The lowdown on deploying Windows 7

J Peter Bruzzese runs through the do's and dont's of the new OS

Windows 7 is right around the corner. The official release date is October 22, but some PC makers will ship it before then. Most businesses skipped the poorly received Vista, choosing instead to run the now eight-year-old XP. So after holding off on a Windows upgrade for so long, many are no doubt ready to adopt Windows 7.

But how should you migrate to Windows 7? The answers depend on several factors specific to your environment, but let me walk you through the key decisions and options you'll have to address to ensure a successful migration.

First off, you need to consider the number of systems on which you plan to deploy Windows 7. As part of that, ask yourself if you can use existing hardware or if you must purchase new PCs. Windows 7, for example, requires at least 2GB of RAM, and you'll want at least a 1GHz dual-core CPU and at least 16GB of installation space for the 32-bit version of Windows 7 and 20GB for the 64-bit version. The PCs should also have a DirectX 9-compatible graphics processor or card with WDDM 1.0 or higher driver.

You may be thinking, "I'll need all (or many) new PCs to run Windows 7, so I'll automatically go with the 64-bit version of the OS." But before you do that, weigh the pros and cons. Although any new PC should be capable of supporting both the 32-bit and 64-bit versions of Windows 7, you may not yet want the 64-bit version in your production environment. The 64-bit OS supports much more RAM than the 32-bit version (which in practice is limited to about 3GB of available RAM), and it offers enhanced security through hardware data execution prevention, kernel patch protection, and mandatory driver signing.

But many peripherals' drivers do not work with the 64-bit OS — and neither do 16-bit applications nor unsigned kernel-mode drivers. Thus, adopting the 64-bit Windows 7 may require a wholesale change in your hardware and application environment, not just new PCs. Plus, some 32-bit applications may run slower on the 64-bit OS.

Your next logical step is to determine which versions of Windows 7 you will need for your deployment. Keep in mind that the edition you choose may not have the features you thought it did. For example, if you want BitLocker encryption on the system, perhaps for your laptop deployments, the Professional Edition isn't going to work for you; you need either the Enterprise Edition (which requires a volume licence) or the Ultimate Edition. The same holds true for working with DirectAccess (VPN-less access for mobile users) and BranchCache; both require the Ultimate or Enterprise editions.

These two editions also offer the Windows 7 UI in 35 languages in a single OS image for global deployment. But one advanced feature — Windows XP Mode (aka XPM), for running XP in a virtual machine — is available in the Professional, Ultimate, and Enterprise editions.

In addition, the Enterprise Edition supports federated search across remote repositories, AppLocker policy-based management of user apps, and multiple-monitor and microphone support in virtual desktop infrastructure (VDI) environments.

Addressing hardware and software compatibility issues

Before you begin rolling out Windows 7, be sure to deploy it in a smaller environment to test your systems. That way you can identify if your PCs have any issues with their hardware or software. You can try running Microsoft's Windows 7 Upgrade Advisor utility (currently in beta). You can also quickly test PCs' support for Windows 7 using InfoWorld's free Windows Sentinel tool. However, if you need a more serious tool for your organisation, go with the Microsoft Assessment and Planning Toolkit (MAP) 4.0. MAP provides an agentless scan of your systems to inventory your system hardware, checks for compatibility, and reports where you stand.

If you have legacy 16-bit applications, note that they will not run in the 64-bit version of Windows 7. You can run them in the new XP Mode virtual machine that comes with the Professional, Ultimate, and Enterprise versions of Windows 7, or natively in the 32-bit version of Windows 7. XP Mode is useful not only for running 16-bit apps but for any programs that require legacy application compatibility.

Windows 7's XP Mode

To use XP Mode, your PCs must support processor based virtualisation (either Intel-VT or AMD-V), which leaves out a lot of older PCs. Users start and run applications in XP Mode just as they do native applications; however, these applications cannot take advantage of native Windows 7 features such as the Aero interface.

From the software perspective, you may want to look into the Application Compatibility Toolkit (ACT) 5.5; it has a variety of tools that help determine which applications will function smoothly in Windows 7 and which ones will give you trouble.

ACT does require a local agent be installed on the systems you are testing; those agents drill down into the systems to find every last application you've forgotten about and report them back to the server. Typically you don't need to scan every single machine in the enterprise; a few representative machines from different departments and locations should provide enough of a baseline.

One of my personal favorite tools from the Application Compatibility Toolkit is the Standard User Analyzer (SUA), shown at right, which requires you to install the Application Verifier tool. SUA lets you loosen User Access Control (UAC) permissions for standard users for those applications that UAC causes to issue many "are you sure?" messages. (UAC's overeagerness was one of users' main dislikes of Vista).

Addressing the licensing question

Now that you've done the footwork and have PCs ready to deploy, it's time to think about licensing and activation. In enterprise deployments, it's best to use a volume licence and the product activation approach called Volume Activation (VA) introduced with Vista. To use VA, you need either a Multiple Activation Key (MAK) or a Key Management Server (KMS), which requires a KMS key. The mechanics of getting these keys is complicated, so Microsoft has a help page on how to do it.

Note that Microsoft has many types of licences for Windows and other products. When upgrading to Windows 7, be sure not to confuse the volume licence with the Enterprise Agreement, Enterprise Subscription Agreement, or Software Assurance (SA) programs. The two agreements are essentially maintenance agreements that include the SA program, which lets you upgrade to a new version of Windows at any time during your agreement period, in exchange for a per-system annual fee. Given Microsoft's slow OS update schedule and the lack of transferability of SA coverage to new PCs, this insurance-type plan has ended up costing businesses more per desktop than simply purchasing upgrade licenses for old PCs and getting the OS included with new system purchases.

