Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.

Building A Windows XP Reference Image, Typical Customizations Examples

Nick Moseley has a nice post on some typical XP customizations that are done to your reference XP Image.  He has some examples of system settings, user settings, and some unattend.txt settings as well. 

Read his full post here.


Uninstalling iSeries Legacy Client Access

If you have legacy iSeries Windows Client Access and need to do an upgrade to the latest 6.1 version, it can be a little challenging to get the old version uninstalled.  Here is a script that will take care of the uninstall, credit goes to a former colleague of mine for creating this. This has worked with versions 5.4 and 5.2.

Begin Script


@echo off

if exist "C:\Program Files\IBM\Client Access\cwbunins.exe" goto legacy

exit 0



echo Uninstalling old versions.

"C:\Program Files\IBM\Client Access\cwbunins.exe" /s

reg.exe delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /v "CA RmDir" /f

rmdir /s /q "C:\Program Files\IBM\Client Access\Mri2924"

exit 0



End Script


Kicking It Old School – Deploying WinXP using USMT3 with ConfigMgr without using the SMP

The information provided in this post is “as-is”, use at your own risk and please be sure to test appropriately!

This method has been superseded by a much easier method with MDT 2010 Update 1.  Read this post here for the new method.

Mention the SMP to any ConfigMgr OSD guy and he/she will probably give you a dirty look.  The most common frustration is when replacing hardware and doing a replace scenario.  Most of us have no desire to sit down and create hundreds or thousands of computer associations.  We look back to SMS 2003 and think, man that worked slick, why can i just do it like we used to?  Well you can without too much trouble actually. 

For our environment, we wanted to run USMT in a XP to XP scenario just like we used to.  Capture the user data to a network location, then restore from that network location.  If we were doing a hardware refresh, then we would run a pre-capture to the network location, then when the new machine is named the same as the old one, the user data would come back down onto that machine from the network share.  Hence Kicking It Old School.  Modifying a few scripts and some task sequence steps gave us the intended result we wanted.

The components needed for this are:

Modified MDT Toolkit Package, XP Settings Package (cs.ini), and a modified Task Sequence

MDT Toolkit

The first thing we’ll need is a new Toolkit package since we will want to modify a few of the MDT scripts, it’s preferable to just make a new package and then copy in the updated scripts attached to this post, that way you aren’t effecting you toolkit files for all other TS’s in case you wanted to do something different.

I would recommend naming it “MDT 2010 Toolkit Files – USMT3” or something so you know that it’s a modified package for USMT3. 

The scripts modified are ztiuserstate.wsf and ztiutility.wsf.  ZTIUserState.wsf is modified to force USMT3 to always use the network, and ZTIUtility.wsf has some modifications for connection to UNC’s and creating the necessary folders when they don’t exist.  Thanks to Michael Niehaus for the help on that script. 

Put the scripts attached to this post in your \scripts folder and either replace the existing ztiuserstate.wsf and ztiutility.wsf or just rename them to “script.old”.

XP Settings Package

Next we’ll need a settings package for the TS.  We will want to set the following items in customsettings.ini under the [Default] section.  You can modify the Args to what you would like to run.

ScanStateArgs=/v:7 /o /c /uel:30 /targetXP /ui:domain\*
LoadStateArgs=/v:7 /c /uel:30 
USMTMigFiles4=custom.xml (if needed)

The other items you’ll want to set via the DB or cs.ini is the UDDir and UDShare properties.  I do this via the DB so it’s set correctly for all the locations.  If you want to do it in your cs.ini via locations, you can do that as well.  Just remember to set the values in some way. 

UDDir=%OSDComputerName%, and UDShare=\\server\share

Task Sequence

Next we’ll need to modify our TS with the steps we want to run.

First we’ll want to delete or disable some steps in the default TS, your choice.

In the State Capture phase, we want to disable the following steps:


In the State Restore Phase, we want to disable the following steps:


Next we’ll want to add a custom run command line step under State Capture:


Use the following command line, and make sure to select your USMT3 package:

“cscript.exe “%SCRIPTROOT%\ZTIUserState.wsf” /capture”


Next, we’ll add a custom run command line step under State Restore:


Use the following command line, and make sure to select your USMT3 package:

“cscript.exe “%SCRIPTROOT%\ZTIUserState.wsf” /restore”


Next, you’ll to make sure your TS is using your modified Toolkit package and Settings package.


Make sure to change all your appropriate “Use Toolkit Package” steps:


That should be all, be sure to test, hopefully you will find that you can capture/restore data from a network location and that your replace scenarios hopefully are a little easier to work with.


Script Files Download Here


Configuration Manager 2007 R2/SP2 Driver Management

The post will cover the most common methods that I know of for driver management in ConfigMgr.  For once I won’t be talking about MDT integration!

Auto-Apply Drivers

Auto-Apply consists of importing all your drivers into ConfigMgr and then utilizing the “Auto-Apply Drivers” step in a Task Sequence, this step will match PNP ids and inject the drivers that match the detected ID’s.  You can limit selections by utilizing “Categories” or you can simply just let it have free reign on your driver database.  The only step i’ve had to work with on this TS step is the “Install only the best matched compatible drivers” vs “Install all compatible drivers.”  I had a few models that wouldn’t install all drivers unless I used “Install all compatible drivers.”  The biggest problem with this method is that it will grab the newest compatible driver, so if you just imported the latest greatest for a new model you have, many of those drivers will work for older models and will be used for those models even if you don’t want them to be.


1) Quick, easy

2) Don’t have to know what specific drivers you need, provided there is a matching driver, your device will be installed correctly, that works great for some people

3) Matches drivers based upon PNP


1) Sub-devices can be missed sometimes

2) No control over what drivers are being put where, you have some control with “Categories”, but not the degree of control some people like, it will grab the newest/greatest driver it can find that matches your device

3) Matches drivers based upon PNP 🙂

Step in the TS this method focus’s around:


Other main focus points you will want to be concerned with:


Using Driver Packages

This is commonly known as the “control freak” method.  When using this method you typically want to control the specific drivers going to each model.  Usually this is driven by a Task Sequence step with a WMI query to match up the Model.  The major issue with this is that ConfigMgr won’t let you import duplicate drivers, and if you are using common manufactures, 50-80% of your drivers could be same for every model.  So what you end up doing is creating driver packages in ConfigMgr, but not actually importing the drivers, you instead put the in the driver package source files and then distribute those to the Distribution Points, thus allowing you full control over what drivers are in the package.  This leads to a bit more maintenance since you have to work with the drivers from a folder perspective and you mostly maintain them outside of ConfigMgr.  You would still import NIC and Mass Storage drivers (for XP) as you would need those imported ideally to inject them into your boot images, although you could inject them into the wim yourself if you really wanted to.  This method works great when you have to be concerned with certain versions of drivers going to certain models, a great example for us is we need our video drivers to be Certified by Solidworks, to get support, we need to ensure the machines are using a correct Certified driver.  The problem with the new unified drivers is that the newest version that i need for my new laptop also happens to work for my 2 year old workstation class machine, however that newest driver isn’t Solidworks Certified.  Again the theme of this method is control.

This is the method i have personally used up to this point, I now use the 3rd method which i’ll talk about in a bit. 


1) Complete control over what is going where

2) Control! x2

3) Injects all drivers in that package, anything in that package is available to the OS


1) Can’t easily import duplicate drivers

2) More administrative overheard

3) Not typically managing most of the drivers from with ConfigMgr

4) You will have the same drivers in multiple packages, taking up more space, possible concern for some


Hybrid of Auto-Apply and Driver Packages

After reading this post by Keith Garner, I got to thinking about how I could do something similar in ConfigMgr.  When i really sat down to think about it, the only drivers that really mattered to us was controlling the video drivers.  So I decided, why couldn’t i do PNP for everything but the video drivers.  Even more on that, unless it’s a machine running Solidworks, i really don’t care what video drivers are installed.  So I basically ended up with this structure:

-Common Drivers (Will use PNP)

-Common Video Drivers (Will use PNP)

-Specific Video Drivers (one package for each model requiring a specific video driver)

I imported all my common drivers into ConfigMgr, imported all my video drivers, then seperated them out into common drivers and the specific drivers.  I then created all the driver packages i needed for each model that required a specific video driver and added the required driver to the package.  I made use of “Categories” to control what was being used for PNP detection.


1) Advantages of PNP detection along with the control over drivers by using driver packages when needed


2) Takes a little configuration and setup

The first section in my Driver Management part of my Task Sequence is for Windows XP Mass Storage drivers, I do a WMI query for the deviceID and then inject the appropriate MSD, this allows me to not have MSD in my other packages and I can have a single driver package for all MSD’s and then just inject when appropriate. 




Next, I do a Auto Apply driver step that injects all my Common Drivers, I have these all under a Category called “Common”, this would be audio, modem, card readers, anything that isn’t a video/display device.



Next I have a section for Video Drivers, the driver(s) I want to control in my case.  First we inject any Common Video Drivers for models I don’t care about. Just get the best video driver available installed for me.



This is driven by a WMI Model query on the backend for all the models I don’t care about, notice I use “LIKE” statements to get around HP’s funky part #’s:


Next we get into the specific models that I want to inject specific video drivers:


Here we are using a Driver Package for each TS step with a WMI query on the backend, this Driver Package contains the Certified driver that I need for that model:



That’s it! That is how i now manage my drivers, I feel this to be the most effective method for our environment.

Hope this helps or inspires someone else.



Scheduling A Weekly Defrag Through SMS/ConfigMgr

Without any third party tools here is a simple way to create a weekly defrag task on your client workstations.  This is specific for Windows XP, although you could create something similar for Vista or Windows 7.

We went to create a new Package called “Schedule Weekly Defrag”


The data source can be set empty:


Then we want to create a new program called “Schedule Defrag Task”

This is your command line, this one will run every Sunday at 8 AM and defrag the C drive:

schtasks.exe /create /sc weekly /d SUN /tn defrag /tr "c:\windows\system32\defrag.exe c: -f" /st 08:00:00 /sd 01/20/2007 /ru "system"

Notice we set the start path, and make sure to set it to run hidden:


For the Environment, we want admin context and we will need a drive letter for the command to execute:


It’s also my preference to hide notifications, since this is administrative task:


Here we can see the task has been created on a client machine:


If we look at the actual task, we can see the properties are set correctly:

image image


ConfigMgr USMT Migration Bug

Known bug that has been talked about on the lists quite a bit.  Looks like the SCCM team blog posted something on it finally:



Custom Front End – Name and OU prompt – ConfigMgr/MDT 2010/Pre-execution hook

This information is provided as-is… proceed at your own risk…

Provided with MDT 2010 SCCM integration is a pre-execution hook that allows for a computer name prompt prior to execution of the task sequence.  This works great for bare metal installs and avoids the MININT% name.  An additional property i wanted to define for bare metal builds was to provide a selection screen where the user can select the target organizational unit (ou) in Active Directory.  What i also wanted was validation on the OU prompt so that the user couldn’t go to the next screen without first selecting an OU.  It took me awhile to figure out the variable i needed for the OU validation, so thanks to Hector for that. (I don’t claim to be a scripting expert, never have… ) 🙂

Here is the computer name promt:


Here is the OU prompt: (blocking out our OU’s)


You’ll need the MDT wizard editor found here:


First thing you need to do is make sure that you have a boot image that was created with MDT and you opted to check the pre-execution hook check box.


The files for the pre execution hook are stored here once you’ve installed MDT 2010:

C:\Program Files\Microsoft Deployment Toolkit\SCCM

You will want to work with the Deploy_SCCM_Definition_ENU.xml file.  I would NOT recommend modifying the one included with MDT.

In my case, i made a copy of the xml and the vbs script to a c:\custom\mdt_custom\ folder  i had created. That is where i worked with the files.  Wherever you run the wizardeditor from and wherever the xml you are working with is, it will put the necessary files in that folder, so don’t run this from your desktop or you’ll see a bunch of new files pop up on your desktop!

I used the same file name so i didn’t have to modify my tsconfig.ini in the boot image, but if you want to use a different file name you can.  Just make sure to change the ZTImediahook.wsf to call the appropriate file.  It’s simple enough to just use the same name and call it a day.

Once you open this file with the wizard editor you will see this:



We need to add a new pane called “machineobjectou”

