Version 3 of AutoSPInstaller introduces complex remoting functionality that, although effective in most cases, requires certain conditions in order to work properly:

  • All target servers must already exist and be online.
  • Server names must be entered in NetBIOS (un-dotted) form (e.g. SPSERVER, not and be resolvable as such.
  • All accounts specified in AutoSPInstallerInput.xml must already exist.
  • The script MUST be run as the dedicated installer account (not farm account), and it must already have local Administrative privileges on all servers in the farm and on the server where script is being run.
  • Good network connectivity among all farm servers, including ability to access shares etc.
  • Script and installation files are accessible from all farm servers via UNC path (either explicitly shared e.g. \\SERVER\Share\SP\, or admin share e.g. \\SERVER\D$\SP\). Mapped network drives (e.g. Z:\) are NOT supported.
    • You must kick off the script from a UNC path, even if the files reside locally on the server from which the script is launched
    • Full Control to the share is best, in case any missing tools (e.g. PsExec) need to be downloaded and written to the share
    • If UAC is turned on, the share AND NTFS permissions may need to be set to Everyone-Read as a minimum – under investigation
  • Outbound Internet connectivity may be required if certain utilities/files (e.g. PsExec.exe) aren’t already present.
  • IE Enhanced Security Configuration may need to be turned OFF on all remote servers, but this hasn’t been confirmed 100%. If in doubt, turn it off and try again.
  • The Secondary Logon service must be started on all target servers for remote installation.

Also, in addition to open issues that members of the community have logged, here are some known issues with the current (v3) release:

  • You may see “powershell.exe exited on <SERVER> with error code –1” displayed in the console; this is simply due to the forced exit of the PowerShell process when invoked by PsExec.
  • If you get a “\\share\folder\AutoSPInstallerMain.ps1 is not recognized as the name of a cmdlet, function, script file...” error, this may be due to the default IE ESC enabled state on remote servers – try disabling it in advance.
  • You may see “The remote use of BITS is not supported” if any of the Adobe PDF files aren’t already present in the PDF folder while performing a remote install. To avoid this, simply download them in advance according to the instructions in the ReadMe.txt in the PDF folder.

That’s all for now, happy remoting!


Last edited Mar 28, 2013 at 1:13 AM by brianlala, version 4


SpRambler Dec 17, 2015 at 6:11 PM 
This is old but...
Yes you should do differently.
Offloading means either:
1. You put the ssl certificate on the load balancer and continue your route to the servers on http => web apps should be created with http on port 80 (default) or other. less secure since traffic from load balancer to servers is not encrypted.
2. You can put the certificate on the load balancer and configure the certificate profiles or settings on the load balancer to decrypt and recrypt to continue with https to the servers. this way your traffic is encrypted from end to end. this requires an https webapp on port 443 (default) or other.

vishalseth Oct 30, 2014 at 7:12 PM 
There seems to be an issue when trying to set up a 2013 environment to be configured with SSL offloading or termination to the LB. In this case we want the URL to read https but port to be 80. 1. This fails the creation of the web app and site collection. 2. It attempts to auto configure and import a self signed certificate just because the url is https. We don't want that since we are offloading. Should we be doing things differently?