Quantcast
Channel: AutoSPInstaller
Viewing all articles
Browse latest Browse all 2279

Commented Unassigned: Couple of strange behaviors with Remote-Install function in multi-server install: Errors out on first run with "there are other servers specified as farm members in: \\..AutoSPInstallerInput.XML but is not set to "true"-nothing else to do" [20724]

$
0
0
__Background__:
1. Using the [106186](https://autospinstaller.codeplex.com/SourceControl/changeset/106186) release
2. Topology: 1 SQL, 1 WFE, 1 APP
Attached: our XML

__Behavior__:
We've been firing off the AutoSPInstaller.bat file from the WFE server in our case. Everything runs fine from checks, prereq installs, binary install, cumulative update, farm creation from WFE and it abruptly stops the script when trying to run Remote install on APP with [this](http://i.imgur.com/o961vF7.png) error:

>
> -There are other servers specified as farm members in:
> -\\...\AutoSPInstallerInput.XML
> -but <RemoteInstall> is not set to "true" - nothing else to do.
>

...

__Workaround__:
Interestingly, when we fire off this batch file second time time from WFE server then the script executes remotely to APP just fine. This led us to the guts of Franken-Scripts and we added a check for remote install (copied what you already have lines 64-80 in Main.ps1) in Remote-Install function. We noticed that the registry values as correct as we go through install but the value of $enableRemoteInstall does not get updated properly unless we did this check. At this point, the script was kicking off remotely fine :)

But we ran into another hiccup right after remote install was preparing to start on APP-
> "Cannot bind argument to parameter 'SecureString' because it is null"

Tracing the code, we determined that it didn't have credential value passed, so we added a check for this as well (also something you already have in Main.ps1 in this region- '#Region MAIN - Check for input file and start the install").

With these two changes (our current version of Main.ps1 also attached), we were able to run things without a hicchup and are happy. We just want to reach out about this before we get too lost in copying pasting around :)

__Question for community, brianlala__:
Why us!? jk What are we doing different that no one else seems to be reporting this issue? Or has anyone else seen this issue?

Let me know if I can clarify anything here.

Thank You,
Samir Raut
Comments: ** Comment from web user: nicholasromyn **

My workaround is to run the script from a non-sharepoint server, such as SQL or a desktop, using a dedicated account for setup with the appropriate permissions. If a reboot is required, I have autologin set to true, and the install continues (until manual intervention is required for the Farm setup). Not super clean, but then again, Windows' support for remote scripting is pretty poor so we're stuck with what we have.
The other way I've been dealing with this is to use an image with the binaries (or at least prerequisites) already installed. It's probably worth the effort to spin up an image you can re-use if you're doing more than 2-3 of these.


Viewing all articles
Browse latest Browse all 2279

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>