Autologon after creating virtual machine from template with VMM 2012 SP1 beta

I’ve been having a fun time trying to get System Center Virtual Machine Manager 2012 SP1 beta to do things. It’s been even more fun when I’ve been trying via the delightful PowerShell – I want to get to a point where I can build/re-build servers quickly and easily.

My most recent conquest has been to get it to make a newly created virtual machine log on at the console at the end of the creation process.

I’m deploying Windows Server 2012 VMs, and have been able to get them to join to my active directory, that was relatively easy. Getting them to log on required some extra fiddling that I wasn’t expecting.

According to the documentation, which is sparse at best (even for the older and not beta non-SP1 VMM 2012) you just use the -AutoLogonCredential and specify a SCVMM RunAs account. What you actually have to specify is an object that contains a RunAs account. If you’ve been getting the VM to join an active directory then this is fairly easy to work out as it’s the same mechanism used to specify the -DomainJoinCredential. You set up a RunAs account via SCVMM which contains the username, password and domain, then just specify the name of this account (which is not necessarily the Active Directory SamAccountName – depends what name you gave the RunAs account when setting it up). This is quite nice as it means you don’t need to specify passwords in the script. e.g. to set up the credential object you use :

$DomainJoinCredential = Get-SCRunAsAccount -Name <your runas account>

In my case I wanted the server to log on as the same user I was using to join the server to AD, should have been simply a case of adding:

-AutoLogonCredential $DomainJoinCredential -AutoLogonCount 100

to the end of my New-SCVMTemplate command line.

Fail. The VM tries to log on but gives the following on screen:

Other user
The user name or password is incorrect. Try again.

The VM is still joined to AD though, using the same credential object, so I know that the username and password is definately correct. It’s clearly not being passed to the VM’s OS properly. To fix this I changed my script a little and made a new code block to add all the autologon stuff in one place. It seems as though the critical bit that’s missing is the domain name. I now have the following code to modify the template I’ll use to create the virtual machine from:

Write-Host "Add autologon credential..."
Set-SCVMTemplate -VMTemplate $Template -AutoLogonCredential $DomainJoinCredential -AutoLogonCount 100 | Out-Null
$Unattend = $Template.UnattendSettings
Set-SCVMTemplate -VMTemplate $Template -UnattendSettings $Unattend | Out-Null

The 6 on the $Unattend.Add line places the command into the oobesystem section of the unattend script.

I’ve previously created the temporary template using New-SCVMTemplate, then retrieved it into $Template by using:

$Template = Get-SCVMTemplate -Name <temporary template name>
This entry was posted in PowerShell, Scripting, Windows and tagged , , , , , , , , , , , . Bookmark the permalink.

4 Responses to Autologon after creating virtual machine from template with VMM 2012 SP1 beta

  1. Storing login/password in registry in plain text isn’t good idea…
    I want to recommend you look at LogonExpert tool

    • rcmtech says:

      The password isn’t stored in plain text, it’s encrypted. Personally, I prefer using SysInternals Autologon.exe to set autologon username/password/domain for Windows:

      However, setting autologon manually is unnecessary when building VMs with SCVMM. You only need to know the password when you set up the RunAs account initially, the password is then not required to be entered – you just specify the RunAs account (which is kind of a combination of username, password and domain). Thus an Administrator can set up the RunAs account and less trusted people can use it without knowing or being able to find out what the password actually is.

      • No, not really, google for — all Windows passwords are easy to extract.

      • rcmtech says:

        …if you have access to the location(s) where they’re stored. You’ll notice that the process above is used for the duration of a server build, during which time sensible people will keep the server well protected, and thus uncontactable. You can’t crack an LSA secret if you can’t get to it in the first place.

        I then use autologon.exe at the end of the build process to set the encrypted autologon username, password and domain to “unknown” to clear out the LSA encrypted “real” data that had been stored in the registry during the build.

        Also, LogonExpert doesn’t state that it currently supports Server 2012/Windows 8 so is possibly no use for the above process at the moment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s