No Mapping Between Account Names and Security IDs – SQL Server Install and SysPrep Generalize
Recently, a colleague and I were working on creating a set of virtual machines to be used in a SharePoint play-pit environment hosted by Hyper-V.
After creating a base Windows Server 2008 R2 VM, we used SysPrep to clone the base image and start building our the servers. We built a nice DC and added service accounts for SQL services and then started building SQL Server 2008 VM.
During the SQL Server installation, after entering details of the relevant service accounts, the setup failed to progress to the next step, displaying the message: ‘The credentials you supplied for the xxx service are invalid…’
After double checking the service account details numerous times, I was stumped. We went to numerous lengths to try and resolve the issue – including rebuilding the DC and SQL VMs a couple of times.
I tried adding the service accounts to the Local Administrators groups (I don’t know why as I knew the service accounts didn’t require these permission levels, but by this time it was getting frantic). Then I noticed that after the account was confirmed as joining the group, it disappeared from it!
Going back to the SQL Server installation, I tried browsing to the account name rather than type it in, and although the account was found, a different error was generated after attempting to confirm the account – “..No mapping between account names and security IDs was done.”
After some fishing around, I linked this error message back to the way we had sysprep’d (cloned) our Base VM!
Casting our minds back to the cloning of the base VM we were presented with this dialog:
By default, the ‘Generalize’ option is un-ticked. This is ABSOLUTELY KEY as, only when selected, will it regenerate security IDs (SIDs). Leaving it blank (as we did) means that all our cloned VMs were using duplicate SIDs, and hence the peculiar behaviour and failed SQL Install!.
We cloned our original base VM once more with SysPrep, but this time remembering to click the box, and rebuilt our DC and SQL Server successfully!
I hope this comes in useful for someone.
p.s. Big thanks to Sam Wainwright who patiently re-built the VMs and reinstalled SQL countless times on my command and was patient to the end!
thank you for your great help. I spent a week to figure it out. I am going to reclone my VMs.
Unbelievable. This has been frustrating me for hours. There appears to be a flaw in Russinovich’s statement about SIDs not being important. Wish I could get ahold of newSID. Ah well, sysprep it is. Thanks again for posting this.
Thank you. Spend the night fighting this at least you gave me the root cause. Fix worked.
Arrrggghhh after reading this I ran the PSgetSID tool and hey presto, I’ve suddenly got alot of work to do! Damn that, but well done for this post. It turned out to be a customers template they said that I could use! Note to self Trust only yourself!
Thank you for taking the time to post this. I just ran across this issue today and spent several hours desperately searching for a resolution. Your scenario is exactly the same as mine, and now I have a fix!