Michael Niehaus' Windows and Office deployment ramblings
A few people asked why I hadn’t talked about support for these new OSes yet. First, these were mentioned in the original announcements so you’ve probably already heard about that, and second, I said I would mention new features in no particular order.
So yes, MDT 2010 Beta 2 fully supports Windows 7 and Windows Server 2008 R2 release candidate builds. The deployment process for Windows 7 and Windows Server 2008 R2 is very similar to that used with Windows Vista, so you may not immediately notice any difference. (We use the same unattend.xml templates for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, which tells you how similar they really are.) There are a few differences that we’ve encountered, but our scripts hide those so you probably will never notice.
With Windows 7 and Windows Server 2008 R2, the Windows team recommends creating two partitions, a small partition for the boot files and a large partition for the operating systems. The minimum size for the small partition is 100MB, but MDT 2010 uses 300MB to make sure that there is enough space for a Windows Recovery Environment (Windows PE-based) WIM. This partition will automatically be created when performing a “new computer” deployment using Lite Touch. (There is a variable, DoNotCreateExtraPartition, that can be set to “YES” via CustomSettings.ini to skip this if you want to purposely ignore the Windows team’s recommendations.)
MDT 2010 Beta 2 also supports deploying Windows 7 and Windows Server 2008 R2 using the ConfigMgr 2007 SP2 beta, which is available on http://connect.microsoft.com, so be sure to try that beta (in a lab, of course) too.
When importing drivers into MDT 2010, Deployment Workbench will validate if each driver is signed; this information will be recorded and visible in the list of drivers. Remember that Windows will always prefer signed drivers over unsigned drivers, so you can use the information gathered by Deployment Workbench to figure out what drivers are likely to be installed by Windows.
In previous versions of MDT, there was no way to copy a step or a group of steps between two task sequences. Now with MDT 2010 that is fairly simple:
This should save you some typing, since you won’t need to manually recreate steps in other task sequences. The step or group details being copied will be kept on the Windows clipboard, so it’s even possible to copy from one machine via Terminal Services and then paste into another.
In MDT 2008, the Windows PE startup process was something close to this:
That meant that there was always a command window visible on the screen, as well as another minimized one that could be used for troubleshooting. Some didn’t like that cluttered look, so they hooked in utilities to hide these command windows.
With MDT 2010, that will no longer be necessary. The startup process has been modified:
That means no command windows at all:
Well, what if you really want a command prompt so that you can do some troubleshooting (e.g. checking if a network driver has been installed)? Simple, press the F8 key and one will be started for you. (This command prompt should behave like the one in ConfigMgr 2007: as long as you have a command prompt open, the machine won’t reboot. However, there is a problem with that in MDT 2010 Beta 2 so the machine will reboot even with the command prompt open. That should be fixed before the final release of MDT 2010.)
Jeff Alexander posted the details of an interesting offer for the upcoming TechEd Australia conference, which is happening from September 8th through the 11th: each paid attendee will receive an HP 2140 Mini Notebook with the RTM version of Windows 7 preinstalled. Read http://blogs.technet.com/jeffa36/archive/2009/06/30/teched-australia-free-netbook-on-offer.aspx for all the details.
And of course MDT 2010 will be used to prepare all of those machines for the attendees.
Hopefully I’ll see some of you there at the conference.
With MDT 2008, there were two actions in Deployment Workbench: “Update” and “Update (files only)”. With MDT 2010, there is now only one called “Update Deployment Share”. This action’s purpose is to generate the Windows PE boot images and ISOs needed to perform a deployment. It will figure out what actions need to be performed to get the images updated and will only perform those actions. So generally the first time you run “Update Deployment Share” it will take a while to generate the boot image; the next time it will see that nothing needs to be done and quickly finish.
We also modified the configuration for these boot images. There are now separate settings for x86 and x64 boot images. You can also specify ISO file names, image descriptions (useful if you are importing the Lite Touch WIMs into WDS), RAMdisk scratch space size (useful for those pesky huge nVidia drivers that you want to inject into Windows Vista), etc.
When you perform the “Update Deployment Share” process, Deployment Workbench will compare the current boot image configuration against the previous configuration. If there are only minor changes, it will copy the WIM locally, make the necessary updates (e.g. injecting new drivers, updating the Bootstrap.ini, adding new components), save the updated WIM, and (optionally) generate a new ISO file. If there are major changes, the boot image will be recreated from scratch. You can force a full update in the “Update Deployment Share” wizard by selecting “Completely regenerate the boot images”:
Because adding and removing drivers, components, patches, etc. can slowly cause the size of the Windows PE boot WIMs to increase, you can also choose to compress the boot image, which will export the WIM contents to a new WIM to get the size back to the smallest possible.
With MDT 2008, Deployment Workbench would always use the “winpe.wim” files from the Windows Automated Installation Kit as the source for all boot images that it would generate. With MDT 2010, Deployment Workbench will look for a “boot.wim” file from one of the imported operating systems that has the same build number as Windows AIK (e.g. “boot.wim” from a Windows 7 RC, build 7100, operating system to go with the Windows AIK for Windows 7 RC). If it finds a match, it will use that WIM instead. Why do we do this? Because the “boot.wim” contains the Windows Recovery Environment (Windows RE), a component that isn’t available in Windows AIK.
Another enhancement in this process: you can now abort the “Update Deployment Share” process at any point, so if you decide you would rather do the update later you can. It might take a while for the process to clean up after itself (e.g. unmount any mounted WIMs) so the machine is left in a good state, so be patient.
In a previous posting, I talked about arranging items into folders. To help with that arrangement process, Deployment Workbench now supports drag-and-drop, making it pretty easy to copy (link) items into additional folders. If you hold down the shift key before dropping, the copy will change to a move.
Behind the scenes, these drag-and-drop operations become “Copy” and “Paste” or “Cut” and “Paste” operations, so if you prefer to do it using those actions they work fine too.
Drag-and-drop will also work with folders too, if you decide you want to rearrange your folder structure.
You can also use drag-and-drop (and Copy/Paste or Cut/Paste) to copy or move items between deployment shares.
With MDT 2008, you could have one distribution share, which corresponded to a lab deployment point. You could then have additional network deployment points and media deployment points, with each of these receiving a subset of what was on the main lab deployment point.
With MDT 2010, we’ve changed terminology somewhat. Now, instead of distribution shares and deployment points we just have deployment shares. And there’s no real differentiation between “lab” and “network” – a deployment share is a deployment share. You can have as many of those as you want, and you can choose to replicate all content between them or keep them independent. Each deployment share can be on the local machine or on a different server (accessed via the UNC path); we even support standalone DFS roots.
So let’s talk about a few different scenarios that you might want to consider.
Scenario #1: Simple but reliable
You want to have a single deployment share on a highly-available file server cluster with SAN-attached storage, but you don’t want to install MDT on that server. That wasn’t possible with MDT 2008, but it’s simple with MDT 2010. You can install MDT on your workstation (or any other machine) and use it to manage the contents of a deployment share on the file server cluster via the UNC path that you created.
Scenario #2: Private and public
You have a lab environment where you create your reference images. You import those images into Deployment Workbench and create new task sequences to deploy those. But you don’t want your end users to ever deploy the reference image task sequences, just the ones that deploy the reference images. With MDT 2008, you could have done that using a lab deployment point and a network deployment point.
With MDT 2010, you would create two deployment shares, for example \\SERVER1\Lab and \\SERVER1\Production. You can then replicate only the items you want from lab to production. This is done using “linked deployment shares”, a new feature that allows you to specify the target deployment share (e.g. \\SERVER1\Production) and the content that should be replicated to it. Or, you could do this manually as Deployment Workbench could have both deployment shares open at the same time, enabling you to manually copy the needed items from one share to the other.
Scenario #3: Server and desktop
You might have two different teams, one which works on server OSes, images and task sequences, and the other that works on desktop OSes, images, and task sequences. You can create two deployment shares to support that, and even selectively copy content (e.g. a subset of drivers or applications) between them.
Scenario #4: Cooperative deployment shares
Some companies do not have a completely centralized IT group. They may have a central team that creates reference images and packages applications, but regional IT groups are responsible for the actual deployment, including figuring out what drivers are needed for the hardware used at that location. With MDT 2010, you can have a central deployment share, then selectively replicate content to regional deployment shares, e.g. all images and applications, without disturbing the rest of the deployment share content. The IT administrators at the regional sites can maintain their own task sequences, drivers, etc.
In MDT 2008, you could define driver groups and package groups as a way of logically organizing the items that you imported into Workbench. With MDT 2010, we have extended that so that you can now create an unlimited number of folders, set up in whatever folder hierarchy you want to use. For example, here’s the structure that I created in my test environment:
There’s nothing special about this folder structure – you can choose to arrange items into whatever folder structure you want to use. These folders are then used to control driver injection, package (patch) installation, boot image creation, and even the Deployment Wizard display. More on those some other time.
To populate those folders, you can either move or copy existing items into them (no more “brain-dead UI” property pages that force you to check off the groups that a driver should belong to). When you copy items, the item itself isn’t duplicated. Instead, a new link is added to the existing item. That means you effectively have the same item in multiple places – if you modify the link (e.g. rename it or modify its comments) you’ll see the same modifications on the original item.
Related to this “linking” logic, we do not allow you to have two items of the same type with the same name, even if those items are in different folders. All application names need to be unique; all task sequence names need to be unique; etc. So if you see two items with the same name, you can be assured that they are links to each other. (If you want absolute confirmation of that, look at the list view: it will show the GUID assigned to each item, and the GUIDs will be the same for each link.) We do support specifying a display name for items like applications, so if you want two different items to show up as “Office 2007” you can do that.
MDT 2010 includes a new script called LTISuspend.wsf that isn’t actually part of any of the task sequence templates – by default it’s not used. But if you add it into a task sequence during the “State Restore” phase activities, it will allow you to temporarily suspend the task sequence. This is intended for reference image creation processes where there might be some activities that you just can’t possibly automate – you can make the changes by hand and then when finished restart the task sequence to create your image. (If there is any way to do the automation, you should – this is for those “I have no other choice” situations.)
To use this new script, add a step into the task sequence with the following command line:
cscript.exe %SCRIPTROOT%\LTISuspend.wsf
When this step runs, you’ll see a popup dialog on the screen:
There will be a “Resume Task Sequence” shortcut on the desktop that should be used to eventually restart the task sequence from the next step after the suspend step. You can do anything you want while the task sequence is suspended, including rebooting, but when you are done you should make sure that you are logged in as the local Administrator account again, and that UAC is still disabled for the local Administrator account.
This same capability is used by MDT 2010 in other ways – more on those later.