Exchange 2000 and SharePoint Portal Server

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.

   Previous  [1]  2  Next