Exchange 2000 and SharePoint Portal Server

These server products don't belong on the same machine

Despite the fact that Microsoft Exchange 2000 Server and Microsoft SharePoint Portal Server 2001 (formerly code-named Tahoe) share a common technological heritage—the Extensible Storage Engine (ESE)—Microsoft doesn't want you to install both products on the same Windows 2000 server. Many Microsoft documents (e.g., the README file that comes with SharePoint Portal Server, the Microsoft article "Programs That Cannot Coexist with SharePoint Portal Server" at http://support.microsoft.com/support/kb/articles/q295/0/12.asp, the Planning and Installation Guide for SharePoint Portal Server at http://www.microsoft.com/sharepoint/techinfo/productdoc/planning/planinstall.asp) reiterate this advice but don't offer much technical information as to why coexistence is impossible. When you look past the statement that the products' coexistence is unsupported—as well as some of the more obvious reasons why Microsoft didn't specifically design these products to coexist—and examine the products' similarities and differences a bit more closely, the conflicts that might arise become clear.

Which Is Which?
Microsoft has often emphasized that despite their common roots, Exchange 2000 and SharePoint Portal Server are quite different and distinct products, each developed by a separate engineering group and each designed to do a completely different job. An email server is different from a document management and portal server; therefore, the products' code must vary as well. (One obvious example: Exchange 2000 absolutely depends on Win2K and a solid deployment of Active Directory—AD—whereas SharePoint Portal Server runs on Win2K but doesn't require AD.)

However, the two products share a common database engine: the ESE, which powers both the Exchange Information Store (known as IS in Windows NT or the Store in Win2K) and the SharePoint Portal Server store. (Win2K AD uses yet another ESE variant.) This common use can cause a good deal of confusion if you install both products on the same server.

Consider the simple matter of event-log entries. Figure 1, page 84, shows an extract from a SharePoint Portal Server machine's Application log. Judging by the sources of the events in this log, you might presume that both Exchange 2000 and SharePoint Portal Server are running on the system. Events originate from sources such as ESE98 (which you might assume is the Exchange 2000 Store) and MSExchangeIS Public (which you might think relates to Exchange public folder activity) as well as SharePoint Portal Server.

This presumption would be wrong, however. SharePoint Portal Server "borrows" certain event messages from Exchange—and doesn't even attempt to disguise the fact by changing the event name. For example, one of the events that Figure 1 shows is an instance of event ID 1221, with a source of MSExchangeIS Public Store. This event reports a database defragmentation that both Exchange and SharePoint Portal Server perform as a background maintenance operation. When you probe a little further and review this event's description, which Figure 2, page 84, shows, you find that the event's true source is SharePoint Portal Server.

As you can see, an obvious potential for confusion exists if Exchange and SharePoint Portal Server are active on the same server. Even though you can study an event's details to determine the source of a problem, you could easily mistake a SharePoint Portal Server­signaled database error for an Exchange-signaled error.

Engineered to Live Apart
Many of the products' conflicts probably occur because SharePoint Portal Server shipped after Exchange 2000. The SharePoint Portal Server engineers knew that Exchange 2000 existed and so could build an installation procedure that accommodates Exchange. However, the Exchange engineers were in the dark about SharePoint Portal Server and so didn't consider a situation in which the two products might be active together. (Or perhaps the Exchange engineers knew about SharePoint Portal Server but couldn't take the demands of a future product into account when they built the Exchange 2000 installation program.) Flawless interoperability is always difficult to achieve when products follow skewed release dates.

In short, Microsoft simply didn't design Exchange and SharePoint Portal Server to interoperate. Also, Microsoft assumes that corporations will deploy email and portals on separate dedicated servers—probably a fair assumption because many companies now consider both email servers and portals to be mission-critical applications. As such, administrators take care to tune servers specifically for those applications and manage server operations to ensure that a failure in one application or server can't affect another important application. (For the same reasons, you probably wouldn't run Exchange and Microsoft SQL Server on the same server.) Therefore, Microsoft products' separate engineering groups don't usually consider test scenarios that feature these products working together on enterprise servers. Of course, avoiding coexistence tests also reduces costs for Microsoft.

Simplified Support
Keeping the two products apart also makes support easier for Microsoft Product Support Services (PSS) and for customer Help desks. The fewer products that are active on a server, the easier the job for support personnel to debug and solve problems. Each new product that you add to a configuration increases the likelihood and complexity of problems that might occur. Exchange servers are usually complex environments that include virus checkers, backup software, messaging connectors, management and monitoring tools, and other utilities that interact with the Store, the Message Transfer Agent (MTA), the Routing Engine, Microsoft IIS, and other components. Adding SharePoint Portal Server to the mix might be too much of a good thing.

The Nitty-Gritty
If you ignore the obvious and underlying reasons to avoid putting Exchange 2000 and SharePoint Portal Server on the same system, you can expect to experience several known problems. Although these problems aren't particularly serious, they won't make your job any easier.

The SharePoint Portal Server installation halts the Exchange Information Store service during the installation process. The stoppage is brief but means that all Exchange user activity must cease.

SharePoint Portal Server won't work with Exchange 2000 Enterprise Server. That version of Exchange supports multiple storage groups (SGs) and databases, whereas SharePoint Portal Server doesn't support the Store and so is restricted to one SG. I haven't tried to fiddle around with installation procedures to get Exchange Server 5.5 and SharePoint Portal Server to work together, but my guess is that the two simply won't function. Unlike Exchange 2000 and SharePoint Portal Server, which both base their store on the ESE98 release of the database engine, Exchange 5.5 uses an earlier variant (i.e., ESE97), adding an additional layer of incompatibility.

Exchange and SharePoint Portal Server share several services such as the Microsoft Search (MSSearch) service. Problems don't surface when you install Exchange 2000 first, then install SharePoint Portal Server, then leave the system configuration alone. However, if you remove and reinstall Exchange, you modify system components that can stop SharePoint Portal Server; likewise, removing SharePoint Portal Server might stop Exchange. The exact details of these problems vary from system to system, but the sheer fact that you can't predict the results of installation and uninstallation procedures is a good enough reason to avoid mixing Exchange 2000 and SharePoint Portal Server on a production server.

When you install SharePoint Portal Server, a special instance of the Web Storage System (WSS) becomes active on the server. Exchange 2000 and SharePoint Portal Server share common database technology, so if you install Exchange 2000 after you install SharePoint Portal Server, the Exchange installation procedure detects that the WSS is already present on the system and halts. This step is logical from the perspective of the installation procedure, which doesn't want to overwrite what it determines to be an already operational Exchange server.

Exchange 2000 uses the M drive as the base drive letter for the Exchange Installable File System (ExIFS), a component that supports file-system-like access to store contents. SharePoint Portal Server also supports ExIFS but doesn't expose the M drive by default, largely because applications and users don't need file-system access to documents in the SharePoint Portal Server store. You can make a registry change to force SPS to permit file-system access, but you must change the drive letter to avoid a conflict with Exchange.

Exchange 2000 works on a Win2K cluster; SharePoint Portal Server doesn't. (Microsoft designed SharePoint Portal Server to support departments rather than enterprises, and department-level servers usually don't need the type of availability that clustering provides. However, future versions of the product will likely focus more on the needs of larger enterprises, so cluster support in an upcoming version wouldn't be surprising.) The SharePoint Portal Server installation upgrades the MSSearch service to add features that SharePoint Portal Server uses, and the resulting MSSearch component is unsupported on a cluster. Therefore, installing SharePoint Portal Server on an Exchange server that's part of a cluster produces unpredictable results if Exchange uses the MSSearch service for full-text indexing of mailbox or public folders. (You also shouldn't add a server running SharePoint Portal Server to a cluster.)

What's the Problem?
Given that SharePoint Portal Server is a relatively new product, few companies have probably even considered running it and Exchange on the same computer. Probably, the only people who are currently affected by or care about these problems are systems integrators and administrators who run test systems and want to install many products on the same server. If you're in this category and want to work with both Exchange and SharePoint Portal Server, you need to run multiple servers or work around some of the known problems to make the two products work together—something you can do with a little care and tolerance.

Still, I'm somewhat disconcerted that Microsoft doesn't seem able to distribute enterprise-server software that interoperates seamlessly. True, Microsoft spent an enormous effort to ensure that layered products can't interfere with Win2K (for example, the company put a lot of work into preventing the DLL Hell syndrome). However, products still butt heads and interfere with one another. This situation might be understandable if it involved Microsoft products and third-party products but is completely unsatisfactory when two Microsoft products cause such confusion. Given that messaging and document-management have been part of the "electronic office" since the early 1980s, I'm disappointed that Exchange 2000 and SharePoint Portal Server can't coexist—especially when they have such common technical roots. Microsoft promises great things in the new .NET era. Let's hope that better product interoperability will be one of the benefits delivered in this brave new world.