Michael Niehaus' Windows and Office deployment ramblings
The new application model in Configuration Manager 2012 will require administrators to study up on how best to deploy software – this isn’t anything like traditional software distribution like you would find in ConfigMgr 2007.
I recently set up Office 2010 as an application in ConfigMgr 2012 Beta 2. Here are the steps I used – not necessarily the only way to do it, but it worked for me.
First you need to create a new application. If this were a simple MSI, you could just choose the MSI file and the whole process would be simpler. But Office 2010 is a little different than your typical application, so we need to manually define the information.
Now you need to specify some general identification and ownership information. This information is primarily for the ConfigMgr administrator’s use, as the end user can see different information in the software catalog.
Notice the “Allow this application to be installed from the Install Application Task Sequence Action without being manually deployment” checkbox. If you are planning to have MDT install this application dynamically in a task sequence (by specifying the application name in CustomSettings.ini, e.g. Applications001=Office 2010), you will need to check this box.
ConfigMgr provides a software catalog, the Software Center, where end users can choose from optional applications (deployed as “available”, i.e. non-mandatory). You need to specify how the application should show up in the catalog – you can even specify different languages.
The high-level “application” doesn’t say how to actually install the application. That’s done by one or more deployment types (similar in concept to the old package/program concept, where one package can have multiple programs, but in this case each deployment type can have different content – maybe one deployment type is an MSI install and another uses App-V).
Again, because Office 2010 isn’t a typical application, you need to manually specify the deployment type details.
You need to give the deployment type a name.
Now you need to specify the source files, the installation command line, and the uninstall command line.
Since we are deploying Office, the install command line is pretty simple, just specify SETUP.EXE. This assumes that the package source contains an “Updates” folder with an MSP patch file that is configured to install Office without any user intervention.
The uninstall command line is a little harder to come up with – I just copied the command that Office placed in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS on a 64-bit computer). It isn’t very complicated, just specifying “SETUP.EXE /uninstall PROPLUS”. (I haven’t actually confirmed that this command line works, so test appropriately.)
ConfigMgr 2012 will automatically reinstall an application targeted to a computer if it detects that it is no longer present. In order for this to work, you need to specify a detection rule so that ConfigMgr can figure out if it is still installed.
First add a new detection MSI detection rule. In the case of Office 2010, you can check for the present of any of the MSIs that are installed by the Office Setup program. I usually pick the one for the main product, Office Professional Plus, as that uniquely identifies the specific Office SKU that is installed. You browse to the “proplusww.msi” file in the “ProPlus.WW” folder so that you don’t need to type in the MSI product GUID.
Typically you want to install Office in the system content and whether or not a user is logged on (both are mandatory settings for the task sequence to install the application). Neither of these settings are defaults, so be sure to change them:
There are a few more screens, but you can take the defaults for each of them.
Now you have successfully created the application, but you aren’t done yet.
The source files specified on the deployment type still need to be distributed to your distribution points. (You don’t need to do each deployment type separately, just once for the application.) There are different options you can choose for distributing the content. In my case, I’ll just keep it simple and distribute it to every one of my distribution points (one of them):
At this point, you are ready to deploy. You don’t choose to deploy a specific deployment type. Instead, you deploy the application itself. It’s pretty simple in this case, with only one deployment type, as it’s fairly obvious which one will be installed. But if you had multiple deployment types, you would need to specify rules to determine which one is used.
There’s no doubt that this will take ConfigMgr administrators some time to get used to – just one of the big changes coming in ConfigMgr 2012.g
Some of you probably noticed a new download showed up today:
The Windows® Automated Installation Kit (AIK) for Windows® 7 SP1 http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0aee2b4b-494b-4adc-b174-33bc62f02c5d
Be sure to read the “readme” that goes along with this at:
Windows Automated Installation Kit for Windows 7 Readme http://technet.microsoft.com/en-us/library/dd349350(WS.10).aspx
A quick Q&A that I assembled from information in this readme and our own MDT testing:
This supplement is optional. If you do not need to modify the SP1 boot.wim and winre.wim files, you can continue to use the Windows 7 RTM tools, including WinPE 3.0, without installing this supplement. (So MDT and ConfigMgr can deploy WIndows 7 SP1 just fine using Windows PE 3.0.)
There’s no installer provided with this. You need to extract the contents of the download and then XCOPY the files over the top of your existing Windows AIK installation. See the details in the readme.
Yes, this is fully supported. (There is one small issue involving Windows 7 SP1, Windows PE 3.1, and having Windows RE included in your MDT-generated Lite Touch boot images, but if you don’t mind Windows RE not being there, you don’t need to worry about this.)
The Configuration Manager team is still testing Windows 7 SP1 and Windows PE 3.1, so this is unsupported until that testing is completed.
No, you need to download and apply that one (http://blogs.technet.com/b/mniehaus/archive/2011/02/02/usmt-4-0-support-for-office-2010.aspx) separately.
There are two new Lite Touch task sequence templates provided in MDT 2010:
I’ve always been a fan of the thinnest image possible. Taking that to an extreme, that means using the original image straight off the Microsoft media. But over time if you did this you’d find that the time required to apply patches to that image becomes unmanageable. (Case in point: I started up a new laptop for the first time with an OEM-installed image that had hooks to require all patches be applied before first logon. It took three hours for that to happen.)
I’ve also been a fan of doing “just in time” patching, which is something that MDT can do too: Instead of patching the image in advance, you can inject updates offline after the image has been applied to the disk but before it boots for the first time. That does often improve the time required, but it doesn’t eliminate it – it adds time when initially injecting the updates offline, and then more time on first boot as the “online actions” for those “offline patches” are completed (you’ll see the messages on the screen during the first boot showing a percentage complete while this is happening).
So reading between the lines, that means I would suggest always creating your own master image containing at least all the current service packs and patches. (Don’t try to install the OS service pack yourself – just download “slipstreamed” media from the Microsoft licensing website, as that’s the ultimate time-saving technique.) So how should you do this? Well, there are a few ways:
Not surprisingly, MDT 2010 Lite Touch provides a way to implement my preferred method above – and actually multiple methods that can be used. Let’s go through those methods.
This is the easy way, as long as you have good internet bandwidth (all updates are downloaded from the internet) and a direct path to these downloads (as we don’t really support proxy servers in the MDT task sequence), and always want to install all critical updates. (We skip language packs, drivers, and service packs by default, and you can exclude additional updates, but the exclusion process requires a little work.)
To use this method, all you need to do is search your task sequence for the following steps:
Enable both of them, and then build a new image – that’s all there is to it. (Why are there two steps you ask? Well, the first might be required in order for the subsequent application installs to complete; the second might be required to patch the applications, e.g. Office, after it’s installed. If the second step doesn’t need to install any additional patches, it won’t take very long.)
To give you better control over patched put into your image, you may only want to install approved updates. If you are using Windows Server Update Services (WSUS), then you already have such an approval mechanism in place, all you need to do is tell the task sequence to talk to WSUS instead of going to the internet. This is pretty simple too:
Make sure that you have configured WSUS to install updates on unknown computers, because when building a reference computer it is indeed unknown to WSUS at the point the task sequence is executing.
This one is probably the most work, primarily because you need to manually download all the updates that you want to install, and it only works for OS updates (as they are the only ones that can be injected offline). The steps required:
When the task sequence runs, the “Apply Patches” will identify all the updates for the OS and platform being deployed, download them to the client, and update the unattend.xml to inject them. (SETUP.EXE will later call DISM.EXE to do the actual injection after the image has been extracted and applied to the hard drive.) If you want to apply a particular set of patches, you can configure a selection profile with one or more folders containing those updates, then configure the “Apply Patches” step to use that selection profile.
Well, that’s a completely different discussion. Some people do a new image monthly (and probably don’t do much testing on that image each time they recreate it). Some do it every few months. Some do it once a year. You just need to balance the efforts required to build it (easy), test it (not quite so easy), and distribute it (can be really painful) against the added time of applying some updates later.
You can actually use any (or all) of the above methods in that “later” deployment task sequence too:
Some additional links that might be useful:
Windows Update in MDT 2010 « Xtreme Deployment
Approving Windows Updates in an MDT 2010 Standalone Environment
With the release of the Windows AIK for Windows 7 SP1 supplement (see http://blogs.technet.com/b/mniehaus/archive/2011/02/17/windows-aik-for-windows-7-sp1-released.aspx for details), there is a new version 3.1 version of Windows PE available. If you plan to install this update, you need to be aware of an issue when using this with MDT 2010 Update 1.
To explain the issue, first you need to understand the way the MDT boot image creation process works. Fortunately, I explained that almost two years ago (http://blogs.technet.com/b/mniehaus/archive/2009/06/27/mdt-2010-new-feature-7-boot-image-creation-optimized.aspx):
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.
That’s kind of high level, so let’s get a little more specific. First, some background details:
Now, let’s assume that you have Windows 7 RTM x86 installation files present in your deployment share, and you haven’t installed the Windows 7 AIK for Windows 7 SP1 supplement. MDT’s processing when creating a boot image will look like this:
Now, install the Windows 7 AIK for Windows 7 SP1 supplement and update the deployment share:
The actual error will look something like this (repeated for each Windows PE feature pack):
Deployment Image Servicing and Management tool Version: 6.1.7600.16385 Image Version: 6.1.7600.16385 Processing 1 of 1 - Adding package WinPE-HTA-Package~31bf3856ad364e35~x86~~6.1.7601.17514 Error: 0x800f081e The specified package is not applicable to this image. The DISM log file can be found at C:\Windows\Logs\DISM\dism.log Exit code = –2146498530 DISM /Add-Package failed for component C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-hta.cab, rc = -2146498530.
Uh oh – you can’t get past this error to generate boot images. So what should you do? There are two options:
There is one downside to the second option, which goes back to why MDT attempts to use the boot.wim in the first place: The winpe.wim doesn’t contain Windows RE. Since there’s no way to add Windows RE to a Windows PE image built from the Windows AIK winpe.wim, that means the resulting Lite Touch boot WIM won’t have Windows RE. If you aren’t using Windows RE, that doesn’t matter.
Let’s look at some other scenarios too to see what will happen:
Note that this will never be an issue with MDT-generated boot images used with ConfigMgr 2007, as MDT will always use the winpe.wim from Windows AIK when generating these. (ConfigMgr 2007 doesn’t yet support Windows PE 3.1, so don’t install the Windows AIK for Windows 7 SP1 supplement yet if you are using ConfigMgr.)
If there are any additional questions about this, let me know (mniehaus@microsoft.com).
In MDT 2012 Beta 2, a new feature has been added: the ability to integrate the Microsoft Diagnostics and Recovery Toolset (DaRT) 7 into the Lite Touch boot images generated by MDT. The end result is a new option when booted into Windows PE:
And when you choose the “Run DaRT Tools” option, you can see all the tools that DaRT offers:
While you will typically see DaRT positioned as more of a “recovery” tool, you can probably see the “diagnostics” benefits too, using the provided tools to inspect the current computer.
One of the new features in DaRT 7 is especially useful: remote control. Using this you can access a remote computer even while it is in Windows PE. There is a client-side agent for this that is automatically executed as soon as the MDT “Welcome” wizard completes. (We don’t start it before then because you might be using static IP addressing that would be configured through the “Welcome” wizard. If you aren’t planning to use static IP, you can skip the “Welcome” wizard by setting “SkipBDDWelcome=YES” in CustomSettings.ini.) You’ll see this minimized on the bottom left of the screen:
If you restored that to a full window, you would see that it is listening for connections:
From a computer with DaRT installed, you can run the “DaRT Remote Connection Viewer” to make the connection, just type in the ticket number, IP address, and port. (If you’ve enabled the MDT 2012 monitoring feature, to be discussed more in a future blog posting, this process is automated – the connection details are automatically provided.) The connection performance is good, just like you are using a typical RDP connection. (Really, that’s exactly what you are doing – this uses the same underlying protocol as a typical remote desktop connection.)
So how do you enable the DaRT integration? The MDT documentation explains this, although there is an error in step #1, which I’ve rewritten below:
Enable DaRT support Copy the Tools.cab file from the DaRT installation to the appropriate tools folder (either Tool\x86 or Tools\x64) in a deployment share. Click Start, and then point to All Programs. Point to Microsoft Deployment Toolkit, and then click Deployment Workbench. In the Deployment Workbench console tree, go to Deployment Workbench/Deployment Shares In the details pane, click deployment_share (where deployment_share is the name of the deployment share for which you want to enable DaRT support). In the Actions pane, click Properties. The deployment_share Properties dialog box appears (where deployment_share is the name of the deployment share for which you want to enable DaRT support). In the deployment_share Properties dialog box, on the Windows PE tab, select platform (where deployment_share is the name of the deployment share for which you want to enable DaRT support and platform is the processor architecture platform for which you want to enable DaRT support), select the Microsoft Diagnostics and Recovery Toolkit (DaRT) check box, and then click OK. Update the deployment share. As a part of updating the deployment share, the DaRT files are integrated with the Lite Touch Windows PE .wim files, which automatically include Windows RE. When the .wim files are installed on the target computer, DaRT support will automatically be included. Note For more information about updating a deployment share see Update a Deployment Share in the Deployment Workbench Close all open windows and dialog boxes.
So how do you know which folder to copy the “Tools.cab” into? Well, when you install DaRT on an x86 OS, you get an x86 Tools.cab, so that goes into the Tools\x86 folder. Conversely, when you install DaRT on an x64 OS, you get an x64 Tools.cab, so that goes into the Tools\x64 folder. (Yes, that’s less than ideal as it means you need an x86 and an x64 install of DaRT to get both platform files. We’re working on that. In the meantime, you can cheat: you can do an administrative install of the opposite platform using “msiexec.exe /a MSDart70msi”. That will end up creating the folder structure, but not any of the shortcuts, for the opposite platform install.)
Once you’ve copied the files into the right place, you can then see a new Windows PE component in the deployment share properties:
Check the DaRT checkbox (for each platform), apply the changes, update the deployment share, and you’re done.
A few common questions:
DaRT is a component of the Microsoft Desktop Optimization Pack (MDOP). To get DaRT, you need to get MDOP. To get MDOP, you need to have Software Assurance on your client computers (or be using Windows Intune). If you have any questions, contact your local Microsoft account team. (Don’t know who they are? Drop me an e-mail and I’ll find out.)
The DaRT remote control agent writes a file to the X:\Windows\system32 folder with the details needed to make a remote control connection (ticket, IP address, port). This file is found by the MDT “Gather” script (you can see the values in the BDD.LOG). When monitoring is enabled, those details are passed along to the monitoring server and stored, making it easy to initiate remote control with a simple button push:
This initiates the DaRT Remote Connection Viewer with command line parameters with the required details (ticket, IP address, port).
Well, sort of. If you copy the Tools.cab files into the C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Tools\<platform> folder, you will then see the “Microsoft Diagnostics and Recover Tools (DaRT)” option in the MDT wizard for creating a new boot image in ConfigMgr:
So that adds the pieces into the boot image, but you would still need to run them as part of a ConfigMgr task sequence with a command line like “cmd.exe /c start /min x:\windows\system32\RemoteRecovery.exe -nomessage”.
One of the new features that has been added to Lite Touch Installation in MDT 2012 Beta 1 is support for deploying 64-bit Windows to machines configured to use UEFI. So what exactly does that mean? That’s no simple question.
The “Unified Extensible Firmware Interface” (UEFI) specification, created by an industry consortium that includes many influential companies from the PC industry, including Intel, AMD, Apple, Microsoft, Lenovo, Hewlett-Packard, Dell, IBM, American Megatrends, Phoenix Technologies, and Insyde. What common interest do those companies have? They either make firmware for PCs, create operating systems for PCs, or use firmware and operating systems on PCs.
Today, most computers use firmware called the BIOS, the “basic input output system”. This has been around since the original IBM PC. Although hardware has advanced quite a bit, today’s BIOSes still have some serious limitations, including:
UEFI addresses all of these, so it’s only a matter of time before these “legacy BIOSes” make way for UEFI replacements. In fact, many computers have already move to UEFI, including all the latest laptops from Dell, HP, and Lenovo, most Dell and IBM servers, etc. But if these computers (which many of you are probably using today) already have moved to UEFI, how are they still working? Simple, they include a “compatibility support module” (CSM) that enables UEFI firmware to emulate a “legacy BIOS”. With this in place, the operating system can’t even tell the computer supports UEFI.
On most of the UEFI-enabled computers shipping today, “native” UEFI (running without the CSM) is disabled through the configuration of the machine, so you typically need to turn it on in order to get the choice to install using “native” UEFI or “legacy” BIOS emulation.
To make matters a little more confusing, you’ll see references to “UEFI BIOSes” and “BIOS configuration” even with UEFI-enabled computers. It’s not really a “BIOS” any more, but since everyone is used to calling it that, it is bound to happen.
As you can probably gather from the list of limitations above, UEFI is designed to eliminate the limitations of today’s “legacy” BIOS. It provides:
From a Windows perspective, there are some specific benefits that result:
As we move forward, you will likely see more UEFI-only Windows features. Also, don’t be surprised if some future PCs are UEFI-only, providing no BIOS compatibility model at all – once that happens, you must use “native” UEFI.
One additional note: Today, Windows only supports UEFI for 64-bit installations of Windows Vista SP1, Windows 7, Windows Server 2008, and Windows Server 2008 R2. 32-bit installs, and older OSes, must continue to use the “legacy” BIOS support.
There are a few differences that need to be taken into account to deploy Windows to a computer running “native” UEFI. First, there is a different disk layout, shifting from the master boot record (MBR) structure to the new GUID partition table (GPT) structure. GPT supports much larger boot volumes (up to 9.4 zettabytes, or 9.4 billion terabytes) and up to 128 partitions (whereas MBR had a limit of 4).
Next, there is also a different recommended disk layout, as described at http://technet.microsoft.com/en-us/library/dd744301(WS.10).aspx, that involves three partitions:
The “EFI System Partition” (ESP) is roughly equivalent to the small boot partition typically used with Windows 7 today, holding the boot files needed to “bootstrap” the loading of the operating system. Interestingly enough, this partition is formatted as a FAT32 volume because that’s required by UEFI – it can’t read NTFS-formatted volumes. What would you expect to find on this partition? Think of it like the old OEM partitions: It can contain boot loaders (like the ones used to load Windows), OEM firmware utilities, etc. But instead of each OEM using a different setup, all can share this volume. (There are even specific subdirectories that each vendor has agreed to use, see http://www.uefi.org/specs/esp_registry.) There are even “EFI shells” that can be loaded onto this partition (for configuration, browsing, or whatever other creative uses you might find).
There is one thing that you won’t find on the EFI System Partition: a BCD file. When booting from a “legacy” BIOS, the Windows boot loader (bootldr) reads the boot configuration data from the \BOOT\BCD file on the active partition, but with UEFI that information is stored in and read from non-volatile RAM (NVRAM) on the motherboard. The same BCDEDIT.EXE utility that is used to manipulate the BCD file also knows how to manipulate the NVRAM – not surprisingly as the BCD structure was built in anticipation of UEFI.
The next partition, the Microsoft Reserved (MSR) partition, reserves some disk space for Windows to use for certain operations (e.g. converting a basic disk to a dynamic disk).
Overall, these partitions are fairly small, with the ESP at 100MB and the MSR partition at 128MB, so there isn’t much overhead here.
The next challenge then involves bootable CDs and DVDs. Today, you would typically set up an ISO using the El Torito specification, specifying the ETFSBOOT.COM boot sector for the “legacy” BIOS to call to initiate the CD/DVD boot process. With UEFI, there is a new boot sector called EFISYS.BIN. This isn’t an “either-or” proposition though, as you can actually configure a bootable CD or DVD to have both ETFSBOOT.COM and EFISYS.BIN at the same time. (See http://support.microsoft.com/kb/947024 for an example of the OSCDIMG command line syntax to do that.) If the computer supports UEFI and “native” UEFI is enabled, then it will typically choose the UEFI boot sector by default (or prompt and ask which one you want to use), while computers that don’t support UEFI or those that don’t have “native” UEFI enabled will revert to the ETFSBOOT.COM “legacy” boot sector.
The final challenge then is USB media. As with CDs and DVDs, you probably want them to support both “legacy” BIOS and UEFI booting. This is pretty simple to do, formatting the USB media using FAT32 (so it can be read by UEFI) and setting up both “legacy” BIOS and UEFI boot files.
One other complication to mention: What if you have a computer that supports UEFI, but it is currently running an operating system (e.g. Windows XP or Windows 7) through the legacy BIOS compatibility module (CSM), and you want to move it to UEFI. Can you perform a typical “refresh” operation? No, because the “refresh” process can’t even see that the machine supports UEFI when running in compatibility mode, plus there is no way to convert an MBR disk to a GPT disk while preserving the data. So in order to do this type of migration, you need to move the user data off of the disk, then boot from UEFI-enabled media, reformat the disk as GPT, install the new OS, and then restore the user data.
It’s also worth noting that you may need to upgrade any imaging or disk partitioning tools that you are using today to versions that understand GPT disk structures. (This isn’t an issue with Windows AIK and ImageX, as ImageX uses file-based images that don’t care about MBR vs. GPT.)
All of that background information and we still haven’t really talked about what MDT 2012 does in regards to UEFI. So let’s quickly review what MDT 2012 does to enable UEFI support:
In the end, that means that this becomes sort of a “ho-hum” exercise: It should just work, as soon as you figure out how to enable UEFI “native” mode in the firmware (BIOS) settings and then boot in “native” mode. That’s not always as simple as it seems, as the UEFI firmware available today isn’t terribly obvious. (I’ve tried it with Dell and HP laptops. The Dell machine isn’t too hard to figure out, but getting the HP to boot in “native” mode is a little more challenging. See below for more details.)
Some computers will benefit more from UEFI than others, due to the specific hardware, the UEFI firmware being used, etc. So I’ve run a few timings with an HP EliteBook 8440p laptop to illustrate the differences on a typical machine. First, let’s compare the Windows PE boot time, reading the same boot image from a USB key using “legacy” and “native” boot options (stopping the timer once the initial MDT wizard is displayed):
The next test then is operating system installation (measuring how long from finishing the MDT deployment wizard until the summary wizard appears in Windows 7 SP1 x64):
(Note that both of these times should be one minute shorter, but due to a bug in the task sequencing engine there is an extra minute of “nothing going on” added to the end of the deployment process, before the summary wizard is displayed. We’re still working to get that fixed.)
Now let’s compare the “cold boot” time (from powered off to the logon prompt appearing):
And finally, time to resume from hibernate (with no applications running, from powered off to the lock screen appearing):
So it’s not a huge difference, at least with the current UEFI revision on this machine, the USB key performance, and the SATA (non-SSD) hard drive in the system. Imagine though if you were using an SSD…
It was interesting using UEFI on the HP EliteBook 8440p, not nearly as “refined” as I would have expected. First, when you enable UEFI in the BIOS, you get an interesting warning:
The “UEFI Boot” option on this system is provided for development purposes only and is currently NOT fully supported or warranted by HP. Preboot Authentication and Drive Lock are currently NOT supported under UEFI Boot mode. HP strongly recommends disabling Preboot Authentication and Drive Lock before enabling UEFI boot on this system.
Then (ignoring the warning), the UEFI firmware doesn’t seem to be able to detect UEFI-bootable USB keys, so you have to browse to the “bootx64.efi” file on the USB key and explicitly tell the machine to boot from that.
You would think that this “temporary boot choice” would only apply for this single boot (so that when the computer reboots after Windows is installed it will boot from the hard drive), but that’s not the case: It keeps booting from the USB key if you leave it inserted. So I’ve gotten used to pulling the USB key every time the computer reboots, then reinserting it before MDT wants it back so it doesn’t pause and prompt.
And as mentioned previously, there is no UEFI PXE support provided on this computer. (I hope it will work as expected with a dual-boot CD/DVD, offering a choice, but I didn’t have one handy to try.)
I have previously tried this on a Dell Latitude E6410 laptop, which seems to be a little better behaved (although it doesn’t seem to support UEFI PXE boot either). Your mileage may vary, based on computer manufacturer and model, UEFI firmware version, etc.
Both MDT 2010 Lite Touch and ConfigMgr 2007 run the same task sequencer. This task sequencer can run any command that you want, just specify the command line to use. That’s the simple part – the harder part is figuring out what this command line should do. Often the command, a VBScript or PowerShell script, needs to get information from the task sequence itself, accessing variables in the task sequence environment. Remember, these task sequence variables aren’t environment variables – they are distinctly separate, so you can’t use the PowerShell “Env:” drive.
If you are using MDT, building a VBScript that includes the ZTIUtility.vbs script makes accessing task sequence variables pretty simple, as you can then reference something like this in your script:
sValue = oEnvironment.Item("MYVAR")
But PowerShell is now the rage – what if you wanted to do the same thing using PowerShell? Fortunately that’s not too difficult either. Here’s a simple example that gets the value of a particular variable:
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment Write-Host $tsenv.Value("_SMSTSLogPath")
You would then need to set up a task sequence step that ran that PowerShell script. In the Lite Touch case, I would suggest saving the file in the “Scripts” directory on the deployment share, for example as “Test.ps1”. You could then create a “Run command line” step in the task sequence that executes this command:
PowerShell.exe -File "%SCRIPTROOT%\Test.ps1"
If you were using MDT 2010 integrated with ConfigMgr, the same thing would work, but you would need to add the file to the “Scripts” directory of the MDT toolkit package. Alternatively, you could create a new software distribution package containing the PowerShell script, specify to use that package on the “Run command line” step of the ConfigMgr task sequence, and then specify a command line that assumes the script is in the working directory:
If you want to change a task sequence variable (or set a new one), you use the same “Value” method:
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment $tsenv.Value("MyVar") = "My Value"
Maybe you want to do something a little more involved, like create an transcript (log) of the execution of your script. You can use the _SMSTSLogPath variable to determine where to place the file:
# Determine where to do the logging $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment $logPath = $tsenv.Value("_SMSTSLogPath") $logFile = "$logPath\$($myInvocation.MyCommand).log" # Start the logging Start-Transcript $logFile # Insert your real logic here Write-Host "We are logging to $logFile" # Stop logging Stop-Transcript
# Determine where to do the logging $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment $logPath = $tsenv.Value("_SMSTSLogPath") $logFile = "$logPath\$($myInvocation.MyCommand).log"
# Start the logging Start-Transcript $logFile
# Insert your real logic here Write-Host "We are logging to $logFile"
# Stop logging Stop-Transcript
Another useful example is a script that logs the values of all task sequence variables:
# Determine where to do the logging $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment $logPath = $tsenv.Value("_SMSTSLogPath") $logFile = "$logPath\$($myInvocation.MyCommand).log" # Start the logging Start-Transcript $logFile # Write all the variables and their values $tsenv.GetVariables() | % { Write-Host "$_ = $($tsenv.Value($_))" } # Stop logging Stop-Transcript
# Write all the variables and their values $tsenv.GetVariables() | % { Write-Host "$_ = $($tsenv.Value($_))" }
Or you could use the same technique to turn all the task sequence variables into PowerShell variables:
# Determine where to do the logging $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment $logPath = $tsenv.Value("_SMSTSLogPath") $logFile = "$logPath\$($myInvocation.MyCommand).log" # Start the logging Start-Transcript $logFile # Convert the task sequence variables into PowerShell variables $tsenv.GetVariables() | % { Set-Variable -Name "$_" -Value "$($tsenv.Value($_))" } # Write out a specific variable value Write-Host $_SMSTSMDataPath # Get all the variables Dir Variable: # Stop logging Stop-Transcript
# Convert the task sequence variables into PowerShell variables $tsenv.GetVariables() | % { Set-Variable -Name "$_" -Value "$($tsenv.Value($_))" }
# Write out a specific variable value Write-Host $_SMSTSMDataPath # Get all the variables Dir Variable:
(Take out all the extra stuff and this could be reduced to two lines, the one that creates the COM object and the one that calls GetVariables.)
A few other notes worth mentioning:
I’ve been distracted while we worked on fixing the remaining bugs in MDT 2010, which was finally released today. Now it’s time to get back to the discussion on new features in MDT 2010. Next up on the list: improved driver management.
This is really a combination of two features we had already discussed:
with some capabilities added in that we haven’t already discussed. First, there are new options available in a Lite Touch task sequence’s “Inject drivers” step:
Now there are two options when injecting drivers:
You might choose the first option, you might choose the second – it just depends on how you want to do it. You might also choose to do both: you could create multiple “Inject driver” steps and specify different options and different selection profiles on both. For example, you might have one “always apply” selection profile with all the printer drivers that you support (whether currently attached or not) and an “only matching” selection profile for everything else. You could also set up multiple steps and place conditions on them, using different selection profiles and injection options based on the conditions (e.g. make and model).
Of course, if you want the process to be more dynamic, you can override the settings on the fly. I would foresee this being a very common scenario, where you either specify a different selection profile on the fly, or maybe instead specify a list of folders that should be used. To do this, you need to understand the available task sequence variables that can be configured through CustomSettings.ini:
It’s important to understand that these parameters have an “additive” effect. For example, if you specify a selection profile of “Everything” (all folders) and then specify “DriverGroup001=Toshiba\Tecra M400” the net result will be everything. But if you specified a selection profile of “Nothing” (no folders) and “DriverGroup001=Toshiba\Tecra M400” then the result would be just the one folder you specified. (DriverPaths values would be additive as well, but those aren’t recommended.)
So you have options. You can create multiple selection profiles and choose which one to use dynamically, something that gets messy if you just want one folder per selection profile (e.g. per model) since every new folder would require a new selection profile. Or you can choose the “Nothing” selection profile and then specify one or more folders via “DriverGroup”. I believe that will be the most common approach, as you can then do things like:
DriverSelectionProfile=Nothing DriverGroup001=%Make% DriverGroup002=%Make%\%Model% DriverGroup003=Peripherals
If you’ve already experimented with this and have some best practices to share, comments about challenges while implementing this, or just general questions, feel free to e-mail me at mniehaus@microsoft.com.
Yes, I’ve been promising this blog posting for quite some time. And I’ve been working on this for quite some time, but kept getting distracted either by new releases (Windows 7, Windows Server 2008 R2, MDT 2010, SCVMM 2008 R2, etc.) or by the addition of new features to the PowerShell scripts that I’ve been using. But I’m determined to get this first part finished today. Shame sometime can be a motivator :-)
First you need some additional background information. I did a presentation at the Microsoft Management Summit, TechEd US, and TechEd Australia where I talked about how to use MDT 2010, ConfigMgr 2007, and SCVMM together for two main purposes:
So this posting is covering the first part, using MDT 2010 Lite Touch together with SCVMM to create an image factory. Here’s more of a logical picture of what I am talking about:
So imagine that you have created a deployment share in MDT 2010 Deployment Workbench, imported your operating systems and all the other required files, and created multiple task sequences to build your reference images. Now you want a quick and easy way to run all of those task sequences, without having a pile of hardware (so virtual machines are good) and without needing to manually initiate the process on each machine (automating the wizard). That’s where the “image factory” comes in.
To implement this, I created a set of PowerShell scripts to initiate the step-by-step process above. The scripts and their purpose:
These scripts need to know some details from your environment. Rather than hard-coding that information in the scripts themselves, this information is stored in a separate XML file named “MDTImageFactorySettings.xml.” This file contains the following settings:
So what is required to set this up in your environment? First, make sure that your environment is functional, as these scripts won’t magically fix things:
Once that’s done, you can perform the following setup steps:
You should then see that connections are made to the MDT deployment share, the MDT database (the settings for the database are retrieved from the deployment share), and the SCVMM server. A virtual machine will be created for each enabled OS deployment task sequence in the specified folder (and subfolders, recursively), and then the specified number of VMs will be started. As the first VMs complete they will shut down (as long as the task sequence finishes successfully) and new ones will be started, until all task sequences are finished.
As part of the VM creation process, new MDT database entries are created specifying the computer settings, associated to the MAC address of the network adapter for that VM. These settings include:
SkipWizard=YES SkipFinalSummary=YES TaskSequenceID=<the ID of the task sequence to run> AdminPassword=P@ssword DoCapture=YES ComputerBackupLocation=<deployment share UNC>\Captures BackupFile=<task sequence ID>.wim FinishAction=SHUTDOWN
So that specifies to skip all the wizards, run a specific task sequence, use a constant local admin password, capture an image to the deployment share using the task sequence ID to name the WIM file, and to shut down the VM when the whole process is complete.
Here’s what you might expect to see while the VMs are being created:
and while they are running:
That display will keep repeating until all task sequences are complete and the virtual machines shut down.
As the virtual machines complete, there will be two “outputs”: the WIM file that is written to the “Captures” directory of the deployment share, and the VHD file that is still attached to the VM. You can turn that VHD into an SCVMM template and use that when creating new VMs. If you do that, be sure to disconnect the ISO file from the virtual DVD drive and to configure the NIC to specify a dynamic MAC address. (More on that topic in a future blog post when we talk about virtual machine customization.)
That’s pretty much the whole process, but it is worth mentioning a few things in closing:
The “Part 2” blog posting will describe how to perform the same scenario using System Center Configuration Manager 2007 (with or without MDT), but it will take me some time to recover from this posting before I get to that one.
If I messed up the instructions or left something out, please let me know via e-mail, mniehaus@microsoft.com. The scripts attached to this blog entry are provided as-is, and are not supported by Microsoft. See the scripts for the full disclaimer.