Cliff Hobbs - FAQShop.com and Microsoft MVP ConfigMgr/ SMS

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:

1. Edit a task sequence.
2. Right click on the task sequence step or group that you want to copy, then choose “Copy”.
3. Select another node in the task sequence, or in another task sequence.
4. Right click on the node and choose “Paste” to copy the step or group of steps below the selected node.

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:

1. Windows PE started CMD.EXE to run STARTNET.CMD.
2. STARTNET.CMD started WPEINIT.EXE.
3. WPEINIT.EXE initialized networking and optional components, then ran “WSCRIPT.EXE X:\Deploy\Scripts\LiteTouch.wsf”.
4. LiteTouch.wsf started a minimized CMD.EXE, for troubleshooting, then runs the Welcome or Deployment Wizard.

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:

1. Windows PE starts BDDRUN.EXE.
2. BDDRUN.EXE starts WPEINIT.EXE.
3. WPEINIT.EXE initialized networking and optional components, then ran “WSCRIPT.EXE X:\Deploy\Scripts\LiteTouch.wsf”.
4. LiteTouch.wsf runs the Welcome or Deployment Wizard.

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

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.

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:

1. Mount the “vmguest.iso” from Hyper-V (it contains the integration components).
2. Create an application in Deployment Workbench, specifying “D:\Support\x86” as the path for the source files (assuming you mounted the ISO to D:).  Give it a name of something like “Hyper-V Integration Components x86”.  Specify an installation command line of “setup.exe /quiet /noreboot”.  Check the “Reboot the computer after installing this application” checkbox.
3. Add this application to your task sequence.
4. Add a condition to the task sequence step for that application that specifies “VMPlatform equals Hyper-V”.

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.

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.