Geek of All Trades: Why, When and How to Use Windows 7 XP Mode
Greg Shields
Virtualization on the desktop! Operating systems within operating systems! Complete elimination of application compatibility pains! Windows 7 XP Mode promises all this. Using this specialized incarnation of Windows Virtual PC, your business can immediately upgrade to Windows 7 without fear of application incompatibility.
At least, that’s what the marketing says. But what’s the reality?
Why Use It?
Virtually every company or organization today has some line-of-business legacy (that is, problem) application that consumes more of the IT department’s effort than it probably should. That’s even true in the small environments run by us jack-of-all-trades IT professionals.
Legacy software complicates OS upgrades. If your organization needs to use an application that you know won’t run atop Windows 7, then the likelihood is high that you won’t be upgrading soon. One single, stupid, backward application stands between you and the improved security, management and UI that the newest Microsoft desktop OS delivers.
This is the reason for XP Mode. And, it’s important to state, this is the only reason for XP Mode. Period.
When to Use It?
With the why question reasonably answered, your next thought should relate to where XP Mode fits in your environment. When should you use a solution like this? Simply put, as a last resort.
Windows XP Mode leverages a locally installed copy of Windows Virtual PC to create a fully functional instance of a second OS on a user’s desktop or laptop. This instance runs as a Windows XP virtual machine and is used exclusively for hosting the few problem applications that won’t run on Windows 7. With this single solution, Microsoft squashes the argument that “we can’t upgrade because our apps won’t let us.” In a way, it’s an absolutely brilliant marketing strategy. Huzzah, Microsoft!
Using XP Mode is only one way to solve the problem, however. If you’ve been closely following the theme of my last few columns, you’ve noticed they focused on application delivery mechanisms. Using today’s Microsoft technologies, your options for getting software to users grow far beyond the traditional install-it-locally approach.
My two previous columns (TechNet Magazine, February 2010 and March 2010) discussed how you can easily use Remote Desktop Services (RDS) or hosted virtual desktops atop Hyper-V to create a remote-applications infrastructure. In such an environment, users connect to individual applications or entire desktops housed somewhere in your server room. Because the applications are remote, as long as users have access to your network (or even the Internet) their locations don’t matter. Connected users are never more than a few mouse clicks away from the tools they need.
The approaches introduced in those previous two columns are of fundamental importance to this month’s column. In many ways, their discussion of alternative delivery mechanisms creates a whole new mindset concerning the way you connect users to their applications.
Let’s assume, for example, you have three problem legacy applications in your small environment. Each is just a little different in its needs and characteristics. Consider how you’d make these programs available to users—assuming you want to upgrade to Windows 7 very soon—given these parameters:
- Application A works fine on Windows XP or Windows 7, but is an administrative nightmare with many configurations and routine updates. Application A runs fine on Windows Server 2008, though.
- Application B works on Windows XP, but not on Windows 7. This program is relatively lightweight and used by a moderate number of users.
- Application C also has incompatibilities with Windows 7, and unlike Application B, it requires substantial resources to run but is only needed by one or two individuals.
Each of these programs requires a different approach in delivering it to users. Application A should be easy. Because this application works atop Windows Server 2008, it immediately becomes a candidate for hosting via RDS. And because the software has numerous configurations and many updates, installing the pieces one time to an RDS server ensures everyone has access while reducing your administrative burden.
Dealing with applications B and C is a bit more difficult. They’re not compatible with Windows 7, which means neither will work atop Windows Server 2008. As noted in the parameters, a moderate number of people use Application B, which is relatively lightweight. This makes it a potential candidate for a set of pooled virtual desktops running atop Hyper-V and RDS.
Application C has substantial resource requirements, which will have an impact on the number of concurrent virtual desktops a single Hyper-V server can host. Because this app is needed by only one or two people, it might be a good candidate for XP Mode.
How to Use It?
Restricting the number of applications you support with XP Mode is certainly a best practice. This has to do with the lack of tools available for automating and centrally managing its services and virtual machines. XP Mode is intended to be a solution for limited uses in small and midsize environments only.
Deploying virtual machine (VM) disk files to clients requires manual or self-scripted solutions. There are no tools for centrally controlling the mode’s settings or policies. You must manually install applications and patch XP Mode VMs within each installation or using deployment tools such as Windows Server Update Services or System Center Essentials.
You must install and manage security tools, such as firewalls and anti-malware clients, on each XP Mode VM as well as the primary machines, doubling your administrative effort. You should also note that XP Mode doesn’t support applications requiring 3-D graphics. And, if your environment requires greater levels of automation or has applications that get fairly widespread use, you should consider Microsoft Enterprise Desktop Virtualization (MED-V), which is only available to businesses as part of the Microsoft Desktop Optimization Pack (MDOP).
XP Mode also has somewhat steep hardware requirements: The computer must support hardware-assisted virtualization (which you can confirm with the Microsoft HAV Detection Tool); processor and RAM resources must be sufficient to support both primary machine and its secondary virtual instance simultaneously; and, while a 64-bit OS isn’t required, it may be necessary to get around the RAM limitations inherent in Microsoft 32-bit OSes.
Licensing can also be a consideration, depending on how you plan to provision VMs within XP Mode. Every installation of XP Mode includes a prepackaged Windows XP VM as a VHD file. The primary computer’s Windows 7 license grants the user unrestricted access to use this prepackaged VM, but only this VM. While you can create your own custom VMs for use with XP Mode, doing so requires additional licensing.
Installing XP Mode requires installation of Windows Virtual PC. You’ll find both at the Microsoft Windows Virtual PC download page. The Web site provides separate links for the two, with instructions to install XP Mode first.
.png "Windows XP Mode Setup Fig. 1")
Figure 1 Windows XP Mode Setup
After installing both components, go to the Start Menu and launch Windows XP Mode. You’ll find it in the Windows Virtual PC folder. The first time you run XP Mode it will ask you to specify an installation folder as well as a User name and Password for its XPMUser account (see Figure 1). This is a local account in the guest OS, that’s a member of its local administrators group. The account is used to enable seamless application support when users launch XP-hosted applications within their primary OS.
.png "The Windows XP Guest OS, immediately after installation Fig. 2")
Figure 2 The Windows XP Guest OS, immediately after installation
After you finish using the setup wizard, the default guest OS will power on and log in. It will show you a screen similar to that in Figure 2. The machine comes up with a name of \\VirtualXP-xxxxx where xxxxx is a random series of numbers. The machine will also begin in a workgroup, but you can add the VM to your domain if you wish to use domain credentials.
.png "A guest application as seen on the host’s Start Menu Fig. 3")
Figure 3 A guest application as seen on the host’s Start Menu.
Now you’re ready for the final step: installing your problem application into its guest OS. You can do so manually or with an application deployment solution. When you’ve installed software to the XP Mode guest, it can launch automatically from the host in seamless mode, with the link to launch the application appearing on the host’s Start Menu (see Figure 3).
To use a seamless application, the guest VM must be logged out and closed prior to being launched from the host’s Start Menu. Alternatively, users can work with the guest VM’s full desktop by clicking the link marked Windows XP Mode. When not in use, the XP guest VM will hibernate, reducing the time necessary to begin working with it when it’s needed again.
As you can see, XP Mode does indeed supply virtualization at the desktop as well as OSes within OSes. It also provides a mechanism for completely eliminating the pain of application compatibility—it simply eradicates OS incompatibility by providing a compatible OS. While XP Mode is limited by the administrative tools used in managing it as well as the hardware requirements of its VM, this solution can do away with the hurdles to an OS upgrade. Just don’t forget that this solution is one of many that can fulfill your needs.
Greg Shields, * MVP, is a partner at Concentrated Technology. Get more of Shields’ Geek-of-all-Trades tips and tricks at** ConcentratedTech.com*.