The Deployment Guys : Windows Vista

Preventing OEM builds from Accidentally Performing Mini-Setup without the Task Sequence

DeploymentGuys — Tue, 01 Dec 2009 16:48:00 GMT

When you pre-load an OEM build on machines, they are usually set-up to perform Mini-setup as soon as they come up. Customers sometimes have difficulties ensuring that these machines boot to WinPE using boot media or PXE rather than simply performing Mini-setup...(read more)

Useful Script Number 5 - Adjusting the Default User Registry Hive

DeploymentGuys — Fri, 06 Jun 2008 17:03:00 GMT

Michael Murgolo did a great post on the different ways to adjust default settings when building an image (Configuring default settings for Windows image deployment) and one of the options presented was to targeted changes to the Default User Registry hive and profile folders. I had to do this recently and put together a script that can be launched from the MDT task sequence because I was finding my customised Administrator profile wasn't being copied over correctly to the Default User profile as part of SysPrep.

As Michael mentioned in his post - there are three main processes...you first need to load the default user hive (NTUser.dat) - make the changes you require - then unload the user hive. I have reproduced the core part of my script that does this process for discussion.

The first section sets the two variables that will be used - one to store the temp key (sTempHive) that we will load to, and the second to hold the profile file and location that we want to load (sDefaultUserHive)

For Windows Vista the entry """%USERPROFILE%\..\Default\NTUSER.DAT""" refers to C:\Users\Default\ntuser.dat

sTempHive = """HKEY_USERS\Test"""
sDefaultUserHive = """%USERPROFILE%\..\Default\NTUSER.DAT"""
sSName = oUtility.ScriptName
set oshell = WScript.CreateObject ("Wscript.Shell")

iZTIRetValue="1"

We then need to start logging - it's the law :-)

oLogging.CreateEntry sSName & ": Actions Start - Updating Default Profile",LogTypeInfo
oLogging.CreateEntry sSName & ": Loading the Default User hive",LogTypeInfo

The next section runs reg load to load the NTUser.dat file from the default user directory to the temp key (HKEY_USERS\Test) set in the first section - if there is an error the script fails and quits with a specific failure number or we log success.

oShell.run "reg load " & sTempHive & " " & sDefaultUserHive
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to load the registry hive " & sDefaultUserHive,LogTypeError
ZTIProcess=70
Exit Function
End If
oLogging.CreateEntry sSName & ": Default User Hive Loaded to " & sTempHive,LogTypeInfo
oLogging.CreateEntry sSName & ": Starting Registry Changes... ",LogTypeInfo

Now that the hive is loaded we can start changing stuff...as an example - I have set the code to change the wallpaper and the screen saver for the default user - again with error checking and specific failure codes

This codes sets the wallpaper (the file needs to be where you set the key to :-)

oLogging.CreateEntry sSName & ": Setting Default User Wallpaper",LogTypeInfo
RegPath = "HKEY_USERS\Test\Control Panel\Desktop\"
oshell.RegWrite Regpath & "WallPaper", "C:\Windows\Web\Wallpaper\CorporateWallpaper.bmp", "REG_SZ"
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to update wallpaper file setting",LogTypeError
ZTIProcess=60
Exit Function
End If

...and this codes sets the screen saver (again - the file needs to be where you set the key to :-)

oLogging.CreateEntry sSName & ": Setting Default User Screensaver",LogTypeInfo
RegPath = "HKEY_USERS\Test\Control Panel\Desktop\"
oshell.RegWrite Regpath & "SCRNSAVE.EXE", "C:\Windows\CorporateScreensaver.scr", "REG_SZ"
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to update Screensaver settings",LogTypeError
ZTIProcess=50
Exit Function
End If

Once all of the changes have been made - its time to unload the hive from its temp key - again with logging and error checking

oLogging.CreateEntry sSName & ": Unloading the Default User hive",LogTypeInfo

oShell.run "reg unload " & sTempHive
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to unload the default user registry hive",LogTypeError
ZTIProcess=40
Exit Function
End If
oLogging.CreateEntry sSName & ": Actions completed",LogTypeInfo

The completed script can be added to your MDT task sequence towards the end - so that it runs before the machine SysPreps and reboots for capture.

The complete script - in MDT format (to include logging and access to classes from ZTIUtility.wsf) with a number of other changes included is available on the Deployment Guys SkyDrive:

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Getting caught out by your logon script

DeploymentGuys — Mon, 26 May 2008 11:36:05 GMT

Whenever I go onsite with a customer to start a Windows Vista deployment project I always like to discuss with them the issues that we will be having during the project. I do this so that, together, we can try and avoid having the issues in the first place. Most of the issues the customer is already aware of as they have been testing Windows Vista in a laboratory environment for a while; however, there is one issue that nearly always catches them unaware and gives them major headaches, their logon script.

This is often one of the biggest problems that a company will have when trying to deploy Windows Vista. The reason that most people do not notice that the logon script does not work on Windows Vista is because they have done their testing only in a laboratory environment where the logon script does not exist.

Let's look at a hypothetical example. Contoso developed a MS-DOS based logon script when they first rolled out their systems on Windows NT 4.0. When Windows 2000 was realised, they made some amendments and added more code to the script in order for it to work on the new platform. When Windows XP was released, they had to tweak it again and add substantially more code in order to be able to migrate it to the Windows XP platform. Because the script has been extended each time they rolled out a new OS, it is now a monster of a script with almost 2000 lines of code.

Now, based on their past experience, they have assumed that they will just need to tweak it and probably add some more code so that it works with Windows Vista, consequently, they have not actually gotten around to testing the script yet, nor assign the resources to this task. Big mistake, because they haven't realised that the chance of the script working 100% on Windows Vista is almost 0.

Why? The new security model that Windows Vista uses, that's why. Let me give an example. Contoso has an application that is vital to their business. It is an application that requires certain keys to exist in the HKEY_CURRENT_USER section of the registry, and without those keys the application will not start. Because Contoso users do not have roaming profiles, the IT team added the following line to their logon script to ensure that this application always works, regardless of which computer the user logs on to:

regedit.exe /s %logonserver%\vitalapp.reg

Consequently, when the user logs on the registry file imports the required keys into the registry and the application works correctly, and because this is in the logon script the process is invisible to the end user. However, if the same script is run on Windows Vista, the following window will appear during the execution of the logon script:

The famous (or infamous...?) User Account Control (UAC) window

This window will appear because the resource regedit.exe is a protected file that requires administrative rights to be able to run it. Unfortunately for Contoso, their logon script imports 12 different registry files which means that their logon script causes the UAC prompt to appear 12 times.

There are several ways to stop this message appearing, but they all reduce the overall level of security of the operating system (for example, you could disable UAC or give all users admin rights).

But don't panic! There are plenty of solutions that you can use to solve these issues whilst maintaining the UAC feature and the extra security benefits that it gives. The method I also recommend to customers is to use custom ADM files to create the registry keys, see here for a good guide on how to do it. That way, every time the user logs on and receives their group policy configuration, the registry key will be created. And, because it runs in a different context to the user, it will have enough permissions in the registry to create the keys without invoking the UAC window.

If you are considering, or even if you have already started, deploying Windows Vista in your business environment, I strongly recommend that you test your logon script thoroughly and as soon as possible on Windows Vista. The last thing you want is to have to put the deployment on hold when the problems start appearing.

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain