Export (0) Print
Expand All

Exchange Server 2003 Daily Operations

 

Topic Last Modified: 2006-10-23

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

  • 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

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.

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

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

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

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

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.

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:

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

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

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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

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

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

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.

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.

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 alerts. For example, you can configure an alert to notify you when the MSExchangeIS Mailbox object’s Send Queue Size counter exceeds 25 messages.

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

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

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.

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.

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.

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.

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.

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.

Queue Viewer has the following options:

  • Disabling outgoing mail

  • Settings

  • Finding messages

  • Viewing additional information

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

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.

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.

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.

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.

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

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.

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

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

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

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.

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

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

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

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

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

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.

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.

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.

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

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

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)

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

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.

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.

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.

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.

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 Bytes

Monitor this counter to ensure that this 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.

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

The following security measures are discussed in this section:

  • Exchange Server 2003 updates management

  • Antivirus measures

  • Anti-spam measures

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

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.

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

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.

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

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.

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.

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

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

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

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

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

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

Community Additions

ADD
Show:
© 2014 Microsoft