jump to navigation

Understanding USMT with MDT 2010 November 20, 2009

Posted by tmintner in MDT 2010, USMT, Windows 7.
Tags: , , , ,
21 comments

The User State Migration Tool (USMT) is an extremely powerful and essential piece of an Operating System Deployment.  With the release of the Windows AIK for Windows 7, USMT 4.0 was made available and includes many great new features such as hard-link migration (for more information on what’s new in USMT 4.0 see this article).  MDT 2010 integrates USMT directly into the task sequence for both Lite Touch Installations and Zero Touch Installations.  There have been several questions since MDT 2010 was released on how USMT works with MDT and how all of the pieces fit together. 

 

Lite Touch Installation

USMT 4.0

In order to user MDT 2010, you must install the Windows AIK for Windows 7.  The Windows AIK now includes USMT 4.0 as a feature of the AIK so there is no longer a separate download required for USMT.  When you create your Deployment Share inside of the Deployment Workbench, MDT will create a folder at the root of the deployment share called USMT and copy the USMT files into that folder. 

 

Refresh Scenario

A refresh scenario means that you are deploying an Operating System to a computer that already has an existing Operating System using a task sequence created with the Standard Client Task Sequence.  The process is started from within the current Operating System.  In a Refresh scenario, the disk is not formatted or partitioned so in most cases, the user data can be saved locally on disk saving time and network bandwidth.  During a Lite Touch Installation there are only two steps in the task sequence step that uses USMT.  The first step is called Capture User State and the second step is called Restore User State.  This step will run a script called ztiuserstate.wsf.  The actions that ztiuserstate will be performed are determined by the following factors:

  • The Operating System being deployed
  • The values provided in CustomSettings.ini for UserDataLocation and UDDIR and UDShare
  • The values provided in the Client Deployment Wizard used to start the Task Sequence

If ZTIUserState determines that you are deploying Windows XP it will not be able to use USMT 4.0 and will try to use USMT 3 for the user state migration (more on that later).  If you have specified that UserDataLocation = Network and you have also specified a UDDIR and UDShare in the customsettings.ini then USMT will migrate all of the files to a compressed file at the network location you specify.  Also if you provide a network location in the Client Deployment Wizard, USMT will migrate the user data to a compressed file at the network location you specify.  If UserDataLocation = AUTO and you are not deploying Windows XP, the ztiuserstate script will keep the data local in the MININT folder using hard-link migration.  There is no need to do an estimate because the hard-link migration process only requires 250 MB of space on the disk and if you didn’t have that much the process would fail in the validate step.

Replace Scenario

A Replace scenario is made up of two task sequences.  The first task sequence is based upon the Standard Client Replace template and the second task sequence is based on the Standard Client task sequence template.  The first task sequence is initiated from within the existing Operating System like in a Refresh scenario.  The USMT capture process in a Replace scenario works just like a Refresh scenario with one exception, in a Replace scenario the user data can not be stored locally so you must provide a network location to store the User Data.

The second task sequence is started by booting into the Lite Touch boot image and doing a New Computer deployment.  The Client Deployment Wizard will ask if you want to restore user state and where the user state is stored.  The Restore User State step in the task sequence would then use USMT to restore the user state to the computer being deployed.

 

USMT 3.01

So if USMT 4 has all these new cool features, why would you ever still want to use USMT 3?  Well USMT 4.0 cannot restore user data onto Windows XP.  Loadstate.exe from USMT 4.0 will not run on Windows XP.  So if you plan on migrating user data to Windows XP you will still need to use USMT 3.01.  To use USMT 3.01 you will need to download it from Microsoft.  The Deployment Workbench has direct links to both the 32 bit and 64 bit versions of USMT 3.01 in the Components section.  After downloading the installation files you will need to place those installations files in the Tools\X86 folder in your Deployment Share for 32 bit installs and Tools\X64 for 64 bit installs.

Refresh Scenario

In a Refresh scenario,the Lite Touch Installation process will be able to determine if the Operating System being deployed is Windows XP.  The same factors mentioned above are applicable for USMT 3.01.  If the Operating System is Windows XP, the ztiuserstate script will install USMT 3.01 on the computer and then do an estimate to determine how much user data is on the computer.  If the amount of user data is less than the amount of disk space needed then ztiuserstate will store the user data on the local disk in the MININT folder.  If there is not enough space then the user data will be stored in the UDSHARE and UDDIR locations.

Replace Scenario

A Replace scenario is a little trickier.  The Lite Touch Installation process won’t be able to automatically determine what Operating System you are going to be deploying because the Operating System is going to be deployed with a separate task sequence potentially even on a different computer.  In a Replace scenario ztiuserstate will use USMT 4.0 by default, however there is one problem with that.  User Data backed up with USMT 4 cannot be restored with USMT 3 and USMT 4 cannot be run on Windows XP!  So if you are replacing a Windows XP computer with another Windows XP computer, how can you make sure that USMT 3.01 is used?  To handle that scenario, MDT has a variable called USMT3.  To force the Replace scenario to use USMT 3 you would enter the following into your customsettings.ini:

USMT3 = YES

 

Zero Touch Installation (ConfigMgr/SCCM)

The USMT process with ZTI is slightly different than the process with Lite Touch.  The steps in a ZTI task sequence look like the following for capturing User State:

image

The MDT integrated task sequence uses the built in actions for Request State Store, Capture User State, Release State Store, and Restore User State.  The Ztiuserstate.wsf script is only used in one step: Determine Local or Remote User State. 

With ZTI, the version of USMT that is used is solely dependent on the USMT package that is associated with the Determine Local or Remote User State, Capture User State, and Restore User State steps in the task sequence.  You will need to create a package that contains the files for either USMT 3.01 or USMT 4.0.  Thankfully when you walk through the wizard to create the MDT task sequence in Configuration Manager, the MDT provided wizard will create the USMT 4.0 package for you automatically.  If you want to create a USMT 3.01 package you will need to download and install USMT 3.01 on a client computer and use the installation folder in the Program Files folder as the source directory for your package.

USMT 4.0

The version of USMT that you are using for your USMT package will determine what actions the Determine Local or Remote User State will perform.  If you are using USMT 4.0 then the Determine Local or Remote User State will set the variable needed to do a hard-link migration and also set a variable called USMTLOCAL =TRUE.  The Request State Store and Release State Store steps in the task sequence have a condition on them so that they will only run if USMTLOCAL is not true.  That means if you are using USMT 4, the user state will always be local and the State Migration Point will never be used.  If you would like to use the State Migration Point instead of using hard-link migration then just disable the Determine Local or Remote UserState step in the task sequence

USMT 3.01

If you are using USMT 3.01 then the Determine Local or Remote User State step will perform a USMT Estimate to determine if there is enough space locally on the disk to store the user data.  If there is enough space locally the variable USMTLOCAL is set to TRUE.  Again the Request and Release State Store steps are conditional on this variable so if there is not enough room locally the State Migration Point will be used

 

Summary

Whew..that is a lot of information.  As you can see, MDT tries to cover all of the scenarios with USMT whether you are using USMT 4.0 or still deploying Windows XP and need USMT 3.01.  Enjoy and happy deploying!

 

-Tim Mintner

Identify Driver Problems in MDT 2010 Litetouch (new tool) November 19, 2009

Posted by keithga in MDT 2010, VBscript.
comments closed

This tool is in response to a common question:

In my MDT 2010 Litetouch environment, how do I identify which hardware devices are not being installed with the correct drivers?

Introducing the “Yellow Bang” tool!

Yellow bang is a slang term used to describe drivers that have “problems” represented by a Yellow exclamation point ( ! ) in the Windows Device Manager:

image

