The Deployment Guys

Happy Halloween - Windows 7 style

2009-10-30T19:00:08Z

Since my latest Windows 7 “project” turned out so well, I though I’d share it with you. Yes, I did carve this intricate design myself. :-) Have a Happy Halloween from the Deployment Guys. Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use . This post was contributed by Michael...(read more)

Configuring Default User Settings – Full Update for Windows 7 and Windows Server 2008 R2

2009-10-29T14:36:00Z

I have written several posts on this topic before. However, changes were made to Windows 7 and Windows Server 2008 R2 that warrant a full revisit of this topic. This post can can also be also be found on the Windows Springboard Series blog here . Anyone who had been doing operating system deployments long enough has had to deal with configuring default settings for users that log on to the computer after the image is deployed. Some examples of these are folder settings, desktop wallpaper, and screen...(read more)

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

2009-10-22T01:06:00Z

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 updates in both environments. The most common solution is to set up an external standalone WSUS server for your reference machine to pull down updates. However, it would be ideal to have a single place to manage the approval and download of updates...(read more)

Essential Guide for Deploying Windows 7

2009-10-19T07:42:51Z

There is a great eBook that has just been released on the Microsoft website that gives a good insight into many of the technologies and concepts that you’ll need to consider and address for when you start working on your Windows 7 deployment, and the best thing is that the eBook is free! It covers a lot of topics, including some very common ones that people often get into problems with, and as you can see from the below table of contents, the scope of the book is surprisingly broad:...(read more)

Reporting on Office 2007 Customisation Settings

2009-10-14T12:53:27Z

So I don’t know about you but I have a very distinct love hate relationship with the Office 2007 Customisation Wizard. I just love the amount of tweaking I can do and I just hate the fact that I can tweak so much. In past I have found that tweaking as little as possible is often the best way forward. However sometimes you go on site and there is an Office Customisation file already setup – but its not quite doing what you or the deployment team expects. So what now? Well in the past I have gone through...(read more)

How to configure BitLocker on additional drives in a MDT 2010 deployment.

2009-10-09T22:39:54Z

MDT 2010 supports encrypting disks with BitLocker during deployment. This is configured in the Task Sequence using the following: This works for the Operating System Drive. If configuration of Bitlocker is tried on additional drives, the deployment fails. When the logs are examined it appears that the encryption of the operating system using the TPM has been tried a second time. This is because some of the Task Sequence variables that the ZTIBDE.WSF script contain values from encrypting...(read more)

Making WinPE Wait for Network in LTI Deployments

2009-09-23T21:24:00Z

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

2009-09-21T12:36:00Z

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

2009-09-10T11:30:00Z

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.

MDT 2010 is Released to the Web!

2009-09-09T10:54:00Z

Yesterday the MDT team in Redmond released MDT2010 to the web for download. There is a blog posting with the location for download here: http://blogs.technet.com/msdeployment/archive/2009/09/09/mdt-2010-is-released.aspx

Or you can go to the following link directly: http://www.microsoft.com/downloads/details.aspx?FamilyID=3bd8561f-77ac-4400-a0c1-fe871c461a89&displayLang=en

Also Michael Niehaus did a great series of blog posts on most of the new features of MDT 2010. You can review those posts here: http://blogs.technet.com/mniehaus/search.aspx?q=MDT+2010+New+Feature&p=1

Make sure you review upgrade instructions for moving from earlier versions of MDT to this latest greatest one.

Happy Windows 7 Deploying!

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

Keeping An Eye On USMT Progress v0.2

2009-09-02T18:41:00Z

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

Windows 7 WAIK and Custom Images

2009-08-27T11:50:46Z

Working on customer site recently I was perplexed by why I could not create an unattend.xml file from within MDT 2010 for my custom Windows 7 x32 image. So I did some digging and finally located a program manager who could explain to me what was going on. The summary is that;

if you run Windows 7 x32 and WAIK x32 you can create unattends for both x64 and x32 custom images.
if you run Windows 7 x64 and WAIK x64 you can not create unattends for x32 custom images.
running x32 WAIK on Windows 7 x64 is not supported.

What the program manager said…

I understand that its an annoyance that on x64 machines, you can only create catalogs for x64 WIM's. Back in Vista timeframe, a decision was made to use the servicing stack binaries in the image you're trying to generate a catalog for, in order to create the catalog (as opposed to having WAIK carry those binaries, which created a servicing burden for WAIK). This was a better overall design strategy since it now allowed WSIM to work ok, independent of any changes made to the servicing stack binaries of the image you're trying to generate a catalog for.

However, one side consequence is that the architecture and flavour of the WSIM tool has to match the architecture of the servicing stack ( that was extracted from the WIM ). Since a 32 bit WIM carries only a 32 bit servicing stack in it, 64 bit WSIM cannot generate a catalog due to architecture mismatch. ( Hence one can use only 32 bit OPK for this.) However a 64 bit WIM carries both , a 32 bit and a 64 bit servicing stack in it. Thus one can use either a 64 bit or a 32 bit WSIM to generate a catalog for such a WIM.

I think they have made the right trade off here in terms of reducing the support complexity for Windows System Image Manager. The down side is it might introduce a few extra steps for those of us creating custom images.

So if your admin machine is x64 when you create an unattend for a custom image you have to create it against the RTM media. Then copy the resultant XML to the correct place for your x32 custom image to use when it is installed. Alternatively use an x32 workstation to create all your unattends.

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

Location Deployment Wizard for ConfigMgr 2007

2009-08-17T19:37:00Z

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.

Clustering the MDT Database

2009-08-10T21:32:39Z

Sometimes for availability purposes, it is necessary to ensure the MDT database is clustered to allow failover in case of a server failure or maintenance event. There are a few things that you want to keep in mind when you decide to do this:

1. The SQL Browser service is NOT cluster-aware. This means if you put the database on a named instance of SQL, when clients request a connection to the SQL Cluster IP, the node IP will respond. This makes the Windows Firewall in Vista, Win7 and even Windows PE regard the traffic as unsolicited and hence blocks it. You can add an exception to all of your Full OS clients, however WinPE does not allow you to customize the firewall and you would have to shut the entire firewall off – this is not recommended. The best way to resolve this is to ensure that the MDT Database is on the DEFAULT INSTANCE and does not need to use the SQL Browser service.

2. MDT Authentication share. In order to check windows authentication to the SQL Server, MDT attempts to connect to a Windows Share on the box. In a cluster, you can set this share up as a cluster resource. Ensure that the cluster resource fails over with the MDT database, i.e. is part of the same group. Also make sure that the network access account has access to the share and DB Reader access to the database. If you are not using windows authentication, ensure that you include DBID and DBPW fields in your queries.

3. Use the Cluster name in CustomSettings.ini. In the CustomSettings.ini file, ensure that the name you use for the SQLServer property in each query is the cluster name – do not specify an Instance Name.

4. Named Pipes – Ensure that you have named pipes set up on your SQL Server.

Note that this post covers clustering the MDT database only. You can follow LTI – Following Daniel’s excellent advice on clustering the resource of the Distribution Share http://blogs.technet.com/deploymentguys/archive/2008/03/31/up-ping-the-uptime-of-your-lite-touch-server.aspx you can ensure that this resource is also on the same group as the MDT Database.

Happy clustering :).

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

Windows XP to Windows 7 Migration Guide

2009-08-04T09:52:25Z

Although this post is not strictly a deployment post, I felt it worthy because it offers some assistance for planning your Windows 7 deployments!

A great guide has been posted on TechNet recently that should really help with the Windows 7 deployment discussions that a lot of you are hopefully having :-). The Windows XP to Windows 7 Migration section is a complete guide on pretty much everything you’ll need to know in order to start preparing and planning your migration to Windows 7 from Windows XP. It starts by gathering information about your hardware/software and then helps with the business decisions you’ll need to make based on your inventory and requirements; it also offers tips/tricks/assistance to help things go smoothly.

Find it here: http://technet.microsoft.com/en-us/windows/ee150430.aspx

The only vital thing that seems to be missing from it is a link to this blog…

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