Vista Deployment Postmortem

The lesson here is to always ensure that the equipment you want will remain available throughout the deployment. Had we known about the impending discontinuation, we’d have ordered the alternative model for everyone. The only reason we went with the original model in the first place was that it was slightly smaller and our users like to maximize their desk space.

Printing woes. Initially we tried to use our existing print server, which contained only XP drivers, for Vista machines. That was a mistake. Several of the drivers were incompatible with Vista, which caused the print spooler on the Vista machines to crash on startup and was difficult to troubleshoot.

To resolve the problem, we set up a new print server that contained only Vista drivers and which was used solely by our Vista machines. The new print server was a blessing in disguise, as we intend to retire the XP print server after the migration is complete.

A warning here to folks who are familiar with Windows Server 2003 R2’s print management tools and XP’s PushPrinterConnections. exe utility: As you probably know, Vista doesn’t use PushPrinterConnections .exe to deploy printers via Group Policy. However, printers that are added to a GPO will be installed not only at system startup (as was the case with XP), but also at the next Group Policy refresh.

This Vista-specific behavior hit us hard after we added a new printer model to the print server during the workday and our Vista machines attempted to automatically install the driver at the next policy refresh. The Help desk phone rang off the hook when users, none of whom run with Administrator- level credentials, were unable to install the new driver and didn’t know how to proceed. We were accustomed to adding new printer models to our print server and telling our users (who at that time were running only XP) to “restart if you need new printer XYZ.” We liked the fact that our Vista users no longer needed to restart, but we certainly didn’t want to give them all Administrator-level credentials.

Fortunately, there is a solution to this glitch, and we should have found it sooner. When setting up our Vista GPOs, we took the time to go through all of the available settings, but we glossed over the Point and Print section (which is located under User Configuration\Administrative Templates Control Panel\Printers). This was a key tactical error. As we learned, you can mitigate this undesirable behavior by setting Point and Print Restrictions to Enabled and setting both When installing drivers for a new connection and When updating drivers for an existing connection to Do not show warning or elevation prompt. (For details about how to prevent this Vista glitch from ruining your day, download the Microsoft white paper “Point and Print Security on Windows Vista” at www.microsoft.com/whdc/device/print/VistaPnPSec.mspx.)

Group Policy surprises. A couple of new Group Policy settings in Vista caught us off guard. In our GPOs, we set the user Group Policy loopback processing mode to Merge. As a result, all users should have the same policy regardless of who they are or where they sit. But if you run Gpupdate with the /force switch, the Merge setting produces a hair-pulling error stating that Windows is unable to resolve the computer name. The Microsoft article “Error results when you run the ‘gpupdate /force’ command on a computer that is running Windows Vista: ‘User policy could not be updated successfully’” (support.microsoft.com/?kbid=934907) documents the problem and provides a hotfix, which is also included in Vista SP1.

Our users will often sit at a computer temporarily, and letting all those temporary profiles hang around wastes a lot of disk space. So we were thrilled to see a new Vista GPO setting for deleting user profiles that remained unused after a specified number of days. As we discovered, however, the initial implementation of this feature has a bug. The feature counts the number of days since the profile was created instead of the number of days since it was last used. Panic ensued when the first users to receive Vista machines arrived at work one morning to find that their user profiles had been deleted. SP1 fixes this problem, and a hotfix for pre- SP1 systems is available in the Microsoft article “User profiles are unexpectedly deleted after you configure the ‘Delete user profiles older than a specified number of days on system restart’ Group Policy setting on a Windows Vista-based computer” (support.microsoft.com/?kbid=945122).

IE Protected Mode. Vista includes Internet Explorer Protected Mode, which we happily put to use. We use GPOs to configure our internal application sites as trusted sites. In Vista, trusted sites work as expected, but sites that are not trusted open in a new IE process. Our users found this additional IE window to be confusing. To make them more comfortable, we expanded our list of trusted sites to include trusted vendors’ Web sites, where our users spend a lot of their browsing time. We then did additional education to explain that users should consider one IE window the “work browser” and the other window the “non-work-related browser” for browsing sites such as Google.

This IE Protected Mode experience leads directly to our most important observation.

Insufficient user training. Our users grasped the Vista OS itself easily and quickly. But despite showcasing our new equipment at a company-wide event and involving our users in testing, we realized too late that we didn’t provide enough training on the new machines, especially for Office 2007 and the Ribbon. Everyone in IT loved the Ribbon and found it easy to use, but our users— especially the power Office users—were lost. They immediately wanted to “switch back to the old way,” which of course wasn’t possible. Although those folks learned the Ribbon relatively quickly, they still lost hours of work by fumbling about the interface or by calling the Help desk for assistance.

Bon Voyage!
It’s likely that you’ll make the trip to Vista at some point. Rolling out Vista in an organization isn’t a casual stroll in the park; it requires planning and research. I hope that some of the things we discovered will help your trip go smoothly, and I encourage you to talk to others who have already deployed Vista about their experiences before you deploy. There’s no substitute for hands-on experience and adequate testing, and your users will appreciate the experience more if you involve them in the process as much as possible.