Now typically, most IT professionals will be using SCCM, that can gather from each machine in the environment, and query computer status in a more structured way. This solution is only designed for IT departments that are using Litetouch only.

New Tool

Use this tool in MDT 2010 to identify all drivers that have problems on a client machine running MDT Litetouch. These are the drivers that have a Yellow Exclamation point (Bang) in the Windows Device Manager. Simply add this script to your …\scripts\ directory, and add the script to your task sequence.

For each driver that is not working properly the details are written to the bdd.log and the ZTIYellowBang.log file for later review.

Example Output

For this example, I have a HP Laptop that is missing a driver for the ACPI\HPQ0004 device, which is the “HP 3D DriveGuard”. <meh>

Microsoft Deployment Toolkit version: 5.0.1641.0
SUCCESS: 0: Create object: Set oScriptClass = New ZTIYellowBang  DRIVER_ERROR [28: Device drivers are not installed.]
DeviceID [ACPI\HPQ0004\3&33FD14CA&0]
HardwareID [ACPI\HPQ0004]
HardwareID [*HPQ0004]
CompatibleID []
ZTIYellowBang processing completed successfully.

Steps

Simply copy the ZTIYellowBang.wsf script to the Deployment Share under the …\scripts\ directory. Then add the ZTIYellowBang.wsf script as a Step to your Task Sequence:

Cscript.exe “%ScriptRoot%\ZTIYellowBang.wsf

Links

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/ZTIYellowBang.zip

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Installing Office 2010 Beta with MDT 2010 November 18, 2009

Posted by tmintner in MDT 2010, Office 2010.
Tags: , , ,
3 comments

The Office 2010 Beta went public late last night so you might be wondering how to deploy it with MDT 2010.  To do so you first need to extract the files from Microsoft with the command:

ProfessionalPlus.exe /extract:c:\extractedfolder

 

Now that you have extracted the files you can import Office 2010 directly into MDT 2010 as an application.  Go to the Applications node and choose a New Application, choose Application with Source Files and click on Next.  Enter in the Application Name information and click on Next.  For the source files choose the extracted folder you created earlier and click on Next.  Enter a name for the folder and click on Next.  For the command line just enter setup.exe and click on Next.  Click on Next on the summary screen and the Application will be created.

Now that you have Office 2010 imported as an application you can now go to the Properties of the Application you Created and you should see a new tab that looks like the following:

image

If you want to customize the installation you can choose to use the Office Customization Tool.  For example to set the product key for the installation you would navigate to Licensing and User Interface as shown below:

image

Just enter your product key and go to File, Save to save your changes.

Now you are ready to install Office 2010!

 

- Tim Mintner

How to add users to “Remote Desktop Users” Group November 18, 2009

Posted by keithga in MDT 2010, VBscript.
add a comment

Someone posted a question recently that I thought was intresting:

What is the correct way to use ZTIGroups.wsf, the Restore Groups MDT action, to populate local group membership of groups that have a space in the name?  As a test I’m trying to use CustomSettings.ini to add domain users/groups to the local Remote Desktop Users group.  I didn’t find a lot of detail in the MDT docs on doing anything other than Administrators or Power Users. 

I had done some work in ZTIGroups.wsf earlier this year. We added the ability to save the list of group names, and create the groups dynamically during restore time, in addition to the ability to add members to the group.

I had done testing with ZTIGroups.wsf, however I didn’t recall testing with the group “Remote Desktop Users” group. How did that work?

I tried running a command:

C:\>cscript ZTIGroups.wsf   /Groups1:"Remote Desktop Users"   "/Remote Desktop Users1:pickett\keith.garner"   /restore /Debug:True /DebugCapture

While looking at the output I noticed that the script was looking for a new property: “RemoteDesktopUsers”, where did that come from?

It turns out that the ZTIGroups.wsf script will look for members using the properly name derived from the name of the group being populated, *without* the spaces in the property name.

So running a deployment with the following properties in the customsettings.ini worked:

Groups001=Remote Desktop Users  RemoteDesktopUsers001=pickett\Keith.Garner

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

How to Know You are Using Scripts from MDT 2010 November 17, 2009

Posted by tmintner in Uncategorized.
add a comment

We’ve had a few emails over the last few weeks where certain variables or actions in the task sequence in MDT 2010 were either not functioning at all or were not behaving as expected.  After looking at the log files, it was pretty clear that a mixture of MDT 2008 boot images were being used with MDT 2010.  So how can you tell if you are using a MDT 2010 boot image?  The easiest way to tell is to look in the bdd.log file.  IN MDT 2010 we added a version line to each of the scripts that are run so if in the first 15 or so lines of the BDD.LOG you do not see this: Microsoft Deployment Toolkit version: 5.0.1641.0 , then your boot images are probably running scripts from MDT 2008.

 

To fix this you would, right click on the DeploymentShare and choose Update.  Then you would choose Completely regenerate the boot images as shown below:

image

 

Now that your boot images are updated you will either need to burn new CDs or re-import the boot images into WDS

 

- Tim Mintner

Solving an Intermittent Format Problem November 17, 2009

Posted by tmintner in MDT 2010, Troubleshooting.
Tags: , , ,
1 comment so far

I received and interesting email yesterday from someone who was performing Lite Touch deployments and it seemed that randomly his deployments would fail at the Format and Partition Disk step in the task sequence.  Examining his BDD.LOG showed this error:

FAILURE ( 7705 ): command: FORMAT.COM C: /FS:NTFS /V:OSDisk /Y /Q   FAILED with error = 4

The first step I had him do was reboot the computer and run through the steps that the script ztidiskpart runs manually.  Those steps are:

  1. Boot in Windows PE
  2. Press F8
  3. Run diskpart
  4. select disk 0
  5. clean
  6. create partition primary
  7. assign letter=c:
  8. active
  9. exit
  10. format c: /fs:ntfs /v:OSDisk /Y /Q

Again the format command failed.  He then immediately tried the format again and it worked.  So this was truly an intermittent problem.  My suspicions went up that this was driver related and had him check what kind of storage controller is in the laptop and it was the lovely Intel Matrix Storage Driver.  I checked Intel’s web site and had him download the new driver from here: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17882&lang=eng 

After removing the old Intel Matrix Driver from his Deployment Workbench, adding this one back in, and regenerating his boot images it worked!

It was a great lesson for both of us and now hopefully you won’t have to go through as many steps.  If you ever run into any intermittent format or partitioning problems start investigating the storage driver!

- Tim Mintner

New Tool: MDT 2010 Build-out/Hydration Evaluation November 13, 2009

Posted by keithga in MDT 2010, PowerShell, VBscript, Windows 7.
comments closed

I wanted to give a glimpse of some projects we are working here at Xtreme Consulting Services – Deployment Team.

This is a Microsoft Deployment Toolkit 2010 Build-out (sometimes called Hydration) system.

It starts off as a small 3MB *.zip file. The MDTBuildout.exe program will automatically download all required files (around 10GB of files), create a Virtual Machine running Windows Server 2008, and build out a functional MDT 2010 system. All the files downloaded are publicly avaiable over the internet.

This sample is *not* designed for production environments. The Server OS and Windows 7 Client OS’es downloaded are time-limited Evaluation versions of Microsoft OS’es, and not intended for production environments. If you would like to setup a functional system for your corporate environment, please let us know.

Xtreme Consulting Service’s Deployment Team is ready to assist you with your deployment needs.

Features

