The Deployment Guys : Microsoft Deployment

"Easy" List Items for the Microsoft Deployment Toolkit

DeploymentGuys — Fri, 12 Dec 2008 13:00:00 GMT

In MDT rules processing with CustomSettings.ini, some of the items that can be configured are List Items. List Items are essentially multi-valued custom properties. Examples of items that are List Items are Applications in LTI and Packages in ZTI. To define a List Item based property in CustomSettings.ini you add the base property name in the Properties line in the Settings section in the form Propertyname(*) if it is a custom List Item. Then in the section(s) where you want the to define the values for the List Item, you add them in the form of either Propertyname1=value or Propertyname001=value. The numeric suffix should start at 1 or 001 and increment by 1. Below is the example for the Packages List Item property from the MDT help file:

[Settings]
Priority=Default

[Default]
Packages001=NYC00010:Install
Packages002=NYC00011:Install

Since this is an MDT-defined property, it does not need to be listed in the Properties line. Below is an example of a custom List Item (additions in blue):

[Settings]
Priority=ExcludeRootFolders, Default
Properties=MyCustomProperty, UsmtExcludeRootFolders(*)

[Default]
OSInstall=Y

[ExcludeRootFolders]
UsmtExcludeRootFolders001=%ProfilesFolder%
UsmtExcludeRootFolders002=%ProgramData%
UsmtExcludeRootFolders003=%ProgramFiles%
UsmtExcludeRootFolders004=%windir%
UsmtExcludeRootFolders005=C:\_SMSTaskSequence
UsmtExcludeRootFolders006=C:\drivers
UsmtExcludeRootFolders007=C:\MININT
UsmtExcludeRootFolders008=C:\MSOCache
UsmtExcludeRootFolders009=C:\Temp
UsmtExcludeRootFolders010=C:\Winnt
UsmtExcludeRootFolders011=C:\Boot
UsmtExcludeRootFolders012=C:\System Volume Information
UsmtExcludeRootFolders013=C:\PerfLogs

The list of folders in this example is one of several lists that a custom script of mine consumes and generates a custom USMT XML file. When I was first doing this with standard MDT List Items I found several things really frustrating. The first was the numeric suffix. The numeric suffix must be in numeric order and there must be no repeated numbers and no gaps in the number sequences. If you don't do this, not all the items will be processed. I like to keep the folders in alphabetical order so that when I need to add or remove one, it is easy to find the place to add, delete, and make sure I'm not adding a duplicate. So when I have to add an item near the top of the list, painful tedious re-numbering would have to be done.

Also, MDT rules processing expands all variables in values placed on CustomSettings.ini. So the special folder variables at the beginning of the list would get expanded to the value for that folder on the source OS. However, I actually wanted the exact text (without variables being expanded) placed in the List Item.

So to get around these limitations I created a User Exit script to implement what I call Easy List Items. Here is the previous example done as an Easy List Item (additions in green):

[Settings]
Priority=TestEasyListItem, Default
Properties=MyCustomProperty, AddUsmtExcludeRootFolders
[Default]
OSInstall=Y
[TestEasyListItem]
UserExit=EasyListItemExit.vbs
AddUsmtExcludeRootFolders=#AddToListItem("UsmtExcludeRootFolders", "ExcludeRootFolders", "", False)#

[ExcludeRootFolders]
UsmtExcludeRootFolders=%ProfilesFolder%
UsmtExcludeRootFolders=%ProgramData%
UsmtExcludeRootFolders=%ProgramFiles%
UsmtExcludeRootFolders=%windir%
UsmtExcludeRootFolders=C:\_SMSTaskSequence
UsmtExcludeRootFolders=C:\Boot
UsmtExcludeRootFolders=C:\drivers
UsmtExcludeRootFolders=C:\MININT
UsmtExcludeRootFolders=C:\MSOCache
UsmtExcludeRootFolders=C:\PerfLogs
UsmtExcludeRootFolders=C:\Temp
UsmtExcludeRootFolders=C:\System Volume Information
UsmtExcludeRootFolders=C:\Winnt

As you can see from this example, the AddToListItem function in EasyListItemExit.vbs allows you to add all the List Item entries without the numeric suffix. You can now reorder, add, and delete items without worrying about number order or gaps in the numbering. And because this function simply adds to the List Item if it already exists, Easy List Items can coexist with standard MDT List Item entries.

The parameters for the function are the List Item name, the section to process for entries to add, the INI file path (blank for the current INI file), and True (expand variables) or False (don't expand variables). The INI file parameter allows you to query additional INI files for entries. In this example the custom property AddUsmtExcludeRootFolders that causes the AddToListItem function to run will have a value of Success or Failure (if the List Item entries, section name, or INI file cannot be found).

The script can be found in the Zip file below.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Back to basics #3 – Branding the deployment and fixing the 0xc000000e problem

DeploymentGuys — Thu, 20 Nov 2008 11:57:00 GMT

Two more tips for the blog. Actually, one is a tip and the other is the solution to a common problem I see!

During the execution of a task sequence in MDT (normally while creating an image, or deploying one) the computer will display the Installation Progress window in the centre of the screen, on top of all others (see here and here for tips on how to move this window out the way). By default, this window says “IT Organization” in bold letters; something like this:

But wouldn’t it be good if you could change it to look like this?

By simply setting the variable _SMSTSOrgName in the customsettings.ini file, you can replace the text “IT Organization” with anything you like (as long as it is not longer than the width of the progress window!).

For example, the below customsettings.ini file will set the text to “Contoso – Windows Vista Deployment” in the progress window:

[Default]
OSInstall=Y
SkipProductKey=YES
SkipFinalSummary=NO
SkipComputerName=YES
SkipApplications=YES
Computername=%SerialNumber%
_SMSTSOrgName=Contoso – Windows Vista Deployment

If you wish to change the “Running: Lite Touch Installation” text on the window it is not so straightforward. You need to edit the line oEnvironment.Item("_SMSTSPackageName") = "Lite Touch Installation” (usually line number 599) in the script LiteTouch.wsf, replacing the text in the quotes with the text that you want to display. However, you should be aware that if you modify any of the out-of-the-box scripts that are provided with MDT you might no longer be eligible for any support from Microsoft; consult with your local Microsoft contact for more information.

These are one of the first questions I often get asked by customers who have existing MDT servers. While it might seem a rather basic and obvious configuration to some, a lot of people seem to have not found out how to change it and consequently believe that they have to maintain the default setting of “IT Organization”!

Recently, I was trying to use an external USB drive as a media deployment point to boot some computers in a laboratory. Nearly every machine booted fine, but a couple of them always failed with the same not-so-helpful error message:

Status: 0xc000000e
Info: An unexpected error has occurred

A rather poor quality photo of the error taken with the camera in a mobile phone!
Click on the picture to enlarge it.

Failure always occurred at the same point, just as the computer was about to boot WinPE from the RAM-disk, after loading the WIM file into it from the USB device. Initially, it was suspected that there was a problem with the WinPE WIM file that MDT had generated, but running the “Update” command on the deployment point a couple of times did not solve it. Then, memory was suspected, but this proved to be a functioning correctly as well. What was also strange was that the same files booted correctly on other computers. To make matters worse, some computers of the same make and model booted correctly, while other ‘identical’ machines did not??!?!?!

In the end, the problem was solved by upgrading the BIOS on the computer to the latest version published by the manufacturer. It seems that the manufacturer had supplied all new computers but with different BIOS versions, within the same shipment; once the BIOS was upgraded to the newer version the computer booted to WinPE correctly. A word of warning though, you should consult with the manufacturer/hardware supplier before performing any BIOS upgrades. And, don’t forget the adage: “If it ain’t broke, don’t fix it”. From experience, upgrading the BIOS on a machine that does not exhibit any problems may break something that you have already working.

Whilst I had seen the problem before, I never really was able to investigate it because the client always just gave me a new computer and took the old one away. So, thanks to a colleague of mine, David Marín, for solving this (after banging his head against the monitor for quite some time trying to work out what was going on!)

This post was contributed by Daniel Oxley a consultant with Microsoft Services, Spain

Back to basics #2 – 7 Things you shouldn’t do in a LiteTouch Deployment

DeploymentGuys — Fri, 17 Oct 2008 11:48:00 GMT

The below list is a list of the most common mistakes made when creating a LiteTouch task sequence. While not an exhaustive list, it might help to improve your deployment experience when using MDT to create LiteTouch deployments.

1.) Hard-code paths to files/scripts in the task sequence, or inside a script, or referring to the distribution point as Z:\

I would say that this is the number one cause of errors that I see. Because MDT always maps the distribution point to Z:, most assume that it is safe to use this to refer to a file during the deployment process. 99% of the time they are right and it will work fine. However, there are some scenarios when this will generate a failure but it might not be immediately obvious as to why it has failed. So, the solution is to not use Z:\ when specifying paths to files. In the example in the below image, the variable %SCRIPTROOT% instead of Z:. MDT will make sure that the value of this variable will always be to the distribution share, regardless of where it is.

The most common scenario that I have seen this fail in, is when using a Media Deployment Point where the drive Z: does not exist, causing any custom script/processes to fail.

2.) Use non-descriptive names for each task or script, and not fill in the comments field for each task in the task sequencer.

When adding tasks to the task sequencer a lot of people skip the Description box, and also often give the task a rather ambiguous name (plenty of times I have actually seen the task left with the default name i.e. “Run Command Line”). This is not such a problem if it is you that will always administer the server, but when the day comes that someone else needs to look at the task sequence, it will be nigh on impossible for them to work out quickly what each task is doing. So, what could be a simple quick fix will turn into something much longer because they will need to go through the sequencer to work out which is the task that they are looking for.

You can save a lot of work for everyone, including yourself, by filling in Description field for each task you add to the sequencer. You can also later on use the content of this field to help with your documentation.

3.) Use an account for connecting to the deployment share that has full administrative access over the server.

Often, during the development stage of any deployment, most people use the administrator account of the domain in the laboratory, or the local administrator account of the MDT server, as the user that connects to the deployment share during any deployment. Although this works fine, from a security perspective it is pretty terrible, especially as you will often have to share the account credentials with anyone that wants to deploy a machine. If you are using an administrative account in the laboratory, make sure that this practice does not get passed into the production environment at a later stage.

The ideal option is to create an account group (either local to the server or in the domain) that has access to the share, and then add the necessary users to this group. That way they can use their own account credential for deploying a computer without compromising any security on the server. You can also use the auditing options on the server if you want to find out the who, what and when for any computer that was deployed.

4.) Create a LiteTouch task sequence that deploys a computer without any user intervention.

Although this might sound like a great idea as it provides an almost ZeroTouch deployment method, it is actually quite a bad thing to implement. Imagine that you launch a deployment on a computer, no user input is required so the task sequence launches. Just as the drives start to format themselves, you realise that you launched the deployment on the wrong computer. Doh!

I have to confess that this has caught me out before, because of the use of several computers all connected to a keyboard/mouse/monitor switch box. Consequently, I like to leave at least one user-required action at the start of any task sequence and before any ‘damage’ is done. Even if it is just a simple “Welcome to the Windows Vista Deployment project – Press OK to continue” message.

5.) Don’t specify the scripting engine when launching a script file.

As you can see in the image below, MDT will launch a custom VBS script during a deployment cycle, the problem with this example is that the scripting engine has not been specified for launching this script. So, by default, Windows will launch the script with WScript.exe rather than CScript.exe. Most of the time this will be fine and give no problems, however, if you have a script that has the command WScript.echo “My message” in it somewhere then the script will pause, showing a window to the user, and it won’t continue until the user presses the OK button.

You may want this behaviour, i.e. introducing a user intervention at some point in the deployment, but if you don’t then just specify CScript.exe on the command line before the script file (as shown in the images at the top of this post).

6.) Don’t bother creating detailed documentation of the whole process.

Although this won’t break anything, and although it is an extremely dull task, documenting everything that you have done during the creation of your deployment is invaluable. It will save you, and anyone else, a lot of time in the future when you need to make changes to anything on the server.

7.) Create a media deployment point, and then test the super massive 8Gb ISO image with Virtual PC.

Although Virtual PC now has support for large ISO files, it still sometimes has a few ‘issues’ when the files are super big. The issue never manifests itself with the same error message twice though. Instead, you might start seeing problems booting from the ISO file, and then the next time you might get an inexplicable failure in a script. The solution I have always found to work is to simply use the same ISO file with Virtual Server 2005 SP1, or better still, Hyper-V.

Without a doubt, there are plenty more do’s and don’t with MDT. This is simply a consequence of the fact that MDT is so customisable, a sure sign that it is a powerful tool. Feel free to comment on this post with any of your own suggestions that you want to share with everyone else!

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Back to basics #1 – Locking the computer during deployment

DeploymentGuys — Wed, 01 Oct 2008 10:26:01 GMT

This is the first post in a series that will cover some of the more simple/basic tricks that you can do with MDT, but that are often overlooked. I’ll be the first to admit that a couple of them I only learnt recently, even though I have been using BDD/MDT for years.

During the deployment of a computer, MDT will auto-logon Windows using the local Administrator account in order to run its task sequence; during this time, the computer is left logged on as administrator with the desktop unlocked for all to see. Consequently, anyone who happens to walk past the computer during its deployment can use it with full administrative access.

The best way to protect your computer systems from any unwanted access is to simply lock the computer during the Windows phase of the deployment. To do this, just add a “Run Command Line” action to your task sequence, and place the following command in the command line of this action:

rundll32 user32.dll,LockWorkStation

You can place the action at any point in the task sequence, as long as it is executed from within Windows rather than during any Windows PE stage. It doesn’t matter if you have any reboot actions in the task sequence because, even though the workstation is locked, it will still reboot; just remember that you’ll need to execute the command again after reboot in order to lock the computer again. Bear in mind though that you won’t be able to see the summary screen at the end of deployment so you won’t know when it has finished.

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Documenting Your Task Sequences Automagically

DeploymentGuys — Sun, 17 Aug 2008 08:53:00 GMT

Often times, after creating an MDT or SCCM task sequence, you need to document it for yourself or your customers. Usually, this involves creating a table with the groups and steps, extracting their descriptions, identifying conditions and denoting the step actions and variables and then having format it all nicely and with indents denoting hierarchy. All of this information is usually already in the XML of the task sequence and all you're really doing is formatting. You can automatically format XML documents by using an XSL transform with the right logic. In order to do this:

1. Copy the attached file at the bottom of the post to the same folder as your task sequence.

2. Open your task sequence in your favourite text editor.

3. After the first line which should look something like this:

<?xml version="1.0"?> or <?xml version="1.0" encoding="utf-8"?>

enter the following as the second line:

<?xml-stylesheet type="text/xsl" href="tsDocumentorv1.xsl"?>

4. Save your task sequence file and open it in Internet Explorer. Presto! The XSL takes care of formatting, indents and sizing.

Your Task Sequence should look like this:

You can even change the styles of groups and steps easily.

1. Open up the tsDocumentorv1.xsl file

2. Edit the following section:

<STYLE TYPE="text/css">
TD.group { background-color:teal;color:white }
TD.step { background-color:beige }
</STYLE>

Change the colours or any other css properties you choose!

The XSL should work with task sequences created with BDD 2007, MDT 2008 and SCCM 2007.

Please try it out and post comments.

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region. Credit to Michael Murgolo for initial idea and effort.

Task Sequence logic tricks using MDT variables

DeploymentGuys — Mon, 28 Jul 2008 22:59:00 GMT

In my particular part of the Microsoft organization (the CTS testing lab), we install just about every OS, at every service pack level, on both major platforms. Because of this, I created a master template that is used to create dozens of task sequences where the only thing that changes is the OS. To pull this off, I made heavy use of the variables built into MDT2008 to branch my logic accordingly and create a framework in which future additions can simply get dropped into. See the screen shot to get an idea of what this framework looks like in the Workbench:

For this example, I have removed all of the actual Tasks themselves to only show the folder structure for clarity’s sake. But you get the idea. With this in place you can simply add tasks as appropriate into the appropriate level. Keep in mind, any folder level is valid and useful. For example, I have some things that I want only all clients to get, and other things for only all servers to get, so I drop them into the Client and Server folder root levels respectively. Also, something like anti-virus software can be dropped straight into a platform folder, such as x86 or x64 so all OS's regardless of flavour or SP level will get the applications. These are just simple examples, but what’s possible's are limitless.

The philosophy here is the only add logic to your task sequences to the folder level, and not individual task items. This makes keeping track of why things happen (or don’t happen) in your task sequence easier to control, manage, and troubleshoot when you don’t have to examine every individual task item, and can rely on the group level logic of the containing folders. This also means that every time I want to add a new task item to my sequence, I don’t also have to add in the logic to control it, since dropping it in the right folder makes sure it happens in the right OS environments.

So, for example, the top level of this folder has the following logic applied in the Options tab:

Obviously the x64 folder has similar logic with the x86 value changed to x64. For brevity here are the logic values applied to each folder in the first screen shot:

X86 – Architecture equals x86

Client - IsServerOS equals FALSE

Windows XP – OSVersion equals XP

Vista - OSVersion equals Vista

Server – IsServerOS equals TRUE

2003 - OSVersion equals 2003

RTM - SELECT * FROM Win32_OperatingSystem WHERE CSDVersion = ""

SP1 - SELECT * FROM Win32_OperatingSystem WHERE CSDVersion = 'Service Pack 1'

2008 - OSVersion equals 2008

X64 - Architecture equals x64

Client - Etc etc.