Then create a validation step, and set the value to MachineObjectOU.Value <> “”



Without going into great detail, MachineObjectOU is the task sequence variable you want set for the target OU.  By setting this variable we are controlling the OU the computer will end up in.

Next you need to create some HTML code and figure out how you want it to display.  You can use the preview pane to see how your changes will work.

Here is the basic HTML code i use:


<H1>Select the Organizational Unit<H1>
<span style=”width: 95%;”>
<p>Select Organizational Unit the computer will be added to</p>
<select id=OUlist size=16 language=VBScript onchange=”MachineObjectOU.Value = OUlist.value” class=wideedit>

<option value=”ou=something,dc=something,dc=com” >OU Display Name</option>
<label class=ErrMsg for=OUList>* Required (MISSING)</label>
<input type=hidden Name=MachineObjectOU />


Which gives you this look:



Next, you will want to click on Wizard – Test


This will let you test the wizard and logic to make sure it acts as expected.

You will be prompted with a list of variables you can set, then you can click run and run the wizard, after going through the wizard panes, you will provided with a list of variables and you should see your new variables listed on the bottom of the list:

First variable list:


Second variable list after running the wizard and you can see the new variables populated:


Now that you’ve hopefully verified your changes work and the wizard runs as expected, we need to get those changes into your boot image.  You need to mount your boot.wim and replace the existing \deploy\scripts files with your modified ones.  Then commit your changes and unmount the .wim.  Then you need to update your distribution points and recreate your task sequence media. That’s the short version at least 🙂 I’m assuming you already know how to mount an image and inject files.




Windows XP – Sysprep – Default profile settings

If you want your administrator profile on the reference image to apply as the default profile for all users, you will need to set the “UpdateServerProfileDirectory” command in your sysprep file before you capture the image.  Microsoft has changed this a back and forth between the various service pack releases. 


Here is a link from the Deployment Guys with some more information:

Specific to WinXP SP3:


Here is some information from the Microsoft KB:

How to customize the default local user profile in Windows XP or in Windows Server 2003

In Windows XP and in Windows Server 2003, updates that you have installed may change the method that you use to customize the default local user profile. For more information, see the following sections.

Windows XP Service Pack 2 (SP2)

The default behavior is to automatically copy customizations from the administrator profile to the default user profile. Therefore, no additional steps are required to customize the profile.

Windows Server 2003 Service Pack 1 (SP1) or Windows Server 2003 SP2

The default behavior is to automatically copy customizations from the administrator profile to the default user profile. Therefore, no additional steps are required to customize the profile. You can disable this functionality by setting a parameter in the Sysprep.inf file. This parameter prevents the Minisetup process from copying customizations from the administrator profile. To do this, set the parameter in the “UNATTENDED” section of the Sysprep.inf file as follows:

Windows XP Service Pack 3 (SP3) or hofix 887816 is applied

Hotfix 887816 disables the automatic copying of customizations. Therefore, you must configure a parameter in the Sysprep.inf file to enable the Minisetup process to copy the customizations from the administrator profile. To do this, set the parameter in the “UNATTENDED” section, as follows:


Note Windows XP SP3 includes hotfix 887816.


Process Monitoring Tools

Someone on the myitforum list mentioned this tool (YAPM) so i decided to check it out.  It’s pretty neat and feature packed.

Here is the link to site:

Here is a shot of it in action:


Someone also mentioned PolyMon:


Pretty neat tools, check them out!



SMS 2003 OSD from RIS/WDS

The information provided below is provided “as-is”.  Proceed at your own risk.

Initial Configuration Steps

I will not go into detail on these and will assume you have already completed these steps.

1) Install and configure RIS/WDS

2) Authorize server in DHCP and configure scope options

3) Configure Group Policy options –

a. Automatic setup is for flat files

b. Tools/Troubleshooting for RAMdisk

4) Your Windows PE version is 2005 based upon Server 2003 SP1 media


Deploy Windows PE from a RIS server by using a RAM disk

1. On the RIS server, locate the \RemoteInstall\Setup\Language\Images folder.

2. Create a subfolder for Windows PE. For example, type the following at a command prompt:

drive:\Cd \RemoteInstall\Setup\English\Images md winpe