When complete, this Buildout (Hydration) system will create:

  • A Virtual Machine running Windows Server 2008 (R1) x86 Server Standard.
  • MDT 2010, with all dependencies installed (including WAIK).
    • OS’es: Server 2008 R1 x86, Windows 7 x86 and Windows 7 x64.
    • Microsoft Office 2007 Enterprise Evaluataion Version.
    • Applications: 7-zip, Foxit PDF Reader, MacroMedia player, Silverlight player, SQL Server 2008 Express, Sun Java Runtime, Video Lan Player, Windows Debugger (windbg).
    • Sample Driver package: Intel Chipset drivers.
    • Sample Packages: Windows 7 Language Packs, Hyper-V Drivers, Remote Server Administration Tools (RSAT)
  • A Windows 7 Media build DVD image with Office 2007.
  • It will also enable a PXE/WDS Service for servicing MDT 2010 WinPE Images (no Domain Controller required).
  • A blank Virtual Machine ready to perform a capture of Windows 7 back to the MDT 2010 server.

Requirements

  • Your machine must be running windows with a version of either Hyper-V (for Windows Server 2008) or Virtual PC 7 (for Windows 7).
  • Your machine must have at least 2GB of ram, and 60GB of free hard disk space.

Walkthrough

Download the MDTBuildout.zip file to your local machine and expand the contents to their own folder. You should see the manual: MDTBuildout.rtf and the Wizard Wrapper MDTBuildout.exe. Go ahead and launch the MDTBuildout.exe.

The MDTBuildout.exe wizard will guide you through the process of creating the virtual machine and downloading the necessary files to get it started. The wizard will create to Virtual Machines:

MDTVirtualServer – This is the Virtual Server that will host MDT 2010. It takes a couple of hours to setup, depending on the speed of your network connection.

image

MDTVirtualClient – This Virtual Machine will be used later on to capture a reference image of Windows 7 with Office 2007.

image

It is recommended that you use the default settings during the MDTBuildout.exe wizard, although, you can override the settings if required. Be sure to give the Virtual Machines enough memory, place the *.VHD files on a disk with 40+GB of space free, and select the Virtual Networking adapter with internet access.

When you select “Build” the wizard will begin the process of downloading the Windows Server 2008 Eval *.iso file to the local machine, this file is about 1.8GB. When done, the wizard will automatically create the virtual machines with the required parameters, and start the process. You can continue to watch the progress in the VM window.

The entire build process can take several hours depending on the speed of your network connection. Let the install run. When complete, you should see a dialog showing the status.

The password for the MDT Server is: P@ssword

When complete, you can start the MDT 2010 Workbench (start –> Microsoft Deployment Toolkit –> Deployment Workbench), and view the components added to the system.

image

The deployment share should be at: c:\deploymentshare

The media share should be at: c:\media

If you wish, you can start the PXE server, to allow other computers on the network to boot into MDT 2010, this is a great way to upgrade machines on your corporate network in a “self-service” fashion. To enable the pxe server, run the command “net start wdsserver”. WARNING: The PXE/WDS Server running on the Virtual Machine *will* conflict with other PXE/WDS servers on the network. Please ensure that you are the *only* PXE/WDS server on the network before starting! This is why the WDS service is disabled by default.

You can also burn the contents of the Win7 Media ISO to a DVD drive. Or perhaps copy the *.iso file to the local machine.

Use this server to evaluate MDT 2010 and try deploying Windows 7 (Evaluation Version), to your test lab.

When ready, you can boot the MDTVirtualClient Virtual Machine, using either the Win7 Media ISO image, or PXE/WDS. The Client Virtual Machine has been specially configured to auto install Windows 7 and upload the captured image back to the MDT 2010 Server in a completely hands off fashion.

More documentation, walkthroughs, and videos to follow.

Link

<Edit> No longer available.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

The Case of the Disappearing Task Sequences November 13, 2009

Posted by tmintner in MDT 2010, VBscript.
Tags: , , ,
17 comments

We’ve gotten quite a few emails on this so I figured it was time to put this on the blog. :)   The problem that most people run into is that sometimes when they go through the Lite Touch Client Deployment Wizard, the task sequence list is empty.  So what causes the task sequence list to be empty?  The simple answer is if the DeployRoot cannot be found or is incorrect.  The DeployRoot is the location of the DeploymentShare or content of the MDT Media Point. 

 

