This project has moved and is read-only. For the latest updates, please go here.

AutoSPInstaller not handling .pvt domain very well

Topics: Feature Requests, Feedback
Jun 9, 2014 at 8:59 PM
Up until the latest bits (5/14), AutoSPInstaller has always been great at being re-entrant as problems arise. I am working within a customer domain where the Farm and service accounts are of of the form xxxx.pvt\spFarm, etc. I discovered that the Throw in the IF block of line 2064, after this cmdlet: New-SPManagedAccount -Credential $credAccount | Out-Null needed to be emptied-out, i.e. { } in order to get past the "managed account already created" exceptions I was seeing. Once I did this temporary change in AutoSPInstallerFunctions, I was then able to change the accounts to xxxx\spFarm, xxxx\spServices, etc. in the xml input file and all was good.

If there is a way to code around this in a permanent way, it would be better.

Jun 11, 2014 at 3:08 PM
Accounts specified in that format typically don't have a dot in the domain portion - you'd normally use XXXX\spFarm rather than xxxx.pvt\spFarm. Is this the case, or does your NetBIOS domain name really have a .pvt in it?

Jun 11, 2014 at 3:19 PM
Hello Brian,

Not a good answer, but it was a mixed bag. For some reason, several identities required the .pvt appended, but most did not. When I have encountered .local domains in the past, I never appended .local and did not have to - as expected. I reported this in case someone was in a situation where the NetBIOS domain name was in fact appended with a TLD like .pvt. I was able to work around this as I noted, then I changed the XML input to match what SP had in Managed Accounts - then when I ran again, all was OK. Because the build I was using was new to me, I wasn't sure if the Throw in the aforementioned code line had been there before or not - it just seemed like AIS was not handling the errors gracefully, but this was not a test, but a real-world "get it built" situation.