Vista Deployment Postmortem

Many organizations are still pondering whether and when to deploy Windows Vista. With the recent release of SP1, those who were planning to “wait for the first service pack” might soon be taking the plunge.

Before they do, however, they’ll probably reach out to other admins who have already deployed Vista for a heart-to-heart about the experience. When you’re going somewhere you’ve never been before, you’d like to be able to get there without running into detours, roads under construction, and bridge trolls. Hearing from others who have made the trip before you will help you know what landmarks to look for and plot alternative routes around problem areas.

My organization recently deployed Windows Vista Business, and I might be able to help you enjoy your trip to the same destination by sharing two things. The first is the positive experiences of our deployment. Maybe you can expand upon our experiences and make your deployment all the better. The second and perhaps more important is what I wish I’d known beforehand or spent more time on in research, during testing, or both.

The Positives
Overall, our implementation went extremely well, despite the bad press that Vista’s received. We feared that the publicity would prejudice our users to think that “Vista is bad” before we even began—and it did, but our deployment went well enough to allay any initial user pushback. The things we did right included replacing all PCs, showcasing the new systemsat a company meeting, and investing in an extended warranty with onsite service.

New hardware. One of the first decisions we made that, in hindsight, was a good one, was to lease brand-new equipment, both monitors and computers, rather than upgrade our existing systems. There were two reasons for this decision. First, many of our existing machines were simply incapable of running Vista even if we upgraded them—most were four- or five-year-old IBM NetVistas with 256MB of RAM and integrated graphics. Second, many of the machines had outlived their useful service life and their components were beginning to fail. One benefit of Vista that we proclaimed to our users was the Aero interface, especially the Flip 3D feature. We wanted our users to have the best Vista experience possible, and that couldn’t happen with the equipment we had in service.

Identical equipment under excellent warranty. Our existing systems had been purchased through several different channels in an attempt to obtain the best price at the time. The result was a mishmash of warranty coverage that ranged from one to three years for different PCs. When a component such as a power supply failed, we often had to buy a replacement part out of pocket rather than have it replaced under warranty. Even systems that remained under warranty didn’t have on-site support coverage, which caused us to spend a considerable amount of time repairing failed systems.

For our Vista deployment, we made sure that all our new equipment was identical in every way, shape, and form. We also obtained a warranty that includes next-business-day onsite service for the length of the lease, which let us easily swap components and replace faulty components and machines almost immediately. This warranty has already paid for itself half a dozen times.

All the new computers support dual monitors out of the box. Previously, when a user requested and received approval for dual monitors, we had to open the user’s machine and install a video card and drivers. Now we simply plug in a new monitor, which is a huge time saver for us and for the user. Ensuring that machines support dual monitors might just be common sense, but I wish that someone who had more common sense than I did at the time had reminded me of it four years ago when we were deploying Windows XP.

Standard image. Our primary piece of software is a .NET Web application, so our most valued Microsoft application is Internet Explorer (IE). Our users also run Microsoft Office, with Adobe Reader rounding out the software suite that 90 percent of our users rely on. The remaining 10 percent use a handful of specialized applications, but not everyone in that 10 percent uses the same applications.

As a result of our users’ application needs, we decided to build one Windows Imaging Format (WIM) image and deploy it to all users. For users who were in the “special 10 percent,” we either installed the specialized applications manually or deployed them through Group Policy. This approach was very successful, allowing us to create an image that requires less maintenance longterm as the applications are upgraded.

Separate OU for Vista machines. For our Vista machines, we created a new organizational unit (OU) and Vista-specific Group Policy Objects (GPOs) that we linked only to that OU. This approach let us test all new Vista-specific settings and make changes to them without affecting the installed base of XP machines. By letting us modify settings on only the new machines and quickly see the results in production, the new OU and GPOs had already paid for themselves by the time we’d finished ourinitial 20-machine rollout.

Introduction of new systems. At a company- wide meeting, we showcased the new equipment and some of the new features of Vista and Microsoft Office 2007, such as Flip 3D and the Ribbon. A big highlight was our demonstration of the monitors, which are able to rotate into a vertical position. At least 60 percent of our users have elected to keep their monitors in this position because it gives them more screen real estate for reading long documents. The public demonstration gave our users the opportunity to ask questions and let us present the timetable for rolling out the new systems, but the biggest benefit of the introduction was that it excited users and management and brought them on board with the Vista deployment.

User-assisted testing. Our users know their applications far better than we in IT do. For example, although the accounting package installed and ran fine, the IT staff doesn’t have the necessary permissions to perform many of the functions that the software offers. During the initial testing of the Vista WIM image, we invited users to spend some time doing their work in the IT department and tell us about any problems they encountered. By inviting users to work with their software on the machines they’d eventually have, we resolved several problems before the systems were put into production. User involvement brought to light many concerns that we were able to eliminate before deployment and made the whole project proceed more quickly andsmoothly than it otherwise would have.

The Negatives
None of the problems we ran into were show-stoppers, but we certainly would have liked to have known about all of them ahead of time. Fortunately, we were able to successfully deal with all our negative experiences, albeit not always as quickly as wewould have liked.

Discontinued equipment. Shortly after we ordered an initial batch of new machines, our supplier informed us that HP was discontinuing that model. The replacement had similar specifications but a different external appearance. We ordered as many of the original units as we could but were forced to switch to the other model for 20 percent of our deployment. As a result, users who received the discontinued model experienced computer envy, thinking that others were getting newer computers and that theirs was instantly junk, or at least outdated. No amount of explaining that the specifications were virtually identical allayed that feeling.

Continue to page 2

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 ConfigurationAdministrative Templates Control PanelPrinters). 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.