Here is the basic process that should help troubleshoot the problem:

· Windows PE boots up and runs litetouch.wsf

· Litetouch.wsf calls ztigather /inifile:bootstrap.ini and the DeployRoot value is read from the bootstrap.ini

· Litetouch.wsf then makes a call to connect to the DeployRoot using the wizard credentials or the credentials in the bootrap.ini

· Litetouch.wsf then calls ztigather and reads the values from the customsettings.ini (note if a full Media Deployment is inserted in the DVD or USB drive the customsettings.ini will be read from that location instead of the DeployRoot)

· If the DeployRoot value has changed In the customsettings.ini, the value is updated and Litetouch.wsf tries to connect to the DeployRoot

· The wizard is started and the tasksequences.xml file is read from the DeployRoot

· If the DeployRoot does not contain a valid tasksequences.xml then a blank Task Sequence wizard is displayed

 

Steps to troubleshoot:

· Open BDD.Log

· Search for the value DeployRoot and do a Find Next to make sure that all values in the log file for DeployRoot are the same.  If they are not then there is some setting either in CustomSettings.ini, the database, or on local media that is changing the value

Validation: Passing the MDT 2008 Certification Exam November 12, 2009

Posted by keithga in Uncategorized.
add a comment

Took the Microsoft Deployment Toolkit 2008 Certification exam today.

I passed!!!

I’ve been an in-depth Microsoft technical guy for 14 years now, yet I’ve never gotten around to actually taking any Certification test before.

And I figured that since I was on the Dev team for MDT 2008, I’d start with 070-635 (Microsoft Deployment Toolkit 2008, Desktop Deployment). I took the test cold, no studying.

It was kind of weird going back and taking the test for MDT 2008. There have been two product releases since then, MDT 2008 Update 1 and MDT 2010. And I’ve been working on Windows 7/MDT 2010 components now for about a full year.

I’d take some more exams, but I had to pay for this one out of my own pocket. Perhaps in the new year.

Tim Mintner mentioned once that he took this test as well. Which wasn’t really fair, since he helped write the questions. :^)

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

How to delete files that won’t delete November 11, 2009

Posted by keithga in MDT 2010, Troubleshooting, Uncategorized.
add a comment

One of the frustrations when working with beta software is dealing with constant changes and little support for cross-build (not major version) upgrading.

During the development cycle for MDT 2010, one component that had constant change was the Windows Automated Installation Kit. MDT requires several components from the WAIK to perform correctly, so we were constantly upgrading.

One of the components, the WIMGAPI.dll was particularly nasty. The WAIK installer would set the permissions on the file so regular users could not delete it, and the intra-build upgrades didn’t replace the file automatically. Luckily, if you are using the final released (RTM) version of the WAIK, and upgrading from a previously released version, you should be OK.

Why are these files so hard to delete?

Windows protects some installed files by giving only the “Trusted Installer” account access to the file, and explicitly denying everyone else access, including administrators and the SYSTEM account.

Running the icacls.exe command on wimgapi.dll reveals:

NT SERVICE\TrustedInstaller:(F)
BUILTIN\Administrators:(RX)
NT AUTHORITY\SYSTEM:(RX)
BUILTIN\Users:(RX)

The problem is that normal users and administrators don’t have full access to the file and are not allowed to modify the permissions.

How to Modify “Trusted Installer” files

If you ever find yourself in the situation where you need to modify/delete files that are “trusted installer” protected, here is what I do:

  1. Start up an elevated command prompt (with administrator privileges).
  2. Run “icacls.exe <file>” to see the current permissions.
  3. Run “TakeOwn.exe /f <file>” to change ownership.
  4. Run “icacls.exe <file> /reset” to change permissions.
  5. Run “icacls.exe <file>” to display the new permissions.

Example:

icacls 

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group