MDT 2010 USB Media for XP to Win7 REFRESH (fully automated)

To start an MDT 2010 LiteTouch Deployment REFRESH from USB Key follow these steps.

In this example my deployment server is DEVMDT2010. The deployment share is DeployWin7$.

1. In MDT 2010 create a Selection Profile under Advanced Configuration called USBRefresh. Assign the proper Applications, OS, Drivers, Packages, Task Sequence, etc.

2. Create New Media called USBRefresh under Advanced Configuration.

3. On DEVMDT2010, configure the Bootstrap.ini and Customsettings.ini files on the deployment share so the deployment is completely automated.






Priority=Default, DeploymentType, ByDesktopType, ByLaptopType





TimeZoneName=Pacific Standard Time


4. Update Media Content on USBRefresh and copy the Content folder to a USB key.

5. Create a new shortcut on the root of the USB key called LiteTouch Refresh. Point the target location to:  D:\Content\Deploy\Scripts\LiteTouch.vbs

6. Insert the USB key into a Windows XP Client and copy the LiteTouch Refresh script to the desktop. Double-click on it and deploy Windows 7 via REFRESH.

MDT 2010 and USTMT 4.0 Hard Link Migration

One of the most exciting features for deploying a Windows XP client to Windows 7,sits around the ability to create a hardlink during a REFRESH scenario with MDT 2010.

In order to leverage USMT 4.0 in MDT 2010, you must first install the latest Windows Automated Installation Kit for Windows 7.

For more information on the Windows Automated Installation Kit, go here:

Jeremy Chapman has an excellent video demonstrating how this works:

What I really like about hardlinks it doesn’t migrate the user’s data out to the Network, meaning faster deployment times. So, instead of moving files to a protected location on the hard disk, the files aren’t transferred at all, just the paths to them are updated. This is a very cool feature that Microsoft has to offer us to help us facilitate our migration efforts from Windows XP to Windows 7.

This means the install and settings transfer happens much faster, because the files aren’t transferred at all, just the paths to them are updated.  It’s really cool, and means you can have a fresh install of Win7, with all your XP files and settings, completed in short amount of time. Of course, you still need to install the OS. But still…very cool…

So, how do I get USMT hardlinks to work in MDT Lite Touch Installation Environment? When you install MDT 2010 and create your Deployment Share, MDT will create a folder called USMT and copy the necessary USMT files into that folder. If you refresh the machine (by starting Litetouch.vbs from the running OS), MDT 2010 by default uses hardlinks.

I suggest the following read on USMT with MDT 2010 by Tim Minter.

Additionally, MDT 2010 Documentation:

Windows 7 Deployment Useful Tip # 1 – Creating Read-only partitions during deployment with MDT 2010

Depending on your organization’s security policy, you may have the need to make a partition read-only. I have been working on a solution for the last 4 weeks to implement Windows RE into the build process with MDT 2010. Because of security requirements, this drives needs to be marked as read-only.

In MDT 2010 Task Sequence, you can do this by configuring two command lines during State Restore.

Task Sequence steps were created to run CACLS command line to make R: drive Read-Only for “Authenticated Users”.


cacls R: /E /R “Authenticated Users”

No Task Sequences are available in MDT 2010

You may have run into the issue where you boot into WinPE and get the very common “No Task Sequences are available (TaskSEquences.XML does not exist, is empy or inaccessible.” I ran into this for the very first time after upgrading from MDT 2008 Update 1 to MDT 2010.

You then go and validate that the TaskSequences.XML in the control folder of your deploymentshare has data in it and is not corrupt. I noticed that when I canceled out of the deployment wizard, deleted the MININT directory with the following command: rd C:\MININT /q/s – and restart the litetouch.wsf, I do not get the same error. I can then select my Task Sequences as expected.

A tip to debug this issue is to add the /debugcapture when you start the litetouch.wsf script.You can edit the Windows PE Unattend.XML and add the /debugcapture after the litetouch.wsf in the RunSynchronous section. The value on the right side states to run wscript.exe x:\deploy\scripts\litetouch.wsf, just add /debugcapture to the end of it. After making this change you will need to regenerate your boot image with MDT 2010. Then start the process by booting and view the log file when you are done. This might give you some additional information in the BDD.log

Often the issue involves the DeployRoot value isn’t quite correct. Tim Minter does an excellent job discussing this on his blog:

BitLocker Deployment and Window 7 SKUs

I, like many others, build my reference image with a virtual machine. Building your reference image with a VM is the way to go and will give you fewer problems when you go to re-deploy your newly captured WIM. However, at times it can also be extremely frustrating going through the process of running your build and capture Task Sequence and then having it bomb on you when the client reboots into WinPE to capture the image. The most common cause is with network latency and resource issues. You might then find yourself in the scenario where you manually capture your WIM.

The problem you might run into is when you go to deploy your image. Despite the fact that you have the configuration setup in the CustomSettings.ini appropriately, you notice the BitLocker screen was skipped in the deployment wizard.

If you analyze the BDD.log you might  realize that when you captured the Image manually with ImageX, you did not append flags onto it with the SKU of the image (Enterprise). If you’re capturing the image manually you can do that after the fact like this:

imagex /flags “EDITIONID” /info Install.wim 1 “NEW_IMAGE_NAME” “NEW_IMAGE_DESCRIPTION”

Where “EDITIONID” is the appropriate SKU ID as defined in the original factory image (or listed in the WAIK)

The reason why the screen was skipped was because MDT checks the flags value in the wizard to make sure we are only showing the bitlocker screen if you are running Enterprise or Ultimate since Bitlocker is only available on those SKUS.

“Multiple Connections to a server or shared resource by the same user, using more than one user name, are not allowed” with MDT 2010

After upgrading to MDT 2010 from MDT 2008 Update 1, I noticed a common theme at some of my remote offices. The UserDataLocation variable specifies the location of where data is to be stored during the migration process of the deployment. This variable is processed with the ZTIGather.wsf script tha queries the deployment rules and the MDT DB. Even though the technician might not restore user data – they’re going to get errors like what you see below:

Example: UserDataLocation=\\servername\usmt4\migdata\

So during the deployment wizard it would auto-complete the above location. Then all the tech would have to do is type %computername%.  In this scenario if the tech chooses not to restore user data, he gets the error seen in this screen shot:

I discussed this with one of the Lead MDT Developers in October and have posted the details of the error and the fix below.

The error encountered in the ZTIUserState.log and BDD.log, “Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again..”

A change has been made in MDT 2010 to deal with mappings to lower-level directories, which has caused some issues when the lowest level part of the path doesn’t exist. MDT attempts to map it, but that fails because the folder doesn’t exist, and is not able to create the folder because were not mapped. While this doesn’t cause the deployment to fail, it leaves you with some nasty errors in the logs and you might see this in the Summary Screen:

To fix the problem the ZTIUtility.vbs file needs to be edited in the scripts folder. Open the file and replace the following code in the MapNetworkDriveEX function:

Case Else

‘ Case &h800704C3 ‘ Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.

‘ Case &h8007052E ‘ Logon failure: unknown user name or bad password.

‘ There was a some kind of fatal error.

If ErrDesc <> “” then

MapNetworkDriveEx = ErrDesc


MapNetworkDriveEx = “Unable to map UNC Path ” & sShare & ” :” & “( 0x” & hex(HasError) & ” ) ”

End if

oLogging.CreateEntry MapNetworkDriveEx & “”, iLogType

Exit function

End select

With this code:

Case Else


On Error Resume Next

oNetwork.MapNetworkDrive  chr(sDrive)&”:”, sShare, False

HasError = err.number

ErrDesc = err.Description

On Error Goto 0

If Err.Number <> 0 Then

‘ There was a some kind of fatal error.

If ErrDesc <> “” then

MapNetworkDriveEx = ErrDesc


MapNetworkDriveEx = “Unable to map UNC Path ” & sShare & ” :” & “( 0x” & hex(HasError) & ” ) ”

End if

oLogging.CreateEntry MapNetworkDriveEx & “”, iLogType

Exit function


Exit Function

End If

End select