The Deployment Guys : Utilities

Keeping An Eye On USMT Progress v0.2

Daniel Oxley — Wed, 02 Sep 2009 18:41:00 GMT

Back in June I posted a script that I’d written that displays the progress of the USMT capture and recover phases in a neat HTML window off to one side of the screen; particularly useful if you are capturing/recovering large amounts of data because otherwise it looked like the USMT progress had hung due to the progress bar not moving along for quite some time.

While the script I wrote worked fine I was not 100% happy with it, mostly because it ate up too many CPU cycles, which could sometimes slow down the actual USMT progress; an effect that you would never want to happen! The problem was that there was no quick and easy way to parse the last few lines of a text file in VBScript without first reading in all the previous lines. This meant that as the log file grew, my script took longer and longer to run. So, I took it back to the drawing board, and reworked the innards of it to produce version 0.2!

This time, the script runs extremely quickly and it will barely register on the CPU, meaning that it shouldn’t slow anything else down. It still requires the same parameters to be passed to it when adding to the task sequence, which are detailed below. To add it to the task sequence, simply add the following Run Command Line action before the USMT capture or restore actions (or both):

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTCapture.prg”

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTRestore.prg”

It also has one other very important dependency. You must download tail.exe from the Windows Resource Kit and place it in the Tools folder of the MDT deployment share, along with this script. You can get the tool here, it doesn’t matter that it is the 2003 version, I have tested it on Windows 7 and it works fine. If you don’t put tail.exe in the tools folder, then the script will fail.

The next update might take a while to get round to doing, but I want to remove the requirements for the command-line parameter, and have the script find the progress file on it’s own. Also, it would be good to display more information rather than just the current position in the progress, perhaps an extra line that informs what the current task is that is being run. Also, a few cosmetic changes wouldn't go amiss, but I am a techie not a graphic designer!

Attached to this post is the script file.

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

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Location Deployment Wizard for ConfigMgr 2007

DeploymentGuys — Mon, 17 Aug 2009 19:37:00 GMT

When working on deployment projects, there is often a requirement for a workstation to be customised on a location by location basis. Common workstation customisations which are applied in this manner include:

