• Chart: Microsoft Server Application Compatibility with Windows .NET Server

Fundamental architectural changes in Windows .NET Server 2003 will make it incompatible with some Microsoft and third-party applications. Service packs will help some Microsoft server applications work on the new operating system, but at least one application, Exchange, will require an upgrade to a new version. Most earlier Microsoft server products also will not be compatible, and some third-party products will require patches or upgrades. Organizations interested in upgrading to Windows .NET Server will have to factor these issues into their plans, and fixes could be expensive if the server application updates are not covered under maintenance programs, such as Microsoft’s Software Assurance.

(For a complete list of the server application configurations that Microsoft will support, see the chart "Microsoft Server Application Compatibility with Windows .NET Server".)

Why Windows .NET Server Affects Compatibility

Even though Windows .NET Server (scheduled for release in spring 2003) is a minor upgrade from Windows 2000 Server (as opposed to a major upgrade containing revolutionary architectural changes), Microsoft’s Trustworthy Computing initiative has strongly influenced its design. Unlike its predecessor, Windows .NET Server installs in a "secure by default" configuration. (See "SD3 Forms Basis for Security Push" on page 9 of the Oct. 2002 Update.) In certain cases, the security changes can create problems for applications that run fine on Windows 2000.

Although Microsoft has taken pains to ensure that most of the 200-plus architectural changes in Windows .NET Server won't break existing applications and has carried forward most of the Windows 2000 APIs into the new product, applications might become incompatible for the following reasons:

Default installation of critical components only. For security reasons, many Windows operating system components have been removed from the default installation or from the product entirely, which can cause problems for applications that assume these components are present. For example, Internet Information Server (IIS) no longer installs by default, and the Visual Basic 5.0 run-time library is no longer even included in Windows .NET Server, so any application requiring such components must check for their existence and install them if necessary.

Tightened security. Windows .NET Server’s default security settings are much tighter and more conservative, which can create problems for application installation routines that don’t account for these changes. For instance, IIS ISAPI extensions are disabled by default, so applications that need them must first enable them.

Internet Information Server (IIS) 6.0. IIS 6.0 is one of the most changed components in Windows .NET Server. Although the majority of IIS 5.0 Web applications will still run on IIS 6.0, in certain cases the changes could create compatibility problems. (For more specifics on IIS 6.0 compatibility issues, see "Rewritten IIS Anchors Windows .NET Server" on page 3 of the July 2002 Update.)

Applications that require a specific version of Windows. As has been the case with past upgrades, installation routines that check for a specific version of the operating system before they install could fail on Windows .NET Server. This problem is particularly common among applications that install kernel-mode components or drivers.

Improperly written installation routines. Application installation routines that fail to test return values, handle exceptions poorly, or make assumptions about the logical structure of the file system or operating system might encounter problems.

Microsoft has documented the major areas of change (see references in the Resources section below). It has also made tools available to help developers test the compatibility of applications. Once the Windows .NET Server code is finalized, organizations like Veritest will be able to certify that applications are fully compatible with Windows .NET Server. (See "Windows .NET Server Programs" on page 6 of the Sept. 2002 Update.) Until then, developers can test their products on the latest release candidate.

What to Do When Compatibility Issues Arise

Organizations planning to upgrade Windows 2000 servers to Windows .NET Server will need to carefully consider all of the applications and services running on those servers. In addition to their major commercial and in-house applications—including those from Microsoft—they must also consider important utilities such as backup agents, antivirus products, and monitoring and management agents.

Once problem applications have been identified through testing or from vendor advisories, solutions can take two basic forms. Some incompatibilities will simply involve manual workarounds—in these cases, the application vendor will likely document procedures that must be performed during the upgrade or before installing the application. In other cases, affected applications might require customers to install application patches or a new version of the application created specifically for Windows .NET Server.

Microsoft’s Server Applications

For its own applications, Microsoft has decided to require current or future application service packs before it will support running them on Windows .NET Server. In some cases, these service packs are designed not to address specific incompatibilities but rather to strengthen the supportability or security of the product by taking advantage of Windows .NET Server’s increased security or other new features.

In the case of Exchange, Microsoft requires that the product be upgraded to a new release, Exchange 2003 (code-named Titanium), which will not be available until summer 2003. Most other server products will only be supported on Windows .NET Server in their latest editions. Unless customers have purchased Software Assurance on these products (enabling them to upgrade at no additional cost to the latest version), they could find that upgrading to Windows .NET Server will be very costly.

Resources

For more information on Windows .NET Server and Window XP application compatibility and to download the Windows Application Compatibility Toolkit, see www.microsoft.com/windowsxp/appexperience.

Software vendors interested in having applications certified for compatibility with Windows .NET Server should see members.microsoft.com/partner/isv/netcertify.aspx.