Note In this step, drive is the placeholder of the hard disk drive on which RIS is installed. Language is the language of the Windows PE image.

3. Create a subfolder in the \Windows PE folder that is named Platform, where platform is i386 or amd64. For example, type the following command at the command prompt: md winpe\i386

4. Copy the customized Windows PE .iso image file that you created earlier to the Windows PE\Platform folder, where platform is i386 or amd64. For example, type the following command at the command prompt:

copy drive:\Work\Winpex86.iso drive 1:\RemoteInstall\Setup\English\Images\Winpe\i386

Note drive is the placeholder of the hard disk that contains the Windows PE image. Also, drive 1 is a placeholder for the hard disk partition on which RIS is installed.

5. Create a subfolder in the \Windows PE\Platform folder that is named Templates. For example, type the following command at the command prompt:

md winpe\i386\templates

6. Locate the Platform folder of the Windows PE image, and then copy and to the Windows PE\Platform\Templates folder. For example, type the following commands at the command prompt:

drive:\ cd \winpe\i386 copy
drive 1:\RemoteInstall\Setup\English\Images\winpe\i386\templates copy
drive 1:\RemoteInstall\Setup\English\Images\winpe\i386\templates

Note In this step, drive is the placeholder of the hard disk that contains the Windows PE image and drive 1 is a placeholder for the hard disk partition on which RIS is installed.

7. Copy the \Platform\Setupldr.exe (not Setupldr.bin) file from the Windows PE image to the \Windows PE\platform\templates folder, and then rename Setupldr.exe to Ntldr. For example, run the following command at the command prompt:

copy setupldr.exe drive 1:\RemoteInstall\Setup\English\Images\winpe\i386\templates\ntldr

Note In this step, drive 1 is a placeholder for the hard disk partition on which RIS is installed.

8. Create a text file that is named Winnt.sif in the \Windows PE\Platform\Templates folder by using the following text.


BootDevice = "ramdisk(0)"

BootPath = "\platform\System32\"

OsLoadOptions = "/noguiboot /fastdetect /minint /rdexportascd /rdpath=%INSTALLPATH%\%MACHINETYPE%\<bootimage>"

Architecture = "platform"


Repartition = No


Description = "brief description"

Help = "longer description"

LaunchFile = "%INSTALLPATH%\%MACHINETYPE%\templates\"

ImageType = Flat

Version = "5.2 (0)"


9. Start a RIS client, and then select the operating system image that you created.


Notes from Microsoft:

· RAM disk method supports only x86 and x64-based Windows PE ISO images. For Itanium (IA-64)-based Windows PE ISO images use Method 2.

· You can put the i386 and amd64 folders within the same folder on a RIS server. For example, you can create the following folder structure:

\RemoteInstall\Setup\English\Images\Winpe\i386 \RemoteInstall\Setup\English\Images\Winpe\Amd64

· You can give the Winnt.sif file any name that you want as long as the file name extension is .sif.

· The "Repartition = No" entry in the Winnt.sif file avoids a warning from the Client Installation Wizard (OSChooser) about the disk being erased.

· The text for the "Description" and "Help" entries can be any information that you want to include.

· The "LaunchFile" and "ImageType" entries must not change.

Restart the client, and then go into PXE startup. After you log on, select the Maintenance and Troubleshooting option in the Main menu. "Windows PE in RAMDisk," or whatever other description exists in the .sif file, appears as an option. Select this option, and then press ENTER.


Copying ISO

Copy SMS 2003 OSD ISO image to \RemoteInstall\Setup\English\Images\WinPE2005_OSD\i386

Sample winnt.sif


BootDevice = "ramdisk(0)"

BootPath = "\i386\System32\"

OsLoadOptions = "/noguiboot /fastdetect /minint /rdexportascd /rdpath=%INSTALLPATH%\%MACHINETYPE%\osd_image_install_mdt.iso"

Architecture = "i386"


Repartition = No


Description = "WinPE 2005 OSD Disk"

Help = "Windows PE 2005 OSD Disk"

LaunchFile = "%INSTALLPATH%\%MACHINETYPE%\templates\"

ImageType = WinPE

Version = "5.2 (0)"