July, 2012

If you have installed MDT 2012 Update 1 Beta 1, you might have noticed a new wizard page in the MSI installer:

When enabled, this option enables us to collect more information about how MDT is being used, which we can leverage to improve MDT in the future.  No personally-identifiable data is collected; you can read through the full details in our privacy statement that has been posted to TechNet at http://go.microsoft.com/fwlink/?LinkID=255311.

In beta releases, we are allowed to have this set to “Yes” by default, although you can choose not to join during the installation process if you wish.  In the final release, “I don’t want to” will be the default.  Please help us out and change it back to “Yes” so we can get as much information as possible about how MDT is being used.

Another new feature in MDT 2012 Update 1 is the ability to call System Center 2012 Orchestrator runbooks from within a task sequence.  This works with Lite Touch deployments, ConfigMgr 2007, and ConfigMgr 2012.  Using this capability, you can tie external processes into your task sequences, without needing to employ developers to create web services or stored procedures.  So this is yet another option for making your deployments more dynamic.

Unlike the setup in place for web services and stored procedures, the Orchestrator support is not tied to CustomSettings.ini.  Instead, it is designed to run at any point in the task sequence itself by adding a new “Execute Orchestrator Runbook” requests wherever you want them:

In each of those steps, you specify the name of the Orchestrator server, then browse for an available runbook:

If that runbook accepts input parameters, you can pass those from the task sequence either explicitly (type in the value you want, using variable substitution if necessary) or implicitly (if the runbook parameter name matches the name of a task sequence variable, the value of that variable will be passed automatically).

You can also specify to wait for the runbook to complete before allowing the task sequence to continue.  That makes the process synchronous, and also provides a way for the runbook to return values back to the task sequence:  Any return parameters from the runbook execution job will be set as task sequence variables so that subsequent task sequence steps can use those values.

You can include as many of these “Execute Orchestrator Runbook” steps in the task sequence as you would like, but keep in mind the potential time this may add to the deployment process, as well as the load it may place on your Orchestrator server if you deploy hundreds of thousands of machines at the same time.

The default MDT task sequences won’t contain any “Execute Orchestrator Runbook” steps, so this is provided entirely for customization.  Be creative  

Some ideas for runbooks that you might want to try:

• Moving a computer to a new OU.
• Generating or retrieving a computer name.
• E-mailing when a deployment fails.
• Creating a trouble ticket/service request when a deployment fails.

One of these days I’ll get around to blogging about some samples…

In MDT 2012, we added support for DaRT integration into an MDT Lite Touch boot image, as well as a new monitoring feature that integrated with DaRT to make remote control into Windows PE easy.  See http://blogs.technet.com/b/mniehaus/archive/2011/11/28/mdt-2012-new-feature-dart-integration.aspx and http://blogs.technet.com/b/mniehaus/archive/2012/07/27/mdt-2012-update-1-dart-8-support.aspx for more information.

In MDT 2012 Update 1, we now can use the MDT monitoring feature with ConfigMgr deployments, which also means we can simplify the process of using DaRT remote control with ConfigMgr.  DaRT isn’t required to enable monitoring, but without it obviously you won’t have the DaRT remote control integration.

Here are the steps that you need to go through to implement this:

1. In Deployment Workbench, create a deployment share (if you don’t already have one), then in the properties enable monitoring:
   
   The ConfigMgr clients will eventually talk to this monitoring service, and you can see their progress by looking at the “Monitoring” node.
2. (OPTIONAL)  Get the necessary DaRT files where MDT can find them.  If using DaRT 7, copy the appropriate “tools.cab” files into C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\<Platform>.  If using DaRT 8, copy the “toolsx86.cab” or “toolsx64.cab” to the correct place. 
3. (OPTIONAL)  Create a new boot image using one of the MDT wizards integrated into the ConfigMgr console (to create just a boot image or to create a new task sequence with a new boot image).  On the “optional components” wizard screen, select “DaRT” from the bottom of the list:
   
4. Modify the CustomSettings.ini in the Settings package to add a new line to tell the clients to report status to the monitoring service:
   EventService=http://server:9800
5. Deploy.

There are some limitations with this implementation worth pointing out:

• The monitoring service will only see status reports from the MDT steps in the ConfigMgr task sequence.  For the built-in ConfigMgr steps (e.g. “Apply Operating System”), there won’t be any updates.  So as a result, the percent complete will bounce around a bit and the current step won’t be 100% accurate.
• The monitoring implementation hasn’t been tested with huge numbers of clients being deployed at once.  If there are any errors (due to timeouts, full databases, etc.) it won’t affect the deployment process, but pay attention to the BDD.LOG to see if you are running into any errors.

Since we released MDT 2012 Update 1 Beta 1 a few weeks ago, I’ve received a few panicked e-mail messages from people asking “what happened to the UDI task sequence, it’s gone.”  Don’t worry, it’s still there.  What we have done in MDT 2012 Update 1 is merge the ZTI and UDI task sequence together into a single task sequence.  There are a couple of reasons for doing this:

• You can dynamically choose whether or not to display the UDI wizard.  This gives you the same capability as you have with Lite Touch, and in fact uses the same variable, SkipWizard.  So if you specify SkipWizard=YES, it’s a ZTI deployment; if you specify SkipWizard=NO, it’s a UDI deployment.
• You don’t have to choose what functionality you want.  By merging the task sequence templates, we get the best capabilities of both.  That means that ZTI deployments now can do offline user state migration just like UDI deployments can.  It also means that we display the same background progress display in ZTI deployments as you are used to seeing in UDI.

Longer term, I am hopeful that we can stop making any distinctions between ZTI and UDI: they are just slight variations on the same ConfigMgr client OS deployment scenario.  Those same variations exist in Lite Touch as well, but that doesn’t mean “Lite Touch with a wizard” and “Lite Touch without a wizard” are two separate scenarios.

From an implementation perspective, we wanted to make sure that we gave you a simple way of choosing a default for SkipWizard.  This is done as part of the “Create MDT Task Sequence” wizard.  After choosing the “Client Task Sequence” template, you will see a new wizard pane:

The choice that you make ends up configuring a specific step in the resulting task sequence:

So if you want to dynamically choose “wizard or not”, you can remove this step and instead set the value through CustomSettings.ini.

See my previous posting at http://blogs.technet.com/b/mniehaus/archive/2012/07/01/mdt-2012-update-1-dealing-with-in-use-files-when-capturing-user-state.aspx for details on how to leverage offline user state captures for ZTI deployments.

In MDT 2012 RTW that released back in April, we included support for DaRT 7, making it easy to add the DaRT components to Lite Touch boot images.  See http://blogs.technet.com/b/mniehaus/archive/2011/11/28/mdt-2012-new-feature-dart-integration.aspx for more details on that.

With MDT 2012 Update 1 Beta 1, we added support for DaRT 8 Beta, while leaving support for DaRT 7 too.  So if you are using Windows AIK, you would use DaRT 7; when you are using Windows ADK, you would use DaRT 8.  (In general, DaRT releases are OS-specific, so DaRT 8 is for Windows 8 and DaRT 7 is for Windows 7.)

The basic functionality with DaRT 8 is the same as with DaRT 7: we add all the tools to the boot image, and we automatically run the remote agent so that you can make remote connections into Windows PE using the remote viewer (which is integrated into the MDT monitoring solution).  Additional functionality in MDT 2012 Update 1:

• We can automatically locate the DaRT 8 files when DaRT 8 is installed on Windows 8 and copy the files to the right place.  (DaRT 8 can only be installed on Windows 8.  If you aren’t using Windows 8, then you would still need to get the CAB files manually.  But at least you can get both CAB files at once, as the MSI contains both “toolsx86.cab” and “toolsx64.cab”.  Drop those into the tools folder on the deployment share and you’re set.  See the MDT documentation for more details.)
• We have additional integration with ConfigMgr.  We can add the DaRT 8 (or DaRT 7) files when creating a boot image (although you might need to copy the CAB files into C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Tools, as mentioned in the previous blog referenced above).  Also, the “Use Toolkit Package” step will automatically start the DaRT remote agent when it finds it in the boot image.

See http://windowsteamblog.com/windows/b/springboard/archive/2012/03/28/microsoft-dart-8-beta-q-amp-a.aspx for more information on DaRT 8.

The MDT 2012 Update 1 release is primarily intended to add support for deploying Windows 8 and Windows Server 2012.  For ConfigMgr 2012, it’s the SP1 release that adds similar support.  So if you want to start testing out the Windows 8 deployment process, you’ll want to be using MDT 2012 Update 1 (beta at this point, release version in the coming weeks) with ConfigMgr 2012 SP1 CTP.  See John Vintzel’s posting at http://blogs.technet.com/b/inside_osd/archive/2012/07/20/sp1-setup-changes-system-center-2012-configuration-manager.aspx that talks about some of the changes in ConfigMgr 2012 SP1 related to OSD.

