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.

One of the questions I received after presenting a session at TechEd Europe was about encoding any clear-text passwords that you might place into the Bootstrap.ini file, so that if someone looked at the file they wouldn’t be able to tell what value it represented.  I suggested that it would be fairly simple to write a script that would take an encoded value, decode it, and save the decoded value to the “real” task sequence variable.  That evening, a script was written and a blog post started.

As the MDT scripts already provide everything needed to do this, the resulting scripts are pretty simple, with more comments than lines of code.  For the already-typed up scripts, see the attachment below. 

First, let’s talk about the approach.  We need to have encoded values that we can decode.  It’s easy enough to save those encoded values in task sequence variables, set via CustomSettings.ini or Bootstrap.ini.  So imagine something like this:

[Settings]
Priority=Decode, Default
Properties=EncodedUserPassword

[Decode]
EncodedUserPassword=SGVsbG8=

There’s not much to that:  I have declared a new variable called EncodedUserPassword, and set the value of that variable to “SGVsbG8=”, which is the base64-encoded equivalent of the string “Hello”.

The next step then is to decode that encoded value.  The simplest way of doing this is to use a user exit script.  The logic for that needs to do the following:

• Look for a list of “encoded” variable names.  Because MDT already has the concept of “sensitive” variables (passwords, product keys, etc.), we can use that same list of variables as a starting point (although you could obviously add your own list).  To build the name of the “encoded” variable, we just prepend the word “Encode” to the variable as an easy-to-remember (and easy-to-script) convention.
• For each “encoded” variable name, see if we can find a value for it.  If so, we’ll decode it and store it in the non-encoded variable.  For example, we would take “EncodedUserPassword”, if not blank, and store it in “UserPassword”.

The basic logic:

For each sVar in Array("USERID", "USERPASSWORD", "USERDOMAIN", "DOMAINADMIN", "DOMAINADMINPASSWORD", "DOMAINADMINDOMAIN", _
     "ADMINPASSWORD", "BDEPIN", "TPMOWNERPASSWORD", "ADDSUSERNAME", "ADDSPASSWORD", _
     "SAFEMODEADMINPASSWORD", "USERNAME", "USERPASSWORD", "PRODUCTKEY")

    ' If the encoded value exists, decode it and save it to the proper task sequence variable

    If oEnvironment.Item("Encoded" & sVar) <> "" then
        oLogging.CreateEntry "Decoding variable Encoded" & sVar & " for assignment to " & sVar, LogTypeInfo
        oEnvironment.Item(sVar) = oStrings.Base64Decode(oEnvironment.Item("Encoded" & sVar))
    End if
Next

(Don’t try to copy and paste this, as it’s not complete and it doesn’t wrap nicely in the blog posting.  Use the already typed-up version attached below.)  The only real “magic” in this code is to use the “oStrings.Base64Decode” function, which already exists in MDT’s ZTIUtility.vbs script (as MDT actually stores these variables base64-encoded – if you think about that, you realize that we’re taking an encoded value, decoding it, then telling MDT to save it back again encoded.  Kind of silly, yes, but it does mean you won’t ever see the value in clear text.)

To use this user exit script in CustomSettings.ini, you need to copy the “DecodeExit.vbs” script into your deployment share’s “Scripts” folder, then add a reference to it in CustomSettings.ini:

[Settings]
Priority=Decode, Default
Properties=EncodedUserPassword

[Decode]
EncodedUserPassword=SGVsbG8=
UserExit=DecodeExit.vbs

OK, great, you’re all set to go now right?  Well, not really.  Look again at my example:  It’s setting the “UserPassword” variable.  That’s the password used to make a connection to the deployment share.  It really wouldn’t do any good to set that one in CustomSettings.ini.  Instead, it needs to be set in Bootstrap.ini.  Simple enough, right?  Just copy and paste the same lines into Bootstrap.ini.  Well, almost, as there is one additional challenge:  You have to get MDT to include the user exit script in the boot image, so that it’s available when the boot image is generated.  There are two ways that you could do that:

