C:\SP\Automation\AutoSPInstallerConfigureRemoteTarget.ps1 : The term 'C:\SP\Automation\AutoSPInstallerConfigureRemoteTarget.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1

C:\SP\Automation\AutoSPInstallerConfigureRemoteTarget.ps1

  + CategoryInfo          : ObjectNotFound: (C:\SP\Automatio...emoteTarget.ps1:String) [], Comm
 andNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

powershell.exe exited on TESTWFE with error code 1.

Dec 21 '18 00:12 hornickj

Have you confirmed that this is really an issue with AutoSPInstaller? Or is it just a problem that you're having? For example, have you checked that the path mentioned in the error is valid?

Normally it's useful to provide some context, any troubleshooting steps that you've attempted, etc. rather than just an isolated error message.

Dec 21 '18 04:12 brianlala

Sorry for not including more information related to it.

What I’m doing is dropping the custom XML file onto the .bat file and it starts the process, however the traditional SharePoint GUI dialog box pops up and wants the installation key along with confirming the directory locations.

A bigger issue I’m running into is the installation to remote systems within the XML file. I’m able to run a PsExe remotely on this system, however it doesn’t seem to see the PowerShell script. The error I’m seeing is the following:

Server: TESTWFE
Testing connection (via Ping) to "TESTWFE"...Success.
Updating PowerShell execution policy on "TESTWFE" via PsExec...

powershell.exe exited on TESTWFE with error code -1.

Enabling PowerShell remoting on "TESTWFE" via PsExec...

C:\SP\Automation\AutoSPInstallerConfigureRemoteTarget.ps1 : The term 'C:\SP\Automation\AutoSPInstallerConfigureRemoteTarget.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1

C:\SP\Automation\AutoSPInstallerConfigureRemoteTarget.ps1

  + CategoryInfo          : ObjectNotFound: (C:\SP\Automatio...emoteTarget.ps1:String) [], Comm
 andNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

powershell.exe exited on TESTWFE with error code 1.

Starting remote session to TESTWFE... New-PSSession : [TESTWFE] Connecting to remote server TESTWFE failed with the following error message : The WinRM client cannot process the request. The authentication mechanism requested by the client is not supported by the server or unencrypted traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configuration or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: Negotiate Kerberos For more information, see the about_Remote_Troubleshooting Help topic. At C:\SP\Automation\AutoSPInstallerModule.psm1:6724 char:20

... $session = New-PSSession -Name "AutoSPInstallerSession-$server" -Aut ...
```
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
- CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException
- FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed

Script halted!

I really do appreciate how detailed the script is in the process.

Joey

From: Brian Lalancette [email protected] Reply-To: brianlala/AutoSPInstaller [email protected] Date: Thursday, December 20, 2018 at 10:26 PM To: brianlala/AutoSPInstaller [email protected] Cc: Joey Hornick [email protected], Author [email protected] Subject: Re: [brianlala/AutoSPInstaller] AutoSPInstallerConfigureRemoteTarget.ps1 (#32)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Have you confirmed that this is really an issue with AutoSPInstaller? Or is it just a problem that you're having? For example, have you checked that the path mentioned in the error is valid?

Normally it's useful to provide some context, any troubleshooting steps that you've attempted, etc. rather than just an isolated error message.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/brianlala/AutoSPInstaller/issues/32#issuecomment-449243980, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AogfeKWmWgmYF7HZUi3M0BDlIpl1qXj2ks5u7GMGgaJpZM4ZdH8J.

Dec 21 '18 15:12 hornickj

For the second issue, if you haven't manually copied all the required files (C:\SP*.*) to each target SharePoint server, then the path C:\SP\Automation\AutoSPInstallerConfigureRemoteTarget.ps1 won't exist on other servers than the one you're running the script on. The best way to avoid this is to run the script from a UNC path like \server1\c$\SP\Automation - this absolute path should be resolvable on all servers (assuming permissions are set correctly).

For the first issue, I have found that this is usually because there's an extra XML file located in the \Automation\ directory that's accidentally getting picked up by the script. Make sure only the XML file you're using as input (dragging onto the .bat) is present in that directory.

Hope this helps, Brian

Dec 21 '18 16:12 brianlala

Thank you for the quick response, I wasn’t sure if the script would copy the contents over or not. I wasn’t able to find any commands referencing that process, but also didn’t want to make any assumption.

Joey

From: Brian Lalancette [email protected] Reply-To: brianlala/AutoSPInstaller [email protected] Date: Friday, December 21, 2018 at 10:15 AM To: brianlala/AutoSPInstaller [email protected] Cc: Joey Hornick [email protected], Author [email protected] Subject: Re: [brianlala/AutoSPInstaller] AutoSPInstallerConfigureRemoteTarget.ps1 (#32)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

For the second issue, if you haven't manually copied all the required files (C:\SP*.*) to each target SharePoint server, then the path C:\SP\Automation\AutoSPInstallerConfigureRemoteTarget.ps1 won't exist on other servers than the one you're running the script on. The best way to avoid this is to run the script from a UNC path like \server1\c$\SP\Automation - this absolute path should be resolvable on all servers (assuming permissions are set correctly).

For the first issue, I have found that this is usually because there's an extra XML file located in the \Automation\ directory that's accidentally getting picked up by the script. Make sure only the XML file you're using as input (dragging onto the .bat) is present in that directory.

Hope this helps, Brian

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/brianlala/AutoSPInstaller/issues/32#issuecomment-449430419, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AogfeFm-cowzfq167CTB9Ne0zbCvzdZUks5u7QkogaJpZM4ZdH8J.

Dec 21 '18 16:12 hornickj

Running it from a UNC path is a much better path so all systems are able to see the same files (and takes out human error.). I hope this is the final error/challenge I face:

From log file:

| Automated SP2016 Remote Installs | | Started on: 12/21/2018 4:34:21 PM |

Enabling WSManCredSSP for "TESTWFE"
Enabling WSManCredSSP for "TESTCACHE"
Enabling WSManCredSSP for "TESTWORKFLOW"
Enabling WSManCredSSP for "TESTSEARCH"

Server: TESTWFE
Testing connection (via Ping) to "TESTWFE"... Success.
Updating PowerShell execution policy on "TESTWFE" via PsExec...
Enabling PowerShell remoting on "TESTWFE" via PsExec...
Starting remote session to TESTWFE...
Starting remote session to TESTWFE...
Starting remote session to TESTWFE... PS>TerminatingError(): "Key cannot be null. Parameter name: key"

TerminatingError(): "Key cannot be null. Parameter name: key" TerminatingError(): "Key cannot be null. Parameter name: key"

Script halted!

From PowerShell dialog: Configuring PowerShell remoting... WARNING: The updated configuration might affect the operation of the plugins having a per plugin quota value greater than 1024. Verify the configuration of all the registered plugins and change the per plugin quota values for the affected plugins. powershell.exe exited on TESTWFE with error code -1.

Starting remote session to TESTWFE...
Starting remote session to TESTWFE...
Starting remote session to TESTWFE...

Script halted!

Exception : System.ArgumentNullException: Key cannot be null. Parameter name: key at System.Collections.Hashtable.ContainsKey(Object key) at System.Management.Automation.Language.PSGetDynamicMemberBinder.GetIDictionaryMember(IDict ionary hash, Object key) at System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1) at System.Management.Automation.Interpreter.DynamicInstruction`3.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame) TargetObject : CategoryInfo : OperationStopped: (:) [], ArgumentNullException FullyQualifiedErrorId : System.ArgumentNullException ErrorDetails : InvocationInfo : System.Management.Automation.InvocationInfo ScriptStackTrace : at Get-MajorVersionNumber, \staging\SP\Automation\AutoSPInstallerModule.psm1: line 7772 at Start-RemoteInstaller, \staging\SP\Automation\AutoSPInstallerModule.psm1: line 6814 at Install-Remote, \staging\SP\Automation\AutoSPInstallerMain.ps1: line 145 at <ScriptBlock>, \staging\SP\Automation\AutoSPInstallerMain.ps1: line 433 at <ScriptBlock>, <No file>: line 1 PipelineIterationInfo : {} PSMessageDetails :

From: Brian Lalancette [email protected] Reply-To: brianlala/AutoSPInstaller [email protected] Date: Friday, December 21, 2018 at 10:15 AM To: brianlala/AutoSPInstaller [email protected] Cc: Joey Hornick [email protected], Author [email protected] Subject: Re: [brianlala/AutoSPInstaller] AutoSPInstallerConfigureRemoteTarget.ps1 (#32)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

For the second issue, if you haven't manually copied all the required files (C:\SP*.*) to each target SharePoint server, then the path C:\SP\Automation\AutoSPInstallerConfigureRemoteTarget.ps1 won't exist on other servers than the one you're running the script on. The best way to avoid this is to run the script from a UNC path like \server1\c$\SP\Automation - this absolute path should be resolvable on all servers (assuming permissions are set correctly).

For the first issue, I have found that this is usually because there's an extra XML file located in the \Automation\ directory that's accidentally getting picked up by the script. Make sure only the XML file you're using as input (dragging onto the .bat) is present in that directory.

Hope this helps, Brian

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/brianlala/AutoSPInstaller/issues/32#issuecomment-449430419, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AogfeFm-cowzfq167CTB9Ne0zbCvzdZUks5u7QkogaJpZM4ZdH8J.

Dec 21 '18 16:12 hornickj

I got exactly the same error. After some test I found out the the error was generated within the remote function "Start-remoteinstaller" by not getting the Version nummber. After commenting out line 7073 and 7074 in the AutoSPInstallerModule-File:

$spYear = $xmlInput.Configuration.Install.SPVersion

$spver = Get-MajorVersionNumber $spYear_

and hardcoding the correct version number into the variable: $spVer ="16" the script started the remote installation in new PSSession Window correctly. I have had some problems with the version nummber in earlier installations, too, and have been able to correct it this way. There seems to be a problem with reading the hashtable.

Apr 13 '21 09:04 EckhardH