Although most new applications run fairly well on Windows Server 2008 R2, some apps are written for older operating systems that may have trouble installing to, or running on, R2. Fortunately, there are ways to tackle these compatibility challenges.
Keep your server up to date
The first step to addressing application compatibility is to make sure that
Use the Application Compatibility Toolkit
Another way to manage app compatibility is by deploying the Microsoft Application Compatibility Toolkit.
It's primarily designed to test applications for compatibility with desktop operating systems such as Windows 7 and Windows Vista. Windows 7 and Windows Server 2008 R2 are built on the same kernel, however, so if a fix exists that will allow the application to run within a Windows 7 environment, it may also allow it to work with Windows Server 2008 R2.
Note that the toolkit does not actually fix application compatibility problems. It takes an inventory of the apps running and reports compatibility issues for each one. For example, Figure 1 shows some of what's running on desktops on my own network.
As you can see, Microsoft provides vendor assessments of compatibility information whenever possible. There is also a community assessment section where other IT professionals can chime in on how well an app works with a given operating system. In many cases, the tool provides detailed information about how to fix any incompatibilities that are reported.
Contact the application publisher
As great as the Microsoft Application Compatibility Toolkit is, it's not completely comprehensive because it doesn't contain compatibility fixes for some apps. This is especially true for some of the more obscure programs or those specifically intended to run on a server platform.
In these situations, contact the application's publisher to find out whether a patch is available that will allow the app to run on Windows Server 2008 R2. Even if no patch exists, the publisher may provide some hints on how to make the application work in an R2 environment.
Check Internet message boards
Sometimes a software publisher won't officially support an application on a certain OS because it has not thoroughly tested the application for compatibility. In other cases, a vendor may refuse to provide support simply because it is getting ready to release a new version and wants to force customers to purchase that edition. In either case, it is important to remember that regardless of the publisher's reasons for refusing to support an application, there are risks associated with running it in an unsupported state.
Adjust the application
Sometimes an app can be forced to work in an otherwise incompatible OS by "shimming" it. Just right-click on the app, and choose the Properties command from the shortcut menu. Windows will display a properties sheet for the app that includes a Compatibility tab (see Figure 2) with several settings that can be used to trick the app into running.
Virtualization can also help run stubborn applications. For instance, Windows Server 2008 R2 includes Microsoft Hyper-V, which can be used to run an application within a legacy OS on top of Windows Server 2008 R2. There are also many third-party products that virtualize applications without having to deploy a full-blown virtual machine running a legacy operating system. Applications should be virtualized as a last resort, however. As you can see, there are quite a few options for running an otherwise incompatible application within Windows Server 2008 R2. Start by understanding the ins and outs of each option, and you'll be well on your way to troubleshooting any problems that might arise.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Brien Posey is a seven-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, he worked as a CIO for a national chain of hospitals and health care facilities. Posey has also served as a network administrator for some of the nation's largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in May 2011