• Create a folder somewhere that is accessible via a UNC path, e.g. \\SERVER\ExtraFiles$.  Inside of that folder, create a “Deploy” folder, and inside that, a “Scripts” folder.  Place a copy of DecodeExit.vbs in that “Scripts” folder.  Then update the deployment share properties to specify that UNC path for the “Extra directory to add” path.
• Find the “LiteTouchPE.xml” file that defines what files MDT adds into the boot image.  Edit the file to add a new entry for DecodeExit.vbs that looks something like this:

<Copy source="%DEPLOYROOT%\Scripts\DecodeExit.vbs" dest="Deploy\Scripts\DecodeExit.vbs" />

Either approach will work.  After you make either change, you’ll need to update the deployment share to generate new boot images (then import those to WDS, generate new boot CDs, etc.).  The advantage of the first is that it will survive MDT upgrades.  The advantage of the second is that it’s easier to do and will detect script changes (e.g. if you modify the script to include more variables and then want to update the boot image again).

So how do you come up with the encoded value in the first place?  Well, if you search the internet, you’ll find lots of “base64 encoder” web pages, so you can always do that.  Or you can use the second script that I’ve attached, Encode.wsf, which leverages the matching “oStrings.Base64Encode” function from ZTIUtility.vbs.  You would run the script like so:

cscript.exe Encode.wsf /Value:”Hello"

It will display the resulting encoded value on the console, so you can then copy-and-paste into CustomSettings.ini or Bootstrap.ini.

As usual, even the simplest setup requires a lot of explanation…

I mentioned a while back that I wanted to do a blog post talking about how to troubleshoot the new MDT 2012 monitoring feature for Lite Touch deployments, but first I had to actually describe it.  If you haven’t reviewed that post, you might want to check it out first at http://blogs.technet.com/b/mniehaus/archive/2012/03/09/mdt-2012-new-feature-monitoring.aspx.

So now let’s talk about troubleshooting.  First, let’s look at the server side.  You have to enable monitoring on a computer that has MDT 2012 installed.  When you use Deployment Workbench on that computer and check the box to enable monitoring, Workbench will first check to see if the specified monitoring host name is local:

It doesn’t really matter if you specify an IP address, a short host name, or a fully-qualified host name, as long as the clients can resolve whatever you specify.  If you specify a name that Workbench doesn’t think is local (because Workbench itself can’t resolve the name back to an IP address assigned to the current machine), it won’t try to install the monitoring component; instead, it will try to contact that server to see if monitoring is running on that computer.  If it is, great; if it isn’t, you’ll see an error message:

If you look closely at the error “tip” at the end of the “Monitoring host” line, you’ll see a message like “Unable to connect to the specified server and port”.  If you think you specified the local computer name and got that error, then Workbench couldn’t figure out that it was the local computer name (something that’s harder to do than you might think).  If you are specifying a different server and see this error, then it’s having problems communicating with that other server.

Tip #1:  Make sure the name you specify in Workbench can be resolved to the IP address of the current machine.

What does the checkbox do?

You’ve checked the checkbox and can’t see that anything happened.  So what was actually done?  Two things:

1. A new “Microsoft Deployment Toolkit Monitor Service” service was installed on the computer and started.
2. An additional entry was added to the [Default] section of CustomSettings.ini telling the clients how to contact the server, with an entry such as:
   
   EventService=http://mdt-server.mdt.local:9800

Tip #2:  Make sure the “Microsoft Deployment Toolkit Monitor Service” is installed and running.  If it’s not installed and it should be, you can uncheck the box, click apply, then check the box again and click apply to reinstall it.  If it’s installed but not running, try to start it.

Tip #3:  Make sure the entry was added to CustomSettings.ini by looking at the Rules tab.  Because of a peculiarity with the way Workbench works, if you make any changes to the Rules tab after you’ve clicked the “Enable monitoring” checkbox but before you’ve clicked OK, it’s possible that the changes made on the Rules tab overlay the EventService entry in CustomSettings.ini, but it’s easy enough to put it back manually.

What if the service doesn’t start?

The service has two dependencies:

1. .NET 3.5 SP1 needs to be installed.  That shouldn’t be an issue, because you can’t install MDT 2012 without .NET 3.5 SP1.
2. The ports you specified need to be available for use.  (Generally that’s not an issue either, as 9800 and 9801 aren’t commonly-used TCP ports.  But it is possible to have another application use them.  Fortunately, MDT will happily use other ports.)

So there’s no dependency on IIS or SQL Server.  The service uses .NET to host a web server as part of the service process, and it uses a SQL Compact database (basically a set of DLLs, which ship with MDT, that run in the service process) to store the monitoring information.  It’s designed to be easy to install and run.

Tip #4:  If you try to start the service and it won’t start, that most likely means the ports you chose were already in use.  (If you want to know what’s using the ports, use a tool like TCPView, available from http://technet.microsoft.com/en-us/sysinternals/bb897437.)  Pick different ports.

While it’s always possible that there could be some other reason the service fails, I haven’t seen any other causes.  But if you know the ports are not in use and the service still won’t start, capture a trace using DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647) to see if it provides any further clues.  If not, contact Microsoft Support for assistance.

Verifying the Monitoring Service

The monitoring service listens on the two ports that you specified.  The first of these ports (9800) is used by computers being deployed to send progress events.  The second (9801) is used by Workbench itself to query information about deployments being monitored.  To make sure these ports are accessible, we can manually connect to each one using Internet Explorer.

To verify the “event port” from the monitor server itself, you can use a URL such as:

http://localhost:9800/MDTMonitorEvent/

If that works, you should see a response like:

That’s a proper response in this case – the web service doesn’t expect to be called in this way (an HTTP GET request instead of an HTTP POST request), so it’s telling you the proper way to call the service.

To verify the “data port” from the monitor server itself, you can use a URL such as:

http://localhost:9801/MDTMonitorData/

This response (which is an ODATA feed in case you are curious) confirms that the data feed is working as expected.

But those are the easy queries – they are using “localhost”, which is almost never subject to firewall restrictions.  Next, you need to try these queries remotely, using the appropriate “remote” URLs:

http://mdt-server:9800/MDTMonitorEvent/

http://mdt-server:9801/MDTMonitorData/

If those work, great.  If they don’t, then you need to make sure that whatever firewall is running on the monitoring server allows the ports you specified (e.g. 9800 and 9801) to be accessed from remote hosts.

Tip #5:  Make sure you can access the monitor service ports both locally and remotely.  Adjust the firewall rules as necessary.

Note that there are other networking “challenges” that can get in the way, e.g. IPSec domain isolation.  In this configuration, computers that aren’t domain-joined, e.g. running from Windows PE, can’t talk to domain-joined computers because they aren’t using encrypted IPsec communication.  This type of configuration will never work – you would need to set up the monitoring service on a “boundary server” that has been configured to allow non-IPsec traffic on the configured ports.  So don’t assume that if a “remote” URL works from a domain-joined machine, it will also work from a workgroup machine (or Windows PE) – know how your network is configured.

From the Client Side

When the EventService task sequence variable is set (via the processing of CustomSettings.ini), each MDT script executed in the task sequence will send an event to the monitor service on the “event port” URL.  When this succeeds, you’ll see a message like this:

If a script is unable to send an event, you’ll see something different:

That’s a clear sign that something isn’t right.  Make sure the service is running, that the firewall ports are open, etc. – the same challenges we already reviewed.

Tip #6:  Check the client logs to make sure the clients are able to talk to the monitoring service.

Another way you might notice an issue:  If the monitor service isn’t running, the clients will still try to connect to it, eventually timing out.  This timeout process will cause a delay at the end of each step in the task sequence, so if you are watching the task sequence progress dialog, you’ll see steps that you never noticed before (because they usually run so fast) now taking a long time.

From Workbench

When you try to look at the monitoring data from Workbench, it calls a PowerShell cmdlet (Get-MDTMonitorData), then that PowerShell cmdlet makes the “data port” query to retrieve the details from the monitoring service.  If the service is working as expected, you can see the list of monitored machines in Workbench.  If the service isn’t working, you’ll see something like this instead:

Good advice, make sure the service is running

Finally

Still having issues?  Post them as comments here, or send me an e-mail at mniehaus@microsoft.com and we’ll try to figure out what’s going on.