Sysprep and Settings Autologon Keys with FirstLogonCommands

Ran into small problem today when setting up a Vmware View Repurposed Thin Client. The behavior i wanted has the Windows 7 machine running sysprep. On first boot it autologon's to the local administrator account. On that first logon it runs all the nessary FirstLogonCommands from the sysrep unattended file. In those commands are the nessary commands to change the autologon to have it login to a local viewuser account that has had it window shell replaced. The problem was that the FirstLogonCommands where failing at setting the autologon registry keys correctly.

Problem
It turns out that because AutoLogonCount is set to 1, on logon it decrements it to zero. On logoff and reboot when Windows 7 sees the AutoLogonCount set to zero it deletes the keys "AutoAdminLogon", "AutoLogonCount", and "DefaultPassword" from the registry. Those same values I had just set for the ViewUser.

Solution
The easy solution is easy, I just have to add a command to delete the AutoAdminLogon key from the registry my self. Then Windows never goes back and cleans up the Auto Logon Registry keys that where just set.

<AutoLogon>
    <Password>
        <Value>password</Value>
        <PlainText>true</PlainText>
    </Password>
    <Domain>.</Domain>
    <Enabled>true</Enabled>
    <LogonCount>1</LogonCount>
    <Username>Administrator</Username>
</AutoLogon>

This is how it will look in the sysprep unattended file to set the autologon after the administrator autologon.

      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v AutoLogonCount</CommandLine>
        <Description>Remove AutoLogonCount so that other autologon settings stay</Description>
        <Order>18</Order>
        <RequiresUserInput>false</RequiresUserInput>
      </SynchronousCommand>
      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v DefaultDomainName /t Reg_SZ /d .</CommandLine>
        <Description>Set default Domain for autologon</Description>
        <Order>19</Order>
        <RequiresUserInput>false</RequiresUserInput>
      </SynchronousCommand>
      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v DefaultUserName /t Reg_SZ /d ViewUser</CommandLine>
        <Description>Set default UserName for autologon</Description>
        <Order>20</Order>
        <RequiresUserInput>false</RequiresUserInput>
      </SynchronousCommand>
      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v DefaultPassword /t Reg_SZ /d password</CommandLine>
        <Description>Set default Password for autologon</Description>
        <Order>21</Order>
        <RequiresUserInput>false</RequiresUserInput>
      </SynchronousCommand>
      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v AutoAdminLogon /t Reg_SZ /d 1</CommandLine>
        <Description>Set AutoLogon to enabled </Description>
        <Order>22</Order>

VMware View 4.5 - Configuring the Local Account on the Thin Client (Part 3)

This post is part of a Series of Posts

• VMware View 4.5 - Thin Client with PCoIP using Windows 7 (Part 1)
• VMware View 4.5 - Building the Windows 7 Thin Client (Part 2)
• VMware View 4.5 - Configuring the Local Account on the Thin Client (Part 3)

Configure ViewUser Account and the Shell Replacement

Now login to the ViewUser account. We want to change the Shell, so that when this account is logged all they can see is Vmware View Client. But first some housekeeping. Run this command from PowerShell so that our unsigned script is allowed to execute on this account.

Set-ExecutionPolicy -scope Currentuser -executionPolicy Unrestricted

Now navigate to the folder we placed the script file in. Right click VMwareViewShell.ps1 and choose "Run with PowerShell". It should launch the VMware View Client and proceed to the username and password Screen.

You should be able to login and view your VMware View Desktop, test that and USB redirection. If the script is working correctly you should be able to close the VMware View Client it should relaunch self and clear the username and recenter it to the screen. Continue testing till your satisfied  that the script works correctly. Once it does we can now replace the explorer shell with the script instead. To do this we need to make a registry change.

VMware View 4.5 - Building the Windows 7 Thin Client (Part 2)

Note: that this works with all View Client versions View 4.5, 4.6 and 5.0.

Update 4-4-2011- Added the scripts and the fix windows size Powershell shell.

This post is part of a Series of Posts

• VMware View 4.5 - Thin Client with PCoIP using Windows 7 (Part 1)
  
• VMware View 4.5 - Building the Windows 7 Thin Client (Part 2)
• VMware View 4.5 - Configuring the Local Account on the Thin Client (Part 3)

The this guide will walk you through building a Thin Client will have the following details.

• Running Windows 7
• Using the PCoIP Protocol
• User authentication based on AD
• The Thin Client will have a replaced shell to limit the users to VMware View Client only.
• The Client can be configured to use a particular Pool or offer the user any they have access

Thin Client OS Install

The Thin Client only needs to be protected and run VMware View. The OS is about the only software we need installed and I'll be reploying clones of this machine so I only plan to build it once by hand. Starting with a formated machine that's same as the hardware it'll be running on in the lab. I run a fresh Windows 7 install from DVD. After the Install with normal options for your enviroment. I make the following changes.

