Export (0) Print
Expand All

Exchange Server 2003 Scheduled Maintenance Tasks

 

Topic Last Modified: 2004-10-15

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

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 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.

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.

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:

  • 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.
importantImportant:
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).

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 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).

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).

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.

Table 1   Types of protocol logs

File Format Description

World Wide Web Consortium (W3C) Extended Log

Writes the log in ASCII text. Fields are 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) Log

Writes the log in ASCII text following the IIS log file format. Fields are tab-delimited, and each entry is written on a new line.

noteNote:
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).

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 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.

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).

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.

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.

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.

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.

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.

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.

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 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).

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.

noteNote:
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.

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.

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

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.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft