This update resolves the following issues in Microsoft System Center 2012 R2 Configuration Manager.

Issue 1

After you enable the PXE Service Point role on an instance of a specific distribution point, or you select the Deploy this boot image from the PXE-enabled distribution point property of a boot image, the Windows Deployment Service (WDS) stops running. Additionally, entries that resemble the following are logged in the Windows Application log:

Issue 2

When operating system image files are downloaded to Configuration Manager 2012 R2 clients, you may find that the download takes longer than it did in previous versions of Configuration Manager 2012 clients. You may see this behavior when the target client is running Windows PE or a full Windows operating system.

Installation information

This update applies to Central Administration sites, primary sites, administrator consoles, and clients. Applying this update to a site server will let you create client update packages. After the update is installed on site servers, any operating system boot images should be updated. To update boot images after the hotfix is applied, follow these steps:

In the Configuration Manager console, click Software Library.

In the Software Library workspace, expand Operating Systems, and then click Boot Images.

Select the boot image that you want to update.

Right-click and then select the Update Distribution Points action. Note This action updates all distribution points and may have an adverse effect on an environment that contains many distribution points.

Repeat steps 3 and 4 for all boot images that have previously been distributed.

Notes

All existing media (such as stand-alone, boot, or prestaged) that use existing boot images (default or custom) will have to be re-created.

To fully fix the problem in Issue 2, the client side .msp file has to be installed during the "Setup Windows and ConfigMgr task by using the PATCH= command.

I’ve had several people contact me asking if I had new templates for ConfigMgr 2012 for my popular USMT to UNC posts I’ve done in the past. I’ve cleaned up the process quite a bit over the years and here is what I’ve been using with clients lately. In this blog post I will explain how I configure my Task Sequences to capture to a network location and I will provide links for the templates you can download.

There are many times where capturing/restoring USMT to a network share fits into the workflow better than using the built in State Migration Point (SMP). The SMP is encrypted, which is a good thing, but can cause issues for swapping data between devices. You are also required to create computer associations before you do a capture, which some times people forget to do. So an easy solution is to simply capture USMT to a network share instead. This process can be configured to dynamically move to different servers for different locations without much difficulty but I won’t be discussing that in this post.

Set Variables

The first thing I do in the Task Sequence is create a Set Variables group where we can set a few properties to be used in the Task Sequence.

The first variable we set is a ServerA property. This is the name if the server you want to capture the data up to. This step is conditioned to only run if the ServerA value is not already defined. If you are using MDT integration, you can define the ServerA value dynamically using the Database. This is commonly used to account for different geographical locations.

The second step we use to define the MigData variable. We take the ServerA value and create the path with the built-in OSDComputerName variable available to the Task Sequence.

The third step in the Set Variables section we use to set the OSDStateStorePath variable which is what USMT will actually use. We use this value so we can use the built-in USMT steps in the Task Sequence.

Capture User State

The USMT Capture section is made up of 3 steps.

The first step creates the directory in the targeted OSDStateStorePath location. This ensures the folder for the computer name exists. If the folder doesn’t exist, we can’t dump the user state data to it. This step is conditioned to continue on error, if the folder already exists, then the step will error out.

The second step is optional, but is an example of how you would pass additional parameters to the built-in Capture User State step. In the templates, I’m doing a /uel:90, which excludes all accounts older than 90 days. We do this using the variable OSDMigrateAdditionalCaptureOptions.

The third and final step in the USMT capture group is the default Capture User State step. You can customize which XML’s you want to use and the step will automatically process the values we have set previously.

Restore User State

One of the big advantages of using a process like this to capture user state is that we are dumping the data to a network share. If you are using the templates I’ve provided or created a similar process using the steps in this blog post, then User State will automatically be restored whenever a matching folder name is found. No association is required, if we can find data in the OSDStateStorePath then we will restore it.

The USMT Restore process also consists of 3 steps.

The first step simply sets our OSDStateStorePath variable again.

The second step configured additional restore options. In the templates/example, I’ve used a /ue:%computername%\* which excludes all local accounts from being restored.

The third and final step again simply uses the built in Restore User Step. This will use the OSDStateStorePath variable we’ve set and the OSDMigrateAdditionalRestoreOptions values together with however you have chosen to configure the Restore User State Step.

Templates

The first template I’ve created is for a stock ConfigMgr Task Sequence without MDT Integration. This has all the steps I’ve discussed configured for you, with explanations of what each step is doing.

These templates were created on a ConfigMgr 2012 SP1 lab environment, I don’t believe you can import these into a RTM site without issues.

If you are not going to use the templates I’ve provided, then you will need to configure your Task Sequence using the logic I discussed in this blog post and you will need to disable/remove all existing Request/Release/Move State Store steps in the Task Sequence. Those are used to work with the SMP and we won’t be needing those.

Deployment Fundamentals – Volume 3 is crammed with a lot of useful information on how to deploy Windows 7 with System Center Configuration Manager 2007 R3. We (the authors) have all been fighting with OS deployment for many years, and we simply decided to fill the book with everything we know on how to make it effective and easy to manage OS deployment in ConfigMgr. You also will find many real-world examples, including ready-made scripts and solutions you can use directly in your environment. Although this is a ConfigMgr 2007 book, there are few changes in the way OS deployment works in ConfigMgr 2012. Therefore, all of the useful insights and practical knowledge shared in this book translate easily to ConfigMgr 2012.

These types of updates aren’t available typically from Microsoft Update, so your normal Software Update steps in ConfigMgr don’t do the trick. When we use Lite-Touch, we have a “Packages” node where we can import these types of hotfixes, updates or Language packs and they will be installed automatically for us by the ZTIPatches script.

What I’ve seen most people do in ConfigMgr is they will create an individual package for each hotfix and then install them like an Application in the Task Sequence using a wusa.exe command line.

This works just fine, however, you are installing the hotfixes while in the full OS and you need multiple steps for each update. I’m sure you could come up with a fancy way to use a single step to install multiple updates via a script, but, MDT already can do that for you, so why reinvent the wheel!

Using a MDT integrated Task Sequence, we can install multiple hotfixes/updates in a single step for multiple architectures using a single package.

First we need to get the CAB files for the hotfixes/updates we want to work with. You can use your favorite extractor to get the files out of the MSU’s. 7-Zip did the trick for me and allowed me to do multiple files at once.

Once extracted, you only need the CAB, so I removed the other files from the folder.

Next I created a package source folder called “Windows 7 Hotfixes” and placed the extracted files in that folder. This folder contains both x86 and x64 hotfixes.

Create a Package that references those source files and distribute it to your Distribution Points.

Next, open up your Build and Capture Task Sequence. We want to add a new action to our Post Install phase, “Install Language Packs Offline”. This step actually calls ZTIPatches.wsf, so it’ll do what we want, just like in MDT Lite-Touch.

Select the Package you created earlier called “Windows 7 Hotfixes”.

Name the Task Sequence step appropriately.

Make sure your Task Sequence step is BEFORE the Configure step in the Post Install section.

Now when you run your Build and Capture Task Sequence, we will install the hotfixes offline and we’ll scan through the package and grab any applicable hotfixes/updates. If we find a x64 update and we are building an x86 OS, we’ll just skip it and only grab the x86 hotfixes that match.

Here we can see them installed on a system I deployed my captured image to.

Some tools require setting an environment variable when they are used. For example, the User State Migration Tool has several that can be used for troubleshooting. One is discussed in the Ask the Directory Services Team blog post here. Unfortunately, the built-in MDT or ConfigMgr Task Sequence steps for capturing and restoring the user state don’t allow you to set environment variables.

Trying to set the environment variable using a script in a preceding step will not work. If you set an environment variable in the script (e.g. using the SET command in a command shell script) it will only be set for that script. The task sequencer parent process will not inherit the environment variable, so neither will subsequent steps. Setting a System (or master) environment variable will have the same issue. The task sequencer will not inherit the new master environment. However, if you restart the computer after setting the System environment variable then task sequencer will inherit the updated System environment variables.

So the process for using an environment variable with something like USMT is to have steps before the steps that run the tool (the user state capture and restore steps in this case) that set the variable in the System environment and then restart the computer. This is shown in the steps prefixed with Custom: in the sample MDT Lite Touch Task Sequence below.

Michael Petersen has a nice new post up on the CoreTech Blog that is something I talk repeatedly about with clients. Only injecting the drivers you NEED, instead of needlessly injecting drivers until you get a working boot image.

It seems to me, people tend to add way to many drivers to their boot images, which in some cases make WinPE unstable, and subsequent make the Deployment fail. It also makes it near impossible to figure out which driver versions/types are actually included, as that info is kind of limited from within the Boot Image node itself …

What I do, is find the exact drivers needed for my WinPE environment to work on the specific model(s), and add only those drivers.. If I Can boot WinPE, and gain access to the network (IPCONFIG) and hard disk (DISKPART – list disk), I do not update my boot image, even if I choose to add a new NIC to the deployed OS itself!

In this example I will use a DELL latitude E6320, because this particular machine has a network driver not already included in WinPE.

The first thing to do is go into the device manager and check which driver the network card is using. I usually do this from the Win7 preloaded OS that comes with the machine (you know! before reinstalling). If this is not an option, you can do something similar from within WinPE using DrvLoad.exe, and wmic, but more about that in a later post!!

In the new Dart 7 (Beta) release, Microsoft added a remote connection application to WinPE, it allows you to connect to a WinPE system using the new Dart Remote Connection Viewer. This article explains how to add it to either MDT 2010 Lite Touch or ConfigMgr (SCCM) 2007 to monitor your deployments.

Credit goes to Michael Niehaus for letting me know it existed and explaining the inner works, and thank you Process Monitor and Process Explorer for helping me figure out what files where actually needed 🙂

I recently had the need to pop up a message box duing an LTI task sequence. I was creating a stand-alone wizard to allow a manually-initiated launch of a task sequence that would install the Service Pack 1 update on Windows Server 2008 R2. As part of this task sequence, if a certain software package was of a certain version or earlier we had to reinstall this software after the service pack installation. If this installation was not going to happen because a newer version was already installed, the customer wanted to notify the technician at the end of the process. Since this was to be a simple notification, a message box was sufficient. I could have simply created a VBScript that had a static MsgBox function call for this purpose.

However, I decided that I would make it more reusable than that. Instead I created an MDT script that would take the input arguments for the the MsgBox function as command line parameters. That way the script could be reused any time a message box was needed. The script can also optionally use the MsgBox return value as the script exit code and/or use it as the value for a task sequence variable.

……

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services – U.S. East Region