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.