Michael Niehaus' Windows and Office deployment ramblings
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.)
If you haven’t already seen the official announcement at http://blogs.technet.com/msdeployment/archive/2009/06/26/microsoft-deployment-toolkit-2010-beta-2-is-now-available-for-download.aspx, the bits are now available for download from http://connect.microsoft.com. (If you need the instructions for how to sign up check out http://blogs.technet.com/msdeployment/archive/2008/12/03/a-new-version-is-coming-soon.aspx.) Please try this out and let us know what you think (the sooner the better – the march to RTM has already begun).
MDT 2010 Beta 2 is a significant change over previous versions (even beta 1), so be sure to check out the release notes and updated documentation.
In the coming days, I’ll start posting more messages about the changes in MDT 2010 Beta 2, from the large obvious ones (folders everywhere, PowerShell support, Windows 7 support) to the much more subtle ones.
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.
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.
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.
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.
This is the first in what will probably end up being a long series of posts talking about new features in MDT 2010. These won’t be in any particular order, and I’m sure I’ll miss some so don’t consider this an exhaustive list either.
First up is a new variable, SLShareDynamicLogging. If you set this in CustomSettings.ini to a network path using something like this:
SLShareDynamicLogging=\\server\share\%OSDComputerName%
you’l see something interesting when the deployment is executing. As the deployment progresses, each line being written to the local BDD.LOG on the local computer will also be written to the network location. That will allow you to use something like TRACE32.EXE (http://www.microsoft.com/downloads/details.aspx?FamilyID=948e477e-fd3b-4a09-9015-141683c7ad5f&DisplayLang=en) to follow the progress of the deployment in real time, instead of waiting for the process to complete so that you can check the BDD.LOG.
This doesn’t affect the local log file, which will still be written to as well.
This will work for both Lite Touch and ConfigMgr deployments. Because of the amount of network traffic that could be generated opening, writing, and closing the file for each log line, I wouldn’t recommend using this in production environments when you are performing lots of updates, but it could be very useful in lab environments.
Because organizations are increasingly using at least some virtual machines, it’s useful to be able to detect during an OS deployment if a task sequence is running on a physical machine or a virtual machine. It’s also helpful to know if the physical machine is capable of being a virtualization host. That’s where these enhancements to the MDT 2010 gathering process (ZTIGather.wsf) come from. We now gather these additional details:
IsHypervisorRunning: This variable is set to “True” if the processor reports that a hypervisor (any hypervisor) is currently running. You can use this to detect the presence of a hypervisor-based virtualization solution (e.g. Hyper-V).
SupportsVT: This variable is set to “True” if the processor reports that hardware-assisted virtualization is enabled. (This could also be useful on laptops and desktops, as this is required for the new Virtual PC used as part of the Windows 7 XP Mode software.) Note that SupportsVT will be false when running inside of a VM, as the VM hides the actual hardware support for this.
SupportsNX: This variable is set to “True” if the processor reports that “NX” (no-execute) support is enabled. This is another requirement for Hyper-V and other virtualization solutions.
Supports64Bit: This variable is set to “True” if the processor reports that it supports 64-bit processing (as most do these days). (Technically, this was already in MDT 2008, although through a different variable, CapableArchitecture.)
SupportsHyperVRole: This variable is set to “True” if SupportsVT, SupportsNX, and Supports64Bit are all true. Those are the main requirements for Hyper-V.
IsVM: This variable will be set to true if we can detect that we are running in a virtual machine. (While we can easily figure that out for Hyper-V, Virtual Server, Virtual PC, and VMware, we might not accurately figure this out for other virtualization solutions.)
VMPlatform: This variable will be set to a value that tells you what virtualization platform we detected. Values that are possible:
Hyper-V Beta or RC0 Hyper-V VS2005R2SP1 or VPC2007 VS2005R2 VS2005 or VPC2004 VMware VirtualBox
I make use of these variables inside of a task sequence to automate the installation of the needed Hyper-V integration components. Here’s the process I go through for Lite Touch:
Repeat steps 1-4 for the amd64 platform (using “D:\Support\amd64” for the source). The steps required for ConfigMgr would be slightly different (creating packages instead of applications), but the idea is the same.
You could also use this to automatically install the Hyper-V role on any machine with SupportsHyperVRole=True. Just set up an “Install OS Roles” step with the “SupportsHyperVRole=True” condition.
All of these variables are available for both Lite Touch and ConfigMgr deployments.
As some of you have already discovered, ConfigMgr (RTM and SP1) is unable to capture an image of a Windows Vista SP2 or Windows Server 2008 SP2 operating system. Fortunately, there are now two hotfixes available for this, one if you are running ConfigMgr RTM:
http://support.microsoft.com/kb/969991
And another if you are running ConfigMgr SP1:
http://support.microsoft.com/kb/970093
This fix is already included in the ConfigMgr SP2 beta (which is available from Connect now), but that’s not supported in production environments.
Those of you who have tried have probably already encountered this, but it’s good to state it anyway: Due to the changes made in ConfigMgr SP2 beta to support Windows 7 deployment, MDT 2008 Update 1 (or any previous version) will not work with ConfigMgr SP2 beta. This is primarily due to the use of the new Windows Automated Installation Kit for Windows 7 RC (a.k.a. Windows AIK 2.0).
Once MDT 2010 Beta 2 is released (very soon – yes, I know I’ve been saying that for a while, but it really is), you will be able to use it with ConfigMgr SP2 beta.
There are no plans to release additional updates for MDT 2008 or BDD 2007 – all our efforts are now focused on MDT 2010.