Non-Microsoft Applications and Migration


Topic Last Modified: 2007-12-20

Published: March 02, 2005

By Ed Beck

When you migrate from earlier versions of Microsoft Exchange Server or Microsoft Windows, some non-Microsoft applications may not work or may not work correctly. This issue frequently comes up for one of the following reasons:

  • Applications were built on Collaboration Data Objects for Microsoft Windows NT Server (CDONTS).

  • Security constraints prevented the applications from accessing required resources.

This article discusses these two scenarios.

This article does not contain code samples to help you migrate non-Microsoft applications. However, in the “For More Information” section later on this page, I provide links to Microsoft Knowledge Base articles that contain that information. Also, I'm not going to go into specifics about how to modify security settings, but I do provide links to more information about security settings.

I recently reviewed six month's worth of support cases that involved customers who develop applications for Exchange Server. Ten percent of the cases involved customers who were having problems with non-Microsoft applications that did not work after the customer upgraded from an earlier version of Windows or Exchange Server. In 30 percent of these cases, the applications didn't work or didn't work correctly because the applications used CDONTS or because security updates prevented the applications from accessing required resources.

CDONTS was included in Windows NT. CDONTS uses SMTP as its e-mail interface and is generally used with an Active Server Pages (ASP) script. The script runs on a server running Microsoft Internet Information Services (IIS) to send simple mail messages. Although CDONTS is not very robust, it is lightweight and simple to use. These characteristics contributed greatly to its success.

When Windows 2000 Server was released, it included Collaboration Data Objects for Windows 2000 (CDOSYS) and CDONTS. CDOSYS provided developers with a more robust API but did not require that developers create applications that were required to run on a computer running Exchange Server. Windows 2000 Server included CDONTS for backward compatibility.

Microsoft Windows Server 2003 introduced managed code and, with it, a managed wrapper for CDOSYS. That managed wrapper is called System.Web.Mail.

Windows Server 2003 does not include CDONTS, so clean installations of Windows Server 2003 do not contain CDONTS. However, when you upgrade from Windows 2000 Server to Windows Server 2003, CDONTS is not removed. Therefore, a CDONTS application may run on a server running Windows Server 2003 if the server was upgraded from Windows 2000 Server, but it may not run a server running a clean installation of Windows Server 2003.

As more people upgrade from Windows NT 4.0 to Windows Server 2003, this problem occurs more frequently. Customers experience this problem when Web hosting companies install new servers running clean installations of Windows Server 2003 and then move their clients' Web pages to the new servers. Frequently, some of the migrated pages use CDONTS. The best way to maintain a supported configuration is to upgrade servers running Windows 2000 Server to Windows Server 2003.

We strongly urge developers to convert existing CDONTS applications to CDOSYS or, preferably, System.Web.Mail. In the “For More Information” section later in this article, I've added links to some helpful Knowledge Base articles.

Non-Microsoft applications may also not work or not work correctly after certain types of upgrades because new security constraints prevent the applications from accessing required resources. These upgrades include newer versions of Windows, Exchange Server, or Microsoft Office, or installation of a service pack.

In these cases, the developer of the non-Microsoft application has not done anything on purpose to cause a security update to shut down the application. Rather, in the course of Microsoft's continual review of source code, we have identified potential security issues and resolved them in upgrades and service packs. These upgrades and service packs sometimes close paths that non-Microsoft applications depend on. I want to stress that software developers do not sit in their offices trying to find and use weaknesses in our software. Their applications don't work or don't work correctly because the applications couldn't access required resources after a software upgrade closed a specific path.

Let's look at an example. Before the release of Exchange 2000 Server Service Pack 3 (SP3), the Everyone group had read access to the IIS metabase. A common method for sending SMTP mail was to ask the application to look up the name of the default SMTP server in the IIS metabase. This method worked fine because the Everyone group had read access to the IIS metabase. However, Exchange 2000 Server SP3 removed read access to the IIS metabase for the Everyone group, causing applications that made use of the former permissions to no longer work.

Microsoft addresses this particular issue in a Knowledge Base article. Two workarounds focus on making sure that the application runs under an account that had the appropriate rights to access the IIS metabase. In today's environment, designing the appropriate rights to an application's architecture is very important. Applications must have sufficient rights to access the resources they need, but no more.

It is inappropriate to run every application under the Administrators account or to allow anonymous access to all your resources. You should determine what resources your application requires, and configure your application to run under an account that has those rights.

The biggest generators of support calls about security configuration today are issues that are associated with permissions on the pickup directory when you use the sendusingpickup method. For more information about how to correctly configure permissions for the sendusingpickup method, see the following Microsoft Knowledge Base article: