The Deployment Guys : Scripts

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.

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

Sharing some simple HTAs

Daniel Oxley — Thu, 26 Mar 2009 16:06:00 GMT

I was recently asked to share these files with a colleague, so I thought I would also share them with everyone via our blog. I developed them a while ago for a deployment project and I have since used them a few times more.

Basically, they are 3 very simple HTA (HTML application) files that prompt the user for information in order to configure either a static IP address, change the local administrator password, or add a computer to a domain. Of course, all of these actions can be accomplished directly via MDT, but I had to create them for a very specific reason where MDT could not be used to for this. They were developed for a Windows XP deployment, so they have not been tested on Windows Vista but I can’t see why they would not work, as long as you ran them elevated. You can be launch them directly from the task sequence in MDT by using the following command:

mshta.exe CUSTOM_Config_Network.hta

CUSTOM_Config_Network.hta

CUSTOM_Config_PWD.hta

CUSTOM_Config_Domain.hta

I have attached the 3 files to this post in a zip file. Please bare in mind that they are pretty simple and don’t have the error checking for every possible error that might occur, so use at your own risk!

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

Deploying Win 7 to Boot From VHD with MDT 2010

DeploymentGuys — Tue, 03 Mar 2009 23:29:00 GMT

One of the more difficult scenarios that customers have found in the past is multi-booting a new OS. The effort needed to re-partition the drive to allow for the new OS is sometimes too great. One new solution that is gaining ground in deployment is Boot From VHD. This allows you to take a VHD file with Windows 7 or Windows Server 2008 R2 and boot your machine to it. This means that you can take advantage of the physical hardware of your machine while not having to repartition your drive for Win 7 and keep your original OS intact. More information on how to Boot From VHD can be found here http://edge.technet.com/Media/Windows-7-Boot-from-VHD/ .

MDT 2010 Beta 1 can deploy Win 7 Beta out-of-the-box however, it deploys it to the Disk 0 Partition 1 by default. In order to change this behaviour so that MDT 2010 deploys Win 7 to a VHD and leaves your existing OS you can follow the steps below:

1. Create a Task Sequence to install Win 7 in MDT 2010

2. Insert the following 3 steps in the Pre-Install \ New Computer only Phase:

a) Disable the format and partition disk step

b) Insert a Set Task Sequence Variable Step to set the path for the VHD with the variable BootVHDLocation. Ensure that path DOES NOT EXIST already on the machine.

c) Insert a Set Task Sequence Variable Step to set the size of the VHD (in MB) with the variable BootVHDSize. Ensure that there is enough space on the drive as the VHD may grow to this size.

d) Insert a Run Command Line step to run the command line cscript.exe "%SCRIPTROOT%\ZTIDiskPartVHD.wsf"

3. Copy the attached script below to your Distribution$\Scripts folder.

4. Run your task sequence on a machine and watch Win 7 install into a VHD. Once the process is done, your machine will have a boot menu similar to this:

Please note, this script does not deal with BitLocker encrypted drives and Boot From VHD will only work with Windows 7 Beta or Windows Server 2008 R2. As always test this out and feel free to post comments.

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

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

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

Porting Configuration Manager Task Sequences to a Different Environment

DeploymentGuys — Wed, 15 Oct 2008 23:27:00 GMT

Many scenarios arise in which you may want to port your task sequence from one environment to another. Common scenarios include promotion through Lab and QA environments and migration between disconnected hierarchies. Configuration Manager allows you to export task sequences into XML files as an out-of-the-box feature, however there are some things to remember when doing this.

Here is a checklist I like to follow:

1. Passwords: The exported task sequence will replace passwords in the task sequence for known steps before performing an export to ensure no clear-text passwords exist in the XML. This means any passwords in the "Apply Windows Settings" and "Join Domain" steps will replaced with ???????? . Remember to re-enter passwords when importing the task sequence or it will be set to 8 consecutive question marks.

2. Product Keys: Any product keys you enter will be blanked out in the "Apply Windows Settings" step. Remember to re-enter these for your XP task sequences.

3. Package IDs*: If the new Configuration Manager Site Server is not in the same hierarchy, you will have to re-associate all the steps in the task sequence to the packages in the new environment. You may also need to reassociate the boot image and any packages selected to run before the task sequence. Read below for a script to automate this process.

4. Inject Drivers in the Apply Driver Package step: If you have configured the task sequence with an Apply Driver Package step and chosen a boot-critical driver for Pre-Vista OSes, you will need to reselect this driver in the new environment.

5. Setup Windows and Config Manager step: If you are migrating to a new hierarchy, you will also want to see whether any of your Config Manager client properties need to be changed - such as reference to an FSP or SLP.

6. Domain references: You may have to also change any Join Domain steps you have in the Task Sequence to point to a new domain and use different credentials to perform the join.

7. MDT Database: If you are moving to a new hierarchy, the packageIDs in your MDT Database will still point to packageIDs in your previous environment. I am working on a script to help automate this and will post it once it is ready.

*Steps 3 can be a tedious process and often times can result in a manual configuration error. Luckily, we've created some powershell scripts to help make the process less manual:

Automated Scripts:

ExportTSRefs.ps1 - Exports the name, packageID and version of any referenced packages of a given task sequence to a RefIDsFile. This includes OS Packages, OS Install Packages, Driver Packages, Boot Image Packages and Software Packages. Note this only exports the refIDsFile not the packages or XML themselves.

Usage:

."ExportTSRefs.ps1" -sitecode <sitecode> -refIDsFile <filename> -delim <delimiter> -tsID <taskSequencePackageID>
For Example to Export the references of the CEN00001 TaskSequence Package:
."ExportTSRefs.ps1" -sitecode "CEN" -refIDsFile "refIDs.txt" -delim "=" -tsID "CEN00001"
Running the script multiple times with different tsIDs and an existing refIDs file will append only unique packageIDs to the refIDs File.

ScrubTS.ps1 - Reads a RefIDsfile generated by the ExportTSRefs.ps1 script. It then scrubs all the Task Sequence XML files in the given folder for package IDs, looks up packages with the same name and version in the new environment and replaces the XML with the new package IDs. Note: packages in Configuration Manager and source files must already exist in the new environment.

Usage:

."ScrubTS.ps1" -sitecode <sitecode> -refIDsFile <filename> -delim <delimiter> -path <folderpath>
For Example to scrub the package IDs of all the XML files in the C:\ExportedTaskSequences folder
."ScrubTS.ps1" -sitecode "CEN" -refIDsFile "refIDs.txt" -delim "=" -path "C:\ExportedTaskSequences"

Remember the path is a folder name and the script will read all the .XML files in the folder. The new XML files will have the extension _scrubbed.XML.

For both scripts you can use any delimiter you like , I prefer "=" but feel free to experiment.

We are working on developing more scripts to add further automation around the promotion and migration process of task sequences. Stay tuned! As always try out the scripts and feel free to add any comments or contributions.

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

Logging All the Configuration Manager Task Sequence Variables

DeploymentGuys — Fri, 29 Aug 2008 18:31:00 GMT

When debugging a MDT based Configuration Manager Task Sequence, it is often helpful to know what certain built-in Configuration Manager variables are set to during a step in the task sequence. For instance, you may want to see if _SMSTSLastActionRetCode was equal to a certain value or perhaps which management point the client is using by checking _SMSTSMP. These variables and more are available in the Microsoft.SMS.TSEnvironment and you can easily log them using the script snippet below:

Dim sVar

Set osdV4 = CreateObject("Microsoft.SMS.TSEnvironment")

For Each sVar in osdv4.GetVariables()
oLogging.CreateEntry sVar & ":" & oEnvironment.Item(sVar), LogTypeInfo
Next

A list of the variables and their values can be found at http://technet.microsoft.com/en-us/library/bb632442.aspx .

The full ZTI-style script is included below. Add the script to the Microsoft Deployment Toolkit package and you can call this script as a task in the task sequence. The variables will be outputted to OutputTSVariables.log.

Try it out and feel free to comment.

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

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.

Useful Script Number 5 - Adjusting the Default User Registry Hive

DeploymentGuys — Fri, 06 Jun 2008 17:03:00 GMT

Michael Murgolo did a great post on the different ways to adjust default settings when building an image (Configuring default settings for Windows image deployment) and one of the options presented was to targeted changes to the Default User Registry hive and profile folders. I had to do this recently and put together a script that can be launched from the MDT task sequence because I was finding my customised Administrator profile wasn't being copied over correctly to the Default User profile as part of SysPrep.

As Michael mentioned in his post - there are three main processes...you first need to load the default user hive (NTUser.dat) - make the changes you require - then unload the user hive. I have reproduced the core part of my script that does this process for discussion.

The first section sets the two variables that will be used - one to store the temp key (sTempHive) that we will load to, and the second to hold the profile file and location that we want to load (sDefaultUserHive)

For Windows Vista the entry """%USERPROFILE%\..\Default\NTUSER.DAT""" refers to C:\Users\Default\ntuser.dat

sTempHive = """HKEY_USERS\Test"""
sDefaultUserHive = """%USERPROFILE%\..\Default\NTUSER.DAT"""
sSName = oUtility.ScriptName
set oshell = WScript.CreateObject ("Wscript.Shell")

iZTIRetValue="1"

We then need to start logging - it's the law :-)

oLogging.CreateEntry sSName & ": Actions Start - Updating Default Profile",LogTypeInfo
oLogging.CreateEntry sSName & ": Loading the Default User hive",LogTypeInfo

The next section runs reg load to load the NTUser.dat file from the default user directory to the temp key (HKEY_USERS\Test) set in the first section - if there is an error the script fails and quits with a specific failure number or we log success.

oShell.run "reg load " & sTempHive & " " & sDefaultUserHive
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to load the registry hive " & sDefaultUserHive,LogTypeError
ZTIProcess=70
Exit Function
End If
oLogging.CreateEntry sSName & ": Default User Hive Loaded to " & sTempHive,LogTypeInfo
oLogging.CreateEntry sSName & ": Starting Registry Changes... ",LogTypeInfo

Now that the hive is loaded we can start changing stuff...as an example - I have set the code to change the wallpaper and the screen saver for the default user - again with error checking and specific failure codes

This codes sets the wallpaper (the file needs to be where you set the key to :-)

oLogging.CreateEntry sSName & ": Setting Default User Wallpaper",LogTypeInfo
RegPath = "HKEY_USERS\Test\Control Panel\Desktop\"
oshell.RegWrite Regpath & "WallPaper", "C:\Windows\Web\Wallpaper\CorporateWallpaper.bmp", "REG_SZ"
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to update wallpaper file setting",LogTypeError
ZTIProcess=60
Exit Function
End If

...and this codes sets the screen saver (again - the file needs to be where you set the key to :-)

oLogging.CreateEntry sSName & ": Setting Default User Screensaver",LogTypeInfo
RegPath = "HKEY_USERS\Test\Control Panel\Desktop\"
oshell.RegWrite Regpath & "SCRNSAVE.EXE", "C:\Windows\CorporateScreensaver.scr", "REG_SZ"
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to update Screensaver settings",LogTypeError
ZTIProcess=50
Exit Function
End If

Once all of the changes have been made - its time to unload the hive from its temp key - again with logging and error checking

oLogging.CreateEntry sSName & ": Unloading the Default User hive",LogTypeInfo

oShell.run "reg unload " & sTempHive
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to unload the default user registry hive",LogTypeError
ZTIProcess=40
Exit Function
End If
oLogging.CreateEntry sSName & ": Actions completed",LogTypeInfo

The completed script can be added to your MDT task sequence towards the end - so that it runs before the machine SysPreps and reboots for capture.

The complete script - in MDT format (to include logging and access to classes from ZTIUtility.wsf) with a number of other changes included is available on the Deployment Guys SkyDrive:

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