MDT 2012 Update 1: Dealing with in-use files when capturing user state

A thread on the MDTOSD mailing list hosted by https://www.myitforum.com website was talking about how some user state data, such as PST files that Outlook has opened, could be lost during the user state migration process.  This reminded me of some new functionality coming in MDT 2012 Update 1 Beta 1.  Yes, that hasn’t released yet, but it’s worth discussing now anyway because users of MDT 2010 and MDT 2012 can benefit from some of the same changes.

Handling in-use files: config XML adjustments

First, let’s talk about the USMT Scanstate program and what it does for in-use files.  By default, it considers these to be fatal errors.  That’s generally problematic, as there are a variety of in-use files that are part of Windows that you don’t really care about, and you certainly don’t want the deployment process to stop because of those.  So since, well, forever, we have specified to continue on those types of errors.  On the positive side, state capture works.  On the negative side, you might miss real data files.

In MDT 2010 and MDT 2012, we added a new USMT config file in Lite Touch deployments and when capturing offline data in ConfigMgr (UDI scenarios) that specifies what to do with certain types of errors, whether they should be considered fatal or whether the deployment process should continue.  (We don’t specify this config file for ZTI deployments at this point, but we’ll look at ways to do this in the future.)

In the MDT 2010 and MDT 2012 version of this USMT config file, called ZTIUserState_config.xml, we specify the following error control parameters based on the example provided in the USMT documentation (not the complete file):

<?xml version="1.0" encoding="UTF-8"?>
< Configuration>
  <Policies>
    < ErrorControl>
      < fileError>
        <nonFatal errorCode="32">* [*]</nonFatal>
         <fatal errorCode="any">C:\Users\* [*]</fatal>
      </fileError>
      < registryError>
        < nonFatal errorCode="5">* [*]</nonFatal>
      </registryError>
    </ErrorControl>
  </Policies>
…

This error control logic says any error 32’s (“File in use”) should be considered an error if the file is in the C:\Users folder, but not anywhere else on the disk.  OK, so what’s wrong with that?  A few things:

• If you are migrating from Windows XP, the folder name would be different than C:\Users.
• With Outlook PST files, you could get an error 33 (“portion of the file is locked”) instead of an error 32.
• If we are using hardlinks, the fact that the file is in use doesn’t really matter – we can tell USMT to create a hardlink anyway.

So we’ve changed this logic in MDT 2012 Update 1 to be as follows:

<?xml version="1.0" encoding="UTF-8"?>
< Configuration>
  <Policies>
    < ErrorControl>
      < fileError>
        <nonFatal errorCode="32">* [*]</nonFatal>
        < nonFatal errorCode="33">* [*]</nonFatal>
        <fatal errorCode="any">%PROFILESFOLDER%\* [*]</fatal>
      </fileError>
      < registryError>
        < nonFatal errorCode="5">* [*]</nonFatal>
      </registryError>
    </ErrorControl>
    <HardLinkStoreControl>
      < fileLocked>
        < createHardLink>%PROFILESFOLDER%\* [*]</createHardLink>
      </fileLocked>
    </HardLinkStoreControl>
  </Policies>
…

So now we treat error 32 and 33 the same, use an environment variable for the profile folder instead of C:\Users, and most importantly, tell USMT to create the hardlink anyway if the file is locked, for any file in any user profile.  That should help some with this, although maybe want to tweak this further based on your specific needs.  Why might this be necessary?  Let’s look at the example errors posted on the MDTOSD thread:

2012-06-27 08:52:17, Info                  [0x080000] Error 32 attempting to create a hardlink to C:\UnsecureData\Outlook\Wayne's Duplicate Files.pst
2012-06-27 08:52:17, Error                 [0x000000] Read error 33 for C:\UnsecureData\Outlook [Wayne's Duplicate Files.pst]. Windows error 33 description: The process cannot access the file because another process has locked a portion of the file.[gle=0x00000021]

Would either of these worked with the default ZTIUserState_Config.xml file from MDT 2012 Update 1?  No, because the files aren’t within the user profile folder.  It might make sense to modify the file to instead specify something like:

<createHardLink>C:\* [*]</createHardLink>

Yes, that’s using a hard-coded path, but since I’m writing this on a plane (making the long trip back from TechEd Europe 2012 in Amsterdam) it’s hard to test out ways to dynamically specify the volume that would work online and offline.  Just take note that this is less than desirable, especially when using offline migration when that path might not be the right one (when drive letters shift around in Windows PE).  But you get the idea at least.

Handling in-use files: offline user state capture

That’s only part of the USMT changes made in MDT 2012 Update 1.  We’ve also added the ability to capture user state offline for Lite Touch and ZTI scenarios.  We used offline migration by default for UDI deployments, but for a variety of reasons didn’t extend that capability to the other scenarios.  Now we have.  It’s not the default in some of the scenarios, so you as a “deployment administrator” need to make that choice.  Fortunately, that’s easy to do: just set task sequence variable USMTOfflineMigration to “TRUE” via CustomSettings.ini and we’ll do an offline capture instead of an online one.

The advantage of doing offline migrations should be apparent:  It’s not possible for any files to be in use because the OS isn’t running.  That doesn’t mean that it’s a perfect scenario, since some things are harder offline (e.g. user or domain remapping, user filtering) and some settings may not be migrated offline.  So read up on the offline migration limitations in the USMT documentation before deciding to do this.

There are a few scenario clarifications that should be made to, which are easiest to explain with a table:

So the highlighted text above shows the new scenarios that MDT 2012 Update 1 supports.  As you might be able to infer from the first row about LTI new computer deployments, there is a new feature there too.  When you boot into Windows PE (from media, via PXE, etc.) and we see that there is an existing and accessible OS on the drive, we will present a new wizard pane to ask if the user state should be captured from that OS – automatically using offline hardlink migration and skipping the steps to reformat and partition the disk (as that would destroy the data).  Here’s what the wizard pane looks like:

It’s worth pointing out at the same time that there are some scenarios where we can’t migrate the user data, and we will do our best to identify those (when possible).  For example, you can’t use USMT to migrate from x64 to x86, nor can you migrate to an older version of the OS (e.g. from Windows 8 to Windows 7).  And you can’t migrate data from a BitLocker-encrypted volume when you boot directly into Windows PE, as we have no simple way to unlock the volume for deployments that don’t start from within the full OS.  So in those scenarios, you’ll see the “Do not move user data and settings” option chosen by default.

It’s also worth pointing out that these new offline user state migration scenarios (for ZTI and LTI) require creating new task sequences, as there are new steps added to the task sequence to support this.

Summary

Isn’t deployment fun? 

This is just one of the new features in MDT 2012 Update 1 – more on that over the coming weeks.  If you haven’t yet signed up on https://connect.Microsoft.com, please do so now and we’ll e-mail you when the beta is ready.  Look for the Microsoft Deployment program under the Solution Accelerators connection.