• Updates service configured to auto update and download other microsoft updates
• Install all possible Microsoft updates
• Update any drivers
• Disable UAC
• Set for best performance
• turn off system restore points
• Enable remote desktop.
• Stop and disable the Themes Service
• Check that the newest version of  Powershell is installed
• Change Power settings
• Don't password protect awaking from sleep
• Let Sleep monitor and/or machine

Creating a ViewUser and Changing its Shell

We need a Local User that we will use to run VMware View Client from. We could have users log in as themselves but I didn't for a the following reason. If we make users login to Windows. They would login to the machines, profile would be created, then View Client Launched, Authentication is passed, then finally the user is prompted for what VM they would like to access. After they select it they have to wait for it to login and create another profile. Very time consuming. We can skip all of the first profile copy issues by createing a already logged in local user. So Instead lets create the local user.

Using Sysprep with CopyProfile in Windows 7 and Windows Server 2008

First rule of testing a sysprep unattened file:

Thou shall test your unattend xml file on a newly unconfigured OS install before blaming the file.

The Reason: Before becomeing a server admin I made my way by developing new and better ways to deploy computers on campus. I moved to the server team before Vista came out so my experitise was in mostly with Windows XP. So recently after 5hrs of trying to do the once simple task of copying the administrator profile to the default profile I can say that things have changed.  First let me setup what I'm working on, then share what can so you can avoid the problems I had.

The Goal: To use the <CopyProfile> option with sysprep to copy the Administrator profile to the default profile on a Windows 7.

The Problems: Things that can go wrong will.

• If your using a Virtual Machine that some one else built, you don't know what they did or didn't do. In my case my brother built a tweaked Virtual Machine for Windows 7 stripped for speed. At some point he made the profiles/registry gods upset and sysprep no longer can listen to the <CopyProfile> option. See here for fix. 
• You need to be able to read the local disk Incase the box will not boot or in this case gets stuck in a sysprep endless boot. I can't over state this. You can not see whats wrong with sysprep with out this. In my case I used a network PXE server with WinPE loaded with VMware Drivers. However note that PXE doesn't work with VMXNET3 and ESX 4.1 as of yet. See my other post.
• Sysprep isn't your friend, its more of the coworker you have to deal with. Learn to get along with it as its not going anywhere. 

The Solution
The only truly supported way to copy a profile in Windows 7 to the default to do so by using Sysprep to do the Profile copy. If you search the web many people list ways but they shouldn't be used in real production environments and require manually editing the registry files. And honestly you don't should need these shortcuts as doing the copy via sysprep is easy enough if you follow this post.

First configure the Administrator Profile to the way you want. Make sure you opened most programs and everything works. I'm not going to go through the finer points of this and may make a post on it later and link to it here.

VMware View 4.5 - Thin Client with PCoIP using Windows 7 (Part 1)

Note: that this works with all View Client versions View 4.5, 4.6 and 5.0.

Series of Posts

• VMware View 4.5 - Thin Client with PCoIP using Windows 7 (Part 1)
• VMware View 4.5 - Building the Windows 7 Thin Client (Part 2)
• VMware View 4.5 - Configuring the Local Account on the Thin Client (Part 3)

For what must be the fourth time at work we're looking in to deploying a Thin Client environment. This time we're focusing on VMware View 4.5 and looks to have addressed many of the problems we had in the past. We've stood up a VMware View and a few other systems in the past but weren't satisfied with them.

Our big use case where View machines can be offered to students via VPN and connected to from home using the student's own hardware and everything works perfect. However one of the use cases management wants VMware View to fill is as a replacement for actual Student labs on campus. Where a lab machine is running VMware View and offering students their choice of VM's. This also needed to be accomplished with the following firm constraints.

• VMware View 4.5
• Reuse existing PC's in labs as the client hardware.
• Use PCoIP has the protocol for enhanced multimedia experience.
• Lock down the PC hardware.
• Management of the hardware is required. (Example: SCCM and/or Forefront)
• Easy of Client deployment.

The issue became what OS and how to configure it on the current lab hardware. VMware doesn't really supply a good guide on this for View 4.5. What’s even more surprising appears to be a lack of a good community supplied setup guide; at least that I've found after looking. Sorry if' I've just missed it.

And there appears to be no way of doing a bootable image (WinPE or Linux) that uses PCoIP.  Further research believes me to believe that short of running Windows embedded or a full blown copy of Windows is the only option for PCoIP on re-purposed hardware client.

After approaching this problem and lack of helpful walk through on line I hope this will be just that to others interested in a same or similar setup. I have worked out a method to reach all these constraints and am interested on what the on-line community thinks of it as I will be using Windows 7 as the client OS and PCoIP as the protocol. I'll be posting the solution and steps to creating it in next several posts starting with this one as the length to this guide proves necessary.

Special Thanks to Patrick Towles, Paul Ritter, and Matthew Campbell for their help on this subject..