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 is differs for many
reasons:
-
Email and application
uses are different. While predicting the use of email 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. 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 email is considered mission-critical for many
companies, it may not make sense to jeopardize a healthy email
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 email 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.
|
