Microsoft Exchange Server 2003

Operations Guide
 

Microsoft Corporation

Published: December 12, 2006

Author: Exchange Server Documentation Team

Abstract
The Exchange Server 2003 Operations Guide provide guidelines for disaster recovery tasks,
and for daily, weekly, and monthly maintenance tasks.

Comments? Send feedback to exchdocs@microsoft.com.

Contents
Exchange Server 2003 Operations Guide................................................................................5
For More Information............................................................................................................. 5

Understanding Microsoft Exchange Server 2003 Operations...................................................6

Microsoft Operations Framework.......................................................................................... 7
Best Practices for Exchange Organizations........................................................................15

Exchange Server 2003 Daily Operations................................................................................33

Performing Physical Environmental Checks.......................................................................34
Monitoring Event Viewer..................................................................................................... 34
Performing Backups............................................................................................................ 42
Checking Disk Usage.......................................................................................................... 44
Checking Connector and Server Status..............................................................................46
Monitoring Server Performance..........................................................................................50
Checking Message Paths................................................................................................... 52
Performing Daily Database Maintenance............................................................................56
Monitoring Network Performance........................................................................................ 57
Monitoring Exchange and Windows Services.....................................................................58
Monitoring Cluster Resources.............................................................................................61
Enforcing Security Measures..............................................................................................64

Exchange Server 2003 Scheduled Maintenance Tasks..........................................................69

Generating Reports and Identifying Trends.........................................................................69
Reviewing Protocol Logs..................................................................................................... 72
Monitoring Outlook Web Access Servers............................................................................73
Managing Mailboxes........................................................................................................... 74
Managing the BadMail folder.............................................................................................. 79
Managing the Postmaster Mailbox......................................................................................80
Conducting a Status Meeting and Status Reports..............................................................81

Exchange Server 2003 On-Demand Tasks............................................................................82

Online and Offline Defragmentation of Exchange 2000 Server and Exchange Server 2003
Databases....................................................................................................................... 82
Verify Mailbox and Public Folder Store Integrity..................................................................86
Checking the Queue Viewer...............................................................................................88
Guidelines for Configuring a Performance Console............................................................89

Exchange Server 2003 Operations Checklists.......................................................................90

Exchange Server 2003 – Disaster Recovery Preparation Checklist.......................................91

 Checklist: Disaster Recovery Preparation...........................................................................91

Exchange Server 2003 – Summary Checklist........................................................................94

Checklist: Summary............................................................................................................ 95

Exchange Server 2003 – Monthly Operations Checklist........................................................96

Checklist: Capacity Planning...............................................................................................96
Checklist: Hotfixes, Service Packs, Update Rollups, and Security Updates.......................97

Exchange Server 2003 – Weekly Operations Checklist.........................................................97

Checklist: Create Reports................................................................................................... 97
Checklist: Incident Reports.................................................................................................98
Checklist: Antivirus Defense................................................................................................99
Checklist: Status Meeting.................................................................................................... 99

Exchange Server 2003 – Daily Operations Checklist...........................................................100

Checklist: Performing Physical Environmental Checks.....................................................100
Checklist: Check Backups.................................................................................................100
Checklist: Check CPU and Memory Use...........................................................................101
Checklist: Check Disk Use................................................................................................ 102
Checklist: Event Logs........................................................................................................ 103
Checklist: Check IIS Logs and Performance.....................................................................104
Checklist: Exchange Database Health..............................................................................104
Checklist: MAPI Client Performance.................................................................................105
Checklist: Check Queue Viewer........................................................................................105
Checklist: Message Paths and Mail Flow..........................................................................106
Checklist: Exchange Connectors to Non-Exchange Mail Platforms..................................107
Checklist: Security Logs.................................................................................................... 108

Copyright.............................................................................................................................. 109
 5

Exchange Server 2003 Operations Guide

The Exchange Server 2003 Operations Guide consists of four topics that describe the daily,
weekly, and monthly maintenance tasks that, for a Microsoft® Exchange Server 2003
organization, are required to keep an Information Technology (IT) organization running
smoothly and without interruption.

The topic areas are as follows:

 Overview of the processes for effective day-to-day management of an IT infrastructure.

This topic provides the understanding, tools, and best practices required to maintain an
Exchange Server 2003 environment.

 Information about the daily maintenance tasks that are required to ensure the availability
and reliability of your Exchange Server 2003 organization. Some of the many daily
maintenance areas are as follows: performing backups, checking disk usage, monitoring
server and network performance, and enforcing security measures.

 Information about the scheduled maintenance tasks used for collecting data for trend
analysis and capacity planning. Maintenance tasks include generating reports and
identifying trends, reviewing protocol logs, monitoring Microsoft Office Outlook® Web
Access, managing mailboxes, the BadMail folder, and the postmaster mailbox, and
conducting weekly status meetings

 Information about on-demand tasks, such as defragmenting mailbox and public folder
stores, verifying mails and public folder store integrity, checking queues using Queue
Viewer, and configuring System Monitor to monitor Exchange server performance.

Note:
Download Microsoft Exchange Server 2003 Operations Guide to print or read offline.

For More Information

For more information about the factors that affect performance and for recommendations
about how to optimize your Exchange Server 2003 environment, see the Exchange Server
2003 Performance and Scalability Guide.

For more information about backup strategies and disaster recovery operations for you
Exchange Server 2003 organization, see the Exchange Server 2003 Disaster Recovery
Operations Guide.
 6

Understanding Microsoft Exchange Server

2003 Operations
Information Technology (IT) operations refers to the day-to-day management of an IT
infrastructure. An IT operation incorporates all the work required to keep a system running
smoothly. This process typically includes the introduction and control of small changes to the
system, such as mailbox moves and hardware upgrades, but it does not affect the overall
system design. Within a Microsoft® Exchange Server 2003 organization, the procedures,
roles, and responsibilities that are involved in operations need to be formalized.

Implementing Exchange Server 2003 operations procedures according to Microsoft

Operations Framework (MOF) requires:

 An understanding of MOF   MOF is a collection of best practices, principles, and

models that give you technical guidance on the management of IT projects such as daily
Exchange Server 2003 operations. Following MOF guidelines will help you achieve
mission-critical production system reliability, availability, supportability, and manageability
for Microsoft products.

 Familiarity with best practices for Exchange organizations   It is recommended that

you implement proven and practical procedures to manage an Exchange Server 2003
organization. Using the tried, tested, and documented methods of managing operations
in your organization may be more efficient than developing your own methods.

 Separating operations into daily, weekly, and monthly processes   Document the

operations tasks performed regularly in your company. Documenting how and when tasks
are performed ensures that the information is preserved when your operations staff
changes jobs or leaves the company. New employees also benefit from this
documentation because it helps them quickly learn how your IT department conducts its
Exchange operations.

 Deploying the tools required for operating an Exchange Server 2003

organization   Several tools are available to help troubleshoot problems and automate
tasks. You can define a standard set of tools so the tasks performed by the operations
team are done efficiently, consistently, and in a controlled manner. You should also
implement processes to track incidents and major configuration changes.

This topic gives you the understanding, tools, and best practices required to maintain an
Exchange Server 2003 environment. It explains how the management of Exchange
Server 2003 fits in with the overall MOF model. It will help you design your operational
management environment and give you the means to implement procedures to keep your
environment running smoothly.
 7

Microsoft Operations Framework

Microsoft Operations Framework (MOF) is a template on which you can design the
procedures, controls, and roles required for the efficient operation of your IT infrastructure.

The MOF Process Model

MOF provides guidelines about how to plan, deploy, and maintain IT operational processes in
support of mission-critical service solutions. MOF is a generic model so you must adapt many
of the recommendations for use in your company. When you see references to “roles” in the
MOF model, understand that a single person may be assigned many roles, especially in small
companies. But even if you represent the whole IT department, the procedures and
recommendations in this model are generally applicable.

MOF is a structured and flexible model that is based on:

 Microsoft consulting and support teams and their experiences working with enterprise
customers and partners, as well as internal IT operations groups at Microsoft.

 The IT Infrastructure Library (ITIL), which describes the processes and best practices
required for the delivery of mission-critical service solutions.

 ISO/IEC 15504 from the International Organization for Standardization (ISO), which
provides a normalized approach to assessing software process maturity.

MOF provides recommendations for deployments of various Microsoft products, such as

Microsoft Windows® Server™ 2003 and Microsoft Exchange Server 2003. For detailed
information about Microsoft Operations Framework see http://go.microsoft.com/fwlink/?
LinkId=21640.

For information about ITIL and ISO, see http://www.ogc.gov.uk/index.asp?id=2261 and

http://www.iso.org and respectively.

MOF complements and integrates with the Microsoft Solutions Framework (MSF). MSF is a
disciplined approach to managing technology projects based on Microsoft internal practices,
the experiences of Microsoft Product Support Services in working with customers and
partners, and industry best practices in software development and project management. MSF
is a deployment approach for the design and implementation of IT systems (for example, a
migration project to move from Lotus Notes to Exchange Server 2003), whereas MOF
addresses the daily management of a system or environment, such as an Exchange
Server 2003 organization.

Components of the MOF Process Model

The MOF process model is composed of quadrants, operations management reviews, and
service management reviews. Figure 1.1 shows how the MOF cycle works.
 8

Figure 1.1   The Microsoft Operations Framework Cycle

From the figure, you can see how the MOF process model moves clockwise and is split into
four integrated quadrants, as follows:

 Changing

 Operating

 Supporting

 Optimizing

These quadrants form a spiral life cycle that applies to IT operations from a specific
application to a complete operations environment with multiple data centers. The process
model is supported by Service Management Functions (SMFs) and an integrated team model
and risk model. Each quadrant is supported by a corresponding operations management
review (also known as review milestone), during which the effectiveness of that quadrant's
SMFs are assessed. You should understand that although the model describes the MOF
quadrants sequentially, activities from all quadrants can be occurring at the same time.

Briefly, the quadrants cover the following activities:

 Changing   A change is planned and tested during the changing phase. After a Release
Readiness Review, the change is rolled out to the production environment and enters the
operating phase. The Release Readiness Review should not be the first time the release
 9

is evaluated; it should be a final review milestone before the actual deployment. Using
SMFs provides a process and task road and guarantees a successful deployment and
rollout for managed releases.

 Operating   The goal of an Operations Review is to provide the processes, procedures,

and tools that make supporting the system as simple and efficient as possible. Think of
the SMFs in this quadrant as the typical data center activities, such as system
administration, monitoring, and batch processing. These activities guarantee the smooth
and predictable operation of the release.

 Supporting   The supporting phase is the process of maintaining the system, using these
tools and procedures. This quadrant contains the main SMFs required to provide ongoing
support to the users of the IT service solutions. As with any process, system, application,
or service, problems can start when operations start. The support and operations staff
must identify, assign, and resolve problems quickly to meet the requirements set forth in
the service level agreements (SLAs). The SLA Review is a measurement of how
effectively the system is performing. Issues that come out of the SLA Review may
highlight areas where improvements are required.

 Optimizing   The mission of service for this quadrant is to reduce costs while maintaining
or improving service levels. An improvement to the system might require a change to
hardware, software, or procedures. The Release Approved Review evaluates the
proposals for change, accounting for items like costs, risks, and benefits. Approved
changes are fed into the changing quadrant and the process starts over. This iterative
process typically occurs naturally as the various teams gradually introduce changes to
the system to achieve improvements.

The MOF framework formally describes the steps involved in this improvement cycle,
assigning responsibilities for each step and enabling the whole process to be managed. At
the end of each phase, there is a review point. With a large IT department, this is likely to be
a review meeting between the people or teams involved, such as release management,
operations, and security. In a smaller company, review points are possibly only a checkpoint
that indicated you are ready to proceed. Figure 1.2 shows the relationship between MOF and
MSF.
 10

Figure 1.2 Relationship between MOF and MSF

The MSF process can help develop a solution in response to a business need such as the
requirement to consolidate server resources. In this case, the solution may outline how to
deploy powerful mailbox servers that are running Exchange Server 2003. After the solution is
deployed, the design and deployment team hands the environment to the teams described in
the MOF model. These teams manage the daily operations, and provide feedback about
requirements or suggestions for change to the design team. Again, this is an iterative process
that you can use to refine and continuously improve your solution.

Service Management Functions

Service management functions (SMFs) are the roles of people or teams in the organization,
such as support professional or system administration. The SMFs represent the foundation of
the MOF process model. Although SMFs are cross-functional and cross-quadrant, the
primary role of an SMF applies to a specific stage in the quadrant. For example, system
administration is part of the operating quadrant, and release management is part of the
changing quadrant. SMFs and the MOF quadrant of the cycle that each SMF applies to are
discussed in detail in this section. The IT department of your company may comply with these
roles and quadrants. Figure 1.3 shows these service management functions within the MOF
cycle.
 11

Figure 1.3 Service management functions in MOF

 Changing   The processes in this quadrant address the introduction of new solutions,

technologies, systems, applications, hardware, and processes in the environment. This
includes:

 Change management   Involves managing developing, testing, and rolling out

changes to the production environment. A key goal of the change management
process is to identify and provide detailed information to everyone who will be
affected by the impending change.

 Configuration management   Involves identifying, documenting, and tracking

components of the environment and the relationships between them. Configuration
management is also responsible for maintaining the definitive software library (DSL)
which houses the master copies of all the software deployed in the IT environment.

 Release management   Involves releasing new software, hardware, and process

releases into the production and managed preproduction environment. Release
management considers all aspects of a release, whether technical or non-technical.
Make sure that releases are well defined, maintained, and scheduled for each IT
service.
 12

 Operating   The processes in this quadrant revolve around effective and efficient

execution of day-to-day tasks.

 System Administration   Involves maintaining the messaging systems and

coordinating the IT teams.

 Security Administration   Involves maintaining a safe and secure computing

environment.

 Directory Services Administration   Involves managing user accounts, organizational

units, and other Active Directory® directory service objects. Directory Services
Administration focuses on daily operations, maintenance, and support of the
organization.
 Network Administration   Involves maintaining the physical network infrastructure,
such as servers, routers, and firewalls, to ensure that messaging systems can
communicate with each other.

 Service Monitoring and Control   Involves monitoring system performance to ensure

that daily operations are compliant with SLAs.

 Storage Management   Involves maintaining the data repositories in your messaging

organization to ensure the availability of data. This includes backup and capacity
planning.

 Job Scheduling   Involves scheduling maintenance jobs during off-peak hours (for

example, backups and batch processes), considering the available capacity.

 Supporting   The processes in this quadrant revolve around the resolution of incidents,

problems, and inquiries.

 Service Desk   Provides guidance about setting up and running the organizational

unit or department that is the single point of contact between the users and the
provider of IT services. Service Desk organizes the activities and customer
communications about incidents, problems, and inquiries related to production
systems.

 Incident Management   Involves managing the process of resolving any fault or

disruption to the production system, including escalation to and communication with
other SMFs.

 Problem Management   Focuses on structuring the escalation process of

investigation, diagnosis, resolution, and closure of problems.

 Optimizing   Focuses on changes to optimize performance or capacity, increase

availability, or decrease costs in the delivery of IT services.

 Service Level Management   Involves monitoring the performance of the IT

department and periodically reviewing its compliance with SLAs.
 13

 Financial Management   Involves justifying required changes and other expenditures

in terms of cost versus benefit. For example, the cost of hiring additional user
helpdesk staff versus the benefits of a reduced waiting time for support calls.

 Capacity Management   Involves monitoring the capacity of your messaging systems

to ensure compliance with performance measures defined in SLAs.

 Availability Management   Involves managing, monitoring, and reporting the

availability, reliability, and maintainability of your messaging systems.

 Workforce Management   Involves providing best practices and assessing staff

requirements, developing skills and positive team attitudes, and transferring
knowledge.
 Security Management   Defines and communicates the organization's security plans,
policies, guidelines, and relevant regulations defined by the associated external
industry or government agencies.

 Infrastructure Management   Ensures coordination of infrastructure development

efforts, translating strategic technology initiatives to functional IT environmental
elements, managing the technical plans for IT engineering, hardware, and enterprise
architecture projects, and ensuring that quality tools and technologies are delivered.

MOF Team Model Roles

The MOF Process Model and MOF Team Model are the core models that define Microsoft
Operations Framework. The MOF Team Model provides guidelines for organizing teams, and
the functions and competencies of each role cluster. The role clusters in the Team Model
work with the SMFs of the Process Model. The Team Model role clusters enable the SMF
processes to be followed. The MOF Team Model also suggests combinations of functions that
should be kept separate. For example, the team that tests a change before it is released to
the production environment should be separate from the team that developed the change.
Figure 1.4 shows how these role clusters combine within MOF.
 14

Figure 1.4 Role clusters within MOF

The MOF Team Model defines seven role clusters. These roles frequently reflect how teams
are organized in a medium to large environment. The role clusters are discussed in this
section:

 Release   The release team manages the roll-out of changes into the production
environment, is responsible for configuration management, maintains licensing
information, and forms a liaison between development and operations groups.

 Service   The service team is responsible for end-to-end management for a specific

service such as provisioning a messaging solution service across the organization. The
service team is involved in the design, deployment, and operations phases of the
solution.

 Infrastructure   The infrastructure team plans and manages the IT infrastructure,

including capacity forecasting, managing standard builds and system images, and
monitoring system availability and connectivity.

 Support   The support team represents the liaison between users and helpdesk support.
This team manages compliance with SLAs, provides incident and problem resolution, and
maintains a knowledge base of common resolutions. This team is also responsible for
providing customer feedback to design teams.

 Operations   The operations team manages user accounts and mailboxes, monitors

performance and availability of systems, manages connectivity with external systems,
monitors queues and logs, and maintains firewalls.
 15

 Partner   The partner team liaises between suppliers and partners such as Internet
Service Providers (ISPs). This team manages contractual SLAs with third parties,
evaluates alternative suppliers, manages procurement, and makes purchasing decisions.

 Security   The security team detects virus attacks, intrusion attempts, denial of service,
and other attacks. This team must monitor the usage of IT resources and compliance with
standards and audit tracking and reporting. This team frequently manages Public Key
Infrastructure (PKI) technologies required for message signing and encryption, as well as
external testing including mail relay testing and penetration testing.

This detailed MOF model forms the basis for organizing resources and responsibilities to
operate, support, optimize, and make changes to an IT infrastructure.

Best Practices for Exchange Organizations

Best practices are recommendations based on knowledge and experience gained by IT
professionals across many environments. They provide standard procedures for typical tasks
that your messaging administrators must accomplish daily and list what tools they should use
to manage the Exchange 2003 Server organization.

Typical tasks for Exchange administration include the following:

 Capacity and Availability Management   Define how and what to measure to predict

future capacity requirements. Also, to report on the capacity, reliability, and availability of
your systems. You must ensure that servers that are running Exchange are sized to
handle load on the system, and that unplanned downtime is kept under the levels defined
in the SLA. Additionally, you will need to upgrade hardware to continue to meet the
defined requirements.

 Change Management and Configuration Management   Control how changes are

made to your IT systems. This should cover testing, application, feedback and
contingency plans, documentation of all changes, and buyoff from management if
problems occur. Keep a record of your software and hardware assets and their
configurations.

 System Administration   Outline standard methods for doing administrative tasks, such

as database administration and messaging administration.

 Security Administration   Have a detailed policy and plan to protect the data

confidentiality, data integrity, and data availability of your IT infrastructure. This includes
day-to-day activities and tasks related to maintaining and adjusting the IT security
infrastructure.

 System Troubleshooting   Outline methods for dealing with unexpected issues,

including steps to prevent similar issues in the future.

 Service Level Agreements   Maintain a set of goals for the performance of your IT

systems and regularly measure performance against these goals.
 16

 Documentation   Document standard procedures, such as configuration information and

lessons learned, and make them available to the staffs that need them. As changes to the
configuration are made, update the documentation accordingly.

Capacity and Availability Management

The purpose of capacity management and availability management is to measure and control
system performance. It is recommended that you implement capacity management and
availability management procedures so that you can measure and control system
performance. You must know whether the system is available and whether it can handle the
current and the projected demands by setting baselines and monitoring the system to look for
trends.

Capacity Management
Capacity management involves planning, sizing, and controlling service capacity to ensure
that the minimum performance levels specified in your SLA are exceeded. Good capacity
management ensures that you can provide IT services at a reasonable cost and still meet the
levels of performance defined in your SLAs with the client. These criteria can include the
following:

 System Response Time   This is the measured time that the system takes to do typical
actions. Examples include, the time taken for a client to log on and authenticate to the
domain, the time allowed to do a full backup of an Exchange store, and the time taken to
retrieve an item from a mailbox or public folder.

 Storage Capacity   This is the capacity of a storage system, whether it is a network

share, a backup tape drive, or an Exchange store. Examples include the minimum
amount of storage space to be provided per user and the amount of time that backup
tapes must be kept before being overwritten.
Adjusting capacity is frequently a case of ensuring that enough physical resources are
available, such as disk space and network bandwidth. Table 1 lists typical resolutions for
capacity-related issues.

Table 1   Typical resolutions for capacity-related issues

Issue Possible resolution

Slow logon to mailboxes Introduce another domain controller to the

site or increase network bandwidth

Slow retrieval of documents from a public Ensure that a replica of the public folder is
folder available locally

Access through Microsoft Office Outlook® Increase the available bandwidth of the
Web Access is too slow Internet connection
 17

Issue Possible resolution

Shortage of free space on a network share Add more disks to the server or storage
array

Capacity is affected by system configuration and depends on physical resources such as

network bandwidth. For example, if a server that is running Exchange Server 2003 is
configured to log troubleshooting information to disk, log files may use up disk space over
time. This can reduce the disk capacity available to the Exchange store. Capacity
management is the process of keeping the capacity of a system within acceptable levels and
addresses the following issues:

 Reacting to changes in requirements   Capacity requirements need to be adjusted to

account for changes in the system or the organization. For example, if you increase the
maximum allowed size of messages to the Internet, you may notice a corresponding
increase in traffic across the Internet connection. Then, you may need to increase the
capacity of the connection to avoid unacceptable delays in message transfer.

 Predicting future requirements   Some capacity requirements change predictably over

time and can be planned for in advance. For example, the total volume of mail in an
Exchange store typically increases at a fairly constant rate. By looking at how the
Exchange store size has changed over the last six months, you may be able to predict
approximately when it will reach the limit. The maximum size of Exchange stores on a
Standard Edition Exchange 2003 server is 16 gigabytes (GB). Therefore you will need to
either plan to upgrade to Enterprise Edition, introduce mailbox size quotas, or add
Exchange servers and move some mailboxes to those new servers.

Availability Management
Availability management is the process of ensuring that any IT service consistently and cost-
effectively delivers the level of availability required by the customer. Availability management
is not concerned only with minimizing loss of service, but also with ensuring that appropriate
action is taken if service is lost. In an Exchange Server 2003 environment, you may be
concerned about whether the Exchange store service is available, whether an SMTP
connector is functioning, and so on. An SLA defines what frequency and length of outages
are acceptable, allowing for certain periods when the system is unavailable for planned
maintenance and unexpected failures.

If you need to provide reports to your management about systems availability, or if you have
financial or other penalties associated with missing availability targets, you must record
availability data. Even if you do not have such formal requirements, it is a good idea to at
least know how frequently a system has failed in a certain time period, for example, system
availability in the last 12 months and how long it took to recover from each failure. This
information will help you measure and improve your team’s effectiveness in responding to a
system failure. It can also provide you with useful information if there is a dispute.
 18

Measures related to availability are as follows:

 Availability   This is typically expressed as the time that a system or service is

accessible, compared to the time that it is down. It is typically expressed as a percentage.
(You may see references to “three nines” or “five nines”. These refer to 99.9% or
99.999% availability.)

 Reliability   This is a measure of the time between failures of a system and is sometimes

expressed as Mean (or average) Time Between Failures (MTBF).

 Time to Repair   This is the time taken to recover a service after a failure has occurred
and is sometimes expressed at Mean (or average) Time To Repair (MTTR).

Availability, reliability, and time to repair are related as follows:

Availability = (MTBF – MTTR) / MTBF

For example, if a server fails twice over a six-month period and is unavailable for an average
of 20 minutes, the MTBF is three months or 90 days and the MTTR is 20 minutes. Therefore,
Availability = (90 days – 20 minutes) / 90 days = 99.985%

Availability management is the process of ensuring that availability is maximized and kept
within the parameters defined in SLAs. Availability management includes the following
processes:

 Monitoring   Examining when and for how long services are unavailable.

 Reporting   Availability figures should be regularly provided to management, users, and

operations teams. These reports should highlight trends and identify areas that are doing
well and areas that require attention. The report should summarize compliance with
targets set in the SLAs.

 Improvement   If availability falls under targets defined in the SLAs, or where the trend is
toward reduced availability, the availability management process should define what
steps are planned. This should include working with other responsible teams to highlight
reasons for outages and to plan remedial actions to prevent a recurrence of the outages.

Capacity and availability measurements are repetitive tasks that are ideally suited to
automated tools and scripts such as Microsoft Operations Manager, which is discussed later
in this topic.

Change Management
Sometimes you must introduce changes to your IT environment, such as new technologies,
systems, applications, hardware, tools, and processes, and also changes in roles and
responsibilities. An effective change management system lets you introduce changes to your
IT environment quickly and with minimal service disruption. A change management system
brings together the teams involved in modifying a system. An example is the introduction of
 19

Microsoft Office Outlook® Web Access. Outlook Web Access is an integrated component of
Exchange Server 2003 that uses a Web browser and an Internet or intranet connection to
enable you to read your corporate e-mail messages, schedules, and other information that is
stored on an Exchange server. Deployment of Outlook Web Access in your organization
requires involvement from several teams such as:

 Test Team   This team must load-test Outlook Web Access on a test server and provide
the instructions to implement Outlook Web Access on the production servers. The test
team must evaluate Outlook Web Access by using specified types and versions of
popular Web browsers, such as Internet Explorer 6.0.

 Exchange Administrators   This team administers the system after the change is

deployed in the production environment. They must understand the effect of the changes
and incorporate them in their procedures before the changes are put into production.

 Network Team   This team is responsible for changes in firewall rules to allow access
from the Internet to the Outlook Web Access servers.

 Security Team   This team assesses security and minimizes risks. The security team
must review known vulnerabilities and ensure that security risks are minimized.

 User Acceptance Team   This team is composed of users who are willing to test the
system and offer feedback for improvements.

The change management process defines the responsibilities of each team and schedules
the work to be performed, incorporating checks and tests where they are required. Change
controls will vary depending on the complexity and expected effect of a change. They can
vary from automatic approval of minor changes, to change review meetings, to full project-
level reviews. To illustrate this better, the groups of changes are discussed in this section.

 Major Changes   Major changes have a global effect on the system and may require
input from various teams. An example of this is upgrading from Exchange Server 5.5 to
Exchange Server 2003. Major changes affect many different teams and perhaps different
systems. The change management process may follow a similar procedure to the
example discussed earlier about deploying Outlook Web Access in your organization, but
will probably include one or more change review meetings to inform the teams that will be
involved in the change or be affected by the change.

 Significant Changes   Significant changes require significant resources to plan, build,

and implement. Appropriate change controls should be introduced to ensure that the
effect of the change is understood, deployment procedures are tested, and the rollback
and contingency plans are ready. An example of a significant change is deploying a new
service pack.

 Minor Changes   Minor changes do not significantly affect the IT environment, for

example, modifying certain Exchange system policy settings.

 Standard Changes   Standard changes are performed regularly and are well understood
and documented. Examples include creating a new mailbox or changing the scope of
 20

backups. Regular changes should be documented in standard operating procedures

(SOPs), but they do not require change controls. For example, a procedure for creating a
new mailbox may state that all new mailboxes will have a storage limit of 100 megabytes
(MB), will have IMAP and Outlook Web Access enabled, and all other client protocols
disabled. The change management process should review any changes to the
procedure, but should not, for example, be involved in creating every mailbox.

The following example of change management examines how different teams interact and
the actions that are performed when a new service pack is deployed. These actions are
organized and managed by the change management process.

 Raise a change request   The security team has assessed the latest service pack and
confirmed that it resolves a possible vulnerability in the production system. The team
raises a Change Request to have the new service pack applied to all Exchange servers.

 Service pack release notes review   The Exchange administrator team reviews the
service pack release notes to identify the effect on the system.

 A series of lab tests is done   The Exchange administrator team must perform test
updates on a server in a non-production environment to decide whether the service pack
can be applied successfully without affecting any of the installed applications and server
systems. If there are third-party or internally-created applications that interface with
Exchange in a production environment, these should be also tested. These tests can also
be used to estimate the time required to perform the upgrades.

 Users are informed of the outage   The Exchange administrator team or user help desk
informs all affected users about the planned maintenance cycle and how long the server
will be unavailable.

 A full backup of the Exchange store is performed before the upgrade   The Exchange
administrator team must ensure that there is a valid backup in place to be able to revert
to the original system state if the service pack installation fails. It is recommended that
the backup be restored to a standby server to have this system readily available if there
are problems.

 The service pack is deployed   The Exchange administrator team does the installation
during the planned maintenance cycle.

Managing the Timing of Changes

It is recommended that you implement a procedure for scheduling changes to avoid
disruptions in overlapping sections of your work. For example, two teams may both be
planning a minor change to a system. One team may be applying a service pack while
another team is installing a custom form for an expenses claim application that runs under
Exchange Server 2003. Neither team is affected by the changes that the other team is
planning and they may not necessarily know about what changes the other team is planning.
If both changes occurred at the same time, there could be problems implementing the
changes. Also, if there are issues after the changes have been applied, for example if the
 21

expense claim application fails, it may be difficult to decide which change should be rolled
back. There should be regular maintenance periods set up between IT and management to
test the changes and accept them.

Configuration Management
Configuration management is the process of recording and tracking hardware and software
assets and system configuration information. It is generally used to track software licenses,
maintain a standard hardware and software build for client computers and servers, and define
naming standards for new computers. Configuration management generally covers the
following categories:

 Hardware   This category tracks what pieces of equipment the IT organization owns,

where they are located, and who uses them. This information enables an organization to
plan and budget for upgrades, maintain standard hardware builds, report on the value of
IT assets for accounting purposes, and help prevent theft.

 Software   This category tracks what software is installed on each computer, the version
number, and where the licenses are held. This information helps plan upgrades, ensure
that software is licensed, and detect the existence of unauthorized (and unlicensed)
software.

 Standard Builds   This category tracks the current standard build for the client
computers and servers and whether the client computers and servers meet this standard.
The existence and enforcement of standard builds helps support staff because they are
required to maintain only a limited number of versions of each piece of software.

 Service Packs and Hotfixes   This category tracks which service packs are tested and
approved for use and which computers are up-to-date. This information is important to
minimize the risk of computers being compromised and to detect users who have
installed unapproved updates.

 System Configuration Information   This category tracks the function of a system, the

interaction between system elements, and what processes depend on the system
running smoothly. For example, a connector to a third-party e-mail system may be
configured on a single server. The e-mail system’s dependence on this server should be
understood and contingency plans may be required if there is a failure. If a second
connector is installed on another server, dependencies and contingency plans will
probably change.

Implementing Configuration Management

After you determine the purpose of your configuration management exercise and decide what
items need managing, you need to implement configuration management by collecting data
and reporting data. The simplest approach for small organizations is to collect data manually
(number and model of client computers, operating system, software installed) and store it in a
Microsoft Office Word or Microsoft Office Excel document. For larger, more complex, and
 22

constantly changing systems, the discovery of assets and collection of detailed information
must be automated. Decide what information is relevant to your organization and record it in
a database.

The configuration management database is a useful tool for support staff and management in
the following areas:

 Security Audits   The database enables you to identify Exchange servers and client
computer systems that need to have hotfixes applied or that have missed the installation
of a service pack or the latest antivirus updates.

 Software Installation   If you identify client computers that already have Microsoft Office
Outlook 2003 installed, this will save time if you are manually deploying Outlook 2003.
 Configuration Information   If you maintain an up-to-date list of all Exchange 2003
connectors to mail systems, fax servers, and so on, you will be able to troubleshoot
connectivity problems quicker and more effectively.

 Planning Upgrades   If a capacity review reveals that additional storage space is

required on your Exchange 2003 servers. If each server has an internal RAID controller
but each has a different model and a different number of disks installed, the configuration
management database will indicate what type of disk can be installed, how many and
what the upgrade path will be in each case.

Tools Used for Configuration Management

There are many tools to discover, audit, and report assets. Some of these tools are discussed
in this section.

 Automated Scripts   You can write simple scripts to report items like the operating
system, service pack level, and existence of software on a specific set of computers. You
can specify these scripts to an organization’s exact requirements; however, the number of
scripts required and their complexity can make scripts expensive to create and maintain.

 Automated Tools   Depending on the size of your business and your organizational

needs, you may want to consider using automated tools. Tools such as Microsoft
Systems Management Server (SMS) incorporate standard report templates (such as
service pack level) and also enable you to create customized reports, for example, for a
custom application. Microsoft Operations Manager (MOM) can also be used to report on
hardware and software configurations. For more information about SMS and MOM, see
the Systems Management Server and Microsoft Operations Manager sub-topics in “Tools
and Technologies for Operating an Exchange 2003 Server Organization” later in this
topic.

There are also tools that can be used to record configuration data and make it accessible to
the appropriate IT personnel:
 23

 Public Folders   These can be useful for storing configuration data, because they can be
accessed throughout the organization and can be easily controlled so that only
appropriate staff can view or change items.

 Microsoft Windows SharePoint® Services   Windows SharePoint Services is the

Windows Server 2003 component that helps organizations increase individual and team
productivity by enabling them to create Web sites for information sharing and document
collaboration. Users can collaborate on documents, tasks, and events and share contacts
and other information. Additionally, Windows SharePoint Services enables managers of
teams and sites to manage site content and user activity. The SharePoint environment is
designed for flexible deployment, administration, and application development.

 Custom Databases   For larger organizations, it may be useful to store configuration

information in a Microsoft Office Access or Microsoft SQL Server™ database, so more
advanced queries can be run on the information. For example, list all Windows XP client
computers that do not have Service Pack 2 installed.

 Automated Tools   Tools such as SMS not only automatically gather the data, but store it
in a central database where it can be used to do standard and custom queries, and
reports on the data.

Relationship with Change Management

Configuration management is closely related to change management. Configuration
management identifies the need for change and identifies and records that a change has
occurred. For example, the configuration management database can be used to identify
servers that require a hotfix. Change management then defines the process for applying the
hotfix.

Conversely, if a new software package is rolled out, the change management process should
feed this information to the configuration management system. The configuration
management tools will probably need to be configured to identify the new software so that
they can discover and track where and when the software is deployed.

System Administration
System administration includes the day-to-day administrative tasks, both planned and on-
demand, that are required to keep an IT system operating smoothly. Typically, system
administration tasks are covered by written procedures. These procedures ensure that the
same standard tools and methods are used by all support staff.

In an Exchange Server 2003 environment, typical system administration tasks include

creating mailboxes, backing up and archiving mailboxes and public folder data, monitoring
logs, maintaining and recovering mailboxes, and updating antivirus scanners.
 24

Standard Procedures
There are several resources that help you define what standard procedures are required in
your organization and how to do them. For more information about how to administer your
Exchange organization, see the Exchange Server 2003 Administration Guide
(http://go.microsoft.com/fwlink/?LinkId=21769). Because each organization is unique, you will
have to customize and adapt these resources to suit your requirements.

Standard procedures will change and documentation will occasionally need to be revised. As
changes are made, the change management process should identify how each change is
likely to affect how administrative tasks are performed. Use the change management function
to update and control the documentation.

Frequently, change management takes over where system administration finishes. If a task is
covered by a standard procedure, it is part of the system administration function. If there is no
standard procedure for a task, it should be handled using the change management function.

Centralized Versus Decentralized Administration

Roles and responsibilities for doing system administration tasks depend on whether the
organization follows a centralized or decentralized model, or a combination.

The Centralized Model   In a centralized model, one or several controlled administrative

groups maintain complete control of the Exchange system. This administrative model is
similar to a data center where all administration tasks are performed by a single information
technology group. Roles and responsibilities within the team should be defined according to
experience and expertise.

The Decentralized Model   Decentralized organizations are located in several geographic

locations and have Exchange servers and teams of administrators in different locations. For
example, there may be local administration staff and one or more Exchange servers for each
office in each country. Alternatively, there may be a cluster of Exchange servers and an
administrative team for North America and one for Europe. Sometimes, you will want to
ensure that administrators are responsible only for their own geographical area and that they
do not have permission to administer other areas. In Exchange Server 2003, you can do this
by using the Delegate Control Wizard to assign administrators to specific administrative
groups.

System Troubleshooting
An organization must be prepared to deal with unexpected problems and should have a
procedure to manage problems from the point at which they are reported until their resolution.
Information about how support staff diagnosed a problem should be recorded and used in the
future, to avoid unnecessarily repeating work that has already been completed.
 25

System Troubleshooting Process

Figure 1.5 shows the system troubleshooting process and the interactions with other
operations roles.

Figure 1.5   System Troubleshooting Flowchart

 Classify and Prioritize   This task is typically performed by the service desk. For
example, a problem may be grouped as a messaging issue or a hardware issue. The
problem is then routed to the appropriate support team for investigation. The rules for
determining the priority of a problem, together with the time to respond and time to
resolve, are typically defined in the SLA.

 Investigate and Diagnose   The appropriate support team diagnoses the problem and
proposes changes to resolve the problem. If the solution is simple and does not require
change control, the solution can be applied immediately. If the solution is not simple, a
request for change should be raised and the proposed work should be managed by the
change management process, frequently under a “fast-track” procedure. Any changes
that are made should be recorded using the configuration management process.

 Close and Record   After testing the resolution, the problem should be closed. If there
are lessons to be learned from the problem, an entry should be created in the knowledge
base.

 Review and Trend Analysis   Periodic reviews of recent problems should be performed

to identify problem trends. For example, if your users are experiencing frequent problems
with slow logons to their mailboxes, network bandwidth issues may be the cause.
Problem resolution times and the effect of any outages on system availability should be
reviewed and compared with the SLA. The person who liaises with the customer on
 26

service issues, such as an account manager, should be informed of any significant

problems.

Problem Management Tools

Service desk tools enable staff to record, classify, and prioritize new problems. They will then
provide the workflow processes to manage the problem “ticket” through investigation and
diagnosis, often by more than one support team. They will frequently provide reports on
resolution times and historical trends. They may also include a knowledge base database,
which can be used to search through past problems. The Microsoft Knowledge Base is a
useful record of support issues that have been encountered by Microsoft. For more
information, see the Microsoft Help and Support Web site at http://go.microsoft.com/fwlink/?
linkid=14898.
There is third-party software but it typically requires customization to suit the organization’s
needs, such as the organization of teams, reporting requirements, and measures required by
the SLA.

Service Level Agreements

The service level agreement (SLA) is a document that defines what services your customer
expects from you. The complexity and content of this document depends largely on whether
customers are internal (within your company) or external.

External Customers
If your customer is external, the SLA may be part of a legal contract with financial incentives
and penalties for performance that falls inside or outside defined levels of service. Defining
these levels of service should be part of the overall contract negotiation.

As with all contracts, it is important that both parties understand what is expected of them and
what to expect. The SLA defines these expectations. The contents of the document should
change infrequently and only because of negotiations with the customer.

Internal Customers
If your customer is internal, you may still want to define the services expected of operations
teams and of IT systems. The SLA may be created by the operations staff and intended as a
set of goals for the availability of IT services within your organization. Alternatively,
performance levels may be set by management and used as benchmarks when assessing
staff performance.

Typical Criteria
Service level agreements include components that define criteria of minimum levels of
availability, support, and capacity.
 27

 Availability   Define the hours and the operating systems on which e-mail and other
Exchange services will be available (this may include handheld PDAs and mobile
phones). Any routine maintenance that affects service availability should be defined.
Define external factors that affect service, for example the loss of Internet connectivity.

 Support   Define the hours when support for a system will be available. Specify methods
for customers to contact support staff, how incidents are grouped, and target time to
respond and to resolve the incident. Define frequency and content of feedback to the
customer.

 Capacity   Define the maximum allowed size of a user’s mailbox, together with steps to
take if the limit is exceeded. Define the maximum allowed time to do standard tasks, such
as the time to retrieve a document from a public folder. Define the maximum number of
users and agree to a process to follow to increase capacity if more users are added.

Documentation
The Microsoft Operations Framework (MOF) model is composed of many service
management functions. Documentation about how and when tasks are performed can be
shared with members of the same team or with other teams. The method of storing and
sharing documentation can vary according to the type of function. For example, the
procedures for system administration may be stored as Word documents because they are
likely to be printed and referenced frequently. Configuration management information may be
automatically generated and stored in a database for easy searching and indexing. Some
documentation may be sensitive and should be restricted. An example of sensitive
documentation is a document describing security measures to prevent e-mail spoofing, spam,
virus, and attacks from malicious users. These documents should be made available only to
the appropriate people. A mechanism for version control has to be in place so when
documentation changes old copies in circulation can be replaced.

Document Management Systems

A documentation management system acts as a central repository for documents, ensuring
that only the latest revision of a document is available. You can also consider archiving the
older version of the document for reference purposes. Microsoft SharePoint® Portal Server is
one of many appropriate applications for managing documents. To prevent the accidental use
of an out-of-date procedure, discourage the IT staff from using local copies of documents.
Documents can be restricted and viewed or edited only by people with permission to do this.
Draft documents can be held pending approval, for example when waiting for an associated
change request to be approved.

Databases
Several tools and management functions have been discussed that are suited to using
databases. The configuration management process is likely to use automated processes that
 28

store large amounts of data that require indexing and searching. Support staff may search a
database of past problems and resolutions when troubleshooting new problems.

It is likely that there will be different databases being used for different purposes. Decide if
these databases should be linked or consolidated. For example, if the service desk identifies
several problems with a common theme (such as new software causing a problem with a
particular network card), they can query the configuration database to predict how many
computers might be affected.

Daily, Weekly, and Monthly Processes

There are many IT services that should be monitored automatically and in real-time. Also,
there could be critical situations in which operations staff must be alerted immediately, for
example, a message queue backlog. If it were to be discovered only during a manual check
at the end of a working day, the delay in mail getting through could have serious implications
for a business.

There are many more complex monitoring tasks that are not commonly automated and these
should be covered by regular manual checks. For more information about the need for
regularly documented checks and maintenance task, see "System Administration" earlier in
this topic. The following are lists of some of the standard tasks relevant to Exchange
Server 2003. Use these lists as a basis for generating standard procedures for your
organization. These lists will be discussed in more detail later in this topic.

Daily Operations Tasks

It is recommended that the following tasks and procedures be performed daily:

 Examine the Windows Event Logs for Exchange warnings and errors   The
Exchange server event logs should be checked for unexpected warnings and errors. You
can do this manually on each Exchange server or by using a tool like Microsoft
Operations Manager (MOM), which can consolidate logs and filter out certain entries.

 Check Backup Jobs   Ensure that the previous night’s backup jobs have run and
investigate any errors or warnings. There should be a procedure for media rotation,
labeling, and storage, according to the backup strategy being used. If applicable (based
on the type of the backup that was run), determine whether the transaction logs have
been flushed from the disk as part of the backup process.

 Check Performance Monitors   You may be using Windows Performance Monitor or

more advanced tools such as MOM to check key performance indicators, such as free
disk space and message queue lengths for an overall view of the state of the server or
system. Use the alert feature of these tools to set up warnings for any sudden changes or
problems and set baselines that you can modify with the growth of your organization.
 29

 Check Intrusion Detection Logs   If you have dedicated intrusion detection software or
if your firewall produces logs of intrusion attempts, review the logs for the previous day,
investigating repeated authentication attempts and other suspicious activity.

 Check Antivirus Updates   Check that the automatic antivirus signature update has
been working on each Exchange server and/or gateway and that all the signatures are
up-to-date. If you manually update antivirus signatures, do them daily.

Weekly Operations Tasks

It is recommended that the following tasks and procedures be performed weekly:

 Archive Event Logs   If event logs are not configured to overwrite events as required,
they must be regularly archived and purged. This is especially true of security logs, which
may be required when investigating attempted security breaches.

 Check for Security Updates   Identify any new service packs, hotfixes, or updates. If
appropriate, test these in a test lab and use the change control procedures to arrange for
deployment to the production servers.

 Review SLA Performance Figures   Check the key performance data for the previous
week. Review performance against the requirements of the SLA. Identify trends and
items that have not met their targets.

 Check Public Folder Replication   Check that public folder replication is up-to-date. If

replication is failing, users might not be able to access data, or they may be accessing
data from remote sites, resulting in gradually increasing WAN traffic.

 Archive Data   Archive data to CD, DVD, tape, or similar media. After a user has left and
depending on your organization’s policy, you may have to leave the mailbox for a period
of time and then archive it to maintain a reasonable Exchange store size.

 Environmental Tests   Air conditioning, temperature and humidity monitors, and physical

security measures should be periodically checked and maintained.

Monthly Operations Tasks

It is recommended that the following tasks and procedures be performed monthly:

 Security Checks   Depending on the level of required security, it may be appropriate to

perform regular audits of security, including firewall rules, user rights, group membership,
delegate rights, and so on.

 Capacity Planning   Review capacity figures for the previous month and produce a plan
for any upgrades that may be required in the coming months to keep the system
operating within limits specified by the SLA.

 Disaster Recovery Test   Do a system recovery for a single server to test hardware. This
will simulate a complete hardware failure for one server and ensure that the resources,
 30

plans, and data are available for recovery. Try to rotate each month, so that failure of a
different server or other piece of equipment is tested every time. For example, mail relay
server, front-end Exchange server, back-end Exchange server, firewall, and so on.

As-Required Operations Tasks

The following tasks are performed as-required, but are frequently also covered by standard
procedures:

 New Users and Leavers   New users typically require a user account, a mailbox, certain
rights and group memberships, possibly an e-mail copy of the organization’s IT and
security procedures, and so on. For this to occur quickly, the exact procedure should be
documented. People who leave the organization must have access to their mailbox and
other systems revoked (often urgently). You may require a policy to define what should
be done with e-mail destined for the user (should it be re-routed or rejected). You will also
need a procedure to explain what happens to a user’s Exchange data after they leave.

 Public Folder Creation   You can grant users permission to create some public folders,
but other folders (especially top-level folders) should be created by administrators only. A
procedure should define who can make requests and what permissions should be
applied.

 Mailbox Recovery   Recovery of an entire mailbox can be done by using the mailbox

recovery center. You can do this quickly and safely if it is standardized in a procedure.

 Full Security Audit   This may be performed regularly, in response to an upgrade or

redesign of the messaging system, or in response to an attempted (or successful)
security breach. The procedure may involve port scans on servers and firewalls, audits of
security fixes, and third-party penetration tests.

 Update Performance Baselines   Performance baselines should be updated after an

upgrade or configuration change. Baselines will be used to measure performance
changes and to detect problems that affect system performance.

 Database Maintenance   Use disk defragmentation to perform database maintenance.

Defragmenting your hard disks helps increase disk performance and helps ensure that
your Exchange servers run smoothly and efficiently.

 Other Database Maintenance   Other database maintenance can be categorized under

system troubleshooting. It is useful to have a procedure about how to use Isinteg.exe,
Eseutil.exe, and other standard tools in response to specific problems.

Tools and Technologies for Operating an Exchange 2003

Server Organization
The basic set of tools for administering Exchange servers and users includes the Windows
Server 2003 administrative tool pack and the Exchange Server 2003 system management
 31

tools. This section outlines some of the tools for managing the operations of an Exchange
Server 2003 organization. These management tasks and tools are divided into six groups:

 Active Directory and Permissions Management   Exchange Server 2003 is tightly

integrated with, and depends on Active Directory. User attributes that pertain to Exchange
servers (e-mail address, ability to connect using POP3, mailbox server, and so on) are
stored as user attributes in Active Directory. Therefore, an important tool for managing
Exchange users is the Active Directory Users and Computers MMC snap-in.

 Security Updates and Software Updates   Messaging systems can be especially

vulnerable to malicious attacks because most messaging systems are connected to the
Internet and must be able to accept unsolicited connections from unknown systems. It is
very important to apply all security updates to servers exposed to public networks as
soon as they are available. Ensure that you test the security updates in a test
environment before you deploy them in your production environment. To verify that your
servers are up-to-date and report back on missing service packs and hotfixes for the
operating system and applications, you can use Microsoft Baseline Security Analyzer
(MBSA). MSBA, which is available as a free download from Microsoft, should be used to
do audits on systems. For more information, see the Microsoft Trustworthy Computing:
Security Web site (http://go.microsoft.com/fwlink/?LinkId=26388).

Note:
MBSA looks for security updates on Exchange Server 5.5 and above. It will not
check how Exchange is configured.

 Conversely, Software Update Services (SUS) is a tool for automatically deploying

security updates and other necessary updates. It is especially useful for updating
workstations, but can also be used to update servers. SUS automatically downloads
each update over the Internet as it is released by Microsoft. It allows you to test a
new update before automatically deploying it. Using Active Directory policies, you can
control which computers receive updates and how the updates are applied.
Workstations can be configured to download and install updates and restart as
needed without manual intervention. Servers are typically configured to download
updates only. An administrator must manually install the updates and restart the
server at a convenient time. For more information about SUS, see
http://go.microsoft.com/fwlink/?LinkId=35215.

 Security Management   Use the IIS Lockdown Tool to secure Internet Information

Server 4.0, 5.0, and 6.0. The IIS Lockdown (IISlockd.exe) tool is required for
Windows® 2000 Server only. In Windows Server™ 2003, IIS Lockdown is a core part of
Internet Information Services (IIS). For more information about how to use the IIS
Lockdown tool for a server running Exchange Server 2003 on Windows 2000, see
Security Operations Guide for Exchange 2000 Server (http://go.microsoft.com/fwlink/?
linkid=11906). The IIS Lockdown Tool is composed of two parts. The first part changes
configuration settings within IIS to prevent common attacks against Web servers. It also
provides the option to remove or disable unused services and Web pages. The second
 32

part is referred to as URLScan, which prevents malicious and malformed requests from
Web browsers. There are templates provided within IIS Lockdown for various server roles
that disable only the services that are not required for a specific server role. When you
are running IIS Lockdown on an Exchange server, make sure that you use the template
for the appropriate version of Exchange. For more information about the IIS Lockdown
Wizard, see Microsoft Knowledge Base article 325864, "HOW TO: Install and Use the IIS
Lockdown Wizard" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325864).

 Microsoft Operations Manager   In medium to large enterprises, or in organizations

where high availability is important, consider using an automated tool to track the
performance and availability of servers and for capacity management. These tools can be
configured to report on long-term trends such as a gradual drop in response to MAPI
clients as the number of clients increase. They can also be used to alert support staff if a
failure occurs or there is a rapid degradation of service. Microsoft Operations Manager is
an application for monitoring and alerting, managing event logs, reporting, and trend
analysis. It is used to monitor servers and automatically logs and analyzes events and
statistics from many computers. For more information about Microsoft Operations
Manager, see the Microsoft Operations Framework Web site
(http://go.microsoft.com/fwlink/?linkid=21640).

 Systems Management Server   Systems Management Server is a tool that enables you

to automate configuration management tasks by gathering information about hardware
and software assets, storing this data in a SQL Server database, and allowing custom
queries and reports to be generated. Besides doing the reporting duties of configuration
management, Systems Management Server can deploy software, service packs, and
hotfixes. System Management Server can be configured to automatically detect devices
on a network and to deploy agents to each server or workstation.

Each agent gathers configuration data from the device and passes the information back
to the central database. It can therefore be used to automate many of the regular
changes discussed in the change management section. Windows Server 2003 software
deployment services can be used to deploy software to computers or users across an
organization or in a specific organizational unit (OU). With the flexibility of Systems
Management Server you could, for example, deploy software only to clients within a
specific OU, running Windows XP, with at least 2 GB of free disk space, and at least
256 MB RAM. For more information about System Management Server, see
http://go.microsoft.com/fwlink/?LinkId=34976.

 Exchange Server 2003 Tools   Standard tools to manage an Exchange Server 2003

organization include Exchange System Manager and the Exchange Migration Wizard.
For more information about using Exchange System Manager to do standard tasks, see
the topic, "Daily Operations Tasks." The Exchange Migration Wizard, is used to migrate
user mailboxes from other messaging systems, such as Exchange Server 5.5,
Exchange 2000 Server, Microsoft Mail for PC Networks, or Lotus cc:Mail to Exchange
Server 2003.
 33

 Automation Tools and Scripts   Many administrative tasks can be automated by using

scripts. Microsoft Windows Scripting Host (WSH) is the host application that enables
scripts to be run and is installed by default on Windows Server 2003 and Windows XP
Professional. Of the scripting languages, VBScript (a derivative of Visual Basic®) is the
most commonly used for administrative tasks, where speed of writing is more important
than elegance and efficiency of the code. There are many examples of useful scripts on
the Web that can be customized to suit your needs. For useful script examples, see the
Script Center on the Microsoft TechNet Web site (http://go.microsoft.com/fwlink/?
linkid=33284).

Exchange Server 2003 Daily Operations

To ensure the availability and reliability of your Microsoft® Exchange Server 2003
organization, you must actively monitor the physical platform, the operating system, and all
important Exchange Server 2003 services. Preventive maintenance will help you identify
potential errors before any one of these errors cause problems with the operation of your
Exchange organization. Preventive maintenance combined with disaster recovery planning
and regular backups will help minimize problems if they occur. Monitoring your Exchange
organization involves checking for problems with connections, services, server resources,
and system resources. You can also set alerts to notify administrators when problems occur.
Microsoft® Windows Server™ 2003 and Exchange Server 2003 provide you with many
monitoring tools and services to ensure that your Exchange Server 2003 organization is
running smoothly. The key advantages to daily monitoring are as follows:

 Ensures that the performance requirements of your service level agreements (SLAs) are
being met.

 Ensures that specific administrative tasks, such as daily backup operations and checking
server health, are being successfully completed.

 Enables you to detect and address issues, such as bottlenecks in the server performance
or need for additional resources, in your Exchange organization before they affect
productivity.

The following daily maintenance tasks let you establish criteria for what is normal for your
organization and to detect any abnormal activity. It is important to implement these daily
maintenance tasks so that you can capture and maintain data about your Exchange
organization, such as usage levels, possible performance bottlenecks, and administrative
changes. The following tasks are discussed in detail this topic:

 Performing physical environmental checks

 Performing backups

 Checking disk usage

 34

 Checking the Event Viewer

 Checking connector and server status

 Monitoring server performance

 Checking message paths

 Performing daily database maintenance

 Monitoring network performance

 Monitoring Exchange and Windows services

 Monitoring cluster resources

 Enforcing security measures

Performing Physical Environmental Checks

Before you check performance, availability, and functionality of your Exchange organization,
you should check the physical environment. For example, the server room temperature might
need to be lowered, or a network cable might need to be replaced. You should perform the
following physical environmental inspections:

 Physical security measures   Physical security protection such as locks, doors, and

restricted-access rooms must be secured. Check for any unauthorized and forced entries
and signs of equipment damage.

 Temperature and humidity   High temperature and humidity can cause hardware

components to overheat. Check temperature and humidity to ensure the environmental
systems such as heating and air conditioning can maintain acceptable conditions and
function within the hardware manufacturer's specifications.

 Devices and components   Your Exchange organization relies on a functioning physical

network and related hardware. Check to ensure that routers, switches, hubs, physical
cables, and connectors are operational.

Monitoring Event Viewer

You can use Event Viewer to obtain information about service failures, replication errors in the
Microsoft Active Directory® directory service, and warnings about system resources such as
virtual memory and disk space. Use Event Viewer to view and manage event logs; obtain
information about hardware, software, and system problems that must be resolved; and
identify trends that require future action.

Event Viewer maintains logs about application, security, and system events on your
computer. Both Exchange Server and Windows report warnings and error conditions to the
event logs. Therefore, make sure that you review event logs daily. For more information about
 35

Event Viewer, see the Windows Server 2003 Help documentation. You can also use Event
Viewer as a troubleshooting tool. For more information about using Event Viewer as a
troubleshooting tool, see Microsoft Knowledge Base article 302542, "How to Diagnose
System Problems with Event Viewer in Windows Server 2000"
(http://go.microsoft.com/fwlink/?linkid=3052&kbid=302542).

A computer that is running a Windows Server 2003 operating system records events in three
types of logs:

 Application logs   The Application log contains events logged by applications or

programs. Developers determine which events to log. For example, a database program
might record a file error in the Application log. Most Exchange Server-related events are
in the Application log.
 Security logs   The Security log records events such as valid and invalid logon attempts,
as well as events related to resource use such as creating, opening, or deleting files or
other objects. For example, if logon auditing is enabled, attempts to log on to the system
are recorded in the Security log.

 System logs   The System log contains events logged by Windows system components.
For example, the failure of a driver or other system component to load during startup is
recorded in the System log. The event types logged by system components are
predetermined by the server.

Exchange Server 2003 diagnostic logging records significant events related to authentication,

connections, and user actions. After you enable diagnostic logging, you can view the log
entries in Event Viewer.

Note:
Using the maximum logging settings is not recommended unless you are instructed
to do this by Microsoft Product Support Services. Maximum logging drains significant
resources and can give many "false positives," that is, errors that get logged only at
maximum logging but are really expected and are not a cause for concern. It is also
recommended that you do not keep diagnostic logging on permanently. It should be
used only when troubleshooting.

Within each Event Viewer log, Exchange Server records informational, warning, and error
events. Monitor these logs closely to track the types of transactions being conducted on your
Exchange servers. You should periodically archive the logs or use automatic rollover to avoid
running out of space. Because log files can occupy a finite amount of space, increase the log
size (for example, to 50 MB) and set it to overwrite, so that Exchange Server can continue to
write new events.

You can also automate event log administration by using tools and technologies such as the
Event Comb, Eventtriggers, and Microsoft Operations Manager (MOM).

 The Event Comb tool lets you gathers specific events from the event logs of several
computers to one central location. It also lets you report on only the event IDs or event
 36

sources you specify. For more information about Event Comb, see the Account Lockout
and Management Tools Web site (http://go.microsoft.com/fwlink/?linkid=35607).

 You can also use command-line tools to create and query event logs and associate
programs with particular logged events. Eventtriggers.exe lets you create event triggers
that will run programs when specific events occur. For more information about
Eventtriggers, see the Windows Server 2003 documentation.

 You can use Microsoft Operations Manager to monitor the health and use of Exchange
servers. Exchange Server 2003 Management Pack extends Microsoft Operations
Manager by providing specialized monitoring for servers that are running Exchange
Server 2003. This management pack includes a definition of health for an
Exchange 2003 server and will raise an alert message to the administrator if it detects a
state that requires intervention. For more information about Exchange 2003 Management
Pack, see the Microsoft Operations Manager Web site (http://go,microsoft.com/fwlink/?
linkid=16198).

The following section gives you information about the types of events to monitor.

Normal Events
Reviewing event logs daily will help you establish a baseline for typical events for your
system. Examine your event logs for the following application log events (Table 1) on your
Exchange servers.

Table 1   Normal events

Event ID Status

8000 and 8001 This event indicates the start and end of a
backup process.

700 and 701 This event indicates the start and end of the
online defragmentation process.

1206 and 1207 This event indicates the start and end of the
clearing of the deleted items process.

1216 This event is logged on the Exchange

Standard server only when Microsoft
Exchange Information Store service starts
and indicates that the databases are limited
to 16 GB
 37

Event ID Status

1217 This event is logged on the Exchange

Enterprise server only when Microsoft
Exchange Information Store service starts
and indicates that the databases are not
limited in size (theoretical limitation is 16 GB)

9523 This event is logged when individual

Exchange databases are successfully
mounted. There might be multiple instances
of this event when the Exchange server
restarts.

1001 This event indicates that the Microsoft

Exchange Information Store service has
started. This event also indicates the version
and build number of the Microsoft Exchange
Information Store service.

1016 While this event is logged with Warning

severity, you do not have to worry about it.
This event is logged even when one user
checks another user’s free/busy information,
so this does not indicate a security problem
by itself. For more information, see Microsoft
Knowledge Base article 301328, "A 1016
event entry appears in the application event
log after you upgrade to Outlook 2002"
(http://go.microsoft.com/fwlink/?
linkid=3052&kbid=301328).

Events That Indicate Problems

The events described in Table 2 are examples of application log events that may indicate
issues with your Exchange Server.

Table 2   Events indicating problems

Event ID Status

2064 and 2069 Indicates DSAccess problems caused by

incorrect Domain Name System (DNS)
configuration.
 38

Event ID Status

9582 Fragmented virtual memory. For more

information about fragmented virtual memory
issues, see Microsoft Knowledge Base
article 325044,"HOW TO: Troubleshoot
Virtual Memory Fragmentation in
Exchange 2003 and Exchange 2000,"
(http://go.microsoft.com/fwlink/?
linkid=3052&kbid=325044).

9548 This Warning event indicates incorrect

security settings on mailbox-enabled user
accounts. Multiple occurrences of this event
will cause performance issues on the
Exchange Server computer. For more
information, see the following Microsoft
Knowledge Base articles:

 278966, "Unable to Move or Log On to

Exchange Resource Mailbox,"
(http://go.microsoft.com/fwlink/?
linkid=3052&kbid=278966).

 839862, "How to troubleshoot the RPC

Cancel Request dialog box in
Outlook 2003 or in Outlook 2002,"
(http://go.microsoft.com/fwlink/?
linkid=3052&kbid=839862).

9551 This Warning event indicates the presence

of “zombie users” in Access Control Lists
(ACLs) of mailboxes or public folders.
"Zombie" users are unused access control
entries (ACEs). Multiple occurrences of this
event will cause performance issues on the
Exchange Server computer. This can be
logged on both mailbox and public folder
servers. For more information, see Microsoft
Knowledge Base article 839862, "How to
troubleshoot the RPC Cancel Request dialog
box in Outlook 2003 or in Outlook 2002,"
(http://go.microsoft.com/fwlink/?
linkid=3052&kbid=839862).
 39

Event ID Status

9552 This Error event indicates problems with

conversion of distribution groups that are
listed in ACLs of public folders or mailboxes
to security groups. Multiple occurrences of
this event will cause performance issues on
the Exchange Server computer. This can be
logged on both mailbox and public folder
servers. For more information, see Microsoft
Knowledge Base article 274046, "You
Cannot Add a Distribution Group to
Permissions of a Public Folder in
Exchange 2000,"
(http://go.microsoft.com/fwlink/?
linkid=3052&kbid=274046).

Event Sources to be Monitored in the Application Log

As shown in Table 3, in the event source, you must monitor the following Exchange
messaging and collaboration service counters.

Table 3   Event sources to be monitored

Event source Status

MSExchangeAL This component stamps users with e-mail

addresses and adds users to address lists.

Event ID 8026 indicates network connectivity

or Lightweight Directory Access Protocol
(LDAP) configuration issues.

MSExchangeIS The Microsoft Exchange Information Store

service handles Exchange databases and is
part of the mail delivery process.

Event ID 9518 indicates a failure while

starting an Exchange storage group.

MSExchangeSA This component records an entry when

Exchange Server uses Active Directory to
store and share directory information.
 40

Event source Status

MSExchangeTransport Event ID 4000 indicates that a connection

has failed because of a non-protocol error.
Connection failures can include DNS and
server issues.

ESE This is the database engine that the

Microsoft Exchange Information Store
service uses. Errors or warnings that are
logged by this component must be
investigated immediately.

MSADC MSADC runs only on Exchange servers that

are also running Active Directory Connector
(ADC). Warnings or errors logged with this
source could indicate problems with ADC
replication. These events typically include
the name of the connection agreement that
is having problems replicating.

MSExchangeDSAccess DSAccess is a component that Exchange

uses when talking to Active Directory. Errors
or warnings logged by this component
typically indicate issues connecting to the
domain controller or global catalog server
and should be investigated because
message flow or even startup of Exchange
services could be affected.

MSExchangeMU The metabase update service is a

component that updates the IIS metabase
with information in Active Directory. Errors or
warnings in this component could mean that
there is a problem either with the IIS
metabase or with accessing objects in Active
Directory.

USERENV While this is not an Exchange-logged event,

you should watch for it. If there are problems
applying the computer policy to the
Exchange Server computer, this event is
logged. Typically, this is logged as an Error
event and it should be investigated because
not having a domain policy will be a problem
for the Exchange Server computer.
 41

Event Sources to be Monitored in the System Log

Table 4 shows the Windows-related issues that you must monitor in the event source.

Table 4   Events sources to monitor

Event source Status

Disk Any warnings or errors logged with this

source could indicate hardware problems
that could damage your Exchange
installation, database log files, or transaction
log files. Investigate the description to see
which drives are having problems.

NTFS file system Errors or warnings with this source generally

indicate a problem at the file-system level.
Investigate the description to determine
which drives are having problems and
search the Microsoft Knowledge Base for
information about the event, because some
problems can be repaired.

NETLOGON Errors with this source could indicate serious

problems with either established domain
trusts or security channel issues between
Exchange Server and its domain. This in
turn could cause multiple Exchange issues,
including not being able to mount databases
or start services. This should be looked at
immediately.

Service Control Manager Errors with this source generally indicate

service startup failures or abnormal service
termination (event 7031).

Performing Backups
Performing backups of your servers is your first line of defense in planning for a disaster. You
must have a well planned and well rehearsed disaster recovery plan for your Exchange
organization. Your disaster recovery plan should include backing up your Exchange data and
Active Directory data daily. You must back up all critical data from many sources, including
server configuration, the Active Directory database, and the Microsoft Exchange Information
 42

Store service. You should also back up all logged event and performance data. Make sure
that you back up records such as Active Directory data, application software, Exchange
Server 2003 message tracking log files, and databases and log files. For more information
about disaster recovery planning, see the Exchange Server 2003 Disaster Recovery
Operations Guide (http://go.microsoft.com/fwlink/?LinkId=30250).

You can use the NTBackup tool (included with Windows Server 2003) to back up Windows
Server 2003 and Exchange Server 2003 data. You can also use a third-party backup tool that
supports Exchange Server 2003. The NTBackup tool helps you back up Exchange
Server 2003 databases, directories, selected files, and System State data, which includes
Windows Server 2003 operating system registry information.

The recommended minimum backup strategy is a daily "online" backup. For your daily
backup strategy, depending on the size, speed of backup software, hardware capacity, and
time requirements, you can choose between full backup, incremental backup, or differential
backup of your Exchange data. These options are discussed in more detail in this section.
For more information about these backup strategies as well as disaster recovery operations,
see the Exchange Server 2003 Disaster Recovery Operations Guide
(http://go.microsoft.com/fwlink/?LinkId=30250).

NTBackup
NTBackup is the native Windows backup tool that enables you to back up files to tape and
restore files from tape. If Exchange Server or System Manager is installed on the server, the
registry is modified on each Exchange server to extend the capabilities of the tool. As soon as
it is extended, the tool can be used to back up Exchange data either locally or across the
wire.

For more information about NTBackup, see the Windows Server 2003 documentation. For
more information about how to perform an online backup using NTBackup, see Microsoft
Knowledge base article 258243, "How to Back Up and Restore an Exchange Computer by
Using the Windows Backup Program," (http://go.microsoft.com/fwlink/?
linkid=3052&kbid=258243).

Full Backup
A full backup is also known as a normal backup. You should perform a full backup of your
database files and transaction logs every day. After completion of a full backup of a storage
group, the committed transaction log files on the Exchange databases are purged (deleted)
from the server. Doing a full backup gives you the advantage of speed in a recovery scenario,
because you need only one tape set to restore all data.
 43

Incremental Backup
Depending on your organization's requirements, you may choose to do a full backup
periodically and perform incremental backups more frequently, possibly daily. An incremental
backup captures only that data that has changed since the last full or incremental backup by
backing up the transaction log files (not database files). After the incremental backup is
completed, the committed logs files are purged. This kind of backup is not enabled if you
have configured a storage group to use circular logging.

You can choose this backup strategy if you have large databases that have a lot of daily
activity. Know that when recovering from an incremental backup, you will need the tape sets
from your last full backup and all the subsequent incremental backups. The extra time
needed to manage the additional tape sets should be factored in to your SLA.

Differential Backup
Depending on the needs of your organization, you may choose to do a full backup
periodically and perform a differential backup more frequently, possibly daily. Differential
backups capture data that has changed since the last full backup. A differential backup copies
all log files (not database files) when it is run. After the differential backup is complete, no log
files are purged. This means that the number of files backed up each day will continue to
increase until a full backup is performed (which purges the log files). This kind of backup is
not enabled if you have configured a storage group to use circular logging.

The advantage of a differential backup is that you need only one tape set for recovery of all
log files after the last full backup is restored from the tape.

Checking Disk Usage

Hard disks drives are a critical component of your Exchange organization. Without sufficient
free disk volume, neither the operating system nor the Exchange databases can function
correctly. You must monitor the Exchange store statistics daily to ensure that you do not run
out of disk space and to prepare to add storage resources as required. When the Microsoft
Exchange Information Store service runs out of hard drive space, it will log Event ID 1113 in
the application event log to indicate the problem. For more information about managing
Windows Server 2003 disks and data, see the Windows Server 2003 documentation.

Checking Disk Space

Exchange Server needs hard disk space to store its databases and transaction logs. You can
check free disk space by using the following methods:

 Windows Explorer   Use Windows Explorer to check for disk space on volumes that
store Exchange logs and databases. You should monitor the disk space regularly to
ensure that the Microsoft Exchange Information Store service will not be negatively
 44

affected because of insufficient storage resources. Comparing and maintaining statistical

information about available disk space on each Exchange volume and expected growth
of the databases and transaction log files, will help you with capacity planning and adding
storage when the storage resources are required. To accommodate troubleshooting and
disaster recovery situations, it is recommended that available free volume space be equal
or greater than 110% of the size of database.

 Running a script   Monitor disk space by running a script that will send you an alert
message if the hard disk space falls below 100 MB. You can find a sample script on the
TechNet Script Center Web site (http://go.microsoft.com/fwlink/?linkid=33284).

 Implementing alerts   Implement alert messages in Exchange Server and in the

Performance Monitor to "alert the administrator" when volume space is constrained. For
more information, see "Monitoring Server Performance" in this topic.

Gathering Information about Exchange Databases by Using

Exchange System Manager
You can gather additional information about the Exchange databases by using Exchange
System Manager. Expand the mailbox and public folder store node in Exchange System
Manager to view database information and do the following tasks:

 Alert users to close their mailboxes before a planned maintenance of your Exchange
system.

 Monitor the size of users' mailboxes to identify which users are using the most storage
resources.

 Gather information about the current state of the full-text indexing for mailbox and public
folder stores (if indexing is used).

 Collect information about the current state of public folders.

 Export this date to a file so that it can be used for historical trending or other reporting
purposes. You can also automate the collection of information about Exchange stores by
using third-party tools and Windows Management Instrumentation (WMI). For more
information about WMI, see the "Monitoring Network Performance" topic.

Checking Transaction Logs

The most important aspect of disaster recovery for Exchange Server is the transaction logs,
which allows you to recover Exchange Server data "up to the point of failure." For efficiency,
there is one set of transaction logs per storage group. The transaction logs configuration is
important to ensure that you can recover data if the databases are damaged.

In standard Exchange transaction logging, each store transaction (such as creating or

modifying a message) is written to a log file and then to the Exchange store. The logging
 45

process ensures that records of transactions exist if a store is damaged between backups. In
many cases, recovering a damaged store means restoring the store from a backup, replaying
any backed up log files, and then replaying the most recent log files to recover transactions
that were made after the last backup.

If a disaster occurs, and you must rebuild a server, use the latest transaction log files to
recover your databases. If you have access to the latest backup and the transaction log files
since the backup, you can recover all your data. For more information about how transaction
logs function, see "Understanding Exchange 2003 Database Technology" in the Exchange
Server 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?
LinkId=30250). By default, Exchange stores transaction log files in the following folder:
%windir%:\Program Files\Exchsrvr\MDBDATA. This folder is in the same partition where you
installed Exchange Server 2003.

Checking Connector and Server Status

You can use the Monitoring and Status feature in Exchange System Manager to view and
provide alert messages about the status of connectors, Exchange services, and operation
system services in your organization.

You can set notifications in Monitoring and Status to alert administrators when connectors or
services fail or when defined resource thresholds are reached (for example, when the free
disk space on a particular disk reaches a specific capacity). To access the Monitoring and
Status feature in Exchange System Manager, expand Tools in the console tree. For
procedural information about how to use Monitoring and Status, see Exchange Server 2003
Help.

Setting Notifications
You can set notifications to alert an administrator of many potential problems. You can set e-
mail notifications or you can use a script to respond to server or connector problems. You can
send notifications only in the following circumstances:

 If a server enters a warning state

 If a server enters a critical state

 If a connector enters an unreachable (down) state

After an alert is sent, you can use the Status window to view the state of a server or
connector and use the Monitor tab to view server resource monitor states. Table 5 describes
the server resource states and the potential cause for the state.
 46

Table 5   Server resource states

Server status Potential cause

Unreachable The server may be down, or if the server is

in a different routing group, the connector
between these routing groups may be down
or may not exist.

Unknown The System Attendant cannot communicate

with the local server.

Critical or Warning A monitored server resource has reached or

exceeded the defined threshold.

Unavailable A communication service, such as the

routing service, may not be functioning for
the connector.

Monitoring Exchange Server Resources

You can configure the hardware and software resources you want to monitor by using the
Monitoring tab in the server's Properties. You can specify the parameters within which your
server's hardware and software should function before a warning or critical state (or both)
alert is displayed. After resource monitoring thresholds are met or exceeded, a warning is
displayed on both the Monitoring tab of a server's Properties and on the Status node under
Monitoring and Status.

You can use Exchange System Manager to direct Exchange to send an e-mail message or
start a script when the server resources that you are monitoring perform outside defined
thresholds. These messages or scripts that notify you when something is wrong are referred
to as notifications.

Table 6 shows these additional resources and provides guidelines for setting their respective
thresholds. These resources are discussed in detail in this section.

Table 6   Additional resources

Resource Guideline for setting the threshold

Available virtual memory Set warning and critical thresholds for

available virtual memory. Virtual memory
should not fall under 25 percent free on an
Exchange server for any length of time.
 47

Resource Guideline for setting the threshold

CPU Utilization Set warning and critical limits for CPU usage
over a sustained period. CPU usage should
not exceed 80 percent over 5 minutes.

Free disk space Set warning and critical levels for available
space on a volume. Monitor the volumes
used for system binaries, Exchange Server
databases, and Exchange Server
transaction logs. Configure the monitor to
issue a warning when a drive has less than
100 megabytes (MB) of disk space
remaining and to issue a critical alert when a
disk drive has less than 25 MB of disk space
remaining.

SMTP queue growth Set thresholds for continuous queue growth.

Messages that stay in the queue for longer
than five minutes may indicate a problem
with a connector.

Windows 2000 service Identify additional services in Windows that

you want to monitor. Identify whether each
service being stopped is considered to be in
a warning or critical state.

X.400 queue growth Set thresholds for continuous queue growth.

Messages that stay in the queue for longer
than five minutes may indicate a problem
with a connector. This queue should be
empty if your environment uses only SMTP
to connect to other messaging systems.

You can also use the Windows Server 2003 System Monitor for establishing a baseline of
performance and for troubleshooting performance issues. You can also review event logs to
monitor server resources.

Virtual Memory
Virtual memory stores data. Problems can occur if there is insufficient virtual memory. You
can set the virtual memory threshold in minutes that the virtual memory can stay under the
specified limit before an alert status is displayed. You can specify the Warning state to
indicate the smallest percentage of virtual memory on which your server can operate before a
warning is displayed. If you have both warning and critical state limits specified, the critical
 48

limit must be a smaller percentage (less virtual memory available) than the amount specified
for the warning state.

For more information about fragmented virtual memory issues, see Microsoft Knowledge
Base article 325044," HOW TO: Troubleshoot Virtual Memory Fragmentation in
Exchange 2003 and Exchange 2000," http://go.microsoft.com/fwlink/?
linkid=3052&kbid=325044.

CPU Utilization
CPU utilization provides information about how busy your CPUs processors are. You can
monitor the percent of your server's CPU utilization. When your server's CPU utilization is too
high, Exchange Server 2003 may stop responding.

Note:
During some server events, CPU utilization may increase to high levels for a period
of time. When the server event is complete, CPU utilization returns to normal levels.
Ensure that the duration that you specify is more than the number of minutes that
such system events normally run.

You can specify the number of minutes that the CPU utilization threshold must exceed before
an alert status of warning or critical is displayed. You can set the warning state limit to specify
the maximum percent of CPU utilization that can occur before a warning is displayed. You
can also set a critical state limit to indicate the maximum percent of CPU utilization that can
occur before a critical state alert is displayed. A critical limit value must be a larger percentage
than a warning limit value.

Free Disk Space

Free disk space indicates the amount of disk space, in megabytes (MB) that is available on a
specified drive. You can add limits to ensure that sufficient disk space is available to use
virtual memory and to store application data after an application is closed. You can set the
warning state threshold (in MB) that identifies the smallest amount of disk space on which
your server should operate before a warning appears. You can also specify the critical state
limit that identifies the smallest amount of disk space on which your server should operate
before a critical state alert appears. The value for the critical state limit must be less than the
value for the warning state limit.

SMTP Queue Growth

SMTP queue growth provides information about the queue growth within a specified time. If
an SMTP queue is backlogged, e-mail messages do not leave the queue and are not
delivered to another Exchange server as quickly as new messages arrive. This may indicate
network or system problems. You can set the Warning state (in minutes) to specify the
maximum time an SMTP queue can grow continuously before a warning is displayed. You
 49

can also set the Critical state (in minutes) to specify the maximum time an SMTP queue can
grow continuously before a critical alert is displayed. If you set both Warning and Critical state
thresholds, the Critical state threshold must be greater than the Warning state threshold.

Windows Server 2003 Service Monitor

You can use the Windows Server 2003 service monitor to monitor the Windows Server 2003
services running on your Exchange server. If a service is not running, you can specify the
type of warning (warning or critical) you receive. You can also monitor multiple Windows
Server 2003 services using a single Windows Server 2003 service monitor.

X.400 Queue Growth

X.400 queue growth provides information about the queue growth within a specified time. If
an X.400 queue continuously grows, e-mail messages do not leave the queue and are not
delivered to an Exchange 5.5 server or X.400 server as quickly as new messages arrive. This
can indicate network or system problems. You can set the Warning state (in minutes) to
specify the maximum time an X.400 queue can grow continuously before a warning is
displayed. You can also set the Critical state (in minutes) to specify the maximum time an
X.400 queue can grow continuously before a critical alert is displayed. If you set both
Warning and Critical state thresholds, the Critical state threshold must be greater than the
Warning state threshold.

Monitoring Server Performance

If your organization is small, or if you rely on one server for most of your Exchange
operations, you may need to monitor only one server. If you have a larger organization, or if
you want to monitor the performance of all servers and components in Exchange Server,
such as Microsoft Exchange Information Store service, you can use System Monitor, a
Windows Server 2003 component. The Performance console, which is made up of the
System Monitor and Performance Logs and Alerts snap-ins, is the primary toolset used to
analyze and maintain Exchange and operating system performance levels. The Performance
console is quite flexible and can be used to gather data interactively from a single server or
automated to gather data from many servers.

Exchange server performance is affected by many factors such as user profiles, system
architecture, software, and hardware components. Make sure that Windows is functioning
correctly because if it is not, your Exchange performance will be affected.

Monitoring server performance ensures that your servers are functioning correctly and helps
you identify bottlenecks in the system. You can use the performance monitoring data to
identify problems and apply corrective action. You can also use the monitoring data to
enhance the performance of your servers by identifying areas that need additional resources.
For example, you may need to increase your storage capacity to handle the growing number
 50

of users in your organization. For more information about enhancing the performance and
scalability of your organization, see the Exchange Server 2003 Performance and Scalability
Guide (http://go.microsoft.com/fwlink/?LinkId=28660).

Monitoring the Operating System

You can use the Windows Performance console, a Windows Server 2003 snap-in, to verify
that your Windows Server 2003 operating system is functioning correctly. For more
information about using the Performance console, see the Windows Server 2003
documentation.

The Windows Performance console is composed of System Monitor and Performance Logs
and Alerts. You can also use Task Manager to obtain information about the processes and
programs that are running on your local computer.

There are important differences between Task Manager and the Performance console, such
as the Performance console captures data to a file whereas the Task Manager can end a
process. Task Manager is primarily a troubleshooting aid, and the Performance console is
used for more detailed troubleshooting and analysis.

System Monitor
Using the System Monitor tool, you can define, collect, and view extensive data about the
usage of hardware resources and the activity of system services on computers that you
administer. System Monitor lets you monitor a single computer or several computers
simultaneously. This flexibility can be helpful when you want to locate a problem in your
system. You can specify the type of data you want to monitor, the source of the data, and
establish sampling parameters, such as manual or automatic, within a time interval on real-
time data. You can even change the appearance of your System Monitor to use graph,
histogram, or report views.

Performance Logs and Alerts

With Performance Logs and Alerts you can collect performance data automatically from local
or remote computers. You can view logged counter data using System Monitor or import the
data into spreadsheet programs or databases for analysis and report generation.
Performance Logs and Alerts collect data in a comma-separated or tab-separated format for
easy import to spreadsheet programs. It also supports setting sampling intervals for
monitoring data about hardware resources and system services. You can set an alert on a
counter, thereby defining that a message be sent, a program be run, an entry made to the
application event log, or a log be started when the selected counter's value exceeds or falls
under a specified setting.

An alert is a system-generated event that is triggered when counters that you are tracking
perform outside predefined thresholds. You use Performance Logs and Alerts to configure
 51

alerts. For example, you can configure an alert to notify you when the MSExchangeIS
Mailbox object’s Send Queue Size counter exceeds 25 messages.

Note:
The alert functionality depends on the Windows 2003 Messenger Service, the
Windows 2003 Alerter Service, and the existence of the recipient account registration
in the Windows Internet Name Service (WINS). The Messenger and Alerter services
are disabled by default and must be enabled and started to allow network messages
to be transmitted.

For more information about creating and configuring alerts in Windows Server 2003, see
Microsoft Knowledge Base article 324752, "How to Create and Configure Performance
Monitor Alerts in Windows Server 2003," (http://go.microsoft.com/fwlink/?
linkid=3052&kbid=324752).

Task Manager
Task Manager (Taskmgr.exe) is a Windows Server 2003 tool that provides information about
the processes and programs that are running on your local computer. You can use Task
Manager to monitor key indicators of your computer's performance. You can see the status of
the programs that are running and end programs that have stopped responding. You can also
assess the activity of running processes using up to 15 parameters, and see graphs and data
on CPU and memory usage. Additionally, you can view the network status and see how your
network adapter is functioning. If you have more than one user logged on to your computer,
you can see who is connected, what they are working on, and you can send them a
message.

Checking Message Paths

It is important to monitor the message load on your Exchange servers. You should send
routine test messages to ensure that the SMTP transport is functioning correctly. If there are
any issues with missing e-mail messages, or you suspect that there is a problem with
message delivery or routing, you can use Message Tracking Center to determine whether a
message is waiting in a queue or whether it has been sent.

By default, message tracking is turned off. Besides verifying that the Exchange Management
Service is started, you can enable message tracking by:

 Creating a system policy to enable message tracking and applying the policy to the
servers for which you want to track messages.

 Editing the properties of each server for which you want to track messages.

Message Tracking Center lets you reference the message tracking logs stored on each
server and view the history of sent messages. If the message does not appear in a tracking
log, check the Queue Viewer to see if the message is waiting in a queue for an available
 52

connection or for routing information before it can be delivered. For more information about
the Message Tracking Center and Queue Viewer, see the Exchange Server 2003
Administration Guide (http://go.microsoft.com/fwlink/?LinkId=21769).

Sending Test Messages

It is important to send test messages to ensure that messages are queued and delivered to
recipients. You can do this by creating test accounts on each of your Exchange servers and
creating an account outside your Exchange environment. You can also send test messages
between recipients in the organization and to outgoing recipients. Sending test messages is a
practical way to check for correct SMTP transport functionality.

Using the Message Tracking Center

Message Tracking Center tracks messages across servers in both mixed- and native-mode
Exchange organizations. Message Tracking Center can also track messages that are
destined for, or arriving from, another messaging system, such as Lotus Notes. Through
Message Tracking Center, you can search for all kinds of messages, including system
messages (alerts that are displayed when problems occur), public folder messages, and e-
mail messages.

To search for a specific system message in Message Tracking Center, search for the
Message ID. If you do not know the Message ID, you can find system messages manually by
reviewing the message tracking logs. Exchange automatically creates these logs if you have
message tracking enabled on a server. To search for other types of messages, you can
search by sender, recipient, or server.

Before you enable messages to appear in Message Tracking Center, you must enable
subject logging on the Exchange server. However, enabling subjectlogging causes the
subject lines of messages in SMTP and MAPI queues to be displayed in the Subject column
of Queue Viewer. By default, the Subject column is left empty to preserve confidentiality. For
example, some Exchange organizations prefer to keep low-level administrators from viewing
message subjects. Therefore, verify your organization's policy about revealing subject line
information before you enable subject logging.

Enabling Message Tracking

You can create a server policy to control the message tracking options of a group of servers
in an administrative group. However, you can also enable message tracking on an individual
server basis. For example, if you do not track messages on all your servers, but users on a
specific Exchange server are experiencing mail flow problems, you may want to enable
message tracking on the server that is experiencing mail flow problems. Alternatively, you
may want to track messages only on your Internet gateway servers.
 53

When you enable message tracking on an individual server, messages routed through the
server are added to the message tracking logs. These logs are text files that you can review
to monitor and troubleshoot message flow. The Exchange System Attendant service on each
server maintains these log files.

Managing Message Tracking Log Files

If you enable message tracking, you may want to customize how Exchange manages the
resulting log files. By default, Exchange stores the message tracking log files in the Exchange
Suite Directory and removes these log files every seven days. These default settings may or
may not fit the requirements of your Exchange environment.

Checking the Queue Viewer

Queue Viewer is a tool that lets you maintain and administer your organization's messaging
queues. Exchange uses queues to hold messages as they are being processed for routing
and delivery. Queue Viewer is available on all SMTP virtual servers, X.400 objects, and all
installed Microsoft Exchange Connectors for Novell GroupWise, Lotus Notes, and Lotus
cc:Mail.

To access Queue Viewer, in Exchange System Manager, expand the server you want, and
then click Queues. Expanding Queues reveals one or more system queues, which are
default queues specific to the protocol transporting the messages (SMTP, X.400, or MAPI).
The system queues are always visible. The link queues are also visible in the Queues
container. These queues are visible only if the SMTP virtual server, X.400 object, or
connector is currently holding or sending messages to another server. Link queues contain all
outgoing messages queued on each connector.

Options in Queue Viewer

Queue Viewer has the following options:

 Disabling outgoing mail

 Settings

 Finding messages

 Viewing additional information

Disabling outgoing mail

By using the Disable Outbound Mail option, you can disable outgoing mail from all SMTP
queues. For example, disabling outgoing mail can be useful if a virus is active in your
organization. The Disable Outbound Mail option does not disable the message transfer
agent (MTA) or system queues; it only prevents the server from transmitting to the next hop.
 54

System queues are default queues for each protocol that hold messages only while certain
required routing tasks are performed, such as content conversion and address resolution.

Settings
The Settings option lets you determine the frequency at which all the queues are refreshed,
with the default rate being every two minutes. You can set the refresh rate to one minute, five
minutes, 10 minutes, or Never refresh. If you are investigating an issue with message
delivery, you may consider reducing the frequency to one minute to see the changes in the
queues sooner.

Finding messages
You can use the Finding messages option to search for messages by specifying search
criteria (such as the sender or recipient) or the message state (such as frozen). You can also
specify the number of messages that you want your search to return.

Viewing additional information

You can view additional information about a particular queue. In Queue Viewer, the Additional
queue information pane may contain troubleshooting tips or other information about a
particular queue. The Additional queue information pane also informs you if the queue is
unavailable (for example, if the service has not started). Based on the information provided,
you may need to investigate other services to resolve the problem.

Queue States
You can check the state of all queues by looking at the State column. Queues in the Ready
state and queues that are delivering messages correctly usually have few messages queued
for transfer. If a queue is continually retrying to send a message, it may indicate that the
destination is not available. It is important to monitor queue growth. If you find messages
queued for extended periods and the queue is in Retry state, it may mean that one or more
basic routing functions is failing in your Exchange organization.

If you want to prevent outgoing mail from a particular remote queue, instead of disabling all
SMTP queues, you can freeze the messages in that particular queue. For example, if it
appears that a 5-MB message is holding up the transfer of many messages, temporarily
freeze the 5-MB message to allow other messages to transfer out. When the queue is
emptier, unfreeze the 5-MB message.

Note:
X.400-based queues cannot be frozen.

To find the messages that may be causing problems in message delivery, you must
enumerate messages in the queue by using the Find Messages feature. Table 7 lists the
types of queue states.
 55

Table 7   Queue states

Queue state Description

Active Indicates that the link queue has an active

connection. No additional action is required.

Ready Indicates that the link queue is ready for

connection. No additional action is required.

Retry If a connection attempt has failed, the server

is waiting to retry the connection. If the State
column does not change, this may indicate
that there is a problem preventing the
messages in the queue from being
delivered.

Scheduled Indicates that the queue is waiting for a

scheduled connection. No additional action
is required.

Remote Indicates that the queue is waiting for a

remote command. No additional action is
required.

Frozen Link queue is frozen and no messages will

be permitted to leave the queue until you
unfreeze the queue.

Performing Daily Database Maintenance

Mailbox and public folder stores require regular online maintenance. By default, each
database is set to run online maintenance between the times of 01:00 and 05:00. Online
maintenance performs tasks that are necessary to keep the Exchange stores in good health.
For more information about online database maintenance, see the Exchange Server 2003
Performance and Scalability Guide at (http://go.microsoft.com/fwlink/?LinkId=28660).

These online maintenance tasks include, but are not limited to:

 Checking Active Directory to determine whether there are any deleted mailboxes.

 Permanently removing any messages or mailboxes that are older than the configured
retention policy.

 Performing online defragmentation of the data in the database.

Online maintenance performs an Active Directory lookup for each user who has a mailbox on
the store that runs maintenance, in the database. These searches are used to keep the
 56

mailbox store synchronized with Active Directory changes (specifically, look for deleted
mailboxes). The effect that online maintenance has on Active Directory is proportional to the
number of users in each server database. If you have many users or have global data centers
that serve customers in different times zones, you may want to consider staggering the online
maintenance.

Online maintenance also permanently removes any messages or mailboxes that are older
than the retention policy (Mailbox Manager), and performs online defragmentation of data in
the database. These tasks are disk-intensive and affect the server where the online
maintenance is being run. Your server may seem to be slow if many databases are set to
perform online maintenance at the same time. In corporate scenarios, you may want to do
online maintenance during non-business hours when the server can better handle the
additional load. In a global data center, consider staggering the database schedule (with
regard to each other on a single server to spread disk-intensive tasks over a greater period of
time.

Exchange database online defragmentation refers to rearranging mailbox store and public
folder store data to fill database pages more efficiently and optimize how objects are stored to
try to reduce disk I/O. The defragmentation process provides more database space without
actually changing the file size of the database.

You must ensure that neither your index maintenance, nor your online backups conflict with
your scheduled "maintenance interval" for any databases in the same storage group. If there
is a conflict, backup will stop the online defragmenting part of the scheduled maintenance and
the database may not be able to finish defragmenting.

You can plan the correct online maintenance strategy for your organization by examining the
user profile (such as times of low and high activity); knowing how many users, databases,
and servers are in the site; and coordinating this information with the online backup strategy.

Monitoring Network Performance

It is important to monitor your network performance because this can affect the performance
of your Exchange system. You can monitor your network by using the following tools:

 Network Monitor

 Windows Management Instrumentation (WMI)

 Simple Network Management Protocol (SNMP)

You can also use third-party monitoring tools or Microsoft Operations Manager (MOM) to
monitor your Exchange system. For more information about MOM 2005, see the MOM 2005
Product Documentation Web site (http://go.microsoft.com/fwlink/?linkid=35627).
 57

Network Monitor
Network Monitor, a Window Server 2003 tool, is used to collect, display, and analyze
resource usage on a server and measure network traffic. Network Monitor exclusively
monitors network activity. By capturing and analyzing network data and using this data with
performance logs, you can determine your network usage, identify network problems, and
forecast your network needs for the future.

Windows Management Instrumentation

Windows Management Instrumentation (WMI) helps you manage your network and
applications as they become larger and more complex. With WMI, you can monitor, track, and
control system events that are related to software applications, hardware components, and
networks.

Exchange Server 2003 provides many WMI classes that you can use to monitor and analyze
Exchange servers, track messages, and check mail flow status. The Exchange Server 2003
SDK contains complete information about the Exchange WMI providers, including many
sample scripts to help you get started. You can download or view the Exchange 2003 SDK
from the Microsoft Exchange Server Downloads page on MSDN®
(http://go.microsoft.com/fwlink/?LinkId=29301).

Simple Network Management Protocol

Simple Network Management Protocol (SNMP) lets you capture configuration and status
information about your network and send the information to a designated computer for event
monitoring. For more information about SNMP, see SNMP in Windows Server 2003 Help.

Monitoring Exchange and Windows Services

You should monitor Exchange Server and Windows required services—services are
application types that run in the system background. Exchange Server relies on Windows
Server 2003 services for access to system resources. To perform messaging and
collaboration functions, Exchange Server has its own services that also depend on Windows
Server 2003 services; for example, to add a new mailbox store to Microsoft Exchange
Information Store service, IIS Admin Services and the Microsoft Exchange System Attendant
service must be running.

Table 8 lists the Exchange services dependencies that are required in any environment.
 58

Table 8   Exchange services dependencies

Processes Service dependencies

Setup For Exchange Server 2003 Setup to run, you

must install and enable, but not necessarily
start:

 NNTP

 SMTP

 World Wide Web Publishing Service

 IIS Admin Service

Exchange Server 2003 Setup disables the

following services by default; however, the
current state is preserved during reinstalls or
upgrades:

 NNTP

 Microsoft Exchange IMAP4

 Microsoft Exchange POP3

Administration To administer Exchange Server 2003, the

following services are required:

 Microsoft Exchange System Attendant

 Microsoft Exchange Management

 Windows Management Instrumentation

Routing To enable Exchange Server 2003 to route

messages, the following services are
required:

 Microsoft Exchange Routing Engine

 IIS Admin Service

 SMTP
 59

Processes Service dependencies

Earlier version compatibility To provide compatibility with earlier versions

of Exchange Server, the following services
are required:

 Microsoft Exchange Event Service

 Microsoft Exchange Site Replication

Service

 Exchange MTA Stacks (for

Exchange 5.5 compatibility only)

Additional features The following services provide additional

features for Exchange Server 2003:

 Microsoft Search

 World Wide Web Publishing Service

Exchange Server Services

Ensure that only the required minimum of Exchange Server services are running and have a
startup type of automatic. These services are defined by the Exchange server role, such as
front-end server. Exchange Server automatically monitors the following services:

 Microsoft Exchange Information Store

 Microsoft Exchange MTA Stacks

 Microsoft Exchange Routing Engine

 Microsoft Exchange System Attendant

 Simple Mail Transfer Protocol (SMTP)

 World Wide Web Publishing Service

Windows Services
You should verify that Windows services such as World Wide Web and SMTP are started.
Because Exchange Server also relies on Windows services, if the services are not configured
correctly, Exchange Server will not work efficiently. You should also monitor the following
services:

 Domain Name System (DNS) service

 Internet Information Services (IIS) service

 Active Directory
 60

For more information about the services dependencies of the Exchange Setup process, see
the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=21768).

Domain Name System (DNS) Service

Exchange depends on DNS for name resolution and its performance is affected by the DNS
configuration and performance. You should monitor for any indicators of DNS issues in Event
Viewer daily. You can use the DNS management console to verify the address records for
your domain controllers and global catalog servers, and the mail exchanger (MX) resource
record for your Exchange server.

Internet Information Services (IIS) Service

The IIS service is a Web service platform for publishing information about an intranet or the
Internet and for building server-based Web applications. If there are any performance issues
reported in your IIS service, you may want to review your default Web site configuration.

Active Directory
Exchange Server relies on Active Directory for correct functionality. Among other things,
Active Directory contains information about objects (such as users, contacts, groups, and
configuration) on the network and makes this information available for authorized
administrators and users. Exchange Server uses Directory Access (DSAccess) to discover
the Active Directory topology, detect domain controllers and global catalog servers, and
maintain a list of valid directory servers that are usable by the Exchange Server components.
You should monitor Active Directory servers to identify trends before actual issues, such as
the delay in authentication of client computers, occur.

You can use Active Directory Sites and Services to verify replication by helping you identify
any Active Directory replication issues that may cause performance issues for Exchange
Server. For more information about monitoring Active Directory performance, see the
Windows Server 2003 documentation.

Monitoring Cluster Resources

You must monitor your cluster resources to ensure that your Exchange Server 2003 clusters
function correctly. Before you start managing and monitoring your Exchange cluster, you may
want to review what constitutes an Exchange Virtual Server and its associated Exchange
resources. You may also want to become more familiar with Cluster Administrator—the
primary tool used to configure and manage clusters.

Before you perform any cluster administration tasks, familiarize yourself with the clustering
concepts described in "Checklist: Preparation for installing a cluster"
(http://go.microsoft.com/fwlink/?LinkId=16302) in the Microsoft Windows Server™ 2003
 61

Enterprise Edition Online Help and in the Windows Server 2003 Technical Reference
(http://go.microsoft.com/fwlink/?LinkID=27137).

Also, make sure that you are familiar with "Using Server Clustering" in Chapter 5, "Planning
for High Availability" in Planning an Exchange Server 2003 Messaging System
(http://go.microsoft.com/fwlink/?LinkId=21766) and with Chapter 7, "Deploying
Exchange 2003 in a Cluster," in the Exchange Server 2003 Deployment Guide
(http://go.microsoft.com/fwlink/?LinkId=21768)

You can monitor cluster resources by doing the following:

 Using Cluster Administrator to manage Exchange clusters

 Monitoring performance of an Exchange cluster

 Monitoring virtual memory counters

Using Cluster Administrator to Manage Exchange Clusters

You can monitor your Exchange clusters daily by using Cluster Administrator. Cluster
Administrator is used for configuration tasks, management tasks, and to monitor failovers on
your Exchange clusters.

You can also use Cluster Administrator to remotely administer a server cluster. Computers
that are used to administer a server cluster remotely must be secure and restricted to trusted
personnel. For more information about Cluster Administrator, see "Best practices for securing
server clusters" in the Windows Server 2003 Enterprise Edition Online Help
(http://go.microsoft.com/fwlink/?LinkId=18173).

Monitoring Performance of an Exchange Cluster

To monitor the performance of the Exchange Virtual Servers in your cluster, use System
Monitor. To monitor your Exchange Virtual Servers for errors that may be occurring, use
Event Viewer.

Active/passive clusters are the recommended configuration for Exchange 2003 clusters. You
can monitor active/passive clusters just as you would stand-alone server deployments.
Exchange 2003 also supports active/active clusters with at most two nodes. However,
active/active clusters are not a recommended configuration for Exchange 2003 clusters. If
you have an active/active cluster, use a monitoring application such as System Monitor to
monitor the cluster. For more information about deploying Exchange Server 2003 in a cluster,
see Chapter 7, "Deploying Exchange 2003 in a Cluster," in the Exchange Server 2003
Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=21768)
 62

Monitoring Virtual Memory Counters

It is important to monitor virtual memory to determine whether an Exchange Virtual Server
needs to be restarted because of memory fragmentation. You can monitor virtual memory by
doing the following:

 Monitor the application event log for event ID 9582

 Monitor Exchange Server 2003 virtual memory counters

 For more information about monitoring and troubleshooting virtual memory counters, see
Microsoft Knowledge Base article 325044, "HOW TO: Troubleshoot Virtual Memory
Fragmentation in Exchange 2003 and Exchange 2000," (http://go.microsoft.com/fwlink/?
linkid=3052&kbid=325044).

Monitor Event ID 9582

You should monitor for Event ID 9582, which is logged by the Microsoft Exchange Information
Store service. It indicates if your Exchange virtual memory server has become too
fragmented.

The warning logged if the largest free block is smaller than 32 MB
EventID: 9582

Severity: Warning

Category: Performance

The virtual memory that is required to run your Exchange server is fragmented in such
a way that performance may be affected. It is highly recommended that you restart all
Exchange services to correct this issue.

The error logged if the largest free block is smaller than 16 MB
EventID: 9582

Severity: Error

Category: Performance

The virtual memory that is required to run your Exchange server is fragmented in such
a way that normal operation may begin to fail. It is highly recommended that you
restart all Exchange services to correct this issue.

Monitor Virtual Memory Counters:

You should monitor the following virtual memory counters to identify memory fragmentation
on your Exchange Server 2003 clusters. It is especially important to monitor the virtual
memory counters that are listed in Table 9.
 63

Table 9   Exchange Server 2003 virtual memory counters

Virtual memory counter Description

MSExchangeIS\VM Largest Block Size
Monitor this counter to make sure that it
stays above 32 megabytes (MB). When this
counter drops under 32 MB, Exchange
Server 2003 logs a warning (Event ID=9582)
in the event log and logs an error when this
counter drops under 16 MB.

MSExchangeIS\VM Total 16MB Free Blocks
Monitor this counter to predict when the
number of 16-MB blocks is likely to drop
under three. If the number of blocks drops
under three, restart all the services on the
node.

MSExchangeIS\VM Total Free Blocks
Monitor this counter to measure how much
available virtual memory is being
fragmented. The average block size is the
Process\Virtual Bytes\STORE instance
divided by MSExchangeIS\VM Total Free
Blocks.

MSExchangeIS\VM Total Large Free Block Monitor this counter to ensure that this
Bytes counter does not drop under 32 MB. If the
number of blocks drops under 32 MB, fail
over the Exchange Virtual Servers
and restart all the Exchange services on the
node.

Enforcing Security Measures

An integral function of daily operations is to include strategies for combating spam, viruses,
and other external threats to your Exchange Server 2003 system. The performance of your
Exchange organization depends not only on hardware and software availability, but also on
correct configuration and preventive measures. There is a wealth of information about the
Exchange Server 2003 Web site about ways to secure your Exchange server. For more
information about securing your Exchange Server 2003 system, see the Microsoft Exchange
Server 2003 Security Hardening Guide (http://go.microsoft.com/fwlink/?LinkId=25210). For
specific information, see the Security Resources for Exchange Server 2003 Web site
(http://go.microsoft.com/fwlink/?LinkId=21660). You must also secure your Windows Server.
For more information about securing Windows Server 2003, see the Windows Server 2003
Security Guide (http://go.microsoft.com/fwlink/?linkid=16717).
 64

The following security measures are discussed in this section:

 Exchange Server 2003 updates management

 Antivirus measures

 Anti-spam measures

Exchange Server 2003 Updates Management

Exchange Server 2003 updates management involves staying current with the latest updates,
hotfixes, and service packs. You should ensure that both Exchange Server 2003 and the
operating system are current.

Microsoft supplies two tools to help you stay current with Microsoft Windows® service packs,
hotfixes, and updates: Microsoft Network Security Hotfix Checker (Hfnetchk) and Microsoft
Baseline Security Analyzer (MBSA). Hfnetchk is a tool that lists which updates have been
applied to a computer; MBSA identifies common security misconfigurations. Hfnetchk is
available through the command line interface of the MBSA. You can download these tools
from the Microsoft Baseline Security Analyzer Web site (http://go.microsoft.com/fwlink/?
linkid=17809). You can also use third-party tools for updates management.

You can keep current with updates available for your organization by subscribing to Microsoft
Security Bulletins. To be notified of any new updates, you can subscribe for automatic
notifications to the Microsoft Security Bulletins (http://go.microsoft.com/fwlink/?LinkId=12322).
Make sure that you test the updates in a lab environment before you deploy them.

For more information about Windows Server 2003 updates management processes, see the
Windows Server 2003 Security Guide (http://go.microsoft.com/fwlink/?linkid=16717).

Antivirus Measures
E-mail viruses can slow server performance by introducing excess network traffic and they
can attack individual computer systems or your entire e-mail environment. You must ensure
that you have sufficient protection against viruses in your Exchange Server 2003
environment. At a minimum, you must deploy antivirus software designed for messaging
systems at either the Simple Mail Transfer Protocol (SMTP) gateway or on the Exchange
servers that host mailboxes. You should also run antivirus software on the client computers. If
you are running antivirus software designed for messaging systems (meaning that it can
parse and scan MIME) at the gateway or on the Exchange server, running a file-level scanner
on client computers is usually sufficient. However, you must assess if running a file-level
scanner is sufficient for your organization.

Regardless of your virus scanning solution, you must ensure that the following is done:

 Implement a daily method to update antivirus signature files on all computers in the
organization manually or set up automatic updates. You should monitor the automation to
ensure that automatic updates are successful.
 65

 Create an action plan that explains what to do when a virus is detected. For example, you
can isolate the infected computer and disinfect it, educate users about steps to take when
their computers become infected, and update software with any required updates to
prevent additional vulnerability.

 Ensure that your solution can scan message attachments for viruses. New viruses and
worms that can do extensive damage by causing heavy network traffic can spread
through e-mail messages. Additionally, when new viruses that propagate through e-mail
attachments appear, educate users about the correct steps to take when this occurs.

Best Practices in Virus Defense

Even though you should educate users, update antivirus signature files, scan for viruses, and
plan for responding to viruses, you should also perform preventive and maintenance tasks
such as:

 Quarantine files that you suspect are infected. Then, check files to see if they are critical
and necessary components. If they are necessary and if the files cannot be disinfected,
you must replace the files from a backup or other source.

 Check the quarantine and empty unnecessary content. Files put in quarantine that can be
safely deleted should be deleted. The quarantine is a depository for administrative
inspection and should not be overloaded with files. Also, clean files should not be in
quarantine.

 For added security and protection, you can set up filtering rules to filter messages.

Anti-Spam Measures
Unsolicited commercial e-mail (spam) is a major problem for many organizations. Spam is
costly in a number of ways, from lost user time in sorting and deleting it to wasted bandwidth
and storage space. There are several ways to combat spam, as follows:

 Educate your users about spam.

 Use spam-protection features in Microsoft Office Outlook® 2003 and Microsoft Office

Outlook Web Access 2003.

 Restrict distribution groups in Exchange Server 2003

 Use message filtering options

 Use Exchange Intelligent Message Filtering

 66

Educating Your Users about Spam

The first step in combating spam is to educate your users about how to handle it. In fact, your
users are probably the most important defense against spam and it is important to educate
them about how to avoid it.

Using Spam-Protection Features in Outlook 2003 and Outlook Web

Access 2003
Both Outlook 2003 and Outlook Web Access 2003 include features, such as user-maintained
block lists and safe lists, junk e-mail filter, and external content blocking,which can help
protect your users against spam.

Restricted Distribution Groups in Exchange 2003

If spammers know the alias of a distribution group, they can reach many of your employees
with one e-mail message. Restricting distribution groups is especially effective for large
groups that contain many nested distribution groups. Exchange 2003 has a new feature that
permits mailbox users or distribution groups to receive e-mail messages only from
authenticated users. This feature lets you restrict incoming Internet e-mail for specific users
or for distribution groups. The feature is enabled when you select the From authenticated
users only check box in Message restrictions settings for an individual user or a distribution
group.

When Exchange Server 2003 expands a distribution group that can only receive mail from
authenticated users or can only receive mail from distribution groups that have the
msExchRequireAuthToSendTo attribute set to true, the Exchange message categorizer does
not permit unauthenticated mail that is sent by using SMTP to be sent to the distribution
group. Mail to restricted distribution groups is accepted only if the messages are submitted by
using the store driver, the messages are authenticated by using SMTP, or if the Resolve
anonymous e-mail option is turned on in the SMTP virtual server.

For more information about restricted distribution groups in Exchange Server 2003, see
Microsoft Knowledge Base article 827616, "How to restrict the users who can send inbound
Internet e-mail to another user or to a distribution group in Exchange 2003,"
(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827616). To learn more about the groups
that are used by Exchange Server 2003 for mail distribution and access control lists (ACLs),
see Microsoft Knowledge Base article 839949, "Troubleshooting mail transport and
distribution groups in Exchange 2000 Server and in Exchange Server 2003,"
(http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949).
 67

Message filtering options

Exchange Server 2003 includes a set of features that let the administrator create sender,
recipient, and connection filtering lists to try to block spam at the perimeter of the
organization. Exchange Server 2003 supports the following filters:

 Sender filtering   By default, SMTP connections that are created by senders on this list
are dropped. Use this feature to block e-mail messages from a list of senders

 Recipient filtering   Lets you set global restrictions on mail to specific recipients. Use
this feature to block e-mail messages to a list of internal recipients.

 Connection filtering   Filters incoming messages by comparing their IP address against

a block list provided by externally-based services that list known sources of unsolicited e-
mail sources, dial-up user account lists, and servers. You can also enter your own set of
accepted or restricted IP addresses at a global level.

For more information about how filters are applied, see the guide What's New in Exchange
Server 2003 (http://go.microsoft.com/fwlink/?LinkId=21765).

Exchange Intelligent Message Filtering

Microsoft Exchange Intelligent Message Filter provides server-side message filtering to
prevent spam. Intelligent Message Filter, based on Microsoft SmartScreen Technology from
Microsoft Research, enables Exchange Intelligent Message Filter to distinguish between
legitimate e-mail messages and unsolicited commercial e-mail (spam).

Note:
Exchange Intelligent Message Filter can be installed only on a server that is running
Exchange Server 2003 Standard Edition or Exchange Server 2003 Enterprise
Edition. When an external user sends e-mail messages through a server that is
running Exchange Server 2003 and that has Exchange Intelligent Message Filter
installed, the filter evaluates the content of the messages for recognizable patterns
and assigns the message a rating based on the probability that the message is
unsolicited commercial e-mail or spam. This rating is stored with the message as a
message property referred to as a spam confidence level (SCL). This rating persists
with the message when the message is sent to other servers that are running
Exchange Server and even other user inboxes.

Note:
The spam confidence level rating is used only by Outlook 2003 or later versions and
Exchange Server 2003.

For more information about Intelligent Message Filter, see the Exchange Intelligent Message
Filter Overview (http://go.microsoft.com/fwlink/?linkid=35656).
 68

Before you install Intelligent Message Filter, read the Microsoft Exchange Intelligent Message
Filter Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=27922). If you do not
configure Intelligent Message Filter correctly, your messaging environment can be negatively
affected.

You can also obtain more information about uninstalling Intelligent Message Filter, known
issues, and answers to frequently asked questions in Microsoft Knowledge Base article
867633, "Intelligent Message Filter Release Notes," (http://go.microsoft.com/fwlink/?
linkid=3052&kbid=867633).

Exchange Server 2003 Scheduled

Maintenance Tasks
By performing scheduled monitoring of your Microsoft® Exchange servers, you can collect
the data required for trend analysis and capacity planning. The information that you gather
from scheduled monitoring will help you characterize system performance over time. You can
use this information to plan resources before a critical need comes up, document tasks and
processes that are common for your Exchange organization, and troubleshoot your servers.
Performing the following scheduled maintenance tasks ensures that your Exchange servers
run smoothly and efficiently:

 Generating reports and identifying trends

 Reviewing protocol logs

 Monitoring Microsoft Office Outlook® Web Access servers

 Managing mailboxes

 Managing the BadMail folder

 Managing the postmaster mailbox

 Conducting weekly status meetings

Generating Reports and Identifying Trends

To ensure that Microsoft Exchange Server 2003 runs efficiently and with minimal downtime,
you must gather enough information to establish a baseline for the performance of your
server. By gathering the appropriate information, you can proactively manage your Exchange
Server 2003 messaging system and perform trend analysis and capacity planning. You must
create a baseline when you first deploy your server and then re-create the baseline any time
a change in hardware or workload occurs, such as a significant change in the number of
users. For more information about the factors that affect performance and for
recommendations about how to optimize your Exchange Server 2003 environment, see the
 69

Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?

LinkId=28660). This guide is a companion to the Exchange Server 2003 High Availability
Guide (http://go.microsoft.com/fwlink/?linkid=30251). As you plan your Exchange 2003
deployment, review both guides to help you design and optimize your environment.

This section gives you guidelines for the following tasks:

 Monitoring and measuring tasks   Provide procedures for system monitoring and

system measurement.

 Capacity planning   Establish baselines for each service and monitor all levels of system
operations.

 Capturing and reporting performance data   Record and log system activity over time,
chart the activity in real time, and display information that is in log files.

 Analyzing trends   Capture data and analyze the reports that you create by using that
data.

Guidelines for Monitoring and Measurement

At a minimum, you must create procedures for the following monitoring and measurement
tasks:

 System monitoring   These procedures must include information about server resources

that must be monitored, including memory, processor usage, hard disk space and disk
performance, and network performance. Additionally, Exchange-specific performance
indicators, such as Exchange store performance, message delivery rates, and message
queue problems must be included. Each of these procedures must specify the frequency
of monitoring tasks, the baseline or expected data to be captured, and the appropriate
escalation procedures for managing problems as they occur.
 System measurement   These procedures work with system monitoring procedures and
must include standards for the types of information measured, the measurement
sampling rate, the equations to use when you analyze data, the formats to store the data
in, and the formats to use for reporting.

Guidelines for Capacity Planning

Capacity planning is the allocation and monitoring of system resources to ensure that optimal
system performance is maintained as the system load increases. To provide capacity
planning, you must establish baselines for each service, and then continually monitor all
levels of system operations. For example, make sure that you plan carefully before
significantly increasing the number of users supported on a server that is running
Exchange Server 2003; otherwise, the increased user load may decrease performance and
overload both hard disk resources and other system resources. You can use the following
capacity planning tools:
 70

 Capacity Planning and Topology Calculator   The Capacity Planning and Topology

Calculator helps you determine the size of the servers you need for your Exchange 2000
Server or Exchange Server 2003 topology.

 Exchange Server Load Simulator (LoadSim.exe) 2003   You can simulate the load of

MAPI clients against Exchange by running LoadSim tests on client computers. These
tests send messaging requests to the Exchange server, causing a load on the server.

 Exchange Stress and Performance (Esp.exe)   The Exchange Stress and Performance

tool is a highly scalable stress and performance tool for Exchange Server. It simulates
large numbers of client sessions by concurrently accessing one or more protocol
services.

 Jetstress (Jetstress.exe)   Jetstress is a tool in Exchange Server to help administrators

verify the performance and stability of the disk subsystem before putting their Exchange
server into production.

Important:
Because some of these tools create accounts that have non-secure passwords,
these tools are intended for use in test environments, not in production environments.

For more information about capacity planning, see the Planning an Exchange Server 2003
Messaging System Guide (http://go.microsoft.com/fwlink/?LinkId=21766).

Guidelines for Capturing and Reporting Performance Data

Use Performance Monitor (Perfmon.msc) to provide information about performance objects
and related counters. The Performance Monitor console contains two snap-ins—Performance
Log and Alerts and System Monitor. To provide the required information, do the following
tasks:
 Record and log system activity over time by using Performance Logs and Alerts. You
collect data to analyze performance and usage. To use Performance Monitor to generate
reports, you must do the following:

 Configure Performance Logs and Alerts to collect data for the recommended
counters at set intervals, such as every 10 to 15 minutes.

 Capture performance data.

 Retain logs over extended periods of time by storing data in an archive with
performance log files on the hard disk or in a database such as Microsoft Access or
Microsoft SQL Server™. If you store the data in a database, you can use the
reporting features of those programs to create complex reports that you can use to
assess overall performance, do trend analysis, and do capacity planning.

 Chart activity in real time and display information that is in log files by using System
Monitor. System Monitor is a Microsoft Management Console (MMC) snap-in that you
 71

can use to monitor many subsystems and software. It provides a common infrastructure
for reporting data based on performance counters. For more information about System
Monitor, see Windows® Help. You can use System Monitor to do the following tasks:

 View server activity when server performance is decreased.

 Analyze processor activity and queues, which is useful in isolating problems with
specific components.

 Display logs of captured performance data viewed as reports, graphs, or histograms.

For more information about the tools you can use to verify the performance of your Exchange
Server 2003 environment, see "Exchange Performance Tools" in Appendix A of the Exchange
Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?
LinkId=28660).

Guidelines for Analyzing Trends

By capturing data and analyzing the reports you create by using that data, you can find
patterns and predict future trends. This trend analysis allows you to be proactive in
determining how to manage your Exchange servers in the future. For example, by analyzing
the current usage on your Exchange server, you can predict when normal growth, such as
mailbox growth, will require that you upgrade your storage. For more information about
setting baselines and analyzing trends, see the Troubleshooting Exchange Server 2003
Performance guide (http://go.microsoft.com/fwlink/?LinkId=22811).

Reviewing Protocol Logs

Protocol logging lets you track commands that virtual servers receive from clients. Do not
leave your protocol logging on continuously because it may cause bottlenecks in disk space,
which can affect system performance. You can use protocol logging to track HTTP, Simple
Mail Transfer Protocol (SMTP), and Network News Transfer Protocol (NNTP) virtual servers.
For example, for each message, you can view the client IP address, client domain name,
date and time of the message, and number of bytes sent. Consider reviewing protocol logs
regularly.

Protocol log files can help you troubleshoot messaging problems and identify potential issues
with your HTTP, SMTP, and NNTP virtual servers. There are four types of protocol logs as
described in Table 1.
 72

Table 1   Types of protocol logs

File Format Description

World Wide Web Consortium (W3C) Writes the log in ASCII text. Fields are
Extended Log space-delimited, and each entry is written on
a new line. This style is the default.

National Center for Supercomputing
Applications (NCSA) Common Log
Writes the log in ASCII text following the
National Center for Supercomputing
Applications (NCSA) Common Log file
format. Fields are space-delimited and each
entry is written on a new line.

Open Database Connectivity (ODBC) Log Writes each entry as a record in the Open
Database Connectivity (ODBC)-compliant
database that you specify.

Microsoft Internet Information Services (IIS) Writes the log in ASCII text following the IIS
Log log file format. Fields are tab-delimited, and
each entry is written on a new line.

Note:
W3C Extended Log File Format is the preferred logging format. Unless you are sure
that another format meets your needs, use this format with HTTP, SMTP, and NNTP
protocol logging.

You can enable protocol logging on the Properties tab of the SMTP or NNTP virtual servers
in Exchange System Manager. You enable logging on the HTTP Exchange Virtual Server
through the IIS Manager. For more information about how to enable logging for virtual
servers, see the Exchange Server 2003 Help. For more information about troubleshooting
transport issues, see Microsoft Knowledge Base article 821910, "How to Troubleshoot for
Exchange Server 2003 Transport Issues," (http://go.microsoft.com/fwlink/?
LinkId=3052&kbid=821910).

Monitoring Outlook Web Access Servers

You can use the HTTP Monitoring Service (HTTPMon), a Windows Server Resource Kit tool,
to monitor Web sites and applications. HTTPMon provides reports about the availability and
response time of Web sites and applications. HTTPMon can also simultaneously check
several Web sites and applications and report the results to a log file in comma-separated
value (.csv) format or in the Windows Server 2003 event log.

You can install HTTPMon from the resource kit by running Setup.exe from the \apps\httpmon
folder of the resource kit. After you install HTTPMon, you must run HTTPMon Configuration
Manager to configure the service. HTTP Configuration Manager lets you configure global
 73

settings for your organization and add the Outlook Web Access servers you want to monitor.
You can use the Services MMC to start the HTTP Monitoring Service. After your tests start
running, you should review the .csv files for response codes, time taken by the sample to
return the text, and for the number of retry attempts made by HTTPMon. You can analyze this
data to detect problems with your Outlook Web Access servers, and you can review the
events logged by HTTPMon in Event Viewer.

HTTPMon is made up of three components:

 Real-time Sampling Service   This is a real-time monitoring service

 SQL Reporting Server   Gathers data from monitor servers and loads it into SQL Server

 Client Monitor   This component is a set of Web pages that displays the results from the
SQL Reporting Server database

You can then use Windows Management Instrumentation (WMI) or other technologies to
monitor the event log, or you can import the .csv file output to Microsoft Office Excel, SQL
Server, or another tool for more analysis. You can also use the SQL Server data and Client
Monitor to track your servers, and you can use the reporting features of SQL Server to
additionally analyze the data.

You can use HTTPMon to identify and troubleshoot issues with Outlook Web Access servers.
Make sure that you monitor Outlook Web Access regularly. Based on your organization's
requirements, you may want to consider monitoring your Outlook Web Access servers
weekly. You can increase or decrease the frequency of monitoring based on trend analysis of
your Outlook Web Access servers. For more information about installing and configuring
HTTPMon, see the Windows Server 2003 Resource Kit documentation.

Managing Mailboxes
Mailboxes are the delivery location for all incoming mail messages for a designated recipient.
A mailbox can contain messages, message attachments, folders, documents, and other files
such as calendar and contact objects. Information in a user's mailbox is stored in a mailbox
store database on an Exchange server. Mailboxes inherit many of their properties, such as
storage limits, from the mailbox store. You can create different mailbox stores for different
groups of users. For example, you may put mailboxes for your staff in one store and
mailboxes for executives in another store, and give the executives double the normal storage
limits by configuring the store instead of configuring the individual mailboxes. You must
actively manage the mailboxes in your organization to guarantee reliability and availability to
your users. Make sure that you manage mailbox limits for resource management of your
servers. For more information about managing mailboxes, see the Exchange Server 2003
Administration Guide (http://go.microsoft.com/fwlink/?LinkId=21769).
 74

Using Storage Limits to Manage Mailbox Limits

You can monitor the sizes of mailboxes by using the Mailboxes node in Exchange System
Manager. By using the limits settings on the Limits tab of a mailbox store, you can control the
maximum size of mailboxes in the mailbox store and control how deleted items are handled.
For an individual user, you can override the mailbox store's limits settings by using the
Active Directory® Users and Computers snap-in to configure limits settings for the user.
Table 2 defines the limits that can be set for a mailbox store. By default, no limits are set.

Table 2   Options on the Limits tab for a mailbox store

Option Description

Issue warning at (KB) When a user's mailbox exceeds the

specified size limit, the user receives an e-
mail alert message to delete messages from
the mailbox. By default, this option is not
selected.

Prevent send at (KB) When a user's mailbox exceeds the

specified size limit, the user receives an e-
mail alert message to delete messages from
the mailbox. Additionally, e-mail messages
cannot be sent until the mailbox size is
reduced below the specified limit. By default,
the option is not selected.

Prevent send and receive at (KB)
When a user's mailbox exceeds the
specified size limit, the user receives an e-
mail alert message to delete messages from
the mailbox. Additionally, e-mail messages
cannot be sent until the mailbox size is
reduced below the specified limit and
incoming e-mail messages are returned to
the sender with a non-delivery report (NDR).
The user still can receive system messages.

Warning message interval Use this drop-down list to schedule when

warning messages are generated. You can
select one of the standard maintenance
schedules, or click Customize to set up your
own schedule. This process is CPU-
intensive and disk-intensive and can slow
server performance. It is a good idea to
schedule maintenance of this type at off-
peak times.
 75

Option Description

Keep deleted items for (days)
You can designate the number of days that
deleted items (such as e-mail messages)
remain on the server before they are
removed permanently. You can type a
number from 0 to 24855. If you type 0,
deleted items are removed from the server
immediately. As long as deleted items
remain on the server, Outlook users can
retrieve them using Outlook's Recover
Deleted Items function. Setting a high value
for this option could affect your database
sizes on the hard disk.

Keep deleted mailboxes for (days)
You can designate the number of days that
deleted mailboxes remain on the server
before they are removed permanently. After
this value is set, you have the specified
number of days to recover mailboxes that
were deleted accidentally. You can type a
number from 0 to 24855. If you type 0,
deleted mailboxes are removed from the
server immediately. By default on a new
installation, this is set to 30.

Do not permanently delete mailboxes and
items until the store has been backed up
You can keep deleted mailboxes and items
on the server until a backup is performed.
After a backup is performed, mailboxes and
items are deleted, according to the settings
that you specified.

Using System Policies to Manage Mailbox Limits

You can create Exchange system policies to manage mailbox stores. A system policy is a
collection of configuration settings that you apply to one or more servers, mailbox stores, or
public folder stores. A mailbox store policy allows you to configure settings and apply that
policy to one or more mailbox stores on any server. You can use the System Policies node in
Exchange System Manager to create and apply policies.

You can apply a policy to a mailbox store only if you have permissions to modify that mailbox
store. If you are using a distributed administration model, with multiple administrative groups
that have separate administrators, each administrator will be able to interact only with the
mailbox stores in that administrator's own administrative group.
 76

Using Event Viewer to Manage Mailbox Limits

To view the events in the application log of Event Viewer when your mailboxes reach various
stages of storage limit warning, you can configure diagnostic logging on your server.
Configure the storage limits from the following location: MSExchangeIS/Mailbox/Storage
Limits. Note that you should not have diagnostic logging on at all times because this can
affect your server resources.

Using Mailbox Manager to Manage Mailbox Content

You can manage mailboxes by using Mailbox Manager. Mailbox Manager is a component that
uses a recipient policy that can be used to set age and size limits for messages on mailboxes
that match the policy filter. By using the Mailbox Manager settings, you can schedule when
the Mailbox Manager process runs on a server and whether the process generates a report.
When it runs, the Mailbox Manager processes messages that exceed limits defined in the
policy. For more information about Mailbox Manager, see the Exchange Server 2003
Administration Guide (http://go.microsoft.com/fwlink/?linkid=21769).

You can select when you want the mailbox management process to start on a particular
server, according to the rules defined by associated recipient policies. The recipient policies
determine which mailbox or mailboxes Mailbox Manager cleans. You can also customize the
mailbox management schedule to suit your organizational requirements. For example, you
can create a custom schedule that runs Mailbox Manager on Saturday at midnight.

When you schedule Mailbox Manager, you can designate a mailbox, contact, or distribution
group to receive Mailbox Manager reports. You can also select the type of report to be
generated. The report can include information such as when Mailbox Manager ran, which
mailbox recipient policy settings were applied, which mailboxes were processed, which
folders were processed, the number of messages that were moved or deleted, and the size of
messages that were moved or deleted.

Most of the Mailbox Manager settings are controlled through recipient policy. You can add an
additional tab named Mailbox Manager Settings to an already existing policy, or a new
policy can be created. For each recipient policy you create, you can define the objects that
this recipient policy will apply to (this is done through defining the policy Filter) and select
whether you want to delete messages based on age, size, or both. You can also choose to
notify clients that their mailboxes were cleaned. In the Properties of the server object, on the
Mailbox Manager tab, you can choose to have reports sent to an administrator and can
choose the Administrator's mailbox.

The action that occurs when Mailbox Manager processes a message depends on the setting
that you select when creating the policy. By default, only a report is generated. No additional
action is taken. In addition to the default setting, there are four other options for how Mailbox
Manager processes messages that exceed the specified limits. Table 3 describes these
Mailbox Manager options.
 77

Table 3   Mailbox Manager options

Option Description

Generate report only(default) No messages are moved or deleted, but an

administrator report is generated that
indicates which mailboxes contain items that
exceed the limits defined by the mailbox
recipient policy.

Move to Deleted Items folder
Messages are moved to the Deleted Items
folder in each client mailbox. Messages are
handled as if deleted by the client. Users can
remove them from the Deleted Items folder if
they want to.

Move to System Cleanup folders
A partial replica of the folder hierarchy of the
mailbox is created under a root folder named
System Cleanup. Affected messages are
moved to the appropriate subfolder of the
System Cleanup folder. This feature gives
users a way to recover recently deleted
items without losing information about the
original folder location of the items.

Delete immediately Messages are immediately deleted from

client view without being moved to either the
Deleted Items or System Cleanup folder.

You can use the same limits for every folder that the mailbox recipient policy applies to, or
you can set custom limits on a folder-by-folder basis. Each folder must be configured
individually if its limits differ from the default limits.

Managing the BadMail folder

Badmail are e-mail messages that are contained in the BadMail folder. The BadMail folder
contains undeliverable messages or NDRs (non-delivery reports) that cannot be returned to
the sender. If a message has reached the retry limit and cannot be delivered to the sender, a
copy of that message is stored in the BadMail folder. Failure to monitor the BadMail folder
may result in running out of disk space and causing the Microsoft Exchange Information Store
service to shut down. Excess messages in the BadMail folder may also indicate a security
breach.

By default, the BadMail folder is located in the virtual server's home directory. The default
location is \Exchsrvr\Mailroot\vsi #virtual server instance\badmail. Before Exchange
Server 2003 SP1, badmails were written to the BadMail folder until the hard disk became full
 78

or messages were deleted from hard disk manually. In Exchange Server 2003 SP1, badmails
are not written to the disk. However, if you want to continue to receive the badmails, you can
use Registry Editor to add two registry keys that will ensure that you continue to receive
badmail messages. For more information about the BadMail folder and badmail messages,
see Microsoft Knowledge Base article 555164, "Exchange 2003 Service Pack 1 stops the
BadMail folder from collecting bad messages" (http://go.microsoft.com/fwlink/?
LinkId=3052&kbid=555164).

In Registry Editor, you must add the following registry key under the folder:
HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\SMTPSVC\\Queuing

 MaxBadMailFolderSize   This is the maximum number, in kilobytes, that the system will

write badmail to each BadMail folder. This setting applies to all BadMail folders under the
various virtual server instances (VSIs) that you may have. When a BadMail folder
reaches the size limit, badmail will no longer be written. Using a value of -1 (0xffffffff
hexadecimal in regedit) will give you the same functionality as in pre-
Exchange 2003 SP1, that is, badmails grow unbounded. When the regkey is not set, the
default is 0: no badmail written.

 BadMailSyncPeriod (in minutes)   This registry key defines how frequently Exchange

Server monitors the system to see if badmails have been deleted. The server caches the
size of the BadMail folder for performance reasons and this cached size is used only
when a MaxBadMailFolderSize is specified. If regkey is not set, the default value of 12
hours is used.

Use Windows Explorer to examine the BadMail folder contents for undeliverable messages.
Many undelivered messages could indicate a network or Domain Name System (DNS)
problem. You can create policies for monitoring the BadMail folder and remove messages
after a specified time (such as deleting messages once a week). You can also use the
Badmail Deletion and Archiving tool to automatically delete or archive files in the Badmail
directory of specified SMTP virtual servers. Installing this tool ensures that the size of the
Badmail directory does not exceed specific size limits and eliminates the administrative
overhead of manually archiving or deleting these files. To download the Badmail tool, see the
Downloads for Exchange Server 2003 Web site (http://go.microsoft.com/fwlink/?
linkid=25097).

Managing the Postmaster Mailbox

The postmaster mailbox is an account that receives NDRs and sends delivery status reports
of messages to the sender. By default, Exchange Server 2003 creates the postmaster proxy
address and designates this address to the user who created the Exchange organization. If
you need multiple postmaster mailboxes, you can use event sinks to create additional
postmaster mailboxes.

Depending on your organization's requirements, you may want to change this default
assignment to avoid exposure of your administrator account to external users.
 79

Note:
Requests for Comments (RFC) 2822 defines a reserved address for the postmaster.
For more information about RFCs, see http://www.rfc-editor.org/rfc.html.

To designate a specific user's mailbox as the postmaster mailbox for any local SMTP domain
that is created, you can manually add the proxy postmaster@localdomainname to the user's
list of SMTP proxy addresses.

Managing the postmaster mailbox may involve the following high-level tasks:

 Depending on your organization's requirements, you may need to decide whether to:

 Associate a single e-mail account with the postmaster, such as your Help desk
mailbox account.
 Create a dedicated postmaster account that will be used when NDRs are sent.

 If you are creating a dedicated postmaster account, you will need to designate access to
the postmaster’s mailbox to the appropriate support staff. You can manage a dedicated
mailbox in the following ways:

 Create a dedicated account and log on as that account by using an Outlook profile,
and then respond to the account messages.

 Delegate Send As permissions on the account to the person who typically manages
the mailbox, and then add the mailbox to their Outlook profile.

 You should establish a regular schedule, such as a weekly schedule, for reviewing and
responding to the delivery reports in the mailbox. For example, you may want to respond
to messages in which the e-mail alias is incorrect and then notify the sender that they
must update their records. The schedule you establish should be based on your
organization’s requirements. Some organizations make this a daily task to try to reduce
the number of e-mail messages that are delivered to users who are no longer with the
company, while other companies make this a weekly or monthly maintenance task.

 Determine whether you want a copy of all NDRs to be sent to the postmaster account.

Conducting a Status Meeting and Status

Reports
Status meetings provide time to evaluate past problems, discuss current solutions, identify
trends in issues, and plan for the future of your IT environment. You should also create status
reports to help with capacity planning, service level agreement (SLA) reviews, and
performance analysis.
 80

Conducting Status Meetings

Although the format and style of status meetings can vary between organizations, consider
including the following discussions in your status meetings:

 Server and network status for the overall organization and segments

 SLA reviews

 Incident report reviews

 Risk analysis and evaluation

 Capacity, availability, and performance reviews

Creating Status Reports

Status reports are very important when monitoring an Exchange organization because they
provide an overview of past events and create data for comparison. You can create reports by
using recorded data with basic tools such as Excel or an in-house solution. Alternatively,
Microsoft Operations Manager (MOM) with Exchange Management Pack includes reporting
capability. Besides status reports, you should create incident reports. Incident reports can be
part of the trouble ticket system used to resolve problems, or they can be generated
independently whenever an incident occurs. Using incident reports helps evaluate common
and recurring problems to understand bottlenecks and weak areas. You can also use third-
party applications to generate status reports.

Exchange Server 2003 On-Demand Tasks

Microsoft® Exchange Server databases can grow over time and become fragmented, which
can cause performance issues that may affect users. You can identify discrepancies in
Exchange Server databases by using tools available in Exchange Server. You can also
examine the Queue Viewer and monitor the performance of your Exchange servers and
identify normal and abnormal trends. Typically, on-demand tasks are performed when errors
are reported by monitoring tools, or by users reporting issues to your Help desk.

You may need to perform the following on-demand maintenance tasks:

 Defragment mailbox and public folder stores   Exchange databases can become

fragmented over time which can cause performance problems. By defragmenting the
databases, you can reduce the file size and create contiguous storage space.
Defragment Exchange databases by using Exchange Server Database Utilities
(Eseutil.exe).

 Verify mailbox and public folder store integrity   You can resolve inconsistencies in
Exchange databases by verifying and repairing the integrity of the database using
 81

Information Store Integrity Checker (Isinteg.exe). You can also use the Eseutil.exe tool to
check database integrity.

 Examining queues   You can use Queue Viewer to examine queues. This activity lets
you identify normal and abnormal trends for messages that are visible in the queues.
Many messages backed up in the queue can indicate a security threat, a spam attack, or
a network performance issue.

 Configure Performance console   You can configure the System Monitor (Performance

Monitor in Microsoft Windows NT® 4.0) to monitor the performance of your Exchange
servers, so that you can establish what is normal and what changes you can make to
improve performance.

Online and Offline Defragmentation of

Exchange 2000 Server and Exchange
Server 2003 Databases
Exchange Server databases require defragmentation. Specifically, Exchange Server
database defragmentation refers to rearranging mailbox store and public folder store data to
fill database pages more efficiently, which eliminates unused storage space. There are two
types of Exchange database defragmentation: online and offline.

Online Defragmentation
Online defragmentation is one of several database-related processes that occur during
Exchange database maintenance. By default, Exchange servers automatically run Exchange
Server database maintenance between 01:00 (1:00 A.M.) and 05:00 (5:00 A.M.) local time,
every day. Online defragmentation occurs while the Exchange Server databases remain
online. Therefore, your e-mail users have complete access to mailbox data during the online
defragmentation process.

The online defragmentation process involves automatically detecting and deleting objects that
are no longer being used. This process provides more database space without actually
changing the file size of the databases that are being defragmented.

Note:
To increase the efficiency of defragmentation and backup processes, schedule your
maintenance processes and backup operations to run at different times. Running the
online backup after the online defragmentation has started will end the online
defragmentation process at that time.

You can schedule database defragmentation in two ways:

 To schedule database defragmentation for an individual database, use the Maintenance

interval option on the Database tab of a mailbox store or public folder store object.
 82

 To schedule database defragmentation for a collection of mailbox stores and public folder
stores, use the Maintenance interval option on the Database (Policy) tab of a mailbox
store or a public folder store policy.

For more information about how to create a mailbox store policy or public folder policy, see
"Create a Mailbox Store Policy" and "Create a Public Folder Store Policy" in Exchange 2000
Server or Exchange Server 2003 Help.

Offline Defragmentation
Offline defragmentation involves using Exchange Server Database Utilities (Eseutil.exe).
Eseutil is an Exchange Server tool that you can use to defragment, repair, and check the
integrity of Exchange Server databases.

By default, Eseutil is located in the <drive>:\<installation root>\exchsrvr\bin directory after

running Exchange 2000 Server or Exchange Server 2003 Setup (where <drive> is the drive
letter of the drive and <installation root> is the installation path where you installed Exchange
Server).

You can perform offline defragmentation only when your Exchange Server databases are
offline. Therefore, your e-mail users will not have access to mailbox data during the offline
defragmentation processes. The database has to be in the "clean shutdown" state for offline
defragmentation to run on it.

During the offline defragmentation process, Eseutil.exe creates a new database. It copies
only the in-use database records to the new database file, which results in a new compact
database file. An offline defragmentation is the only method that reduces the physical file size
of the databases. You should perform an offline defragmentation in the following situations:

 After performing a database repair (using the command Eseutil /p)

 After moving a significant amount of data from an Exchange Server database

 If instructed to do this when you are working with Microsoft Product Support Services, or
when troubleshooting a specific problem and the existing documentation calls for an
offline defragmentation.

Important:
You should consider an offline defragmentation only if many users are moved from an
Exchange Server database or after a database repair. Performing offline
defragmentation when it is not required could affect performance. To determine how
much space you will regain after the offline defragmentation of the database, check
event 1221 in the Exchange server’s Application log. You should also consider the
time factor when performing an offline defragmentation of the database because it is
a lengthy process.
 83

Important:
It is also important to note that the offline defragmentation requires about 110% of the
space of the original database to succeed. This is because the Eseutil tool actually
creates a new database file, in addition to the original database file. Both files have to
coexist on the disk. It is possible however, to redirect the temporary database file to a
different hard disk by using the Eseutil /t switch. Using this switch increases the time
required to complete the defragmentation process. You can also use a network disk.
However, using a network disk is not recommended because it significantly increases
the time required to complete the defragmentation process. Also, you are subject to
the risk of network availability issues.

When you use Eseutil.exe to defragment your Exchange Server databases, consider the
following:

 When you run Eseutil.exe in defragmentation mode (using the command Eseutil /d), you
can also include a /p switch. Including the additional /p switch during a defragmentation
operation preserves the original database being defragmented in case you need to revert
to this database. If the original database and the temporary databases are on different
drives during the offline defragmentation process, using the /p switch bypasses the need
to copy the defragmented database to the location of the original database. Then you
need to manually rename the newly created temporary database using the same
database name that the original database had and manually move the database to the
correct location using Windows Explorer.

 Because offline defragmentation actually creates the new database, database files, and
log file signatures, you should create new backups of Exchange Server 2003 databases
immediately after offline defragmentation. A new defragmented database file will have a
different database signature on it. Because the databases and transaction logs point to
each other based on signatures, all previous backups of this database are invalidated by
the offline defragmentation. Table 1 provides information about the modes of operation of
Eseutil.

Table 1   Modes of Eseutil operation

Mode of operation Task

Eseutil /d Performs an offline compaction of a

database.

Eseutil /r Performs soft recovery to bring a single

database into a consistent or clean
shutdown state.

Eseutil /g Verifies the integrity of a database.

Eseutil /m Generates formatted output of various

database file types.
 84

Mode of operation Task

Eseutil /p Repairs a corrupted or damaged database.

Eseutil /c Performs a hard recovery after a database

restore.

Eseutil /k Verifies the checksums of a database.

Eseutil /y Copies a database, streaming file, or log file.

For more information about defragmenting Exchange 2000 Server and Exchange

Server 2003 databases, see Microsoft Knowledge Base article 192185, "How to Defragment
with the Eseutil Utility (Eseutil.exe)," (http://go.microsoft.com/fwlink/?
LinkId=3052&kbid=192185).

For more information about defragmenting Exchange Server databases, see Microsoft
Knowledge Base article 328804, "How to defragment Exchange databases,"
(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328804).

You can also obtain information in the Microsoft Exchange Team Blog, "Is offline
defragmentation considered regular Exchange maintenance?"
(http://go.microsoft.com/fwlink/?linkid=35348).

Verify Mailbox and Public Folder Store Integrity

You will need to verify the Exchange store integrity in the following situations:

 An item count on a mailbox or public folder store is inconsistent. This may indicate that
some of the counters and pointers in your mailbox or public folder store may be
corrupted.

 You cannot move a mailbox. For example, if the Move Mailbox command or ExMerge
fails on a particular mailbox, the structure of the mailbox, or of a message inside the
mailbox, may be corrupted.

 The e-mail client crashes frequently. For example, Microsoft Office Outlook® crashes
repeatedly when a user tries to access a particular message or mailbox. Running a store
integrity check may identify the cause of the errors.

Isinteg
Isinteg is a command-line tool that searches an offline Exchange store for integrity
weaknesses. You can also repair issues that Isinteg detects. The Microsoft Exchange
Information Store service must be online when Isinteg is started
 85

By default, Isinteg is located in the <drive>:\<installation root>\exchsrvr\bin directory after

running Exchange Server 2000 or Exchange Server 2003 Setup (where <drive> is the drive
letter of the drive on which you installed Exchange Server).

The Isinteg tool performs the following tasks:

 Verifies whether the MSExchangeIS service is stopped, and then Isinteg does one of the
following tasks:

 If the MSExchangeIS service is stopped, Isinteg displays the following error

message: “Error: unable to get databases status from server." The reason could be
either an incorrect server name or networking problems.

 If the service is not stopped, Isinteg displays a list of databases to select from on that
server.

 Browses all the cross-reference tables for errors. Isinteg builds an Exchange database,
Refer.mdb, of reference counts before it browses the tables.

 Compares the counts found to the counts in the reference database. If Isinteg is running
with the -fix switch, these counts are updated to the true values, as determined by
Isinteg.

 Performs the named to ID or named properties cleanup check to remove unused

named properties.

Important:
Isinteg cannot resolve physical database problems. If the database is damaged on
the physical database page level (for example, because of hard disk problems, the
file-level antivirus software modified the database, and so on), you may need to use
the Eseutil tool. The database must be in the “clean shutdown” state for Isinteg to run
on it.

Verifying the Exchange Store Integrity

To view the command-line Help about Isinteg tool, type the following command line at a
command prompt:

<drive>:\<installation root>\exchsrvr\bin>isinteg /?

The syntax for using the Isinteg command-line tool is as follows:

isinteg -s ServerName [-fix] [-verbose] [-l LogFilename] -test TestName[[, TestName]...]

Use the information in Table 2 to determine which switch to use when you run the Isinteg tool.

Table 2   Isinteg switches

Switch Use the switch to

-fix Fix any inconsistencies in your database.

 86

At a minimum, you must specify -test Testname or -dump at the command line to be able to
proceed.

The steps to run the Isinteg command-line tool based on a specific criteria are as follows:

 To test the integrity of the Exchange store, at a command prompt, type:

<drive>:\<installation root>\exchsrvr\bin>isinteg -s ServerName -test alltests

For example, you can type c:\program files\exchsrvr\bin>isinteg -s servername -fix -test
alltests

 To fix inconsistencies and errors in the Exchange store, at a command prompt, type:

<drive>:\<installation root>\exchsrvr\bin>isinteg -s ServerName -fix

For more information about the Isinteg tool, see Microsoft Knowledge Base article 182081,
"Description of the Isinteg utility" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=182081).

For more information about the command-line parameters used for Isinteg tool, see Microsoft
Knowledge Base article 301460, "Exchange Command-Line Parameters for the Isinteg.exe
Tool" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=301460).

Checking the Queue Viewer

Queue Viewer is a tool that lets you maintain and administer your organization's messaging
queues and identify mail-flow issues. Exchange uses queues to hold messages as they are
being processed for routing and delivery. Queue Viewer is available on all SMTP virtual
servers, X.400 objects, and all installed Microsoft Exchange Connectors for Novell
GroupWise, Lotus Notes, and Lotus cc:Mail.

You must develop a queue baseline so that you can identify the difference between normal
behavior and abnormal behavior for your organization. Typically, on-demand use of Queue
Viewer is the result of a support call indicating that e-mail delivery is slow or a message has
not been delivered.

For more information about Queue Viewer, see the topic "Checking Message Paths" in the
topic "Daily Operations."

For more information about each queue, common causes of problems in each queue, and
how you can troubleshoot mail-flow issues, see Microsoft Knowledge Base article 823489,
"How to Use Queue Viewer to Troubleshoot Mail Flow Issues"
(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823489).

You can use Queue Viewer to check for the following:

 Messages that are queued for extended periods of time. Unless an Exchange 2003
server handles an extremely high volume of e-mail messages, the server will not typically
have queued messages for any extended duration. Having extended periods of queuing
 87

typically indicates a system issue that warrants your attention. Review your performance
metrics to see if some other performance issues are causing e-mail messages to queue.
If not, look for connectors or servers that are down or not functioning. SMTP protocol
logging might also help you discover the problem.

 Peaks in queued messages. Spikes in queued messages can occur when someone
sends:

 A message to a large distribution list.

 An extremely large message to many people.

 A message whose destination is across a slow network link.

These conditions are not cause for alarm. However, you must review the security of your
Exchange organization if either of the following conditions exists:

 A large volume of messages is queued to one recipient or e-mail address. A large volume
of messages queued to one recipient or e-mail address can be a symptom of a spam
attack on an e-mail loop or a denial-of-service (DoS) attack.

 A large volume of messages is queued to a specific server or domain. A large volume of

messages queued to a particular server or domain indicates that a server is down, a
service is stopped, a domain is unreachable, or a network disruption is preventing the
system from establishing a connection.

Guidelines for Configuring a Performance

Console
You can configure System Monitor to monitor the performance of your Exchange servers to
understand what system behavior is normal and what changes you can make to improve
Exchange performance.

You must be able to answer some basic questions about your system environment, including
the following:

 Number of messages received per user per day

 Number of messages that are downloaded

 Frequency with which users open folders

 Number of additional users who servers can support

 Peak delivery rate, the peak period during the day, and the peak day of the week

 Frequency of monthly or quarterly peaks, if any

You must create a Performance console that lets you see the entire system environment and
also register even minor changes in the performance of your servers. The guidelines for
creating a Performance console are as follows:
 88

 Create a Performance console with two charts that have two different sample times, such
as:

 900 seconds for a 24-hour view

 10 seconds to catch short-lived spikes

 Include a minimal set of counters in each console, such as:

 Processor(_Total)\% Processor Time

 Process(store)\% Processor Time

 MSExchangeIS\RPC Requests

 MSExchangeIS\RPC Operations/sec
 MSExchangeIS\RPC Averaged Latency

 PhysicalDisk(_Total)\Disk Transfers/sec

 PhysicalDisk(_Total)\Avg. Disk sec/Read

 PhysicalDisk(_Total)\Avg. Disk sec/Write

 SMTP Server\Local Queue Length

 SMTP Server\Messages Delivered/sec

 MSExchangeIS Mailbox\Local Delivery Rate

 MSExchangeIS Mailbox\Folder Opens/sec

 MSExchangeIS Mailbox\Message Opens/sec

 Examine your busiest server to gather information about why the server is so busy and to
understand what performance issues can be resolved when the server does not perform
as well as the other servers.

 Save reference log files in order to develop historical baseline data that will enable you to
see what changes have occurred so you can then deal with them in growth over time.

For more information about creating a performance baseline for your server, see
Troubleshooting Microsoft Exchange Server 2003 Performance
(http://go.microsoft.com/fwlink/?LinkId=22811).

Exchange Server 2003 Operations

Checklists
The Microsoft® Exchange Server 2003 Operations Checklists provide guidelines for IT
professionals to do disaster recovery tasks, and to perform the daily, weekly, and monthly
 89

maintenance tasks required to keep your Exchange server performing optimally. Use these
following checklists as is, or adapt them to suit your company's specific needs.

 Exchange Server 2003 – Disaster Recovery Preparation Checklist

 Exchange Server 2003 – Summary Checklist

 Exchange Server 2003 – Monthly Operations Checklist

 Exchange Server 2003 – Weekly Operations Checklist

 Exchange Server 2003 – Daily Operations Checklist

Exchange Server 2003 – Disaster Recovery

Preparation Checklist
The following checklist helps you prepare for disaster recovery. For step-by-step procedures
for backing up and restoring Microsoft® Exchange Server 2003 using the Windows Backup
tool, see the Exchange Server 2003 Disaster Recovery Operations Guide.

Checklist: Disaster Recovery Preparation

Prepared by:

Date:
 90

Completed Task

  Establish a backup and restore strategy.

Choose a backup strategy that lets you meet

your business requirements and service
level agreements. For example, allowed
downtime, allowed recovery time, and data
loss tolerance.

A backup strategy includes the following:

 Choose backup hardware

 Choose backup application

 Identify the things that you want to back

up

 Choose a strategy for recovering an

entire server. For example, restoring the
server, rebuilding the server, or using a
stand-by recovery server.

 Determine a backup schedule for each

category of data that you want to help
protect and the frequency of backup
types (normal, incremental, differential)
for each category
 91

Completed Task

  Ensure that you help protect the data you

need.

Identify the components that can be restored

by replicating data from other sources (for
example, data that is stored in Active
Directory® directory service), what
components must be restored from backups
(such as Exchange databases and
transaction log files), and what data can be
re-created (such as connector and server
configuration).

The data you help protect can include the

following:

 Windows® operating system data

 Domain controller data

 IIS metabase

 Exchange Server 2003 databases and

transaction logs

 Site Replication Service

 Exchange connector-specific data

 Certification authority (for servers

running certification services)

 Cluster configuration data (if you are

using back-end clustering)

 Individual mailboxes (optional)

 Unique dynamic data – preserve any

other data stored on your servers
specific to your organization that would
be difficult to re-create or restore. For
example, this data might include custom
scripts, Web forms for IIS, or any other
data that you want to help protect.
 92

Completed Task

  Implement practices that minimize the

effect of a disaster.

Consider implementing the following

measures to help prevent or minimize the
effect of a disaster.

 Have your software and firmware

updates available

 Have all software disks easily available

 Have a plan to monitor servers

proactively

 Maintain hardware records

 Maintain software records

 Implement fault tolerance in your

organization at the hardware or software
level. This would include using methods
like RAID, multi-path hardware solutions,
and clustering.

 Ensure that you have sufficient hard disk

capacity for your Exchange servers. You
should have sufficient space on your
hard disk to restore both the database
and the log files. For more information
about disk capacity planning, see the
Hard Disk Space Considerations section
in Best Practices for Configuring
Exchange Back-End Storage.

 Use high quality media

 Plan schedules for archiving your

backup media

 Archive the backup media in a secure

location, for example, a fire-proof safe or
at another location (offsite storage)

 Train your staff on disaster recovery

procedures

 Monitor the health of the Exchange

store. For example, monitor the event
log for the occurrence of 1221 events to
 93

Completed Task

  Schedule your maintenance processes

and backup operations to run at different
times.

This type of schedule increases the

efficiency of defragmentation and backup
processes.

  Ensure that the online maintenance

process is completed successfully.

For example:
Event: 1221

Source: MSExchangeIS Private

Type: Information

Category: General

Description: The database has nnn

megabytes of free space after online
defragmentation has terminated.

Event: 1221

Source: MSExchangeIS Public

Type: Information

Category: General

Description: The database has nnn

megabytes of free space after online
defragmentation has terminated.

  Practice restoring from backup in a test

environment.

Exchange Server 2003 – Summary

Checklist
This checklist provides you with a summary of Exchange Server 2003 Operations tasks on a
daily, weekly, and monthly basis. You can modify these checklists based on your
organization's requirements.
 94

Checklist: Summary
Prepared by:

Date:

Completed Daily

  Check of physical environmental

  Check backups

  Check CPU/Memory use

  Check disk use

  Examine message queues

  Examine event logs

  Check backups

  Check IIS performance

  Check Exchange Server database health

  Check MAPI client performance

  Check Queue Viewer

  Check message paths and mail flow

  Check Non-Exchange Server connectors

  Check security logs

  Update virus definitions and scan for viruses

  Verify that Exchange Server and required

Windows services have started correctly

Completed Weekly

  Create reports

  Complete incident reports

  Meet to discuss status

  Check IIS logs

 95

Completed Monthly

  Do capacity planning

  Perform hotfixes, service packs, update

rollups, and security updates

  Perform Disaster recovery test – testing one

backup a month to restore

Exchange Server 2003 – Monthly

Operations Checklist
Use these checklists to record monthly operations.

Checklist: Capacity Planning

Use this checklist for capacity planning.

Prepared by:

Date:

Completed Task

  Check capacity and performance against

service level agreement (SLA) requirements

  Review SLA requirements and capacity

figures from previous month

  Produce and implement upgrade path based

on projected growth from previous growth
data

   

Checklist: Hotfixes, Service Packs, Update

Rollups, and Security Updates
Use this checklist to update your systems with hotfixes, service packs, update rollups, and
security updates in your organization.
 96

Prepared by:

Date:

Completed Task

  Maintain a list of applied hotfixes, service

packs, update rollups, and security updates

  See if there are new hotfixes for Windows

Server

  See if there are service packs for Windows

Server

  See if there are updates to complementary

services such as IIS, Active Directory, and
DNS

  Apply updates uniformly across servers and

workstations in the organization

  Perform critical security updates as soon as

possible, based on company policy

   

Exchange Server 2003 – Weekly

Operations Checklist
Use these checklists to record weekly operations.

Checklist: Create Reports

Use this checklist to create status reports to help with capacity planning, service level
agreement (SLA) reviews, and performance analysis.

Prepared by:

Date:
 97

Completed Task

  Use daily data from event log and System

Monitor to create reports

  Report on disk usage

  Create reports on memory and CPU usage

  Generate uptime and availability reports

  Generate database and mailbox sizes

  Create capacity reports from messages sent

and client logons

  Create reports on queue use, size, and

growth

   

Checklist: Incident Reports

Use this checklist to create incident reports.

Prepared by:

Date:

Completed Task

  List the top generated, resolved, and

pending incidents

  Create solutions for unresolved incidents

  Update reports to include new trouble tickets

  Create a document depository for

troubleshooting guides and post mortems on
outages

   

Checklist: Antivirus Defense

Use this checklist to perform your antivirus defense
 98

Prepared by:

Date:

Completed Task

  Perform a virus scan on each computer -

exclude drives that are specifically for
Exchange (SMTP/Exchange
Databases/Logs, and so on)

   

Checklist: Status Meeting

Use this checklist to conduct weekly status meetings during which the following items will be
reviewed.

Prepared by:

Date:

Completed Task

  Server and network status for the overall

organization and segments

  Organizational performance and availability

  Overview reports, and incidents

  Risk analysis and evaluation including

upcoming changes

  Capacity, availability, and performance

reviews

  Service level agreement (SLA) performance

and compare items that have not met target
objectives

   
 99

Exchange Server 2003 – Daily Operations

Checklist
Use these checklists to record daily operations.

Checklist: Performing Physical Environmental

Checks
Use this checklist to ensure that physical environment checks are completed.

Prepared by:

Date:

Completed Task

  Verify that environmental conditions are

tracked and maintained.

  Check temperature and humidity to ensure

that environmental systems such as heating
and air conditioning settings are within
acceptable conditions, and that they function
within the hardware manufacturer's
specifications.

  Verify that physical security measures such

as locks, dongles, and access codes have
not been breached and that they function
correctly.

  Ensure that your physical network and

related hardware, such as routers, switches,
hubs, physical cables, and connectors are
operational.

   

Checklist: Check Backups

Complete this checklist to check backups.

Prepared by:
 100

Date:

Completed Task

  Ensure that the recommended minimum

backup strategy - a daily online backup - is
completed.

  Verify that the previous backup operation

completed.

  Analyze and respond to errors and warnings

during the backup operation.

  Follow the established procedure for tape

rotation, labeling, and storage.

  Verify that the transaction logs were

successfully purged (if your backup type is
purging logs).

  Make sure that backups complete under

service level agreements (SLA).

   

Checklist: Check CPU and Memory Use

Record the sampling time of each counter.

Prepared by:

Date:

Completed Task

  Examine % Processor Time performance

counter.

  Examine Available MBs performance

counter.

  Examine % Committed Bytes in Use

performance counter.

  Check against a performance baseline to

determine the health of a server.
 101

Completed Task

   

Counter Measured Value Time When Recorded

% Processor Time    

Available MBs    

% Committed Bytes in Use    

     

Checklist: Check Disk Use

Follow the checklist and record the drive letter, designation, and available disk space.

Prepared by:

Date:

Completed Task

  Create a list of all drives and label them in

three categories: drives with transaction
logs, drives with queues, and other drives.

  Check disks with transaction log files.

  Check disks with SMTP queues.

  Check other disks.

  Use server monitors to check free disk

space.

  Check performance on disks.

   
 102

Drive Letter Designation (drives Available Space MB Available % Free

with transaction logs,
drives with queues,
and other drives)

       

       

       

       

       

       

       

Checklist: Event Logs

Check event logs using the following checklist.

Prepared by:

Date:

Completed Task

  Filter application and system logs on the

Exchange server to see all errors.

Note:
This process can be time-
consuming.

  Filter application and system logs on the

Exchange server to see all warnings.

  Note repetitive warning and error logs.

  Respond to discovered failures and

problems.

   
 103

Checklist: Check IIS Logs and Performance

Complete this checklist to check IIS logs and performance, as well as the status of services
such as POP3 and IMAP. For more information about monitoring IIS logs and performance,
see Microsoft Windows Server 2003 Internet Information Services (IIS).

Prepared by:

Date:

Completed Task

  Examine event log and filter. IIS logs give

you information about your changes.

Note:
If you are a medium-size
organization, examine your event
logs weekly.

  Examine System Monitor for IIS

performance to examine the output of
performance counters. Examine the
following performance counters:

 Web Service counters to monitor the

World Wide Web Publishing Service
(WWW service).

 Web Service Cache counters to monitor

the WWW service cache.

 FTP Service counters to monitor the File

Transfer Protocol (FTP) service.

 Active Server Pages counters to monitor

applications that run as Active Server
Pages (ASPs).

   

Checklist: Exchange Database Health

Use this checklist for to verify health of your Exchange database.

Prepared by:

Date:
 104

Completed Task

  Check the number of transaction logs

generated since the last check. Is the
number increasing at the “usual” rate?

  Verify that databases are mounted.

  Make sure that public folder replication is up-

to-date.

  If full-text indexing is enabled, verify that

indexes are up-to-date.

  With test mailbox, verify the logon of each

database and the send/receive capabilities.

   

Checklist: MAPI Client Performance

Complete the checklist to verify MAPI client performance and server availability.

Prepared by:

Date:

Completed Task

  Examine System Monitor counters.

  Examine Event Viewer logs.

  Verify that a test account can log on to the

Exchange server and has send/receive
capabilities.

  Verify your Perfmon RPC counters against a

baseline - RPC average latency/RPC
requests/RPC operations.

   

Checklist: Check Queue Viewer

Follow the checklist and record the size of each queue.
 105

Prepared by:

Date:

Completed Task

  Check queues for each server in each

administrative group using Exchange
System Manager.

  Record queue size.

   

Queue Type Queue Size

   

   

   

Checklist: Message Paths and Mail Flow

Use this checklist to examine the message paths and mail flow in your organization.

Prepared by:

Date:

Completed Task

  Send messages between internal servers

using test accounts.

  Check and verify that messages deliver

successfully.

  Send outgoing messages to non-local

accounts.

  Check and verify that outgoing messages

deliver successfully. With the test account on
the external host, verify that mail comes in.
 106

Completed Task

  Send messages across any connectors to

Exchange 5.5 organizations, Lotus Notes,
and Novell GroupWise recipients.

  Verify successful message transfer across

connectors and routes.

  Run WinRoute weekly to ensure

connectivity.

   

Checklist: Exchange Connectors to Non-

Exchange Mail Platforms
Use the following checklist to monitor mail flow and directory synchronization.

Prepared by:

Date:

Completed Task

  Check DirSync: Examine The container

where Lotus Notes or GroupWise contacts
are synchronizing, to make sure that the
changes are coming across. Also, monitor
the application event log for errors/warnings,
as well as successful updates in both
directions.

  Check Lotus Notes connectors: For mail

flow, check the Queue Viewer in Exchange
System Manager (ESM). There are four
queues for the Lotus Notes connector, two
incoming and two outgoing. Examine the
Application log for errors/warnings.
 107

Completed Task

  Check Novell GroupWise connectors: For

mail flow, check the Queue Viewer in
Exchange System Manager (ESM). There
are four queues for the GroupWise
connector, two incoming and two outgoing.
Examine the Application log for
errors/warnings.

  Ensure that the connector services are

started.

   

Checklist: Security Logs

To effectively correct known and discovered security issues, complete the following checklist.

Prepared by:

Date:

Completed Task

  View the security event log on Event Viewer

and match security changes to known,
authorized configuration changes.

  Investigate unauthorized security changes

discovered in security event log.

  Check security news for latest virus, worm,

and vulnerabilities.

  Update and fix discovered security problems

and vulnerabilities.

  Verify that SMTP does not relay

anonymously - or lock down to specific
servers that require functionality.

  Verify that the Message Tracking Log does

not have the Everyone group listed in the
ACL permission -(you can also do this task
weekly).
 108

Completed Task

  Verify that SSL is functioning for configured

secure channels.

  Update virus signatures daily.

   

Copyright
The information contained in this document represents the current view of Microsoft
Corporation on the issues discussed as of the date of publication. Because Microsoft must
respond to changing market conditions, it should not be interpreted to be a commitment on
the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information
presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO

WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS
DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in or
introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express
written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you
any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted in examples herein are fictitious. No
association with any real company, organization, product, domain name, e-mail address,
logo, person, place, or event is intended or should be inferred.

© 2006 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, ActiveSync,
ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN, MSN,
Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile,
Windows NT, and Windows Server System are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.

109