When I speak about Exchange at seminars and other events, the topic of best
operational practices often comes up. People want to know the steps they must
take to operate an efficient and effective Exchange installation once the
software moves from pilot status into production. Email is now a
mission-critical application for many large companies, and these organizations
want to minimize the company's risk in the investment they make to implement
client/server-based messaging. In "Planning a Large-Scale Exchange
Implementation," May 1997, I discussed how to plan for a successful
implementation; now I'll consider day-to-day operations in an Exchange
environment and explain the five guiding principles that will make your
operations successful.
Microsoft designed Exchange to be scalable, robust, and reliable in
distributed environments. Exchange manages reasonably large user populations on
individual servers (one server at Digital has supported more than 2750
mailboxes) and will manage far larger populations as Windows NT and hardware
evolve. Exchange is more akin to mainframe or mini-computer messaging systems,
such as IBM PROFS or Digital ALL-IN-1, than Microsoft Mail or Lotus cc:Mail.
Guiding Principles
Managing very large user communities is impossible if you don't follow
disciplined systems management practices. I have several principles that guide
efficient system management for a production-category Exchange server.
- Plan for success. Assume that users
will increase the demand on the servers, the volume of mail traffic will
increase, and you'll deploy new messaging applications (such as workflow). Make
sure that system configurations incorporate room for growth and accommodate
periods of increased demand.
- Use dedicated hardware for Exchange.Configure the hardware to provide a resilient
and reliable service on a
continuous basis for three years with a minimum number of interventions (and
system downtime) required. After three years, replace the hardware.
- Keep downtime to a minimum. Never
take an action that interferes with or removes the Exchange service from users.
For any intervention that requires taking servers offline, plan in advance and
clearly communicate your intentions to users. Also, be prepared for catastrophic
hardware failure. Outline a recovery plan to handle emergencies.
- Track system statistics. Proactive
system monitoring is a prerequisite for delivering a production-quality service.
While you're monitoring the system, gather regular statistics on system use and
analyze the data to help identify potential problems and protect the quality of
service.
- Follow well-defined, regular
housekeeping procedures.
Exchange needs disciplined management to achieve maximum potential. Anyone
can take the Exchange CD-ROM, slap it into a drive, install the software, and
have a server up and running with clients connected in 30 minutes. Such a system
can handle a small user community. This approach is OK if that level of service
is all you need. The strategy I outline here is geared to large, corporate
deployments, but the logic that drives the strategy is valuable no matter what
size shop you run. The five principles are generic, but they have proved to work
over a large number of Exchange deployments in the past two years.
1. Plan for
Success
Any configuration will come under increasing pressure as it ages. You
experience the best performance immediately after you install the system,
when disks are not fragmented, users put little demand on the computer, and
application files are as small as they'll ever be.
As people get to know an application, the user-generated load increases.
Users send more messages, and the messages are larger. Users find more reasons
to use the underlying service: For example, you might install a fax connector
for better communication with external agencies or deploy a full-text retrieval
package to improve manageability of public folder contents. The disks fill up
with user and application data. With Exchange, the information store swells to
occupy as much space as you can devote to it. If you don't configure the system
with success in mind and incorporate room for growth, you'll end up with a
system that runs smoothly at the beginning only to suffer increasingly as time
goes by.
I recommend overconfiguring the service at the start so that you don't
become entangled in a cycle of constant upgrades. Install two CPUs rather than
one, use 128MB of RAM rather than 96MB, have 20GB of disk instead of 16GB, and
so on. Build server configurations that can handle at least some expected
software developments over the next few years. For example, consider RAID
controllers for system clustering. Look at the hardware that existing clustering
solutions use and see whether you can include hardware with the same or superior
capabilities. (For more information on clustering solutions, see Mark Smith, "Clusters
for Everyone," and Joel Sloss, "Clustering Solutions for Windows NT,"
June 1997.) Because the upcoming release of 64-bit NT 5.0 will require a new
version of Exchange before it can be used for messaging, it is probably at the
outer range of consideration. But think about Alpha CPUs if you're interested in
building high-end servers that you want to eventually run 64-bit NT on. Alpha
CPUs are also appropriate as servers that must handle high levels of format
translation work, such as those that host Internet connectors. Configure systems
that will be successful over time rather than just today. Any other approach
might require more hardware upgrades than you want in a production environment.
2. Use Dedicated Hardware for Exchange
You can install Exchange on just about any NT server that has the correct
revision level of the operating system (for Exchange 5.0, the correct level is
NT 4.0 with Service Pack 3--SP3) and a minimum of 32MB of RAM. The same server
can run other BackOffice applications and some personal productivity
applications such as Office 97. For good measure, the server can provide file
and print sharing to a set of workstations, not to mention Domain Name System
(DNS), Windows Internet Name Service (WINS), and Dynamic Host Configuration
Protocol (DHCP), and act as a domain controller. The applications will install
and run, but run slowly. And, with all those applications, think of the steps
you'll have to take to get the server back online in case of hardware failure. I
do not recommend this mix on a production system. Having dedicated hardware lets
you tailor and tune the configuration to meet the needs of an application.
Previous
Register
I’ve learned that Exchange server will use a feature called IS Maintenance to defragment the Information Store and Directory databases over time. The server manages the online defragmentation process and performs it according to a schedule page on each Server object.<br>
As a database has objects added and deleted, the internal structure of the file will become fragmented, much like files affect a hard disk. To provide optimum performance, you must defragment the JET database to reclaim the unused space. Defragmenting the database will also improve performance because the service requesting the information will wait less time during data retrieval. Defragmenting the database will not reduce the size of the database; rather, it will order the objects in it. As you add objects to the file, the database will reuse the space reclaimed by defragmenting. This approach lets you reuse the space before you need to increase the file size again.<br>
As Tony mentions in his article, you must stop the Information Store service and use the EDBUTIL utility. What Tony does not mention is that you must have at least as much free disk space as the .edb file that you are defragging needs. Here is how the process works:<br>
1. While the EDBUTIL utility is running, the file tempdfrg.edb (or whatever you choose to name it) is created (use the /t<drive letter>\<filename> option to create this file on another drive if you don’t have enough disk space).<br>
2. Entries from the original database are written into tempdfrg.edb. Blank space is not written to tempdfrg.edb.<br>
3. After all the entries from the database are written into tempdfrg.edb, the database file is deleted and tempdfrg.edb is renamed to the database name (dir.edb, priv.edb, or pub.edb, depending on which file you are running this process against).<br>
I just wanted to give a heads-up to administrators who are planning to defrag their database. I am not aware of too many shops that have 12GB of available space.<br>
--Gene Ferioli <br><br>
<i>Thanks for your comments, Gene. I should have mentioned your point about requiring at least the same amount of free disk space before running EDBUTIL. Many shops that operate a few large servers use a plug-in array for such defragmenting exercises. You can wheel around the array from server to server as required, which reduces the need to have a lot of space permanently connected.
As for defragmentation, I guess we’ll have to disagree (but only a little) on semantics. You explain the online defragmentation process that occurs every night, but this process just shuffles pages around the database to collect all the “white space” (from deleted messages) into contiguous space. This process does not return free space to the disk, which is what I’ve always thought of as a side effect of defragmentation. After using Exchange for a couple of months, most systems administrators will worry about the disappearing space and will resort to EDBUTIL; they won’t notice the good work the regular online defragmentation processing is doing on their behalf.<br>
--Tony Redmond</i>
Gene Ferioli August 13, 1999