The Deployment Guys : MDT

Preventing OEM builds from Accidentally Performing Mini-Setup without the Task Sequence

DeploymentGuys — Tue, 01 Dec 2009 16:48:00 GMT

When you pre-load an OEM build on machines, they are usually set-up to perform Mini-setup as soon as they come up. Customers sometimes have difficulties ensuring that these machines boot to WinPE using boot media or PXE rather than simply performing Mini-setup...(read more)

Approving Windows Updates in an MDT 2010 Standalone Environment from a ConfigMgr Software Update Point

DeploymentGuys — Thu, 22 Oct 2009 01:06:00 GMT

You’ve no doubt read some of the benefits around using the Software Update Point features of ConfigMgr. However, if you are already using MDT standalone as an Image Engineering environment – there is sometimes a duplication in having to manage software...(read more)

Making WinPE Wait for Network in LTI Deployments

DeploymentGuys — Wed, 23 Sep 2009 21:24:00 GMT

In some environments, network device drivers and/or infrastructure take longer to load than WinPE waits before running the task sequence. This can be due to congested DHCP scopes, link negotiation latency or slow loading network drivers. In these cases, it is necessary to delay the start of the task sequence until a valid IP address is obtained otherwise the task sequence will fail.

In order to do this, you can create a script that will wait for a valid IP address before continuing on with the LiteTouch Wizard. The LiteTouch Wizard is launched using a RunSynchronous command in the Unattend.xml file for WinPE. MDT obtains this file from %ProgramFiles%\Microsoft Deployment Toolkit\Templates folder. Here are instructions for doing this with MDT 2008 and an x86 Boot Image (UPDATE : MDT 2010 includes a wait by default):

1. Navigate to %ProgramFiles%\Microsoft Deployment Toolkit\Templates and rename the Unattend_PE_x86.xml file to Unattend_PE_x86.old

2. Copy the attached Unattend_PE_x86.xml file to %ProgramFiles%\Microsoft Deployment Toolkit\Templates .

3. Navigate to your Distribution Share and copy the attached WinPEFiles folder there.

4. Navigate to the WinPEFiles\Windows\System32 edit the file “WaitForIP.bat” replace <SERVERNAME> with the name of your WDS Server.

5. In the Deployment Workbench , navigate to the Deploy Node and right click on the LAB deploy point and choose Properties.

6. In the Windows PE tab under extra directory to add and Browse to the WinPEFiles folder created in step 3. Note: navigate to the WinPEFiles and not any of the sub directories. Click OK to apply the change.

7. In the Deployment Workbench , right click on the LAB Deploy point and choose “Update”

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region.

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.

Using Device Aliases for Hardware Specific Application Installation

DeploymentGuys — Mon, 21 Sep 2009 12:36:00 GMT

In my last post I described how to use and extend model aliases. In this installment I show how you can do the same thing with individual devices or groups of devices.

Defining setting, applications, etc. by model works in many instances. However, there are time when a device may or may not be installed in any particular model (e.g. broadband wireless adapter) and you may need to install an application only if the device is installed. I had just such a need at my current customer and this led me to develop a concept of Device Aliases. I define a Device Alias as a friendly name given to a device or groups of devices for which you want to configure the same settings, applications, etc.

I used a simple version of the concept of a Device Alias in my post on Windows XP Tablet PC Edition 2005 Single-Image Deployment. The IsTablet property is actually a device alias for the defined set of digitizer devices. IsTablet is set to True when one of the digitizer devices if present.

[Settings]
Priority=IsTabletCheck, Default
Properties=MyCustomProperty, TabletPnpIds, IsTablet

[IsTabletCheck]
TabletPnpIds=ACPI\WACF004,ACPI\WACF008,ACPI\MAI3310,ACPI\FUJ02E5
UserExit=ZTI-DetectHardwareExit.vbs
IsTablet=#DetectDevices("%TabletPnpIds%")#

You could use this method as is to create additional device aliases. However, once you have more that a few of these, the Properties line in CustomSettings.ini would become loaded with Device Alias variables. So I took a different approach for defining multiple Device Aliases. Before I explain, I want to note that for my new design to work you will need to fix a bug that I found in one of the MDT scripts. I explain how to fix the script at the end of this post.

I decided to design the new implementation with its own INI file called DeviceAlias.ini. Below is a sample INI file that I created for testing this on my laptop (Lenovo T61p).

[HIDClass]
WacomDigitizer=ACPI\WACF004,ACPI\WACF008

[Display]
NVIDIAQuadroFX570M=PCI\VEN_10DE&DEV_040C,PCI\VEN_10DE&CC_030000

[Net]
Intel82566MMGigabit=PCI\VEN_8086&DEV_1049,PCI\VEN_8086&CC_020000

[NoPrefix]
IsTablet=ACPI\WACF004,ACPI\WACF008,ACPI\MAI3310,ACPI\FUJ02E5

[NoPrefix-Mouse]
ThinkPadUltraNav=ACPI\IBM0057

This INI file is organized in to sections. The sections contain the <Device Alias entry>=<Plug and Play ID list> entries. These section names are used in a prefix that is added to the device alias. When the prefix is added the Device Alias is of the form Device_<section name>_<device alias entry>. In this example, a machine with an NVIDIA Quadro FX570M display adapter would have a the Device Alias of Device_Display_NVIDIAQuadroFX570M set to True. I add the prefix to make it easier to find and sort Device Alias entries in the Make and Model entries in the MDT Database. As in the example above, I like to use the device class as the prefix. However, the section names can be anything you want. For Device Alias variables that you don’t want to have a prefix (IsTablet is a good example), just begin the section name with NoPrefix.

I have updated ZTI-DetectHardwareExit.vbs with two new functions to process the Device Alias INI file. The first, SetDeviceAliases, reads each section in the INI file and evaluates each entry to determine if any of the Plug and Play IDs in the list for the entry is installed. It then sets the Device Alias for that entry to True or False based on that determination. Finally, for any Device Alias that is True (the device is present), the Device Alias is added to a list item called DeviceAlias. This list item is used in the database queries. Below is an example of the CustomSettings.ini entries to use SetDeviceAliases.

[Settings]
Priority=SetDeviceAlias
Properties=MyCustomProperty, SetDeviceAliases

[SetDeviceAlias]
UserExit=ZTI-DetectHardwareExit.vbs
SetDeviceAliases=#SetDeviceAliases("DeviceAlias.ini")#

Even a Device Alias is insufficient to identify which hardware specific applications should be installed during a deployment. At minimum, you usually also need to know the operating system version and architecture for which the applications are targeted. For example, for an NVIDIA Quadro FX570M display adapter you would typically have one or more hardware specific applications for Windows XP x86, one for Windows Vista x86, one for Windows Vista x64, etc. To that end I created a new composite property called DeviceOSArchAlias. which combines the Device Alias, OSVersion, and Architecture properties. (I refer to this property by a newly minted acronym called DOAA. Sounds like something Homer Simpson would say. J ) I create this by using another new function, SetDeviceOSArchAliases, using CustomSettings.ini entries like the ones below:

[Settings]
Priority=SetDeviceAlias
Properties=MyCustomProperty, SetDeviceAliases, SetDeviceOSArchAliases

[SetDeviceAlias]
UserExit=ZTI-DetectHardwareExit.vbs
SetDeviceAliases=#SetDeviceAliases("DeviceAlias.ini")#
SetDeviceOSArchAliases=#SetDeviceOSArchAliases("DeviceAlias.ini")#

SetDeviceOSArchAliases also adds the DOAA entries that are True to a list item called DeviceOSArchAlias to be used in the database queries. So for the DeviceAlias.ini shown above, SetDeviceOSArchAliases run on a Windows Vista x64 machine that an NVIDIA Quadro FX570M display adapter, an Intel 82566MM Gigabit ethernet adapter, and a ThinkPad UltraNav pointing device will create the following properties and list items:

Device Alias Properties
Device_HIDClass_WacomDigitizer = False
Device_Display_NVIDIAQuadroFX570M = True
Device_Net_Intel82566MMGigabit = True
IsTablet = False
ThinkPadUltraNav = True

DeviceAlias List Item
DeviceAlias001 = Device_Display_NVIDIAQuadroFX570M
DeviceAlias002 = Device_Net_Intel82566MMGigabit
DeviceAlias003 = ThinkPadUltraNav

DOAA Properties
DOAA_Display_NVIDIAQuadroFX570M_Vista_X64 = True
DOAA_Net_Intel82566MMGigabit_Vista_X64 = True
ThinkPadUltraNav_Vista_X64 = True

DeviceOSArchAlias List Item
DeviceOSArchAlias001 = DOAA_Display_NVIDIAQuadroFX570M_Vista_X64
DeviceOSArchAlias002 = DOAA_Net_Intel82566MMGigabit_Vista_X64
DeviceOSArchAlias003 = ThinkPadUltraNav_Vista_X64

To define settings, applications, roles, etc. in the MDT Database based on either the DeviceAlias or DeviceOSArchAlias, enter the DeviceAlias or DeviceOSArchAlias as the Model in the Make and Model entries in the Database. You can put anything you want in the the Make field in the database entries. I enter the alias type (DeviceAlias or DeviceOSArchAlias) so that I can sort the entries by type. Here is a screen shot with a DeviceAlias or DeviceOSArchAlias entry for a device in the Panasonic Toughbook model CF-U1 that I have been working with recently.

You would then use CustomSettings.ini entries like the ones below. (The DatabaseVariables section below is there because I like to use variables for the common database parameters in the other sections so that the actual values only have to be changed in the DatabaseVariables section. Note that some lines may wrap on the screen depending on your display resolution.)

[Settings]
Priority=SetDeviceAlias, DatabaseVariables, DASettings, DAPackages, DAApps, DAAdmins, DARoles, DOAASettings, DOAAPackages, DOAAApps, DOAAAdmins, DOAARoles
Properties=MyCustomProperty, MASQLServer, MADatabase, MANetlib, MASQLShare, SetDeviceAliases, SetDeviceOSArchAliases

[SetDeviceAlias]
UserExit=ZTI-DetectHardwareExit.vbs
SetDeviceAliases=#SetDeviceAliases("DeviceAlias.ini")#
SetDeviceOSArchAliases=#SetDeviceOSArchAliases("DeviceAlias.ini")#

[DatabaseVariables]
MASQLServer=SQLS001
MADatabase=MDT
MANetlib=DBNMPNTW
MASQLShare=Logs$

[DASettings]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelSettings
Parameters=DeviceAlias
DeviceAlias=Model

[DAPackages]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelPackages
Parameters=DeviceAlias
DeviceAlias=Model
Order=Sequence

[DAApps]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelApplications
Parameters=DeviceAlias
DeviceAlias=Model
Order=Sequence

[DAAdmins]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelAdministrators
Parameters=DeviceAlias
DeviceAlias=Model

[DARoles]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelRoles
Parameters=DeviceAlias
DeviceAlias=Model

[DOAASettings]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelSettings
Parameters=DeviceOSArchAlias
DeviceOSArchAlias=Model

[DOAAPackages]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelPackages
Parameters=DeviceOSArchAlias
DeviceOSArchAlias=Model
Order=Sequence

[DOAAApps]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelApplications
Parameters=DeviceOSArchAlias
DeviceOSArchAlias=Model
Order=Sequence

[DOAAAdmins]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelAdministrators
Parameters=DeviceOSArchAlias
DeviceOSArchAlias=Model

[DOAARoles]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelRoles
Parameters=DeviceOSArchAlias
DeviceOSArchAlias=Model

In a computer replacement and/or OS change (different source and destination OS) scenario you will likely only want to set the DeviceOSArchAlias and do the DOAA database queries using a Gather step in the State Restore phase. This is because you will almost always want the hardware specific settings, application installations, etc. based on the target model and operating system.

Fixing the Database Class Bug

As I explained earlier, there is a bug in the MDT Database class that needs to be fixed before the database queries above will work. If a parameter in the database section is a list item like DeviceOSArchAlias, then the Database class Query function does not use the translated column name (Model in this case) and the query fails.

The problem appears in line 2691 in the MDT 2008 Update 1 version of ZTIUtility.vbs or line 549 in the MDT 2010 RTW version of ZTIDataAccess.vbs . This line is:

tmpClause = sElement & " IN ("

The query works if the line is changed to:

tmpClause = sColumn & " IN ("

If you need to make this change, be sure to edit not only the copies in your current deployment shares but also edit the copy in %ProgramFiles%\Microsoft Deployment Toolkit\Templates\Distribution\Scripts so that new deployment shares will get the fix as well.

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

Using and Extending Model Aliases for Hardware Specific Application Installation

DeploymentGuys — Thu, 10 Sep 2009 11:30:00 GMT

In a post on his blog from a few years ago (found here) Ben Hunter described a method of creating and using model aliases using BDD/MDT User Exit scripts. A model alias is a friendly name assigned to cover multiple model variations in a manufacturer’s computer model family. I have been going through this exercise for my current customer and have found some limitations to using Ben’s process exactly as is.

First, the MDT properties Make and Model (which come from the Manufacturer and Model properties of the Win32_ComputerSystem WMI class) are no longer sufficient or necessarily the most convenient properties for determining the model alias. For example, distinguishing between Microsoft’s different types of virtual machines (Virtual PC, Virtual Server, Hyper-V) requires looking at Version property of the Win32_BIOS WMI class. Also, many current Lenovo computer models already have the Version property of the Win32_ComputerSystemProduct WMI class filled in with a friendly name for the model. Here is a sample of a User Exit script with an expanded SetModelAlias function that uses this additional information. (Note that some lines may wrap on the screen depending on your display resolution.)

Function UserExit(sType, sWhen, sDetail, bSkip)

    oLogging.CreateEntry "USEREXIT:ModelAliasExit.vbs started: " & sType & " " & sWhen & " " & sDetail, LogTypeInfo

    UserExit = Success

End Function

Function SetModelAlias()

    oLogging.CreateEntry "------------ Initialization USEREXIT:ModelAliasExit.vbs|SetModelAlias -------------", LogTypeInfo

    sMake = oEnvironment.Item("Make")
    sModel = oEnvironment.Item("Model")
    SetModelAlias = ""
    sCSPVersion = ""
    sBIOSVersion = ""

    Set colComputerSystemProduct = objWMI.ExecQuery("SELECT * FROM Win32_ComputerSystemProduct")
    If Err then
        oLogging.CreateEntry "Error querying Win32_ComputerSystemProduct: " & Err.Description & " (" & Err.Number & ")", LogTypeError
    Else
        For Each objComputerSystemProduct in colComputerSystemProduct
            If not IsNull(objComputerSystemProduct.Version) then
                sCSPVersion = Trim(objComputerSystemProduct.Version)
                oLogging.CreateEntry "USEREXIT:ModelAliasExit.vbs|SetModelAlias - Win32_ComputerSystemProduct Version: " & sCSPVersion, LogTypeInfo
            End If
        Next
    End if

    Set colBIOS = objWMI.ExecQuery("SELECT * FROM Win32_BIOS")
    If Err then
        oLogging.CreateEntry "Error querying Win32_BIOS: " & Err.Description & " (" & Err.Number & ")", LogTypeError
    Else
        For Each objBIOS in colBIOS
            If not IsNull(objBIOS.Version) then
                sBIOSVersion = Trim(objBIOS.Version)
                oLogging.CreateEntry "USEREXIT:ModelAliasExit.vbs|SetModelAlias - Win32_BIOS Version: " & sBIOSVersion, LogTypeInfo
            End If
        Next
    End if

    ' Check by Make
    Select Case sMake

        Case "Dell Computer Corporation", "Dell Inc.", "Dell Computer Corp."

            ' Use Model with spaces removed
            SetModelAlias = Replace(sModel, " ", "")

        Case "IBM", "LENOVO"

            ' Check by Version property of the Win32_ComputerSystemProduct WMI class first
            If Not sCSPVersion = "" Then
                Select Case sCSPVersion
                    Case "ThinkPad T61p"
                        SetModelAlias = "ThinkPadT61"
                    Case Else
                    ' Use Version with spaces removed
                    SetModelAlias = Replace(sCSPVersion, " ", "")
                End Select
            End If

            ' Check by first 4 characters of the Model

            If SetModelAlias = "" Then
                sModelSubString = Left(sModel,4)
                Select Case sModelSubString
                    Case "1706"
                        SetModelAlias = "ThinkPadX60"
                    Case Else
                        SetModelAlias = sModel
                        oLogging.CreateEntry "USEREXIT:ModelAliasExit.vbs|SetModelAlias - Alias rule not found. ModelAlias set to Model value." , LogTypeInfo
                End Select

            End If

        Case "Matsushita Electric Industrial Co.,Ltd."

            If Left(sModel,5) = "CF-U1" Then
                SetModelAlias = "CF-U1"
            Else
                SetModelAlias = sModel
                oLogging.CreateEntry "USEREXIT:ModelAliasExit.vbs|SetModelAlias - Alias rule not found. ModelAlias set to Model value." , LogTypeInfo
            End If

        Case "Microsoft Corporation"

            ' Microsoft virtualization technology detected, assign defaults

            SetModelAlias = "Hyper-V"

            ' Try to determine more specific values using Version property of the Win32_BIOS WMI class

            Select Case sBIOSVersion
                Case "VRTUAL - 1000831"
                    SetModelAlias = "Hyper-VBetaorRC0"
                Case "VRTUAL - 5000805", "BIOS Date: 05/05/08 20:35:56 Ver: 08.00.02"
                    SetModelAlias = "Hyper-V"
                Case "A M I - 2000622"
                    SetModelAlias = "VS2005R2SP1orVPC2007"
                Case "A M I - 9000520"
                    SetModelAlias = "VS2005R2"
                Case "A M I - 9000816", "A M I - 6000901"
                    SetModelAlias = "WindowsVirtualPC"
                Case "A M I - 8000314"
                    SetModelAlias = "VS2005orVPC2004"
                Case Else
                    SetModelAlias = sModel
                    oLogging.CreateEntry "USEREXIT:ModelAliasExit.vbs|SetModelAlias - Alias rule not found. ModelAlias set to Model value." , LogTypeInfo
            End Select

        Case "VMware, Inc."

            SetModelAlias = "VMware"

        Case Else
            If Instr(sModel, "(") > 2 Then
                SetModelAlias = Trim(Left(sModel, Instr(sModel, "(") - 2))
            Else
                SetModelAlias = sModel
                oLogging.CreateEntry "USEREXIT:ModelAliasExit.vbs|SetModelAlias - Alias rule not found. ModelAlias set to Model value." , LogTypeInfo
            End if

    End Select

    oLogging.CreateEntry "USEREXIT:ModelAliasExit.vbs|SetModelAlias - ModelAlias has been set to " & SetModelAlias, LogTypeInfo

    oLogging.CreateEntry "------------ Departing USEREXIT:ModelAliasExit.vbs|SetModelAlias -------------", LogTypeInfo

End Function

Second, even a model alias is insufficient to identify which hardware specific applications should be installed during a deployment. At minimum, you usually also need to know the operating system version and architecture for which the applications are targeted. For example, for a Lenovo T61 you would typically have one hardware specific application list for Windows XP x86, one list for Windows Vista x86, one list for Windows Vista x64, etc. To that end I created a new composite property called ModelOSArchAlias. which combines the ModelAlias, OSVersion, and Architecture properties. (I refer to this property by a newly minted acronym called MOAA. Catchy, isn’t it. J ) I create this by using CustomSettings.ini entries like the ones below:

[Settings]
Priority=SetModelAlias, Default
Properties=MyCustomProperty, ModelAlias, ModelOSArchAlias

[SetModelAlias]
UserExit=ModelAliasExit.vbs
ModelAlias=#SetModelAlias()#
ModelOSArchAlias=%ModelAlias%_%OSVersion%_%Architecture%

So for a Lenovo ThinkPad X60 running 32-bit Windows Vista using my SetModelAlias function and this CustomSettings.ini, the MOAA would be ThinkPadX60_Vista_X86.

To define settings, applications, roles, etc. in the MDT Database based on either the ModelAlias or ModelOSArchAlias, enter the ModelAlias or ModelOSArchAlias as the Model in the Make and Model entries in the Database. You can put anything you want in the the Make field in the database entries. I enter the alias type (ModelAlias or ModelOSArchAlias) so that I can sort the entries by type. Here is a screen shot with a ModelAlias and ModelOSArchAlias entry for the Panasonic Toughbook model CF-U1 that I have been working with recently. (Ignore the DeviceAlias and DeviceOSArchAlias entries. I’ll describe those in my next post. J )

[Settings]
Priority=SetModelAlias, DatabaseVariables, MASettings, MAPackages, MAApps, MAAdmins, MARoles, MOAASettings, MOAAPackages, MOAAApps, MOAAAdmins, MOAARoles
Properties=MyCustomProperty, MASQLServer, MADatabase, MANetlib, MASQLShare, ModelAlias, ModelOSArchAlias

[SetModelAlias]
UserExit=ModelAliasExit.vbs
ModelAlias=#SetModelAlias()#
ModelOSArchAlias=%ModelAlias%_%OSVersion%_%Architecture%

[DatabaseVariables]
MASQLServer=SQLS001
MADatabase=MDT
MANetlib=DBNMPNTW
MASQLShare=Logs$

[MASettings]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelSettings
Parameters=ModelAlias
ModelAlias=Model

[MAPackages]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelPackages
Parameters=ModelAlias
ModelAlias=Model
Order=Sequence

[MAApps]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelApplications
Parameters=ModelAlias
ModelAlias=Model
Order=Sequence

[MAAdmins]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelAdministrators
Parameters=ModelAlias
ModelAlias=Model

[MARoles]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelRoles
Parameters=ModelAlias
ModelAlias=Model

[MOAASettings]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelSettings
Parameters=ModelOSArchAlias
ModelOSArchAlias=Model

[MOAAPackages]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelPackages
Parameters=ModelOSArchAlias
ModelOSArchAlias=Model
Order=Sequence

[MOAAApps]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelApplications
Parameters=ModelOSArchAlias
ModelOSArchAlias=Model
Order=Sequence

[MOAAAdmins]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelAdministrators
Parameters=ModelOSArchAlias
ModelOSArchAlias=Model

[MOAARoles]
SQLServer=%MASQLServer%
Database=%MADatabase%
Netlib=%MANetlib%
SQLShare=%MASQLShare%
Table=MakeModelRoles
Parameters=ModelOSArchAlias
ModelOSArchAlias=Model

In a computer replacement and/or OS change (different source and destination OS) scenario you will likely only want to set the ModelOSArchAlias and do the MOAA database queries using a Gather step in the State Restore phase. This is because you will almost always want to hardware specific settings, application installations, etc. based on the target model and operating system.

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

Keeping An Eye On USMT Progress v0.2

Daniel Oxley — Wed, 02 Sep 2009 18:41:00 GMT

Back in June I posted a script that I’d written that displays the progress of the USMT capture and recover phases in a neat HTML window off to one side of the screen; particularly useful if you are capturing/recovering large amounts of data because otherwise it looked like the USMT progress had hung due to the progress bar not moving along for quite some time.

While the script I wrote worked fine I was not 100% happy with it, mostly because it ate up too many CPU cycles, which could sometimes slow down the actual USMT progress; an effect that you would never want to happen! The problem was that there was no quick and easy way to parse the last few lines of a text file in VBScript without first reading in all the previous lines. This meant that as the log file grew, my script took longer and longer to run. So, I took it back to the drawing board, and reworked the innards of it to produce version 0.2!

This time, the script runs extremely quickly and it will barely register on the CPU, meaning that it shouldn’t slow anything else down. It still requires the same parameters to be passed to it when adding to the task sequence, which are detailed below. To add it to the task sequence, simply add the following Run Command Line action before the USMT capture or restore actions (or both):

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTCapture.prg”

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTRestore.prg”

It also has one other very important dependency. You must download tail.exe from the Windows Resource Kit and place it in the Tools folder of the MDT deployment share, along with this script. You can get the tool here, it doesn’t matter that it is the 2003 version, I have tested it on Windows 7 and it works fine. If you don’t put tail.exe in the tools folder, then the script will fail.

The next update might take a while to get round to doing, but I want to remove the requirements for the command-line parameter, and have the script find the progress file on it’s own. Also, it would be good to display more information rather than just the current position in the progress, perhaps an extra line that informs what the current task is that is being run. Also, a few cosmetic changes wouldn't go amiss, but I am a techie not a graphic designer!

Attached to this post is the script file.

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

Location Deployment Wizard for ConfigMgr 2007

DeploymentGuys — Mon, 17 Aug 2009 19:37:00 GMT

When working on deployment projects, there is often a requirement for a workstation to be customised on a location by location basis. Common workstation customisations which are applied in this manner include:

Localisation settings (locales, keyboard settings, time zones, Windows (Windows Vista/Windows 7) language injection
Domain membership/organisational unit join information
Location based applications to be installed
Site or location based administrator groups or accounts that need to added to the local administrators group

The Microsoft Deployment Toolkit (MDT) and its accompanying database offers features to tailor a workstation based on its location during a deployment. The MDT Database allows locations to be defined and a set of location specific settings can be stored against each entry. When a workstation is been deployed, an MDT database lookup determines its location and collects the relevant build settings for that location. The location is determined by carrying out a lookup of the default gateway on the target workstations assigned NIC against default gateways assigned to locations in the MDT Database. To learn more about the Microsoft Deployment Toolkit and the database supplied with MDT see http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx

During a mass deployment it is quite common for workstations to be built in central locations and then to be shipped to other sites for use. In these circumstances, the MDT Database location functionality may not be as useful as any database location lookups will return settings for the site at which the workstations are being built and not the site to which the workstation will be eventually shipped.

A solution to this is to use a location deployment wizard when using the MDT Database along with System Center Configuration Management (ConfigMgr) 2007 Operating System deployments (OSD) in zero touch scenarios. A location deployment wizard is an HTA that is displayed to the user/build engineer at the start of the workstation deployment process to display the location in which they are currently situated. If the location is the site at which the workstation will be based they can click next and the deployment will continue applying all the deployment settings for that site. However, the wizard allows an “override” for the detected location and allow the user/build engineer to select another location from the MDT Database. Overriding the detected location will apply all of the selected location deployment settings from the MDT Database to the workstation despite it not being at that location. This solution allows workstations to be built in a central location whilst being fully customised for their destination locations.

The location deployment wizard is an HTA that is stored in a customised ConfigMgr OSD boot image and is executed before a ConfigMgr task sequence starts. The HTA uses Operating System Media Pre-Execution Hooks (http://technet.microsoft.com/en-us/library/bb694075.aspx) to place itself before the task sequence window. The location deployment wizard allows inputs that are stored as a ConfigMgr task sequence variable. The location variable can then be used by a ConfigMgr deployment task sequence to recover settings from the MDT Database throughout the deployment (During ZTIGather phase).

Pre-Requisites

The following pre-requirements should be configured in your deployment environment:

System Center Configuration Management 2007 (RTM, SP1, R2 or SP2 beta) environment configured for OSD deployments.
Microsoft Deployment Toolkit 2008 / MDT 2010 Workbench + Database hosted on Microsoft SQL 2005 or 2008 (Express / Standard / Enterprise)
ConfigMgr 2007 console with integrated MDT console functions
The MS SQL Database hosting the MDT Database should be configured to allow NamedPipes
A share should be setup on the MDT Database server for authentication when using NamedPipes from a WinPE environment by using the SQLShare$ method.
ConfigMgr “Network Access Account” should have db_datareader access to the MDT SQL Database
Another AD account should be created which is assigned db_datareader access to the MDT Database. Note This account will be stored in a plain text file in the ConfigMgr OSD Boot image. This account should be limited to just db_datareader access on the MDT SQL Server and denied all other rights on the domain

Location Deployment Wizard Setup Steps

Download the location deployment wizard attached to this post and extract the files to a temporary location on the computer/server which has a ConfigMgr 2007 Console with integrated MDT console functions. There are 4 components which need to be configured in your environment for this solution to operate:

Configure the Bootstap.ini file
Create a custom boot image
Configure Location settings in the MDT Database
Configure CustomSettings.ini file

1. Configure the Bootstrap.ini file

The Bootstrap.ini file contains the settings required by the Location Deployment Wizard to make the initial connection to the MDT Database. These settings need to be configured for your environment:

Edit the Bootstrap.ini file in the Location Deployment Wizard\LocationDeploymentWizard folder. This file is used by the location deployment wizard HTA to connect to the MDT Database for the first time:
- Replace <USERNAME> with the AD account created for reading the MDT Database in the pre-requirements e.g. CONTOSO\MDTDBReader
- Replace <PASSWORD> with the password of the account entered above
- Replace <SQL SHARE FOR AUTHENTICATION> with the name of a shared folder on the MDT Database server e.g. \\MDT01.contoso.com\SQLShare$
- Replace <MDT DATABASE SEVER> with the fully qualified domain name of the MDT Database server e.g. mdt01.contoso.com
- Replace <MDT DATABASE NAME> should be replaced with the instance name of the MDT Database in SQL e.g. MDTDB

2. Create a custom boot image

During OSD deployments a WinPE boot image provides the environment for deploying a workstation. ConfigMgr 2007 provides default boot images in the Operating System Deployment -> Boot Images node in the console. A new custom boot image needs to be generated containing the location deployment wizard HTA and its supporting files – this will execute when the boot image first loads on a workstation:

Create a new custom boot image in the ConfigMgr console using the “Create Boot Image Using Microsoft Deployment” wizard:

Follow the wizard, selecting the default options. On the Image Options page set the Extra Folder to Add as the Location Deployment Wizard folder which is found in the root of the files extracted earlier
Complete the wizard selecting the default options. ConfigMgr/MDT will now create a new customised boot image with the location deployment wizard included.
Assign the boot image to the OSD deployment task sequence that you wish to use the location deployment wizard with:

3. Configure location settings in the MDT Database

Locations and their associated settings need to be configured in the MDT SQL Database, these are typically configured through the interface in the MDT workbench. In the MDT workbench go to the Database >> Locations Node. Here you can add as many different locations as are required for your environment.

For a location to be available to the location deployment wizard it must be assigned at least one default gateway. This can be found in a locations properties on the Identity tab.
If no default gateways for a site are initially known then assign 0.0.0.0 as the default gateway for that location. Although this site will never be automatically detected by the location build wizard, it can be manually selected.
In the Details tab of a locations properties use the SERVERA property to populate sites or country e.g. UK. This is used by the location deployment wizard to break down the locations so there is not just one long list:
Populate any other deployment site settings as required for your deployment including locales, time zones, keyboard settings, UI Language, location specific apps and location specific admins.

4. Configure CustomSettings.ini file

The CustomSettings.ini (http://technet.microsoft.com/en-us/library/bb977690.aspx) is a rules file which is used to automate deployments and setup how to query settings from the MDT Database. The location deployment wizard has its own CustomSettings.ini which is used during Gather phases in a ConfigMgr task sequence to retrieve location settings from the MDT Database. The CustomSettings.ini file included in the supplied location deployment wizard must be customised to your environment:

Edit the CustomSettings.ini file located in the root of the extracted files. The customsettings.ini file is a rules file is used by the MDT script ZTIGather.wsf to gather all of the location based settings from an MDT database:
- All instances of <FQDN MDT DATABASE> should be replaced with the fully qualified domain name of your MDT Database server e.g. mdt01.contoso.com
- All instances of <MDT DATABASE NAME> should be replaced with your MDT Database name in SQL e.g. MDTDB
- All instances of <AUTHENTICATION SHARENAME> should be replaced by your shared folder name on the MDT Database server e.g. SQLShare$

Once the customsettings.ini file has been updated it should be wrapped up into a ConfigMgr package (typically this is the MDT Settings package) and sent to all distribution points on your network which will be used for OSD. This rules package must be used by all Gather phases in your MDT integrated deployment task sequence to gather location settings from the MDT Database.

This post was contributed by Mark Hooks and Richard Smith, consultants with Microsoft Services – U.K.

Persisting ConfigMgr Packages during a Task Sequence

DeploymentGuys — Fri, 17 Jul 2009 17:30:00 GMT

The MDT Task Sequences for System Center Configuration Manager 2007 use a clever technique to download and persist the MDT Files package during each phase of the Task Sequence. The Use Toolkit Package step uses the ZTISCCM.wsf script to copy the contents of the package to a WDPackage subfolder of the _SMSTaskSequence folder. The Task Sequencer maintains this folder (the path of which is held in the _SMSTSMDataPath variable) for holding the logs and downloaded package contents. So the WDPackage folder will continue to exist until the next reboot. MDT places the path to the WDPackage folder in the DeployRoot variable.

Doing this prevents repeated download of the MDT Files every time the execution of an MDT script is needed. My customer wanted to be able to used the same technique for their custom scripts. They maintain a package of custom scripts so that they are not mixed in with the MDT scripts. This will allow them to update/replace the MDT Files package as needed without having to worry about their custom scripts.

One way of doing this would be to simply create a Run Command Line step (after the Use Toolkit Package step) that simply does an xcopy of the files/folder in the package to either DeployRoot or ScriptRoot or a subfolder of those paths. You can then call your scripts relative to the DeployRoot or ScriptRoot variable.

I wanted to provide my customer with maximum flexibility for this so I created a custom script called ZTI-PersistSccmPackage.wsf. This script should be copied to the root of the package along with a copy of the MDT script ZTIUtility.vbs. The command has the following syntax:

cscript ZTI-PersistSccmPackage.wsf /pathvar:<path variable name> /xcopy:"<additional xcopy switches>"

The /pathvar switch sets the name of the variable the can be used to reference the path to the persisted files. If you specify a variable name that is either DeployRoot, ScriptRoot, or ToolRoot, the script will copy the contents of the package to the corresponding location in the WDPackage folder created by the Use Toolkit Package step. If you specify any other variable name, the script will create a randomly named folder in the _SMSTSMDataPath location, copy the contents of the package to that folder, and set a Task Sequence variable pointing to that folder path with the variable name specified with the /pathvar switch. For example, if you had a package of custom scripts you wanted to persist in their own folder, you would could run the script like this:

cscript ZTI-PersistSccmPackage.wsf /pathvar:CustomScriptRoot

You could then reference your scripts using the CustomScriptRoot variable. For example, if the package contained a script called MyScript.wsf you could run it from a Run Command Line step using the following syntax without having to add the package to the step:

cscript "%CustomScriptRoot%\MyScript.wsf"

The optional /xcopy switch is used to specify additional switches for the xcopy command. By default, the script uses xcopy with the following switches: /s /e /h /y /c. For example, if you wanted to add the /d switch to filter the copy by date or add the /exclude switch to exclude files from the copy, you would specify those using the /xcopy switch.

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

Single WIM Deployment of Windows XP Professional and Tablet PC Edition (and Other Operating Systems)

DeploymentGuys — Mon, 13 Jul 2009 22:55:00 GMT

Update 2009-07-17: Corrected some errors in the application settings in the Extracting the Sysprep Files section that occured because I did not make all necessary changes after doing a copy/paste.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

In my post on August 3 2009, I promised in an upcoming post I would show you how to create a single WIM file that contains several XP images with a single MDT Lite Touch Task Sequence (rerun four times). Additionally, I said that I would show you how you can deploy these images from that WIM file onto the correct target hardware using either a single MDT Lite Touch Task Sequence or a single MDT Zero Touch Task Sequence in SCCM. Well, that day is finally here!

Image Build: MDT Setup

For building and capturing images, I prefer to use the MDT Lite Touch process over Systems Center Configuration Manager 2007. You have more control over the process, you can have tasks with a visible UI for testing and troubleshooting, and since the Task Sequencer runs as the built-in Administrator account you can configure settings that can get propagated to Default User settings. So the process I'm about to describe will only use MDT Lite Touch for building and capturing images into the single WIM file. Also, everything I describe in the post was done with MDT 2008 Update 1. Once MDT 2010 has released or is close to releasing, I’ll blog what, if any, changes are necessary.

As I described in the August 3rd post, the "Single Image" process for XP Pro/Tablet PC Edition will not be supported for Service Pack 3. Because of this, I moved my current customer's XP deployment process back to separate images. Since they have to support hardware that requires both types of XP ACPI HALs, this deployment process required four XP Images:

Windows XP Professional with ACPI Uniprocessor HAL (APIC HAL)
Windows XP Tablet PC Edition 2005 with ACPI Uniprocessor HAL (APIC HAL)
Windows XP Professional with Advanced Configuration and Power Interface (ACPI) PC HAL (PIC HAL)
Windows XP Tablet PC Edition 2005 with Advanced Configuration and Power Interface (ACPI) PC HAL (PIC HAL)

If you only require a subset of these images (perhaps you don’t need to support Tablet PCs or PIC hardware, etc.), you can modify the steps that follow accordingly.

Using traditional sector-based imaging tool supporting four images would require four times the disk storage and four times the WAN traffic to replicate those images around. However, using file-based WIM images that can take advantage of "single instance storage" that allows you to store all four of these images in a single WIM file that will only be slightly larger than any single image.

All of the above images can be generated from a single MDT Task Sequence by simply running it four times on either the correct computer hardware or by using the correct XP Product Key. Unfortunately, if you try this with MDT 2008 “out of the box”, the process will fail during the attempt to capture the second image. This is because the MDT 2008 script that does the image capture, ZTIBackup.wsf, is hard-coded to use an image name of the format <TaskSequenceID><drive letter>Drive (e.g. XPPROSP2CDrive). Since an image name must be unique within a WIM file, when ZTIBackup.wsf tries to append the next image with the same image name, it fails. Therefore, to capture four image into on WIM with MDT 2008 as is you would need four identical Task Sequences. And you would need to remember to specify the same WIM file in the deployment wizard when each Task Sequence.

So to work around this limitation, I created a custom version of ZTIBackup.wsf (with the exciting name of ZTIBackupCustom.wsf). With this version you can specify the image name prefix (the part before <drive letter>Drive) using either a command line switch, /nameprefix, or a custom property, ImageNamePrefix. I used this script instead of ZTIBackup.wsf in the Create WIM step in the Task Sequence. Using only this change worked well but imposed the limitation the each run of the Task Sequence had to complete before starting the next. Also, all the runs had to be completed in the proper order so that the image index in the WIM would come out the same each time.

To get around this limitation, I changed the BackupFile MDT property (which holds the WIM file name) for each run of the Task Sequence so that each run created a different WIM file. I then created a script that uses imagex /export to combine all the WIM files in to a single WIM. This allows you to run the build in any order (even all at once) and re-run those that fail if needed.

OS Installation Media

You will need to assemble and import the XP SP2-integrated media as I described in my post on August 3 2009.

CustomSettings.ini

To control what edition of XP gets install, what image name prefix gets used, what BackupFile name is used, etc. I used MAC Address sections in CustomSettings.ini. Doing it this way requires four computers with different MAC Addresses. (I used Hyper-V and Virtual Server virtual machine as my build machines so that I didn’t need to be bothered with CD or PXE booting physical machines, but this process will work either way. I used Hyper-V to build the APIC HAL images and needed Virtual Server to build the PIC HAL images.) Here is what the CustomSettings.ini looks like:

[Settings]
Priority=Default, MACAddress, Finish
Properties=MyCustomProperty, CapturedImageIndex, ImageNamePrefix, CompletionFile, BackupFile

[Default]
OSInstall=Y

OrgName=Contoso
_SMSTSORGNAME=Contoso
SLShare=%DeployRoot%\Logs

SkipAppsOnUpgrade=YES
SkipDeploymentType=YES
    DeploymentType=NEWCOMPUTER
SkipComputerName=YES
    ;ComputerName set in MACAddress sections
SkipDomainMembership=Yes
    JoinWorkgroup=Workgroup
    ;JoinDomain
    ;DomainAdmin
    ;DomainAdminDomain
    ;DomainAdminPassword
SkipUserData=yes
    UserDataLocation=NETWORK
    ;UDDir
    ;UDShare
SkipComputerBackup=Yes
SkipBuild=YES
    ;BuildID set in MACAddress sections
SkipTaskSequence=YES
    ;TaskSquenceID set in MACAddress sections
SkipProductKey=YES
    ;ProductKey
SkipPackageDisplay=YES
    ;LanguagePacks
SkipLocaleSelection=Yes
    UserLocale=en-us
    InputLocale=en-us
    KeyboardLocale=en-us
SkipTimeZone=Yes
    TimeZone=35
    TimeZoneName=Eastern Standard Time
SkipApplications=YES
    ;Applications
SkipAdminPassword=YES
    AdminPassword=*
SkipCapture=YES
    DoCapture=YES
    ComputerBackupLocation=%DeployRoot%\Captures
SkipBitLocker=YES
    ;BDEDriveLetter
    ;BDEDriveSize
    ;BDEInstall
    ;TPMOwnerPassword
SkipSummary=YES
SkipFinalSummary=NO

[00:15:5D:11:AF:FF]
; Vista x86
BuildID=Vistax86SP1
TaskSquenceID=Vistax86SP1
CapturedImageIndex=1
ComputerName=vx86sp1%HALNAME%
WsusServer=http://MDTSERVER

[00:15:5D:11:AF:FE]
; XP Pro APIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=1
ComputerName=xppro%HALNAME%
ProductKey=11111-22222-33333-44444-55555
WsusServer=http://MDTSERVER

[00:15:5D:11:AF:FD]
; XP Tablet APIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=2
ComputerName=xptab%HALNAME%
ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
WsusServer=http://MDTSERVER

[00:03:FF:64:17:41]
; XP Pro PIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=3
ComputerName=xppro%HALNAME%
ProductKey=11111-22222-33333-44444-55555
WsusServer=http://MDTSERVER

[00:03:FF:64:17:42]
; XP Tablet PIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=4
ComputerName=xptab%HALNAME%
ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
WsusServer=http://MDTSERVER

[Finish]
BackupFile=%TASKSEQUENCEID%_%CapturedImageIndex%.wim
ImageNamePrefix=%TASKSEQUENCEID%.%CapturedImageIndex%.%TASKSEQUENCEVERSION%_
CompletionFile=%TASKSEQUENCEID%.%CapturedImageIndex%.txt

The edition of XP (Professional or Tablet PC Edition 2005) that gets install is controlled by using the correct Pro or Tablet Product Key. (In this sample 11111-22222-33333-44444-55555 represents the XP Pro product key and AAAAA-BBBBB-CCCCC-DDDDD-EEEEE represents the XP Tablet PC Edition product key.) The BackupFile name is constructed from the TaskSquenceID and the custom property CapturedImageIndex. So for example the BackupFile name for the XP Pro APIC HAL image would be XPSP3_1.wim. The prefix for the image name within the WIM the TaskSquenceID, the custom property CapturedImageIndex, and the TASKSEQUENCEVERSION. For the the XP Pro APIC HAL image, the ImageNamePrefix would be something like XPSP3.1.05.

Image Build: Task Sequence Details

Installing XP Service Pack 3

As I stated in my post on August 3 2009, the only way to create a supported installation of Windows XP Tablet PC Edition 2005 Service Pack 3 is to first install Tablet PC Edition from Service Pack 2 media and then install the Service Pack 3 Update. So to be consistent, the task sequence creates all the XP images by first installing from SP 2 media and installing the SP 3 Update as an Application in the Custom Tasks group.

I did this by download the Windows XP Service Pack 3 Update from here: http://www.microsoft.com/downloads/details.aspx?FamilyId=5B33B5A8-5E76-401F-BE08-1E1555D4F3D4&displaylang=en. I extracted the contents of the update to a temporary folder with the following command:

WindowsXP-KB936929-SP3-x86-ENU.exe /x:<temporary folder path>

Then I used the temporary folder to import the extracted Service Pack 3 Update as an Application in MDT with the following settings:

Folder name: Microsoft Windows XP Service Pack 3 Update
Name: Windows XP Service Pack 3 Update
Version: 1.0
Publisher: Microsoft
Language: en-US
Source: .\Applications\Microsoft Windows XP Service Pack 3 Update
CommandLine: Update.exe /passive /norestart /n
WorkingDirectory: .\Applications\Microsoft Windows XP Service Pack 3 Update\i386\update

Updating the \Windows\Source folder

MDT copies the XP installation source files into the %windir%\Source folder so that it is available if an optional component needs to be installed later. Unfortunately, since you are installing from SP 2 media and installing the SP 3 Update later the %windir%\Source folder will be at SP2 but the installed OS will be at SP3. To fix this you have to add step to the Task Sequence to update the %windir%\Source folder with the SP3-level installation source files.

To do this, create a temporary folder. Copy ZTIUtility.wsf from the MDT Scripts folder and the custom scripts LTI-ReplaceWindowsSource.wsf and LTI-CopySysprepFiles.wsf (in the ZIP attachment below) into this folder. Create a subfolder of the temporary folder called Source. Copy the contents of the SP3-level integrated media or slipstreamed version of the XP Pro installation CD files into the Source folder (copy all files/folders from the CD especially the Support folder, not just the i386 folder). The folder should look similar to this:

Import this folder as an Application with source files with the following settings:

Folder name: Windows XP Professional Service Pack 3 Integreted Media
Name: Windows XP Professional Service Pack 3 Integreted Media
Version: 1.0
Publisher: Microsoft
Language: en-US
Source: .\Applications\Windows XP Professional Service Pack 3 Integreted Media
CommandLine: cscript.exe LTI-ReplaceWindowsSource.wsf
WorkingDirectory: .\Applications\Windows XP Professional Service Pack 3 Integreted Media

Add this as an Install Application step in the Custom Tasks group.

If you are going to create your media for this step by slipstreaming SP3 into an SP2 installation source, this is what I recommend that you do. Download the Windows XP Service Pack 3 - ISO-9660 CD Image File from here and burn it to a CD using software that can burn ISO images to CD. (I like using ImgBurn for this but there are many others you can use.)

Copy the SP2 installation source that you imported following my instructions in the August 3, 2009 post to a temporary folder. Delete the Dotnetfx, Support, and Valueadd folders from the temporary folder. Replace them with the ones on the XP SP3 CD you just created. Then use the SP3 installer (WindowsXP-KB936929-SP3-x86-ENU.exe) on the root of the CD to integrate SP3 into the temporary folder using the following command:

WindowsXP-KB936929-SP3-x86-ENU.exe /integrate:"<temporary folder path>"

Copy the resulting installation files into the Source folder in the above instructions. Then create a Install Application step in the Custom Tasks group to “install” this as I described above.

Extracting the Sysprep Files

MDT copies the Sysprep files from the operating system folder in the Distribution folder. Because of this, the Sysprep files copied will be the SP2 versions instead of the SP 3 versions. Similar to the above step, we need to make sure the SP3 versions get copied instead.

Create another Application in MDT as Applications without source files or elsewhere on the network with the following settings:

Name: Windows XP Professional Service Pack 3 Sysprep Files
Version: 1.0
Publisher: Microsoft
Language: en-US
CommandLine: cscript.exe LTI-CopySysprepFiles.wsf
WorkingDirectory: %DeployRoot%\Applications\Windows XP Professional Service Pack 3 Integreted Media

Then create a Install Application step in the Custom Tasks group to “install” this.

Changing the Create WIM Step

You still need to copy ZTIBackupCustom.wsf from the attached Zip file, place it in the MDT Scripts folder, and change the command line of the Create WIM step to use it instead of ZTIBackup.wsf.

Merging the WIM files

After completing all four runs of the Task Sequence, there should be four WIM files in the \Distribution\Captures folder: XPSP3_1.wim, XPSP3_2.wim, XPSP3_3.wim, and XPSP4_1.wim. To merge them all into a new single WIM file (XPSP3.wim), I created the following CMD script (MergeXPImages.cmd) to do this. It uses a small VBScript as well (both included in the Zip attachement). This script is run on the MDT Server. Be sure to change the set CAPTURES=D:\Distribution\Captures line to point to your Captures folder path.

@echo off
setlocal

call "%ProgramFiles%\Windows AIK\Tools\PETools\pesetenv.cmd"
set CAPTURES=D:\Distribution\Captures

:: Get the Last Modified date for the previous merged WIM if it exists
:: and create an environment variable
If exist "%CAPTURES%\XPSP3.wim" (
    for /f "tokens=*" %%i in ('cscript //nologo GetFileDateInfo.vbs "%CAPTURES%\XPSP3.wim"') do set %%i
)

:: Rename previous merged WIM so as not to overwrite or merge to the previous WIM
If exist "%CAPTURES%\XPSP3.wim" rename "%CAPTURES%\XPSP3.wim" "XPSP3_%FileLastModified%.wim"

:: Merge the source WIMs into a single destination WIM
call :MERGEIMAGE "%CAPTURES%\XPSP3_1.wim" "%CAPTURES%\XPSP3.wim"
call :MERGEIMAGE "%CAPTURES%\XPSP3_2.wim" "%CAPTURES%\XPSP3.wim"
call :MERGEIMAGE "%CAPTURES%\XPSP3_3.wim" "%CAPTURES%\XPSP3.wim"
call :MERGEIMAGE "%CAPTURES%\XPSP3_4.wim" "%CAPTURES%\XPSP3.wim"

goto :EOF

:MERGEIMAGE

    for /f "delims=<> tokens=2,3*" %%i in ('imagex /info "%~1" 1') do set %%i=%%j
    imagex /export "%~1" 1 "%~2" %NAME%
    imagex /info "%~2"

goto :EOF

Deploying the XP Multi-image WIM

So now that you have this multi-mage WIM file, how do you make sure that the correct image gets applied in the deployment Task Sequence? The steps are different depending on whether you are deploying with MDT Lite Touch Installation or with System Center Configuration Manager 2007 with MDT Integration. You must use MDT Integration and an MDT Task sequence in ConfigMgr so that the Gather step will run.

In both cases you will need to make the changes to CustomSettings.ini and use ZTI-DetectHardwareExit.vbs as shown in the Edit CustomSettings.ini for Detecting Tablet PC Hardware section of my post on August 3 2009. Using this multi-image WIM requires that the IsTablet variable is set correctly to True or False.

System Center Configuration Manager 2007

If you are deploying with System Center Configuration Manager, the setup is very straight forward. Import the WIM files as an Operating System Image Package. In your Task Sequence you will now need to have four Apply Operating System Image steps instead of one. Give each a unique step name like Apply OS – XP Pro APIC HAL to avoid confusion as to why there are four. For all of them you will check Apply operating system from captured image and select the Image package you just created. Then for each one you will select a different Image number (1, 2, 3, or 4). Finally you will set conditions on the Options tab on each Apply Operating System Image step. For example, the conditions for the XP Pro APIC HAL image would look like this:

The table below shows the various settings for all the Apply Operating System Image steps.

Step Name	Image #	Conditions
Apply OS - XP Pro ACPIAPIC HAL	1	HALNAME equals ACPIAPIC and IsTablet equals FALSE
Apply OS - XP Tablet ACPIAPIC HAL	2	HALNAME equals ACPIAPIC and IsTablet equals TRUE
Apply OS - XP Pro ACPIPIC HAL	3	HALNAME equals ACPIPIC and IsTablet equals FALSE
Apply OS - XP Tablet ACPIPIC HAL	4	HALNAME equals ACPIPIC and IsTablet equals TRUE

Similarly, you should have two Apply Windows Settings steps, one with the XP Professional Product Key and one with the XP Tablet PC Edition Product Key:

Step Name	Product key	Conditions
Apply Windows Settings – XP Pro	(Windows XP Professional Volume License Key)	IsTablet equals FALSE
Apply Windows Settings - XP Tablet	(Windows XP Tablet PC Edition 2005 Volume License Key)	IsTablet equals TRUE

MDT 2008 Update 1

If you are using MDT Lite Touch Installation, things get a little trickier. First import the WIM as a Operating System into MDT. After you do you will see four entries in Operating Systems like XPSP3.1.05_CDrive in "Windows XP SP3\XPSP3.wim" if you used a folder name of Windows XP SP3 during import.

When you create your deployment Task Sequence select the one that starts with XPSP3.1 as the operating system to install. This will be the XP Pro APIC HAL image which should be the one that will be installed most often. You can only have the one Install Operating System step in an MDT Task sequence.

When you import a WIM as an Operating System in the Deployment Workbench it creates one or more entries in \Distribution\Control\OperatingSystems.xml. It will create one entry for each image in the WIM files. Below is an example of the entries in OperatingSystems.xml for my multi-image XP WIM file

<os guid="{e22d5b4a-1d2f-4c73-860a-ced219bb8c09}">
<Name>XPSP3.1.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>1</ImageIndex>
<ImageName>XPSP3.1.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpiapic_up</HAL>
<Size>3003</Size>
</os>
<os guid="{1c47ea5f-73cd-44f2-a0a6-37583ac9b774}">
<Name>XPSP3.2.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>2</ImageIndex>
<ImageName>XPSP3.2.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpiapic_up</HAL>
<Size>3236</Size>
</os>
<os guid="{61c15f32-1f9f-4c64-806a-202eaccac425}">
<Name>XPSP3.3.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>3</ImageIndex>
<ImageName>XPSP3.3.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpipic_up</HAL>
<Size>3051</Size>
</os>
<os guid="{a8f8689f-ed34-4595-a2f8-02ef98832979}">
<Name>XPSP3.4.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>4</ImageIndex>
<ImageName>XPSP3.4.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpipic_up</HAL>
<Size>3284</Size>
</os>

You will notice that each entry is assigned a unique GUID. This is what MDT uses to track what OS to install when you select an OS in the Install Operating System step. Unfortunately, MDT takes the GUID from the entry selected in the Install Operating System step and sets a global Task Sequence variable called OSGUID with the value. This means that to change what OS gets installed within the Task Sequence, you have to override the OSGUID value with the GUID for the OS you want to install. You also need to override the variable IMAGEINDEX as well. To do this you need to create a series of Set Task Sequence Variable steps to override both variables using conditions similar to those on the ConfigMgr steps. Below is a table showing the Set Task Sequence Variable steps for my sample above that should immediately precede the Install Operating System step and their conditions. There should be no conditions on the Install Operating System step.

Step Name	TS Variable	Value	Conditions
Set OSGUID - XP Tablet ACPIAPIC HAL	OSGUID	{1c47ea5f-73cd-44f2-a0a6-37583ac9b774}	HALNAME equals ACPIAPIC and IsTablet equals TRUE
Set IMAGEINDEX - XP Tablet ACPIAPIC HAL	IMAGEINDEX	2	HALNAME equals ACPIAPIC and IsTablet equals TRUE
Set OSGUID - XP Pro ACPIPIC HAL	OSGUID	{61c15f32-1f9f-4c64-806a-202eaccac425}	HALNAME equals ACPIPIC and IsTablet equals FALSE
Set IMAGEINDEX - XP Pro ACPIPIC HAL	IMAGEINDEX	3	HALNAME equals ACPIPIC and IsTablet equals FALSE
Set OSGUID - XP Tablet ACPIPIC HAL	OSGUID	{a8f8689f-ed34-4595-a2f8-02ef98832979}	HALNAME equals ACPIPIC and IsTablet equals TRUE
Set IMAGEINDEX - XP Tablet ACPIPIC HAL	IMAGEINDEX	4	HALNAME equals ACPIPIC and IsTablet equals TRUE

You will also need to set the ProductKey property to either the XP Pro or XP Tablet key depending on whether IsTablet equals FALSE or TRUE respectively. This can be done using conditioned Set Task Sequence Variable steps or using CustomSettings.ini by adding sections like the ones shown below:

[Settings]
Priority=IsTabletCheck, ByTabletType, Default
Properties=MyCustomProperty, TabletPnpIds, IsTablet, XPTabletProductKey

[IsTabletCheck]
TabletPnpIds=ACPI\WACF004,ACPI\WACF008,ACPI\MAI3310,ACPI\FUJ02E5
UserExit=ZTI-DetectHardwareExit.vbs
IsTablet=#DetectDevices("%TabletPnpIds%")#

[ByTabletType]
Subsection=Tablet-%IsTablet%

[Tablet-True]
ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
OSInstall=Y

[Tablet-False]
ProductKey=11111-22222-33333-44444-55555

OSInstall=Y

[Tablet-Error]
OSInstall=N

[Default]

where 11111-22222-33333-44444-55555 represents the XP Pro product key and AAAAA-BBBBB-CCCCC-DDDDD-EEEEE represents the XP Tablet PC Edition product key.

Creating Multi-image WIM files with Other Operating Systems

Creating and deploying multi-image WIM files can be done with other operating systems. For example, you could use a single task sequence to create an custom WIM that contains custom images of Windows Vista Business and Windows Vista Enterprise. Or create a single WIM file with Windows Server 2008 Standard, Enterprise, and Datacenter. (You would generally only include images of the same OS and the same architecture with a single WIM. You would not benefit from single instance storage if you tried to include x86 and x64 images in the same WIM.) To do this, the image build process would have to be done more like the MDT 2008 deployment method described above. What is unique about XP is all the images were created for the same source “Operating System” (the XP SP2 media). For including multiple editions of other operating systems in a single WIM requires using multiple MDT “Operating Systems” in the Task Sequence. This requires overriding the OSGUID and IMAGEINDEX like the process above except you would have to condition off another variable.

For example, let’s say you wanted to create a WIM that contains custom images of Windows Vista Business and Windows Vista Enterprise. You could set a custom variable call Edition like this:

[Settings]
Priority=Default, MACAddress, Finish
Properties=MyCustomProperty, CapturedImageIndex, ImageNamePrefix, CompletionFile, BackupFile, Edition

[Default]
OSInstall=Y

.
.
.

[00:15:5D:11:AF:FF]
; Vista Business x86
BuildID=Vistax86SP1
TaskSquenceID=Vistax86SP1
Edition=Business
CapturedImageIndex=1
ComputerName=vbx86sp1
WsusServer=http://MDTSERVER

[00:15:5D:11:AF:FE]
; Vista Enterprise x86
BuildID=Vistax86SP1
TaskSquenceID=Vistax86SP1
Edition=Enterprise
CapturedImageIndex=2
ComputerName=vex86sp1
WsusServer=http://MDTSERVER

.
.
.

In the image build Task Sequence you would select the most often deployed OS (let’s say Windows Vista Enterprise for example) in the Install Operating System step. You would then create Set Task Sequence Variable steps that override the OSGUID and IMAGEINDEX with the ones for Windows Vista Business with a condition of Edition equals Business.

For deploying the resulting WIM you would do similar conditioned steps for ConfigMgr and MDT but you would have to again use a custom variable for the condition that perhaps get set per computer, location, or role in CustomSettings.ini or the MDT database.

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

Keeping An Eye On USMT Progress

Daniel Oxley — Fri, 26 Jun 2009 12:31:00 GMT

I recently did a project where all users had around 25Gb (don’t ask!) of data that had to be migrated with the USMT during the OS deployment. Because of the sheer volume of data, the USMT phases of the project took an extremely long time to complete, and because no on-screen feedback is given of the progress, the customer would often think that something had hung, so they often cancelled the deployment; only to find that it was indeed running correctly. In order to stop them doing this, I wrote a very simple VBS script that showed the current progress of the USMT. It works by simply parsing the progress file, looking for the percentage progress of the process.

I thought I would publish it here, because when I showed it to some colleagues they asked for a copy as they thought it would be useful to use during the lab phases of MDT projects.

It consists simply of a VBS file that requires the path of the USMT log file to be passed as a parameter. The script creates a small HTML window that then displays a single line showing the progress of the USMT as a percentage. You can either launch the script by hand or add it to the task sequence. To add this to the task sequence, simple add the following “Run Command Line" action before the USMT capture or restore actions (or both):

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTCapture.prg”

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTRestore.prg”

Why the two commands lines? Well, the first one is to show the progress of the capture phase of the USMT, and the second is to show the progress of the restore phase. Also, I should point out that the command is launched in this way because MDT needs to launch the command, and then move on. If you don't have the cmd.exe /c "start" part at the beginning then MDT will launch the script and wait for it to finish (which is never) and the USMT commands will never fire. You may also have noticed that I had to put the drive letter in the command path, this is because the variable %SCRIPTROOT% is not available with this usage.

The screenshot below shows what it looks like in action.

Be warned though, this script does consume quite a few CPU cycles because it is probably not the most efficient routine; it was really a proof-of-concept thing that I wrote in order to show that everything was running as expected. When I wrote it I was running it on dual core desktop computers and it didn’t seem to noticeable affect the deployment time.

Attached to this post is the script file.

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

Excluding USB, FireWire and other drives from USMT Capture

DeploymentGuys — Wed, 29 Apr 2009 15:48:00 GMT

A common requirement during user state migration is to not capture data from certain drives. The most commonly requested for exclusion are removable drives such as USB and FireWire drives. There is no command line option to exclude these drives automatically with USMT v3. I had to turn to scripting to accomplish this.

I created a script, ZTI-ExcludeDrivesXmlGen.wsf (and its function library HelperFunctions.vbs), that will generate a USMT XML rules file to unconditionally exclude USB and FireWire drives (as well as additional specified drives) during the deployment. The script should be run during the State Capture phase before Scanstate.exe is run. The resulting XML file should be used on both the Scanstate.exe and Loadstate.exe command lines. The script is driven by either command line switches or MDT properties:

Use the /output switch or the USMTExcludeDrivesOutput property to specify the output XML file. If not specified, the default of oUtility.LogPath & "\MigExcludeDrives.xml" is used.
Use the /usb switch or the property USMTExcludeUsbDrives=True to exclude USB and FireWire drives from the migration.
Use the /scriptdrive switch or the property USMTExcludeScriptDrive=True to exclude the drive from which this script is running from the migration.
Use the /drives switch or the USMTExcludeDrives property to exclude specific drives from the migration. The switch should be specified like this example:
/drives:"D:,E:,F:"
The property should be specified like this example:
USMTExcludeDrives=D:,E:,F:
Use the /flagfile switch or the USMTExcludeDriveFlagFile property to exclude specific drives from the migration using a flag file. Using the /flagfile switch without a value or setting USMTExcludeDriveFlagFile=True will cause the script to exclude drives that have the default flag file, NO_USMT_ON_DRIVE.USMT, in the root folder of the drive. (You SMS experts out there will get the choice of the default flag file name. J ) Using the switch or property with a file name value will exclude drives that have the specified named flag file in the root folder of the drive.

Remember that the generated XML file must also be used with Loadstate.exe. Therefore, it must be saved to a location that from which it can be retrieved during the State Restore phase. I have included a script, ZTI-CopyFilesToStateFolder.wsf, to copy files to a subfolder of the state store location that can be used for this.

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

Deploying Windows 7 VL with MAK (Multiple Access Keys) using MDT 2010

DeploymentGuys — Mon, 30 Mar 2009 11:00:26 GMT

My esteemed colleague - Doug Klokow who is a Senior Consultant in the worldwide deployment practice, working with Windows 7 TAP (Technical Adoption Program) customers in the US has put together a most useful set of instructions regarding Windows 7 deployment using MDT 2010 and MAK keys. This is of benefit when deploying to environments where access to KMS may be tricky during the activation timescales – I recently came across this in a university where professors and research staff go off on research assignments for up to a year at a time…When deploying Windows 7 Enterprise Volume License (VL) edition using MDT 2010, it is possible to include a MAK activation key, however, the standard methods of including the key in the unattend.xml file requires modification. Additionally, it is possible to deploy MAK keys using a custom script as part of a Task Sequence.

Situation

While deploying Windows 7 Enterprise VL with MDT 2010, the typical behaviour would be to include the activation key in the customisation wizard used to create a Task Sequence for the deployment of the Windows 7 operating system. By design, the Task Sequence wizard is designed to support retail activation keys, not volume license keys. The difference is subtle, but important to the context of this scenario.

As you complete the New Task Sequence Wizard, you are prompted the Product key.

When you enter a product key into the field shown above, the MDT 2010 wizard adds the code into two specific locations of the unattend.xml file for this task sequence.

The first location for the ProductKey is the WindowsPE phase, specifically, the x86_Microsoft-Windows-Setup_neutral\UserData\ProductKey setting.

The second location is in the Specialize phase, specifically the x86_Microsoft-Windows-Shell-Setup_neutral\ProductKey setting.

Issue

The Unattended Windows Setup reference explains why there are two entries for the ProductKey setting, but if the Product Key for Windows 7 Enterprise is placed in both locations (as is the default) when entering the Product Key using the task sequence creation wizard, you will receive the following error when attempting to build or deploy a client machine with that task sequence.

Resolution

There are a number of options available to address this particular situation. Each provides a resolution, but using different methods.

OPTION 1

Simply delete the ProductKey entry in the WindowsPE phase, specifically, the x86_Microsoft-Windows-Setup_neutral\UserData\ProductKey setting. The unattended install should work as expected deploying your Windows 7 machine using the configurations your define. Once the Windows 7 installation is complete, it will be necessary to either manually kick off the activation process from the Computer Properties screen of the machine, or using the Volume Activation Management Tool (VAMT) to complete the activation remotely.

NOTE: At the time this blog was authored, an updated VAMT tool is not presently available with support for Windows 7.

OPTION 2

Use the slmgr.vbs script to perform the activation as a task in the task sequence in lieu of the ProductKey entries in the unattend.xml file. Check the two locations in the unattend.xml file to validate that both entries for ProductKey are blank.

STEP 1: Add the first entry into the Custom Tasks section of the State Restore phase as shown below:

Task Name:	Activate Client using VL MAK
Command Line:	cscript.exe c:\windows\system32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Start in:	c:\windows\system32

NOTE: Replace the X's with your VL MAK key for Windows 7

STEP 2: Add the slmgr.vbs /ato script to automatically activate the client during deployment as shown below:

Task Name:	Activate the machine using the VL MAK
Command Line:	cscript.exe c:\windows\system32\slmgr.vbs /ato
Start in:	c:\windows\system32

NOTE: This task will only work if the machine is connected to the internet during the State Restore phase. If this task fails because the network connectivity is not fully initialized, it is possible to manually activate the client through the Computer Properties window.

Now when the client machine is deployed, the task sequence will provide the MAK key during the State Restore phase, and attempt to automatically activate the client machine.

OPTION 3

Use the OverRideProductKey entry in the CustomSettings.ini to specify the MAK key to be injected. This will add the MAK product key only into the x86_Microsoft-Windows-Shell-Setup_neutral\ProductKey location in the Unattend.xml.

From the MDT Toolkit Reference document:

OverrideProductKey

The Multiple Activation Key (MAK) string to be applied after the target operating is deployed to the target computer. The value specified in this property is used by the ZTILicensing.wsf script during the State Restore Phase to apply the MAK to the target operating system. The script also configures the volume licensing image to use MAK activation instead of Key Management Service (KMS). The operating system needs to be activated with Microsoft after the MAK is applied. This is used when the target computer is unable to access a server that is running KMS.

Value	Description
MAK	The MAK string to be provided to the target operating system.

Example

[Settings]

Priority=Default

[Default]

ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE-FFFFF

OverrideProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE-FFFFF

Option 4

During deployment, it is possible to specify the Product Key while running the deployment of the workstation. The Deployment Wizard includes an option to prompt for the Product Key using the "SkipProductKey" entry in the CustomSettings.ini file for the Deployment Point. By specifying an entry of "SkipProductKey=No" the user will be prompted to enter a key while running the deployment of the machine, and if they enter their MAK key there, they deployment will complete successfully.

From the MDT Toolkit Reference document:

SkipProductKey

Indicates whether the Specify the product key needed to install this operating system wizard page is skipped.

For other properties that must be configured when this property is set to YES, see the section “Providing Properties for Skipped Windows Deployment Wizard Pages” later in this reference.

Value	Description
YES	Wizard page is not displayed, and the information on that page is not collected.
NO	Wizard page is displayed, and the information on that page is collected. This is the default value.

Example

[Settings]

Priority=Default

[Default]

SkipWizard=NO

SkipCapture=NO

SkipAdminPassword=YES

SkipApplications=NO

SkipAppsOnUpgrade=NO

SkipComputerBackup=NO

SkipDomainMembership=NO

SkipDeploymentType=NO

SkipUserData=NO

SkipPackageDisplay=NO

SkipLocaleSelection=NO

SkipProductKey=YES

Caution This property value must be specified in upper case so that it can be properly read by the deployment scripts.

UPDATE:

If you are working with MDT 2010 Beta 1 then the issue and resolutions referred to above are valid – however our other most esteemed colleague and MDT creator Michael Niehaus has pointed out that the issue has been fixed for MDT 2010 Beta 2. Now the screen will have another option to match the options that are available in the client-side Deployment Wizard:

Resources

For more information on the using the SLMGR.VBS script for activation tasks, see the Volume Activation 2.0 Deployment Guide.

For more information on the ProductKey setting, see the Unattended Windows Setup Reference.

This post was contributed by Richard Smith a senior consultant with Microsoft Services UK on behalf of Doug Klokow a senior consultant with Microsoft Services US

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

SCCM 2007 and Microsoft Deployment Toolkit - Video Walkthrough

DeploymentGuys — Thu, 20 Mar 2008 11:35:00 GMT

Are you struggling with setting up SCCM 2007 Operating System Deployment and integrating MDT? - I have created a video walkthrough that shows you how to:

Setup the server environment for SCCM 2007 OS deployment
Configure the SCCM 2007 Site Settings
Configure the SCCM 2007 Computer Management Settings
Configure the SCCM 2007 Operating System Deployment Settings
Setup and use MDT integration with SCCM 2007
Add a reference machine object to SCCM 2007
Create a build and capture reference image for mass deployment using SCCM 2007

View the SCCM and MDT Video Walkthrough from the Windows Media Servers here!

View the SCCM and MDT Video Walkthrough from the TechNet Edge Media Servers here!

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

Microsoft Deployment Toolkit - Lite Touch Video Walkthrough

DeploymentGuys — Thu, 13 Mar 2008 12:20:00 GMT

Are you struggling with setting up MDT Lite Touch? - I have created a video walkthrough that shows you how to:

Add operating systems, applications, drivers and packages to MDT
Configure Office 2007 into the build process
Create a MDT Lite Touch task sequence
Setup a lab based deployment point
Create a customised build to a reference computer
Capture the reference computer as a customised WIM
Add the customised WIM back into MDT for deployment

View the MDT Lite Touch Video Walkthrough from the Windows Media Servers here!

View the MDT Lite Touch Video Walkthrough from the TechNet Edge Media Servers here !

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