When working with computers and software (and a good many other things), it is rarely wise to do something simply because you can. This basic truth should be a guiding beacon to any of you who may be toying with the notion of a single server running both Exchange 2000 and Sharepoint Portal Server.
Make no mistakes about it: with Service Pack 2 of Exchange 2000, it is now possible to run Exchange 2000 and Microsoft Sharepoint Portal Server on the same box. As you'll see, I use much of this article to argue against such a configuration in the name of network efficiency. You'll also learn that I am not completely one-sided in my opinions when I touch -- though ever so cautiously -- on the few special scenarios for which it may be a good idea after all.
Covering the Basics
Both Microsoft SharePoint Portal Server (SPS) and Exchange Server 2000 are applications based on the Exchange Server Information Store (formerly named the Web Storage System). Both systems support WebDAV (Web Distributed Authoring and Versioning) and both use similar methods to process HTTP client requests.
Exchange 2000 comes in two editions: Standard and Enterprise. With the Enterprise Edition, you can create additional (non-MAPI) Public Folder stores and write your own Exchange 2000 HTTP applications. Application developed on these Exchange Stores can be replicated to other servers, backed up and restored using off-the-shelf utilities, and can take advantage of anti-virus software. Moreover, Exchange 2000 applications can be designed to leverage existing Active Directory security groups and user accounts to establish roles and access control lists for objects and application processes. However, development on this platform is not easy. Except for the most basic of applications, Exchange 2000 HTTP development is best left to serious developers and development companies.
SPS is an application that extends the Exchange Information Store with additional database functions and application procedures, including controls for document storage and versioning. With this new SharePoint Store, Microsoft has leveraged some of its existing Digital Dashboard technology so that users can easily create workspaces and collaborative applications on the SPS server without custom code. By enabling managers and team leaders to create workspaces, SPS enables document sharing, indexing and team folders with little to no interaction from the IT staff. This ease with which users can create their own solutions is one of the strong selling points of SPS.
Server Roles and Responsibilities
Exchange 2000 and SPS are both based on similar core technology and use Microsoft's Internet Information Services (IIS) to provide HTTP access to applications and data. Even though the backend technologies are nearly identical, the load on the servers differs for many reasons:
- E-mail and application uses are different. While predicting the use of e-mail is made easier by logs and performance monitoring, predicting the use of an application is more difficult without such baseline comparisons.
- Application load varies among the procedures used by the developers. There are many ways to code a function and some methods are more efficient than others are. Anything entering or leaving the Exchange Information Store via HTTP also runs through a WebDAV process to ensure proper object definition. A programmatic batch process that moves files in and out of the information store requires high CPU and memory usage. When an Exchange 2000 or SPS server can no longer access the CPU, or if physical RAM is exhausted, end-users can be subjected to delays of several minutes. (Some companies will not extend SPS with custom code. If you belong to this group, you may want to refer to the SPS Capacity Planning guide at http://www.microsoft.com/sharepoint/techinfo/planning/CapPlan.doc.)
Because of these differences, Microsoft strongly cautions against running SPS and Exchange Server 2000 on the same machine. I was able to find one support article at the Microsoft Web site (search for article reference no. Q290734) indicating that this setup is not supported. Since e-mail is considered mission-critical for many companies, it may not make sense to jeopardize a healthy e-mail server by installing additional software and services, thereby reducing the available memory and CPU cycles for other applications. For most cases, it is better to use a different machine in order to isolate and protect the e-mail environment.
SharePoint Limitations
The inherent design of SPS often temps people to combine servers. For starters, you cannot replicate workspaces or data to other SPS servers. All workspaces and code executed on an SPS server stays on that server. For example, if you have several locations that connect over the WAN, you are likely to have more than one SPS installation. Each SPS has its own workspace with its related documents. While workspaces and data files cannot be replicated, a large SPS network typically consists of several SPS site servers and a master search portal server that can "connect" the various collections of documents. This allows searches to span several locations even though the workspaces and documents contained therein cannot.
Departmental versus Campus Environment
So what does all this mean? If you are in a campus environment or centrally located office, you probably have a large SPS server (or two) and a separate set of Exchange 2000 servers. If however, you have remote offices with less than 100 people then you have to pick one of the following options:
- Install an Exchange 2000 server and an SPS server
- Increase bandwidth so remote users can use documents stored on a centrally located SPS server
- Install SPS on your departmental Exchange 2000 server
Each plan of action is comes with its own set of costs depending on your unique situation. While I cannot easily detail what these costs could be, I can show you what the last option requires.
Install SharePoint Portal Server on an Exchange 2000 Server
Remember the first line of the article? In a lab and limited pilot environment, I have personally encountered no problems with this configuration. Your results may vary.
After you have decided on the appropriate machine, install Windows 2000 (including the NNTP and SMTP Service) and the latest service packs followed by Exchange 2000 Standard Edition and its latest Service Packs. The next step is to install SPS. This installation begins with an error that displays three warnings:
- "Warning: Setup has detected Microsoft Exchange 2000 Server Service Pack 1 on this machine. Once SharePoint Portal Server has been installed, uninstalling Exchange 2000 Server will cause SharePoint Portal Server to stop functioning"
- "You must be a domain administrator in order to install SharePoint Portal Server on a computer running Exchange 2000 Server."
- "Warning: Setup has detected the Microsoft Search Service (MSSearch) on this computer. This service will be upgraded if you continue with setup. As part of the upgrade process, MSSearch upgrades the format of existing full-text catalogs created by Microsoft SQL Server 2000 and Microsoft Exchange 2000 Server. In order to complete this process, MSSearch requires free disk space on each drive that contains a full-text catalog. For instance, if drive (G) has 1-gigabyte (GB) catalog, it must have 1.2 GB of free disk space for the upgrade to succeed. Please verify this disk space is available before proceeding. Also note that the catalog process starts immediately following installation, and may take several hours depending on the size of your full-text catalogs. Until this upgrade is complete, you cannot search your catalogs and full-text search administration is disabled. Please cancel setup if you do not wish to upgrade MSSearch at this time."
Despite these wordy warnings the installation of SPS on an Exchange 2000 machine is rather straightforward. With Standard Edition, you do not have the ability to create a non-MAPI Public Folder store, which is the heart of Exchange 2000 and SPS HTTP development. When the installation routine determines you are indeed running Exchange 2000 Standard Edition, it installs an additional Storage Group called SharePoint Portal Server Group and a store called SharePoint Portal Server Store. The setup routine also installs the SharePoint Portal Server Service and several libraries needed for Dashboard and Portal processing, not to mention the SPS ASP files. It also replaces the Exchange 2000 search engine with the much improved SPS engine. Towards the end of installation, another warning reminds you of the disk space required when indexing many or large items.
From the Exchange System Manager, this database appears as a normal store. You can browse through the folders and even view their sizes and associated rights.
As you can see from the graphic, the SPS installation has extended the ability of the information store to use another store. While this store cannot be replicated to another SharePoint Portal Server, you can replicate the content to an Exchange 2000 Enterprise Server. However, the benefit of such a replication is not obvious since a restoration would require IIS Metabase modifications as well as other specialized configuration changes.
In order to properly back up the SPS workspaces, however, you must follow a completely different process using the Msdmback script. For details on this process, the Microsoft Web site includes a support article on SPS backup procedures (search for article reference no. http://support.microsoft.com/default.aspx?scid=kb;en-us;281413>Q281413). I also recommend their article (reference no. Q300672) for information on the backup and restoration of the IIS Metabase, since the workspaces are provided using IIS virtual directories. The creation of a new workspace in SPS creates new virtual directories in IIS.
The WebDAV schema is contained within the folder structure of the Workspaces and the Portal Server store, so no additional backup or restore procedures are required for the schema.
Be careful about trying to use the Exchange System Manager tools with SPS stores and settings as SPS sets specific configurations on the items. Another application layer exists above this one to permit or restrict access to the workspaces and files.
With Exchange 2000 SP2, we can now run SharePoint Portal Server on the same machine as our Exchange 2000 Mailbox and Public Folder servers. This practice, however, should be limited to just a few circumstances, such as a testing environment or perhaps a remote departmental location to accommodate financial or bandwidth restrictions.
If you have a SharePoint question, feel free to e-mail them to Steve.
Steve Bryant is a Microsoft Exchange Most Valuable Professional and has spent the last several years designing and securing Exchange and Active Directory environments. He is the editor and a regular contributor to http://www.outlookexchange.com, an on-line resource for Exchange administrators and system designers, as well as an author for Exchange & Outlook Magazine and .NET Magazine.