Localisation settings (locales, keyboard settings, time zones, Windows (Windows Vista/Windows 7) language injection
Domain membership/organisational unit join information
Location based applications to be installed
Site or location based administrator groups or accounts that need to added to the local administrators group

The Microsoft Deployment Toolkit (MDT) and its accompanying database offers features to tailor a workstation based on its location during a deployment. The MDT Database allows locations to be defined and a set of location specific settings can be stored against each entry. When a workstation is been deployed, an MDT database lookup determines its location and collects the relevant build settings for that location. The location is determined by carrying out a lookup of the default gateway on the target workstations assigned NIC against default gateways assigned to locations in the MDT Database. To learn more about the Microsoft Deployment Toolkit and the database supplied with MDT see http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx

During a mass deployment it is quite common for workstations to be built in central locations and then to be shipped to other sites for use. In these circumstances, the MDT Database location functionality may not be as useful as any database location lookups will return settings for the site at which the workstations are being built and not the site to which the workstation will be eventually shipped.

A solution to this is to use a location deployment wizard when using the MDT Database along with System Center Configuration Management (ConfigMgr) 2007 Operating System deployments (OSD) in zero touch scenarios. A location deployment wizard is an HTA that is displayed to the user/build engineer at the start of the workstation deployment process to display the location in which they are currently situated. If the location is the site at which the workstation will be based they can click next and the deployment will continue applying all the deployment settings for that site. However, the wizard allows an “override” for the detected location and allow the user/build engineer to select another location from the MDT Database. Overriding the detected location will apply all of the selected location deployment settings from the MDT Database to the workstation despite it not being at that location. This solution allows workstations to be built in a central location whilst being fully customised for their destination locations.

The location deployment wizard is an HTA that is stored in a customised ConfigMgr OSD boot image and is executed before a ConfigMgr task sequence starts. The HTA uses Operating System Media Pre-Execution Hooks (http://technet.microsoft.com/en-us/library/bb694075.aspx) to place itself before the task sequence window. The location deployment wizard allows inputs that are stored as a ConfigMgr task sequence variable. The location variable can then be used by a ConfigMgr deployment task sequence to recover settings from the MDT Database throughout the deployment (During ZTIGather phase).

Pre-Requisites

The following pre-requirements should be configured in your deployment environment:

System Center Configuration Management 2007 (RTM, SP1, R2 or SP2 beta) environment configured for OSD deployments.
Microsoft Deployment Toolkit 2008 / MDT 2010 Workbench + Database hosted on Microsoft SQL 2005 or 2008 (Express / Standard / Enterprise)
ConfigMgr 2007 console with integrated MDT console functions
The MS SQL Database hosting the MDT Database should be configured to allow NamedPipes
A share should be setup on the MDT Database server for authentication when using NamedPipes from a WinPE environment by using the SQLShare$ method.
ConfigMgr “Network Access Account” should have db_datareader access to the MDT SQL Database
Another AD account should be created which is assigned db_datareader access to the MDT Database. Note This account will be stored in a plain text file in the ConfigMgr OSD Boot image. This account should be limited to just db_datareader access on the MDT SQL Server and denied all other rights on the domain

Location Deployment Wizard Setup Steps

Download the location deployment wizard attached to this post and extract the files to a temporary location on the computer/server which has a ConfigMgr 2007 Console with integrated MDT console functions. There are 4 components which need to be configured in your environment for this solution to operate:

Configure the Bootstap.ini file
Create a custom boot image
Configure Location settings in the MDT Database
Configure CustomSettings.ini file

1. Configure the Bootstrap.ini file

The Bootstrap.ini file contains the settings required by the Location Deployment Wizard to make the initial connection to the MDT Database. These settings need to be configured for your environment:

Edit the Bootstrap.ini file in the Location Deployment Wizard\LocationDeploymentWizard folder. This file is used by the location deployment wizard HTA to connect to the MDT Database for the first time:
- Replace <USERNAME> with the AD account created for reading the MDT Database in the pre-requirements e.g. CONTOSO\MDTDBReader
- Replace <PASSWORD> with the password of the account entered above
- Replace <SQL SHARE FOR AUTHENTICATION> with the name of a shared folder on the MDT Database server e.g. \\MDT01.contoso.com\SQLShare$
- Replace <MDT DATABASE SEVER> with the fully qualified domain name of the MDT Database server e.g. mdt01.contoso.com
- Replace <MDT DATABASE NAME> should be replaced with the instance name of the MDT Database in SQL e.g. MDTDB

2. Create a custom boot image

During OSD deployments a WinPE boot image provides the environment for deploying a workstation. ConfigMgr 2007 provides default boot images in the Operating System Deployment -> Boot Images node in the console. A new custom boot image needs to be generated containing the location deployment wizard HTA and its supporting files – this will execute when the boot image first loads on a workstation:

Create a new custom boot image in the ConfigMgr console using the “Create Boot Image Using Microsoft Deployment” wizard:

Follow the wizard, selecting the default options. On the Image Options page set the Extra Folder to Add as the Location Deployment Wizard folder which is found in the root of the files extracted earlier
Complete the wizard selecting the default options. ConfigMgr/MDT will now create a new customised boot image with the location deployment wizard included.
Assign the boot image to the OSD deployment task sequence that you wish to use the location deployment wizard with:

3. Configure location settings in the MDT Database

Locations and their associated settings need to be configured in the MDT SQL Database, these are typically configured through the interface in the MDT workbench. In the MDT workbench go to the Database >> Locations Node. Here you can add as many different locations as are required for your environment.

For a location to be available to the location deployment wizard it must be assigned at least one default gateway. This can be found in a locations properties on the Identity tab.
If no default gateways for a site are initially known then assign 0.0.0.0 as the default gateway for that location. Although this site will never be automatically detected by the location build wizard, it can be manually selected.
In the Details tab of a locations properties use the SERVERA property to populate sites or country e.g. UK. This is used by the location deployment wizard to break down the locations so there is not just one long list:
Populate any other deployment site settings as required for your deployment including locales, time zones, keyboard settings, UI Language, location specific apps and location specific admins.

4. Configure CustomSettings.ini file

The CustomSettings.ini (http://technet.microsoft.com/en-us/library/bb977690.aspx) is a rules file which is used to automate deployments and setup how to query settings from the MDT Database. The location deployment wizard has its own CustomSettings.ini which is used during Gather phases in a ConfigMgr task sequence to retrieve location settings from the MDT Database. The CustomSettings.ini file included in the supplied location deployment wizard must be customised to your environment:

Edit the CustomSettings.ini file located in the root of the extracted files. The customsettings.ini file is a rules file is used by the MDT script ZTIGather.wsf to gather all of the location based settings from an MDT database:
- All instances of <FQDN MDT DATABASE> should be replaced with the fully qualified domain name of your MDT Database server e.g. mdt01.contoso.com
- All instances of <MDT DATABASE NAME> should be replaced with your MDT Database name in SQL e.g. MDTDB
- All instances of <AUTHENTICATION SHARENAME> should be replaced by your shared folder name on the MDT Database server e.g. SQLShare$

Once the customsettings.ini file has been updated it should be wrapped up into a ConfigMgr package (typically this is the MDT Settings package) and sent to all distribution points on your network which will be used for OSD. This rules package must be used by all Gather phases in your MDT integrated deployment task sequence to gather location settings from the MDT Database.

This post was contributed by Mark Hooks and Richard Smith, consultants with Microsoft Services – U.K.

Keeping An Eye On USMT Progress

Daniel Oxley — Fri, 26 Jun 2009 12:31:00 GMT

I recently did a project where all users had around 25Gb (don’t ask!) of data that had to be migrated with the USMT during the OS deployment. Because of the sheer volume of data, the USMT phases of the project took an extremely long time to complete, and because no on-screen feedback is given of the progress, the customer would often think that something had hung, so they often cancelled the deployment; only to find that it was indeed running correctly. In order to stop them doing this, I wrote a very simple VBS script that showed the current progress of the USMT. It works by simply parsing the progress file, looking for the percentage progress of the process.

I thought I would publish it here, because when I showed it to some colleagues they asked for a copy as they thought it would be useful to use during the lab phases of MDT projects.

It consists simply of a VBS file that requires the path of the USMT log file to be passed as a parameter. The script creates a small HTML window that then displays a single line showing the progress of the USMT as a percentage. You can either launch the script by hand or add it to the task sequence. To add this to the task sequence, simple add the following “Run Command Line" action before the USMT capture or restore actions (or both):

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTCapture.prg”

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTRestore.prg”

Why the two commands lines? Well, the first one is to show the progress of the capture phase of the USMT, and the second is to show the progress of the restore phase. Also, I should point out that the command is launched in this way because MDT needs to launch the command, and then move on. If you don't have the cmd.exe /c "start" part at the beginning then MDT will launch the script and wait for it to finish (which is never) and the USMT commands will never fire. You may also have noticed that I had to put the drive letter in the command path, this is because the variable %SCRIPTROOT% is not available with this usage.

The screenshot below shows what it looks like in action.

Be warned though, this script does consume quite a few CPU cycles because it is probably not the most efficient routine; it was really a proof-of-concept thing that I wrote in order to show that everything was running as expected. When I wrote it I was running it on dual core desktop computers and it didn’t seem to noticeable affect the deployment time.

Attached to this post is the script file.

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

Sharing some simple HTAs

Daniel Oxley — Thu, 26 Mar 2009 16:06:00 GMT

I was recently asked to share these files with a colleague, so I thought I would also share them with everyone via our blog. I developed them a while ago for a deployment project and I have since used them a few times more.

Basically, they are 3 very simple HTA (HTML application) files that prompt the user for information in order to configure either a static IP address, change the local administrator password, or add a computer to a domain. Of course, all of these actions can be accomplished directly via MDT, but I had to create them for a very specific reason where MDT could not be used to for this. They were developed for a Windows XP deployment, so they have not been tested on Windows Vista but I can’t see why they would not work, as long as you ran them elevated. You can be launch them directly from the task sequence in MDT by using the following command:

mshta.exe CUSTOM_Config_Network.hta

CUSTOM_Config_Network.hta

CUSTOM_Config_PWD.hta

CUSTOM_Config_Domain.hta

I have attached the 3 files to this post in a zip file. Please bare in mind that they are pretty simple and don’t have the error checking for every possible error that might occur, so use at your own risk!

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

GImageX Beta for Windows 7 Beta

DeploymentGuys — Wed, 04 Feb 2009 12:47:12 GMT

The Windows Automated Installation Kit (Windows AIK) is a set of tools and documentation that support the configuration and deployment of Microsoft® Windows® operating systems.. By using Windows AIK, you can automate Windows installations, capture Windows images with ImageX, configure and modify images using Deployment Imaging Servicing and Management (DISM), create Windows PE images, and migrate user profiles and data with the User State Migration Tool (USMT).

GImageX is a third-party graphical version of the ImageX command-line tool from the Windows AIK.

With the release of the Windows 7 beta and also the beta of the Windows Automated Installation Kit I’ve updated GImageX to work with these new beta versions. I’ve also tidied up parts of the documentation around installation and tweaked the “mount” functionality to provide better feedback during the operation.

Please note that GImageX is a third-party tool so please remember that you won’t be able to ring up Microsoft PSS to get support with it! However, it uses the official Microsoft published WIMGAPI SDK which is a supported way of working with WIM files.

GImageX Capture Tab

The GImageX beta can be downloaded here and the new beta version of the Windows AIK which it requires can be downloaded here. Please provide feedback, problems, questions, suggestions to the email address listed in the help file contained in the download. As both GImageX and the v2.0 Windows AIK are beta versions please only use these in test environments.

This post was contributed by Jonathan Bennett a Senior Consultant with Microsoft Services, UK.

USMT Error Codes

DeploymentGuys — Wed, 14 Jan 2009 10:38:10 GMT

I was recently configuring the User State Migration Tool for a customer’s MDT server when, during the testing phase, the USMT began failing with an error code (‘return code’ or ‘rc’ when you read the MDT log files). I searched the USMT documentation on TechNet looking for the explanation of what the error code meant, only to discover that I could not find any information at all.

So, after a bit of asking around internally at Microsoft, I have managed to obtain the below list of error codes. I should point out though that this list of error codes is only for version 3.01 of the USMT, I don’t know if there are differences for any past or future versions of the tool.

Error code	Error text
0	USMT_SUCCESS
1	USMT_DISPLAY_HELP
2	USMT_MEMORY_FAIL
3	USMT_INVALID_PARAMETERS (Bad command line)
4	USMT_INVALID_STORE_LOCATION
5	USMT_NO_MORE_TOKEN
6	USMT_UNABLE_SET_SCRIPTFILES
7	USMT_UNABLE_GET_SCRIPTFILES (Can’t find XML file(s) specified in the command-line)
8	USMT_UNABLE_SET_STOREPATH
9	USMT_UNABLE_SET_USERS
10	USMT_UNABLE_FINDMIGUNITS
11	USMT_UNABLE_DOMIGRATION (A file is in use)
12	USMT_FAILED_MIGSTARTUP (Error in XML file ‘Bad XML’)
13	USMT_FAILED_SETMIGRATIONTYPE
14	USMT_FAILED_LOCALONLY
15	USMT_UNABLE_GET_WORKINGDIR
16	USMT_UNABLE_SETKEY
17	USMT_UNABLE_READKEY
18	USMT_TOO_LONG_KEYSTRING
19	USMT_UNABLE_SETCOMPRESSION
20	USMT_ERROR_INSUFFICIENT_RIGHTS
21	USMT_UNABLE_DELETE_STORE
22	USMT_UNABLE_SET_BENONADMIN
23	USMT_ERROR_INSUFFICIENT_STRINGBUFFER
24	USMT_ERROR_UNSUPPORTED_PLATFORM
25	USMT_ERROR_UNABLE_TOVERIFY_PLATFORM
26	USMT_UNABLE_SET_EFSMODE
27	USMT_INIT_ERROR
28	USMT_UNABLE_SET_LAC_LAE
29	USMT_ERROR_CORRUPTED_ENCRYPTED_STORE (Store is encrypted and no or invalid key has been specified)
30	USMT_ERROR_NO_INVALID_KEY (Store is only compressed but a key has been specified)
31	USMT_ERROR_CORRUPTED_NOTENCRYPTED_STORE
32	USMT_ERROR_LOGFILES_INSIDESTORE
33	USMT_INVALID_PLATFORM_FOR_TARGETXP
34	USMT_STORE_VALID_ONLY_FOR_XP
35	USMT_UNABLE_TO_READ_CONFIG_FILE
36	USMT_INVALID_CONFIG_FILE_FORMAT
37	USMT_ERROR_UNABLE_CREATE_LOGS
38	USMT_ERROR_USE_LAC
39	USMT_FAILED_TO_EXCLUDE_FOLDERS
40	USMT_ERROR_UNABLE_CREATE_PROGRESS_LOG
41	USMT_STATUS_CANCELLED

Most of the codes are pretty self-explanatory, but I have included some extra information for some of the more cryptic error messages.

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

Logging All the Configuration Manager Task Sequence Variables

DeploymentGuys — Fri, 29 Aug 2008 18:31:00 GMT

When debugging a MDT based Configuration Manager Task Sequence, it is often helpful to know what certain built-in Configuration Manager variables are set to during a step in the task sequence. For instance, you may want to see if _SMSTSLastActionRetCode was equal to a certain value or perhaps which management point the client is using by checking _SMSTSMP. These variables and more are available in the Microsoft.SMS.TSEnvironment and you can easily log them using the script snippet below:

Dim sVar

Set osdV4 = CreateObject("Microsoft.SMS.TSEnvironment")

For Each sVar in osdv4.GetVariables()
oLogging.CreateEntry sVar & ":" & oEnvironment.Item(sVar), LogTypeInfo
Next

A list of the variables and their values can be found at http://technet.microsoft.com/en-us/library/bb632442.aspx .

The full ZTI-style script is included below. Add the script to the Microsoft Deployment Toolkit package and you can call this script as a task in the task sequence. The variables will be outputted to OutputTSVariables.log.

Try it out and feel free to comment.

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region.

Non-shrinking WIM files

DeploymentGuys — Tue, 26 Aug 2008 10:39:03 GMT

If you make regular changes to your WIM files with the use of the /MOUNTRW or /DELETE switches of IMAGEX, then you may have noticed that your WIM files do not shrink in size after you commit the changes back to the file. You could delete 500mb of data from an image file, only to see the file stay the same size, or even grow by a few megabytes. The reason for this is that the data in a WIM file are not actually removed from the file when deleted, rather the references to it's contents are simply removed; this is a bit like how deleting a file from your C: drive only deletes the reference to it in the allocation table rather than actually scrubbing all the files binary 1's and 0's from the disk sectors.

But don't worry, there is a solution to this which you can use to optimise the size of your WIM files! With the use of the /EXPORT switch of IMAGEX, you simply export the image from the WIM file into a new one, and you can even change the level of compression used. An example of the use of the command is:

ImageX.exe /export existing.wim X new.wim "My optimised WIM file" (where X is the number of the image file you want to export)

If you make regular manual edits to your existing WIM files then you might want to consider including the process of exporting the WIM to a new one into your work routine. However, it is probably not worth using export if you make infrequent or one off changes. One important thing to remember when using the export command is not to lose any of the /FLAGS settings during your export!

The question that clients always ask me about this subject is: why has Microsoft designed IMAGEX like this? The answer is logical, if not always obvious though at first glance. So, why does IMAGEX not optimise the file upon every commit action? Well, for a start, it would be very inefficient to have to do this each time you change the WIM file. Imagine that you add a 10kb file to a 12Gb WIM, then commit the changes. You'd have to wait while IMAGEX streams the 12Gb of data into a new WIM file, which would take a very long time.

Finally, I would not consider it good practice manually editing your WIM files on a regular basis. It would be better to use MDT to include any changes you need to make by incorporating them in future versions of your image files. Infrequent manual changes are fine, but if you are regularly having to manually edit your WIM files in order to include new files/registry keys etc. then you should be looking at automating this process in order to reduce this required manual administration. It will make work easier!

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

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.

Managing Windows Updates

DeploymentGuys — Mon, 19 May 2008 19:03:49 GMT

When creating a new operating system WIM image with MDT, one of the things that you should always examine is the new updates for Windows that you will include; my recommendation has always been to make sure that the image is as up-to-date as possible with all the released Windows updates for the operating system you are going to deploy. During the testing phase of the image you create, you will be able to identify and catch any possible problems that an update may cause. I believe that this is a better approach to patching rather than testing and then deploying each individual update as they are released because it requires less time and work from you, but still ensures that an update will not give problems.

With MDT you add the updates to the workbench (as you can see in the screenshot below) and MDT will install them at the correct point in the installation process, couldn't be simpler!

Note: MDT expects the updates in the MSU format, whereas BDD wants the MSI format.

However, what is not a simple task is the actual job of identifying and downloading all the updates in the first place so that they can be included in MDT. There are several ways to attack this job:

Install a base Windows XP machine and run Windows Update on it, then note down by hand all of the KB numbers that appear in the list. You need to be aware that some updates have dependencies on others, so they will not appear in the list until you have installed it's required update beforehand. This means that you will need to run Windows Update several times on the computer until no new updates are detected.
Then, go to www.microsoft.com and search for each KB article, follow the link to the page and download the file(s). This is a very slow and laborious task, especially if you have a lot of them to download.
Only install the service packs when they are released because they contain all previous updates. This will leave your computer image missing many critical updates for long periods of time because the intervals between service packs is so great, I would not recommend this approach. Also, what happens after the final service pack for Windows XP is released, will you not patch any further...?
Use the Windows Update task from the MDT task sequence. This task will automatically run Windows Update during the execution of the task sequence to ensure that your build is up-to-date. Unfortunately, it does not yet support proxy servers so sometimes is not a viable choice.
Update the operating system post-deployment via SMS or the Automatic Updates service. This is the simplest option, although it exposes your systems to unnecessary risk until they are fully patched.

All of the methods above will allow you to complete an operating system deployment containing all the latest updates; however as I mentioned above, they all have their drawbacks. The method I have always used is the first one, as it was the only sure way to have all the required updates, but the job is a slow and tedious one. A slightly faster way is to use the site http://catalog.update.microsoft.com to download the updates as this lets you create a 'shopping basket' and then download them all at once; which is a marginally quicker way to do it but it is still slow.

I recently completed a project to create a set of Windows XP images, and the client wanted the images to contain Service Pack 2 plus all current critical updates (Service Pack 3 was still in beta at the time). One of the first steps I took was to create the list of KB articles for the updates I would have to download (via the Windows Update method in the list above), and it came out at almost 200 KB articles! At the thought of a day's work ahead of me clicking around the Microsoft website, I decided to find out if there was an easier way to do this as I did not relish the thought of sitting at my computer to download each and every file manually.

After searching around, both internally at Microsoft and externally via live.com, it became clear that there is not a Microsoft solution to this problem. However, all was not lost because it seems that someone else had come across the same problem and created a solution for it. Windows Updates Downloader will allow you to download all updates since the last service pack for the system that you choose. As you can see from the image below, it currently lists Service Pack 3 and all the post-SP3 updates that have been released, which are not that many at the time of writing this post although the list is bound to grow somewhat in the future.

This tool has saved me hours of work and is now a permanent fixture in my array of deployment tools! Go find out more information about it here: http://wud.jcarle.com/. By the way, I must mention that this is not a Microsoft product and that I am not endorsing it in any way. All and any problems or issues related to it should be directed to the author, not Microsoft.

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

Dealing With Duplicate User Profile Links in Windows Vista

DeploymentGuys — Thu, 01 May 2008 16:24:00 GMT

Overview of Windows Vista User Profiles

In previous versions of Windows the user's profile was largely hidden away and only the more technically-minded of us would ever knowingly delve into its contents. With Windows Vista there seems to have been a significant change in that the profile has been dragged sulkily into the spotlight.

The Windows Vista user profile

The Windows Vista user profile is visible everywhere. It's the very first link in the Start Menu and it appears prominently in Explorer and most Open/Save dialogs. Some dialogs even open directly to this profile location and ignore any Favorite Links. Many people - including myself - initially tried to rebel against this new behaviour and attempted to hide the profile away again. This usually causes its own set of problems when a user who only understands Documents and Pictures suddenly gets a Save dialog with an eyeful of profile. They panic. They blindly click on the root of the C: drive and with brows furrowed in incomprehension they drag the entire contents to the Recycle Bin. Then they pull the power cord out.

Those are the good users. The rest call the helpdesk!

It's much better to embrace the new way of working and provide training around using the user profile to the end users.

Folder Redirection

Another change in Windows Vista is the ability to independently redirect each of the user profile sub-folders to a network location using Group Policy and Folder Redirection. This can significantly improve logon times in an organisation that uses roaming profiles where users move around lot. A common approach is to redirect the "big hitters" where large files are often stored, such as:

Documents (usually with the addition of Pictures, Music and Videos)
Desktop
Downloads

Let's have a look at our Windows Vista profile after we redirect these:

Duplicate infested profile - The Horror!

What's going on here?! What are all these duplicates? Which is the real one? If you thought users panicked when they hadn't seen a profile before then you haven't seen a user when presented with duplicate links! And no, a slightly different icon is never a good enough way to tell the difference. "No, don't save it in the one that looks like a folder, save it in the one that looks like a folder with a document on top of the folder". I think not.

So why does this happen? Well, when redirecting a folder using Group Policy one of the options is to "Move the contents". Unless this option is selected a duplicate link will be left behind - even when that folder is completely empty. The problem is that depending on the way the infrastructure is set up we can't always safely select this option.

Here are some common reasons you might not want to use the "move" option:

The user is often not the owner of the redirected folder. Many organisations pre-create redirected folders with administrator ownership to simplify administration. The Group Policy option to move the contents of the redirected folder fails when the user is not the owner.
Server moves and maintenance. Often administrators need to move the location of user data between folders or even servers. If the administrator changes the location of a redirected folder they generally want to move the corresponding files themselves at the same time. Using the Group Policy "move" option, if an administrator changed the redirected location for 10000 users they would need to wait for all 10000 users to logon for all of the data to be moved. Warning: Administrators tend to froth at the mouth a little when told this. You could attempt to change the Folder Redirection location and then move the files yourself anyway but this usually causes the Windows client to get confused, especially where Offline Files are involved.

If none of the above scenarios applies to you then you are very lucky indeed and can stop reading now. The rest can continue on for a possible workaround...

A Possible Workaround

So, to fix this we need to find a way to automatically remove these duplicate links, let's say on logon. The solution will need to:

Run on any Windows Vista build and not rely on any specific frameworks or runtime libraries which may not be present
Be able to check if folders have been redirected
Where a folder has been redirected, be able to work out what the duplicate/default location was
Check that the duplicate folder is indeed empty
Delete duplicates (or recycle them to be safer)

Usually I'd use VBScript for something like this, but in order to get the redirected and default profile folder locations we need to use the API call SHGetKnownFolderPath which means writing a custom application in Visual C++ 2008 Express (or the full version if you have it). What? Why don't I just use VBScript and read the registry keys in "Explorer\Shell Folders" and "Explorer\User Shell Folders"? Because Raymond says so, and because Technet says so.

Don't worry about using Visual C++ , it's going to be a tiny program that's pretty easy to follow for a scripter and you'll be able to act smug around the office and throw lines into conversations like: "VBScript, yeah, that's pretty good. I guess. <pause dramatically here> Check out my proper code and cast off your childish ways, mortals!".

The sample code will create a program that can be run as follows (from a login script, logoff script, StartUp group, RunOnce registry key - your choice):

RemoveDuplicateProfileLinks.exe [/norecycle]

By default, it will move deleted duplicates to the Recycle Bin (safe) but you can force a full deletion using the optional "/norecycle" switch (less safe).

Download the sample code here:

To compile:

Open Visual C++ 2008 Express.
Open the solution file "RemoveDuplicateProfileLinks.sln".
Ensure that the "Release" build is active.
Select the menu "Build \ Rebuild Solution".
The code will compile.
The resulting .exe file will be created in the top-level "Release" folder.

<disclaimer>Remember, this is sample code and you use it at your own risk :)</disclaimer>

A Quick Look at the Code

For the geeks among you let's have a quick look at the code. The main functions are in the "RemoveDuplicateProfileLinks.cpp" file and consist of:

wWinMain() and CheckFolder() - These do most of the work in reading command-line parameters, checking for redirection and deleting duplicates.
IsVistaOrLater() - Checks if we are running Windows Vista or later.
IsValidDir() - Checks if a given folder exists.
MyGetFullPathName() - Expands a given folder into it's non-relative and long path name version.
IsFolderEmpty() - Checks if a folder is empty and suitable for deletion. We have to be a little careful as duplicate profile links tend to still contain files like "desktop.ini" and junction points to "My Pictures" and the like. You can modify this function to suit your environment, but as it stands it should work well for a clean Windows Vista build that has just logged on and had a number of folders redirected.
FileRecycle() - Handles deletion or recycling of a folder.

The main two functions wWinMain() and CheckFolder() are shown below so you can see what you are getting yourself into:

The WinMain() function

The CheckFolder() function

That wasn't so hard was it? It's not rocket science after all - it's just brain surgery... Let me know how you get on with this and if you have any other ideas or suggestions.

This post was contributed by Jonathan Bennett a Senior Consultant with Microsoft Services, UK.