Based on my experiences in the field, including a successful Windows 7 Rapid Deployment Program, I have to say the compatibility story for Windows 7 is surprisingly positive. First of all the number of applications experiencing compatibility issues has been very low so far, and for those that have had issues the solutions have been quick and easy.

In addition to the programs that Mary-Jo mentioned there is another that is specifically geared to application compatibility remediation: Microsoft’s Application Compatiblity Factory (ACF) Program. This program, provided using Microsoft Partners, focuses on using the Application Compatibility Toolkit 5.5 to quickly assess and remediate compatibility issues across the enterprise. It’s a great way to put a box around the scope and scale of potential effort required for an organization’s Windows 7 migration.

Here are some additional links to ACF materials:

• Microsoft ACF Introduction
• About ACF Handout Card

Out of all the programs mentioned, ACF is the most targeted at compatibility remediation. Talk to your Microsoft representative to find a local partner that can provide the service. I think you’ll be pleasantly surprised (and relieved) to find out the reality of your compatibility issues instead of worrying about what you think you might encounter when migrating to Windows 7.

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

When you get to the point “To add RDP protocol permissions to a virtual machine” in Step 2: Installing and Configuring Virtual Machines you’ll quickly realize the command-lines included don’t work on Windows XP:

wmic /node:localhost RDPERMISSIONS where TerminalName="RDP-Tcp" CALL AddAccount "contoso\rdvh-srv$",1
wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='contoso\\rdvh-srv$'" CALL ModifyPermissions 0,1
wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='contoso\\rdvh-srv$'" CALL ModifyPermissions 2,1
wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='contoso\\rdvh-srv$'" CALL ModifyPermissions 9,1

After a bit of searching I found various PowerShell and VB Scripts to configure the settings but none seemed to work as-is. Also, PowerShell wasn’t available on the Windows XP images I was using and I didn’t have the freedom to add it. I tried to simplify the things and ended up with the following two scripts to configure the RDP protocol permissions on Windows XP. You need to replace %DOMAIN% and %ACCOUNT% with the Remote Desktop Virtualization Host domain and computer account name, i.e., “CONTOSO” and “RDHV-SRV$” as per the proof-of-concept documentation. Note the first occurrence has a single backslash but the second one has two. Copy them into a .vbs file and execute them by double-clicking or with cscript from the command-prompt.

set objWMI = GetObject("winmgmts:\\.\root\cimv2")
set colItems = objWMI.ExecQuery("Select * from Win32_TSPermissionsSetting")
for each objItem in colItems
   intRC = objItem.AddAccount("%DOMAIN%\ACCOUNT%", 1)
   if intRC then
      WScript.Echo "Error adding " & strAccount & " to " & _
                   objItem.TerminalName
   else
      WScript.Echo "Successfully added " & strAccount & " to " & _
                   objItem.TerminalName
   end if
next

set objWMI = GetObject("winmgmts:\\.\root\cimv2")
set colItems = objWMI.ExecQuery ("Select * from Win32_TSAccount Where AccountName='%DOMAIN%\\%ACCOUNT%'")
for each objItem in colItems
    intRC = objItem.ModifyPermissions(0,True)
    intRC = objItem.ModifyPermissions(2,True)
    intRC = objItem.ModifyPermissions(9,True)
    if intRC then
       WScript.Echo "Error setting permissions for " & strAccount
    else
       WScript.Echo "Set permissions for " & strAccount
    end if
next

Download Configure_XP.vbs

