Michael Niehaus' Windows and Office deployment ramblings
In MDT 2008, we had various functions in the ZTIUtility.vbs script that could be used in CustomSettings.ini – not that we really intended for that to be the case, but because the “Gather” process can call any global VBScript function, so it just works.
In MDT 2010, we rearranged the logic in ZTIUtility.vbs into different classes, just to make the script more modular and maintainable. But as a result, some of those global functions were no longer global, so anyone trying to use them wouldn’t be able to any more.
Michael Murgolo noticed this, as he was using the ConvertBooleanToString function in the blog posting at http://blogs.technet.com/b/deploymentguys/archive/2010/02/15/using-convertbooleantostring-with-ztigather-wsf-in-mdt-2010.aspx. To fix this issue (and to avoid anyone needing to implement a workaround) we added logic in MDT 2010 Update 1 to make the function global again.
(10614)
Some people noticed that during an OS deployment task sequence, performed either by MDT 2008 Lite Touch or by ConfigMgr, could capture sensitive information (from unattend.xml, variables.dat, etc.) as part of the automatic System Restore snapshot process that happens whenever a new driver, application, security update, etc. is installed.
To address that issue, we added some logic in MDT 2010 to disable System Restore by configuring the default unattend.xml template:
<component name="Microsoft-Windows-SystemRestore-Main" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DisableSR>1</DisableSR> </component>
We then added logic to re-enable that at the end of the deployment process – but only for Lite Touch. (You can see that logic in LTICleanup.wsf.) We discovered later that this was left out of the ConfigMgr scripts. So as a result, machines deployed using ConfigMgr and an MDT 2010 task sequence template ended up with System Restore disabled.
In MDT 2010 Update 1, we added logic to address this. Now, System Restore will be re-enabled at the end of the deployment even with ConfigMgr. (Because we don’t have the equivalent of LTICleanup.wsf in a ConfigMgr task sequence, the logic was added to ZTICopyLogs.wsf, the last script to run during an OSD task sequence.)
(10527)
During Lite Touch deployments, the task sequence runs ZTIDrivers.wsf, which needs to figure out what drivers are needed for the computer, based on the PnP IDs found on the computer and the available drivers on the deployment share. For every match, the driver files are copied to the computer.
It’s possible (especially with chipset drivers) for there to be multiple drivers in the same driver directory. Because we don’t really know which files are necessary for each driver, we don’t try to separate them during the driver import process. Instead, we just have multiple driver entries (one for each INF file) pointing to the same folder.
That means it’s actually possible for the same folder to be selected multiple times, once for each INF in the folder that matches a PnP ID. And each time it’s selected, it’s copied. Prior to MDT 2010 Update 1, that could mean that the same folder (maybe 100MB) gets copied several times, overwriting what was copied the previous time. That’s not terribly efficient, so we modified ZTIDrivers.wsf to not re-copy files that already exist in the destination (C:\Drivers). (Since ZTIDrivers.wsf actually uses XCOPY, all we really did was add “/d” into the command line parameters, so XCOPY is doing the real work.)
So if you’ve complained that driver injection is taking too long, this could help out. It won’t help out in all cases (especially if the deployment share is remote or especially large), just those where there are multiple drivers in a folder.
(10541)
In MDT 2010 (and earlier versions), we provided some task sequence templates to perform what we called an “OEM preload” scenario, where you could send a disk image to an OEM for them to preload on each new machine they manufactured for you. But due to some limitations in ConfigMgr (and our requirement to not do anything in MDT that isn’t supported by the ConfigMgr team), we had to do this in a less-than-optimal way. We ended up with two task sequences:
Because of the product limitations, there was no way to do this with a single task sequence. And there was no way to initiate the second task sequence without a boot CD or using PXE. That meant that the first task sequence would intentionally leave the disk unbootable (no partitions active) to ensure that the second task sequence was initiated next. It worked and was supportable, but it wasn’t very pretty.
Fortunately, the ConfigMgr team was able to come up with a better solution in ConfigMgr R3 that they call “prestaged media”. Using that, you can use a single standard task sequence to do this whole process. The “create media” wizard now lets you create one large WIM file that contains both a boot image and an extracted OS image package, and that can be staged to the hard drive. When that hard drive then boots, it contacts the MP and runs whatever task sequence you choose. When that task sequence gets to the “Apply Operating System” step, it knows that the OS is already on the hard drive and just exits. For more details on this whole scenario, see John Vintzel’s post at http://blogs.technet.com/b/inside_osd/archive/2010/04/29/prestaged-media-in-configuration-manager-r3.aspx.
So, back to the topic at hand: What did we need to do to the MDT task sequence templates for ConfigMgr in order to support this new ConfigMgr R3 “prestaged media” capability? It was almost embarrassingly simple: We need to modify the “Format and Partition Disk” steps so that they wouldn’t execute if we were running from the disk. This is a simple enough check to see if the task sequence variable “_SMSTSMediaType” is set to “OEMMedia”. If it is, the formatting is always skipped so that the prestaged hard drive content is preserved.
That’s it – no other changes were needed in MDT 2010 Update 1 to support ConfigMgr R3.
(10595)
When using MDT task sequence templates for ConfigMgr, we expect to keep user state locally if you are refreshing existing machines. But if you are replacing a computer, the user state needs to be stored on a ConfigMgr state migration point. In that setup, you would run two different task sequences:
There were a variety of issues in the task sequence templates that resulted in this not working right in some scenarios, so you’ll see some extensive changes in he SCCM_ClientReplace.xml template, rearranging steps, adding steps, adjusting conditions, etc. (The rearranging is necessary because you can’t release a state store from within Windows PE – that needs to be done in the full OS.) There were a few related adjustments in SCCM_Client.xml too, primarily adjusting the conditions used on various steps to make sure that the user state and computer backup always end up at the same location: If user state goes the SMP, both will go to the SMP; if user state is kept locally, the backup will be kept locally too. (Most of those conditions were already present, but the case-sensitive checks were causing them to not be evaluated correctly.)
At the same time, we fixed an issue where a failure in the “Restore User State” step might not be noticed because the step was configured to continue on error. That makes sense in cases where there was no user state captured, but if there is a valid user state store present, we should use it. So additional conditions were added to the step to cause it to be run any time user state exists and skipped otherwise, and if it fails, the task sequence will fail.
A quick reminder too: If you don’t want computer backups to be performed (often the case because they take so long), you need to edit the CustomSettings.ini file in the settings package being used so that it specifies “ComputerBackupLocation=NONE”.
(10836, 10837)
In MDT 2010, we restructured the ConfigMgr task sequence templates so that they had a common structure to them, with two main groups:
But there was one problem in the setup in MDT 2010: the error was caught and the cleanup steps would run, but after that the task sequence would appear to complete successfully. No dialog would be displayed indicating that there was a failure, and the status messages sent to the server would indicate that the task sequence was successful too . If you were watching the results from the individual steps (watching for status message 11135 messages), you would see that there was an error though.
In MDT 2010 Update 1, we’ve updated each of the task sequence templates (and included the same logic in the new UDI template) to include two new steps to address this problem. The first is named “Set Error Code” and (appropriately enough) captures the error code (e.g. everyone’s favorite –2147500037) into a task sequence variable. The second step, named “Error in the task sequence”, then runs a new script (ZTIErrorMsg.wsf) whose only purpose is to force the task sequence to fail with that same error code. That solves the problem.
So this is one of the main reasons to consider generating new ConfigMgr task sequences after installing MDT 2010 Update 1.
(10627)
MDT 2010 also includes a variety of task sequence templates. When you upgrade from MDT 2010 to MDT 2010 Update 1, your existing task sequences won’t be changed. So, you have to decide if any of the changes that we’ve made are of value to you, and if they are, you’ll need to create new task sequences so that you pick up those changes.
So let’s review the task sequence templates that have changed:
And there’s one new template:
For the changed templates, I’ll get into the specifics of the changes in later posts. But to give you some guidance, here are my opinions:
Since MDT 2010 Update 1 was released, I’ve been intending to write a series of blog postings talking about the changes that have been made. While my intentions were good, I’ve been too busy to really act on them. So I’m going to force myself to do this one posting, and hope that encourages me to keep going from there…
You’ve already seen the list of new features mentioned in the official announcment, so I thought it would be good to list the scripts that were actually changed in Update 1. I do intend to talk about why some of those have changed, but that will need to come later – right now, I want to just focus on the list.
So which have changed? Well, all of them – but that’s only because the build number is embedded in the scripts by our build process, so you’ll see that all of the scripts have been modified so that they say “5.1.1642.1” instead of “5.0.1641.0”. So let’s look past that and focus on the ones that had real changes:
OK, so maybe it would have been easier to list the scripts that weren’t changed. As you can probably tell from the list, the changes were rather widespread, sometimes to fix bugs, sometimes to add enhancements based on your requests, and other times to support new features. Some of these changes were fairly minor, others were more substantial (more details on the actual changes to come later). Regardless, if you’ve modified any of the MDT scripts, you’ll want to save a copy of your modifications and then compare them against the new scripts (after upgrading your deployment shares or toolkit file packages) to see how to integrate your changes, or even if they are still needed.
There were also some new script files added (all used by the new UDI scenario):
Next up: Exploring the changes made to the MDT task sequence templates. That can wait for another day.
For those of you who didn’t notice the posting on our team blog talking about today’s release of MDT 2010 Update 1 or hadn’t signed up for the beta on http://connect.microsoft.com so you didn’t get the e-mail notification, I wanted to post a few quick notes about the new release:
Also remember the typical upgrade process:
This release is definitely recommended for all current MDT 2010 users (and those still running MDT 2008 and BDD 2007 too), as it adds a few key features (see the team blog entry) and fixes a variety of issues in the current MDT 2010 release.