Archive | December, 2012

Domain with suffix fails in AutoSpInstall

14 Dec
  1. First if you have not used AutoSPInstaller it is greatness. super handy for setting up multiple servers, multiple zones with SharePoint 2010 and now 2013. There are a lot of things you can forget, and this tool makes it all config file driven. good stuff.
So the situation is I was working through the 2013 support and getting a solid baseline cloud environment setup in cloudshare.
I had provisioned a few different VMs to match the recommended architecture for SP2013.
  • I had a SQL server..
  • and 2012 standard server,
  • and a 2012 Domain controller.
The domain that was provisioned was something like AD2012.loc. I went through the steps of adding the other two boxes to the domain. Letting cloudshare know I did it, and changed the default logins.
All so far so good. I downloaded the SP2013 bits, and the AutoSPInstaller and the new configuration GUI tool. Looks like we are ready to go.
SP2013 has a few reboots it may need to do in order for the process to finish, and for that to be automated you have an option to automatically login as admin. Which I selected..
However. the first part of the script say it is looking to verify that administrator account and I get this error:
Checking credentials: “AD2012\Administrator”…Invalid – please try again.

now you will notice that the domain is not correct.it is missing the little .loc at the end.
So I thought.. maybe there is a bug in the script.. so I looked through the script to see where this was happening..and it was simply pulling in an $env variable. UserDomain.
that should be correct.. but it wasn’t. see the powershell output below..
PS C:\users\Administrator.AD2012\Desktop\AutoInstall\AutoSPInstaller> $env:UserDomain
AD2012

PS C:\users\Administrator.AD2012\Desktop\AutoInstall\AutoSPInstaller> $env:UserName
Administrator

Ok, maybe there is another way to go about this:

PS C:\users\Administrator.AD2012\Desktop\AutoInstall\AutoSPInstaller>[Security.Principal.WindowsIdentity]::GetCurrent().Name

AD2012\Administrator

Same issue.
then I came across this article.. which seemed to cover that same issue.
  1. So I gave this a go:

    PS C:\users\Administrator.AD2012\Desktop\AutoInstall\AutoSPInstaller>  [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name

    AD2012.Loc


    Bingo, exactly what I was looking for. Now to modify the script and see if we can’t get a totally happy unattended install going.