The specific changes that we made in the MDT 2012 Update 1 task sequence templates to support the new functionality in ConfigMgr 2012 SP1 are:

• New steps for formatting and partitioning UEFI disks.  ConfigMgr 2012 SP1 CTP now supports UEFI deployment, which brings some specific requirements around the disk structure: you must use GPT disks, you should create four partitions, etc.  So we’ve added UEFI-specific steps to the MDT task sequence templates that will automatically run when booting into UEFI, creating the necessary structure.  These are executed conditionally, based on whether UEFI is present or not.
• BitLocker pre-provisioning.  We’ve added a step that uses the new ConfigMgr “Pre-Provision BitLocker” task sequence action to enable BitLocker while still in Windows PE, telling Windows to only encrypt used space.  This greatly improves the time required to completely deploy a new OS with BitLocker enabled – now the disk can be encrypted while empty (only encrypting used space, but there is little at that point in the process) and then protectors (TPM, PIN, etc.) can be added later.
• Installation of Windows 8 applications (“Metro” apps) via UDI and the application catalog web service.  (More on that in a future blog posting.)

So try out the combination of MDT 2012 Update 1 Beta 1 (available on http://connect.microsoft.com), ConfigMgr 2012 SP1 CTP (available from http://www.microsoft.com/en-us/download/details.aspx?id=30133), and Windows 8 Release Preview (http://windows.microsoft.com/en-US/windows-8/release-preview) today.

In MDT 2012 RTW, we supported PowerShell 2.0 in a task sequence, which worked well for what was released at the time.  But with Windows 8, Windows Server 2012, and Windows PE 4.0 (the version in the Windows 8 ADK), PowerShell 3.0 is now used.  MDT 2012 RTW didn’t support that. 

With MDT 2012 Update 1, we’ve added support for PowerShell 3.0, so now you can use the “Run PowerShell Script” in Windows 8 and Windows Server 2012, as well as within Windows PE 4.0.  And once Windows Management Framework 3.0 is released, we’ll also support PowerShell 3.0 on Windows 7 and Windows Server 2008 R2.

From a functionality perspective, you won’t see any difference in MDT 2012 Update 1 between PowerShell 2.0 and 3.0.  Of course there are features in PowerShell 3.0 that aren’t present in 2.0, but MDT’s support is identical for both releases.

If you haven’t yet tried out the MDT 2012 “Run PowerShell Script” task sequence action, try it with this single-line script:

dir tsenv: | out-host

Save that into a file, e.g. DumpVar.ps1, in the scripts folder on your deployment share (or if using ConfigMgr, in the scripts folder of the MDT toolkit files package) and specify in the “Run PowerShell Script” to execute the script name, e.g. DumpVar.ps1.  What you’ll find in the BDD.LOG after this script runs is a listing of all the task sequence variables defined at that point in the task sequence.

Another change you might notice in MDT 2012 Update 1 is that Lite Touch deployments never use SETUP.EXE.  That doesn’t result in any real change in functionality, as we still do the equivalent steps:

• Applying the image using ImageX.exe.
• Servicing the image using DISM, which injects drivers, software updates, language packs, etc.
• Creating a BCD entry to boot the operating system using BCDBoot.exe.

So then the question becomes “why”.  Well, there are a few reasons:

• Running Windows 7’s SETUP.EXE doesn’t quite work when using Windows PE 4.0 from the Windows 8 Assessment and Deployment Kit (ADK).
• Some complex multiple disk scenarios (more common on servers) could result in errors during installation; similar errors don’t happen when using ImageX.
• It’s no longer necessary to use SETUP.EXE.  With Windows Vista and its INSTALL.WIM, you couldn’t apply the WIM directly because the drive letter of the image (D:) was different from the drive letter of the machine (C:).
• It’s a little faster

So does that mean you never need to import full operating system files?  Not quite.  They are still needed in these situations:

• When installing Windows XP or Windows Server 2003 from source files.
• When installing Windows Vista or Window Server 2008 from the original source files (using INSTALL.WIM), because of the drive letter change issue described above.
• When adding the .NET 3.5 feature to a Windows 8 or Windows Server 2012 installation (more on that in a later blog).

In MDT 2012, we used SETUP.EXE as the primary installation method, but would fall back to ImageX if SETUP.EXE wasn’t available.  Now with MDT 2012 Update 1, the default is to use ImageX.

p.s.  ConfigMgr 2012 SP1 will also prefer using image packages instead of install packages for the same basic reasons.

A thread on the MDTOSD mailing list hosted by http://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 http://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.