Michael Niehaus' Windows and Office deployment ramblings

Troubleshooting MDT 2012 Monitoring

Michael Niehaus — Thu, 10 May 2012 08:28:20 GMT

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:

A new “Microsoft Deployment Toolkit Monitor Service” service was installed on the computer and started.
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:

.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.
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.

Trying to install ConfigMgr 2012 RTM? Make sure you have the right SQL…

Michael Niehaus — Fri, 27 Apr 2012 03:18:43 GMT

Now that Configuration Manager 2012 RTM is available, people will certainly start installing it, both in their labs and in production – and will start finding out that the SQL version check in the ConfigMgr installer is looking for some very specific SQL maintenance levels. (I’ve pulled out plenty of my own hair doing this recently, just like I did with the prerelease versions.) The supported versions can be found at http://technet.microsoft.com/library/gg682077.aspx#BKMK_SupConfigSQLDBconfig. The summary (always subject to change):

SQL Server 2008 SP2 Standard and Enterprise CU9
SQL Server 2008 SP3 Standard and Enterprise CU4
SQL Server 2008 R2 SP1 and CU6
SQL Server Express 2008 R2 and CU4 (secondary sites only)

If you are running SQL 2008 SP2, install CU9 from http://support.microsoft.com/kb/2673382/. If you are running SQL 2008 SP3, install CU4 from http://support.microsoft.com/kb/2673383/. If you are running SQL Server 2008 R2 SP1, use CU6 from http://support.microsoft.com/kb/2679367/. If you aren’t yet on the needed service pack levels, upgrade now, then install the cumulative updates :-)

I’m still looking for a statement on ConfigMgr 2012 RTM and SQL Server 2012. (ConfigMgr 2007 now supports it, see http://blogs.technet.com/b/configmgrteam/archive/2012/04/17/configuration-manager-support-announcements-for-april-2012.aspx.) There’s already a CU1 for SQL Server 2012, http://support.microsoft.com/kb/2679368/.

Inside a Task Sequence

Michael Niehaus — Fri, 20 Apr 2012 18:01:00 GMT

I’ve done a few sessions now where I demonstrated how to put some hooks into a task sequence so that you can single step through the process and “poke around” to see exactly what is going on. Since I’ve promised to make those scripts available, and will get lots of e-mails from people if I don’t do that, I’ll provide those at the bottom of this blog posting.

But the scripts by themselves require some explanation, some instructions, and some caveats.

Some Explanation

First, let’s talk about the basic setup. If you look at a ConfigMgr task sequence, it contains a number of steps and groups that define the sequential process that is going to be executed. This is actually converted into XML, where each step and group becomes a series of XML entries that define:

The command line to be executed.
The variables that are expected by the step (at least those that can be configured by the task sequence editor – the step’s command may use others).
The conditions for the step – if the conditions aren’t satisfied, the step won’t run.
The definition of success – a list of return codes that should be considered “successful”, typically 0 and 3010. You can also say to ignore errors, which means to ignore the return code.

Before the client computer begins to execute the task sequence, it receives (as part of the task sequence policy) the entire XML blob. That XML blob is then processed by the Task Sequence Manager, TSManager.exe, which is what actually starts the commands for each step (at least those where it has decided the conditions have been met).

So that’s a key part of what we want to do: We want to intercept each of the commands that are being executed by the TSManager.exe process before they actually start. That way, we can look at the task sequence variables currently defined, the command line details, the step’s XML, etc. How do you do this intercepting? That’s where a debugger comes in. A debugger can attach the TSManager.exe process, then set a breakpoint on the Windows API call, CreateProcessW, that is used by TSManager to run the command for each step. Each time TSManager.exe then tries to run a new command, the debugger will stop the process until you manually say continue.

That’s where the scripts come in: The provided “InsideTS” scripts take care of setting up the debugger (attaching to the TSManager.exe process, setting the breakpoint), watching for breakpoints (checking the log for “breakpoint hit” messages), and showing the current state (displaying the step details, task sequence variables, logs, etc.). The pieces involved:

InsideTS_Attach.wsf. This is the script hooked into the task sequence itself. It needs to run at the beginning of the task sequence and then each time the computer reboots. (The debugging process doesn’t survive reboots.) It launches the next script, InsideTS_Monitor.wsf, to do the real work, waits until the debugger process (NTSD.EXE) shows up, then exits.
InsideTS_Monitor.wsf. This script, as already mentioned, starts the debugger, NTSD.EXE. It feeds it initial commands to attach to TSManager.exe, to set the breakpoint on CreateProcessW, and to write all the debugger output to a file. The script then monitors the log file looking for “breakpoint hit” messages, and when that happens, it starts a wizard, InsideTS_Details, to show the details of what’s currently going on.
InsideTS_DebugCommands.txt. This file contains the initial commands that are passed to NTSD.EXE.
InsideTS_Details.xml, InsideTS_Details.vbs, and InsideTS_Header.jpg. These files form an MDT HTA wizard pane (which is why this setup requires scripts from MDT, which will be described below). This wizard pane will show three tabs:

Task Sequence. This will give a graphical representation of the task sequence, like you would see in the task sequence editor, and will highlight the step that is about to run. (The breakpoint happens right before this step starts.)
Variables. This will show a list of all the task sequence variables. New variables (those that haven’t been seen before) will show up in green. Existing variables that have new values will show up in yellow. Those that no longer exist (e.g. local variables that are valid only for a single task sequence step) will show up in red (showing the old value that is no longer present). And finally, those that are unchanged since the last step will not be highlighted (showing up in white).
Step. This will show the definition of the step in two ways. First, it will show the XML definition for the step from the task sequence XML blob (which itself is stored in a task sequence variable). It will also show the MOF definition of the step (basically, the definition that the task sequence editor uses to configure the step via the GUI).

InsideTS_TaskSequence.xsl. This is an XML style sheet that converts the task sequence XML blob into displayable HTML. The resulting HTML is displayed on the Task Sequence tab, described above, with the current step highlighted.
InsideTS_Variables.xml. This is another XML style sheet, used to convert the list of task sequence variables (which are saved into an XML file by the InsideTS_Monitor.wsf script – they aren’t typically stored in this way) into HTML displayed on the Variables tab of the details wizard described above.
InsideTS_MOF.xml. This file contains the definitions for each of the steps used in ConfigMgr 2012 and MDT 2012 task sequences.

Some Instructions

In addition to the files listed above, you need to gather these additional files:

From the Windows Debugger tools download (http://msdn.microsoft.com/en-us/windows/hardware/hh852363), you need one file, NTSD.EXE.
From ConfigMgr 2012, you need a copy of the CMTrace.exe.
From MDT 2012, you need several files to support the scripts and wizards described above:

Computer.png, FolderIcon.png, ItemIcon1.png, MinusIcon1.png, NavBar.png, PlusIcon1.png, Wizard,ico (graphics used in the wizard pane).
Wizard.hta, WizUtility.vbs, Wizard.css (the MDT HTA wizard “engine”).
ZTIDataAccess.vbs, ZTIUtility.vbs (main MDT utility scripts).
ServiceUI.exe (a component from MDT that enables the MDT HTA wizard to be visible from the ConfigMgr task sequence, even when in the full OS).

Once you have gathered all of these files into one folder, they need to be added into the ConfigMgr boot image that you will be using and into the new OS image that you are deploying. Create an “InsideTS” folder at the root of both of these. (The simplest way to do this: mount both of the WIMs, XCOPY the folder to X:\InsideTS, commit the changes, then update the DPs.) Why do I include these files in the images? Well, it was easier to do it that way. (More on that later.)

Now that the files have been added to the boot and OS images, you then need to add commands to the task sequence to run InsideTS_Attach.wsf. How many steps you need to insert into this depends on how many reboots you expect the task sequence to perform; you need one after each reboot. At minimum, you will need two, one to run in Windows PE for preinstallation steps and a second to run in the new OS. The step should look like this:

Assuming you have set everything up right, you should be able to start the task sequence and see something like this show up:

This shows the step after the “InsideTS Attach” as being the next one to execute. You can then click on the “Variables” button and see that all of the variables are highlighted in green because they are all considered “new” (as in “never seen before”) at this point:

Once you’ve poked around enough, click the “Finish” button to close the wizard. At that point, you’ll see a strange sight: the NTSD debugger. In a perfect world, the InsideTS_Monitor.wsf script would feed the commands to continue with the step execution once you’ve clicked “Finish” on the wizard, but after messing around with that for a couple of hours, I gave up on that and went with a lower-tech approach: Type in the needed commands yourself. In case you aren’t familiar with NTSD command line options, here’s a quick reference to the ones you’ll need to know:

“G” means go. Type G to run the step.
“Q” means quit. You’ll have to type Q to exit the debugger after the TSManager.exe process exits (which it does before rebooting and before the task sequence completes). If you type Q before that point, the task sequence will die (it quits the debugger and the TSManager.exe process being debugged), so don’t do that. (If you do want to continue the task sequence without any more breakpoints, type “bc0” to clear the breakpoint, then “g” to continue the execution.)

That’s really all you need to know. (I used one other command, “du rdx”, to dump out the CreateProcessW command line parameter during the session, but you can see the same value at the end of the SMSTS.LOG, which you can open by clicking the “Log” button in the wizard.)

Some Caveats

Some people know the story behind this little tool: I originally put these scripts together for a BDNA “SCCM Guru” webcast back in November. The webcast was scheduled months in advance, so I assumed I had plenty of time to prepare. For a variety of reasons (including procrastination) I didn’t prepare for this nearly as soon as I had hoped. In fact, I didn’t start most of it until about 30 hours before the presentation was due to start. And for about 18 of those hours, I was travelling back to Seattle from Moscow – in coach of course. So all the preparation work was done on the airplane, with the scripting done on the Moscow to New York flight, when there was no internet connection, and the testing (and bug fixing) happening on the flight from New York to Seattle (VPN connection from the airplane to my office Hyper-V server, thank you http://www.gogoair.com). The next morning, I presented the session, completely jetlagged…

So there’s my excuse for the following caveats:

I suspect you could add the files to the MDT toolkit files package, then put the “InsideTS Attach” step after each “Use Toolkit Package” step. That would avoid needing the files in the boot image image and OS WIMs. That may require script changes.
I think this will work for both x86 and x64, but I’ve only tried it with x64. (Make sure you get the right platform version of NTSD.EXE and ServiceUI.EXE.) If you want it to work for both (e.g. x86 boot image deploying an x64 OS), you will likely need to make changes to the scripts.
You should be able to use this for refresh executions as well, but you’ll then need at least three “InsideTS Attach” steps (one for the original OS, one in Windows PE, one in the new OS).
I’ve only tried this with ConfigMgr 2012, but it should work with ConfigMgr 2007 too (although since the task sequencer runs as x86 even on an x64 OS, there might be some script updates needed to run the appropriate tools on each platform).
This same process should work for Lite Touch task sequences too, but I’ve not tried that yet.
I cheated on the task sequence step MOF class definitions. While the “source” files for these are in the ConfigMgr (_TaskSequenceProvider.mof) and MDT 2012 (Microsoft.BDD.CM12Actions.mof) installation directories, these files are not easy to read from a script. So I merged these files together, then put XML “wrapper” around each step to make it easier to display the MOF details.
I tried a variety of debuggers (there are several included in the debugging tools download) to try to get one that I could drive via a script, but I had issues with them that prevented complete automation. That’s why you have to manually type “g” and “q” to interact with the debugger directly. I suspect this is fixable, but I haven’t had a chance to try it.
Don’t use this with live, production task sequences. Think of it more as a “learning” tool that you can use in your lab to figure out what happens during a task sequence.
Don’t call Microsoft for support. You can e-mail me with comments and suggestions if you would like. The standard Microsoft disclaimer:

This script code is provided as is with no guarantee or warranty concerning the usability or impact on systems and may be used, distributed, and modified in any way provided the parties agree and acknowledge the Microsoft or Microsoft Partners have neither accountability or responsibility for results produced by use of this script. Microsoft will not provide any support through any means.

Finally

If you manage to set this up successfully, or if you run into any issues, please e-mail me at mniehaus@microsoft.com to let me know. I think the instructions and scripts should work, but I offer no guarantees

Have you tried the Application Approval Workflow solution accelerator?

Michael Niehaus — Fri, 30 Mar 2012 23:46:14 GMT

System Center 2012 Configure Manager includes an application catalog web site, which allows end users to select the applications that they want to install. As part of this, they provide the ability to specify that approval is required before the software can be installed, a required feature in most enterprises. If you aren’t familiar with the application catalog, the blog posting at http://blogs.technet.com/b/ptsblog/archive/2011/12/20/configuration-manager-2012-rc-configure-software-catalogue-portal-and-publish-applications.aspx goes through the flow (although it’s slightly out of date, it gets the point across).

But out of the box, approvals come from exactly one source: the ConfigMgr administrator. What if you want others to do the approvals (mainly because you have better things to do)? That’s where the newest free solution accelerator comes in. The Application Approval Workflow solution accelerator was announced on the Service Manager blog at the beginning of this week:

http://blogs.technet.com/b/servicemanager/archive/2012/03/26/application-approval-workflow-aaw-solution-accelerator-beta-now-available.aspx

The solution works by leveraging three different System Center 2012 products:

Configuration Manager, for showing the application catalog and accepting user requests.
Service Manager, which handles the approval requests using the “service request” functionality. Approvers can be defined for each application, groups of applications, groups of users, etc.
Orchestrator, which is responsible for doing the behind-the-scenes work coordinating the activities between Configuration Manager and Service Manager.

The beta ends soon, so download quickly. Expect to see more about this at MMS 2012 too.

MDT 2012 New Feature: Monitoring

Michael Niehaus — Fri, 09 Mar 2012 08:40:43 GMT

I was going to do a blog posting talking about how to troubleshoot issues with the new monitoring feature available in MDT 2012 for Lite Touch deployments, but then I realized I’ve not yet done an initial post talking about the feature (although I did mention it in a previous blog posting talking about DaRT integration). So I guess I need to start with more of an overview.

Over the years, there have been requests for a way to see what deployments are presently in progress. Way back when, we had a MOM management pack that tried to do this, but there were numerous challenges with that so we ended up removing it – we needed something much simpler. So with MDT 2012, we implemented something simpler to monitor Lite Touch deployments. To enable this, just check one box in the deployment share properties:

When you do this, two things happen:

A new service, the “Microsoft Deployment Toolkit Monitor Service” (short name MDT_Monitor), is installed on the computer. This service receives events from the computers being monitored, tracking each computer and how far it is in the deployment process. It also provides this tracking data to Deployment Workbench for you, the administrator, to see.
The CustomSettings.ini file is modified to add a new entry specifying the URL (a combination of the host name and port specified in the deployment share settings) to be used for monitoring. This is how clients know where to send information. The MDT scripts (through their use of ZTIUtility.vbs) will automatically send events to this URL.

That’s all there is to it. Once you do that, you should be able to track all subsequent deployments via the “Monitoring” node in Deployment Workbench:

If you look at the properties of any of the computers being monitored, you can see the details:

You’ll notice that the display automatically updates every 10 seconds, so you can watch the computer progress. Also, there are three possible buttons (two of which are shown below):

Remote Desktop. This button runs the Remote Desktop Client (MSTSC.EXE), specifying the host name to connect to on the command line. (This will only work if the computer is presently in a full OS and remote desktop is enabled and accessible through the firewall. It won’t work if the computer is in Windows PE.)
VM Connection. This button will only show up if you are using a Hyper-V VM. If you click it, it will run the Hyper-V connection tool (VMConnect.exe) to connect to the host and VM name of the machine. (We gather that information from the Hyper-V integration components from ZTIGather.wsf and pass those values along to the monitor service. Because the integration components don’t run in Windows PE, we can only get this information when in a full OS, so this button will not be enabled when starting a new computer deployment from Windows PE. Also, this requires that the Hyper-V host be accessible from the computer running Deployment Workbench.)
DaRT Remote Control. This button will only show up if DaRT has been integrated into the MDT Lite Touch boot image. It will run the DaRT Remote Control Viewer, passing along the computer’s IP address, DaRT ticket number, and listening port number, using those values to automatically initiate a remote control session. (This will only work when the computer is in Windows PE, because the DaRT remote control agent only runs in Windows PE.) See http://blogs.technet.com/b/mniehaus/archive/2011/11/28/mdt-2012-new-feature-dart-integration.aspx for more information about the DaRT integration.

A few other details:

The computers will be automatically removed after three days, to keep the database from getting too big.
If the monitoring service doesn’t hear from a computer for more than four hours, it considers the machine “unresponsive” – so if you see that status in the Workbench list, that’s why.
Every time a deployment task sequence starts, completes, or fails, an event log message will be written by the service. So if you want to trigger some activity based on these events, you can easily do so.
You might think that IIS would be required for the MDT_Monitor service, but it’s not. It’s leveraging features of the .NET Framework to run a “mini web server” as part of the service itself.
You might also think that a SQL database would be required to store the details. Well, there is one, but you don’t need to install SQL Server to use it. MDT uses a SQL Compact database; all the files needed are installed as part of MDT (and only used if monitoring is enabled).

That’s the quick overview.

MDT 2012 New Feature: Item Sorting

Michael Niehaus — Fri, 09 Mar 2012 00:49:22 GMT

For those of you who have already installed MDT 2012 RC1, you might notice that there is a new behavior in Deployment Workbench: It will keep the list of items (applications, drivers, OS packages, task sequences) in alphabetical order.

Now when you first install MDT 2012 RC1, you might notice that the items aren’t sorted right away – you have to change something in the folder first. As soon as you do (e.g. add an item, rename an item), the items in that folder will be sorted.

Keeping the list of folders sorted is a much bigger challenge, so at this point they will still show up in the order that they were added. That’s something we will have to look at again in a future version.

Trying to install ConfigMgr 2012 RC2? Make sure you have the right SQL…

Michael Niehaus — Wed, 18 Jan 2012 23:41:37 GMT

Now that Configuration Manager 2012 RC2 is available, people will certainly start updating their labs – and finding out that the SQL version check in the ConfigMgr installer is looking for some very specific SQL maintenance levels. (I’ve pulled out plenty of my own hair doing this recently.) The release notes cover the supported versions:

Supported versions of SQL Server 2008 for RC2:

SQL Server 2008 SP2 Standard and Enterprise CU7

SQL Server 2008 R2 SP1 and CU4

SQL Server Express 2008 R2 and CU4

If you are running SQL 2008 SP2, install CU7 from http://support.microsoft.com/kb/2617148. If you are running SQL Server 2008 R2 SP1, use CU4 from http://support.microsoft.com/kb/2633146. If you aren’t yet on the needed service pack levels, upgrade now, then install the cumulative updates :-)

Customizing Wizards with MDT 2012

Michael Niehaus — Sat, 07 Jan 2012 22:57:28 GMT

Many of you have customized the MDT 2010 wizards, and I expect that will be fairly common with MDT 2012 as well – after all, one of the design goals with having HTA-based wizards is to enable customization by creative IT pros. But the process is going to be slightly different with MDT 2012.

First, let’s review the basic process most of you would go through with MDT 2010:

Download the MDT Wizard Editor from http://mdtwizardeditor.codeplex.com/. This makes editing the wizard simpler (although not necessarily trivial – there can still be a fair amount of work to do, depending on the extent of the changes that you intend to make).
Open the “DeployWiz_Definition_ENU.xml” file and make the necessary changes: Adding new panes, changing the HTML and properties of existing pane, etc.
Using Notepad or any other text editor, add any custom scripting to DeployWiz_Initialization.vbs or DeployWiz_Validation.vbs.
Test out all the changes using the MDT Wizard Editor, or if this isn’t possible (due to conditions on the wizard pane or logic contained in the pane itself) drop the changed files into the deployment share and try a deployment.

So it’s quite reasonable for you to try the same thing with MDT 2012. But you’ll quickly discover that you can’t get very far. You can open the file, but as soon as you click on one of the wizard panes in the left-hand column, you get this exception:

So what causes this? Well, if you look at the files in the deployment share, you’ll notice that there are quite a few more that start with “DeployWiz”. That’s because the entire wizard has been restructured. Instead of having one set of large files (DeployWiz_Definition_ENU.xml, DeployWiz_Initialization.vbs, DeployWiz_Validation.vbs), there are now separate files for each wizard pane (e.g. DeployWiz_ComputerName.xml and DeployWiz_ComputerName.vbs). The original files (DeployWiz_Definition_ENU.xml, etc.) are still around, but are much smaller – the bulk of the content has been separated out.

Why was this done? Mainly because it makes the wizard code much easier to maintain. It’s now much more obvious what script pieces are used for which wizard panes. Additionally, it makes the wizard easier to test, as you can work on a single pane at a time without worrying about breaking another unrelated pane.

The individual panes are then tied together by the DeployWiz_Definiton_ENU.xml file. If you look at this file, you’ll see that it’s pretty short, with entries like this:

<Pane id="SelectTaskSequence" reference="DeployWiz_SelectTS.xml">
<Condition><![CDATA[UCASE(Property("SkipTaskSequence"))<>"YES" ]]></Condition>
</Pane>

All that is there is a reference (or link) to the separate files for each wizard pane, along with the conditions for when each wizard pane should be displayed. (This helps with the testing as well: By keeping the conditions in the DeployWiz_Definition_ENU.xml file instead of in the individual wizard files, those conditions don’t get in the way of “offline testing”, e.g. running just that one single wizard pane without going through a full deployment.)

So why does that cause problems with the Wizard Editor? Simple: It doesn’t understand that the wizard pane body is in a separate file. It can’t follow the reference link (highlighted in yellow above) to the separate wizard pieces. So does that mean the Wizard Editor is no longer useful? Not at all – you can still use it to work on (and test) individual pages like DeployWiz_ComputerName.xml:

But you’ll need to edit the DeployWiz_Definition_ENU.xml file by hand.

I’m working on a new version of the Wizard Editor in my “free time” so that it learns how to follow these links (with other improvements added in too), but it might take a while before I can complete that work.

So what does the recommended workflow look like if you wanted to add a new wizard pane to MDT 2012? Here are the basics:

Download the MDT Wizard Editor from http://mdtwizardeditor.codeplex.com/.
Make a copy of files for one of the wizard pane files. For example, copy DeployWiz_AdminPassword.xml as “MyPane.xml” and DeployWiz_AdminPassword.vbs as “MyPane.vbs”.
Use the Wizard Editor to customize and test the new wizard pane.
When you are happy with the functionality of the new wizard pane, add an entry for it into DeployWiz_Definition_ENU.xml (just like all the others, with any conditions that you might need), then test it out as part of a normal deployment.

This new flow has another advantage too: It makes it much easier to integrate a new wizard pane into MDT. You don’t have to worry about reintegrating your changes into the “big” XML file each time you upgrade MDT – your separate files will continue to exist, untouched, so all you will need to do is add the “link” into DeployWiz_Definition_ENU.xml again and you’re good to go.

Creating the ConfigMgr “System Management” Container with PowerShell

Michael Niehaus — Thu, 05 Jan 2012 09:52:00 GMT

One of the steps in the Configuration Manager installation process is to manually create the “System Management” container in Active Directory, then give the ConfigMgr computer account the ability to create objects in it. Yes, even with Configuration Manager 2012, this is still something that needs to be done manually.

So that was this evening’s challenge: Automating that seemingly simple task. As with all automation tasks, you always hope that someone has already solved the problem. But even with searching multiple search engines (something that always pains me), I didn’t really find what I was looking for. (No executables, no third-party tools, no ugly ADSI code, and ideally no VBScript – PowerShell is the future.) So I created a new PowerShell script, incorporating bits and pieces from several other scripts. The basic steps:

Import the “ActiveDirectory” PowerShell module (which only exists in Windows Server 2008 R2, so that is required).
Figure out our domain name (so we don’t have to hard-code a value in the script).
Create the “System Management” container if it doesn’t already exist.
Get the computer account (from the environment, so we don’t need to hard-code that either).
Add the computer account to the “System Management” container’s access control list, giving it full access.

Sounds simple enough, and except for the ACL part, it is. The complete script:

#Requires -version 2.0

# ***************************************************************************
#
# File:      SystemManagement.ps1
#
# Version:   1.0
#
# Author:    Michael Niehaus
#
# Purpose:   Create the AD "System Management" container needed for
#            ConfigMgr 2007 and 2012, and grant access to the current
#            computer account.
#
#            This requires PowerShell 2.0 and Windows Server 2008 R2.
#
# Usage:     Run this script as a domain administrator, from the ConfigMgr
#            server. No parameters are required.
#
# ------------- DISCLAIMER -------------------------------------------------
# This script code is provided as is with no guarantee or waranty concerning
# the usability or impact on systems and may be used, distributed, and
# modified in any way provided the parties agree and acknowledge the
# Microsoft or Microsoft Partners have neither accountabilty or
# responsibility for results produced by use of this script.
#
# Microsoft will not provide any support through any means.
# ------------- DISCLAIMER -------------------------------------------------
#
# ***************************************************************************

# Load the AD module

Import-Module ActiveDirectory

# Figure out our domain

$root = (Get-ADRootDSE).defaultNamingContext

# Get or create the System Management container

$ou = $null
try
{
    $ou = Get-ADObject "CN=System Management,CN=System,$root"
}
catch
{
    Write-Verbose "System Management container does not currently exist."
}

if ($ou -eq $null)
{
    $ou = New-ADObject -Type Container -name "System Management" -Path "CN=System,$root" -Passthru
}

# Get the current ACL for the OU

$acl = get-acl "ad:CN=System Management,CN=System,$root"

# Get the computer's SID

$computer = get-adcomputer $env:ComputerName
$sid = [System.Security.Principal.SecurityIdentifier] $computer.SID

# Create a new access control entry to allow access to the OU

$ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule $sid, "GenericAll", "Allow", "All"

# Add the ACE to the ACL, then set the ACL to save the changes

$acl.AddAccessRule($ace)
Set-acl -aclobject $acl "ad:CN=System Management,CN=System,$root"

The same script is attached.

MDT 2012 New Feature: Gather improvements

Michael Niehaus — Fri, 02 Dec 2011 23:31:36 GMT

Sometimes it’s the little things that most people fail to notice that need some attention. In this case, we’re talking about new task sequence variables automatically set by the MDT “Gather” process (specifically, the ZTIGather.wsf script). There are a few new ones in MDT 2012:

IsOnBattery. This will be set to true if the machine is currently running using a battery with no AC power. This can be useful in any deployment – you really don’t want a computer to turn off because the battery went dead during a deployment.
VMHost. When a virtual machine is running on a Hyper-V server and has the Hyper-V integration components installed, we can determine the name of the Hyper-V server (the VM host) that the VM is running on.
VMName. This also comes from the Hyper-V integration components, telling us the name of the virtual machine in Hyper-V, which might be different than the “computer name” (the name given to the OS) of the VM.

We also made a few other related changes:

The “Make” property now detects Xen, in addition to the the other platforms that could be detected in MDT 2010 Update 1 (Hyper-V, VMWare, VirtualBox).
We fixed the “SMSDP” property, so it should now always return a valid server name for the ConfigMgr distribution point that the boot image associated with the task sequence came from. (The task sequence doesn’t have a distribution point, so we had to pick a package that each task sequence should have.)
We changed the “OSVersion” property so that it doesn’t generate an error on unknown OSes (e.g. Windows 8). We don’t plan to add new OSes to the list set by this function, so consider this variable to be “functionally stabilized” and “obsolete”. It would be better to use OSCurrentVersion or OSCurrentBuild (maybe combined with IsServerOS) instead.
We added progress reporting (which works with Lite Touch and ConfigMgr deployments) so that you can see what ZTIGather is doing during the process. This will be especially useful when you are doing database queries: you’ll be able to see which ones are taking too long.

MDT 2012 New Feature: DaRT integration

Michael Niehaus — Mon, 28 Nov 2011 06:31:05 GMT

In MDT 2012 Beta 2, a new feature has been added: the ability to integrate the Microsoft Diagnostics and Recovery Toolset (DaRT) 7 into the Lite Touch boot images generated by MDT. The end result is a new option when booted into Windows PE:

And when you choose the “Run DaRT Tools” option, you can see all the tools that DaRT offers:

While you will typically see DaRT positioned as more of a “recovery” tool, you can probably see the “diagnostics” benefits too, using the provided tools to inspect the current computer.

One of the new features in DaRT 7 is especially useful: remote control. Using this you can access a remote computer even while it is in Windows PE. There is a client-side agent for this that is automatically executed as soon as the MDT “Welcome” wizard completes. (We don’t start it before then because you might be using static IP addressing that would be configured through the “Welcome” wizard. If you aren’t planning to use static IP, you can skip the “Welcome” wizard by setting “SkipBDDWelcome=YES” in CustomSettings.ini.) You’ll see this minimized on the bottom left of the screen:

If you restored that to a full window, you would see that it is listening for connections:

From a computer with DaRT installed, you can run the “DaRT Remote Connection Viewer” to make the connection, just type in the ticket number, IP address, and port. (If you’ve enabled the MDT 2012 monitoring feature, to be discussed more in a future blog posting, this process is automated – the connection details are automatically provided.) The connection performance is good, just like you are using a typical RDP connection. (Really, that’s exactly what you are doing – this uses the same underlying protocol as a typical remote desktop connection.)

So how do you enable the DaRT integration? The MDT documentation explains this, although there is an error in step #1, which I’ve rewritten below:

Enable DaRT support

Copy the Tools.cab file from the DaRT installation to the appropriate tools folder (either Tool\x86 or Tools\x64) in a deployment share.

Click Start, and then point to All Programs. Point to Microsoft Deployment Toolkit, and then click Deployment Workbench.

In the Deployment Workbench console tree, go to Deployment Workbench/Deployment Shares

In the details pane, click deployment_share (where deployment_share is the name of the deployment share for which you want to enable DaRT support).

In the Actions pane, click Properties.
The deployment_share Properties dialog box appears (where deployment_share is the name of the deployment share for which you want to enable DaRT support).

In the deployment_share Properties dialog box, on the Windows PE tab, select platform (where deployment_share is the name of the deployment share for which you want to enable DaRT support and platform is the processor architecture platform for which you want to enable DaRT support), select the Microsoft Diagnostics and Recovery Toolkit (DaRT) check box, and then click OK.

Update the deployment share.
As a part of updating the deployment share, the DaRT files are integrated with the Lite Touch Windows PE .wim files, which automatically include Windows RE. When the .wim files are installed on the target computer, DaRT support will automatically be included.
Note For more information about updating a deployment share see Update a Deployment Share in the Deployment Workbench

Close all open windows and dialog boxes.

So how do you know which folder to copy the “Tools.cab” into? Well, when you install DaRT on an x86 OS, you get an x86 Tools.cab, so that goes into the Tools\x86 folder. Conversely, when you install DaRT on an x64 OS, you get an x64 Tools.cab, so that goes into the Tools\x64 folder. (Yes, that’s less than ideal as it means you need an x86 and an x64 install of DaRT to get both platform files. We’re working on that. In the meantime, you can cheat: you can do an administrative install of the opposite platform using “msiexec.exe /a MSDart70msi”. That will end up creating the folder structure, but not any of the shortcuts, for the opposite platform install.)

Once you’ve copied the files into the right place, you can then see a new Windows PE component in the deployment share properties:

Check the DaRT checkbox (for each platform), apply the changes, update the deployment share, and you’re done.

A few common questions:

Q: How do I get DaRT?

DaRT is a component of the Microsoft Desktop Optimization Pack (MDOP). To get DaRT, you need to get MDOP. To get MDOP, you need to have Software Assurance on your client computers (or be using Windows Intune). If you have any questions, contact your local Microsoft account team. (Don’t know who they are? Drop me an e-mail and I’ll find out.)

Q: How does monitoring help with this?

The DaRT remote control agent writes a file to the X:\Windows\system32 folder with the details needed to make a remote control connection (ticket, IP address, port). This file is found by the MDT “Gather” script (you can see the values in the BDD.LOG). When monitoring is enabled, those details are passed along to the monitoring server and stored, making it easy to initiate remote control with a simple button push:

This initiates the DaRT Remote Connection Viewer with command line parameters with the required details (ticket, IP address, port).

Q: Can this be done with Configuration Manager too?

Well, sort of. If you copy the Tools.cab files into the C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Tools\<platform> folder, you will then see the “Microsoft Diagnostics and Recover Tools (DaRT)” option in the MDT wizard for creating a new boot image in ConfigMgr:

So that adds the pieces into the boot image, but you would still need to run them as part of a ConfigMgr task sequence with a command line like “cmd.exe /c start /min x:\windows\system32\RemoteRecovery.exe -nomessage”.

SCCM Guru webcast coming up soon

Michael Niehaus — Thu, 10 Nov 2011 11:44:38 GMT

As part of the BDNA “SCCM Guru” webcast series, I will be presenting on November 17th from 11:00am to 12:00pm Pacific time. The topic of the presentation:

Inside a ConfigMgr 2012 OS Deployment Task Sequence

In this webcast with Michael Niehaus, Microsoft’s “Deployment Guy”, you will learn:

The inner workings of a task sequence, showing the various steps in the process

How information is passed to and between each step & what the steps do

How to troubleshoot when things don’t go as expected

I am planning to do something different for this session – with a week to go for preparation (and being on vacation for most of that time), it will be interesting to see how much of my “vision” I’ll be able to get ready in time. (As an added complication, I will be presenting while jetlagged – I arrive back in Seattle the evening before, after a twelve-hour time change. Don’t worry, I’ll have lots of caffeine handy.)

To register for the session, please visit this link:

http://info.bdna.com/20111116-Webcast-SCCM-Guru-Michael-Niehaus-RegistrationPage.html

Windows Thin PC: Another flavor of Windows 7

Michael Niehaus — Thu, 08 Sep 2011 07:15:16 GMT

As I discovered in recent TechEd presentations in Australia and New Zealand, not too many people are familiar with the newest members of the Windows 7 family. So let’s explore one of those in more detail, called Windows Thin PC. For the full marketing overview, you can review these pages:

http://www.microsoft.com/windows/enterprise/solutions/virtualization/products/thinpc.aspx

http://www.microsoft.com/licensing/software-assurance/windows-thin-pc.aspx

To summarize, Windows Thin PC is a modified version of Windows 7 (built from a Windows Embedded Standard 7 base) that is available as a Software Assurance benefit (for anyone with Software Assurance on their desktop operating systems). It has a reduced footprint (1.1GB compressed WIM, under 5GB when expanded on disk), and as a result has lighter hardware requirements:

1GHz processor
1GB RAM
16GB hard disk space

So it should come as no surprise that it is designed to be used as a thin client OS, enabling older or lesser hardware to connect to your VDI or terminal services infrastructure to run most applications.

Windows Thin PC has licensing restrictions that allows very few applications to be installed and used locally. From the Thin PC FAQ:

Can I run applications on WinTPC?

Yes, you can run applications that fall into one of the following categories:

Security

Management

Terminal emulation

Remote Desktop and similar technologies

Web browser

Media player

Instant messaging client

Document viewers

.NET Framework and Java Virtual Machine

However, you cannot run any productivity applications, such as Microsoft Office or similar applications.

Again, this is pretty consistent with what you could do with dedicated thin client hardware,

So what is it like to deploy this operating system? It deploys just like any other version (SKU) of Windows 7. MDT 2012 will officially support deploying this OS (since that where we’ve done all of our testing), but it’s not hard to get MDT 2010 Update 1 to deploy it too by removing the <UpgradeData> section from the unattend.xml that you use to deploy Windows Thin PC.

What does it look like once installed? Just like Windows 7, but with fewer items on the start menu:

So it’s not an operating system for everyone, but it does have its place.

Hyper-V on Windows 8 Client!

Michael Niehaus — Thu, 08 Sep 2011 02:56:00 GMT

Be sure to read the great new posting on the “Building Windows 8” blog:

http://blogs.msdn.com/b/b8/archive/2011/09/07/bringing-hyper-v-to-windows-8.aspx

(Read through the comments too, which talk about support for sleep and hibernate.)

There is one prominent statement made:

Hyper-V requires a 64-bit system that has Second Level Address Translation (SLAT).

That means you have a great reason to consider using the 64-bit version of Windows 8, and why you should buy only hardware with 64-bit support. But what about the second part of that, SLAT support? Well, all you really need to understand is that SLAT is a processor feature that improves virtual machine performance, especially when using higher-end video cards (e.g. those used on client machines). Read more about the benefits in the Hyper-V R2 announcement:

http://technet.microsoft.com/en-us/library/dd446676(WS.10).aspx

This mentions that Intel and AMD have different implementations of this. Intel calls theirs “Enhanced Page Tables” (EPT), while AMD refers to it as “Nested Page Tables” (NPT). Regardless, what you really care about is whether or not a particular processor includes the support. That’s not always easy to figure out from the vendor’s web sites. Fortunately, there is a newly-updated tool available on the SysInternals web site called Coreinfo that will tell you all about a processor’s capabilities:

http://technet.microsoft.com/en-us/sysinternals/cc835722

Mark Russinovich updated this utility recently to add the ability to detect both Intel EPT and AMD NPT. Here’s what the output would look like if your machine has an Intel processor with the needed support:

The AMD output will be slightly different (and not because it’s on a white background instead of a black one):

In both cases, the asterisk (“*”) in the second column indicates that the feature is present. (A minus, “-“, shows if it isn’t.) Be careful if running this in a VM or on a machine currently running a hypervisor, as these will mask the real processor capabilities.)

So check out your machines today to see if they are ready for Windows 8 client Hyper-V!

Migrating application settings with USMT 4.0: Sample #2

Michael Niehaus — Wed, 24 Aug 2011 23:35:00 GMT

So maybe migrating Angry Birds high scores and settings isn’t terribly useful to you. Let’s try something a little more practical and self-serving. Many of you are using Configuration Manager 2007 or testing Configuration Manager 2012. As part of that, you have installed the ConfigMgr console and connected to one or more ConfigMgr sites. When you refresh your own machine, you want those connections to be retained, because it’s too much trouble to have to type in a server name again.

So it’s the same basic exercise as before: Figure out where the ConfigMgr console stores that information (using ProcMon or even Bing searches), then build an XML manifest that says to migrate the data. Fortunately, I already know where ConfigMgr stores that (we use that information in MDT): it’s in the user’s registry. The exact path is different for ConfigMgr 2007 vs. 2012:

ConfigMgr 2012: HKCU\Software\Microsoft\ConfigMgr10\Admin UI\MRU

ConfigMgr 2007: HKCU\Software\Microsoft\ConfigMgr\AdminUI\MRU

So the manifest needs to specify that these registry keys (and all values and subkeys) get backed up and restored if they exist. Simple enough:

A few things to point out with this one:

There are two components defined in the same XML manifest. You can put as many components in the file as you want, so whether you want 20 small XML files or one larger one (as you define more application settings to capture) is entirely up to you.
Since these are user registry entries, the rules will be processed for each user that exists on the machine.

So what happens if the ConfigMgr 2007 console is installed in the old OS but not in the new OS? Will the settings be restored? Yes they will, as the detection rules are only used to determine on the source computer whether the component is present. (When it is detected, it will be put into a generated config.xml file too.)

Migrating application settings with USMT 4.0: Sample #1

Michael Niehaus — Wed, 24 Aug 2011 12:18:00 GMT

Out of the box, USMT 4.0 migrates settings for Windows, Office, and various other applications (typically current versions as of 2009), mostly consumer-focused. (See http://technet.microsoft.com/en-us/library/dd560792(WS.10).aspx for the full list.) So what if you want to migrate settings from additional applications? Well, then you need to author your own migration XML file.

First though, you need to figure out what application settings need to be migrated. Does the application store its settings in a file? In a registry key? Per user or per system? There’s no single right way to do this, so you have to do some investigative work to figure this out for each application. Tools like ProcMon from SysInternals can help with that, by capturing details of all registry and file accesses made by the process. But there can be lots of data captured, so finding the data can be somewhat time-consuming.

So let’s look at a real example using Angry Birds, which is available for download from http://download.angrybirds.com/. Install this on a computer, then start ProcMon and tell it to capture details from process name AngryBirds.exe:

Then launch Angry Birds and click on “Play” to see where you left off – at that point, you know it’s read the saved settings, wherever those came from. At that point, you can stop the capture and begin scanning the captured data. Usually I start at the bottom (most recent) and work my way up, looking for something “interesting”. (What is “interesting” can vary by app, but you will begin to notice patterns that applications follow so the more applications you do this with, the better you’ll get at it.)

From scanning the ProcMon output, I can see a few references to my user profile folder:

Those files (“highscores.lua” and “settings.lua”) sound promising, especially since I noticed that the settings are per user (log in as someone else and you have different progress displayed) and I don’t see any relevant HKCU registry access in the trace.

OK, so we know what we want to capture and restore. Now we have to figure out how. Using your favorite XML editor (I use Visual Studio), create a new XML file that looks like this:

A few things to point out:

The “urlid” value on the first line can be any URL – it just needs to be unique among all XML files being used (no duplicates). Make up whatever value you want, as it’s effectively just a text string, not used for anything beyond identification.
The component type can be either “Application” or “Documents”, depending on what you are capturing. It doesn’t really matter what you specify, as it just controls where the component shows up in the config.xml file (if you generate one). For Angry Birds, I specified “Application”. (If you specify an invalid value, USMT typically doesn’t complain – it does end up ignoring the component though.)
The context is very important. It should be “System” if you are capturing machine-level configuration, or “User” if you are capturing user-specific configuration. You can also specify “UserAndSystem” if you need to capture both. In the case of Angry Birds, we’ve already determined that it is using user settings, so that’s what we need to specify.
The remaining entries generally occur in this type of pattern:

A role node. The type can be “Data”, “Binaries”, “Settings” or “Data” – really just labels for you to use, as all values are treated the same.
One or more detection rules. In this case, we look for the existence of a folder to indicate that this rule should be processed.
A rules node that specifies whether these are “User” or “System” settings. (Typically this is the same as the component value, although it can be a subset, e.g. the component specified “UserAndSystem” while the rule specifies “User”.)
One or more include rules that specify what to migrate.
Potentially more optional elements, e.g. exclusions. See http://technet.microsoft.com/en-us/library/dd560769(WS.10).aspx for a description of all the possible XML elements.

So then lets look at the condition:

MigXmlHelper.DoesObjectExist("File","%CSIDL_APPDATA%\Rovio\Angry Birds")

This uses a helper function to determine if the specified directory exists. The “%CSIDL_APPDATA%” text is a reference to one of the many “environment variables” (listed at http://technet.microsoft.com/en-us/library/dd560744(WS.10).aspx) that can be used; the value will be substituted when evaluating the condition. Because this is a per-user rule, the condition will be checked for each user, with “%CSIDL_APPDATA%” pointing to the user profile’s roaming data folder (e.g. C:\Users\<userID>\AppData\Roaming on Windows 7).

The "include" rule specifies to capture all files and subfolders under the detected path. By default, these will be put back into the same location they were captured from, doing any necessarily translation for changes in %CSIDL_APPDATA% (e.g. drive letter changes).

That’s all there is to it – just tell Scanstate and Loadstate to use this new XML file and all of your Angry Birds progress will be preserved even through an OS refresh or replacement process.

Migrating offline files (CSC) using USMT 4.0

Michael Niehaus — Wed, 24 Aug 2011 11:14:58 GMT

One of the questions that came up after my TechEd New Zealand session on USMT 4.0 was whether USMT migrated the contents of the client-side cache (CSC) used for offline files. Well, it sounds like it “sort of” does – but by default, it only moves the “dirty” files (those not yet sync’d to the network location). That’s a decent default I suppose, as the remaining files can be pulled back from the network after the state is restored, and the modified files won’t be overwritten. So there’s no data loss (always a good thing), but there will be extra network traffic to pull the content down to the cache again.

The actual cache migration is performed by a plug-in to USMT, so the question is whether that plug-in can be influenced to capture everything, instead of just the “dirty” files. From http://support.microsoft.com/kb/942960, you can adjust the behavior by telling CSC you want to migrate everything. (While this article talks about MigWiz.exe, the Windows Easy Transfer Wizard, the underlying engine being used is basically the same as that used by USMT. So the end result of setting “MigrationParameters” should be the same.)

But before you say “great, let’s do it” you need to understand what’s going on behind the scenes. First, this CSC migration plug-in is called automatically by USMT as part of the Windows manifest processing. If you search through the Scanstate log you’ll see lots of references to it, with “CscMig” in the log entries. For example, here is an entry I saw on my computer for a “dirty” file (one that was created while the folder was offline, so USMT needs to capture it):

2011-08-24 22:53:43, Info [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item Created while offline (dirty).txt continueCtx = 00000000003DC480

But the rest of the files in that folder were skipped, as I didn’t have the MigrationParameters registry key set:

2011-08-24 22:53:43, Info [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractFile(653):Skipping item File1.txt because it is in sync with remote location. ItemStatus = 00050020

OK, great, we see what’s happening. But it’s also worth digging a little deeper and seeing what it did with that original file (something you can see from specify verbose logging, /v:5):

2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigGetWorkingDirectory(837):exit: workingDir = <\??\C:\Users\mniehaus\AppData\Local\Temp\tmp6865.tmp\Working\agentmgr\CCSIAgent\CSC>, status = 0x00000000 ( EE = 0 )
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item \\ continueCtx = 00000000003DAF00
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item bdddev continueCtx = 00000000003DB9A0
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item data$ continueCtx = 00000000003DC480
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item Created while offline (dirty).txt continueCtx = 00000000003DC480
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigWrite(446):exit: bytesWritten (743) at offset (0)
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractFile(974):Backup API file content till offset 743

So it used the Windows Backup API to make a backup of the “dirty” file in the CSC cache and placed that backup into a folder in my %TEMP% directory named “tmp6865.tmp\Working\agentmgr\CCSIAgent\CSC”. So even though I’ve specified to use hardlinks, there is data copying going on. In the end, this temporary folder created by CscMig is included in the hardlinked state store, but because these are different files (the backups) you will see twice the disk space consumed, so if you have lots of cached data you better have lots of free disk space to store the data. This isn’t so bad in the default configuration where it is only grabbing “dirty” files, but if you tell it to backup all files, then what happens?

No better way to find out what will happen than to try it. I made the MigrationParameters registry entry as described in the KB article mentioned above and repeated the Scanstate execution. (No service restart was required.) Upon checking the log, I can see now that each file in the CSC was backed up into the temporary folder. Where before it said “skipping item File1.txt”, now it says it’s backing it up:

2011-08-24 23:07:54, Info [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item File1.txt continueCtx = 000000000045C480

And like before all of these items get backed up into a temporary folder, then that temporary folder is hardlinked into the state store folder. So hardlinks or not, if you had 2GB worth of cached files, you’ll end up with those being doubled (temporarily, until the process is complete and the temporary folder and state store are cleaned up). It’s actually going to be tripled if you aren’t using hardlinks: first copy is the original file, second copy is the backup, third copy is contained in the compressed state store.

So that definitively answers the question of whether you can get USMT to migrate the complete contents of the client-side cache. It may not answer the question of whether you should do that, but hopefully the information is useful to help you make that determination yourself.

Troubleshooting the User State Migration Tool 4.0

Michael Niehaus — Wed, 24 Aug 2011 09:59:00 GMT

I gave a presentation today at the TechEd New Zealand conference on “Customizing the User State Migration Tool 4.0” – something I’ve talked with customers about back from my consulting days (way back when, probably with USMT 2.6 at that point – remember that one and its INF-style configuration files?), but haven’t presented in public for a very long time. Needless to say, it was somewhat nerve-wracking. For those in attendance, I hope it was worth your time. (I thought it was only OK. I’ll do better the next time.)

The next few blog postings will likely be related to USMT 4.0 – it’s always good to write about things that are freshly in your mind.

First off, I wanted to take the opportunity to pass along some of the troubleshooting items that I mentioned in the slide deck, consolidating various issues that you might run into while using USMT 4.0. Here they are:

USMT 4.0 isn’t migrating Office 2010 settings

Make sure you install the USMT 4.0 update that adds Office 2010 support. See http://blogs.technet.com/b/mniehaus/archive/2011/02/02/usmt-4-0-support-for-office-2010.aspx for more information.
http://support.microsoft.com/kb/2023591

USMT fails with some half-hour time zones

Install the USMT update for Office 2010 (see above), as it fixes this too.

Bad user profiles (usually a ProfileList registry entry that points to a non-existent folder) can cause state capture issues (delays, failures)

Clean them up or tell USMT to ignore them with MIG_IGNORE_PROFILE_MISSING=1
See http://blogs.technet.com/b/deploymentguys/archive/2010/03/28/usmt-failures-due-to-bad-profile-list-entries.aspx for a script that can help identify these and clean them up so that they don’t cause any issues.
See http://blogs.technet.com/b/askds/archive/2011/04/14/usmt-pauses-at-quot-starting-the-migration-process-quot-for-many-minutes-then-works.aspx for more details about the problem.
Setting MIG_IGNORE_PROFILE_MISSING is rather challenging in ConfigMgr (you can’t set it as a process environment variable because it goes away before the “Capture User State” step runs, so you need to set it as a system variable, reboot, and then capture state). See Michael Murgolo’s blog posting at http://blogs.technet.com/b/deploymentguys/archive/2011/08/03/setting-environment-variables-in-a-task-sequence.aspx for details on how to do this. (You could do a shorter way with MDT Lite Touch by modifying ZTIUserState.wsf to set the variable.)

OS settings don’t migrate with ConfigMgr

This happens because USMT can only find the “DLManifests” folder necessary to do OS setting migration in the working directory, and ConfigMgr doesn’t set the working directory to the location that contains this. See http://support.microsoft.com/kb/2018593 for more information.
MDT 2010 Update 1 includes a workaround for this problem, although the USMT 4.0 fix for Office 2010 (see above) breaks the workaround, requiring a script change (also described in the blog above).

USMT migrates user data from removable drives even with /localonly

It migrates USB disks even with /localonly, use an unconditional exclude to exclude undesired USB disks.
See Michael Murgolo’s blog posting at http://blogs.technet.com/b/deploymentguys/archive/2009/04/29/excluding-usb-firewire-and-other-drives-from-usmt-capture.aspx for a scripted approach of doing this (taking into account that the drive letters can be different on each system, so you might need a different exclude list for each PC).

Shortcuts to files on network drives don’t migrate

Known issue, you can modify MigUser.xml to remove section with IgnoreIrrelevantLinks (but then all links are retained, even invalid ones).

USMT doesn’t exclude the users that I want when I specify /UE and /UEL

These two parameters don’t work together the way you would expect them to, acting like an “or” instead of an “and”. See http://blogs.technet.com/b/askds/archive/2009/11/30/understanding-usmt-4-0-behavior-with-uel-and-ue.aspx for more information.

Any other good troubleshooting tips for USMT 4.0?

Deploying Office 2010 with Configuration Manager 2012 Beta 2

Michael Niehaus — Sat, 13 Aug 2011 20:17:37 GMT

The new application model in Configuration Manager 2012 will require administrators to study up on how best to deploy software – this isn’t anything like traditional software distribution like you would find in ConfigMgr 2007.

I recently set up Office 2010 as an application in ConfigMgr 2012 Beta 2. Here are the steps I used – not necessarily the only way to do it, but it worked for me.

Create the application

First you need to create a new application. If this were a simple MSI, you could just choose the MSI file and the whole process would be simpler. But Office 2010 is a little different than your typical application, so we need to manually define the information.

Specify general information

Now you need to specify some general identification and ownership information. This information is primarily for the ConfigMgr administrator’s use, as the end user can see different information in the software catalog.

Notice the “Allow this application to be installed from the Install Application Task Sequence Action without being manually deployment” checkbox. If you are planning to have MDT install this application dynamically in a task sequence (by specifying the application name in CustomSettings.ini, e.g. Applications001=Office 2010), you will need to check this box.

Specify how it should appear in the software catalog

ConfigMgr provides a software catalog, the Software Center, where end users can choose from optional applications (deployed as “available”, i.e. non-mandatory). You need to specify how the application should show up in the catalog – you can even specify different languages.

Add a new deployment type

The high-level “application” doesn’t say how to actually install the application. That’s done by one or more deployment types (similar in concept to the old package/program concept, where one package can have multiple programs, but in this case each deployment type can have different content – maybe one deployment type is an MSI install and another uses App-V).

Again, because Office 2010 isn’t a typical application, you need to manually specify the deployment type details.

Specify the deployment type details

You need to give the deployment type a name.

Specify install and uninstall details

Now you need to specify the source files, the installation command line, and the uninstall command line.

Since we are deploying Office, the install command line is pretty simple, just specify SETUP.EXE. This assumes that the package source contains an “Updates” folder with an MSP patch file that is configured to install Office without any user intervention.

The uninstall command line is a little harder to come up with – I just copied the command that Office placed in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS on a 64-bit computer). It isn’t very complicated, just specifying “SETUP.EXE /uninstall PROPLUS”. (I haven’t actually confirmed that this command line works, so test appropriately.)

Add a new detection rule

ConfigMgr 2012 will automatically reinstall an application targeted to a computer if it detects that it is no longer present. In order for this to work, you need to specify a detection rule so that ConfigMgr can figure out if it is still installed.

First add a new detection MSI detection rule. In the case of Office 2010, you can check for the present of any of the MSIs that are installed by the Office Setup program. I usually pick the one for the main product, Office Professional Plus, as that uniquely identifies the specific Office SKU that is installed. You browse to the “proplusww.msi” file in the “ProPlus.WW” folder so that you don’t need to type in the MSI product GUID.

Specify user experience settings

Typically you want to install Office in the system content and whether or not a user is logged on (both are mandatory settings for the task sequence to install the application). Neither of these settings are defaults, so be sure to change them:

There are a few more screens, but you can take the defaults for each of them.

Now you have successfully created the application, but you aren’t done yet.

Distribute content

The source files specified on the deployment type still need to be distributed to your distribution points. (You don’t need to do each deployment type separately, just once for the application.) There are different options you can choose for distributing the content. In my case, I’ll just keep it simple and distribute it to every one of my distribution points (one of them):

Deploy

At this point, you are ready to deploy. You don’t choose to deploy a specific deployment type. Instead, you deploy the application itself. It’s pretty simple in this case, with only one deployment type, as it’s fairly obvious which one will be installed. But if you had multiple deployment types, you would need to specify rules to determine which one is used.

There’s no doubt that this will take ConfigMgr administrators some time to get used to – just one of the big changes coming in ConfigMgr 2012.g

MDT 2012 Beta 1: Cross-Platform Deployment

Michael Niehaus — Sat, 11 Jun 2011 05:55:53 GMT

Those of you who deploy both x86 and x64 versions of Windows 7 using MDT 2010 Lite Touch probably know that you have to use two different boot images to do it: When booted from a Lite Touch x86 boot image, you only see task sequences associated with x86 operating systems; when booted from a Lite Touch x64 boot image, you only see task sequences associated with x64 operating systems.

With MDT 2012 Beta 1, that’s been changed. Now, if you boot from a Lite Touch x86 boot image you will see all task sequences, whether x86 or x64.

But there is one “gotcha”: If you choose a task sequence that deploys an x64 OS, MDT will need to find a copy of the corresponding x86 setup files and it will then use those to install the x64 OS. So you need to make sure that you have x86 setup files in the deployment share (with one of the operating systems), even if you aren’t deploying that operating system. It needs to match the version (e.g. 6.1.7601.17514) of the x64 OS that you are deploying. (This is the really the same as if you were deploying a custom image. Now, we just make sure we pick a copy of setup files that match the Windows PE platform being used, ignoring those that don’t, even if they are provided with the OS being deployed.)

The other combination, booting from an x64 boot image and deploying an x86 OS, isn’t supported by Windows Setup, so we still hide x86 task sequences when you have booted into an x64 boot image.

MDT 2012 Beta 1: UEFI Support

Michael Niehaus — Sat, 11 Jun 2011 05:39:20 GMT

One of the new features that has been added to Lite Touch Installation in MDT 2012 Beta 1 is support for deploying 64-bit Windows to machines configured to use UEFI. So what exactly does that mean? That’s no simple question.

What is UEFI?

The “Unified Extensible Firmware Interface” (UEFI) specification, created by an industry consortium that includes many influential companies from the PC industry, including Intel, AMD, Apple, Microsoft, Lenovo, Hewlett-Packard, Dell, IBM, American Megatrends, Phoenix Technologies, and Insyde. What common interest do those companies have? They either make firmware for PCs, create operating systems for PCs, or use firmware and operating systems on PCs.

Today, most computers use firmware called the BIOS, the “basic input output system”. This has been around since the original IBM PC. Although hardware has advanced quite a bit, today’s BIOSes still have some serious limitations, including:

16-bit code (where most OSes are now 32-bit or 64-bit)
1MB of addressable memory (regardless of how much the computer actually has)
Slower option ROM initialization
2.2TB boot disk limitation (an MBR limitation)

UEFI addresses all of these, so it’s only a matter of time before these “legacy BIOSes” make way for UEFI replacements. In fact, many computers have already move to UEFI, including all the latest laptops from Dell, HP, and Lenovo, most Dell and IBM servers, etc. But if these computers (which many of you are probably using today) already have moved to UEFI, how are they still working? Simple, they include a “compatibility support module” (CSM) that enables UEFI firmware to emulate a “legacy BIOS”. With this in place, the operating system can’t even tell the computer supports UEFI.

On most of the UEFI-enabled computers shipping today, “native” UEFI (running without the CSM) is disabled through the configuration of the machine, so you typically need to turn it on in order to get the choice to install using “native” UEFI or “legacy” BIOS emulation.

To make matters a little more confusing, you’ll see references to “UEFI BIOSes” and “BIOS configuration” even with UEFI-enabled computers. It’s not really a “BIOS” any more, but since everyone is used to calling it that, it is bound to happen.

What benefits do you get from UEFI?

As you can probably gather from the list of limitations above, UEFI is designed to eliminate the limitations of today’s “legacy” BIOS. It provides:

Full memory access (32-bit or 64-bit)
CPU independence (enabling UEFI on x86, x64, ia64, and even ARM computers)
Faster initialization
Support for larger boot disks (larger than 2.2TB)

From a Windows perspective, there are some specific benefits that result:

Faster initial boot times, because the operating system can use large IOs to read the operating system files (instead of using the 16-bit Int13 interrupts)
Faster resume from hibernate (since it can read data faster from the hibernation file, again because of large IOs instead of Int13 calls)
Multicast boot, because WDS can send down processor-independent UEFI bytecode to be executed to perform the multicast receiving (although this does require that the UEFI implementation in the PCs supports PXE for the NICs, many don’t currently support this)

As we move forward, you will likely see more UEFI-only Windows features. Also, don’t be surprised if some future PCs are UEFI-only, providing no BIOS compatibility model at all – once that happens, you must use “native” UEFI.

One additional note: Today, Windows only supports UEFI for 64-bit installations of Windows Vista SP1, Windows 7, Windows Server 2008, and Windows Server 2008 R2. 32-bit installs, and older OSes, must continue to use the “legacy” BIOS support.

What is different about the UEFI deployment process?

There are a few differences that need to be taken into account to deploy Windows to a computer running “native” UEFI. First, there is a different disk layout, shifting from the master boot record (MBR) structure to the new GUID partition table (GPT) structure. GPT supports much larger boot volumes (up to 9.4 zettabytes, or 9.4 billion terabytes) and up to 128 partitions (whereas MBR had a limit of 4).

Next, there is also a different recommended disk layout, as described at http://technet.microsoft.com/en-us/library/dd744301(WS.10).aspx, that involves three partitions:

The “EFI System Partition” (ESP) is roughly equivalent to the small boot partition typically used with Windows 7 today, holding the boot files needed to “bootstrap” the loading of the operating system. Interestingly enough, this partition is formatted as a FAT32 volume because that’s required by UEFI – it can’t read NTFS-formatted volumes. What would you expect to find on this partition? Think of it like the old OEM partitions: It can contain boot loaders (like the ones used to load Windows), OEM firmware utilities, etc. But instead of each OEM using a different setup, all can share this volume. (There are even specific subdirectories that each vendor has agreed to use, see http://www.uefi.org/specs/esp_registry.) There are even “EFI shells” that can be loaded onto this partition (for configuration, browsing, or whatever other creative uses you might find).

There is one thing that you won’t find on the EFI System Partition: a BCD file. When booting from a “legacy” BIOS, the Windows boot loader (bootldr) reads the boot configuration data from the \BOOT\BCD file on the active partition, but with UEFI that information is stored in and read from non-volatile RAM (NVRAM) on the motherboard. The same BCDEDIT.EXE utility that is used to manipulate the BCD file also knows how to manipulate the NVRAM – not surprisingly as the BCD structure was built in anticipation of UEFI.

The next partition, the Microsoft Reserved (MSR) partition, reserves some disk space for Windows to use for certain operations (e.g. converting a basic disk to a dynamic disk).

Overall, these partitions are fairly small, with the ESP at 100MB and the MSR partition at 128MB, so there isn’t much overhead here.

The next challenge then involves bootable CDs and DVDs. Today, you would typically set up an ISO using the El Torito specification, specifying the ETFSBOOT.COM boot sector for the “legacy” BIOS to call to initiate the CD/DVD boot process. With UEFI, there is a new boot sector called EFISYS.BIN. This isn’t an “either-or” proposition though, as you can actually configure a bootable CD or DVD to have both ETFSBOOT.COM and EFISYS.BIN at the same time. (See http://support.microsoft.com/kb/947024 for an example of the OSCDIMG command line syntax to do that.) If the computer supports UEFI and “native” UEFI is enabled, then it will typically choose the UEFI boot sector by default (or prompt and ask which one you want to use), while computers that don’t support UEFI or those that don’t have “native” UEFI enabled will revert to the ETFSBOOT.COM “legacy” boot sector.

The final challenge then is USB media. As with CDs and DVDs, you probably want them to support both “legacy” BIOS and UEFI booting. This is pretty simple to do, formatting the USB media using FAT32 (so it can be read by UEFI) and setting up both “legacy” BIOS and UEFI boot files.

One other complication to mention: What if you have a computer that supports UEFI, but it is currently running an operating system (e.g. Windows XP or Windows 7) through the legacy BIOS compatibility module (CSM), and you want to move it to UEFI. Can you perform a typical “refresh” operation? No, because the “refresh” process can’t even see that the machine supports UEFI when running in compatibility mode, plus there is no way to convert an MBR disk to a GPT disk while preserving the data. So in order to do this type of migration, you need to move the user data off of the disk, then boot from UEFI-enabled media, reformat the disk as GPT, install the new OS, and then restore the user data.

It’s also worth noting that you may need to upgrade any imaging or disk partitioning tools that you are using today to versions that understand GPT disk structures. (This isn’t an issue with Windows AIK and ImageX, as ImageX uses file-based images that don’t care about MBR vs. GPT.)

What about MDT 2012?

All of that background information and we still haven’t really talked about what MDT 2012 does in regards to UEFI. So let’s quickly review what MDT 2012 does to enable UEFI support:

MDT will build all ISOs and media folders with both “legacy” BIOS and UEFI boot files. (It’s up to you to make sure you copy the media content to USB devices that are formatted as FAT32, if you expected UEFI to be able to read them.)
MDT will build all ISOs with dual “legacy” BIOS and UEFI boot sectors.
MDT is able to detect when a computer is running in “native” UEFI mode (see the “IsUEFI” property – it’s set to false when running in “legacy” BIOS compatibility mode, true if in “native” UEFI mode).
MDT will automatically format the boot disk using GPT (even if the task sequence says MBR) so that you can use the same task sequences with both “legacy” BIOS and UEFI computers.
MDT will automatically create the needed ESP and MSR partitions when running in “native” UEFI mode.
MDT can refresh a computer running an OS in “native” UEFI mode to a new OS in “native UEFI” mode (but not “legacy” to “native” or “native” to “legacy”).

In the end, that means that this becomes sort of a “ho-hum” exercise: It should just work, as soon as you figure out how to enable UEFI “native” mode in the firmware (BIOS) settings and then boot in “native” mode. That’s not always as simple as it seems, as the UEFI firmware available today isn’t terribly obvious. (I’ve tried it with Dell and HP laptops. The Dell machine isn’t too hard to figure out, but getting the HP to boot in “native” mode is a little more challenging. See below for more details.)

Can you really tell the difference?

Some computers will benefit more from UEFI than others, due to the specific hardware, the UEFI firmware being used, etc. So I’ve run a few timings with an HP EliteBook 8440p laptop to illustrate the differences on a typical machine. First, let’s compare the Windows PE boot time, reading the same boot image from a USB key using “legacy” and “native” boot options (stopping the timer once the initial MDT wizard is displayed):

Legacy boot: 50 seconds (to initial MDT wizard)
Native boot: 40 seconds (to initial MDT wizard)

The next test then is operating system installation (measuring how long from finishing the MDT deployment wizard until the summary wizard appears in Windows 7 SP1 x64):

Legacy boot: 14 minutes, 40 seconds
Native boot: 13 minutes, 55 seconds

(Note that both of these times should be one minute shorter, but due to a bug in the task sequencing engine there is an extra minute of “nothing going on” added to the end of the deployment process, before the summary wizard is displayed. We’re still working to get that fixed.)

Now let’s compare the “cold boot” time (from powered off to the logon prompt appearing):

Legacy boot: 30 seconds
Native Boot: 27 seconds

And finally, time to resume from hibernate (with no applications running, from powered off to the lock screen appearing):

Legacy boot: 17 seconds
Native boot: 14 seconds

So it’s not a huge difference, at least with the current UEFI revision on this machine, the USB key performance, and the SATA (non-SSD) hard drive in the system. Imagine though if you were using an SSD…

Caveat Lector

It was interesting using UEFI on the HP EliteBook 8440p, not nearly as “refined” as I would have expected. First, when you enable UEFI in the BIOS, you get an interesting warning:

The “UEFI Boot” option on this system is provided for development purposes only and is currently NOT fully supported or warranted by HP. Preboot Authentication and Drive Lock are currently NOT supported under UEFI Boot mode. HP strongly recommends disabling Preboot Authentication and Drive Lock before enabling UEFI boot on this system.

Then (ignoring the warning), the UEFI firmware doesn’t seem to be able to detect UEFI-bootable USB keys, so you have to browse to the “bootx64.efi” file on the USB key and explicitly tell the machine to boot from that.

You would think that this “temporary boot choice” would only apply for this single boot (so that when the computer reboots after Windows is installed it will boot from the hard drive), but that’s not the case: It keeps booting from the USB key if you leave it inserted. So I’ve gotten used to pulling the USB key every time the computer reboots, then reinserting it before MDT wants it back so it doesn’t pause and prompt.

And as mentioned previously, there is no UEFI PXE support provided on this computer. (I hope it will work as expected with a dual-boot CD/DVD, offering a choice, but I didn’t have one handy to try.)

I have previously tried this on a Dell Latitude E6410 laptop, which seems to be a little better behaved (although it doesn’t seem to support UEFI PXE boot either). Your mileage may vary, based on computer manufacturer and model, UEFI firmware version, etc.

ConfigMgr 2007 Driver Management Revisited (Again)

Michael Niehaus — Fri, 10 Jun 2011 20:41:37 GMT

After MMS 2010, I had posted a series of blog postings talking about different mechanisms for managing drivers with ConfigMgr 2007. You can read through that at http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx.

Then a hotfix was released that changed the way ConfigMgr 2007 handled duplicate drivers when importing. I talked about that in the post at http://blogs.technet.com/b/mniehaus/archive/2010/10/15/configmgr-driver-management-a-new-development.aspx. One point called out in that posting: driver categories would be overwritten when a duplicate driver was imported specifying a different category. That made the “Added Predictability” model described in the first posting very difficult to implement (without using something like the PowerShell script I posted in the first series).

Now, there is a new development: Another hotfix that affects driver importing:

Category is incorrectly overwritten when you import the same driver on to a System Center Configuration Manager 2007 SP2 site server
http://support.microsoft.com/kb/2513499

From the title, you can probably guess what it fixes: Now, when importing duplicate drivers, if you specify a different category, it will be added to the list of categories instead of overwriting the list that is already there. As a result, the “Added Predictability” model is fairly simple to implement (without the need for scripting). Look at this basic scenario:

Download all the drivers for a Dell Latitude E6410 and import those, specifying a category of “Latitude E6410”.
Download all the drivers for a Dell Latitude E6510 and import those, specifying a category of “Latitude E6510”.

Without the hotfix, all the common drivers would end up with a category of “Latitude E6510”. With the hotfix, they would have both categories specified.

MDT 2010 and Windows AIK Supplement Revisited

Michael Niehaus — Thu, 09 Jun 2011 03:30:00 GMT

In my previous post titled Issue with MDT 2010 Update 1 and Windows AIK for Windows 7 SP1 Supplement, I mentioned some challenges if you wanted to use Windows PE 3.1 and still use Windows RE from a Windows 7 SP1 BOOT.WIM file. One possibility proposed for dealing with this is to manually modify the Windows AIK version so that MDT knows a new version has been installed. That sounds easy enough, renaming HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ComponentStudio\6.1.7600.16385 to instead be HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ComponentStudio\6.1.7601.17514.

I did try this out, and encountered two issues to note:

Deployment Workbench doesn’t really like the change. After changing this key, you’ll get warnings from Deployment Workbench saying that the version of WIMGAPI (6.1.7600.16386) is different than the version of Windows AIK (6.1.7601.17514). There’s no workaround for this – you would just need to live with the annoyance of the warning, which will be displayed any time Deployment Workbench needs to use Windows AIK components.
The Windows AIK team can’t support the change, primarily because it’s not something they have tested to see if there are any other unexpected side effects.

So while the workaround of editing the registry key may work, we can’t really recommend it.

For a longer-term solution, we have modified the Deployment Workbench code in MDT 2012 Beta 1 (see http://blogs.technet.com/b/msdeployment/archive/2011/06/01/microsoft-deployment-toolkit-2012-beta-1-now-available.aspx if you missed that announcement) so that it checks the version of the Windows AIK WINPE.WIM file, rather than checking the Windows AIK version in the registry. As a result, MDT 2012’s behavior is:

Windows PE 3.0 WINPE.WIM present in the Windows AIK folder and Windows 7 RTM or Server 2008 R2 RTM source files in the deployment share? MDT will create a boot image from the Windows 7 RTM BOOT.WIM and it will include Windows RE.
Windows PE 3.1 WINPE.WIM present in the Windows AIK folder and Windows 7 SP1 or Server 2008 R2 SP1 source files in the deployment share? MDT will create a boot image from the Windows 7 SP1 BOOT.WIM and it will include Windows RE.
Any other combination? MDT will create a boot image from the Windows AIK WINPE.WIM file and it won’t contain Windows RE.

Creating a fully-patched image using MDT 2010 Lite Touch

Michael Niehaus — Mon, 16 May 2011 21:10:24 GMT

I’ve always been a fan of the thinnest image possible. Taking that to an extreme, that means using the original image straight off the Microsoft media. But over time if you did this you’d find that the time required to apply patches to that image becomes unmanageable. (Case in point: I started up a new laptop for the first time with an OEM-installed image that had hooks to require all patches be applied before first logon. It took three hours for that to happen.)

I’ve also been a fan of doing “just in time” patching, which is something that MDT can do too: Instead of patching the image in advance, you can inject updates offline after the image has been applied to the disk but before it boots for the first time. That does often improve the time required, but it doesn’t eliminate it – it adds time when initially injecting the updates offline, and then more time on first boot as the “online actions” for those “offline patches” are completed (you’ll see the messages on the screen during the first boot showing a percentage complete while this is happening).

So reading between the lines, that means I would suggest always creating your own master image containing at least all the current service packs and patches. (Don’t try to install the OS service pack yourself – just download “slipstreamed” media from the Microsoft licensing website, as that’s the ultimate time-saving technique.) So how should you do this? Well, there are a few ways:

Mount the existing WIM image and just inject the updates offline with DISM. This is certainly doable, but there are three challenges:

The online actions for these updates will still take some time
It introduces a “human touch” into the process, unless you go through the effort of automating this to make it a repeatable process.
It only works for operating system updates.

Build a new image and install all the updates into that image before sysprepping and capturing the image using a completely automated process. This is my preferred approach, because it’s a consistent process for any other type of update being made to the image.

Not surprisingly, MDT 2010 Lite Touch provides a way to implement my preferred method above – and actually multiple methods that can be used. Let’s go through those methods.

Install all updates from Microsoft Update directly

This is the easy way, as long as you have good internet bandwidth (all updates are downloaded from the internet) and a direct path to these downloads (as we don’t really support proxy servers in the MDT task sequence), and always want to install all critical updates. (We skip language packs, drivers, and service packs by default, and you can exclude additional updates, but the exclusion process requires a little work.)

To use this method, all you need to do is search your task sequence for the following steps:

Windows Update (Pre-Application Installation)
Windows Update (Post-Application Installation)

Enable both of them, and then build a new image – that’s all there is to it. (Why are there two steps you ask? Well, the first might be required in order for the subsequent application installs to complete; the second might be required to patch the applications, e.g. Office, after it’s installed. If the second step doesn’t need to install any additional patches, it won’t take very long.)

Install all updates approved on your WSUS server

To give you better control over patched put into your image, you may only want to install approved updates. If you are using Windows Server Update Services (WSUS), then you already have such an approval mechanism in place, all you need to do is tell the task sequence to talk to WSUS instead of going to the internet. This is pretty simple too:

Enable the same “Windows Update” task sequence steps listed in the previous section (two of them).
Add an entry into the [Default] section of CustomSettings.ini that says:
WsusServer=http://SERVERNAME:PORT
where “SERVERNAME” is the fully-qualified name of your WSUS server and “PORT” is the port number that WSUS was configured to use (only needed if that is something other than port 80).

Make sure that you have configured WSUS to install updates on unknown computers, because when building a reference computer it is indeed unknown to WSUS at the point the task sequence is executing.

Download all updates and import into your deployment share

This one is probably the most work, primarily because you need to manually download all the updates that you want to install, and it only works for OS updates (as they are the only ones that can be injected offline). The steps required:

From the monthly security bulletin, or using a site such as http://catalog.update.microsoft.com, download all the updates which are typically packaged as MSU files. (If they come down as executables, you’ll need to extract the MSU files from the executable.)
Import the MSU files into Deployment Workbench from the “OS Packages” node. (This will extract a CAB file that is contained in the MSU file, since that’s the piece that gets installed offline.)

When the task sequence runs, the “Apply Patches” will identify all the updates for the OS and platform being deployed, download them to the client, and update the unattend.xml to inject them. (SETUP.EXE will later call DISM.EXE to do the actual injection after the image has been extracted and applied to the hard drive.) If you want to apply a particular set of patches, you can configure a selection profile with one or more folders containing those updates, then configure the “Apply Patches” step to use that selection profile.

How often should I do this, and what should I do in between?

Well, that’s a completely different discussion. Some people do a new image monthly (and probably don’t do much testing on that image each time they recreate it). Some do it every few months. Some do it once a year. You just need to balance the efforts required to build it (easy), test it (not quite so easy), and distribute it (can be really painful) against the added time of applying some updates later.

You can actually use any (or all) of the above methods in that “later” deployment task sequence too:

Enable the “Windows Update” steps in the deployment task sequence to download and install any updates released since the last image was created (from Microsoft Update or from WSUS if you set the WsusServer variable).
Download and import any new MSU files into Workbench (but keep these separate from all the ones in the image as MDT won’t know which are installed and which aren’t so it will download all of them and let DISM figure it out).

For more information

Some additional links that might be useful:

Windows Update in MDT 2010 « Xtreme Deployment

Approving Windows Updates in an MDT 2010 Standalone Environment

Got orphaned collections in ConfigMgr?

Michael Niehaus — Thu, 21 Apr 2011 08:35:05 GMT

This one goes back several years to when I was routinely writing code that used the ConfigMgr SDK (although in an odd coincidence, I was writing such code again yesterday). It was pretty easy to run some buggy code that didn’t quite do what was intended, and as a result ConfigMgr might be left in an odd state.

One example of this: orphaned collections. These exist in ConfigMgr, and if you look via WMI you can see them. But they don’t exist in the console anywhere – they are invisible. This would happen because those collections were not “rooted” to the top-level collection called “COLLROOT” (or any other collection, if you build collection hierarchies).

Other than “buggy code”, how else could these orphaned collections happen? Good question, hard to say.

So how do you fix these? Well, simple: You “re-root” them by creating a new SMS_CollectToSubCollect WMI instance that says “this collection is a subcollection of COLLROOT”. A long time ago, I wrote a script to do this. After enough digging around, I found it again, so I’ll provide it here:

Set services = Getobject("winmgmts://YOURSERVER/root/sms/site_XXX")

' Just in case we need to re-root a collection, get the class instance
Set theClass = services.Get("SMS_CollectToSubCollect")

' Get a list of collections. Make sure each one has a parent. If not, connect it to COLLROOT.
Set collList = services.ExecQuery("select * from SMS_Collection where CollectionID <> 'COLLROOT' ")
For each c in collList

    ' WScript.Echo "Checking " & c.CollectionID

    ' See if this collection is already associated with the root collection. If not, fix it.
    Set result = services.ExecQuery("select * from SMS_CollectToSubCollect where subCollectionID = """ & c.CollectionID & """")
    If result.Count = 0 Then
        WScript.Echo "No parent found for " & c.CollectionID

        Set theRelationship = theClass.SpawnInstance_()
        theRelationship.parentCollectionID = "COLLROOT"
        theRelationship.subCollectionID = c.CollectionID
        Set path = theRelationship.Put_
        Set path = Nothing
        Set theRelationship = Nothing

    WScript.Echo "Added " & c.CollectionID & " (" & c.Name & ") to the root collection"

    End If
    Set result = Nothing

Next

Paste this into a text file, change the server name (from “YOURSERVER”) and site code (from “XXX”), save it as “ReRoot.vbs”, and run it using “cscript.exe ReRoot.vbs”. It will check every collection, and if it finds one that is orphaned, it will “re-root” it to to the root collection, telling you what collection (ID and name) was fixed. After the script is finished, you can find the “re-rooted” collections in the admin console, and you can decide what to do with them from there.

Michael Niehaus' Windows and Office deployment ramblings

Troubleshooting MDT 2012 Monitoring

What does the checkbox do?

What if the service doesn’t start?

Verifying the Monitoring Service

From the Client Side

From Workbench

Finally

Trying to install ConfigMgr 2012 RTM? Make sure you have the right SQL…

Inside a Task Sequence

Some Explanation

Some Instructions

Some Caveats

Finally

Have you tried the Application Approval Workflow solution accelerator?

MDT 2012 New Feature: Monitoring

MDT 2012 New Feature: Item Sorting

Trying to install ConfigMgr 2012 RC2? Make sure you have the right SQL…

Customizing Wizards with MDT 2012

Creating the ConfigMgr “System Management” Container with PowerShell

MDT 2012 New Feature: Gather improvements

MDT 2012 New Feature: DaRT integration

Enable DaRT support

Q: How do I get DaRT?

Q: How does monitoring help with this?

Q: Can this be done with Configuration Manager too?

SCCM Guru webcast coming up soon

Inside a ConfigMgr 2012 OS Deployment Task Sequence

Windows Thin PC: Another flavor of Windows 7

Can I run applications on WinTPC?

Hyper-V on Windows 8 Client!

Migrating application settings with USMT 4.0: Sample #2

Migrating application settings with USMT 4.0: Sample #1

Migrating offline files (CSC) using USMT 4.0

Troubleshooting the User State Migration Tool 4.0

Deploying Office 2010 with Configuration Manager 2012 Beta 2

Create the application

Specify general information

Specify how it should appear in the software catalog

Add a new deployment type

Specify the deployment type details

Specify install and uninstall details

Add a new detection rule

Specify user experience settings

Distribute content

Deploy

MDT 2012 Beta 1: Cross-Platform Deployment

MDT 2012 Beta 1: UEFI Support

What is UEFI?

What benefits do you get from UEFI?

What is different about the UEFI deployment process?

What about MDT 2012?

Can you really tell the difference?

Caveat Lector

ConfigMgr 2007 Driver Management Revisited (Again)

Category is incorrectly overwritten when you import the same driver on to a System Center Configuration Manager 2007 SP2 site server http://support.microsoft.com/kb/2513499

MDT 2010 and Windows AIK Supplement Revisited

Creating a fully-patched image using MDT 2010 Lite Touch

Install all updates from Microsoft Update directly

Install all updates approved on your WSUS server

Download all updates and import into your deployment share

How often should I do this, and what should I do in between?

For more information

Got orphaned collections in ConfigMgr?

Category is incorrectly overwritten when you import the same driver on to a System Center Configuration Manager 2007 SP2 site server
http://support.microsoft.com/kb/2513499