Using this framework, we have been able to maintain a single template task sequence that all others are based on regardless of what OS gets thrown at it. There are some other tricks using some other variables as well, but we can cover this in a separate post.

This post was contributed by Roland Sanchez a Lab Engineer with Microsoft Commercial Technical Support Labs, United States.

MDT Script Explanations

DeploymentGuys — Wed, 09 Jul 2008 12:41:56 GMT

I get quite a few emails from people asking if there is a help file that details all of the scripts that are supplied with Microsoft Deployment Toolkit (MDT). The scripts form the engine of a deployment and can also help you to develop a framework for scripts that you need to create for your own tasks. The MDT documentation (installed in \Program Files\Microsoft Deployment Toolkit\Documentation) is a good place to start - but I also point people to the online MDT Reference - which lists the following information for each script supplied:

Name. Specifies the name of the script.
Description. Provides a description of the purpose of the script and any pertinent information regarding script customisation.
Input. Indicates the files used for input to the script.
Output. Indicates the files created or modified by the script.
References. Indicates other scripts or configuration files that are referenced by the script.
Location. Indicates the folder where the script can be found. In the information for the location, the following variables are used:
- program_files. This variable points to the location of the Program Files folder on the computer where Microsoft Deployment is installed.
- distribution. This variable points to the location of the Distribution folder for the deployment point.
- platform. This variable is a placeholder for the operating system platform (x86 or x64).
Use. Provides the command line and options that can be specified.
Arguments and description. Indicate the valid arguments to be specified for the script and a brief description of what each argument means.
Properties. The properties referenced by the script.

You will find each MDT script breakdown at http://technet.microsoft.com/en-us/library/bb979605(TechNet.10).aspx

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Useful Script Number 6 - Pausing the Task Sequence

DeploymentGuys — Mon, 07 Jul 2008 19:59:18 GMT

Have you ever wanted to pause the task sequence in MDT 2008 or ConfigMgr 2007 for a few seconds while something catches up...? I had a requirement to do this recently where I ran a task to close and cancel the Windows Sidebar at the start of the State Restore phase of the task sequencer and then turn the Windows Sidebar back on again at the end of the State Restore phase - I was doing this as the Windows Sidebar can sometimes get in the way of some customisation scripts and you can also see peculiar VB messages when 2007 Office System updates are applied. When the Windows Sidebar is turned back on, there is a couple of seconds before the Sidebar actually appears - yet my task for turning on the Sidebar had returned and the task sequence had moved on...it made be think that there may be other situations where a slight delay in returning to the task sequence may be useful - sure you could add sleep commands to the scripts that your running as commands - but that doesn't help with the tasks that are not scripted - so here is an MDT based script that will pause the task sequence for a specified number of seconds (specified on the command line)

I first have a couple of variables to store the time to pause (strTime) and the script name (strSName - for logging purposes) and the integer argument for the sleep method

Dim strTime, strSName, IntTime

ZTIProcess=1

...I then use a call to ZTIUtility.wsf to set the script name to the strSName variable - this is then used to insert the script name at the start of each line in the log.

strSName=oUtility.ScriptName

...then it's another call to ZTIUtility.wsf to use the arguments class - this makes passing input to the script via the command line easy - in this case I am setting a command line input called "Time"

strTime = oUtility.Arguments("Time")

oLogging.CreateEntry strSName & ": Starting Actions ********************************************* ",LogTypeInfo

...then I check that Time has been specified as a command line input (exit if not) or set the IntTime to number of seconds from the command line x 1000 to get milliseconds

If strTime="" Then
    oLogging.CreateEntry strSName & ": No pause time was specified on the command line.",LogTypeError
    ZTIProcess=90
    Exit Function
Else
    oLogging.CreateEntry strSName & ": Pause time has been set to " & strTime & " seconds",LogTypeInfo

IntTime = strTime * 1000
End if

...I then take the intTime (in milliseconds) and add it to the sleep method to pause the script

oLogging.CreateEntry strSName & ": Task Sequence will pause for " & int(IntTime/1000) & " seconds",LogTypeInfo

wscript.sleep intTime

oLogging.CreateEntry strSName & ": Task Sequence has been paused for " & int(IntTime/1000) & " seconds - returning control to the Task Sequence now",LogTypeInfo

oLogging.CreateEntry strSName & ": Completed Actions ********************************************* ",LogTypeInfo
ZTIProcess = 0
End Function

The script is called CFG-TSPause.wsf so the command line to run it would be CFG-TSPause.wsf /Time:xx (where xx = the number of seconds that you want to pause the task sequence for) Drop the script into your <Deployment Share>\Scripts directory. You can then add the script anywhere in your task sequence by adding a Run Command Line task and specifying the script and the command line input for the number of seconds you want to pause.

As usual, the full script is up on the Deployment Guys SkyDrive:

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Expanding the Scratch Space in Windows PE 2.1

DeploymentGuys — Mon, 12 May 2008 09:40:36 GMT

Recently, I have had to create a bigger scratch space (the MDT X: drive) in Windows PE to deal with the injection of a largish driver during a Windows Vista deployment. The driver in question is the NVidia driver for the Lenovo P60 and P61 and because of the limited scratch space under PE 2.0, this was causing an issue at injection time. There is a scratch file change (registry hack) that can be made to Windows PE 2.0 and below to change the scratch file space from the default 32 Mb - however this is unsupported.

With the introduction of Windows PE 2.1 (supplied with the Windows Automated Installation Kit (Windows AIK) 1.1), the scratch area can be changed from the command line. Below is the process for creating a larger scratch area.

Create a temporary mount folder on your hard disk - MD c:\temp\mount
Go to the Windows AIK tools folder for the platform of PE that you will be changing (ie x86/x64) - CD "Program Files\Windows AIK\Tools\x86"
Mount the default Windows PE image supplied with Windows AIK to your temporary mount folder - imagex.exe /MOUNTRW "C:\Program Files\Windows AIK\Tools\PETools\x86\winpe.wim" 1 c:\temp\mount
Go to the Windows AIK PETools folder - CD "C:\Program Files\Windows AIK\Tools\PETools"
Run the PEIMG command to adjust the scratch size in the mounted image using /SCRATCHSPACE flag to set the size of the drive you want (in this case 128Mb) - peimg.exe /SCRATCHSPACE=128 c:\temp\mount\windows
Change back to the PETools directory - CD "Program Files\Windows AIK\Tools\x86"
Unmount the image and commit the changes - imagex.exe /UNMOUNT /COMMIT c:\temp\mount