1. Open the Local Group Policy MMC (Start –> Run –> “gpedit.msc”

2. Configure the required settings.

3. Copy the contents of C:\Windows\System32\GroupPolicy to wherever you want to keep the source Group Policy settings.

4. Copy the contents back onto the system you want to have the same settings, including your reference system if you’re building an image.

A common difficulty in desktop management is configuring per-user settings. Active Setup is a process that runs automatically every time a user logs in to a computer that can address this problem in a simple and flexible way.

If your application requires installation of components such as files or registry keys on a per-user basis, but your application has no advertised entry points or other triggers to initiate the installation process, then Active Setup is the solution.

When the user logs in the registry keys under HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\%APPNAME% are compared to the keys under HKEY_CURRENT_USER\Software\Microsoft\Active Setup\Installed Components\%APPNAME% and if the HKCU registry entries don’t exist, or the version number of HKCU is less than HKLM, then a specified command-line is executed for the current user.

To implement Active Setup, you simply create the required registry key and values under HKEY_LOCAL_MACHINE to execute the command-line that will apply all of the per-user requirements to the system. This could be an executable, an msiexec.exe command-line, regedit.exe, batch file, or any other executable command-line.

Note: Active Setup runs as the current user so it is not suitable for actions that require Administrator or other privileged security rights on the local computer.

Creating the Active Setup Registry Entries

Create the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\%APPNAME%

Where:

• %APPNAME% is an arbitrary string which can be the application name, or its ProductCode GUID if using an MSI. This value should be unique to the application.

Create the following values under the registry key:

Name	Type	Data	Required
(Default)	REG_SZ	%APPNAME%	No
StubPath	REG_SZ	%COMMANDLINE%	Yes
Version	REG_SZ	%VERSION%	Yes
ComponentID	REG_SZ	%APPNAME%	No

Where:

• %APPNAME% is the arbitrary application name specified above
• %COMMANDLINE% is the command-line to execute
• %VERSION% is an arbitrary version number to determine if Active Setup has run for the specific application

When each new user logs on, the operating system compares the Active Setup keys between HKLM and HKCU, and runs the specified command-line if the HKCU entry is missing or the version in HKCU is less than HKLM.

To re-run the same Active Setup or a new version of your per-user application settings, increment the Version registry value in HKLM. The next time the user logs on Active Setup will run again for that user.

An example exported registry file containing the key and values required to configure Active Setup is included below. Simply replace the variables with your required values.

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\%APPNAME%] @="%APPNAME%" "StubPath"="%COMMANDLINE%" "Version"="%VERSION%" "ComponentID"="%APPNAME%"

Example registry file: Active_Setup_Example.reg

Example: Repairing An Existing MSI-Based Application

To force a repair using the existing MSI where a separate Active Setup executable is not required you could use the following example:

Create the registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\%PRODUCTCODE%

Under the registry key create the following values:

Name	Type	Data	Required
(Default)	REG_SZ	%APPNAME%	No
StubPath	REG_SZ	msiexec /fauvs %PRODUCTCODE% /qb	Yes
Version	REG_SZ	%VERSION%	Yes
ComponentID	REG_SZ	%APPNAME%	No

Where:

• %PRODUCTCODE% is the MSI ProductCode GUID for the application.

Here are the top features (but there are a ton more) from the Windows Server Division Weblog:

• Hyper-V and Live Migration – still the big stars. R2’s Hyper-V enables a complete server virtualization solution available out-of-the-box. Live Migration allows server administrators to migrate VMs between physical machines with no perceived downtime for current server connections and work streams. That means a more dynamic datacenter and more agility in meeting new business needs For more information on Hyper-V in R2, check out today’s in-depth post on the Virtualization Team blog.
• File Classification Infrastructure – FCI lets you manage your data based on its characteristics, including things like file type, user credentials and even content. Based on this kind of criteria, FCI can assign data different access restrictions, store it in different locations or simply push it into an entirely customized lifecycle scheme – all done automatically via policy. For me, this is one of the most exciting new features in R2.
• Active Directory and Pervasive PowerShell – 240 new PowerShell cmdlets and several management consoles (including a new Active Directory interface) have been built on top of PowerShell. Active Directory has also been enhanced with the Active Directory Recycle Bin as well as AD Group Policy objects that give desktop administrators deeper capabilities when it comes to managing Windows 7 clients.
• IIS 7.5 – The latest edition of Internet Information Server also sports updated management tools as well as application serving capabilities that now including support for PHP and .NET on Server Core installations.
• Server Scalability – Not only is R2 Microsoft’s first 64-bit-only operating system, it also supports up to 256 logical processors in a single server as well as all the latest CPU technologies. And, R2 has support for advanced storage technologies, including SAN management and solid state hardware.

And there’s going to be some really nice integration between Server 2008 R2 and Windows 7:

• DirectAccess, for example, provides secure, always-on access to corporate networks no matter from what network a client might be connecting. Better yet, it provides a two-way relationship allowing desktop admins to manage clients the same way whether they’re local or remote.
• BranchCache allows users in remote offices to cache corpnet data locally, providing a better work experience for remote workers while simultaneously lowering expensive WAN bandwidth costs.
• Remote Desktop and Applications – Windows Server 2008’s Terminal Services has now evolved into R2’s Remote Desktop Services, and it integrates so tightly with Windows 7 that administrators will be able to roll out virtualized applications and even entire desktop environments without users being able to tell that these tools aren’t running locally. It’s fast and can even be managed via policy. Very cool stuff.

Finally, on the Microsoft Virtualization Team Blog they’ve got a much longer post with more details on Hyper-V 2008 R2 including this awesome news:

“In Hyper-V R2, we spent time analyzing and optimizing the code path for dynamically expanding VHDs and found areas where we could significantly improve performance. In some cases we achieved a 15x improvement for dynamically expanding virtual hard disks. No, that’s not a typo. With dynamically expanding VHDs we can achieve up to about ~87% performance of native throughput.  While we were at it, we took another look at the fixed VHD code path and improved it further so that fixed VHD performance is now on par with native performance.”

Lots more on that post, Hyper-V is taking a big leap forward with this release!

Websites, Blogs & Forums

• Microsoft System Center Mobile Device Manager TechCenter – launch page for all Microsoft MDM resources
• Microsoft System Center Mobile Device Manager Forum – best place for community help
• The System Center Mobile Device Manager Team Blog
• SCMDM Topics at MobilityDojo.net – excellent how-to articles and the author is a top contributor to the MDM Forum linked above
• MDM Product Documentation – lots of content not in the download versions! There’s a good chance you’ll spend a lot of time in the troubleshooting section especially.

Prerequisites & Tools

As I worked through the documentation and virtual implementation (using Hyper-V of course) I started compiling an ISO containing all of the install files, tools, and prerequisites. Here’s pretty much everything that I ended up collecting. You’ll probably need most of them so you might as well download them ahead of time!

• Windows Mobile 6.1 Emulator Images
• System Center Mobile Device Manager Resource Kit Tools
• System Center Mobile Device Manager Product Documentation
• ActiveSync 4.5
• Microsoft Windows Mobile Device Center 6.1 for Windows Vista: 32-bit, 64-bit (can be installed on Server 2008 and Server 2008 R2 RC to get ActiveSync-like capabilities)
• Group Policy Management Console with Service Pack 1
• Microsoft Baseline Configuration Analyzer
• MMC 3.0: Windows XP, Windows Server 2003, Windows Server 2003 x64 Edition
• PowerShell 1.0
• Microsoft Report Viewer Redistributable 2005 SP1
• Windows Server Update Services 3.0 SP1
• Microsoft .NET Framework 2.0 Service Pack 1: x86, x64
• Windows Mobile Network Analyzer PowerToy

Non-Microsoft Tools

• Hosts File Editor for Windows Mobile
• vxUtil Network Utilities for Windows Mobile (ping, tracert, DNS lookup, etc)
• CeRegEditor – Windows Mobile registry editor
• Wireshark – nice free network protocol analyzer (for when you really need to know if the device is talking to the gateway, etc)

Simplifying mobile device management is not so simple… I recently had the challenging experience of designing and implementing a Microsoft System Center Mobile Device Manager 2008 SP1 solution. If you’ve worked with the product then you know that the Best Practices Analyzer (BPA) is an invaluable tool to determine the answer to the inevitable question, “Why the $@#% is this thing not *%&# working!”.

The first step in runing the BPA is to enter the servers that are part of the installation and verify connectivity. In this case the connectivity check for the Gateway Server was returning “Machine is unreachable”. Ok, no problem, checking the MDM Planning Guide shows that we need TCP 443 open between the Device Management Server and the Gateway Server. We assumed the BPA would validate connectivity using the ports listed in the planning document since the Gateway is typically not domain joined and lives in the DMZ blocked on all sides by firewalls.

That’s not the case!

To get the BPA to validate connectivity to the Gateway server you will need to allow ICMP/PING to through your firewall to the server. After this the pre and post-deployment analyses will use the specified ports.

Once you’ve successfully implemented MDM you can deny ICMP/PING on your firewall as you normally would.