Michael Niehaus' Windows and Office deployment ramblings

User groups in the Seattle area

Michael Niehaus — Tue, 06 Nov 2012 00:30:11 GMT

You would expect that having Microsoft in the Seattle area would result in having a plethora of Microsoft-related users groups around. But over the years, I’ve found that these are somewhat hard to find. So here’s my compilation:

Seattle IT Pro User's Group. This group talks about all sorts of IT pro-related topics, including Windows 8, Windows Server 2012, Windows Azure, System Center, Office, SharePoint, etc. – pretty much anything that an IT pro would care about. They meet the first Wednesday of every month in Bellevue at the Lincoln Square Microsoft office. As long as I’m in town, I try to make it to this meeting. There is a meeting coming up on Wednesday of this week (November 7th) at 6pm – there will be copies of Windows 8 Pro to be given away and free food provided, so RSVP now using the hyperlink above.
Northwest System Center User’s Group. This group meets every other month at the Microsoft Civica office in Bellevue to talk about System Center products, and there is ample participation from the System Center product groups (including Wally Mead). I usually try to make it to this one too. The next meeting is coming up on November 9th, so sign up now via the LinkedIn hyperlink above.
Pacific Northwest SQL Server User’s Group. This group meets every second Wednesday of the month, usually on the main Microsoft campus, to talk about topics related to SQL Server. By my calculation that means there is a meeting coming up next week, for those interested in SQL Server, so keep checking their web site for details.
Puget Sound SharePoint User’s Group. This group meets monthly at the Microsoft Civica office in Bellevue to talk about SharePoint. The next meeting is coming up on November 15th, from 6-8:30pm.

I’m sure there are more groups out there that I haven’t heard about, so let me know if there are more that I should add to this list.

Using boot from VHD and differencing disks

Michael Niehaus — Thu, 01 Nov 2012 02:48:00 GMT

MDT 2012 includes a task sequence for deploying an operating system into a VHD, setting up the computer for booting from that VHD. See my previous blog posting about Deploy to VHD for more details on that. As I mentioned in that blog, setting up a differencing disk to be created during the “Deploy to VHD” task sequence doesn’t make sense, as the parent VHD would be empty. But it would be useful to be able to do it later, so that you have the already installed and configured OS in the main VHD, and then one or more differencing disks set up with that VHD as the parent.

So how do you actually do that? The basic steps would be:

Boot into Windows PE. (You can’t create a differencing disk off of a parent VHD if that VHD is currently open, as it would be when boot from the VHD.)
Use DISKPART to create a new differencing disk with the existing VHD as the parent.
Create a new BCD entry for the differencing disk.

To help with that process, I created a new script called Diff.wsf, attached below, that will perform all of those steps. Set up a new custom task sequence in your MDT deployment share that has a single step in it that runs the script like so:

Then reboot into your MDT Lite Touch boot image (either from media or from PXE) and run this task sequence. The command line parameters above tell it what to do:

/CREATE specifies to create a new differencing disk.
/CLEAN specifies to remove any existing differencing disks that might be present.
/STAGE says to copy the Diff.wsf and all related scripts locally onto the disk, in the same folder as the parent VHD file.

The task sequence completes while in Windows PE, and as soon as you click finish on the summary wizard page, the computer will reboot into the new differencing disk, causing all changes to be written into the diff file while the parent VHD remains unchanged (and effectively read-only).

After that initial differencing disk has been created, the locally-staged script can be run directly without even using a task sequence. Assuming that the drive letter assigned to the physical disk containing the parent VHD (and the differencing disks) is D:, then the script will be located at D:\VHD\Scripts\Diff.wsf. When you run it from there (initiated from within the currently-running OS), you can specify any of the parameters described above, or you can leave off the parameters and the script will prompt.

Note that the script can’t actually delete the differencing disk that is presently in use because, well, it’s currently in use. But it can remove the BCD entry for it, and after a reboot it can then be deleted. So the script will also take care of cleaning up any “orphaned” differencing disks it finds laying around.

A few final comments on scenarios for running Diff.wsf from within the currently-running OS:

If you specify /CLEAN without /CREATE, it will remove all the differencing disks and boot back into the main VHD file. This is useful if you want to update (e.g. patch) the installed OS.
If you specify /CREATE without /CLEAN, you’ll get another differencing disk and another BCD entry – so if you really want to, you can boot between different differencing disks.

More experimenting with RAMdisks: Using a VM completely in RAM

Michael Niehaus — Thu, 18 Oct 2012 07:51:06 GMT

In my previous post, I talked about using a small RAMdisk to speed up the process of generating MDT boot images. But the trial version only supports RAMdisks up to 4GB in size and only on client OSes. One comment posted to that blog pointed out that StarWind also has a free RAMdisk available, and it supports larger RAMdisks and server OSes. See http://www.starwindsoftware.com/high-performance-ram-disk-emulator for more information. (Again, I’m not recommending it, just pointing out its existence. Registration is required to download.)

This let me test out another scenario: Creating a RAMdisk large enough to hold an entire virtual machine, then seeing how much faster Windows can be deployed into such a virtual machine. Fortunately, I have a workstation-class machine with enough RAM to do something like that. I created a 20GB RAMdisk, formatted it as NTFS, then created a new VM where the VHDX file (using Windows Server 2012) was on the RAMdisk.

Using a physical disk array (attached to an Intel RAID controller) on the same system, I can deploy Windows 8 in about 10 minutes (new computer, clean install, no apps, no updates, etc.). So how much faster is the RAMdisk? On my machine, it took about eight minutes – noticeable, shaving 20% off of the time, but not as fast as I would have hoped. That’s another case of shifting the bottleneck: the image is pulled across the (virtual) network, read from a physical disk (VHD), consumes CPU, etc. Now if I only had enough RAM to load my entire server VHD into a RAMdisk to see what that does. Last time I checked, the server required about a terabyte of disk space, so going that far is not possible.

But I can do the next best thing: Create an MDT media ISO, copy that into the RAMdisk, and do a deployment using that instead of over the network. How long did take? About 7 minutes and 30 seconds. Sigh, 30 seconds saved.

One more test: Give the VM more CPUs. Instead of the default single core, I increased it to four cores and tried again. This time, the deployment completed in 6 minutes and 30 seconds. Another minute shaved off. (Don’t have lots of RAM? Well, you probably have more than one CPU in your Hyper-V server, use it when building images.)

So that’s up to a 35% improvement in performance – good overall, but not quite the fantastic results I was hoping for. Ah well, it was worth a try…

Experimenting with a RAMdisk

Michael Niehaus — Sat, 13 Oct 2012 06:49:30 GMT

One of the slow operations in the MDT Deployment Workbench is the initial “Update deployment share” process that has to completely generate new Lite Touch boot images. I always assumed that this was slow due to the amount of I/O being generated by the update process.

Recently, ATI and Dataram released a trial version of their RAMdisk software at http://www.radeonramdisk.com (not that I am endorsing the product – it just happened to come through my Twitter feed and it works on Windows 8), so I had a chance to test the assumption: What would happen if the temporary storage used by MDT to generate the boot images would be on a RAMdisk?

So I installed the software on my laptop, created a 2GB RAMdisk, and formatted it as an NTFS disk. First, I “completely regenerated” the MDT boot images without using the RAMdisk. That process finished in six minutes and 15 seconds (6:15). Then, to get it to use the RAMdisk, I did the following:

Start an elevated command prompt.
Set TMP and TEMP to point to the RAMdisk (E:\ in my case).
Run “mmc.exe DeploymentWorkbench.msc” from the elevated command prompt, so it inherits the TMP and TEMP environment variable settings.
“Completely regenerate” the MDT boot images again.

That looks sort of like this:

So what difference did it make? Well, instead of 6:15, the whole process finished in 4:55. Not too shabby, about 20% faster, but I expected more. So why wasn’t it any faster? Well, it turns out it’s just a case of shifting the bottleneck. Watching the process using ProcMon and the Windows 8 task manager, I could see that the process was CPU-bound; the RAMdisk utilization was negligible. Hmm, I guess it’s time for a faster CPU…

The trial software doesn’t support server OSes or more than 4GB of RAM; you have to purchase the full version for that. Maybe I’ll try that sometime: Imagine a VM where the entire VHD is in a RAMdisk. I wonder how long that would take…

MDT 2012 Update 1: Deploy to VHD

Michael Niehaus — Tue, 02 Oct 2012 05:38:12 GMT

I was working on a separate blog posting (to be posted soon) that referenced the “Deploy to VHD” support that was present in MDT 2012 and improved in MDT 2012 Update 1 and wanted to include a link to that previous blog. Except there was no previous blog – I guess I never did one…

So let’s start with what was added in MDT 2012. Present in this version are two task sequence templates:

Deploy to VHD Client Task Sequence. This is the equivalent of the “Standard Client Task Sequence” template, modified to deploy a client OS (Windows 7 or above) into a VHD file.
Deploy to VHD Server Task Sequence. This is the equivalent of the “Standard Server Task Sequence” template, modified to deploy a server OS (Windows Server 2008 R2 or above) into a VHD file.

Just to be clear, these task sequences have nothing to do with the creation of virtual machines (although you could use them in virtual machines – there’s nothing preventing a VM from using boot from VHD). Instead, these are designed to do the following, in the case of a new computer deployment:

Format and partition the physical disk.
Create a new, empty VHD file.
Format and partition the VHD file.
Apply the specified operating system WIM image to a volume created in the VHD file.
Set up a BCD entry to boot from the OS volume contained in the VHD file.

Of course all the other standard task sequence components are present too (injecting drivers, installing apps, applying patches, etc.). Also, in MDT 2012 Update 1, the first step to format and partition the physical disk can be skipped, causing the new OS to be created on the existing disk, not disturbing the existing OS that might be on that disk. As a result, you could then have a dual-boot computer, choosing the appropriate OS from the boot menu as there would be multiple BCD entries.