That's it - the scratch area will now be set at 128 Mb for all boot images based on this source - which means all boot images created by MDT will now have the set scratch space set (there's a script here somewhere to automate this - so feel free to create and send in your suggestions via the comments area :-)).

Remember that the scratch space is a RAM drive, so the machine being built by this boot environment will need enough memory to deal with Windows PE plus your additional scratch space (so that's approximately 240 Mb plus scratch space).

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Useful Script Number 4 - Silent Installation of Windows AIK 1.1

DeploymentGuys — Wed, 30 Apr 2008 22:25:49 GMT

One of the things that you may need to do - particularly if you are tying to automate the creation of a deployment server in a lab environment - is install the Windows Automated Installation Kit. You may think that because Windows AIK is supplied as .msi files that this would be a simple process, however there is a requirement to manually accept the licensing agreement with no switch to bypass and the msi is coded to only run in full UI mode. Also there is the issue of installing the correct version (x86/x64 versions) on the correct platform.

With this in mind, back when Windows AIK was released (v1.0), I created a small Autoit script to screen scrape the installation - I have now updated this script for Windows AIK 1.1

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_UseUpx=n
#AutoIt3Wrapper_UseAnsi=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

;Copyright (C) 2008
;You have a royalty-free right to use, modify, reproduce and distribute the Sample Application Files (and/or any modified version) in any way
;you find useful, provided that you agree that Microsoft and the author have no warranty, obligations or liability for any Sample Application Files.
;
; AutoIt Version: 3.2.10.0
; Language:       English
; Platform:       Windows
; Author:         Richard Smith - Microsoft UK
; Script Function:
;   Gets CPU architecture then install the Windows Automated Installation Kit (Windows AIK 1.1) silently

#include <Constants.au3>

;Set variables and constants
Dim $Item
Dim $sCmd

;Check the CPU architecture
$Item = @ProcessorArch

; Set the msi to be run based on architecture found
If $Item = "X86" Then
    $sCmd = " waikx86.msi"
ElseIf $Item = "X64" Then
    $sCmd = " waikamd64.msi"
ElseIf $Item = "IA64" Then
    $sCmd = " waikia64.msi"
Else
    MsgBox(0,'Error','The processor type is not supported - Setup will now exit')
    Exit
EndIf

;Run the installation command
Run ("msiexec.exe /i" & $sCmd)

;Program Installation Automation
; Wait for the Welcome window
WinWait("Windows Automated Installation Kit", "Welcome to the Windows Automated Installation Kit Setup Wizard")
Send("!n")

; Wait for the EULA window to become active
WinWaitActive("Windows Automated Installation Kit", "License Terms")
Send("!a")
Send("!n")

; Wait for the Select Install Location window to become active
WinWaitActive("Windows Automated Installation Kit", "Select Installation Folder")
Send("!n")

; Wait for the Confirm Install windows to become active
WinWaitActive("Windows Automated Installation Kit", "Confirm Installation")
Send("!n")

; Wait for the Install Complete window to become active
WinWait("Windows Automated Installation Kit", "Installation Complete")
Send("!c")

; Wait for the Reboot Required window to become active (NO LONGER REQUIRED FOR WAIK VERSION 1.1)
;WinWait("Windows Automated Installation Kit", "")
;Send("!y")

Exit

The first part of the script uses an Autoit function - @ProcessorArch to get the processor type of the machine that the script is being run on. Based on the processor found, the script sets the correct .msi file to run.

The script then uses the Autoit WinWait and WinWaitActive functions to wait for specific screens to appear and then uses the Send function to deliver the correct key stroke to that window.

As usual the Autoit source script (.au3 file) and the compiled executable (x86 .exe file) are available from the Deployment Guys SkyDrive - the executable must be placed into the Windows AIK 1.1 source directory (where the .msi files are) and run from there.

This post was contributed by Richard Smith - a Senior Consultant with Microsoft Services, UK.

Getting help when you are really stuck

DeploymentGuys — Fri, 25 Apr 2008 10:42:00 GMT

A lot of people think that because BDD and MDT are free products they are not eligible for support from Microsoft. This question seems to crop up quite often and people are often surprised when I point out the truth!

So, in true A-Team spirit (i.e. "If you have a problem, if no one else can help, and if you can find them, maybe you can hire the A-Team."):

If you have a problem with BDD or MDT, if no one else has been able to help you, maybe you can try Premier Support!

It is simple, just call the support number which you can find here: http://www.microsoft.com/services/microsoftservices/srv_premier.mspx.

Make sure that you state that you have a BDD/MDT issue because if you talk about deployment you might be routed to a different queue. Also it is worth mentioning that Premier Support have a different style to the A-Team in that they don't use guns and explosions to fix things. Thanks to the MSDeployment guys who first highlighted this problem on their blog. Of course, please carrying commenting on our blog as well!

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Updating System Center Configuration Manager 2007 for Windows Vista Service Pack 1 and Windows Server 2008 Deployment

DeploymentGuys — Fri, 18 Apr 2008 21:58:00 GMT

The SCCM 2007 Operating System Deployment components use the Windows Automated Installation Toolkit (WAIK) for creating, managing, and deploying Windows Imaging (WIM) images. SCCM 2007 setup installs the Windows Vista RTM WAIK (WAIK 1.0) during installation if it is not already installed. In order to deploy Windows Vista SP1 and Windows Server 2008 with SCCM 2007, the WAIK must be updated to the latest version (WAIK 1.1) This process is documented in this Microsoft Knowledge Base article: http://support.microsoft.com/?id=950782. (SCCM 2007 Service Pack 1 will natively support these operating systems when it becomes available.)

The first two steps in this process are very straight forward: uninstall WAIK 1.0, then install WAIK 1.1. The second two steps document a method of creating new WinPE 1.1 Boot Images and importing them into SCCM. The WinPE Boot Images need to be version 1.1 to support deploying Windows Vista SP1 and Windows Server 2008. If you are using the latest version of the Microsoft Deployment Toolkit 2008 with SCCM 2007 integration enabled (v4.1 released in March is the latest), you can use the menu option that MDT adds to the SCCM Boot Images node for creating new boot images and avoid step 3.

However, if you are not using MDT and want to create new default SCCM boot images, the method documented in step 3 of KB 950782 is likely to give you about as much pleasure as a root canal. This method uses WBEMTest, a tool for testing WMI that is built into the OS. If you've used WBEMTest before, the experience is usually something you don't want to repeat. While it is very flexible for testing many WMI options, it is very tedious to use to execute a simple WMI method (as is needed to create new default SCCM boot images). So to alleviate this pain, I used the WMI Code Creator and the SCCM SDK to create a VBScript that turns the long mouse click tedium of WBEMTest into a few second operation.

To use this script, log on to the SCCM site server as an SCCM administrator. Create a folder that will hold the new boot images. If you are going to import the boot images from this folder, you may want to create it in the location when you keep your package source folders. (The folder from which the WinPE WIM file is imported becomes the boot image package data source.) Copy the ExportDefaultBootImages.vbs (listed below) to a folder on the server and edit the strExportFolder variable to point to the folder you just created. Then run then script from a command prompt with cscript.exe. When the script is finished you will have two sub folders, one containing an x86 boot image and one containing an x64 boot image. You can then either import the images as documented in step 4 of KB 950782 from these folders or move them to another location and import from there.

ExportDefaultBootImages.vbs

' Windows Script Host Sample Script
' ------------------------------------------------------------------------
' Copyright (C) 2008
'
' You have a royalty-free right to use, modify, reproduce and distribute
' the Sample Application Files (and/or any modified version) in any way
' you find useful, provided that you agree that Microsoft and the author
' have no warranty, obligations or liability for any Sample Application
' Files.
' ------------------------------------------------------------------------

'This script replaces the procedure in step 3
'of this Microsoft Knowledge Base article:
'http://support.microsoft.com/?kbid=950782

strExportFolder = "E:\BootImages"

Set objFSO = CreateObject("Scripting.FileSystemObject")

'Export x86 boot image
strx86Folder = strExportFolder & "\Default_WAIK_1_1_x86"
If Not objFSO.FolderExists(strx86Folder) Then objFSO.CreateFolder(strx86Folder)
ExportBootImage "x86", strx86Folder & "\WAIK_1_1_boot_image_x86.wim", 1

'Export x64 boot image
strx64Folder = strExportFolder & "\Default_WAIK_1_1_x64"
If Not objFSO.FolderExists(strx64Folder) Then objFSO.CreateFolder(strx64Folder)
ExportBootImage "x64", strx64Folder & "\WAIK_1_1_boot_image_x64.wim", 1

Function GetSiteCode

GetSiteCode = ""

    strComputer = "."
    Set objWmiSmsNamespace = GetObject("winmgmts:\\" & strComputer & "\root\SMS")
    Set objSmsProviderLoc = objWmiSmsNamespace.InstancesOf("SMS_ProviderLocation")

    For Each location In objSmsProviderLoc
        If location.ProviderForLocalSite = True Then
                GetSiteCode = location.SiteCode
        End If
    Next

End Function

Sub ExportBootImage(strArchitecture, strExportImagePath, intImageIndex)

strComputer = "."
Set objWmiSmsSiteNamespace = GetObject("winmgmts:\\" & strComputer & "\root\SMS\site_" & GetSiteCode)

' Obtain an instance of the the class
Set objShare = objWmiSmsSiteNamespace.Get("SMS_BootImagePackage")

    ' Obtain an InParameters object specific
    ' to the method.
    Set objInParam = objShare.Methods_("ExportDefaultBootImage").inParameters.SpawnInstance_()

    ' Add the input parameters.
    objInParam.Properties_.Item("Architecture") = strArchitecture
    objInParam.Properties_.Item("ExportImagePath") = strExportImagePath
    objInParam.Properties_.Item("ImageIndex") = intImageIndex

    ' Execute the method and obtain the return status.
    ' The OutParameters object in objOutParams
    ' is created by the provider.
    Set objOutParams = objWmiSmsSiteNamespace.ExecMethod("SMS_BootImagePackage", "ExportDefaultBootImage", objInParam)

    ' List OutParams
    Wscript.Echo "Out Parameters for " & strArchitecture & " boot image : "
    Wscript.echo "ReturnValue: " & objOutParams.ReturnValue

End Sub

References

How to replace Windows AIK version 1.0 with Windows AIK version 1.1 when you use System Center Configuration Manager 2007
http://support.microsoft.com/?id=950782

Automated Installation Kit (AIK) for Windows Vista SP1 and Windows Server 2008 (WAIK 1.1)
http://www.microsoft.com/downloads/details.aspx?familyid=94BB6E34-D890-4932-81A5-5B50C657DE08&displaylang=en

TechNet Magazine Utility Spotlight: WMI Code Creator
http://technet.microsoft.com/en-us/magazine/cc161034.aspx

System Center Configuration Manager 2007 Software Development Kit (SDK) v4.0
http://www.microsoft.com/downloads/details.aspx?FamilyId=064A995F-EF13-4200-81AD-E3AF6218EDCC&displaylang=en

This post was contributed by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region.

"Up-ping" the uptime of your Lite-Touch server

DeploymentGuys — Mon, 31 Mar 2008 13:10:00 GMT

I like the lite-touch installation (LTI) feature of MDT, it think it's great and is very impressive as it allows clients to easily see the benefit that they will gain by using MDT to create and deploy their images. I can go on-site with a customer to demo the product and have a basic MDT server configured to deploy Windows Vista and Office 2007 (both with the most basic of configurations) over the network in their laboratory, all in one day. Admittedly, the setup won't do much else because it lacks all the details but, as a demo, it works well. However, one thing that LTI does not offer is 'high-availability'; something that Systems Center Configuration Manager excels at.

In one of my previous posts I wrote about using DNS to create 'distribution points'-like behaviour in LTI scenarios. That post got quite a bit of feedback, so with this post I want to 'steal' another Configuration Manager feature so that it can be applied to a LTI scenario, namely, making your MDT server highly available. With this post you will be able to improve the reliability of your deployments by ensuring that your single point of failure (your MDT server) is always available, simply by clustering your MDT distribution share. As before, I once again recommend Systems Center Configuration Manager as the product of choice if you need a highly-available platform for installing your images as it really is the best option available; the content offered in this post could never replace the functionality offered by Systems Center Configuration Manager.

Windows clustering has been around for many years now, and most people understand how it works; the basic concept is shown in the image below. An active server provides services to the network with a passive server in standby waiting to take over from the active server if it ever stops responding. The change-over, or more correctly called: failover, happens very quick so most people would not even notice that a server has failed. With each version of the Windows Server operating system Microsoft has improved the cluster service, so I will try and stay as generic as possible with this post.

Figure1: a generic diagram showing a typical cluster configuration

With this in mind, an excellent way to improve the availability of your MDT server is to copy the distribution$ folder onto a cluster! All your client computers would then connect to the virtual name of the cluster and use the distribution point for the installation of your operating system image, rather than connect to the MDT server. The only change that you would need to make would be to edit the bootstrap.ini file from your MDT configuration in order to include the virtual name of the cluster rather than the hostname of the MDT server; you'll need to make this change manually because MDT will put it's own hostname there by default. Note that even if you installed MDT onto one of the nodes of the cluster, it would still place the hostname of that node into the bootstrap.ini file rather than the cluster virtual name. This is because MDT is not a cluster aware application.

Example of the bootstrap.ini file for use on a cluster:

[Settings]
Priority=Default

[Default]
DeployRoot=\\MYVIRTUALCLUSTER\Distribution$

You will need to create a cluster shared folder resource that shares the folder as "distribution$", without this part it won't work! Also, you will need to manually synchronise any changes you make on the MDT server with the files on the cluster, MDT won't do this for you.

Finally, one important thing to bear in mind is that, in the event of a failover, any existing deployments *might* fail depending on where they are in the process and what they were doing at the time of failover. If a client computer is applying the WIM image when the active server fails, then the process will also fail. If however, the active server fails over during a point in the deployment process when a client computer was not actually using the deployment point then you may find that the process will continue seamlessly, although your mileage will vary with this as it really is an unknown due to various factors in play during failover.

In a follow-up post I will explain how to work with the files on the cluster directly from MDT, so that MDT can update the files onto the clusters shared storage without the need for you to copy the files over manually when you make changes. Stay tuned!

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Useful Script Number 2 - Move the Task Sequence Window

DeploymentGuys — Wed, 19 Mar 2008 13:33:00 GMT

Have you ever created a build and had to pop up a message to the user/technician? - or had to start an HTA application to request some kind of user input during the build or deployment process? If you have then you will know that the task sequence window sits centre screen and everything else pops up behind. This is because the task sequence windows is fixed to the top of the Z-order so that no other window can overlap it...

Recently I had to create an DVD based deployment for a customer where I wrote an HTA application that prompted the user to switch DVDs. I hit this issue where my app was popping up behind the task sequence window and users were missing the prompt - so I set about developing a solution - and the solution I came up with was to move the task sequence window to the top left corner of the screen every time the task sequence starts - I soon found that it wasn't as simple as it initially sounded....

I set about creating a script in Autoit (http://www.autoitscript.com/) to move the window to the correct co-ordinates based on current screen resolution. I like to use Autoit for window manipulation tasks as it has a whole raft of inbuilt functions for automating desktop tasks - which usually makes it easier and quicker than writing the equivalent in VB script.

The Autoit code is listed below:

#NoTrayIcon

;zCFG-MoveTaskWindow
;Version 2.0 March 2008
;Reruns itself and returns - only works when compiled

If $CmdLine[0] = 0 Then
    ; Rerun ourself and let this copy return to the task sequencer
    Run('"' & @AutoItExe & '" rerun')
    Exit
EndIf

Sleep(5000)        ; Time for the first script to return
If WinExists("Systems Management Server") Then
    $size = WinGetPos("Systems Management Server")
    Mousemove($size[0]+50, $size[1]+50)
    MouseClick("left")
    WinMove("Systems Management Server", "", 0, 0)
    Exit
Else
    Exit
EndIf

The first line #NoTrayIcon stops the Autoit icon appearing in the system tray when the script runs. The next section:

If $CmdLine[0] = 0 Then
    ; Rerun ourself and let this copy return to the task sequencer
    Run('"' & @AutoItExe & '" rerun')
    Exit
EndIf

configures the script to re-start itself after returning control to the task sequencer (i will explain why later in the post) before running the code to carry out the window move - having access to Autoit creator and fellow UK MCS consultant Jon Bennett really helps in these situations :-) and Jon came up with this re-spawning code.

The final section:

causes the script to pause for 5 seconds before looking for the existence of the task sequence window (using the Autoit function WinExists). The title of the windows is Systems Management Server, so if found the script gets its position (using the Autoit function WinGetPos). The script then move the mouse to the location of the window +50 pixels on each axis so that the mouse pointer is inside the task sequence window - it then clicks (Autoit function MouseClick) to select the window before the WinMove function moves it to the top left of the screen

The reason for re-spawning the script is to return control to the task sequence, which in turn means that the compiled executable that Autoit creates from this script can be added to the task sequencer in the same way that any other script is run:

The script only works when it is compiled so i have added the script (.au3 file) and the compiled Autoit executable (.exe) to the download location below:

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Lite-Touch Deployments - Making them a bit more scalable

DeploymentGuys — Wed, 12 Mar 2008 12:24:00 GMT

Take a look at the image below, which is a fairly common scenario for a company; let's call them Contoso. Contoso has multiple offices around the country that all connected to their head office, some with high-speed network connections and others with relatively slow ones. Contoso is planning their Windows Vista rollout which will be driven from their central office, in this example, Madrid. Contoso wants to deploy their Windows Vista image that they created on their MDT server in Madrid but with a lite-touch installation to all their clients nationwide.

The problem they need to solve is one of distributing their image file to all company workstations without saturating the network at the time of deployment. Unfortunately, they do not have the infrastructure of SMS or Systems Center Configuration Manager which would make this problem fairly trivial, so they need to create a solution that will allow them to deploy their image created in Madrid to all clients without using up all available network bandwidth. The biggest problem that they will have with a lite-touch scenario is that all clients will contact the MDT server directly by hostname (as configured in the file bootstrap.ini that MDT created and placed inside the WinPE image file) to download the corporate WIM image which, in Contoso's case, is 6 Gb in size. This will work fine in the Madrid office because the MDT server is there and there is high-speed network connectivity between the server and the workstations. But when Contoso starts the deployment in their office in Bilbao, which only has a 256kb network connection to Madrid, it will almost certainly fail due to network bandwidth/latency issues.

So, how can Contoso deploy their image to their satellite offices without bringing down the network at the same time? (this really does sound like a possible Microsoft MCP question, doesn't it??!!)

Not too long ago Adam Shepherd wrote a great article about making a BDD server scalable using technologies such as DFS-R and SQL Replication. It really is a good article because I am often asked by clients about this topic, and I have always used Adam's article to show how it can be done. The problem is that some of my clients do not always implement the recommendations in Adam's article as they see it as too complicated, expensive, or do not like the idea of updating the Active Directory schema in order to implement DFS-R.

Well, there is another possibility that exists which would achieve a similar result and does not require any network or schema changes; DNS Round-Robin. Round-Robin requires the installation of no additional servers, no extra hardware, no extra licenses and probably no changes to any infrastructure/configuration; all it needs to work in this scenario is the simple tick of 2 checkboxes (which are pre-selected with the default configuration of DNS) on the DNS server. In the properties of the DNS server, just make sure that the following two options are selected from the "Advanced" tab:

Enable round robin
Enable netmask ordering

You should also double-check that you have "Strict Name Checking" disabled as well. If it isn't you might find that the remote computer refuses any connection made to it via a DNS alias rather than it's real name. The reason for the error is that an attempt was made to access \\AnAlias\AShare using the DNS A record but the actual hostname of that target was "XYZ", and strict name checking was enabled. See here for more information.

The first step to get it all setup is to replicate the MDT file share to a server in each of the remote offices. Contoso will need to do this manually, and a good way to do it would be with the command ROBOCOPY source destination /MIR. A scheduled task could then be set up to update any changes made to the share with this command as well. An alternative to copying the data over the network is to burn it to a DVD and then send the DVD to the remote office. From there someone in the remote office could copy the data from the DVD onto the local server. Afterwards, Contoso creates an A record for each remote server but with the same hostname as the MDT server in Madrid, just with relevant remote server's IP address. That's it!

To test the round robin configuration, simply use the NSLOOKUP command from any computer in a remote office. If setup correctly, your NSLOOKUP request should always return the IP address of the nearest server, i.e. the server that is hosting the replicated MDT share in the same location as the computer that made the query; if you repeat the NSLOOKUP command, the returned result should always be the same. If not, then a different IP address will be received for each repetition of the NSLOOKUP command. If this is the case then you probably do not have the two checkboxes configured on the DNS server, as mentioned previously. An interesting 'choice' for this setup is that you could even host the MDT share on a Windows XP workstation in a remote office if no server existed and one could not be installed; however, there are 2 major downsides of using a workstation OS rather than a server OS:

Windows XP is limited to 10 concurrent network connections at any one time.
You will certainly see lower network performance from the workstation when compared to a server.

If Contoso wish to use PXE to load the WinPE boot image then they will also need to replicate the WDS server as well to each office which introduces other complications and might not make this solution a viable choice. Otherwise, Contoso simply boots each machine from the MDT-generated boot CD, and upon boot WinPE will map a drive using the MDT server's hostname which, when resolved by DNS, will actually be the server on the same subnet that holds a replica of the MDT share. From then on, the process will continue over the local office network and should thus run significantly faster.

Finally, I would like to add two very important points that will need considering. The first is that Contoso will still need to replicate the MDT database (assuming one is used) to the remote servers, or they could leave it in the central office and maintain the cost of the network traffic for the database. The amount of data transferred from the DB would be far less than the amount used to deploy the image so this might not be too much of an issue. The second is that DNS round robin is not fault-tolerant. The DNS server will not be aware that any of the remote servers are offline and will continue issuing the IP address of a server regardless of it's status. This would lead to failures in the deployment process for an office if the local resource is not available when an attempt to install a computer was made.

Alternatively, you could use a MEDIA deployment point and do away completely with the need for replicated the data between offices and what I have just described. This is also a great way of deploying image files created with MDT but the disadvantage is that every time your deployment point changes you will need to recreate and re-distribute all the deployment DVD's as well; which could prove costly and hard to maintain. Using the method outlined here offers more flexibility and, once setup, would require very little administrative effort (you could program a task to replicate only the changes to the remote shares over night when there would be more network bandwidth available).

In conclusion, what has been (albeit briefly) explained in this post is a useful way of improving the chances of a successful operating system deployment in situations where you need to send large amounts of data over slow or unreliable network connections. My recommendation will always be to use SMS or System Center Configuration Manager if faced with this scenario as they are designed to handle extremely well these situations, and therefore the use of round-robin could never replace the functionality that these technologies provide.

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain