Windows 7 RTM Issue with Group Policy Enforced Wallpaper

I was asked by our Support folks to let you know about an issue that effects Windows 7 when you try to set the desktop wallpaper through Group Policy.  I am blogging this on the Deployment Guys blog because the issue can be avoided by a configuration item in the image build.

Under certain circumstances when you try to use this group policy setting (User Configuration\Administrative Templates\Desktop\Desktop\Desktop Wallpaper) the desktop wallpaper isn't applied and a solid background is displayed instead.

This problem can occur if a desktop wallpaper is applied through group policy and any of the following conditions exist:

• The default theme applied doesn't explicitly define a desktop wallpaper
• The user has never explicitly defined a desktop wallpaper
• A classic theme is in use

This problem occurs if the Wallpaper registry value in HKEY_CURRENT_USER\Control Panel\Desktop is either missing or empty. 

Therefore, you can avoid this issue in your Windows 7 image by configuring a default wallpaper.  See my October 29, 2009 post for information on creating default settings.

To fix this in machines that have already bee deployed, you need to configure the above registry value with a non-blank value.  This can be done in one of several ways:

• Use a Registry preference group policy to set the Wallpaper value. For more information on how to create a registry group policy preference, see http://technet.microsoft.com/en-us/library/cc753092.aspx.
• Create a custom Administrative Template to set the Wallpaper value. For more information on how to create a custom administrative template, see http://technet.microsoft.com/en-us/library/cc738443(WS.10).aspx.
• Use a logon script to to set the Wallpaper value.
• Use a computer startup script to load the Default User registry hive and set a default Wallpaper value.  See method C of my October 29, 2009 post details on how to do this.

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

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

Happy Halloween - Windows 7 style

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 Murgolo a Senior Consultant with Microsoft Services, U.S. East Region.

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

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 saver options. Most of these will be initial settings for user preferences that users will be able to change (unlike policies which are enforced). This is done so that users will have a consistent, known experience when logging on to any client computer for the first time.

This can be done in a number of ways.  Below are the methods I have seen or used with what I feel are pros and cons of each.

Implementing Default User Settings by modifying the Default User Profile

There are three main methods that have been used to configure the Default User profile.  Only one method (B) is now officially supported and I recommend that you use this method.

A. Manual or scripted copy of a configured profile over the Default User profile (unsupported)

The traditional solution for this (developed during the Windows NT Workstation days) was to configure the Administrator account (or another designated account) with the settings, then copy the Administrator (or designated account) user profile over the Default User profile.  This was previously documented in numerous Knowledge Base articles (which have now been deleted).  A tool called CopyProfile was even created to script this process during unattended installations of Windows XP.

However, there are problems with using this procedure.  It is very old procedure from NT4, when the shell was much simpler.  The shell is more complicated for Windows 2000 and higher.  This process will copy settings that should not be copied to the default user profile.  It may seem to work but you will find subtle problems.  Windows XP and later have made those subtle problems more visible.

Also, the Default User profile contains some single run actions that occur when the user logs in for the first time, which then setup that user by running those custom actions.  If you overwrite the Default User profile, those single run actions do not take place.

The manual profile copy process can cause issues such as:

• Their list of most frequently run programs is not cleared
• Whether the user has been introduced to the Start menu (will be set to TRUE for the source account, but should be FALSE for new users). Windows Explorer does some special things the first time you log on to introduce you to the Start menu and other new features.
• Whether the user is an administrator (and should therefore see the Administrative Tools, etc).
• The personalized name for “My Documents” will be incorrect. All users documents folders will be called “Administrator's Documents”.  This is documented in the Knowledge Base article “The Desktop.ini File Does Not Work Correctly When You Create a Custom Default Profile” (http://support.microsoft.com/?id=321281).
• The default download directory for IE will be set to the Administrator's Desktop folder.
• The default Save and Open locations for some application with point to the Administrator's documents folder.
• Windows 7 Libraries are broken.

Because of these issues, this process is no longer supported in Windows XP and all later operating systems.  Unfortunately, the ability to copy a profile over the Default User profile was not blocked in Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008.  This allowed many administrators to continue using the process and putting their Windows installations into an unsupported state.  To prevent this, Windows 7 and Windows Server 2008 R2 now block this scenario by having the Control Panel System applet gray out the option to overwrite the Default User profile.

At this time the only supported way to configure the the Default User profile using a copy of a configured profile is to use the next method described here, the automated profile copy associated with using Sysprep.

B. Automated profile copy with Sysprep (supported)

First introduced in Windows XP Service Pack 2 (http://support.microsoft.com/?id=887816), Minisetup was modified so that it will copy customizations from the local administrator account to the default user profile.  All subsequent versions of Windows will also do this with the proper entries in the answer file.  This process was designed to avoid the problems with method A and is already automated. 

I won’t dwell on how the automated profile copy is used since it is documented in several Knowledge Base articles:

How to customize the default local user profile when you prepare an image of Windows Vista, Windows Server 2008, Windows XP, or Windows Server 2003
http://support.microsoft.com/?id=959753

How to customize default user profiles in Windows 7
http://support.microsoft.com/?id=973289

However this process does have a drawback.  It does not propagate all settings to Default User and there is no known documentation as to what will and will not be propagated.  It also can be difficult to determine if a setting did not carry over to a new user because it was considered inappropriate (i.e. not copied to Default User by design) or is being reset by Minisetup/Specialize or first logon processes.

One final important point to remember is the difference in behavior between Windows XP/Windows Server 2003 and Windows Vista and higher with respect to when the answer file setting must be present for the automated profile copy to occur.  On Windows XP and Windows Server 2003, if you want to change the behavior of the automated profile copy, the UpdateServerProfileDirectory entry must be present in Sysprep.inf when Sysprep is run.  This is because the profile copy happens when Sysprep is run on Windows XP and Windows Server 2003.  The exact opposite is true for Windows Vista and higher.  The CopyProfile setting must be set to True in the final answer file that is present when the OS restarts after Sysprep (Specialize phase) or the answer file used when Setup is used to deploy the custom image.  This setting does not necessarily have to be present in the answer file used during the image build when Sysprep is run (Generalize phase).  This is because the profile copy for Windows Vista and higher happens only during the Specialize phase.  So if you are using a deployment tool like ConfigMgr or MDT that may modify/replace the Unattend.xml, make sure that CopyProfile is configured in the answer file used for deployment.

C. Targeted changes to the Default User Registry hive and profile folders

I used to use this method in the before the automated profile copy existed.  I can be useful when only a small number of targeted changes are required.  It can be described as follows:

1. Identify the needed Registry changes.  Then use a tool like Reg.exe or KiXtart to load the Default User hive into a temporary location into the Registry, write only the needed settings, and then unload the hive.  The Knowledge Base article “How to run a logon script one time when a new user logs on” (http://support.microsoft.com/?id=284193) shows how to do this manually.  This can be scripted for an unattended installation using Reg.exe as shown in this example (these lines may wrap due to page width):

:: ***** Configure Default User
:: *** Load Default User hive
reg load "hku\Test" "%USERPROFILE%\..\Default User\NTUSER.DAT"
:: *** Disable Desktop Cleanup
reg add "hku\Test\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\CleanupWiz" /v NoRun /t REG_DWORD /d 1 /f
:: *** Unload Default User hive
reg unload "hku\Test"

2. Copy only needed files or shortcuts to the Default User profile folder.

This has the advantage that all changes to Default User are known and predictable.  However, this requires that all changes be reduced to “scriptable” items (i.e. Registry or file system changes, no manual configuration). 

To get this method to work properly on various service pack versions of Windows XP or Windows Server 2003 you have to disable the automated profile copy.  In some cases you have to either install the hotfix from this KB article: http://support.microsoft.com/?kbid=887816 or set UpdateServerProfileDirectory=0 in Sysprep.inf.  Which service packs versions have the automated profile copy enabled by default are documented in KB959753.  In Windows Vista and higher the automated profile copy is disabled by default.  You would then do the Default User hive registry edits before Sysprep runs.

This method can also be used to make changes to the Default User profile for machines that are already deployed in production.

You should exercise caution using this method.  Try to keep all changes limited to only the individual Registry or file system changes needed for a particular desired result (e.g., a Windows or application setting).  Do not do wholesale export and import of Registry keys or folder trees.  This can potentially lead to the same problems as a manual profile copy.  You can use a tool like Sysinternals Process Monitor to identify the individual changes.

Implementing Default User Settings by Using Scripts or Group Policy

The following methods are not for configuring the Default user Profile directly.  However, they can be used to achieve the same effect (configuring settings the first time a new user logs on).  And they have the added advantage of potentially being centrally managed.

D. Local logon script in the RunOnce Registry key

This is documented in “How to run a logon script one time when a new user logs on” (http://support.microsoft.com/?id=284193).  This manual process can be scripted with reg.exe.

There are several advantages to using a script in the default user RunOnce key.  It completely avoids Sysprep, CopyProfile, Minisetup/Specialize, or first logon processes effects.  Also, if after deployment the default initial user settings need to changed, only the script file needs to be updated (instead of having to script a load/unload of the default user hive and fixing multiple settings).   Finally, it is easy to “reset” a user’s setting to the defaults because the script can be kept up to date and present on every box through software distribution or Computer Startup Scripts.  This method also requires that all changes be reduced to “scriptable” items.

E. Local or Domain GPO logon script

A Group Policy logon script can be used to set “default settings” once by having the script set a flag after it first runs (perhaps an HKCU Registry entry) that it will look for and exit if found on subsequent runs.  A Domain logon script has the added benefit of being centrally managed.  This method also has the same advantages as method D.  This method also requires that all changes be reduced to “scriptable” items.

F. Group Policy Preferences

Group Policy preferences first shipped as part of the Group Policy Management Console (GPMC) in Windows Server 2008.  GP preferences consist of more than 20 Group Policy extensions that expand the range of configurable settings within a Group Policy object (GPO). Many of these extensions can configure settings that are commonly configured as default settings in a desktop image. Unlike policies, GP preferences can be changed by the user in most cases. Also, GP preferences can be configured to “apply once and do not reapply”. This allows them to behave exactly like initial default settings configured in an image but has the benefit of being centrally managed and updated.

GP preferences cover many of the areas where default settings are usually configured such as:

• Environment Variables
• Files
• Folders
• INI File Settings
• Registry
• Shortcuts
• ODBC Data Sources
• Folder Options
• Internet Settings
• Local Users and Groups
• Network Options
• Power Options
• Regional Options
• Scheduled Tasks
• Start Menu

The main disadvantages GP preferences are that it requires either Windows Server 2008, Windows Server 2008 R2, the Remote Server Administration Tools (RSAT) update for Windows Vista with Service Pack 1 or higher, or the RSAT update for Windows 7 to manage them and client-side extensions (CSEs) have to be installed for Windows Vista RTM, Windows XP with Service Pack 2, and Windows Server 2003 with Service Pack 1 or higher.  For those still managing Windows 2000 images, you will have to use one of the previous methods mentioned since GP preferences will not work on Windows 2000.

I believe that GP preferences will likely be the best way to manage this going forward. Simply create GPOs using GP preferences, target them as needed, install the CSEs into the image(s) as needed, and you no longer need to worry about configuring these settings in the client image(s).

For information about Group Policy preferences see the following web resources:

Group Policy Preferences Overview

http://www.microsoft.com/downloads/details.aspx?FamilyID=42e30e3f-6f01-4610-9d6e-f6e0fb7a0790

Group Policy Preferences Frequently Asked Questions (FAQ)

http://technet.microsoft.com/en-us/windowsserver/grouppolicy/cc817590.aspx

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

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

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

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 for both the deployed machines in ConfigMgr environment and the reference machine during an image capture in the MDT standalone environment.

To create a right click action to approve Update Lists in a standalone WSUS Server:

1. Create your Software Update Lists in ConfigMgr and assign them to a Deployment Package. Download and approve the updates as you would normally in ConfigMgr by creating a Deployment Template.

2. Synchronize your external standalone WSUS server with Microsoft to pull down updates. Note this server should not be a Software Update Point.

3. Download the attached scripts to create a right click action:

a) Copy the a7252c9e-3137-49a4-a8f2-13d17bb8abd0 folder to your ConfigMgr site server  e.g. %ProgramFiles%\Microsoft Configuration Manager\AdminUI\XMLStorage\Extensions\Actions. Substitute the first part of the path with your ConfigMgr path.

b) Copy the ApproveUpdatesToWSUS.ps1 script to a new folder at %ProgramFiles%\OSDLifeCycle\Scripts . Ensure that powershell is installed on your server and that the execution policy is set appropriately.

c) Edit the ApproveUpdatesToWSUS.ps1 file and replace MYUPDATESERVER with the name of you standalone WSUS server.

4. Reload your ConfigMgr Console using an account that is the WSUS Administrators local group on the WSUS Server.

5. Right Click on your update list and you should see “Publish these updates in a WSUS Server”. NOTE: This will accept the EULA of any of the updates in the Update List. Ensure you review any EULAs in ConfigMgr before choosing this option.

6. Ensure the updates were approved successfully and close the powershell window.

7. In the customsettings.ini file of your MDT Image Engineering environment set the WSUSServer variable to equal the location of your server (e.g.WSUSServer=Http://MyUpdateServer)

8. Update your Deployment Share

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.

Essential Guide for Deploying Windows 7

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:

• Deployment Platform
• Planning Deployment
• Testing Application Compatibility
• Developing Disk Images
• Migrating User State Data
• Deploying Applications
• Preparing Windows PE
• Configuring Windows Deployment Services
• Using Volume Activation
• Deploying with Microsoft Deployment Toolkit

It is a good read, and I strongly recommend it to everyone, not just to the techies who will work on the deployment, but also to the decision makers as well.  You can get the book here: http://www.microsoft.com/downloads/details.aspx?FamilyID=EE2A1D38-88A9-43B3-95BC-7E962F0B6030&displaylang=en

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

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.

Reporting on Office 2007 Customisation Settings

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 each and every setting by hand writing down what is set and what’s not, compiling this into a report and then cross checking back with expected behaviour.

Not any more. I recently stumbled across a vbScript that will export the settings in the MSP to an XML file. This can then be viewed via a browser, imported into Excel or some other XML handling application. Now I can quickly review the settings inside each MCP, identify what has been changed and the value it has been changed to and remediate as required. I wish I had found this a few years ago!

The script and instructions for running it can be found here - http://technet.microsoft.com/en-us/library/cc179027.aspx.

There is also good information here on how to use the individual OPA files for each part of the Office Suite to determine what the numeric values mean.

For example here you can see a section of the XML where I specify the company name, the license key and some Outlook configuration options.

<Install>

<AcceptLicense>true</AcceptLicense>

<CDKey>XXXXXXXXXXXXXXXXXXXXXXX</CDKey>

<SourcePaths />

<CompanyName>Microsoft</CompanyName>

</Install>

<Outlook prf="CustomizationFile.F2288213.A8EB.4F37.BBFE.BCA2498927BB" customizationOption="3" modificationOption="0" newProfileName="Contoso eMail" modifyProfileName="" importPrfFilename="" configureExchangeServer="1" configureExchangeMailbox="1" selectedProfileOption="0" newMail="0">

<ExchangeSettings userName=%UserName%@contoso.com serverName="mail.contoso.com" account="Microsoft Exchange Server" overwrite="false" enableOffline="false" ost="%USERPROFILE%\local settings\application data\microsoft\outlook\outlook.ost" oab="%USERPROFILE%\local settings\application data\microsoft\outlook\" localCopy="true" headersOnly="false" fullItemsOnly="true" downloadSharedNonMail="true" headersOnlySlow="true" downloadFldrFav="false" />

<RPCandHttpSettings configureOutlookAnywhere="false" />

</Outlook>

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

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

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 the first drive. 

Here are the steps to work around the issue:

• Add a Set Task Sequence variable step to set BDEINSTALL=KEY. 

• Add a Set Task Sequence variable step to set OSDBitlockerTargetDrive to the drive letter to be encrypted (D: in this case). 

• Finally, add an Enable BitLocker step for the second partition.  Configure this for the second partition (D: in this case)

With theses additions to the task sequence,  the C: drive is protected by the TPM and the D: drive will be protected by a key and will be autounlocked when the system boots.

There is one additional issue with encrypting additional drives.  ZTIBDE.WSF does not implement the wait for BitLocker to complete on all drives before continuing the task sequence execution for additional drives.  Working around this issue requires editing the ZTIBDE.WSF Script.

1. Move line 68 (Dim sOSDBitLockerWaitForEncryption        ) to line 47 and change Dim to Public. (Public sOSDBitLockerWaitForEncryption)
2. Copy the following lines starting at line 439 and past it at line 506:

If sOSDBitLockerWaitForEncryption = "TRUE" Then

    oLogging.CreateEntry "Begining the wait for drive encryption to complete. This can take a signifigant amount of time.", LogTypeInfo
    WaitForEncryptionCompletion
End If

This post was contributed by David Hornbaker a Senior 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.

Making WinPE Wait for Network in LTI Deployments

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

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.

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

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

Using and Extending Model Aliases for Hardware Specific Application Installation

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 )

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

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

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

MDT 2010 is Released to the Web!

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

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

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.

Windows 7 WAIK and Custom Images

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

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:

1. Configure the Bootstap.ini file
2. Create a custom boot image
3. Configure Location settings in the MDT Database
4. 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.

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 Mark Hooks and Richard Smith, consultants with Microsoft Services – U.K.

Clustering the MDT Database

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 :).

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 Aly Shivji a consultant with Microsoft Services - U.S. East Region.