MDT 2012 Update 1 also will work with other scenarios, e.g. refreshes, but I’m not exactly sure why would want to do that. Imagine what happens: The user state is captured from current OS on the disk, a new VHD is created with the new OS, and then the user state is restored into that new OS in the VHD. But now the user state is in both places, in the old OS and in the new OS. (MDT 2012 RTW wouldn’t preserve the existing BCD, so you would always end up with only one BCD entry. That behavior was fixed in MDT 2012 Update 1.)

If you want to try refreshing from a system already booting from a VHD file into a new OS running from a VHD file (same or different one), don’t. It won’t work. The challenge is that MDT really isn’t aware that the existing OS volume is in a VHD, so it might run into a variety of issues (e.g. staging the boot WIM in the VHD, or any operation that requires accessing the old OS files from within Windows PE).

So why is this referred to as “Deploy to VHD”? It’s called that because MDT is not moving around VHD files (which would be highly inefficient, as these files aren’t compressed in any way). Instead, it creates a new empty VHD file and deploys the operating system WIM file into it. This is actually fairly fast and efficient, and surprisingly doesn’t complicate the deployment process very much at all.

Why might you want to do this? This is primarily useful as a mechanism for setting up an additional OS on an existing computer. Personally, I prefer using virtual machines for most things, but there could be some valid cases where using an OS running on the physical hardware (which after all is what you are doing, even when booting from a VHD file) is advantageous.

There are a few gotchas in the process though. Because of some technical issues that could occur when using dynamically expanding VHDs, any time you perform a “boot from VHD” the VHD file will automatically expand to its full size (to make sure that Windows never needs to do this while the OS in the VHD is actively running). So even if you have a 10GB operating system WIM (expanded from a 3GB WIM), you’ll end up with a much larger VHD file. By default, MDT will create a VHD file whose maximum size is 80% of the available disk space on the OS volume. So if you do a bare metal deployment to a computer with a 128GB physical drive, you’ll end up with a 102GB VHD file and about 26GB of free disk space. You can customize this by editing the task sequence if you don’t want it to be that large:

Another gotcha has to do with the use of differencing disks, which you can see in the above screen shot. What happens if you configure that? Well, it will happily create a new empty VHD and then create a differencing disk on that empty VHD. So then when the operating system image gets deployed, it ends up writing the whole thing into the differencing disk, while the parent VHD stays empty. That’s not terribly useful. But there are some additional properties in the underlying MDT ZTIVHDCreate.wsf script that could be leveraged instead to have MDT start by making a copy of an existing VHD file, instead of starting with an empty VHD. But that’s a more advanced scenario, left for the creative types.

MDT 2012 Update 1: Roles and Features improvements

Michael Niehaus — Wed, 26 Sep 2012 23:00:30 GMT

Apparently I was so wrapped up in the MDT 2012 Update 1 development process that I forgot to talk about one of the areas that consumed weeks of my time before the MDT 2012 Update 1 release: improvements to the “Roles and Features” logic.

In MDT 2010 and MDT 2012, we had a task sequence action to “Install Roles and Features” that you could use to install roles and features on various operating systems. But it didn’t support Windows 8 or Windows Server 2012; it tried (unsuccessfully in some cases) to merge all of the role and feature lists into one single list for the rest of the OSes; it didn’t include a complete list of roles and features for all the OSes (e.g. Windows 7); etc. Basically, it needed a lot of work.

So in MDT 2012 Update 1, we took the opportunity to do some housecleaning. First, we changed the “Install Roles and Features” task sequence UI to allow you to display a filtered list of roles and features for the particular OS you are deploying:

We also made sure that the complete lists were present for all the various OSes: Windows 7, Windows 8, Windows Server 2008 (full install and core install), Windows Server 2008 R2 (full install and core install), and Windows Server 2012 (full install and core install). (We didn’t change the list for Windows XP and Windows Server 2003. Given that those are already in extended support and rapidly approaching their end-of-life date, we’re not adding new functionality for them.) And we verified the lists – something that gave our test team a real workout, as we had to make sure that we properly handled all the dependencies between the roles and features on OSes where that wasn’t handled automatically (e.g. Windows 7).

Then, we added a new Lite Touch wizard pane to let you dynamically choose roles and features. It automatically displays the right list based on the OS being deployed, allowing you to choose additional roles and features to install later in the task sequence:

What do you need to enable this wizard pane? Just add a step to the task sequence (somewhere in the State Restore phase; the exact location doesn’t matter, but I typically choose to put it in the “Custom Tasks” group) and the new pane will automatically show up. If you don’t want the wizard pane, you can turn it off through Custom Settings.ini by specifying “SkipRoles=YES”.

We also added a new “Uninstall Roles and Features” task sequence step that can be used to remove roles and features that you no longer want. It presents exactly the same list of roles and features inside the task sequence editor:

Notice the red box above, which I highlighted to point out one specific Windows 8 and Windows Server 2012 feature (and only shows up when you choose Windows 8 or Windows Server 2012): Not only can you uninstall roles and features, but you can also completely remove the components, getting rid of all the files related to that component. (If you ever want to add those back, Windows can download the components from Windows Update, or you can provide the original media to pull them from the WIM file. See http://technet.microsoft.com/en-us/library/hh824822.aspx for more details around this, as well as http://technet.microsoft.com/en-us/library/hh825020 for information about how to specify an alternate “repair source” instead of Windows Update.)

It’s worth noting too that we added some extra logic to handle the installation of .NET 3.5 on Windows 8 and Windows Server 2012. For both of these OSes, the .NET 3.5 feature is not present in the standard WIM file, but the files do exist on the media in the \sources\sxs folder. So for Lite Touch deployments, we will automatically provide these files to Windows as long as you have imported the full source files into your deployment share. For ConfigMgr clients, you would need to do a little bit more:

Set up a network share containing the contents of the “sources\sxs” folder from the original Windows 8 or Windows Server 2012 media.
Set a task sequence variable (either through CustomSettings.ini or directly in the task sequence) called “WindowsSource” that points to the location of that folder.

Behind the scenes, the script responsible for performing the role and feature work, ZTIOSRole.wsf, figures out the right thing to do for each OS:

For Windows Server 2003, use SYSOCMGR.EXE.
For Windows Server 2008, use SERVERMANAGERCMD.EXE.
For Windows 7 or Windows 8, use DISM.EXE.
For Windows Server 2008 R2 (non-core) or Windows Server 2012, use PowerShell.
For Windows Server 2008 R2 (core), use OCSETUP.EXE.

Fun stuff. (For those of you keeping track, this also means that MDT now actually uses PowerShell itself during a deployment task sequence to install or uninstall roles and features on Windows Server 2008 R2 and Windows Server 2012. To keep things simple, the ZTIOSRole.wsf script calls the ZTIOSRolePS.ps1 script to take care of this. Look at the logic in ZTIOSRole.wsf and the new ZTIPSUtility.vbs script to see how that works, in case you ever have the need to do something similar, e.g. do some work in VBScript and some in PowerShell.)

MDT 2012 Update 1 has been updated

Michael Niehaus — Wed, 19 Sep 2012 21:53:55 GMT

For those of you using ConfigMgr 2012, you may be interested in this. When ConfigMgr 2012 Cumulative Update 1 was released, it was discovered that you could no longer create a new task sequence using MDT 2012 Update 1 and the “Create MDT Task Sequence” wizard. When you tried, you would get an error like so:

Microsoft.ConfigurationManagement.ManagementProvider.SmsConnectionException: Failed to validate property Type. ---> System.Runtime.InteropServices.COMException: Failed to validate property Type.
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
   at System.Management.ManagementObject.InvokeMethod(String methodName, ManagementBaseObject inParameters, InvokeMethodOptions options)
   at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, Boolean traceParameters)
   --- End of inner exception stack trace ---
   at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, Boolean traceParameters)
   at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters)
   at Microsoft.BDD.Wizards.SCCM_ImportTaskSequenceTask.DoWork(SmsPageData smspageData, Dictionary`2 data)

A new MDT 2012 Update 1 download has now been released containing a fix for that:

http://www.microsoft.com/en-us/download/details.aspx?id=25175

From the text on that page:

MDT 2012 Update 1 version 6.1.2373.0 (Version 6.1.1 on this page) was made available for download on September 19, 2012 and adds support for System Center Configuration Manager 2012 CU1 and System Center Configuration Manager 2012 SP1 Beta. It can be identified as MDT build 6.1.2373.0 in the MDT Workbench console or in the installer program properties. This is the latest version and we recommend all users run the latest version when they can to ensure the smoothest experience during future upgrades.

So for those of you keeping track, the original MDT 2012 Update 1 release was build 6.1.2369.0, while the new release is 6.1.2373.0. Other than this wizard fix and some documentation updates for ConfigMgr 2012 SP1 Beta, there are no other changes. So if you are using ConfigMgr 2012, please download the new version, install it, and then repeat the “Configure ConfigMgr Integration” process to integrate the updated binaries into your ConfigMgr console. (You don’t need to recreate any task sequences or change the MDT toolkit files package if you are already running MDT 2012 Update 1.)

If you are only using Lite Touch, you don’t need to upgrade, but there would be no harm in doing so. Note that after doing this you would need to update your deployment shares, boot media, etc.

Using the Windows Performance Toolkit

Michael Niehaus — Thu, 13 Sep 2012 08:39:26 GMT

Inside the new Windows Assessment and Deployment Kit (ADK) that was released back in August is a component called the Windows Performance Toolkit. I’ve talked about this at various events over the past few months, noting that you can use this kit to help identify what is causing your computers to take so long when they start up before they are usable. But people always ask “how do I do that myself”. First, I would suggest reviewing the documentation that is available online:

http://msdn.microsoft.com/en-us/library/hh162945

Some of you might have used a previous version of this toolkit, which included tools called XPERF and XPERFVIEW. This latest version includes new replacement tools (although the old tools are still around for compatibility, for those die-hard users) called the Windows Performance Recorder, WPR.EXE (command line) and WPRUI.EXE (GUI), and the Windows Performance Analyzer, WPA.EXE. The Recorder captures the events; the Analyzer displays the results. There is another utility called XBOOTMGR.EXE that takes care of one of the more complicated processes: setting up the computer so that it captures information at boot time. That’s the one we’ll want to use here.

So let’s assume that you are experiencing a problem with Windows 7 computers starting up slowly. You can reproduce this at will, but it’s not immediately obvious why. So you log on to the Windows 7 computer, install the Windows Performance Toolkit redistributable from a computer that has the ADK installed (so we don’t need to put the whole ADK on the Windows 7 computer), and then run the “xbootmgr.exe -trace boot” command to get everything started:

It will quickly reboot the computer, so be prepared. As soon as you can, log in to the computer to finish up the process. By default, it will wait two minutes to let the system settle down, but you can choose to end it sooner by clicking the “Finish” button:

Then you can run the Windows Performance Analyzer to look at the trace; start it using the shortcut on the Start menu. (Note that it requires .NET 4.0 so if you don’t have that installed it will complain. You can always analyze the trace remotely if you want, just copy off the *.ETL file.) Once it launches, have it open the trace file that was created in the same folder we ran XBOOTMGR.EXE from:

Since the Windows Performance Analyzer is very graphically-oriented, you might want to do this using a high-resolution display:

And that’s really where the fun starts: figuring out what graphs to add, what timeframes to focus on, and trying to get to a root cause. I’m no expert myself (yet), but I can see from the trace above that most of the time was spent in the Winlogon Init process. And probably not coincidentally, most of that time corresponds to the gpscript.exe and wscript.exe process lifetimes. And farther below, we can see generic events from Group Policy that confirm group policy processing took about a minute. So what was going on in this case? A bad startup script that took a minute to complete, combined with a policy setting that said “don’t run startup scripts asynchronously”.

Now I just need to teach myself how to better analyze these traces. Let the fun begin…

Troubleshooting Windows Deployments, take #2

Michael Niehaus — Tue, 11 Sep 2012 10:18:00 GMT

Traveling from New Zealand to Australia for the TechEd Australia conference, I had some additional time to work on the troubleshooting guide, which is now starting to feel more like a book. I added two sections to this document, one reviewing all the possible return codes from the MDT scripts (yes, there are lots of them, over 30 pages worth) as well as from USMT 5.0.

As you can probably tell, my focus is still on reference material. See the attached file below.

Database changes in MDT 2012 and MDT 2012 Update 1

Michael Niehaus — Sun, 09 Sep 2012 09:21:07 GMT

A few people have asked about the changes made in MDT 2012 and MDT 2012 Update 1 in regards to the MDT database. There aren’t that many changes, but here they are:

MDT 2012 RTW

Removed obsolete properties for Lite Touch: SkipAppsOnUpgrade.
Added new properties for ConfigMgr 2012: SMSTSPreferredAdvertID, SMSTSUDAUsers, SMSTSAssignUsersMode.
Added one new property for all scenarios, OSDStateStorePath.

MDT 2012 Update 1

Removed obsolete properties for SMS 2003: OSDINSTALLSILENT, OSDINSTALLPACKAGE, OSDINSTALLPROGRAM, OSDNEWMACHINENAME, OSDMP, OSDSITECODE.
Removed obsolete properties for Lite Touch: BuildID, SkipDeploymentType, SkipBuild, SkipBitLockerDetails, SkipDestinationDisk.

If you have an existing database, no properties will be removed; the properties marked as “removed” above just don’t get created in new databases.

If you have an existing database, the properties marked as “added” above will automatically be added to your existing database.

Any customizations that you might have made to your database should be preserved.

Troubleshooting Windows Deployments

Michael Niehaus — Thu, 06 Sep 2012 04:58:00 GMT

I’ve been doing a session at various events over the years called “Troubleshooting Windows Deployments” or something similar to that. Today is the latest, presenting the session at TechEd New Zealand in Auckland. It’s been tweaked some over the years, but the basic flow has always been the same:

Log files of interest
Examples of problems you might encounter
Where to turn for help

Well, I figure it’s about time to turn some of this into documentation and start working on some deeper content – basically, turning the current session into a book. Of course you don’t write a book overnight (especially when you have a day job), so I expect this to be an incremental process. But rather than wait until it’s done and then publish the whole thing, I’d like to take a different approach: publish sections as I manage to work on them.

So here’s my first section, talking about the various log files that may be of interest during the deployment process. (See the attachment below.) With any luck, I’ll add to that every now and then until everything in the session is included in the document – and then keep going…

Revisiting LTI deployment wizard application selection profiles

Michael Niehaus — Tue, 04 Sep 2012 03:36:00 GMT

A few years back, I posted a blog at http://blogs.technet.com/b/mniehaus/archive/2010/06/11/selection-profiles-with-the-lite-touch-deployment-wizard.aspx describing how to modify the Lite Touch wizard so that the deployment wizard shows a different list of applications based on the task sequence that was selected. This worked fine with MDT 2010 Update 1, but there have been a few changes to the scripts and the structure since then. So how do you need to do it now? Well, it hasn’t changed much, but just enough to break things.

First, the script that you need to modify is now DeployWiz_Applications.vbs. This script contains the logic that is specific to the application wizard pane. (In MDT 2012, the wizard was split up so that each pane uses its own wizard files, see http://blogs.technet.com/b/mniehaus/archive/2012/03/01/3474394.aspx for more details.) The logic that needs to be changed is in the same “IsThereAtLeastOneApplicationPresent” function, but one of the variable names was changed from “oXMLAppList” to “g_oXMLAppList” to reflect that it is a global variable. So now the logic needs to be changed to look like this:

So the first line is changed from:

g_oXMLAppList.sSelectionProfile = oEnvironment.Item("WizardSelectionProfile")

to:

g_oXMLAppList.sSelectionProfile = oEnvironment.Substitute("For %TaskSequenceID%") ' MODIFIED

and the second section is added:

' INSERTED
If dXMLCollection.count = 0 then
g_oXMLAppList.sSelectionProfile = oEnvironment.Item("WizardSelectionProfile")
Set dXMLCollection = g_oXMLAppList.FindItems
End if
' END INSERTED

The key changes from the original version are highlighted above. So that’s all there is to it, now the logic should work fine with MDT 2012 and MDT 2012 Update 1.

Automatically configuring the ConfigMgr console for MDT 2012

Michael Niehaus — Tue, 04 Sep 2012 02:54:00 GMT

As part of the MDT installation process, you need to run the “Configure ConfgMgr Integration” wizard to add the MDT components into the ConfigMgr console and database. But what if you want to automate that process? Fortunately, that’s pretty easy to do using PowerShell, as the integration process really just copies some files around.

See below for the attached PowerShell script, which performs the following tasks:

Locates the MDT installation directory.
Attempts to find the ConfigMgr 2007 console’s installation directory. If found, copy files and folders from the MDT installation directory to that location.
Attempts to find the ConfigMgr 2012 console’s installation directory. If found, copy files and folders from the MDT installation directory to that location.

So there’s not much to it. Note that the wizard does a couple of additional tasks that aren’t covered by this script:

Add the MDT task sequence actions into the ConfigMgr database. This is done by editing a MOF file to specify the site server name and site code, and then compiling that MOF. This process just needs to be done once, generally at the top-level site only. It’s easy enough to do this one-time operation manually (using an account that has full permissions to the site server), so no real need to automate it.
Remove the MDT extensions from an existing ConfigMgr console. This is left as an exercise for the reader: Instead of copying the files to the ConfigMgr console directory, you just need to remove them.

Make sure you run this script from an elevated PowerShell session, and also make sure that PowerShell scripting has been enabled using something like “set-executionpolicy bypass”.

Speed up MDT task sequences in Configuration Manager

Michael Niehaus — Sun, 02 Sep 2012 03:52:27 GMT

Here’s a quick suggestion for speeding up MDT-created task sequences in ConfigMgr 2007 or ConfigMgr 2012:

Find your MDT toolkit files package source folder.
In the “Scripts” folder inside that folder, find the “ZTISCCM.wsf” script.
Look for a line like this:

wscript.sleep 30000

Remove that line or comment it out, then save the script.
Update the deployment points for that package.

Not surprisingly, that will remove a 30-second delay from the execution. (Why is that in there? Beats me. I remember who put it in there – it wasn’t me – and I remember discussing it, but the logic behind it escapes me now as it did then.)

So will this cut 30 seconds out of your deployment? For refresh deployments, yes; for bare metal deployments, it will cut 60 seconds from the deployment process. So let’s explore that “Use Toolkit Package” step (the one that runs ZTISCCM.wsf behind the scenes) in more detail. It has a single purpose: It takes the contents of the MDT toolkit package (scripts, tools, etc.) and makes a copy of them on the local hard disk, setting various task sequence variables (DeployRoot, ScriptRoot, ToolRoot, etc.) to let us keep track of where they are. As a result of this, we don’t need to download them for every single step. But we do typically need to download them more than once. For example:

In a bare metal deployment, we “temporarily” format and partition the disk if there were no existing partitions, then download the package (as the download would fail if there were no partitions present). Later, the disk is repartitioned and reformatted, so that content was lost. Right after that, the package is downloaded and cached again.
In a refresh deployment, we initially download the files to the C: drive and set all the variables to point to that location. But when rebooting into Windows PE or a new OS, the drive letter may change. As a result, the variables are no longer valid. We have to download all the files just so that we can run the ZTISCCM.wsf script to find the already-cached local files.

So you’ll see a variety of “Use Toolkit Package” steps in the task sequence. In MDT 2010 Update 1, all of these executed. In MDT 2012, we added some conditions to the “Use Toolkit Package” steps so that they only execute when necessary. So when are they necessary? Any time the variables (DeployRoot, ScriptRoot, ToolRoot, etc.) aren’t valid. So the condition was added to say “If not %ScriptRoot% exists”. That way, the step is skipped when it isn’t needed.

In typical bare metal deployments, the step will run two or three times (with the 30-second delay happening twice). In typical refresh deployments, the step will still run two or three times but in different times in the task sequence (with the 30-second delay only happening once).

Copying $OEM$ files and folders with MDT 2012 Update 1

Michael Niehaus — Fri, 24 Aug 2012 07:38:00 GMT

I mentioned in the blog post at http://blogs.technet.com/b/mniehaus/archive/2012/07/21/mdt-2012-update-1-always-applying-images-with-imagex.aspx that MDT 2012 Update 1 no longer uses SETUP.EXE to install Windows 7 and above. One side effect of this is that $OEM$ folders are no longer going to be copied, since that was something that SETUP.EXE did that the MDT LTIApply.wsf script doesn’t handle.

I’ve never been a big fan of using the $OEM$ folder structure, as it’s just as easy to add explicit XCOPY steps into the task sequence. But for those of you out there that are using them, you can leverage the attached script (see the attachment link below) in your task sequence to do that.

To set this up, first copy the script into your deployment share. Then, add a new step to the task sequence right after the “Install Operating System” step to run the script. It should look like this:

Now, it will follow the original MDT logic for locating the appropriate $OEM$ folder to use, checking in this order:

%DeployRoot%\Control\%TaskSequenceID%\$OEM$
%SourcePath%\$OEM$
%DeployRoot%\%Architecture%\$OEM$
%DeployRoot%\$OEM$

where %DeployRoot% is the path to the deployment share, %TaskSequenceID% is the ID of the running task sequence (e.g. WIN8), %SourcePath% is the path within the deployment share for the operating system being used, and %Architecture% is either X86 or X64, depending on the boot image being used. (That’s a bit of a flaw in the original MDT logic since we now support cross-platform deployments – it would choose an X86 $OEM$ folder even if you were deploying an X64 operating system. That’s probably a good sign that no one is using this option. Most people use the last one.)

Once it finds a folder, it will look for two folders in that $OEM$ folder and copy them to the appropriate place for the new OS:

$1 will be copied to the root of the volume that the new OS image was applied to.
$$ will be copied to the Windows folder on the volume that the new OS image was applied to.

The script doesn’t deal with any other folders because it’s too messy to do that from within Windows PE – drive letters aren’t the same as what they would end up being in the full OS.

Displaying the task sequence name

Michael Niehaus — Thu, 23 Aug 2012 05:29:07 GMT

I was talking to some people yesterday at the TechMentor conference in Redmond and about MDT, and somehow during the conversation I got a mental image of the task sequence progress dialog that I couldn’t shake (and that wasn’t really even related to the conversation, go figure).

A while back, we made some changes to the LiteTouch.wsf script and various other places to enable you to specify a “task sequence package name” that would get displayed in the task sequence progress dialog next to the “Running: “ label:

Even before that, you could specify an organization name (“My Org Name” in the picture above). To specify these, you can configure them in CustomSettings.ini:

_SMSTSOrgName=My Org Name
_SMSTSPackageName=My Package Name

That’s great if you want to hard-code the values, but what I wanted was a simple way to set the second one (the “Running” value) to the name of the task sequence that is being executed. That’s a little harder to do, because the task sequence hasn’t yet been selected when CustomSettings.ini is being processed, and you can’t set these read-only variables once the task sequence has started.

So this is one of those cases where you have to modify one of the MDT scripts, in this case LiteTouch.wsf. Fortunately, it’s a really trivial change. Look for this line:

oEnvironment.Item("_SMSTSPackageName") = "Lite Touch Installation"

And change it like so:

oEnvironment.Item("_SMSTSPackageName") = oEnvironment.Item("TaskSequenceName")

That line is only executed if _SMSTSPackageName is blank after CustomSettings.ini has been processed, so it won’t have any effect if you manually configured a value in CustomSettings.ini.

With that change, you can now see the name of the currently-running task sequence:

That’s all there is to it.

One journey ends, another begins

Michael Niehaus — Thu, 02 Aug 2012 03:10:43 GMT

A long time ago, I worked in corporate IT. One day I started looking for new challenges and interviewed with Microsoft for a job in Microsoft Consulting Services, helping customers with their Windows deployment processes. I distinctly remember talking about all the “challenges” (putting it nicely) with the current tool, the Business Desktop Deployment (BDD) 1.0 solution accelerator, that was being used.

Through an interesting twist of fate, I was soon working with the BDD team on version 2.0. That was in 2004. It turned into a full-time job in 2005 when I moved to Redmond. Many more releases followed: BDD 2.5, BDD 2007, Microsoft Deployment (see http://blogs.technet.com/b/mniehaus/archive/2008/01/22/a-concise-history-of-bdd.aspx), Microsoft Deployment Toolkit 2008, Microsoft Deployment Toolkit 2010, and Microsoft Deployment Toolkit 2012. And that doesn’t even count the “update” releases that happened in between (or the latest one, MDT 2012 Update 1, due soon). All total, we’ve managed to have slightly more than one release per year.

It’s been a great journey. But this journey is coming to an end and another is beginning. After eight years, today is my last day working on the MDT team. Starting tomorrow, I am joining the Windows organization as a product marketing manager for enterprise Windows deployment. It’s not huge stretch from what I’ve been doing: helping customers get Windows deployed in their enterprises. But instead of working on individual tools, I’ll expand my horizons to include the entire Windows deployment process.

Does that mean I’ll disappear into the innards of Microsoft, never to be seen again? Not a chance. I’ll still be blogging (hopefully even more), I’ll still be presenting at events (even on MDT), and I’ll still be involved in the MDT, Windows, MVP, and IT pro communities. And I expect to hear from you if you are having deployment challenges, roadblocks, or just questions about how to do things.

Thanks for your support over the years, and I look forward to keeping in touch while on my new journey.

MDT 2012 Update 1 is coming soon!

Michael Niehaus — Thu, 02 Aug 2012 02:27:23 GMT

You probably noticed that Windows 8 and Windows Server 2012 RTM’d today (see http://windowsteamblog.com/windows/b/bloggingwindows/archive/2012/08/01/windows-8-has-reached-the-rtm-milestone.aspx and http://blogs.technet.com/b/windowsserver/archive/2012/08/01/windows-server-2012-released-to-manufacturing.aspx for the details). MDT 2012 Update 1 won’t be too far behind, as this is the version that will fully support Windows 8 and Windows Server 2012 deployment, as well as the new Assessment and Deployment Kit (the replacement for Windows AIK) tools.

Apart from the usual behind-the-scenes enhancements and bug fixes, as well as a simple upgrade process, we’ve also added new features which I’ve reviewed in this series of blog postings:

I’m sure I’ve missed a few (such as new documentation for the MDT PowerShell cmdlets), but that covers most of them Be watching for the upcoming release announcements.

MDT 2012 Update 1: UDI “Build Your Own Pages”

Michael Niehaus — Thu, 02 Aug 2012 02:07:46 GMT

One of the challenges with previous versions of the UDI wizard was extensibility. With MDT 2010 Update 1, there was no way to add a new page. With MDT 2012, you could do this by writing C++ and C# code, which at least made it doable, but beyond the capabilities of most organizations. Now with MDT 2012 Update 1, you can build your own pages without writing any code, directly from the UDI Designer.

Here are the basics for doing that:

Launch the UDI Designer and open an existing wizard configuration file, e.g. UDIWizard_config.xml.
Click the “Add Page” button:
In the dialog, select “Build Your Own Page” then provide a page name (only used in the designer) and a display name (shown in the wizard’s navigation pane):
Find the new page in the Page Library on the left side of the designer window. Double-click on the page to open it in the page editor:
Add whatever controls you want by dragging and dropping them onto the design surface, changing the properties on the Layout and Settings tabs as needed:
Click the “Flow” tab, then drag the new page from the page library to the right location in the flow:
Finally, you can preview your changes by clicking the “Preview” button:
When you are happy with the look and feel, save the new configuration, then update the MDT toolkit files package to make that new file available to the task sequence.

That’s all there is to it.

MDT 2012 Update 1: Customer experience improvement program

Michael Niehaus — Tue, 31 Jul 2012 21:47:03 GMT

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

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

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

MDT 2012 Update 1: Orchestrator support

Michael Niehaus — Tue, 31 Jul 2012 21:20:38 GMT

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

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

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

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

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

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

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

Some ideas for runbooks that you might want to try:

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

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

MDT 2012 Update 1: Monitoring for ConfigMgr

Michael Niehaus — Tue, 31 Jul 2012 20:54:23 GMT

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

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

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

In Deployment Workbench, create a deployment share (if you don’t already have one), then in the properties enable monitoring:

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

There are some limitations with this implementation worth pointing out:

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

MDT 2012 Update 1: Merged ZTI and UDI task sequences

Michael Niehaus — Fri, 27 Jul 2012 17:06:22 GMT

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

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

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

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

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

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

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

MDT 2012 Update 1: DaRT 8 support

Michael Niehaus — Thu, 26 Jul 2012 23:50:57 GMT

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

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

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

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

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

MDT 2012 Update 1: ConfigMgr 2012 SP1 CTP support

Michael Niehaus — Thu, 26 Jul 2012 22:34:10 GMT

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

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

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

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