After following a thread on a myITforum mailing list about the same issue I put together this solution using this Video Resolution Changer which worked best for me out of the bunch that were mentioned. You could swap it out for another EXE by modifying the script.

The display resolution is configured automatically during deployment by running ResSwitch.vbs as a step in the task sequence. I started with this Speed/Duplex script and modified it to set the resolution instead, using ResSwitch.ini to hold the configuration.

ResSwitch.ini uses the following format:

[HWP2694]

;HP L2045w

WIDTH=1680

HEIGHT=1050

Where the string between the brackets must be found in the “PNPDeviceID” WMI value in the root\cimv2\Win32_DesktopMonitor class. Lines beginning with “;” are ignored. You must include WIDTH and HEIGHT entries to specify the desired display resolution. All displays will be set to 32-bit colour depth and 60Hz refresh rate.

To retrieve the PNPDeviceID value in order to add a new monitor to ResSwitch.ini you can run the following:

1. Open a Command Prompt

2. Run “wmic desktopmonitor list full”

3. Look for the PNPDeviceID value and select a subset to use as the search string. Typically the value between the backslashes will work best.

To use the script just unzip the ResSwitch.zip file below, download the Video Resolution Changer and copy 1365VidChng.exe to the same folder. Then run ResSwitch.vbs, i.e., “cscript ResSwitch.vbs”.

It would be cool to collect a whole bunch of PNPDeviceIDs with resolutions to build a comprehensive INI file. Feel free to post yours in the comments and I’ll add it to the file!

ResSwitch.zip

################    ZTIApplications    18/09/2009 1:00:35 PM    0 (0x0000)
Dependent entry: {24db38a6-bb6d-4c05-acad-25682702ccb7}    ZTIApplications    18/09/2009 1:00:35 PM    0 (0x0000)
################    ZTIApplications    18/09/2009 1:00:35 PM    0 (0x0000)
Using a local or mapped drive, no connection is required.    ZTIApplications    18/09/2009 1:00:35 PM    0 (0x0000)
Change directory: Z:\Applications\Adobe Reader 9.1.3    ZTIApplications    18/09/2009 1:00:35 PM    0 (0x0000)
WARNING - unable to set working directory:  (-2147024893)    ZTIApplications    18/09/2009 1:00:35 PM    0 (0x0000)
Run Command: \\server.domain.com\DeploymentShare$\Tools\X64\bddrun.exe Adobe_Reader_9.cmd    ZTIApplications    18/09/2009 1:00:36 PM    0 (0x0000)
ZTI installing application     ZTIApplications    18/09/2009 1:00:36 PM    0 (0x0000)
About to run command: \\server.domain.com\DeploymentShare$\Tools\X64\bddrun.exe Adobe_Reader_9.cmd    ZTIApplications    18/09/2009 1:00:36 PM    0 (0x0000)
Return code from command = 2    ZTIApplications    18/09/2009 1:00:36 PM    0 (0x0000)
Application Adobe Reader 9.1.3 returned an unexpected return code: 2    ZTIApplications    18/09/2009 1:00:36 PM    0 (0x0000)

I had recently enabled logging (SLShare), and dynamic logging (SLShareDynamicLogging) to try to track the various pilot deploys that were going on. Disabling SLShareDynamicLogging resolved the issue.

Why only some applications? It was the applications that were using a .BAT or .CMD file to install. Those files require an environment with a current working directory and so need to be run from a mapped drive. The other applications either ran a .VBS script or the installation executable directly. They were able to run using the just the UNC path.

End result is that if you want or need to use SLShareDynamicLogging you’ll need to make sure none of your applications are using .BAT or .CMD based installations.

I’ve got a Windows XP REFRESH scenario working and USMT is doing what it’s supposed to do even with hardlinking enabled and working automatically. But it’s not capturing the users’ mapped printers and network drives, or other user settings. My Documents, desktop items, IE favourites, those are all fine.

It took a fair bit of digging but I finally came across this in USMTcapture.log

?2009-09-23 15:16:05, Info                  [0x000000] Downlevel Manifests folder is not present. System component settings will not be gathered.

This Downlevel Manifests folder is pretty important. It’s used to gather all of those user settings from older operating systems like Windows XP.

I poked around and the DlManifests folder was being copied from the deployment share and it looked like the correct folder structure was in place:

Scanstate.exe just wasn’t finding the DlManifests folder. On a hunch, I ended up modifying the ZTIUserState.wsf script to specifically set the current working directory to “C:\MININT\USMT” and it fixed the problem!

Here’s what I added to ZTIUserState.wsf starting around line 620:

On Error Resume Next
‘*** BEGIN MODIFICATIONS ***
Dim objShell
Dim sCurDir
‘ Save current directory
sCurDir = oFSO.GetAbsolutePathName(“.”)
oLogging.CreateEntry “Saved current directory: ” _

& sCurDir, LogTypeInfo
‘ Set the current directory to sUSMTPath
Set objShell = CreateObject(“WScript.Shell”)
objShell.CurrentDirectory = sUSMTPath
oLogging.CreateEntry “Set current directory: ” _

& sUSMTPath, LogTypeInfo
‘*** END MODIFICATIONS ***

sCmd = “cmd /c “”"”" & sUSMTPath & “\scanstate.exe”" ” _

& sScanStateArgs & ” > nul 2>&1″”"
iRetVal = oUtility.RunWithHeartbeat(sCmd)

‘*** BEGIN MODIFICATIONS ***
‘ Reset current directory to original value
objShell.CurrentDirectory = sCurDir
oLogging.CreateEntry “Set current directory: ” _

& sCurDir, LogTypeInfo
‘*** END MODIFICATIONS ***

UPDATE: I’ve attached the working ZTIUserState.wsf script. Big note, this is a modified MDT 2010 RC script. I’m not sure if there are other changes between RC and RTM. I’ll take a look when I find a spare hour!

UPDATE2: Thanks Johan for confirming below that the fix applies to both MDT 2010 RC and RTM.

UPDATE3: This same fix works for MDT 2010 RC and RTM. The only difference (confirmed by Johan below) is the version number in the script comments. I’ve updated the attachment to include the RTM version of the script.

ZTIUserState