Migrating your PCs to Windows 7

You have probably already heard the news that XP cannot be upgraded in-place to Windows 7, so your applications and data are not migrated. On a single system, that may be frustrating (although you could upgrade to Vista and then upgrade to Windows 7), but larger businesses don't do in-place upgrades anyhow. For corporations, in-place migration from XP is a non-issue, at least for the OS and the apps. Where there is an issue is migrating "personalities" — the user settings and data — from the old computer or image to the new one.

To aid that "personality" migration, Microsoft provides the User State Migration Toolkit (USMT) 4.0. It supports two migration scenarios. One is moving the data off a PC before Windows 7 is installed, then moving the data back afterwards (called a PC refresh). The second — and depending on the age of your current desktops, possibly the more important scenario — is moving the files and settings to a new computer (called a PC replacement). USMT pulls information from the hard drive, the registry, and other Windows data and restores it to the refreshed or replaced system.

Part of working with the USMT involves the use of the Windows Automated Installation Kit (AIK) for Windows 7. This kit includes the USMT; the Windows System Image Manager (SIM), to create unattended XML answer files; the ImageX tool, to capture and apply images; the Deployment Image Service and Management (DISM) tool, to manage your images by adding and removing drivers, language packs, and patches; and the Windows Preinstallation Environment (WinPE 3.0), to create the OS image you want to deploy.

Note that Microsoft bills the Windows System Image Manager as being able to manage distribution shares, which it technically can manage, but the better tool for doing this is Microsoft Deployment Toolkit (MDT) 2010. Also, note that Imagex is not the right tool to manage or modify Windows 7 images. DISM (shown at right) is a better choice, but DISM cannot capture or apply an image; only ImageX can do that.

Also note that these migration tools — especially AIK — are difficult to use, so you may need to bring in a migration consultant.

You can deploy Windows 7 images over the network if you use Windows Server 2008 and combine MDT with the Windows Server 2008 service called Windows Deployment Service (WDS). MDT and WDS are usually thought of as competing deployment tools, but in fact they can be used together, as Rhonda Layfield, a consultant who is also a Microsoft MVP for Deployment and Desktop Deployment Product specialist, explained to me.

When you use MDT to deploy Windows 7, you have to create the OS image, called a WinPE. You boot from the WinPE, then run its installation program; WinPE can be booted from a CD, DVD, external hard drive, or WDS server. To boot from a WDS server, hold F12 when starting up the client PC; this creates a Trivial FTP connection to the WDS server's UNC share. Choose WinPE, and MDT installs the OS image on the client.

You can also use WDS with MDS if you want to multicast the OS image (MDT supports only unicasting, or one-to-one connections between the server and a client). By telling MDT to use the WDS multicast protocol, WDS sends the WinPE image to multiple clients, and MDT runs the WinPE image at each client.

Considering virtualised desktop deployment

Windows 7 offers a wild new deployment option: client-side virtualisation. You might consider this type of installation because of the flexibility and speed it offers in restoring, securing, and upgrading systems.

One type of client-side virtualisation is to install Windows 7 onto a virtualised hard disk (VHD), which is a single file that you can easily copy and deploy anywhere. You can also create incremental VHDs, so you might have a core file that everyone uses and incremental VHDs that have the applications and other configurations for specific departments and even users. The PC boots as normal but opens Windows 7 from the VHD instead of the hard drive's normal file system.

The use of VHDs will slow your PCs by about 3 percent, Microsoft says. It also prevents you from using the Windows Experience Index, as well as BitLocker on the disk where the VHD resides. (You can use BitLocker within the VHD, but not on the disk where the VHD resides). Note that you need Microsoft's Virtual PC or Virtual Server to create the VHDs, which can run only the 32-bit version of Windows. An MSDN blog details the setup process.

Another virtualisation option is the concept of VDI (virtual desktop infrastructure), where the OS is hosted on a server in the datacentre. Users get the same experience as working with Windows 7 directly on their desktop, but IT can manage the desktops locally in the datacentre and even provision them to different desktops, such as when a person is visiting another office or working at home. Gartner estimates that in 2014 about 15 percent of the professional market will run Windows this way.

Perhaps more futuristic is the notion of running Windows 7 directly on a hypervisor, which could let you run Windows 7 on computers not designed for the Windows OS — or any specific OS. If the computer can run a supported hypervisor, you can run Windows 7 on that hypervisor. Through management tools, you could quickly deploy an OS to multiple systems. There are already tools on the market (such as Virtual Computer's NxTop) that let you manage virtual systems, encrypt the drives (note that BitLocker will not work with VHD-based OSes), and wipe the OS if the system is lost or stolen and booted up.

This hypervisor approach could be very helpful in migrating your users if they are already running in a Windows XP environment with client virtualisation. In that case, they can be moved over to a new OS and their computer's "personality" comes right along with them. Just remember that this is leading-edge stuff, so it's something you're more likely to experiment with than deploy companywide in the near term.

Good-bye nightmare, hello sweet dreams

For many, the transition to Vista was a nightmare best avoided. But the transition to Windows 7 will be a much sweeter sleep.

It will take work to make that migration happen, but by assessing your tools you have, your equipment, and the needs of your organisation going forward, you can do it. And when you're finished, the only system running Windows XP is the one in the company museum with a sign that says, "We ran our company on this OS for 10 years before moving over to Windows 7."

Bruzzese is an IT training consultant, specialising in Microsoft technologies

Join the newsletter!

Error: Please check your email address.

Tags managementWindows 7

Show Comments