Overview of the Microsoft Exchange Server Analyzer Tool

Topic Last Modified: 2005-07-08

The Microsoft® Exchange Server Best Practices Analyzer Tool is a diagnostic tool that performs the following functions:

  • It gathers configuration information from a Microsoft Exchange Server organization.

  • It performs specific tests on the Exchange Server organization.

  • It reports the findings from the tests.

You can use the Exchange Server Best Practices Analyzer to perform the following tasks:

  • It proactively verifies that the configuration is set according to recommended best practices.

  • It reports all settings that are different from the default settings.

  • It reports recent changes in the Exchange Server organization. This functionality helps you diagnose problems that are caused by changes in the Exchange Server organization.

  • It helps you identify the source of problems in unhealthy Exchange Server organizations.

  • It compares a set of servers to a baseline configuration, and it reports all differences in configuration.

Note:
The Exchange Server Best Practices Analyzer can report recent changes only for configuration objects that include a last modified time property.

The Exchange Server Best Practices Analyzer uses a configuration file to determine what information to gather from the Exchange Server organization. It compares the data that it gathers to a set of predefined rules for Exchange Server settings and configurations. It then reports issues.

For every issue, the Exchange Server Best Practices Analyzer provides three kinds of data:

  • It reports what it found in the Exchange Server organization that it scanned.

  • It provides a recommended configuration.

  • It provides links to more detailed information about the issue and related topics.

We welcome your comments, suggestions and feedback on the Exchange Server Best Practices Analyzer. You can send us your feedback a number of ways:

  • Microsoft public newsgroups Members of the Exchange Server Best Practices Analyzer Tool development team frequently monitor the microsoft.public.exchange.tools newsgroup at news.microsoft.com. For details about how to participate in this and other Microsoft newsgroups, see the Microsoft Exchange Server Best Practices Analyzer Tool Web site (http://go.microsoft.com/fwlink/?LinkId=33938) and the Microsoft Product Support Newsgroups Web site (http://go.microsoft.com/fwlink/?LinkId=50219).

  • Exchange Server Best Practices Analyzer documentation feedback If you have any comments, questions or feedback on any of the documentation and articles included with the Exchange Server Best Practices Analyzer, please send your feedback to exbpadoc@microsoft.com.


Installing

Installing |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool >

Topic Last Modified: 2006-02-08

To install the Microsoft® Exchange Server Best Practices Analyzer Tool, run the Microsoft Installer file, ExBPA.msi, on the computer where you will run the tool. The installer will create a directory named ExBPA, located by default at <system drive>\Program Files\, and will copy the required files to this new directory.

Choosing a Computer for Installation

The recommended computer on which to install the Exchange Server Best Practices Analyzer is a dedicated management station. For more information about how to install and use a dedicated management station, see the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?linkid=21769).

To install the tool on a computer that is outside the Exchange organization you need to explicitly set the user names and passwords for logging on to the Active Directory® directory service and the Exchange servers. For more information about how to set the credentials for the user account under which the scan will run, see Permissions.

You can also install the tool on an Exchange server. The tool can run on an Exchange server; however, it will consume a large amount of system resources, most notably CPU and RAM. Therefore, it is recommended that you install the tool on a separate computer. If you install the tool on an Exchange server, it is recommended that you scan only that Exchange server.

Checking for Updates

When you start the Exchange Server Best Practices Analyzer, it will determine whether there is a new file with best practices rules available from www.microsoft.com. If there is a new version, you can download the new file. You must be logged on to the computer as an administrator to download the file. If you choose not to download the new file, or if the tool cannot access the Internet, it will try to use the copy of the file that is on the computer where you are running the tool.

Note:
If you require proxy authentication to access the Internet, the tool will not be able to access the new version of the configuration file for you to download. However, you can manually copy the file from www.microsoft.com to your local computer.
To manually copy the new version of the configuration file

  1. In the directory where the tool is installed, rename the existing ExBPA.Config.xml file.

  2. Navigate to http://go.microsoft.com/fwlink/?LinkId=34290 in your Web browser.

  3. Download the self-extracting package and extract the new files to the directory where the tool is installed (typically C:\Program Files\ExBPA).

See Also

Concepts

Effect of the Tool on Exchange Performance
Permissions

Other Resources

Setting Up the Scan

© 2007 Microsoft Corporation. All rights reserved.


Prerequisites for Running the Tool
Overview of the Microsoft Exchange Server Analyzer Tool >

Topic Last Modified: 2005-07-08

The computers in your Exchange organization must meet several prerequisites before you can correctly run the Microsoft® Exchange Server Best Practices Analyzer Tool. If these requirements are not met, the tool will still run in many cases, but it might not run with full functionality, or it might run at a decreased performance level.

The topics in this section include information about the required permissions for running Exchange Server Best Practices Analyzer, as well as all other prerequisites for the Exchange organization and for the computer that is running the tool. The Other Prerequisites topic also lists the supported environments for running the tool.

In This Section

Permissions

Other Prerequisites for the Tool


Permissions |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool > Prerequisites for Running the Tool >

Topic Last Modified: 2005-07-08

The Microsoft® Exchange Server Best Practices Analyzer Tool can only access the Active Directory® directory service and the Exchange servers if you run the tool using credentials that have all the required permissions.

Permissions

To successfully run the Exchange Server Best Practices Analyzer, you must have the following permissions:

  • Domain Administrator, or a member of the Builtin\Administrators group on the Active Directory server, for enumerating Active Directory information and calling the Microsoft Windows® Management Instrumentation (WMI) providers on domain controller and global catalog servers.

  • Member of Local Administrators group on each Exchange server for calling the WMI providers and accessing the registry and metabase.

  • Delegated at least Exchange View Only Permissions on the Exchange organization.

If you log on to the computer on which you will run the Exchange Server Best Practices Analyzer with an account that does not have sufficient permissions, you have two options:

  1. Use the runas command to open a Command Prompt window that will run under an account that does have sufficient permissions, and then start the tool from this window. The syntax for this is the following:

    runas /netonly /user:<domain>\<username> exbpa.exe

  2. Set the credentials for the accounts you will use on the Connect to Active Directory page in the tool. Click Show advanced login options to expand the options. You can enter two accounts, one for connecting to Active Directory, and one for connecting to the Exchange servers. If you do not specify one or the other of these accounts, the account under which the tool is running will be used.

See Also

Concepts

Other Prerequisites for the Tool

© 2007 Microsoft Corporation. All rights reserved.


Other Prerequisites for the Tool

Other Prerequisites for the Tool |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool > Prerequisites for Running the Tool >

Topic Last Modified: 2007-05-16

In addition to running Microsoft® Exchange Server Best Practices Analyzer Tool with an account that has the required permissions on Active Directory® directory service, and an account that has the required permissions on the Exchange servers, you need to check some additional prerequisites to run the tool successfully.

Prerequisites

For Exchange Server Best Practices Analyzer to run correctly, the following must be true:

  • .NET Framework 1.1 must be installed on the computer on which Exchange Server Best Practices Analyzer will run.

  • Internet Information Services (IIS) Common Files (or Common HTTP Features for Windows Vista™) must be installed on the computer on which Exchange Server Best Practices Analyzer will run, to allow remote metabase access.

    Note:
    If Internet Information Services, Internet Information Services Admin, or Exchange System Manager are installed, Internet Information Services Common Files will be installed automatically.
  • The computer on which Exchange Server Best Practices Analyzer will run must have at least 256 megabytes (MB) of random access memory (RAM). This amount of memory is sufficient for scanning up to 50 Exchange servers. For each addition of up to 50 servers in the Exchange organization, you will need an additional 256 MB of RAM on the computer that is running the tool. For example, if you have between 50 and 100 Exchange servers in your organization, you must have at least 512 MB of RAM on the computer that is running the tool. If you have between 100 and 150 Exchange servers in your organization, you must have at least 768 MB of RAM on the computer that is running the tool.

  • For each Exchange server in the organization that you will scan, you must have at least 2 MB of disk space on the computer on which the Exchange Server Best Practices Analyzer will run.

  • Active Directory must be installed in the topology, on either Microsoft Windows 2000 Server or Windows Server™ 2003.

  • At least one Exchange 2003 or Exchange 2000 server must be installed within Active Directory.

  • Remote Registry (RemoteRegistry) service must be running on both the Active Directory server and the Exchange servers.

  • Windows Management Instrumentation (WMI) (winmgmt) service must be running on both the Active Directory server and the Exchange servers.

  • Exchange Management (MSExchangeMGMT) service must be running on all Exchange servers that are Exchange 2000 Server or later versions.

  • The user who is logged on and running Exchange Server Best Practices Analyzer must have read/write permission to the folder from which the tool runs.

  • To collect Host Bus Adapter (HBA) information, an HBA API-compliant driver and remoting service (such as Emulex's HBAnywhere service) must be installed on any server from which you want to collect HBA information. Additionally, the HBA API Managed Object Format (MOF) installer must be run on both the computer on which the Exchange Server Best Practices Analyzer will run and the target server where the HBA is installed. If an HBA API-compliant driver and remoting service are not installed, Exchange Server Best Practices Analyzer will run, but will not collect HBA information.

Supported Environments

Exchange Server Best Practices Analyzer can be run in the following environments:

  • Exchange Server 5.5 on Windows 2000 Server SP3 and later versions

Note:
The Exchange Server 5.5 server must be part of a mixed-mode Exchange organization, represented in Active Directory.
  • Exchange 2000 Server (all service packs) on Windows 2000 Server SP3 and later versions

Note:
Neither Windows 2000 Server nor Exchange 2000 Server support extensive WMI providers. Data collection and analysis may be limited.
  • Exchange 2003 Server (all service packs) on Windows 2000 Server SP3 and later versions

Note:
Windows 2000 Server does not support extensive WMI providers. Data collection and analysis may be limited.
  • Exchange Server 2003 (all service packs) on Windows Server 2003

  • Exchange Server 2007 on Windows Server 2003

See Also

Concepts

Permissions

© 2007 Microsoft Corporation. All rights reserved.


Scanning the Exchange Organization
Overview of the Microsoft Exchange Server Analyzer Tool >

Topic Last Modified: 2005-07-08

The Microsoft® Exchange Server Best Practices Analyzer Tool scans the computers in the Exchange organization that are within the scope that you select. It compares configuration settings to the set of recommended best practices, and reports results.

While the scanning is in progress, the progress bar updates dynamically, displaying the percent of the entire scan that is completed. The percentage is based on the amount of data to collect for the particular type of scan, and the number of servers within the scope of the scan.

The Estimated Time Remaining updates dynamically, and is recalculated every 60 seconds. The Exchange Server Best Practices Analyzer is multi-threaded, so that it can scan more than one Exchange server at a time. The Exchange Server Best Practices Analyzer scans computers from up to 10 administrative groups at the same time, and scans up to 50 Exchange servers simultaneously. Additional servers are queued and scanned as others finish.

The Server scanning details window shows the state of each server selected for scanning. Servers can be in one of three states: Pending, In Progress, or Completed. If a server is in the In Progress state, a progress bar displays its percent complete. After a server is in the Completed state, an icon will indicate if the Exchange Server Best Practices Analyzer was able to access the server. A green check mark icon indicates that the Exchange Server Best Practices Analyzer was able to access the server and did not fail or exceed time-out thresholds during the scan. A yellow warning icon indicates that the Exchange Server Best Practices Analyzer was able to access the server, but the Exchange Server Best Practices Analyzer either failed or exceeded a time-out threshold during the scan. A red X icon indicates that the Exchange Server Best Practices Analyzer was not able to access the server and the server was not scanned.

In addition to gathering data from the Exchange servers, the Exchange Server Best Practices Analyzer must gather data from the Active Directory® directory service. The progress of gathering data from Active Directory is shown as part of the progress bar and the Estimated Time Remaining at the top of the page, but not in the Server scanning details window. Therefore, the overall status of the scan may be progressing even if all the Exchange servers are in Pending or Completed states.

After the Exchange Server Best Practices Analyzer completes scanning all the servers selected, you can open the View Best Practices Report page.

In This Section

Setting Up the Scan

Network and Permissions Check

Configuring


Setting Up the Scan

Setting Up the Scan |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool > Scanning the Exchange Organization >

Topic Last Modified: 2005-07-08

When you start the Microsoft® Exchange Server Best Practices Analyzer Tool, you must set the parameters for the scan. First, you must choose if you want to download the latest update to the best practices rules. For more information about checking for updates and downloading the latest update file, see Installing.

Next, you must select an action. On the Welcome page, choose Select options for a new scan or Select a Best Practices report to view. If you choose to view an existing report, you can select a file from the list of output files that are stored locally. You can also import an output file from another location, instead of choosing an output file that is stored locally. After you have chosen an output file, you can view the report from that file. For more information about reports, see Understanding the Tool Output.

If you choose Select options for a new scan, you must connect to the Active Directory® directory service and run a new scan. By default, the Exchange Server Best Practices Analyzer detects the closest Active Directory server. You can connect to this server, or you can connect to a different Active Directory server by typing in the name of that server.

The Exchange Server Best Practices Analyzer uses the account under which the tool is running by default. To use different accounts to log on to Active Directory or to log on to the Exchange servers, click Show advanced login options to expand the options. In the upper part of the expanded window, you enter account credentials to log on to Active Directory. In the lower part of the expanded window, you enter account credentials to log on to the Exchange servers.

You can use the same account to log on to Active Directory and to log on to the Exchange servers, or you can use different accounts to log on to Active Directory and to log on to the Exchange servers. If you leave the upper part or the lower part of the expanded window blank, the Exchange Server Best Practices Analyzer logs on with the account under which the Exchange Server Best Practices Analyzer is running.

See Also

Concepts

Installing
Permissions
Configuring

Other Resources

Understanding the Tool Output
Network and Permissions Check

© 2007 Microsoft Corporation. All rights reserved.


Network and Permissions Check

Network and Permissions Check |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool > Scanning the Exchange Organization >

Topic Last Modified: 2005-07-08

Before beginning the scan, the Microsoft® Exchange Server Best Practices Analyzer Tool will perform a network and permissions check, making sure that the account credentials specified are valid, and that the tool can connect to the Active Directory® directory service. If either of these checks fails, you will return to the Connect to Active Directory page, where you can re-enter both the name of the server on which Active Directory is running, and the credentials for logging on to Active Directory and Exchange servers.

See Also

Concepts

Permissions
Configuring

Other Resources

Setting Up the Scan

© 2007 Microsoft Corporation. All rights reserved.


Configuring

Configuring |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool > Scanning the Exchange Organization >

Topic Last Modified: 2006-10-10

Before you run the scan, you must perform the following final steps:

  1. Set a label for the scan.

  2. Set the scope.

  3. Set the type of scan.

  4. Set the network speed.

After you specify the label, the scope, the type of scan, and the network speed, the Microsoft® Exchange Server Best Practices Analyzer Tool starts the scan.

Setting the Label for the Scan

To set a label for the scan, on the Start a New Best Practices Scan page, in the Enter an identifying label for the scan box, enter a unique label. If you later choose to view an existing report, you can identify the reports by the label that you enter in the Enter an identifying label for the scan box.

You can view an existing report in two ways:

  • On the Welcome page, choose Select a Best Practices report to view.

  • In the left navigation pane in the Exchange Server Best Practices Analyzer window, choose Select a scan to view.

Setting the Scope of the Scan

To specify the scope of the scan, on the Start a New Best Practices Scan page, select the servers or administrative groups that you want to scan.

You can choose from three scopes:

  • You can select the whole Exchange Server organization.

  • You can select one or more administrative groups.

  • You can select one or more servers from any administrative group in the Exchange Server organization.

Choosing the Type of Scan

Next, you choose the type of scan. You can choose from three types of scans:

  • Health Check

  • Health/Performance Check

  • Connectivity Test

  • Baseline

The Health Check scan performs a full scan. It checks for errors, warnings, non-default configurations, recent changes, and other configuration information. You should run a Health Check scan if you want to check the health of your Exchange Server organization, or if you want to troubleshoot a particular problem.

The Health/Performance Check scan performs the Health Check scan then proceeds to sample a range of Exchange Server performance counters over a two hour period of time.

The Connectivity Test scan tests network connections and permissions on each Exchange Server that is specified in the scope. You should run a Connectivity Test scan if you suspect a problem with permissions access or if you have firewalls in the topology. If the Connectivity Test is successful, you can run a Health Check scan.

The Connectivity Test scan runs very quickly. The Exchange Server Best Practices Analyzer queries one registry parameter and two Microsoft Windows® Management Instrumentation (WMI) classes. The first WMI query validates WMI repository access. The second WMI query queries the Active Directory® directory service servers that are used by Exchange Server. After scanning all Exchange Servers that are specified in the scope, the Exchange Server Best Practices Analyzer tries to validate network connectivity and permissions on Active Directory servers that are used by Exchange Server.

The Baseline scan performs the following tasks:

  • It selects properties.

  • It sets baseline values for those properties.

  • It then selects servers on which to compare those properties.

The Baseline scan checks for deviations from the baseline values that you set. The Baseline scan report identifies as baseline mismatches all properties on the selected servers whose values are different from the source values of the selected properties.

To run a Baseline scan

  1. On the Start a New Best Practices Scan page, on the Select the type of scan to perform menu, select Baseline, and then click Baseline Options.

  2. On the Baseline Options menu, select an existing scan or type a new label.

  3. Click the Source values arrow to expand the list of baseline properties.

    • These properties are the properties that the ExBPA.config.xml file gathers. Choose which properties to compare in the Baseline scan by clearing or setting the check boxes. The values of the properties are the default values from the ExBPA.config.xml file. Set these values in the text boxes.

  4. Click the Test objects arrow to expand the list of servers to scan.

  5. Select all servers that you want to scan for baseline mismatches.

Setting Network Speed

After you have selected the type of scan, you set the network speed. To set the network speed, select one of the four options:

  • Fast LAN

  • LAN

  • Fast WAN

  • WAN

You use the network speed setting to estimate the time that is required to complete the scan. You also use the network speed setting to set the time-out value.

During the scan, the Exchange Server Best Practices Analyzer waits for a response from a server for a specified time. If it does not receive a response in the specified time-out, the Exchange Server Best Practices Analyzer moves on to complete the scan, instead of continuing to wait. On slower networks, this specified time-out is longer to account for longer network latencies. It is recommended that you select the slowest link in your topology for this parameter so that the Exchange Server Best Practices Analyzer does not time out too quickly.

Running the Scan

After you have set all the options for a scan, you can choose either Start scanning or Schedule a Scan. If you choose Start scanning, the Exchange Server Best Practices Analyzer starts scanning the Exchange organization immediately. For more information, see Scanning the Exchange Organization.

If you choose Schedule a Scan, you see the Schedule a Scan page. To schedule a scan, you must first enter the required security credentials and select the Enable scan scheduling box. For more information on entering the required security credentials, see Setting Up the Scan.

Next, you set the start time. The start time is the day and time that the first scheduled scan will run.

Finally, you must set the frequency. The frequency is how often scheduled scans will run. To close the Exchange Server Best Practices Analyzer, click Exit this tool. The Exchange Server Best Practices Analyzer does not have to be running for the scheduled scan to run. If you exit the Exchange Server Best Practices Analyzer, the scheduled scan runs in the background at the specified date and time. To view the report from a scheduled scan, you must restart the Exchange Server Best Practices Analyzer.

See Also

Concepts

Types of Output Information

Other Resources

Scanning the Exchange Organization

© 2007 Microsoft Corporation. All rights reserved.


Advanced Configuration
Overview of the Microsoft Exchange Server Analyzer Tool > Scanning the Exchange Organization >

Topic Last Modified: 2006-10-26

The Microsoft® Exchange Server Analyzer tool has the following configurable registry parameters:

Location | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
Value | OpenRelayTest
Type | REG_DWORD
Description | Set to 0x0 if you do not want the Best Practices Analyzer to test each SMTP server for open relay capabilities. If this parameter is missing, the Best Practices Analyzer will default to 0x1.

Location | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
Value | OpenRelayTestSender
Type | REG_SZ
Description | Set this to the SMTP address that you want to use for the MAIL FROM: address when performing an open relay test. If this parameter is missing, the Best Practices Analyzer will default to 'ExBPA-OpenRelayTest@Fabrikam.com'.

Location | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
Value | TopoCreateTimeoutSecs
Type | REG_SZ
Description | Set this to the SMTP address that you want to use for the RCPT TO: address when performing an open relay test. If this parameter is missing, the Best Practices Analyzer will default to 'ExBPA-OpenRelayTest@Fabrikam.com'.

Location | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
Value | SMTPTest
Type | REG_DWORD
Description | Set to 0x0 if you do not want the Best Practices Analyzer to submit a test message to each SMTP server included in the scan. If this parameter is missing, the Best Practices Analyzer will default to 0x1.

Location | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
Value | SMTPTestSender
Type | REG_SZ
Description | Set this to the SMTP address that you want to use for the MAIL FROM: address when performing the SMTP mail acceptance test. If this parameter is missing, the Best Practices Analyzer will default to 'ExBPA-MailAcceptTest@Fabrikam.com'.

Location | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
Value | T SMTPTestRecipient
Type | REG_SZ
Description | Set this to the SMTP address that you want to use for the RCPT TO: address when performing the SMTP mail acceptance test. If this parameter is missing, the Best Practices Analyzer will default to the postmaster account as defined by the SMTP service.


Understanding the Tool Output
Overview of the Microsoft Exchange Server Analyzer Tool >

Topic Last Modified: 2006-02-08

The Microsoft® Exchange Server Best Practices Analyzer Tool report displays the analysis of the data gathered in a scan of the Exchange organization. You can select from three types of reports, List Reports, Tree Reports, and Other Reports.

  • List Reports include:

    • Critical Issues

    • All Issues

    • Non-Default Settings

    • Recent Changes

    • Baseline

    • Informational Items

  • Tree Reports include:

    • Detailed View

    • Summary View

  • Other Reports

    • Hidden Items

    • Run-Time Log

List Reports

The default view is the Critical Issues list. This Critical Issues list displays only the errors that were found. Errors are critical issues that immediately affect Exchange Server performance and availability. The All Issues list displays errors, warnings, and best practices violations. The Non-Default Settings list displays configuration changes made to the server since the installation of the Exchange Server product. The Recent Changes list displays configuration changes made to the server within past five days. This includes the installation of service packs and other updates. The Baseline list displays configuration discrepancies between nodes in a cluster.

Tree Reports

The Detailed View displays all configuration settings that have been collected by the Exchange Server Analyzer Tool. The Summary View displays a hierarchical representation of all issues found in the Exchange environment.

Other Reports

The Hidden Items report displays the issues that the Exchange Administrator has chosen to mask from the other Exchange Server Analyzer reports. Items in this list can be included in the other reports if un-masked. The Run-Time Log report displays collection milestone information and any errors returned during the collection process.

In the Critical Issues list, All Issues list, and Non-Default Settings list, you can click any error or warning issue to see an explanation. You can then click Tell me more about this issue and how to resolve it to get more detailed information.

Note:
The output data XML file and a log file of the scan are located at <system drive>\Documents and Settings\<user>\Application Data\Microsoft\ExBPA.

In This Section

Types of Output Information

Resolving and Hiding Issues

Viewing a Previous Report


Types of Output Information

Types of Output Information |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool > Understanding the Tool Output >

Topic Last Modified: 2006-09-29

The Microsoft® Exchange Server Best Practices Analyzer Tool report displays six types of information:

  • Error

  • Warning

  • Non-default configuration

  • Recent change

  • Baseline mismatch

  • Best practice

  • Information

Error

An error indicates a critical issue that requires a change for resolution. For example, an instance of a server that is down or a server that is unreachable is an error.

Errors appear in the following reports:

  • Critical Issues list

  • Full Issues List

  • Detailed View List

  • Detailed View—Full Issues List

If you disable an error, the Exchange Server Best Practices Analyzer displays the error on the Disabled Issues List.

The Exchange Server Best Practices Analyzer indicates an error with a red X (Figure 1).

Figure 1 Error icon

Icon representing error status

Warning

A warning indicates an issue that is not a recommended best practice. The issue might require a change for resolution, or it might be a known issue that does not require a change in your Exchange Server organization. For example, a service that is not started on a server is a warning.

Warnings appear in the following reports:

  • Full Issues List

  • Detailed View List

  • Detailed View—Full Issues List

If you disable a warning, the Exchange Server Best Practices Analyzer displays the warning on the Disabled Issues List.

The Exchange Server Best Practices Analyzer indicates a warning with a yellow warning symbol (Figure 2).

Figure 2 Warning icon

Warning icon yellow triangle and exclamation point

Non-default configuration

A non-default configuration indicates a setting that has been changed from the default value. If the Exchange Server Best Practices Analyzer determines that a non-default configuration is an error or a warning, the Exchange Server Best Practices Analyzer identifies the non-default configuration with the appropriate error symbol or warning symbol elsewhere in the report, in addition to identifying it as a non-default configuration.

Non-default configurations appear in the following reports:

  • Full Issues List

  • Detailed View List

  • Detailed View—Full Issues List

If you disable a non-default configuration, the Exchange Server Best Practices Analyzer displays the non-default configuration on the Disabled Issues List.

The Exchange Server Best Practices Analyzer indicates non-default configuration with the symbol of a pointer to a document (Figure 3).

Figure 3 Non-default configuration icon

Icon for non-default properties

Recent change

A recent change indicates a setting that has changed in the last 5 days. The Exchange Server Best Practices Analyzer can identify as recent changes only those settings that have a last modified time property. If the Exchange Server Best Practices Analyzer determines that a recent change setting is an error, a warning, or a non-default configuration, the Exchange Server Best Practices Analyzer identifies the recent change with the appropriate error symbol, warning symbol, or non-default configuration symbol elsewhere in the report, in addition to identifying it as a recent change.

Recent changes appear in the following reports:

  • Full Issues List

  • Detailed View List

  • Detailed View—Full Issues List

If you disable a recent change, the Exchange Server Best Practices Analyzer displays the recent change on the Disabled Issues List.

The Exchange Server Best Practices Analyzer indicates a recent change with a symbol of a penciled change (Figure 4).

Figure 4 Recent change icon

Icon for recent change

Baseline mismatch

A baseline mismatch indicates a setting whose value is different from the value of that setting on the baseline server. To view baseline mismatches, you must run a baseline scan. If the Exchange Server Best Practices Analyzer determines that a baseline mismatch is an error, a warning, or non-default configuration, the Exchange Server Best Practices Analyzer identifies the baseline mismatch with the appropriate error symbol, warning symbol, or non-default configuration symbol, in addition to identifying it as a baseline mismatch.

Baseline mismatches appear in the following reports:

  • Full Issues List

  • Detailed View List

  • Detailed View—Full Issues List

If you disable a baseline mismatch, the Exchange Server Best Practices Analyzer displays the baseline mismatch on the Disabled Issues List.

The Exchange Server Best Practices Analyzer indicates a baseline mismatch with a symbol of a clipboard and check mark (Figure 5).

Figure 5 Baseline mismatch icon

Icon representing baseline report in ExBPA

Best practice

A Best practice message indicates a setting that is not considered a best practice. Best practice messages are not warnings because they do not affect the overall stability of the Exchange Server organization. Best practice messages are recommended actions. If the Exchange Server Best Practices Analyzer determines that a best practice message is a non-default configuration or a recent change, the Exchange Server Best Practices Analyzer identifies the best practice message with the appropriate non-default configuration symbol or recent change symbol elsewhere in the report, in addition to identifying it as a best practice message.

Best practice messages appear in the following reports:

  • Full Issues List

  • Detailed View List

  • Detailed View—Full Issues List

If you disable a best practice message , the Exchange Server Best Practices Analyzer displays the best practice item in the Disabled Issues List.

The Exchange Server Best Practices Analyzer indicates a best practice message with a blue exclamation point symbol (Figure 6).

Figure 6 Best Practice icon

Best practice alert icon

Information

An information message indicates information that the Exchange Server Best Practices Analyzer does not provide in the other five report types. For example, an information item can communicate the number of Exchange Server objects in the Active Directory® directory service.

Information messages appear in the following reports:

  • Detailed View List

  • Detailed View—Full Issues List

The Exchange Server Best Practices Analyzer indicates an information item with a lowercase letter "i" symbol (Figure 7).

Figure 7 Information icon

Icon for information

See Also

Concepts

Configuring

Other Resources

Resolving and Hiding Issues

© 2007 Microsoft Corporation. All rights reserved.


Resolving and Hiding Issues
Overview of the Microsoft Exchange Server Analyzer Tool > Understanding the Tool Output >

Topic Last Modified: 2006-02-08

After running Microsoft® Exchange Server Best Practices Analyzer Tool on your Exchange organization, you could have issues listed in the report that you want to resolve. If you click an issue, an explanation and three options will be displayed:

  • Click the first option to find more detailed information about the issue, and how to resolve it.

  • Click the second option to hide the issue for this server.

  • Click the third option to hide the issue for all servers. Issues that are on the Hidden Issues list will not be displayed in the Critical Issues or All Issues lists for this report, or any other report that you view. To see the issues you have masked, go to the Hidden Issues list. From the Hidden Issues list, you can un-mask issues so that they will be displayed again in the Critical Issues and the All Issues lists.

The Exchange Server Best Practices Analyzer does not make changes to your Exchange organization to resolve issues. It only displays information about how to resolve issues.

In This Section

Types of Output Information


Viewing a Previous Report

Viewing a Previous Report |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool > Understanding the Tool Output >

Topic Last Modified: 2005-07-08

Instead of running a new scan, you might want to use the Microsoft® Exchange Server Best Practices Analyzer Tool to view a report from a previous scan.

To view a previous report

  1. Start Exchange Server Best Practices Analyzer by running ExBPA.exe.

  2. Choose if you want to download the latest rules.

  3. On the Welcome page, choose Select a Best Practices report to view.

  4. Select the report you want to view from the list of locally stored reports.

    The tool creates the list from the files stored at <systemdrive>\Documents and Settings\<user>\Application Data\Microsoft\ExBPA. When you click a report, the tool displays more information about the size and scope of this report. Click View this report to see the full report.

    You can also import a report from another location by clicking Import report in the upper-right corner of the page. If the version of your ExBPA.Config.xml file does not match the version used to collect the data in the imported report, the tool might re-analyze the imported file after the import.

  5. View the Exchange Server Best Practices Analyzer report.

See Also

Other Resources

Understanding the Tool Output

© 2007 Microsoft Corporation. All rights reserved.


Effect of the Tool on Exchange Performance

Effect of the Tool on Exchange Performance |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool >

Topic Last Modified: 2005-07-08

The Microsoft® Exchange Server Best Practices Analyzer Tool can affect the performance of the following computers in your Exchange organization:

  • The computer on which Exchange Server Best Practices Analyzer is running

  • The server that is running the Active Directory® directory service

  • The Exchange servers that the tool accesses

Performance on the computer that is running Exchange Server Best Practices Analyzer

The Exchange Server Best Practices Analyzer will use the following resources on the computer on which it is running:

  • 5 to 10 megabytes (MB) of RAM for each server that the tool scans

  • 50 to 75 percent CPU during the scan of the Exchange organization

  • 0.5 to 2 MB of disk space used for extensible markup language (XML) data

For more information about choosing which computer to install and run Exchange Server Best Practices Analyzer on, see Installing.

Performance on the Active Directory server

Exchange Server Best Practices Analyzer will use the following resources on the Active Directory server:

  • 25 to 50 percent CPU during the time that the tool accesses the Active Directory server

Note:
The tool will access the Active Directory server sporadically, with each access interval lasting an average of 10 to 15 seconds. The interval will be longer on very large Exchange organizations.

Performance on the Exchange servers

You will not notice any significant performance degradation on the Exchange servers while the Exchange Server Best Practices Analyzer scans the organization.

Note:
The time that the tool will take to gather data from an Exchange server will vary depending on the load on the Exchange server and the network speed. On slow networks, the tool will take an hour or more to gather data. On fast networks, the tool will take less than ten minutes to gather data.

See Also

Concepts

Installing

© 2007 Microsoft Corporation. All rights reserved.


Using the Command-line

Using the Command-line |
 | See Also
Overview of the Microsoft Exchange Server Analyzer Tool >

Topic Last Modified: 2005-07-08

A command-line program version of the Microsoft® Exchange Server Best Practices Analyzer Tool is available. The executable for the command-line program is ExBPACmd.exe, and is installed in the <systemdrive>\Program Files\ExBPA directory when the graphical user interface (GUI) version is installed. In some instances, you might want to use the command-line program instead of the GUI version. For example, you can use the command-line program to create a script to run scheduled scans. As another example, Microsoft Product Support Services might instruct you to run the command-line program to help you solve a problem.

ExBPACmd.exe Syntax

Usage: ExBPACmd.exe [-cfg <config XML>] [-dat <data XML>] [-d <dc name>] [-n <name>] [-u <context> <[domain\]user> <password | *> ...] [-rs <scope> <sub1> ...] [-rc <cat>,...] [-rl <level>] [-th <max threads>] [-to <timeout>] [-a] [-c] [-e] [-?]

-cfg: Specifies the configuration XML file that determines what settings to retrieve. The default value is ExBPA.Config.xml.

-dat: Specifies the data XML file to use. If you specify a data XML file name that is not in the current directory, the tool will use the specified file name for the output file. If you specify an existing data XML file name and you are running an analyze scan, the tool will read the data gathered in the specified file, will analyze that data, and will overwrite the specified file with the output of the scan. If you specify an existing data XML file name and you are running a collection scan, the tool will overwrite the specified file with the output of the scan.

The default value if you are running an analyze scan is output.<ts>.xml, where <ts> is the most recent time stamp in the current directory. The default value if you are running a collection scan is output.<ts>.xml, where <ts> is a new time stamp.

-d: Specifies the domain controller to use to access the Active Directory® directory service. By default, the tool will use the nearest Active Directory server.

-n: Provides a descriptive name for the customer whose topology the tool is scanning.

-u: Provides separate credentials per context.

Valid user contexts: ADLOGON for credentials to log on to Active Directory, or EXLOGON for credentials to log on to Exchange servers.

-rs: Restricts the scan to include only objects within the specified scopes. The <sub> fields are values for the specified scope. If you do not use the -rs switch, the scan will include the whole Exchange organization. If you do use the -rs switch, you can restrict the scan by administrative groups or by servers. You can specify one or more administrative groups, or one or more servers.

Valid scopes: AdminGroup, Server

-rc: Restricts the scan to include only settings and objects that match the specified categories. The configuration XML file defines categories for settings and objects. If you use the -rc switch to restrict a scan to one category, the scan will include only the settings that have that category defined. You can include more than one category with this switch.

The valid categories that you can use with the -rc switch might vary with different versions of the configuration XML file. To determine the categories that are valid for your version of the configuration XML file, run ExBPACmd.exe -?.

-rl: Restricts the scan to include only settings and objects of the specified level of detail or less. The configuration XML file defines levels of detail for settings and objects. The default value is 4.

The valid levels that you can use with the -rl switch might vary with different versions of the configuration XML file. To determine the levels that are valid for your version of the configuration XML file, run ExBPACmd.exe -?.

-th: Sets the maximum number of threads to run at the same time. The default value is 25.

-to: Sets the default time (in seconds) that the tool will wait while gathering data from a server in the Exchange organization. The default value is 300 seconds.

-a: Analyzes the data XML file using the rules from the configuration XML file. You can use this option to analyze an existing output file that is a collection scan by specifying the data XML file to use. You can also use this option to collect and analyze data for a new scan either by specifying a data XML file that is not in the current directory, or by not specifying a data XML file.

-c: Collects the data from the Exchange organization that is specified in the configuration XML file. The tool does not analyze the data using the rules from the configuration XML file, it only collects the data. If neither analyze (-a) nor collect (-c) operation step is specified, this will be enabled by default.

-e: Indicates that the tool should remove the values of any settings that are marked NotForExport in the configuration XML file.

-? Displays syntax information.

See Also

Other Resources

Scanning the Exchange Organization

© 2007 Microsoft Corporation. All rights reserved.


Microsoft Exchange Server Analyzer - Articles

Topic Last Modified: 2006-10-06

The articles in this section correspond to the rules and resulting messages that are generated by the following Microsoft® Exchange Analyzers:

  • Exchange Best Practices Analyzer

  • Exchange Troubleshooting Assistant

The Exchange Troubleshooting Assistant provides access to the following functionalities:

  • Exchange Performance Troubleshooter

  • Exchange Database Troubleshooter

  • Exchange Database Recovery Management

  • Exchange Mail Flow Troubleshooter

Each article describes a single error, warning, or non-default configuration message that could be detected by the Exchange Server Analyzer.

The Microsoft Exchange Analyzers Web page at http://go.microsoft.com/fwlink/?linkid=34707 contains downloads for the current versions of Exchange Best Practice Analyzer and Exchange Troubleshooting Assistant. In addition, the page contains information about system requirements, and a link to a newsgroup for discussion about the analyzers.

If you are running in an environment where you cannot use the automatic updating facility for Exchange Best Practices, you can access the Microsoft Exchange Best Practices Analyzer Web Update Pack Web page at http://go.microsoft.com/fwlink/?linkid=34290. Here you will be able to download the most recent configuration and Help files.

Note:
If updates are being applied automatically, you do not have to use this download.


Active Directory
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2005-11-17

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating with regard to the Active Directory® directory service. Additionally, these articles describe actions that you can take to resolve Active Directory-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


Active Directory Connector server is down or unreachable
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool uses remote procedure calls (RPCs) to read the CurrentVersion string value from the following registry key on the Active Directory Connector (ADC) server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

On a computer running Microsoft Windows® 2000 Server, the expected value for the CurrentVersion string is 5.0. On a computer running Microsoft Windows Server™ 2003, the expected value is 5.2.

If the Exchange Server Analyzer cannot read this registry value for any reason, an error is displayed.

To correct this error

  1. Ensure that the ADC server has been started and is connected to the network.

  2. Use the PING command to see if the ADC server is reachable.

  3. If there is a firewall in place, check to see if RPC ports are blocked.

  4. Ensure that the Remote Registry service on the ADC server has been started.

  5. Check the permissions for the account under which the Exchange Server Analyzer is running to ensure that it has sufficient permissions to read the registry on the ADC server.

For more information about troubleshooting network connectivity problems see the following:

  • Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

  • "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285)


Active Directory Connector server is not executing any connection agreements and is a candidate for removal
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchChildSyncAgreements attribute, which represents the connection agreements that are executing on an Active Directory Connector (ADC) server. This attribute is a multi-valued string and is set on the following Active Directory object: CN=Active Directory Connector (ServerName),CN=Exchange Settings,CN=ServerName,CN=Servers,CN=SiteName,CN=Sites,CN=Configuration,DC=Domain,DC=com

The Exchange Server Analyzer retrieves the number of entries (count) in this attribute. If the count is 0, it indicates that no connection agreements are running, and a warning is displayed.

If it is determined that all the required connection agreements are being executed on other ADC servers, the ADC service on this server should be removed or disabled. Running the ADC service without any connection agreements does not cause problems. However, it is recommended as a best practice to not run services if they are not required. Therefore, you should either disable the ADC service or uninstall the ADC service from this ADC server.

To correct this warning

  1. To disable the ADC service on the server running the ADC service, right-click My Computer on the desktop, and then click Manage.

  2. Expand the Services and Applications node, and then click the Services node.

  3. In the right pane, right-click Microsoft Active Directory Connector and click Properties.

  4. Change the Startup Type to Disabled. The next time the computer starts, the ADC service will not start.

  5. Click Apply, and then click OK.

If you decide to uninstall the ADC service, you can use the Microsoft Exchange 2000 Server or Exchange Server 2003 CD to do so. Go to the \ADC\I386 folder and double-click the Setup.exe program. Follow the prompts to uninstall the ADC service.

For more information about the Active Directory Connector, see the following Microsoft Support webcasts:

  • "Support Webcast: Introduction to the Active Directory Connector" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325300)

  • "Support Webcast: Microsoft Advanced Active Directory Connector" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325221)

  • For more information about installing and configuring the Active Directory Connector, see the Microsoft Knowledge Base article 312632, "HOW TO: Install and Configure the Active Directory Connector in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=312632).


Active Directory Connector server is not running the latest Service Pack for Windows 2000 Server
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool examines the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the ServicePackMajorVersion key on the Active Directory Connector (ADC) server. The Exchange Server Analyzer also examines the following registry entry to determine the version of Windows that is running on the ADC server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

If the Exchange Server Analyzer determines that the ADC server is running a Microsoft Windows 2000 Server operating system but is not running Service Pack 4 (SP4) for Windows 2000 Server, a warning is displayed.

As a best practice, Microsoft recommends running the latest service packs for all software in your Exchange deployment, including ADC servers.

To correct this error

  1. Update this ADC server and any others that are running a Windows 2000 Server operating system to SP4, plus the latest hotfixes and updates from Windows Update.

  2. Update all other Exchange Server computers running a Windows 2000 Server operating system to the latest service pack and roll-ups.

For more information about obtaining and installing service packs for Windows 2000 Server operating systems, see http://go.microsoft.com/fwlink/?LinkId=18353.

For more information about obtaining and installing Exchange Server service packs and roll-ups, see http://go.microsoft.com/fwlink/?LinkId=21573.


Active Directory Connector server may be overloaded
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchChildSyncAgreements attribute, which represents the connection agreements that are running on an Active Directory Connector (ADC) server. This attribute is a multi-valued string and is set on the following Active Directory object: CN=Active Directory Connector (ServerName),CN=Exchange Settings,CN=ServerName,CN=Servers,CN=SiteName,CN=Sites,CN=Configuration,DC=Domain,DC=com

The Exchange Server Analyzer retrieves the number of entries (count) in this attribute. If the count is more than 80, a warning is displayed.

It is recommended to run with fewer than 80 connection agreements per ADC server. If there are additional ADC servers that are not hosting the maximum recommended number of connection agreements, move some of the connection agreements from this server to the other ADC server. If you do not have other ADC servers, install the ADC program that is included with Microsoft Exchange 2000 Server or Exchange Server 2003 on another computer running Microsoft Windows® 2000 Server or Windows Server™ 2003.

Note that when you move a connection agreement from one ADC server to another, the core attributes of the particular connection agreement do not change. For example, the source and destination containers used for replication, as well as the data that has been configured to replicate, remain unchanged. When you move a connection agreement, only the ADC server that ran the connection agreement changes.

To correct this warning

  1. Click Start, click Programs, point to Administrative Tools, and then click Active Directory Connector Management to open the ADC Management console.

  2. The left pane of the MMC console shows a list of servers that run the ADC service. Select the ADC for the server where the connection agreement you want to move is located.

  3. The details pane of the MMC console shows the connection agreements that are hosted on the ADC server that you selected.

  4. Right-click the connection agreement you want to move and then click Properties.

  5. On the General tab, in the Select a server to run the Connection Agreement drop-down list, select the server on which you want this connection agreement to run, and then click OK.

  6. Under Connect as (Windows Server), enter the ADC service account name and password, and then click OK.

  7. Under Connect as (Exchange Server), enter the Exchange service account and password, and then click OK.

For more information about moving connection agreements, see the Microsoft Knowledge Base article, 326060 "XADM: How to Move a Connection Agreement to Another Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=326060).

For more information about installing the Exchange 2000 Server ADC program on another server, see the Microsoft Knowledge Base article, 312632 "How To Install and Configure the Active Directory Connector in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=312632).

For more information about installing the Exchange Server 2003 ADC program on another server, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).


Active Directory Connector software update required
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-10-10

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for Adc.exe, the Active Directory Connector (ADC) file. The Version WMI key indicates the build number for this file.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value for the msDS-Behavior-Version attribute of the forest object in Active Directory, NTDS Settings. This value indicates the Active Directory forest functional level. Valid values for the msDS-Behavior-Version attribute are shown in the following table.

Value | Forest functional level
0 | Microsoft Windows 2000 Server mixed
1 | Windows Server™ 2003 interim
2 | Windows Server 2003 native

If the Exchange Server Analyzer finds that the build number for Adc.exe is less than 6.0.6615.0 on a computer running Exchange Server in an Active Directory forest in Windows Server 2003 interim or native mode, an error is displayed. This error indicates that an Exchange 2000 Server version of the ADC program is running in an incompatible Windows Server 2003 Active Directory forest level. An update to the Exchange Active Directory Connection (ADC) program is required to resolve this issue.

Running an older version of ADC in a mixed or native forest functionality level may cause incomplete directory updates and data loss. It is recommended that you upgrade to the latest Exchange Server 2003 version of ADC on all computers in your organization.

You can download the latest version of ADC, along with the latest Exchange Server 2003 Service Pack, from the Downloads for Exchange Server 2003 page (http://go.microsoft.com/fwlink/?LinkId=25097). You can also install the Exchange Server 2003 final version of the ADC from the Exchange Server CD.

To upgrade to the latest version of ADC

  1. On your server running the older version of ADC, click Start, click Run, and then type E:\setup\adc\i386\setup.exe, where E is the location of the Exchange Server service pack download.

  2. On the Welcome to the Active Directory Connector Installation Wizard page, click Next.

  3. On the Previous Installation Detected page, click Reinstall to upgrade ADC.

  4. On the Completing the Active Directory Connector Installation Wizard page, click Finish.

For more information about how the forest functional level affects ADC, see Microsoft Knowledge Base article 825916, "Exchange 2000 Active Directory Connector Does Not Successfully Replicate Changes to Group Membership in Windows Server 2003 Active Directory in Forest Functional Levels 1 or 2" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=825916).

For more information about domain and forest functional levels, see Knowledge Base article 322692, "How to raise domain and forest functional levels in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322692).


This Active Directory forest has been configured for Hosted Exchange
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Microsoft Active Directory® directory service to determine the value of the LinkID attribute on the Global-Address-List schema attribute object. The Global-Address-List object is used on a Exchange container to store the distinguished name of a newly created global address list (GAL).

If the Exchange Server Analyzer finds that the value of the LinkID attribute of the Global-Address-List object is set to a value of 4048, the Exchange Server Analyzer displays a non-default configuration message. A value of 4048 indicates that the Active Directory forest is configured for a Hosted Exchange environment.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about Hosted Exchange environments, see the following articles:

  • "Information for Hosters" (http://go.microsoft.com/fwlink/?LinkId=46307)

  • "Chapter 23 - Hosted Service Environments" in the Exchange Server 2000 Resource Kit (http://go.microsoft.com/fwlink/?LinkId=46326)


Active Directory server down or unreachable
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool uses remote procedure calls (RPCs) to read the CurrentVersion string value from the following registry key on the Active Directory® directory server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

On a computer running Microsoft Windows® 2000 Server, the expected value for the CurrentVersion string is 5.0. On a computer running Windows Server™ 2003, the expected value is 5.2.

If the Exchange Server Analyzer cannot read this registry value for any reason, an error is displayed.

To correct this error

  1. Ensure that the directory server has been started and is connected to the network.

  2. Use the PING command to determine if the directory server is reachable.

  3. If there is a firewall in place, check to see if RPC ports are blocked.

  4. Ensure that the Remote Registry service on the directory server has been started.

  5. Check the permissions for the account under which the Exchange Server Analyzer is running to ensure that it has sufficient permissions to read the registry on the Active Directory server.

For more information about troubleshooting network connectivity problems, see the following:

  • Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487)

  • "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285)


Active Directory server has less than 1 GB of memory but has the /3GB and /USERVA=3030 switches set in the Boot.ini file
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries two Microsoft Windows® Management Instrumentation (WMI) classes to determine the amount of physical memory in the Active Directory® directory server, and the amount of virtual address space allocated to user mode processes. The table describes the classes and keys being evaluated by the Exchange Server Analyzer.

Class | Key | Description
Win32_OperatingSystem | MaxProcessMemorySize | Maximum number of kilobytes of memory that can be allocated to a process.
Win32_OperatingSystem | OSProductSuite | Installed and licensed system product additions to the operating system.
Win32_ComputerSystem | TotalPhysicalMemory | Amount of random access memory (RAM) installed in the computer.

If Exchange Server Analyzer determines that the directory server has less than 950 MB of RAM, and that the value for the MaxProcessMemorySize is more than 2097024 but less than 3104640, a warning is displayed.

This warning indicates that the directory server is not correctly configured for optimal memory usage in two respects:

  • The /USERVA=3030 startup switch has been set. This switch is only required on Exchange Server computers with 1 GB or more of memory that are running on a Microsoft Windows Server™ 2003 operating system.

  • The /3GB startup switch has been set. This switch should only be used on Exchange servers with 1 GB or more of memory that are running any of the following operating systems:

    • Microsoft Windows Server 2003 Standard Edition

    • Microsoft Windows Server 2003 Enterprise Edition

    • Microsoft Windows Server 2003 Datacenter Edition

    • Microsoft Windows 2000 Advanced Server

    • Microsoft Windows 2000 Datacenter Server

Important:
The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the above operating systems when 1 GB or more of physical memory is installed.

If you encounter this warning on a system in which 1 GB of physical memory is installed, it could indicate that another component, such as a video card, has been allocated some of this physical memory at the hardware level, thereby making the allocated physical memory unavailable to the operating system. In these cases, the amount of memory installed physically according to Windows will be less than the actual amount of physical memory installed in the computer. If you encounter this situation, you should compare the amount of installed memory reported by the BIOS with the amount of installed memory reported by Windows.

To correct this warning on Windows Server 2003

  1. Right-click My Computer and select Properties. The System Properties dialog box appears.

  2. Click Advanced.

  3. In the Startup and Recovery area, click Settings. The Startup and Recovery dialog box appears.

  4. In the System startup area, click Edit. This will open the Windows Boot.ini file in Notepad.

  5. In the [Operating Systems] section, delete the following switches from all startup lines: /3GB /USERVA=3030

  6. Save the changes and close Notepad.

  7. Click OK twice to close the open dialog boxes, and then restart the computer for the change to take effect.

To correct this warning on Windows 2000 Server

  1. In Windows Explorer, locate the system partition.

  2. If you cannot see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in Explorer, click Tools, Folder Options, and then click the View tab. Clear the Hide protected operating system files (Recommended) check box. When prompted with the warning box, click Yes.

  3. As soon as the Boot.ini file is visible in Explorer, right-click the file, click Open With, and click Notepad to open the file.

  4. In the [Operating Systems] section, delete the following switches from all startup lines: /3GB /USERVA=3030

  5. Save the changes and close Notepad.

  6. Restart the computer for the change to take effect.

For additional details about how to use the /3GB and /USERVA startup switches, see the following Microsoft Knowledge Base articles:

  • 308356, "Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356)

  • 297812, "How to Use the 4GT RAM Tuning Feature" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 311901, "The effects of 4GT tuning on system Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 316739, "How to Use the /USERVA Switch in the Boot.ini File to Tune /3GB Configurations" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Active Directory server has less than 1 GB of memory but has the /3GB switch set in the Boot.ini file
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries two Microsoft Windows® Management Instrumentation (WMI) classes to determine the amount of physical memory in the Active Directory® directory server, and the amount of virtual address space allocated to user mode processes. The following table describes the classes and keys being evaluated by the Exchange Server Analyzer.

Class | Key | Description
Win32_OperatingSystem | MaxProcessMemorySize | Maximum number of kilobytes of memory that can be allocated to a process.
Win32_OperatingSystem | OSProductSuite | Installed and licensed system product additions to the operating system.
Win32_ComputerSystem | TotalPhysicalMemory | Number of bytes of random access memory (RAM) installed in the computer.

If the Exchange Server Analyzer determines that the directory server has less than 950 MB of RAM, and that the value for the MaxProcessMemorySize is more than 2097024 but less than 3104640, a warning is displayed.

This warning indicates that the directory server is not correctly configured for optimal memory usage. The /3GB startup switch has been set on this computer and should be removed. This switch should only be used on Active Directory servers with 1 GB or more of memory that are running any of the following operating systems:

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server™ 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

Important:
The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the above operating systems when 1 GB or more of physical memory is installed.

If you encounter this warning on a system in which 1 GB of physical memory is installed, it could indicate that another component, such as a video card, has been allocated some of this physical memory at the hardware level, thereby making the allocated physical memory unavailable to the operating system. In these cases, the amount of memory installed physically according to Windows will be less than the actual amount of physical memory installed in the computer. If you encounter this situation, you should compare the amount of installed memory reported by the BIOS with the amount of installed memory reported by Windows.

To correct this warning on Windows Server 2003

  1. Right-click My Computer, and then click Properties. The System Properties dialog box appears.

  2. Click Advanced.

  3. In the Startup and Recovery area, click Settings. The Startup and Recovery dialog box appears.

  4. In the System startup area, click Edit. This will open the Windows Boot.ini file in Notepad.

  5. In the [Operating Systems] section, delete the following switch from all startup lines: /3GB

  6. Save the changes and close Notepad.

  7. Click OK twice to close the open dialog boxes, and then restart the computer for the change to take effect.

To correct this warning on Windows 2000 Server

  1. In Windows Explorer, navigate to the system partition.

  2. If you cannot see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in Explorer, click Tools, Folder Options, and then click View. Clear the Hide protected operating system files (Recommended) check box. When prompted with the warning box, click Yes.

  3. When the Boot.ini file is visible in Explorer, right-click the file, click Open With, and click Notepad to open the file.

  4. In the [Operating Systems] section, delete the following switch from all startup lines: /3GB

  5. Save the changes and close Notepad.

  6. Restart the computer for the change to take effect.

For further details about using the /3GB startup switch, see the following Microsoft Knowledge Base articles:

  • 308356, "Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356)

  • 297812, "How to Use the 4GT RAM Tuning Feature" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 311901, "The effects of 4GT tuning on system Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 316739, "How to Use the /USERVA Switch in the Boot.ini File to Tune /3GB Configurations" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Active Directory server is running Windows 2000 Server and has the /3GB switch set
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the amount of virtual address space allocated to user mode processes (MaxProcessMemorySize) and the version of Windows (OSProductSuite) that is running on the Active Directory® directory service server. The following table describes the classes and keys being evaluated by the Exchange Server Analyzer.

If the Exchange Server Analyzer determines that the value for the MaxProcessMemorySize is 3104640, and that the value for OSProductSuite resolves to Windows 2000 Server, an error is displayed.

This error indicates that the /3GB startup switch is set in the Boot.ini file on a directory server running Microsoft Windows 2000 Server. This switch is not supported on Windows 2000 Server, and should be used only on computers with 1 GB or more of memory that are running any of the following operating systems:

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

To remove the /3GB switch from the Boot.ini file

  1. In Windows Explorer, navigate to the system partition.

  2. If you are unable to see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in Explorer, click Tools, Folder Options, and then click the View tab. Clear the Hide protected operating system files (Recommended) check box. When prompted with the warning box, click Yes.

  3. When the Boot.ini file is visible in Explorer, right-click the file, click Open With, and choose Notepad to open the file.

  4. In the [Operating Systems] section, delete the following switches from all startup lines: /3GB /USERVA=3030

  5. Save the changes and close Notepad.

  6. Restart the directory server for the change to take effect.

For more information about using the /3GB startup switch, see the following Microsoft Knowledge Base articles:

  • 297812, "How to Use the 4GT RAM Tuning Feature" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 311901, "The effects of 4GT tuning on system Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 316739, "How to Use the /USERVA Switch in the Boot.ini File to Tune /3GB Configurations" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Active Directory Server registry could not be accessed
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry on each domain controller:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion\CurrentVersion

If the Exchange Server Analyzer cannot read this registry value for any reason, the Exchange Server Analyzer displays an error.

To correct this error

  1. Make sure that the domain controller has been started and is connected to the network.

  2. Use the PING command to see if the domain controller is reachable.

  3. If there is a firewall, check to see if RPC ports are blocked.

  4. Make sure that the Remote Registry service on the domain controller has been started.

  5. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have Administrator permissions on each domain controller that it is scanning.

For more information about troubleshooting network connectivity problems, see the following:

  • Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487)

  • "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285)

For more information about port requirements, see the Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


Active Directory server software update available
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2007-02-20

The Microsoft Exchange Analyzer Tool queries the Exchange_DSAccessDC Microsoft Windows Management Instrumentation (WMI) class in the ROOT\MicrosoftExchangeV2 namespace to determine the value for the Name property. The Name property specifies the computer name of the domain controller used by the Exchange server for Active Directory directory service lookups.

The Exchange Analyzer then queries the Active Directory for the values of specific attributes of that domain controller to determine the following:

  • If the Active Directory domain controller is running the Windows Server 2003 operating system

  • If the Active Directory domain controller is running a non-English version of the Microsoft Windows Server 2003 operating system

  • If there is a Microsoft Exchange Server 2007 server in the Exchange organization

  • If the value for the Version key for the ntdsa.dll file on the server is less than 2700

If the Exchange Analyzer finds that all these conditions are true, the Exchange Analyzer displays a warning.

This warning indicates that Exchange Outlook Web Access clients may have issues with the Exchange Address Book indexing.

Outlook Web Access lets users select the language that they want to use for their user interface (UI). The language that users select determines the locale setting. Outlook Web Access also uses that language to sort Active Directory results, such as the address book. When Exchange runs a Virtual List Views (VLV) query and specifies a language that is not available on the domain controller, an error occurs. This problem occurs because there is currently no default indexing mechanism that enables Exchange to use a different language if the language that is specified for a VLV query does not match the language of the domain controller.

To address this warning, obtain and install the file update referred to by Microsoft Knowledge Base article 919166, "The address book function in Exchange 2007 is broken when an Exchange OWA client and a Windows Server 2003-based domain controller do not have the same locale setting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=919166).


Active Directory Server WMI could not be accessed
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the Name key on the domain controller. If the WMI query fails, the Exchange Server Analyzer displays an error.

There are two likely causes for this error:

  • The account that runs the Exchange Server Analyzer does not have sufficient permissions to query WMI information

  • A network issue is preventing the Exchange Server Analyzer from contacting the computer.

To correct this error

  1. Make sure that the Exchange Server computer has been started and is connected to the network.

  2. Use the PING command to see if the Exchange Server computer is reachable.

  3. If there is a firewall, check to see if RPC ports are blocked.

  4. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange Server computer that it is scanning.

    Alternatively, you can grant specific WMI permission to the account under which the Exchange Server Analyzer is running.

    1. On the Exchange computer, open the Computer Management MMC console tree.

    2. Under Services and Applications, right-click WMI Control, and then click Properties.

    3. On the WMI Controls Property page, click the Security tab, and then expand Root.

    4. Select the CIMV2 folder, and click Security.

    5. On the Security for ROOT\CIMV2 page, add the account under which the Exchange Server Analyzer runs.

    6. Select the account that you added in Step e; in Permissions for Selected_Account, under the Allow column, check both Remote Enable and Read Security, and then click OK.

For more information about troubleshooting network connectivity problems, see the following:

  • Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487)

  • "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285)

For more information about port requirements, see the Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


ADCDisabledMail attribute detected
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the Exchange organization is in mixed mode or native mode. If the Exchange organization is found to be in native mode, the Exchange Server Analyzer queries Active Directory to determine whether any mail-enabled object in the organization's domains has the value for the legacyExchangeDN attribute set to ADCDisabledMail. If mail-enabled objects are found with the legacyExchangeDN attribute value set to ADCDisabledMail, a warning is displayed that lists the objects and their domain.

This issue can occur in both Exchange 2000 Server and Exchange Server 2003 environments when a mailbox is deleted. When the mailbox is deleted, the value for the legacyExchangeDN attribute of the account is stamped with ADCDisabledMail. This value is used to instruct the Active Directory Connector (ADC) to delete objects from the Exchange Server 5.5 directory service when the associated object has been mail-disabled in Active Directory. If there are several mailboxes in a large distribution group that have been deleted, the message is delayed while Active Directory is searched for a unique legacyExchangeDN attribute value of ADCDisabledMail. Because several mailboxes may have this same legacyExchangeDN attribute value, the search takes a long time. This causes messaging delays. Messaging delays will also occur when the distribution group is expanded in the message's "To:/Cc:/Bcc:" lines from an Microsoft Office Outlook® 2003 client.

The resolution is to either delete the objects or use the Active Directory Service Interfaces (ADSI) Edit tool, the ldp.exe tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client to remove the contents of the legacyExchangeDn attribute. If the legacyExchangeDN attribute value is set to NULL then the search against Active Directory will be set to "/O=NT5/ou=<objectGUID of the Domain>/cn=<objectGUID of the user>" and the non-delivery report (NDR) will occur much more quickly.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To remove the ADCDisabledMail value on the legacyExchangeDN attribute

  1. Start the ADSI Edit tool from Windows 2000 Support Tools or from Windows Server 2003 Support Tools.

  2. Expand the following nodes:

    • Domain Container

    • DC=Domain_Name

    • Users Container

  3. Right-click User_Name, and then click Properties.

  4. Click legacyExchangeDN in the Attributes list, and then click Edit.

  5. Remove the original legacyExchangeDN value that contains ADCDisabledMail by selecting the original value and clicking Clear.

  6. Click OK two times to apply the change.

For more information about how to work with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in Windows Server online Help.

For more information about how to use the LDP tool, see Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).


Address List filter setting may cause new recipients to not display in address lists
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the attributes that are set for the purportedSearch attribute of each Address List object. If the Exchange Server Analyzer finds that the purportedSearch attribute includes the string "proxyAddresses=*", an error is displayed.

After you create a new user object, the Recipient Update Service assigns specific attributes to that recipient object such as proxy addresses. However, the Recipient Update Service may fail to assign the ShowInAddressBook attribute. The ShowInAddressBook attribute of a recipient object indicates the address lists that the recipient is a member of. Recipient objects that are not assigned this attribute do not display in the global address list or any other address list, even if the object matches the criteria of the Address List filter.

This situation can occur if one or more of the Address List filters include the proxyAddresses attribute. You can determine whether this is the case by reviewing the properties of each Address List and looking for the following string in the Filter rules box: "proxyAddresses=*".

Perform the following procedure to enable the Recipient Update Service to correctly assign attributes to the recipient objects so that they display in the global address list or any other address list.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this error

  1. Open Exchange System Manager.

  2. Expand Recipient, expand All Global Address Lists, and then select Recipient Policies.

  3. In the right pane, right-click the Address List you want to edit and select Properties.

  4. On the Properties page, on the General tab, under Filter rules, click Modify.

  5. In the Find Exchange Recipients drop-down menu, select Custom Search. If the Address List was originally created by a custom search, the Find Custom Search page will be displayed after you click Modify in step 3.

  6. Select the Proxy addresses is (exactly) * entry in criteria list, and then click Remove.

  7. Click OK to close the dialog boxes.

  8. Right-click the recipient policy, and click Apply this policy now.

For more information about the Recipient Update Service, see the following Microsoft Knowledge Base articles:

  • 328738, "XADM: How the Recipient Update Service Applies Recipient Policies" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328738)

  • 319065, "How to work with the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319065)


The administrative group mode is unknown
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to verify the mode of the administrative group by checking the msExchAdminGroupMode attribute of the administrative group object in the Administrative Groups container in Active Directory. If the Exchange Server Analyzer finds that the value for the msExchAdminGroupMode attribute does not equal 0, 1, or 2, an error is displayed.

Exchange uses the mode of the administrative group to indicate whether the administrative group can include Exchange Server 5.5 servers or Exchange Server 2003 servers (or Exchange 2000 Server servers). If a value that is not 0, 1, or 2 is present for this attribute, it is likely an administrator has manually changed the value. Exchange Setup or Exchange System Manager will not set this value incorrectly.

You must correct the value using a tool such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To modify the MSExchAdminGroupMode attribute

  1. Using an Active Directory editor, such as ADSI Edit, to locate the administrative group object in Active Directory.

    The MSExchAdminGroupMode attribute can be found at:

    CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=Organization, CN=Administrative Groups, CN= Administrative group

  2. Type one of the following integer values:

    0=native mode (the administrative group was created using Exchange 2000 Server or Exchange Server 2003)

    1=Exchange Server 5.5 mode (the administrative group was created using Exchange Server 5.5 and includes only Exchange Server 5.5 servers)

    2=mixed mode (the administrative group may include both Exchange Server 5.5 servers and Exchange 2000 Server or Exchange Server 2003 servers)

For more information about using the LDP tool, see Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in Windows Server online Help.


Authenticated Users configuration is incorrect for Hosted Exchange
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the Exchange Server environment is configured as a Hosted Exchange environment. If the Exchange Server environment is a Hosted Exchange environment, the Exchange Server Analyzer queries Active Directory to determine whether the Authenticated Users group is part of the Pre-Windows® 2000 Compatible Access group in the domain.

If the Authenticated Users group is a member of the Pre-Windows 2000 Compatible Access group, the Exchange Server Analyzer displays a warning. This is not a recommended configuration for a Hosted Exchange solution.

To fix this warning, remove Authenticated Users from the Pre-Windows 2000 Compatible Access security group

  1. Open Active Directory Users and Computers.

  2. Expand the domain node and then click the Builtin container.

  3. Right-click the Pre-Windows 2000 Compatible Access security group and select Properties.

  4. Click the Members tab.

  5. Select Authenticated Users.

  6. Click Remove.

  7. Click OK.

For more information about Hosted Exchange environments, see the following articles:

  • "Information for Hosters" (http://go.microsoft.com/fwlink/?LinkId=46307)

  • "Chapter 23 - Hosted Service Environments" in the Exchange Server 2000 Resource Kit (http://go.microsoft.com/fwlink/?LinkId=46326)


Certificate Principal Mismatch
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Server Certificate object in the Exchange server system to retrieve various properties on X509 certificates. For each Secure Sockets Layer (SSL) certificate found, the Exchange Server Analyzer evaluates the Principal attribute to identify the fully qualified domain name (FQDN) that was assigned to the certificate, for example, www.microsoft.com.

Microsoft Exchange Server Analyzer issues a warning when the Principal FDQN name does not match the host address or URL. The certificate Principal mismatch warning means that users might not be able to connect to their mailboxes using Microsoft Office Outlook® Web Access for Exchange Server 2003, Outlook Anywhere for Exchange Server 2007, Exchange Server ActiveSync, and RPC over HTTP.

Note:
A server must have a server certificate when it runs a SSL protocol. As an option, the server can ask for the client's certificate. The server certificate contains the Web site name. The browser verifies that the Web site is the name that was entered. For example, if there is a Web site such as https://www.example.com, the name of the certificate should be www.example.com.

A mismatch could result if one of the following conditions are true:

  • The certificate is accidentally applied to the wrong server

  • The client accesses data on a server through the wrong host URL when servers have more than one host name

To resolve the certificate name mismatch

  • Verify that the SSL certificate has been granted and applied to the correct host.

For More Information

  • For information about how to use certificates with virtual servers in Exchange Server 2003, see Microsoft Knowledge Base Article 823024, "How to Use Certificates with Virtual Servers in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823024).

  • For information about how to use SSL and how to obtain and install server certificates, see "Configuring Exchange Server 2003 for Client Access" in the Exchange Server 2003 Client Access Guide (http://go.microsoft.com/fwlink/?LinkId=47568).

  • For information about how to use SSL and how to obtain and install server certificates for Exchange Server 2007, see "How to Configure SSL for Outlook Anywhere" (http://go.microsoft.com/fwlink/?LinkId=80875).


Connection agreement activation schedule has been set to Never
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the activationStyle attribute on each connection agreement object. The activationStyle attribute represents the schedule setting for the connection agreement. If the schedule is set to Never, a warning is displayed.

If you have determined that this connection agreement is no longer required, you should delete it. If this connection agreement is required, you should configure it to run at an appropriate schedule.

To correct this warning

  1. Click Start, click Programs, click Administrative Tools, and then click Active Directory Connector.

  2. In the left pane, click the Active Directory Connector (ADC) server that hosts the connection agreement you want to modify.

  3. In the right pane, right-click the connection agreement you want to modify, and then click Properties.

  4. Click the Schedule tab.

  5. Set the schedule to Always or Selected times. If you select the latter, click the appropriate areas in the grid to have the connection agreement run at those times.

For more information about configuring a two-way recipient connection agreement, see the Microsoft Knowledge Base article 296260, "XGEN: How to Configure a Two-Way Recipient Connection Agreement for Exchange 5.5 Users" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=296260).


Connection agreement is orphaned
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether each connection agreement has a valid value for msExchHomeSyncService. If the Exchange Server Analyzer finds a connection agreement that does not have a valid value for this attribute, a warning is displayed.

The msExchHomeSyncService attribute contains the Active Directory Connector (ADC) server on which the connection agreement is located.

You can see this warning if you remove an ADC server without first removing ADC, or removing the connection agreements on the ADC server. When you remove the ADC server, the connection breaks between the connection agreements and the ADC server. As a result, the objects that these connection agreements are responsible for will no longer replicate. If you use the ADC Manager snap-in on another ADC server, the connection agreements that were located on the ADC server that has been removed will not be displayed. However, these connection agreements still exist in Active Directory.

To resolve this issue, re-associate the old connection agreements with a new ADC server. One way to do this is to create a new connection agreement on the new ADC server, and then copy and paste the msExchHomeSyncService attribute from the new connection agreement to the old one.

To re-associate a connection agreement with an ADC server

  1. Start the ADC Manager snap-in.

  2. Create a new connection agreement.

  3. Start Active Directory Service Interfaces (ADSI) Edit.

  4. Expand Configuration, expand Services, expand Microsoft Exchange, and then click Active Directory Connections.

  5. In the right pane, open the properties of the connection agreement that was just created.

  6. In the Select a property to view drop-down list, click msExchHomeSyncService.

  7. Copy the whole attribute from the Value(s) box, and then click OK.

  8. Open the properties of the connection agreement that you must re-associate.

  9. Click the Select a property to view drop-down list, and then click the msExchHomeSyncService attribute.

  10. Paste the copied value into the Edit Attribute box.

  11. Click Set, click Apply, and then click OK.

For more information about orphaned connection agreements, see the Microsoft Knowledge Base article 319486, "XADM: Connection Agreements Disappear After You Remove Active Directory Connector" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319486).


Default display name modified
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the createDialog attribute of objects that have a displaySpecifier class. Objects with a displaySpecifier class describe the context menus and property pages to be used with objects in Active Directory. If the Exchange Server Analyzer determines that the createDialog attribute has been set, a non-default configuration message is displayed.

When a new user or contact object is created in Active Directory, the Full name field is always generated in FirstName LastName format. In turn, this field sets the Display Name field on creation, therefore, you end up with a FirstName LastName formatted global address list.

If you want, you can use an Active Directory editor such as Active Directory Service Interfaces (ADSI) Edit to modify the way in which the Display Name field is built. ADSI Edit not only changes the way this field is built, but also the Full Name field; therefore, users appear in the chosen format viewed within Active Directory Users and Computers.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

Before making these changes, be aware that they can have adverse effects. For more information about the potential consequences of this change, see Microsoft Knowledge Base article 276266, "Group Changes for Users with LDAP-Restricted Characters" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=276266).

To change the default display format for user and contact objects

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Right-click the top node, and then click Connect to.

  3. Change the Naming Context to "Configuration Container," and then click OK to bind and authenticate.

  4. Expand the Configuration Container node, and then expand the Configuration node.

  5. Expand the cn=DisplaySpecifiers node, and then double-click CN=409. Note: 409 is the Locale ID for U.S. English. If you are in a multi-lingual environment, you may need to make changes to the other codes.

  6. In the right-hand pane, open the properties for CN=user-Display.

  7. Scroll to the createDialog optional attribute.

  8. Set the attribute to %<sn>.%<givenName> and then click Set. Note: The only tokens that can be formatted are %<sn>, %<givenName>, and %<initials>.

  9. Click OK to close the dialog box.

  10. Create a new user in Active Directory to verify that the Full Name and Display Name are being built as expected. Note: In a multi-domain environment, you may need to wait for replication to complete before the Active Directory Users and Computers tool picks up the changes.

The above steps result in the display name appearing as LastName.FirstName. In addition, the above procedure is for user objects. For contact objects, change step 6 to contact-Display.

For more information about how to use an ADSI script to perform this task, see the Microsoft Knowledge Base article 277717, "How to Change the Display Names of Active Directory Users with Active Directory Services Interface Script" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=277717).

The International Telecommunication Union (ITU) and International Organization for Standardization (ISO) define the code pages. For more information, visit the following ITU and ISO Web pages:

  • http://www.itu.int

  • http://www.iso.ch/iso/en/ISOOnline.openerpage

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For additional information about supporting localized Exchange Clients, see the Microsoft Knowledge Base article 150977, "XADM: Supporting Localized Exchange Clients" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=150977).


Deleted item retention is disabled for mailbox store
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the garbageCollPeriod attribute of each mailbox store. If the Exchange Server Analyzer finds that the garbageCollPeriod attribute is set to 0 for any mailbox store, a best practice recommendation message is displayed.

Garbage collection is an internal Exchange housekeeping process that frees space within the mailbox store database. By default, deleted items are stored in the mailbox store database for a certain number of days before they are permanently deleted by Exchange. You can set the length of the deleted item retention period by either using the mailbox store defaults, or by selecting the number of days that a deleted item is kept before it is permanently deleted.

You can select a number from 0 to 24,855 when specifying the number of days to retain a deleted item. It is recommended that you configure this setting to 7 days. If the deleted item retention period is set to 0, the deleted items are permanently removed from the server immediately. Unless disk space is an issue, it is recommended that you do not disable the deleted item retention feature. Follow the procedures below to specify the number of days that deleted items are stored before they are permanently deleted.

To configure deleted item retention in Exchange System Manager

  1. Open Exchange System Manager.

  2. Expand Administrative Group or Organization, click Servers, and then click Mailbox Store.

  3. Right-click the mailbox store, and then click Properties.

  4. On the Limits tab, set the deleted items retention period by doing the following:

    • To set a retention period for deleted items, click Keep deleted items for (days), and then type a value.

    • To preserve items until backup, click Do not permanently delete mailboxes and items until the store has been backed up.

To configure deleted item retention in Active Directory Users and Computers

  1. Open Active Directory Users and Computers.

  2. In the console tree, expand the domain.

  3. Double-click Users, or double-click the node that contains the recipient information that you want to modify.

  4. In the details pane, double-click the recipient that you are modifying.

  5. On the Exchange General tab, click Storage Limits.

  6. In the Storage Limits dialog box, under Deleted item retention, click to clear the Use mailbox store defaults check box, and then in Keep deleted items for (days), type a value.

    To prevent deleted items from being permanently deleted before they are backed up, select the Do not permanently delete items until the store has been backed up check box.

For more information about setting mailbox storage limits, see the Microsoft Knowledge Base article 319583, "HOW TO: Configure Storage Limits on Mailboxes in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319583).


Deleted item retention is disabled for public folder store
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the garbageCollPeriod attribute of each public folder store. If the Exchange Server Analyzer finds the garbageCollPeriod attribute set to 0 for any public folder store, a best practice recommendation message is displayed.

Garbage collection is an internal Exchange housekeeping process that frees space within the public folder store database. By default, deleted items are stored in the public folder store database for a certain number of days before they are permanently deleted by Exchange. You can set the length of the deleted item retention period by either using the public folder store defaults, or by selecting the number of days that a deleted item is kept before it is permanently deleted.

You can select a number from 0 to 24,855 when specifying the number of days to retain a deleted item. It is recommended that you configure this setting to 7 days. If the deleted item retention period is set to 0, the deleted items are permanently removed from the server immediately. Unless disk space is an issue, it is recommended that you do not disable the deleted item retention feature.

To configure deleted items retention in Exchange System Manager

  1. Open Exchange System Manager.

  2. Expand the Administrative Group or Servers, click Servers, and then click Public Folder Store.

  3. Right-click the public folder store, and then click Properties.

  4. On the Limits tab, set the deleted items retention period by doing the following:

    • To set a retention period for deleted items, click Keep deleted items for (days), and then type a value.

    • To preserve items until backup, click Do not permanently delete items until the store has been backed up.

For more information about setting storage limits for public folders, see the Microsoft Knowledge Base article 319439, "HOW TO: Configure Storage Limits on Public Folders in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319439).


Deleted mailbox retention is disabled
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchMailboxRetentionPeriod attribute of each mailbox store. If the Exchange Server Analyzer finds that the value for the msExchMailboxRetentionPeriod attribute of any mailbox store is set to 0, a best practice recommendation is displayed.

The msExchMailboxRetentionPeriod attribute indicates the number of days to retain deleted mailboxes before deleting them. You can select a number from 0 to 24,855 when specifying the number of days to retain a deleted mailbox. The default setting for deleted mailbox retention is 30 days. If the mailbox retention period is set to 0, deleted mailboxes are permanently removed from the server immediately. Unless disk space is an issue, it is recommended that you do not disable the deleted mailbox retention feature.

To configure deleted mailbox retention

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, and then expand your storage group. If the Administrative Groups node is not displayed in Exchange System Manager, expand Servers, and then expand your storage group.

  3. Right-click the mailbox store you want to configure, and then select Properties.

  4. On the Limits tab, enter a mailbox retention period in the Keep deleted mailboxes for (days) field.

  5. Click OK to save the changes.
Note:
You may be able to recover a mailbox if its mailbox retention period has not expired and the associated user object is not deleted.

For more information about recovering a deleted mailbox, see the following Microsoft Knowledge Base articles:

  • 274343, "How to Recover a Deleted Mailbox in Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=274343)

  • 813337, "How To Recover or Restore a Single Mailbox in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=813337)

  • 823176, "How to recover or to restore a single mailbox in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823176)


Domain has an unknown Exchange signature
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-12-04

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine what version of DomainPrep was last run in the given domain. The version number of DomainPrep acts as the Exchange signature for the domain. The Exchange Server Analyzer examines the objectVersion attribute of the given domain's Exchange System Objects object. There are two valid integers:

  • For Exchange 2000 Server, the objectVersion value is 4406.

  • For Exchange Server 2003, the objectVersion value is 6936.

  • For Exchange Server 2007, the objectVersion value is 10628

If the Exchange Server Analyzer does not find one of the above values for the objectVersion attribute, an error is displayed.

This value is likely to be incorrect if you installed a pre-release version of Exchange 2000 Server or Exchange Server 2003 in the given domain, but did not run the released version of DomainPrep.

Note:
In Microsoft Exchange 2000 Server and Exchange Server 2003, you performed the Active Directory preparation steps by running setup /forestprep and setup /domainprep. Exchange 2007 does not have the /forestprep and /domainprep options. For Exchange Server 2007, you run the setup /PrepareDomain process, or the Setup Wizard, with an account that has the permissions required to prepare Active Directory and the domain.

To remedy this error for Exchange 2000 Server or Exchange Server 2003, run the final released version of Exchange 2000 Server DomainPrep, Exchange Server 2003 DomainPrep, or the final released version of the PrepareDomain process or Setup Wizard for Exchange Server 2007. The account you use to run DomainPrep, PrepareDomain, or the Setup Wizard must be a member of the Domain Admins security group in the local domain and a local computer administrator.

  • The root domain.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 computers.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 mailbox-enabled objects (such as users and groups), even if no Exchange servers will be installed in these domains.

  • All domains that will contain global catalog servers that Exchange directory access components may potentially use.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 users and groups that you will use to manage your Exchange organization.

To run DomainPrep for Exchange 2000 Server or Exchange Server 2003

  1. Insert the Exchange CD into your CD-ROM drive. You can run DomainPrep on any computer in the domain.

  2. At a command prompt, type <drive>:\setup\i386\setup /DomainPrep, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, ensure that Action is set to DomainPrep. If not, click the drop-down arrow, and then click DomainPrep. Click Next.

  7. On the Completing the Microsoft Exchange Wizard page, click Finish.

To run PrepareDomain for Exchange Server 2007

  1. Follow the step by step guidance at "How to Prepare Active Directory and Domains" (http://go.microsoft.com/fwlink/?LinkId=78453)

For more information about running Exchange Server 2003 DomainPrep, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about running Exchange 2000 Server DomainPrep, see "Microsoft Exchange 2000 Server Installation and Setup" (http://go.microsoft.com/fwlink/?LinkId=5906).

For more information about preparing Active Directory and Domains for Exchange Server 2007, see "How to Prepare Active Directory and Domains" (http://go.microsoft.com/fwlink/?LinkId=78453).


Domain Controller is running Virtual Server 2005 with Exchange Server installed as a Guest
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine if the value for the Model key is set to Virtual Machine.

The Exchange Server Analyzer also checks for the presence of the following registry value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

Additionally, the Exchange Server Analyzer reads the Domain Role key of the Win32_ComputerSystem on the physical computer that is running Microsoft Virtual Server 2005. A value greater than 3 indicates that the physical computer is a domain controller.

If the Exchange Server Analyzer finds that the Model key contains the string Virtual Machine, and that the above registry branch exists, and Domain Role is greater than 3, an error is displayed.

A value of Virtual Machine for the Model key indicates that the Exchange Server computer is running as a guest virtual machine on either Virtual Server 2005 or Microsoft Virtual PC 2004. Because the above registry branch is only created by Virtual Server 2005, its existence means that the Exchange Server computer is running as a guest virtual machine in Virtual Server 2005.

Microsoft does not support running any version of Exchange Server on a virtual machine or on an emulator. This is true for Exchange Server running on Virtual Server 2005, Virtual PC 2004, or any third-party virtual machine program. Exchange Server platforms are designed and tested to run only on physical hardware, particularly those hardware platforms that are listed in the Windows Server Catalog at http://go.microsoft.com/fwlink/?linkid=17219.

Further, running Exchange as a Virtual Server guest on a domain controller is not a best practice in that it does not allow for adequate redundancy across services.

To correct this error

  1. Move the mailboxes from the Exchange server running under Virtual Server 2005 to a non-virtual Exchange Server computer.

  2. Re-home any public folders and transfer any roles held by the virtual Exchange server as necessary.

  3. Uninstall Exchange from the virtual machine to decommission and remove from your Exchange infrastructure and from the Active Directory® directory service.

For more information about moving mailboxes, see the following Microsoft Knowledge Base articles:

  • 822892, "Move Mailbox improvements in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 224975, "XADM: Differences Between Move Mailbox Methods" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

For more information about support for Exchange Server computers running in virtual environments, see the Microsoft Knowledge Base article 320220, "Support Boundaries for Exchange Server on a Virtual Machine or an Emulation Machine" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220).

For more information about Microsoft Virtual Server 2005, visit http://go.microsoft.com/fwlink/?linkid=34938.

For more information about Microsoft Virtual PC 2004, visit http://go.microsoft.com/fwlink/?linkid=34663.


Domain Naming FSMO role did not respond
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the fSMORoleOwner attribute of the domain naming operations master in the Configuration Naming Context. For example, in a domain called contoso.com, fSMORoleOwner for the domain naming operations master is an attribute of CN=Partitions,CN=Configuration,DC=contoso,DC=com. The Exchange Server Analyzer then tries to open a Lightweight Directory Access Protocol (LDAP) connection to TCP port 389 on the domain controller that currently holds this role. If the Exchange Server Analyzer cannot connect to this domain controller, an error is displayed.

The domain naming master is a forest-wide operations master role because it manages the addition and removal of all directory partitions, regardless of domain, in the forest hierarchy. The domain controller that has the domain naming master role is the only domain controller that can do the following:

  • Add new domains to the forest.

  • Remove existing domains from the forest.

  • Add or remove cross-reference objects to external directories.

There can be only one domain naming master in the whole forest.

To correct this error

  1. Verify that the directory server specified in the error is online and accessible by Exchange servers in your organization.

  2. If this directory server has been decommissioned, you must assign the domain naming master role to another domain controller.

For more information about transferring the domain naming operations master role from one domain controller to another domain controller, see the following Microsoft Knowledge Base articles:

  • For Microsoft Windows Server™ 2003, see 324801, "How To View and Transfer FSMO Roles in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801).

  • For Microsoft Windows® 2000 Server, see 255690, "HOW TO: View and Transfer FSMO Roles in the Graphical User Interface" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690).


Domain Naming FSMO role not found
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the fSMORoleOwner attribute of the domain naming operations master in the Configuration Naming Context. For example, in a domain called contoso.com, fSMORoleOwner for the domain naming master is an attribute of CN=Partitions, CN=Configuration, DC=contoso, DC=com. The Exchange Server Analyzer then tries to open a Lightweight Directory Access Protocol (LDAP) connection with the domain controller. If the Exchange Server Analyzer finds that the domain controller specified in the fSMORoleOwner attribute does not respond, an error is displayed.

The domain naming master domain controller controls the addition or removal of domains in the forest. There can be only one domain naming master in the whole forest.

You must have a domain naming master defined for your Active Directory forest. Exchange Setup and Exchange Service Pack Setup will fail if a domain naming master domain controller is not online during set up. If the domain controller listed as the domain naming master is offline, it must be brought back online.

To correct this error

  1. Verify that the designated Active Directory server is physically present.

  2. If this directory server has been decommissioned, assign the role of domain naming master to another domain controller.

For more information about how to assign the role of domain naming master to another domain controller, see the following Microsoft Knowledge Base articles:

  • For Microsoft Windows Server™ 2003, see 324801, "How To View and Transfer FSMO Roles in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801).

  • For Microsoft Windows® 2000 Server, see 255690, "HOW TO: View and Transfer FSMO Roles in the Graphical User Interface" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690).


Directory Server DNS name resolution failure
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool attempts a Domain Name System (DNS) query against the configured DNS servers for each Active Directory® directory service server. This connection is made by using a custom object processor that performs a name resolution request and analyzes the results. If the Exchange Server Analyzer does not receive an IP address as part of the query results, an error is displayed.

This error indicates that a directory server was not found in DNS. Both Exchange Server and Active Directory require correctly configured and healthy DNS to operate correctly. DNS registration and resolution issues can have widespread effects on the ability to send, receive, and deliver messages.

You must configure DNS correctly to ensure that Active Directory and Exchange Server will function correctly. For a more in-depth treatment of DNS configuration for Active Directory, see the Microsoft Knowledge Base article 237675, "Setting Up the Domain Name System for Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=237675).

To correct this error

  1. Review the following configuration items to ensure that DNS is healthy and that the Active Directory DNS entries will be registered correctly:

    • DNS IP configuration

    • Dynamic zone updates

    • DNS forwarders

  2. Check for the existence of a Root Zone entry. View the Forward Lookup zones in the DNS Management console. There should be an entry for the domain. Other zone entries may exist. There should not be a dot (".") zone. If the dot (".") zone exists, delete the dot (".") zone. The dot (".") zone identifies the DNS server as a root server. Typically, an Active Directory domain that needs external (Internet) access should not be configured as a root DNS server. Manually reregister the directory server IP address using Ipconfig /registerdns on the directory server after you delete the dot ("."). The Netlogon service may also need to be restarted.

  3. Manually repopulate Active Directory DNS entries using netdiag /fix on the directory server.

For more information about using DNS with Active Directory, see the Microsoft Knowledge Base article 323418, "How To Integrate DNS with an Existing DNS Infrastructure If Active Directory Is Enabled in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=323418).

For more information about troubleshooting DNS and Active Directory issues, see the Microsoft Knowledge Base article 260371, "Troubleshooting Common Active Directory Setup Issues in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260371).


dSHeuristics is not set correctly for Hosted Exchange
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the deployment is a Hosted Exchange deployment. If the Exchange deployment is running in a hosted environment, the Exchange Server Analyzer queries Active Directory to determine whether the dSHeuristics attribute on the Directory Service container is set correctly for a Hosted Exchange deployment.

If the value of dSHeuristics is not equal to 1, the Exchange Server Analyzer displays a warning. In a Hosted Exchange environment, the dSHeuristics attribute should be set to 1.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this warning

  1. Use an Active Directory editor, such as ADSI Edit, to locate the Directory Service object in Active Directory.

    The dSHeuristics attribute can be found at

    CN=Configuration, CN=Services, CN=Windows NT, CN=Directory Service

  2. Enter a value of 1 for dSHeuristics.

For more information about Hosted Exchange environments, see the following articles:

  • "Information for Hosters" (http://go.microsoft.com/fwlink/?LinkId=46307)

  • "Hosted Service Environments" in the Exchange Server 2000 Resource Kit (http://go.microsoft.com/fwlink/?LinkId=46326)


Duplicate Microsoft Exchange System Objects container exists in Active Directory
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the Microsoft Exchange System Objects container exists in the Domain Naming context.

If the Exchange Server Analyzer discovers a duplicate Microsoft Exchange System Objects container exists in Active Directory, the Exchange Server Analyzer displays an error: "Active Directory domain appears to be prepared for Exchange but there are multiple 'Microsoft Exchange System Objects' containers in existence. Clean up may be necessary."

This issue may occur in Exchange Server environments in which:

  • A 2-way Active Directory Connector (ADC) server Connection Agreement from Active Directory to Exchange Server 5.5 was deleted and replaced.

  • A new 1-way ADC server Connection Agreement from Exchange Server 5.5 to Active Directory is in place.

  • A mixed-mode environment running Exchange Server 5.5 was migrated to an Exchange Server 2003 environment.

  • A migration to Exchange Server 2003 from a foreign mail server has been performed.

When the Exchange Server Analyzer displays this error, you must delete the incorrect duplicate Microsoft Exchange System Objects container or organizational unit (OU). When a duplicate Microsoft Exchange System Objects container exists, you cannot solve the problem by running DomainPrep again. You must identify and delete the incorrect duplicate Microsoft Exchange System Objects container.

To remove the duplicate Microsoft Exchange System Object container

  1. Log on to the domain controller with administrative credentials.

  2. Click Start, click Programs, click Administrative Tools and then click Active Directory Users and Computers.

  3. In the Active Directory Users and Computers management console pane, click View from the toolbar menu and select Advanced Features.

  4. In the Active Directory Users and Computers management console pane, locate the incorrect, duplicate Microsoft Exchange System Objects container or organizational unit (OU).

  5. Verify the incorrect, duplicate Microsoft Exchange System Objects container or OU does not contain valid Active Directory objects.

  6. Right-click the incorrect, duplicate Microsoft Exchange System Objects container or OU and then click Delete.

  7. Confirm the deletion by clicking Yes in the Active Directory dialog box.

    Note:
    If you want the change to be replicated immediately, you must manually initiate replication between domain controllers.

For more information about this issue with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 316280, "XADM: A Description of the 'ADC Global Names' Attribute" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=316280)

  • 252228, "XADM: ADC Appears to Create Duplicate Objects" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=252228)

  • 253800, "XADM: ADC May Create Duplicate Objects in Active Directory" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=253800)

  • 274480, "XADM: Duplicate Object Created When Replicating Objects from Exchange Server 5.5 to Windows 2000 Active Directory" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=274480)

  • 288578, "XADM: ADC Creates Duplicate Accounts in Exchange Server 5.5 and Active Directory" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=288578)


Error Accessing Active Directory
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool has determined that an Active Directory® directory service domain controller may not be available. Verify that you have network connectivity to an Active Directory domain controller.

To correct this error

  • If you specified an Active Directory domain controller in the Exchange Server Analyzer, try connecting without specifying a domain controller.

  • If you have not specified a domain controller, specify a domain controller that is running and is available to you.


Error Accessing Exchange Administrative Groups
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool has determined that an Exchange organization has been installed in the Active Directory® directory service forest and that you were successful in accessing the Exchange organization configuration information in Active Directory. However, no administrative groups that contain Exchange servers were found.

To correct this error:

  • Verify that you have the appropriate permissions in Active Directory to access the container for Exchange administrative groups.

  • If the workstation from which you are running the Exchange Server Analyzer belongs to a different Active Directory forest, or you are not logged on with a domain account, you may have to connect to an Active Directory domain controller for a forest that hosts Exchange servers.


Error Accessing Exchange Configuration Container
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool has determined that the Exchange configuration container is inaccessible. Exchange organizational, administrative group, and server configuration information is stored in the Configuration naming context in the Active Directory® directory service. To access any Exchange configuration information, you must be able to read the Microsoft Exchange branch of the Active Directory Configuration container.

To correct this error:

  • Verify that you have the permissions that are required to read the Active Directory Configuration container.

  • Verify that you have network connectivity to an Active Directory domain controller.


Everyone security group is not denied the right to create top-level public folders
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-12-04

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the security identifier (SID) for the Everyone security group is listed in the ntSecurityDescriptor of the Exchange Organization object. If the Exchange Server Analyzer finds the SID for the Everyone group present in the ntSecurityDescriptor of the Organization object, a warning is displayed. This warning indicates that the Everyone group has not been denied the right to create top-level public folders.

In Exchange 2000 Server, the right to create top-level public folders is allowed by default. However, when the Exchange Server 2003 version of ForestPrep or the Exchange Server 2007 of PrepareAD is run, the Everyone security group is denied access to create top-level public folders. The deny functionality has been implemented as a security measure. Allowing the Everyone security group to create top-level public folders may leave your organization vulnerable to denial of service attacks.

Therefore, it is a best practice to deny the right to create top-level public folders to the Everyone security group. If you have Exchange Server 2003 or Exchange Server 2007, you should run the Exchange Server 2003 version of ForestPrep or the Exchange Server 2007 version of PrepareAD, respectively. You can run the Exchange Server 2003 version of ForestPrep in an Exchange 2000 Server environment. However, subsequent installations of Exchange 2000 Server will reset the permissions to allow the Everyone security group to create top-level public folders.

If you do not have Exchange Server 2003 or Exchange Server 2007, you can set this permission manually. Remember that subsequent installations of Exchange 2000 Server will reset this permission. Therefore, you must manually configure this permission after each installation of Exchange 2000 Server. Before you can set the permission, you must enable the Security tab to be displayed in Exchange System Manager, which you can do by adding the ShowSecurityPage entry to the registry on the Exchange Server computer.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry, if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To add the ShowSecurityPage entry to the registry

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExAdmin

  3. Click Edit, click New, and then click DWORD Value.

  4. For the new value name, type ShowSecurityPage, and then press ENTER.

  5. Double-click ShowSecurityPage, type 1 in the Value data field, and then click OK.

To manually deny the Everyone security group the right to create top-level public folders in an Exchange 2000 Server environment

  1. Open Exchange System Manager.

  2. Right-click Organization_Name, and then click Properties.

  3. On the Organization_Name properties page, click the Security tab.

  4. On the Security tab, in Group or user names, select Everyone. In the Permissions for Everyone box, scroll down to the Create top-level public folder permission, clear the check box in the Allow column, and then click Apply.

Before you edit the registry, and for information about how to edit the registry, read Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about running Exchange Server 2003 ForestPrep, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about running Exchange Server 2007 PrepareAD, see "How to Prepare Active Directory and Domains" (http://go.microsoft.com/fwlink/?LinkId=78453).

For more information about how to deny the Everyone security group the rights to create a top-level public folder in Exchange 2000 Server, see the Knowledge Base article 328808, "HOW TO: Remove User Permission from the Create Top-Level Public Folder in Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328808).


Exchange domain container problem
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine if the Microsoft Exchange System Objects container in the Domain Naming Context exists. If the Exchange Server Analyzer finds the Microsoft Exchange System Objects container does not exist or is otherwise invalid or malformed, an error is displayed.

The Microsoft Exchange System Objects container is created in each domain when Exchange DomainPrep is run.

You must run DomainPrep in the domain where this error is found. The domain name where the Microsoft Exchange System Objects container is missing is listed in the Exchange Server Analyzer output.

The account you use to run DomainPrep must be a member of the Domain Admins security group in the local domain and a local computer administrator.

In general, you must run DomainPrep in the following domains:

  • The root domain.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 computers.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 mailbox-enabled objects (such as users and groups), even if no Exchange servers will be installed in these domains.

  • All domains that will contain global catalog servers that Exchange directory access components may potentially use.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 users and groups that you will use to manage your Exchange organization.

To run DomainPrep

  1. Insert the Exchange CD into your CD-ROM drive. You can run DomainPrep on any computer in the domain.

  2. At a command prompt, type <drive>:\setup\i386\setup /DomainPrep, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, ensure that Action is set to DomainPrep. If not, click the drop-down arrow, and then click DomainPrep. Click Next.

  7. On the Completing the Microsoft Exchange Wizard page, click Finish.

For more information about running Exchange Server 2003 DomainPrep, see the Exchange 2003 Server Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about running Exchange 2000 Server DomainPrep, see the technical paper, "Microsoft Exchange 2000 Server Installation and Setup" (http://go.microsoft.com/fwlink/?LinkId=5906).


Exchange domain servers group not found
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the ntSecurityDescriptor attribute of the Microsoft Exchange System Objects object to determine which version of DomainPrep has been run in the domain.

There are two valid integers:

  • For Exchange 2000 Server, the ntSecurityDescriptor value is 4406.

  • For Exchange Server 2003, the ntSecurityDescriptor value is 6936.

If it is determined that either of the above versions of DomainPrep were used, the Exchange Server Analyzer queries Active Directory to determine the value of the objectGuid attribute of the Microsoft Exchange System Objects object to determine whether the Exchange Domain Servers group exists. If the Exchange Server Analyzer determines that this group does not exist, an error is displayed.

To resolve this error, run the final release version of Exchange 2000 Server DomainPrep or Exchange Server 2003 DomainPrep. The account you use to run DomainPrep must be a member of the Domain Admins security group in the local domain and a local computer administrator.

You must run DomainPrep in the following domains:

  • The root domain.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 computers.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 mailbox-enabled objects (such as users and groups), even if no Exchange servers will be installed in these domains.

  • All domains that will contain global catalog servers that Exchange directory access components may potentially use.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 users and groups that you will use to manage your Exchange organization.

To run DomainPrep

  1. Insert the Exchange CD in your CD drive. You can run DomainPrep on any computer in the domain.

  2. At a command prompt, type <drive>:\setup\i386\setup /DomainPrep, where <drive> is your CD drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, ensure that Action is set to DomainPrep. If not, click the drop-down arrow, and then click DomainPrep. Click Next.

  7. On the Completing the Microsoft Exchange Wizard page, click Finish.

For more information about running Exchange Server 2003 DomainPrep, see the Exchange 2003 Server Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about running Exchange 2000 Server DomainPrep, see "Microsoft Exchange 2000 Server Installation and Setup" (http://go.microsoft.com/fwlink/?LinkId=5906).


Exchange Enterprise Servers group not found
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the ntSecurityDescriptor attribute of the Microsoft Exchange System Objects object to determine which version of DomainPrep has been run in the domain.

There are two valid integers:

  • For Exchange 2000 Server, the ntSecurityDescriptor value is 4406.

  • For Exchange Server 2003, the ntSecurityDescriptor value is 6936.

If it is determined that either of the above versions of DomainPrep were used, the Exchange Server Analyzer queries Active Directory to determine the value of the objectGuid attribute of the Microsoft Exchange System Objects object to determine whether the Exchange Enterprise Servers group exists. If the Exchange Server Analyzer determines that this group does not exist, an error is displayed.

To resolve this error, run the final release version of Exchange 2000 Server DomainPrep or Exchange Server 2003 DomainPrep. The account you use to run DomainPrep must be a member of the Domain Admins security group in the local domain and a local computer administrator.

You must run DomainPrep in the following domains:

  • The root domain.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 computers.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 mailbox-enabled objects (such as users and groups), even if no Exchange servers will be installed in these domains.

  • All domains that will contain global catalog servers that Exchange directory access components may potentially use.

  • All domains that will contain Exchange 2000 Server or Exchange Server 2003 users and groups that you will use to manage your Exchange organization.

To run DomainPrep

  1. Insert the Exchange CD in your CD drive. You can run DomainPrep on any computer in the domain.

  2. At a command prompt, type <drive>:\setup\i386\setup /DomainPrep, where <drive> is your CD drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, ensure that Action is set to DomainPrep. If not, click the drop-down arrow, and then click DomainPrep. Click Next.

  7. On the Completing the Microsoft Exchange Wizard page, click Finish.

For more information about running Exchange Server 2003 DomainPrep, see the Exchange 2003 Server Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about running Exchange 2000 Server DomainPrep, see "Microsoft Exchange 2000 Server Installation and Setup" (http://go.microsoft.com/fwlink/?LinkId=5906).


Exchange object in Lost and Found container
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-12-01

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether any objects exist in the LostAndFoundConfig container under the Configuration container. If the Exchange Server Analyzer finds that objects exist in the LostAndFoundConfig container, an error is displayed together with the object and the object class from which the object derives.

The LostAndFoundConfig container holds objects that cannot be reconciled by Active Directory. Make sure that you delete any objects that are in the LostAndFoundConfig container, because Exchange will try to use these objects. For example, when Exchange queries Active Directory by object class (that is, Servers), all objects—regardless of whether they might be in the LostAndFoundConfig container—are returned as valid objects. The result is that Exchange may try to connect to the Server that is under the LostAndFoundConfig container instead of the real object. This could lead to unpredictable behavior by Exchange and even server failure. The presence of these objects may also prevent objects of the same class from being created.

To resolve this issue, you must remove the entries in the LostAndFoundConfig container from Active Directory by using Active Directory Service Interfaces (ADSI) Edit.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.
Note:
ADSI Edit is a tool that is provided with the Windows 2000 Server and Windows Server 2003 Support tools.

To correct this error

  1. Open the ADSI Edit MMC snap-in.

  2. On the Action menu, click Connect to.

  3. In the Connection Settings dialog box, in the Name field, enter a name for the ADSI connection. Under Connection Point, select Select a well known Naming Context, and then select Configuration in the drop-down menu. Click OK.

  4. In the left pane, double-click the Configuration object, and then double-click LostAndFoundConfig.

  5. In the right pane, delete all objects and containers. Right-click the object or container, click Delete, and then click Yes.

  6. Exit ADSI Edit.


Exchange organization has zero recipient policies
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the Name attribute in the Recipient Policies object for each Exchange organization. If the Exchange Server Analyzer determines that there is no Recipient Policies object or that the Recipient Policies object does not contain any recipient policies, an error is displayed.

When Exchange Server is installed, a default recipient policy that applies Simple Mail Transfer Protocol (SMTP) and X.400 addresses to all recipients in your Exchange organization is created. You can modify the default policy or create new policies. However, you must not delete the default policy. All recipients in an Exchange organization must have both SMTP and X.400 addresses. If the Exchange organization has no recipient policies, it will experience reliability issues.

To create a recipient policy

  1. Click Start, click All Programs, click Microsoft Exchange, and then click System Manager.

  2. In the left pane of Exchange System Manager, expand the organization, expand Recipients, right-click Recipient Policies, point to New, and then click Recipient Policy.

  3. In the New Policy dialog box, choose the type of policy that you want to create by selecting the E-mail Addresses check box, the Mailbox Manager Settings check box, or both, and then click OK.

  4. In the Properties dialog box, type a name for the new recipient policy, and then click Modify to create a filter for the recipient policy.

    Note:
    If you do not create a filter, the policy will not be applied to any recipients.

  5. To customize the recipient policy, switch to the E-Mail Addresses (Policy) tab or the Mailbox Manager Settings (Policy) tab in the Properties dialog box. Use the settings on these tabs to configure the recipient policy, and then click OK to create the policy.

  6. Right-click the recipient policy in Exchange System Manager, and then click Apply Policy Now.

For more information about recipients and recipient policies, see "Managing Recipients and Recipient Policies" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).

For more information about how to create and configure recipient policies, see Microsoft Knowledge Base article 249299, "HOW TO: Configure Recipient Policies in Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=249299).


Exchange organization has zero system policies
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the name of each system policy in the System Policies object for each Exchange organization. If the Exchange Server Analyzer determines that there is no system policies object or that the system policies object does not contain any system policies, an error is displayed.

You can use system policy objects to simplify system administration by configuring parameters for multiple Exchange servers through a single configuration object, such as mailbox store, public folder store, or server settings. By default, the following system policies are created when you run ForestPrep on your organization:

  • Hidden DL Membership

  • Mail-Enabled Recipient

  • Mailbox-Enabled User

If these default system policies do not exist in your Exchange organization, you will experience reliability issues. To re-create the default system policies, you must run ForestPrep.

To run Exchange Server 2003 ForestPrep

  1. Insert the Exchange CD into your CD drive.

  2. On the Start menu, click Run, and then type drive:\setup\i386\setup /ForestPrep, where drive is your CD drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you accept the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, verify that Action is set to ForestPrep. If it is not, click the drop-down arrow, and then click ForestPrep. Click Next.

    Important:
    If ForestPrep does not appear under Action, you may have misspelled the ForestPrep command in Step 2. If you have misspelled the ForestPrep command, go back to Step 2 and retype the command.

  7. On the Microsoft Exchange Server Administrator Account page, in the Account box, type the name of the account or group that is responsible for installing Exchange.

    Note:
    The account that you specify will also have permission to use the Exchange Administration Delegation Wizard to create other Exchange administrator accounts. For more information about the Exchange Administration Delegation Wizard, see the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?linkid=47617).

  8. Click Next to start ForestPrep. After ForestPrep starts, you cannot cancel the process.

    Note:
    Depending on your network topology and the speed of your Microsoft Windows® 2000 Server or Microsoft Windows Server™ 2003 domain controller, ForestPrep may take a long time to complete.

  9. On the Completing the Microsoft Exchange Wizard page, click Finish.

For information about how system policies are used in Exchange, see Microsoft Knowledge Base article 253838, "XADM: How the Recipient Update Service Applies System Policies" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=253838).

For more information about system policies, see "Exchange System Manager Architecture" in the Exchange Server 2003 Technical Reference Guide (http://go.microsoft.com/fwlink/?LinkId=47891).

For information about how to create non-default system policies in Exchange, see the Knowledge Base article 256141, "How to Create System Policies in Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256141).


Global Catalog NSPI port has been overridden
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2007-01-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry on global catalog servers to determine whether the TCP/IP Port registry key is set:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\TCP/IP Port

If the Exchange Server Analyzer finds that the TCP/IP Port registry key has been created and is set, a non-default configuration message is displayed.

The TCP/IP Port registry key is required when a global catalog server needs to use a specific port for servicing MAPI clients. If you do not have such a requirement in your Exchange environment, you can remove this key.

.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To delete the TCP/IP port on the global catalog server

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

  3. Right-click the TCP/IP Port key, and then click Delete.

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about configuring RPC over HTTP, see the following Knowledge Base articles:

  • 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)

  • 298369, "How to Configure a Global Catalog Server to Use a Specific Port When Servicing MAPI Clients" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298369)

  • 24823, "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=24823)


Global catalog port 3268 not responding
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries Active Directory® directory service to determine the value of the isGlobalCatalogReady attribute of this server. A value of True for this attribute indicates that the directory server is also a functioning global catalog server, and a value of False indicates that the directory server is not a global catalog server

Then the Exchange Server Analyzer connects to port 3268 on the Exchange server to verify that the port is responding.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The server is a global catalog server.

  • The port 3268 is not responding.

Note:
This message may be displayed in error if there is a firewall between the computer running the Exchange Server Analyzer and the global catalog server.

This problem typically occurs when the global catalog server check box has been selected but the server has not been restarted.

To correct this issue

  • Restart the server.

For more information about promoting domain controllers, see Microsoft Knowledge Base article 304403, "XADM: Exchange Considerations for Promoting a Domain Controller to a Global Catalog Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=304403)


Group class schema error
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-12-01

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchBaseClass class appears in the auxiliaryClass attribute of Group objects in the Active Directory schema.

Active Directory has predefined classes that define all the different object types that the directory must have to function correctly. Object definitions are created by nesting classes inside each other. Nesting classes produces a parent/child relationship between the classes.

The msExchBaseClass class is added to the Active Directory when you install Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007. The msExchBaseClass class is the base auxiliary class that is applied to all classes that are extended by CDO for Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007 (CDOEX). CDOEX provides the fundamental Component Object Model (COM) classes and interfaces that are used to manage most types of information in the Exchange store.

Incorrectly modifying the Active Directory schema may break the relationship between the msExchBaseClass class and the auxiliaryClass attribute of Group objects. This break could cause Exchange server instability, such as Recipient Update Services processing errors, or prevent the installation of new Exchange Server 200x servers into the organization.

If the Exchange Server Analyzer finds the msExchBaseClass class does not appear in the auxiliaryClass attribute of Group objects in the Active Directory schema, this indicates that this relationship is broken. If the msExchBaseClass class does not appear in the auxiliaryClass attribute of Group objects in the Active Directory schema, the Exchange Server Analyzer displays an error.

To correct this error, contact Microsoft Customer Support Services (http://go.microsoft.com/fwlink/?LinkId=41364).


Hosted Exchange requires a native mode Exchange organization
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the Exchange Server environment is configured as a Hosted Exchange environment. If the Exchange Server environment is a Hosted Exchange environment, the Exchange Server Analyzer queries Active Directory to determine whether the Exchange organization is running in mixed mode.

If the Exchange organization is running in mixed mode, a warning is displayed. Hosted Exchange solutions require a native mode organization.

After you switch to native mode you cannot switch back to mixed mode.

To switch to native mode

  1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In the console tree, right-click the organization that you want to switch to native mode, and then click Properties.

  3. In <Organization Name> Properties, under Change operation mode, click Change Mode.

  4. In the warning dialog box, click Yes if you are sure that you want to permanently switch to native mode. Click Apply to accept your new Exchange mode.

To take full advantage of Exchange native mode, you must restart the Microsoft Exchange Information Store service on all the Exchange servers in your organization. You do not have to restart all the Microsoft Exchange Information Store services at the same time, but you must restart the service on each server for the server to take advantage of all Exchange native mode features. Restart the service on your servers after the change to native mode has been replicated to the local Microsoft Windows® domain controller.

To restart the Microsoft Exchange Information Store service

  1. Click Start, click Run, type services.msc, and then click OK.

  2. In the Services (Local) pane, find the Microsoft Exchange Information Store service.

  3. Right-click the service and then click Restart.

For more information about Hosted Exchange environments, see the following articles:

  • "Information for Hosters" (http://go.microsoft.com/fwlink/?LinkId=46307)

  • "Chapter 23 - Hosted Service Environments" in the Exchange Server 2000 Resource Kit (http://go.microsoft.com/fwlink/?LinkId=46326)

For more information about converting from mixed to native mode, see Microsoft Knowledge Base article 32779, "How To Convert from Mixed Mode to Native Mode in Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327779).


Infrastructure FSMO server role did not respond
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the fSMORoleOwner attribute of the infrastructure master in the Domain Naming Context. For example, in a domain called contoso.com, fSMORoleOwner for the infrastructure master is an attribute of CN=Infrastructure,DC=contoso,DC=com. The Exchange Server Analyzer then tries to open a Lightweight Directory Access Protocol (LDAP) connection to TCP port 389 on the domain controller that currently holds this role. If the Exchange Server Analyzer cannot connect to this domain controller, an error is displayed.

The infrastructure master updates the group-to-user references whenever the members of groups are renamed or changed within a domain. The domain controller that holds the infrastructure master role for the group's domain updates the cross-domain group-to-user reference to reflect the user's new name. Periodically, the infrastructure master scans the domain accounts and verifies the membership of the groups. If a user account is moved to a new domain, the infrastructure master identifies the user account's new domain and updates the group accordingly. After the infrastructure master updates these references locally, it uses replication to update all other replicas of the domain. If the infrastructure master is unavailable, these updates are delayed. At any time, there can be only one domain controller acting as the infrastructure master in each domain.

To correct this error

  1. Verify that the directory server specified in the error is online and accessible by Exchange servers in your organization.

  2. If this directory server has been decommissioned, you must assign the infrastructure master role to another domain controller.

For more information about transferring the infrastructure master role from one domain controller to another domain controller, see the following Microsoft Knowledge Base articles:

  • For Microsoft Windows Server™ 2003, see 324801, "How To View and Transfer FSMO Roles in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801)

  • For Microsoft Windows 2000 Server, see 255690, "HOW TO: View and Transfer FSMO Roles in the Graphical User Interface" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690)


Invalid version attribute on the Exchange organization object
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2007-02-28

The Microsoft Exchange Server Analyzer tool queries the Active Directory directory service to determine the schema version information for Exchange. Specifically, the Exchange Server Analyzer examines the following Active Directory object to determine the current value for the rangeUpper attribute:

CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=<DN-of-forest-root-domain>

A rangeUpper value of 4397 indicates that Exchange 2000 Server is installed.

A rangeUpper value of 6870 indicates that Exchange Server 2003 is installed.

A rangeUpper value of 10637 indicates that Exchange Server 2007 is installed.

If the Exchange Server Analyzer finds any other value for rangeUpper, an error is displayed.

The rangeUpper value is entered by Exchange 2000 Server or Exchange Server 2003 during the ForestPrep process. A value other than 4397, 6870, or 10637 typically indicates that a beta or pre-release version of Exchange was used to perform ForestPrep or, in the case of Exchange Server 2007, PrepareDomain.

To resolve this problem for Exchange 2000 Server or Exchange Server 2003, rerun the ForestPrep process using the release version of Exchange that is installed in your environment. For Exchange Server 2007, rerun PrepareSchema using the release version of Exchange that is installed in your environment. You must run ForestPrep or PrepareSchema while logged on with an account that has a minimum of the following rights:

  • Enterprise Administrator

  • Schema Administrator

  • Domain Administrator

  • Local Machine Administrator (if running on member server only)

To correct this error for Exchange 2000 Server or Exchange Server 2003

  1. Run setup.exe /forestprep.

  2. Verify that the ForestPrep process has completed successfully.

To correct this error for Exchange Server 2007

  1. Run setup.exe /PrepareSchema.

  2. Verify that the PrepareSchema process has completed successfully.

For details about how to install Exchange and perform the PrepareSchema process, see the following product documentation:

  • "How to Prepare Active Directory and Domains" http://go.microsoft.com/fwlink/?LinkId=78453

For details about how to install Exchange and perform the ForestPrep process, see the following Microsoft Knowledge Base articles:

  • 312371, "HOW TO: Prepare the Forest by Using ForestPrep in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=312371). This article applies to both Exchange 2000 Server and Exchange Server 2003.

  • 274737, "How to Verify That ForestPrep and DomainPrep Completed Successfully in Exchange 2000 Server or Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=274737).

  • 828765, "Permissions that you must have to install components in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828765).


Legacy account information present in native mode administrative group
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine if the msExchLegacyAccount attribute on each Exchange administrative group object contains data.

The Exchange Server Analyzer also queries Active Directory to determine the value of the msExchAdminGroupMode attribute of each administrative group. A value of 0 for the msExchAdminGroupMode attribute indicates the administrative group is in Exchange native mode. A value of 1 indicates a pure Exchange Server 5.5 environment, and a value of 2 indicates Exchange mixed mode.

If the Exchange Server Analyzer finds that the msExchLegacyAccount attribute contains data, and that the value for the msExchAdminGroupMode attribute is 0, an error is displayed.

When you switch to Exchange native mode, the msExchLegacyAccount attribute is deleted. This attribute is only used in mixed mode Exchange organizations where Exchange Server 5.5 is still present. The actual attribute data is the Exchange Server 5.5 service account, and its presence in the msExchLegacyAccount attribute in a native mode Exchange organization will cause malfunctions during upgrades and service pack installations. In fact, just the presence of the attribute, even without data in it, will cause malfunctions. This is because Exchange Setup uses this attribute as a means of discovering whether an Exchange organization is in mixed mode or native mode. If this attribute exists, Exchange Setup runs in a mixed mode configuration for an installation that is actually in native mode.

It is likely that the msExchLegacyAccount attribute still exists if you manually removed data from Active Directory using the Active Directory Service Interfaces (ADSI) Edit snap-in.

You must remove this data from the msExchLegacyAccount by manually editing the attribute with the LDP (ldp.exe) tool. You must use the LDP tool or another Lightweight Directory Access Protocol (LDAP) version 3 client that will completely remove both the data and the attribute from the directory. The ADSI Edit snap-in is not sufficient in this case, because it only removes the data, and leaves the attribute. LDP.exe is included in the Windows® Support Tools package.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both.. Modify Active Directory object attributes at your own risk.

To remove the msExchLegacyAccount attribute

  1. Start LDP.exe.

  2. On the Connection menu, click Connect; in the Connect dialog box, enter the name of a Domain Controller in the same Active Directory forest as your Exchange Organization, and then click OK.

  3. On the Connection menu, click Bind; in the Bind dialog box, enter credentials that have at least Exchange Full Admin rights at the Administrative Group level, and then click OK.

  4. On the View menu, click Tree; in the Tree View dialog box, leave the field empty if you are connecting from the root domain, otherwise, enter CN=Configuration,DC=Domain_name, DC=Domain_suffix where Domain_name is the root domain in the Active Directory forest and where Domain_suffix is the domain suffix, for example, com, net, and org. Click OK.

  5. Expand the hierarchy view in the left pane of LDP until you open your administrative group. To do this, double-click the nodes in the following order (note that each node in LDP is followed by the full Distinguished Name (DN); only the left-most CNs are noted here for clarity):

    1. DC=Domain_name

    2. CN=Configuration

    3. CN=Services

    4. CN=Microsoft Exchange

    5. CN=Organization_name

    6. CN=Administrative Groups

    7. CN=Administrative_group_name

    In the details (right) pane of LDP, scroll down to view the attributes of your administrative group. If the msExchLegacyAccount attribute is there, you must delete it. If the msExchLegacyAccount attribute is there, it is likely that the msExchLegacyDomain and the msExchEncryptedPassword attributes are also present. If they are, you must delete these as well.

  6. In the hierarchy (left) pane of LDP, right-click Administrative_group_name and then click Modify.

  7. In the Modify dialog box, verify that the full DN listed in the Dn field is correctly identifying the administrative group you need to modify. It should read: CN=Administrative_group_name,CN=Administrative Groups,CN=Organization_name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain_name.

  8. In the Modify dialog box, under Operations, select Delete; under Edit entry, enter msExchLegacyAccount in the Attribute field, and then click Enter. This adds msExchLegacyAccount to the Entry List. The Entry List defines the attributes that will be deleted when you click Run.

  9. If either the msExchLegacyDomain or the msExchEncryptedPassword attributes exist in the administrative group, add them to the Entry List as described in Step 8.

  10. When the Entry List contains the attributes that you must delete, click Run. A status message will appear in the LDP details pane.

  11. On the Connection menu, click New to clear the LDP details pane.

  12. Navigate to CN=Administrative_group_name and double-click the object. Review the contents of the right pane to verify that the attributes are deleted.

For more information about modifying Active Directory with the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).


The legacyExchangeDN attribute for the Exchange organization is invalid
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2007-02-01

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the format for the legacyExchangeDN attribute on the Exchange organization object. If the Exchange Server Analyzer finds the legacyExchangeDN attribute invalid or malformed, an error is displayed.

This value for this attribute is of the form /o=Organization, where Organization is the name of the Exchange organization. If the value begins with anything other than /o= or /O=, it is considered malformed. This problem should be corrected as soon as possible.

To correct this error for Exchange 2000 Server or Exchange Server 2003

  1. Perform the Exchange Server ForestPrep process. During this process, if the Setup program determines that legacyExchangeDN is in the wrong format, it will automatically correct the problem.

To correct this error for Exchange Server 2007

  1. Perform the Exchange Server PrepareAD process. During this process, if the Setup program determines that legacyExchangeDN is in the wrong format, it will automatically correct the problem.

For more information about the ForestPrep process, see the Microsoft Knowledge Base article 312371, "HOW TO: Prepare the Forest by Using ForestPrep in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=312371).

For more information about the PrepareAD process, see "How to Prepare Active Directory and Domains" (http://go.microsoft.com/fwlink/?LinkId=78453).

For more information about the legacyExchangeDN attribute and how to change it, see the following Microsoft Knowledge Base articles:

  • 324606, "How to use Legacydn.exe to correct Exchange organization names or Administrative Group names in Exchange Server 2003 or in Exchange 2000 Server" (http://go.microsoft.com/fwl i nk/?linkid=3052&kbid=324606).

  • 286783, "XADM: Error Message Updating Free and Busy Data in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=286783).

  • 301585, "XADM: Workarounds for Problems with MBconn.exe" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301585).


Legacy domain information present in native mode administrative group
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchLegacyDomain attribute on each Exchange Administrative Group object contains data.

The Exchange Server Analyzer also queries Active Directory to determine the value of the msExchAdminGroupMode attribute of each administrative group. A value of 0 for the msExchAdminGroupMode attribute indicates the administrative group is in Exchange native mode. A value of 1 indicates a pure Exchange Server 5.5 environment, and a value of 2 indicates Exchange mixed mode.

If the Exchange Server Analyzer finds that the msExchLegacyDomain attribute contains data, and that the value for the msExchAdminGroupMode attribute is 0, an error is displayed.

When you switch Exchange to native mode, the msExchLegacyDomain attribute is deleted. This attribute is only used in mixed mode Exchange organizations where Exchange Server 5.5 is still present. The actual attribute data is the Exchange Server 5.5 service account domain, and its presence in the msExchLegacyDomain attribute in a native mode Exchange organization will cause malfunctions during upgrades and service pack installations. In fact, just the presence of the attribute, even without data in it, will cause malfunctions. This is because Exchange Setup uses this attribute as a way of discovering whether an Exchange organization is in mixed mode or native mode. If this attribute exists, Exchange Setup runs in a mixed mode configuration for an installation that is actually in native mode.

It is likely that the msExchLegacyDomain attribute still exists if you manually removed data from Active Directory using the Active Directory Service Interfaces (ADSI) Edit snap-in.

You must remove this data from the msExchLegacyDomain by manually editing the attribute with the LDP (ldp.exe) tool. You must use the LDP tool or another Lightweight Directory Access Protocol (LDAP) version 3 client that will completely remove both the data and the attribute from the directory. The ADSI Edit snap-in is not sufficient in this case, because it only removes the data, but leaves the attribute. LDP.exe is included in the Windows® Support Tools package.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To remove the msExchLegacyDomain attribute

  1. Start LDP.exe.

  2. On the Connection menu, click Connect; in the Connect dialog box, enter the name of a Domain Controller in the same Active Directory forest as your Exchange Organization, and then click OK.

  3. On the Connection menu, click Bind; in the Bind dialog box, enter credentials that have at least Exchange Full Admin rights at the Administrative Group level, and then click OK.

  4. On the View menu, click Tree; in the Tree View dialog box, leave the field empty if you are connecting from the root domain, otherwise, enter CN=Configuration,DC=Domain_name, DC=Domain_suffix where Domain_name is the root domain in the Active Directory forest and where Domain_suffix is the domain suffix, for example, com, net, or org. Click OK.

  5. Expand the hierarchy view in the left pane of LDP until you open your administrative group. To do this, double-click the nodes in the following order (note that each node in LDP is followed by the full Distinguished Name (DN); only the left-most CNs are noted here for clarity):

    • DC=Domain_name

    • CN=Configuration

    • CN=Services

    • CN=Microsoft Exchange

    • CN=Organization_name

    • CN=Administrative Groups

    • CN=Administrative_group_name

    In the details (right) pane of LDP, scroll down to view the attributes of your administrative group. If the msExchLegacyDomain attribute is there, you must delete it. If the msExchLegacyDomain attribute is there, it is likely that the msExchLegacyDomain and the msExchEncryptedPassword attributes are also present. If they are, you must delete these as well.

  6. In the hierarchy (left) pane of LDP, right-click Administrative_group_name and then click Modify.

  7. In the Modify dialog box, verify that the full DN listed in the Dn field is correctly identifying the administrative group you need to modify. It should read: CN=Administrative_group_name,CN=Administrative Groups,CN=Organization_name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain_name.

  8. In the Modify dialog box, under Operations, select Delete; under Edit entry, enter msExchLegacyAccount in the Attribute field, and then click Enter. This adds msExchLegacyAccount to the Entry List. The Entry List defines the attributes that will be deleted when you click Run.

  9. If either the msExchLegacyAccount or the msExchEncryptedPassword attributes exist in the administrative group, add them to the Entry List as described in Step 8.

  10. When the Entry List contains the attributes that you must delete, click Run. A status message will appear in the LDP details pane.

  11. On the Connection menu, click New to clear the LDP details pane.

  12. Navigate to CN=Administrative_group_name and double-click the object. Review the contents of the right pane to verify that the attributes are deleted.

For more information about modifying Active Directory with the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).


The LegacyExchangeDN for this administrative group does not match the parent organization
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-11-30

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the format for the legacyExchangeDN attribute on the administrative group container object. If the Exchange Server Analyzer finds the legacyExchangeDN attribute on the administrative group does not match the legacyExchangeDN for the Exchange organization, an error is displayed.

Exchange uses the legacyExchangeDN value to identify Exchange objects in Active Directory. The legacyExchangeDN value is a distinguished name that indicates where the object fits in the Exchange organization, for example:

/o= organization /ou= administrative group

Objects such as servers and folder hierarchies inherit part of their legacyExchangeDN values from the administrative group. This means that if there is a problem with the administrative group value, many other objects may inherit the same problem.

Usually problems with the legacyExchangeDN occur when an administrator has tried to directly modify the value. You must correct the value using a tool such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Use an Active Directory editor, such as ADSI Edit, to locate the administrative group object in Active Directory.

    The legacyExchangeDN attribute can be found at:

    CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=Organization, CN=Administrative Groups, CN= Administrative group

  2. Type a new string value of the form:

    /o= organization /ou= administrative group

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic, "Adsiedit.msc: ADSI Edit" in Windows Server Help.


The legacyExchangeDN for this administrative group is invalid
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to verify the legacyExchangeDN value of an administrative group. This error is displayed if the organization or administrative group named in the legacyExchangeDN value does not match the actual name of the organization or administrative group, or if part of the value is missing entirely.

Exchange uses the legacyExchangeDN value to identify Exchange objects in Active Directory. The legacyExchangeDN value is a distinguished name that indicates where the object fits in the Exchange organization, for example:

/o= organization /ou= administrative group

Objects such as servers and folder hierarchies inherit part of their legacyExchangeDN values from the administrative group. This means that if there is a problem with the administrative group value, many other objects may inherit the same problem.

Generally problems with the legacyExchangeDN occur when an administrator has tried to directly modify the value. You must correct the value using a tool such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify these Active Directory object attributes at your own risk.

To correct this error

  1. Use an Active Directory editor, such as ADSI Edit, to locate the administrative group object in Active Directory.

    The legacyExchangeDN attribute can be found at:

    CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=Organization, CN=Administrative Groups, CN= Administrative group

  2. Type a new string value of the form:

    /o= organization /ou= administrative group

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic, "Adsiedit.msc: ADSI Edit" in Windows Server online Help.


Mail-enabled non-universal groups present
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of domains in the environment. If the Exchange Server Analyzer finds multiple discrete Active Directory domains in the forest, each domain is then queried to determine whether there are one or more mail-enabled, non-universal groups in those domains.

If the Exchange Server Analyzer determines that mail enabled non-universal groups exist in the multiple-domain forest, the Exchange Server Analyzer displays a warning.

If you use domain local or global distribution groups in a multiple-domain forest, e-mail delivery problems may occur for the following reason:

  • To expand distribution groups into individual recipients, Exchange contacts a global catalog server.

  • Although the global catalog server has a listing of groups of all types from each domain, the global catalog server does not contain the membership list for domain local and global groups created in remote domains.

  • If a message is sent to a global distribution group but expanded in a non-home domain, Exchange cannot correctly deliver the message to members of the group.

  • Because the categorizer cannot expand the distribution list, when a user sends a message to a global distribution or mail-enabled security group in a multiple-domain forest, the users in the global distribution group may not receive the message.

  • The last entry in the tracking logs is a submission to categorizer. The sender of the message does not receive a non-delivery report (NDR).

To resolve this issue and make sure of e-mail delivery, use universal distribution groups in a multiple-domain environment. The membership of universal distribution groups is replicated to each global catalog server in each domain

For more information about this issue in particular and about universal distribution groups in general, see the following topics:

  • "Using Mail-Enabled Groups in Multi-Domain Environments" in the Administration Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47617).

  • The "Group scope" section of "Understanding Groups" in Active Directory (http://go.microsoft.com/fwlink/?LinkId=51276).

  • "Guidelines for Creating Query-Based Distribution Groups" in the Administration Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47617).

In addition, see the following Microsoft Knowledge Base articles:

  • 231273, "XADM: Message Delivery to Global Groups Does Not Work" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=271930).

  • 283051, "XCON: E-Mail Sent to Mail-Enabled Global Group May Disappear" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=283051).

  • 231273, "Group Type and Scope Usage in Windows" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231273).


Mailbox Enable User system policy change is required
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-08-10

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the purportedSearch attribute of each Exchange system policy object. The purportedSearch attribute indicates the search argument used when the policy is applied.

The Exchange Server Analyzer also queries Active Directory to determine the value for the msDS-Behavior-Version attribute of the forest object in Active Directory, NTDS Settings. This value indicates the Active Directory forest functional level. Valid values for the msDS-Behavior-Version attribute are shown in the following table.

Value | Forest functional level
0 | Microsoft Windows® 2000 Server mixed
1 | Microsoft Windows Server™ 2003 interim
2 | Microsoft Windows Server 2003 native

The Exchange Server Analyzer also queries Active Directory to determine the value for the revision attribute of the Windows2003Update container. The value of this attribute indicates whether the Active Directory preparation utility (ADPrep.exe) has been run.

Finally, the Exchange Server Analyzer queries the Win32_OperatingSystem Microsoft Windows Management Instrumentation (WMI) class to determine the value of the OSProductSuite key. The value of the OSProductSuite key indicates the version of Windows running on the computer.

If the Exchange Server Analyzer finds the following criteria to be true, a warning is displayed:

  • The value of the purportedSearch attribute of the Mailbox Enable User system policy does not equal (&(objectCategory=person)(objectClass=user)(mailnickname=*)(homeMdb=*))

  • The Active Directory forest functional level is Windows Server 2003 interim or Windows Server 2003 native mode.

  • The Exchange Server computer is not running Windows Small Business Server 2003.

To avoid mailbox re-homing issues, a modification to the system policies is required. This update can be made using Active Directory Service Interfaces (ADSI) Edit (ADSIEdit.msc), the LDP (ldp.exe) tool, or another Active Directory editor tool.

If Windows Server 2003 is used as a domain controller and the Mailbox Enable User policy is not updated, linked value replication in Windows Server 2003 will cause the Recipient Update Service to overwrite the value of the homeMDB attribute of new users, causing their mailboxes to be re-homed on the first store on the server.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Windows Server 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this error

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=<ExchangeOrganizationName>.

  3. Select CN=System Policies.

  4. In the right pane, right-click CN=Mailbox Enable User, and then select Properties.

  5. Scroll down to select the purportedSearch attribute, and then click Edit.

  6. Clear the attribute, and then configure it with the following filter:

    (&(objectCategory=person)(objectClass=user)(mailnickname=*)(homeMdb=*))

    Note:
    The filter shown in Step 6 has been wrapped for readability. Make sure that you enter the filter without any spaces or returns.

  7. Click OK again to save the change, and then close ADSI Edit.

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about this issue and its impact, see Microsoft Knowledge Base article 903291 "Recipient Update Service may overwrite the value of the homeMDB attribute for new Exchange Server 2003 users" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=903291).


MAPI interface disabled on global catalog
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine that the registry key exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\Initialize MAPI interface

If the Exchange Server Analyzer finds the Initialize MAPI interface key is present and configured to have any numeric value, the Exchange Server Analyzer displays an error.

When the Initialize MAPI interface registry key is present Microsoft Office Outlook® clients will not be able to contact the address book on this server. To correct this problem you must remove the Initialize MAPI interface registry key.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Initialize MAPI interface

  3. Right-click the Initialize MAPI interface key and select Delete.

  4. Close the registry editor and restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Initialize MAPI interface.registry key see Microsoft Knowledge Base article 275127, "XADM:How to Configure Exchange Server 5.5 to Run on a Domain Controller that is a Global Catalog" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=275127)


MaxActiveQueries has been modified
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the maximum number of Lightweight Directory Access Protocol (LDAP) queries that can be processed at the same time. This value is obtained by examining the current LDAP administrative policies. Specifically, the Exchange Server Analyzer checks for the presence of MaxActiveQueries. If the Exchange Server Analyzer determines that MaxActiveQueries exists and is configured with a value of anything other than 20, a non-default configuration message is displayed.

The LDAP administrative limits balance the Active Directory operational capabilities and its performance. These limits prevent specific operations from adversely affecting the performance of the server. Increasing this setting beyond its default value could have an adverse effect on your Active Directory infrastructure.

The MaxActiveQueries value of the LDAPAdminLimits attribute controls the maximum number of simultaneous LDAP queries for the default query policy. By default, a limit of 20 active queries is imposed. If this limit is reached, Active Directory returns "LDAP_ADMIN_LIMIT_EXCEEDED" and does not process additional LDAP queries.

To start Ntdsutil.exe

  1. Click Start, and then click Run.

  2. In the Open text box, type ntdsutil, and then press Enter. To view Help at any time, type ? at the command prompt.

To view policy settings

  1. At the Ntdsutil.exe command prompt, type LDAP policies, and then press Enter.

  2. At the LDAP policy command prompt, type connections, and then press Enter.

  3. At the server connection command prompt, type connect to server DNS name of server, and then press Enter. You want to connect to the server that you are currently working with.

  4. At the server connection command prompt, type q, and then press Enter to return to the previous menu.

  5. At the LDAP policy command prompt, type Show Values, and then press Enter.

    A display of the policies as they exist appears.
Note:
This procedure shows only the Default Domain Policy settings. If you apply your own policy setting, you cannot see it.

To change policy settings

  1. At the Ntdsutil.exe command prompt, type LDAP policies, and then press Enter.

  2. At the LDAP policy command prompt, type Set MaxActiveQueries to 20, and then press Enter.

    You can use the Show Values command to verify your changes.

  3. To save the changes, use Commit Changes.

  4. When you finish, type q, and then press Enter.

  5. To quit Ntdsutil.exe, at the command prompt, type q, and then press Enter.

For more information about configuring LDAP policies, see the Microsoft Knowledge Base article 315071, "How to view and set lightweight directory access protocol policies by using Ntdsutil.exe in Windows 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=315071).


MaxPageSize is non-default
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool verifies the Lightweight Directory Access Protocol (LDAP) configuration of a domain controller by checking the attributes of the Default Query Policy object in the Query-Policies container in the Active Directory® directory service. If the Exchange Server Analyzer determines that the MaxPageSize value of the LDAPAdminLimits attribute has been changed from its default of 1000, a non-default configuration message is displayed.

The LDAP administrative limits balance the Active Directory operational capabilities and its performance. These limits prevent specific operations from adversely affecting the performance of the server, and also make the server resilient to denial of service attacks. Increasing this setting beyond its default value could have an adverse impact on your Active Directory infrastructure.

LDAP policies are implemented by using objects of the queryPolicy class. Query policy objects can be created in the Query-Policies container, which is a child of the Directory Service container in the configuration naming context.

The MaxPageSize value of the LDAPAdminLimits attribute controls the number of records that can be returned for an LDAP query. The default is 1000 records. If there are more than 1000 items returned, Active Directory will see this maximum value and will return nothing.

This limit controls the supportable numbers of several types of Active Directory objects. For example, each organization can have up to 1000 servers, up to 1000 administrative groups, and up to 1000 address lists; each administrative group can have up to 1000 routing groups; and each routing group can have up to 1000 connectors.

Unless you are instructed by Microsoft Product Support Services to use a different value, you should reset this value back to 1000.

To start Ntdsutil.exe

  1. Click Start, and then click Run.

  2. In the Open text box, type ntdsutil, and then press ENTER. To view Help at any time, type ? at the command prompt.

To view policy settings

  1. At the Ntdsutil.exe command prompt, type LDAP policies, and then press ENTER.

  2. At the LDAP policy command prompt, type connections, and then press ENTER.

  3. At the server connection command prompt, type connect to server DNS name of server, and then press ENTER. You want to connect to the server that you are currently working with.

  4. At the server connection command prompt, type q, and then press ENTER to return to the previous menu.

  5. At the LDAP policy command prompt, type Show Values, and then press ENTER.

    A display of the policies as they exist appears.

    Note:
    This procedure only shows the Default Domain Policy settings. If you apply your own policy setting, you cannot see it.

To change policy settings

  1. At the Ntdsutil.exe command prompt, type LDAP policies, and then press ENTER.

  2. At the LDAP policy command prompt, type Set MaxPageSize to 1000, and then press ENTER.

    You can use the Show Values command to verify your changes.

  3. To save the changes, use Commit Changes.

  4. When you finish, type q, and then press ENTER.

  5. To quit Ntdsutil.exe, at the command prompt, type q, and then press ENTER.

For more information about configuring LDAP policies, see the Microsoft Knowledge Base Article 315071, "How to view and set lightweight directory access protocol policies by using Ntdsutil.exe in Windows 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=315071).


MaxPageSize is set too high
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the setting for the MaxPageSize value for the LDAPAdminLimits attribute of the Default Query Policy object in the Query-Policies container. If the Exchange Server Analyzer determines that the value for MaxPageSize is greater than 2,500, an error is displayed.

The Lightweight Directory Access Protocol (LDAP) administrative limits balance Active Directory operational capabilities and performance. These limits prevent specific operations from adversely affecting the performance of the server. The limits also make the server resilient to denial of service attacks. Increasing this setting beyond its default value could have an adverse impact on your Active Directory infrastructure.

LDAP policies are implemented by using objects of the queryPolicy class. Query policy objects can be created in the Query-Policies container, which is a child of the Directory Service container in the configuration naming context.

The MaxPageSize value of the LDAPAdminLimits attribute controls the number of records that can be returned for an LDAP query. The default number is 1,000 records. If there are more than 1,000 items returned, Active Directory sees this maximum value and will return nothing.

This limit controls the supportable numbers of several types of Active Directory objects. For example, each organization can have up to 1,000 servers, up to 1,000 administrative groups, and up to 1,000 address lists. Each administrative group can have up to 1,000 routing groups, and each routing group can have up to 1,000 connectors.

Unless you have been instructed by Microsoft Product Support Services to use a different value, you should set this value back to 1,000.

To start Ntdsutil.exe

  1. Click Start, and then click Run.

  2. In the Open text box, type ntdsutil, and then press ENTER. To view Help at any time, type ? at the command prompt.
To view policy settings

  1. At the Ntdsutil.exe command prompt, type LDAP policies, and then press ENTER.

  2. At the LDAP policy command prompt, type connections, and then press ENTER.

  3. At the server connection command prompt, type connect to server <DNS name of server>, and then press ENTER. Connect to the server that you are currently working with.

  4. At the server connection command prompt, type q, and then press ENTER to return to the previous menu.

  5. At the LDAP policy command prompt, type Show Values, and then press ENTER.

    A display of the policies as they exist appears.

    Note:
    This procedure shows only the Default Domain Policy settings. If you apply your own policy setting, you cannot see it.
To change policy settings

  1. At the Ntdsutil.exe command prompt, type LDAP policies, and then press ENTER.

  2. At the LDAP policy command prompt, type Set MaxPageSize to 1000, and then press ENTER.

    You can use the Show Values command to verify your changes.

  3. To save the changes, use Commit Changes.

  4. When you finish, type q, and then press ENTER.

  5. To quit Ntdsutil.exe, at the command prompt, type q, and then press ENTER.

For more information about configuring LDAP policies, see the Microsoft Knowledge Base Article 315071, "How to view and set LDAP policy in Active Directory by using Ntdsutil.exe" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=315071).


More than 800 address lists are present
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the number of address lists in the All Address Lists group in Active Directory is greater than 800. If the Exchange Server Analyzer finds that there are more than 800 address lists in your Exchange Server organization, the Exchange Server Analyzer displays a warning.

It is recommended that you reduce the number of address lists in the All Address Lists group to fewer than 800 to avoid severe latencies during the Recipient Update Service operations. If you have more than 800 address lists in your Exchange Server organization, the Recipient Update Service incurs severe latencies as it stamps mail-enabled objects.

Alternatively, you can disable the Recipient Update Service and use scripts to handle the tasks that the Recipient Update Service performs.

For more information about disabling the Recipient Update Service, see the Microsoft Knowledge Base article 296479, "Requirements for Disabling the Recipient Update Service" (http://go.microsoft.com/fwlink/?Linkid=3052&kbid=296479).

For more information about address lists and the Recipient Update Service, see "Managing Recipients and Recipient Policies" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


More than 800 global address lists are present
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the number of address lists in the All Global Address Lists group in Active Directory is greater than 800. If the Exchange Server Analyzer finds that there are more than 800 global address lists in your Exchange Server organization, the Exchange Server Analyzer displays a warning.

It is recommended that you reduce the number of address lists in the All Global Address Lists group to fewer than 800 to avoid severe latencies during the Recipient Update Service operations. If you have more than 800 global address lists in your Exchange Server organization, the Recipient Update Service incurs severe latencies as it stamps mail-enabled objects.

Alternatively, you can disable the Recipient Update Service and use scripts to handle the tasks that the Recipient Update Service performs.

For more information about disabling the Recipient Update Service, see the Microsoft Knowledge Base article 296479, "Requirements for Disabling the Recipient Update Service" (http://go.microsoft.com/fwlink/?Linkid=3052&kbid=296479).

For more information about address lists and the Recipient Update Service, see "Managing Recipients and Recipient Policies" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


The msExchHomeMDB attribute is indexed
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the Routing Group Back-Link attribute has been configured for indexing in Active Directory. Specifically, the Exchange Server Analyzer queries Active Directory to determine the current indexing value for the msExchHomeMDB attribute, which is an attribute of mailbox-enabled objects in Active Directory. By default, this attribute is not indexed. If the Exchange Server Analyzer finds that this attribute is configured for indexing, a non-default configuration message is displayed.

The effect of having the msExchHomeMDB attribute indexed is minimal. There will be a small increase in the amount of memory used on global catalog servers because of maintaining the index in memory.

If any of the following apply to your organization, you may benefit from indexing this attribute:

  • You have many mail-enabled objects. In very large environments—those with 100,000 or more mail-enabled objects—indexing this attribute can also increase the performance of Exchange System Manager, as well as the Exchange-specific tasks that can be performed with Active Directory Users and Computers.

  • If you frequently use the Exchange Mailbox Merge Program (ExMerge), it has been found that indexing the msExchHomeMDB attribute is occasionally necessary in medium to large environments that use ExMerge. Indexing the msExchHomeMDB attribute has been shown to increase the speed and performance of ExMerge.

If neither of these situations applies, it is recommended that the setting be changed back to the default value of not indexed.

To correct this error

  • There is no action required, because the message generated by the Exchange Server Analyzer is for informational purposes only.


The msExchRoutingGroupMembersBL attribute is indexed
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the Routing Group Back-Link attribute has been configured for indexing in Active Directory. Specifically, the Exchange Server Analyzer examines the following Active Directory object to determine the current indexing value for the msExchRoutingGroupMembersBL attribute:

CN=Configuration,DC=domain,DC=com, CN=Services, CN=Microsoft Exchange, CN=OrganizationName, CN=Administrative Groups, CN=AdministrativeGroupName, CN=Routing Groups, CN=RoutingGroupName

By default, this attribute is not indexed. If the Exchange Server Analyzer finds that this attribute is configured for indexing, a non-default configuration message is displayed.

In a distributed or branch office deployment of Exchange that contains a large number of routing groups, leaving this attribute as non-indexed can cause performance degradation. For example, if there are hundreds of routing groups in your Exchange organization, you may notice increased activity on one or more global catalog servers every 15 minutes. This increased activity occurs because the DSAccess component in Exchange re-reads the routing group configuration. In severe cases, the global catalog may become consumed with this activity.

To minimize this burden on the global catalog, the Routing Group Back-Link attribute can be indexed, thereby reducing the time it takes for DSAccess to read the routing group information, as well as reducing the burden placed on the global catalog by this activity.

To correct this error

  • There is no action required, because the message generated by the Exchange Server Analyzer is for informational purposes only.

For more information about tuning Exchange for best performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?linkid=47576).


Multiple public folder hierarchies found
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of public folder hierarchies that have a value of 1 for the msExchPFTreeType attribute. A value of 1 for the msExchPFTreeType attribute indicates that the public folder hierarchy is the designated public folder hierarchy for MAPI clients. If the Exchange Server Analyzer determines that more than one public folder hierarchy in the Exchange organization has a value of 1 for the msExchPFTreeType attribute, the Exchange Server Analyzer displays an error.

This error indicates that more than one public folder hierarchy for MAPI clients was found in the Exchange organization. The presence of multiple public folder hierarchies for MAPI clients can cause problems.

To resolve this problem, you can use an Active Directory editing tool to set the value for the msExchPFTreeType attribute of all public folder hierarchies except the MAPI public folder hierarchy to 0. If necessary, reconfigure mailbox stores on your Exchange servers to point to the MAPI public folder hierarchy as the default public folder store for MAPI clients.

The following tools are Active Directory editing tools:

  • Active Directory Service Interfaces (ADSI) Edit (AdsiEdit.msc)

  • LDP (ldp.exe) tool

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this error

  1. Use an Active Directory editing tool to locate the public folder objects in Active Directory. The public folder objects can be found at: CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=<OrganizationName>, CN=Administrative Groups, CN=<AdminGroupName>, CN=Folder Hierarchies

  2. Change the msExchPFTreeType attribute for all public folder hierarchy objects except the MAPI public folder hierarchy by entering 0 as the new value.

  3. Close the Active Directory editor.

  4. Open Exchange System Manager.

  5. To access the Properties for each mailbox store, click Administrative Groups, expand your administrative group, expand Servers, expand your server, and expand your storage group. Then, right-click the mailbox store whose Properties you want to change, and select Properties.

  6. On the General tab, for the Default public store field, click Browse.

  7. Select the MAPI public folder hierarchy, and then click OK two times to save the changes.

  8. Repeat steps 5-7 for each mailbox store.

For more information about modifying Active Directory with the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about public folder hierarchies for MAPI and for applications, see the following resources:

  • Microsoft Knowledge Base article 258509, "Description of public folder tree types in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258509)

  • Exchange Team Blog entry, "How mail-enabled Public Folders work" (http://go.microsoft.com/fwlink/?LinkId=41913)


'NeverPing' Parameter Recommended
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of trusts established for each domain. If at least one domain controller in each domain has the NeverPing value set, the tool displays a best practice message.

The Exchange Server Analyzer displays a warning when the following conditions are true for each domain in the Exchange Server 2003 environment:

  • The domain has more than 50 established trusts

  • The domain controllers in the domain have the NeverPing registry subkey value set to null (0)

This warning indicates that the LSASS.exe process or the process for authenticating users to the domain could be delayed. Local Security Authority Subsystem Service (LSASS) is a process in Microsoft Windows operating systems that verifies the user logging on to a Windows-based computer or server.

To fix the issue, set the NeverPing registry subkey value for the domain controllers to 1 as follows.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To set the NeverPing parameter for the domain controllers in your Exchange 2003 environment

  1. Click Start, click Run, type regedit, and then click OK.

  2. Locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.

  3. Right-click this subkey, point to New, click DWORD Value, type NeverPing, and then press ENTER.

  4. Right-click NeverPing, click Modify, type 1 in the Value data box, and then click OK.

  5. Exit Registry Editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about this issue and to set the NeverPing parameter value for your domain controller, see Microsoft Knowledge Base article 825107, "The Lsass.exe process may stop responding if you have many external trusts on a Windows 2000 Server-based domain controller" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=825107).

Note:
Although the article describes Microsoft Windows 2000 Server, the information applies to Windows Server™ 2003 also. The update mentioned in the article is not required for Windows Server 2003.


A newer version of the Active Directory Connector is available
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute on each connection agreement object. The versionNumber attribute represents the version of Active Directory Connector (ADC) that is running on the computer.

The Exchange Server Analyzer Tool also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for Adc.exe, the Active Directory Connector (ADC) file. The Version WMI key indicates the build number for this file.

The Exchange Server Analyzer displays a warning if following conditions are true:

  • The versionNumber attribute on the connection agreement object is set to 16973842.

  • The versionNumber attribute on the connection agreement object is set to 16973843 and the value of the Version key for Adc.exe is less than 7250.0.

A value of 16973842 indicates that the computer is running the original commercial version of ADC from the Exchange Server 2003 CD and a value of 16973843 with a Version key for Adc.exe of less than 7250.0 indicates that the computer is running the Exchange Server 2003 Service Pack 1 (SP1) version of ADC.

A newer version of ADC is available with Service Pack 2 for Exchange Server 2003. It is recommended that you use the latest version of ADC as a best practice.

To correct this warning

  1. Go to Service Pack 2 for Exchange Server 2003 http://go.microsoft.com/fwlink/?LinkId=54751 to download the latest version of ADC.

  2. Uninstall the existing version of ADC and install the updated version of ADC.

For more information about ADC connection agreements, see the following Microsoft Knowledge Base articles:

  • 823601, "Active Directory Connector Requirements and Implications Throughout an Organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 303180, "Active Directory Connector Connection Agreement Requirements for Mixed Administrative Groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)

  • 317721, "XADM: Exchange Server 5.5 Mailbox Owner Rights Are Removed When You Change the ADC Connection Agreement from a One-Way Connection Agreement to a Two-Way Connection Agreement" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=317721)


Nominated Exchange server for this connection agreement does not exist in the organization
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchServer2NetworkAddress attribute on each connection agreement object. The msExchServer2NetworkAddress attribute represents the network address for the server participating in this connection agreement. The Exchange Server Analyzer enumerates the administrative groups in Active Directory to see if this server name is listed for connection agreement members of an Administrative Group. If this server name is not listed in an administrative group, an error is displayed.

This error indicates an orphaned connection agreement. This can occur if an Exchange Server computer has been decommissioned. If the Exchange Server computer has been removed from the organization, you should change the Exchange server name in the Connections tab of the properties of the connection agreement in the Active Directory Connector (ADC) administration tool. If the Exchange server in question is offline for maintenance or some other known reason, you can ignore this error.

To correct this error

  1. Click Start, click Programs, click Administrative Tools, and then click Active Directory Connector.

  2. In the left pane, click the ADC server that hosts the connection agreement you want to modify.

  3. In the right pane, right-click the connection agreement you want to modify, and then click Properties.

  4. Click the Connections tab.

  5. Change the name of the server used for connections to one that exists.

For more information about ADC connection agreements, see the following Microsoft Knowledge Base articles:

  • 823601, "Active Directory Connector Requirements and Implications Throughout an Organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 303180, "Active Directory Connector Connection Agreement Requirements for Mixed Administration Groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)


The nominated offline address book server does not exist in the organization
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-12-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the offLineABServer attribute of the offline address book configuration object. The offLineABServer attribute is a single-valued distinguished name attribute that stores the distinguished name of the Exchange Server computer that is responsible for generating an offline address book.

The Exchange Server Analyzer also examines the value for the distinguishedName attribute of Exchange Server objects in Active Directory.

If the Exchange Server Analyzer finds the server listed in the offLineABServer attribute does not match the found distinguishedName attributes of Exchange Server objects, and that the offLineABServer attribute does not contain the string, DEL:, an error is displayed.

For each offline address book, Exchange generates and stores the offline address book files in a set of public folders on a specified server. If you see this message, it means that the server specified in the offline address list object does not exist. This situation may occur if the old offline address book server has been decommissioned or incorrectly removed from the topology. Exchange will not generate the offline address book until you specify a new server.

To correct this error in Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, under Recipients, click Offline Address Lists. In the right pane, right-click Default Offline Address List (or any other offline address list that produces this message), and then click Properties.

  2. On the General tab, under Offline address list server, click Browse, and then click the server you want to use.

To correct this warning for Exchange Server 2007

  1. Open the Exchange Management Console.

  2. Expand Microsoft Exchange, expand Organization Configuration, and then select Mailbox.

  3. In the results pane, click the Offline Address Book tab.

  4. On the Offline Address Book tab, select "Default Offline Address Book". In the action pane, Click Move to start the Move Offline Address Book wizard. This wizard allows you to move OAB generation to a different server. It will also copy the existing OAB files to the specified server.

To use the Exchange Management Shell to set the server that will host Offline Address Book generation

  • Run the following command:

    Copy Code
    Move-OfflineAddressBook -Identity <OAB> -Server <Server>

    Where: <OAB> is the distinguished name (DN), Domain\Account name, or GUID of the OAB and <Server> specifies the Exchange server on which to perform the selected operation.

    For example, to move OAB generation to the SERVER01., you would enter:
Copy Code
Move-OfflineAddressBook -Identity "My OAB" -Server "Server1"

For more information about working with offline address books in Exchange Server 2003, see "Configuring Exchange Server 2003 Offline Address Books" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).

For more information about working with offline address books in Exchange Server 2007, see "Organization Configuration > Mailbox > Offline Address Books" (http://go.microsoft.com/fwlink/?LinkId=79247).


The nominated Recipient Update Service Exchange server does not exist in the organization
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-03-29

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the distinguishedName attribute for all Exchange Server objects in the directory. The Exchange Server Analyzer also queries Active Directory to determine the value of the msExchAddressListServiceLink attribute for each Recipient Update Service object in the directory. The msExchAddressListServiceLink attribute is a link from the address list service to the Exchange Server computer it should be running on. If the Exchange Server Analyzer finds that the value for the msExchAddressListServiceLink attribute does not contain the string, DEL:, and the attribute does not match the distinguishedName attribute for any Exchange Server object in the directory, an error is displayed.

Each Recipient Update Service instance is associated with one Exchange Server computer that runs the Recipient Update Service. If you receive this message, the Recipient Update Service instance is associated with an Exchange Server computer that does not exist in the Exchange organization. The server may have been decommissioned or otherwise removed from the topology.

For this instance of the Recipient Update Service to run, you must associate it with an existing Exchange server.

To correct this error

  1. Open Exchange System Manager.

  2. Under Recipients, click Recipient Update Services. In the right pane, right-click the appropriate instance of the Recipient Update Service, and then click Properties.

  3. On the General tab, under Exchange Server, click Browse and specify a new server to run this instance.

  4. Click OK, and then click OK again for the change to take effect.

  5. Close Exchange System Manager.

For more information about Recipient Update Service, see the following topic and Microsoft Knowledge Base articles:

  • "Managing Recipients and Recipient Policies in Exchange Server 2003" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?linkid=47617)

  • 328738, "XADM: How the Recipient Update Service Applies Recipient Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 253828, "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 246127, "XADM: How to Check the Progress of the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 253770, "XADM: Tasks Performed by the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


The nominated routing group master server was not detected in this administrative group
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchRoutingMasterDN attribute for each Routing Group container. If the Exchange Server Analyzer finds that the value for the msExchRoutingMasterDN attribute does not contain a valid server name, and the attribute does not contain the string "DEL:", a warning is displayed.

This problem can occur if the previous routing group master was decommissioned or was incorrectly removed from the topology. Without the routing group master, Exchange will not be able to correctly update or maintain the routing topology.

When you create a routing group, the first server in that routing group is assigned the role of routing group master. The routing group master maintains current link state information for its routing group and propagates it to the other servers within the routing group. The routing group master monitors the routing configuration that is written in Active Directory for its routing group only. Member servers can communicate any connector state or server availability information to the routing group master. For example, if a member server tries to contact another server in a different routing group over a connector, and this link is unavailable, the member server immediately notifies the routing group master. Likewise, when a non-master server receives new link state information, it immediately transfers the connector state information to the routing group master, so that other servers can receive the information about the routing change.

To correct this warning

  1. In Exchange System Manager, and under Administrative Groups, expand AdministrativeGroup, and then expand Routing Groups.

  2. Expand the routing group, and then click Members.

  3. In the right pane, right-click the Exchange computer that you want to configure as the routing group master, and then click Set as Master.

For more information about routing group masters, see "Configuring a Routing Topology" in Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?linkid=47579).


The number of public folder connection agreements is less than the number of configuration connection agreements
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether you have a public folder connection agreement between Active Directory and each Exchange Server 5.5 site. It does this by querying both the number of public folder connection agreements, and the number of configuration connection agreements. If the Exchange Server Analyzer determines that the number of public folder connection agreements is less than the number of configuration connection agreements, a warning is displayed.

This warning indicates that at least one Exchange Server 5.5 site does not have a public folder connection agreement with Active Directory, and cannot replicate directory objects for public folders to Active Directory. Therefore, mail cannot flow from Exchange 2000 Server or Exchange Server 2003 mailboxes to Exchange Server 5.5 public folders, nor can mail flow from Exchange Server 5.5 mailboxes to mail-enabled Exchange 2000 Server or Exchange Server 2003 public folders.

Configuration connection agreements are automatically generated when you install an Exchange 2000 Server or Exchange Server 2003 computer in a pure Exchange Server 5.5 site. Public folder connection agreements are user-defined. If there is a public folder connection agreement between each Exchange Server 5.5 site and Active Directory, there will be at least as many public folder connection agreements as configuration connection agreements.

To create a public folder connection agreement

  1. On an Active Directory Connector (ADC) server, start Active Directory Connector Manager. (On the Start menu, point to Programs or All Programs, point to Microsoft Exchange, and then click Active Directory Connector).

  2. In the console tree, click Active Directory Connector. The right window lists the connection agreements. Use this list to determine which site(s) do not have Public Folder connection agreements.

  3. On the Action menu, point to New, and then click Public Folder Connection Agreement to display the Properties dialog box.

  4. On the General tab, in Name, type a name for the connection agreement.

  5. In the Active Directory Connector Service box, select a server to run the connection agreement.

  6. On the Connections tab, select the Active Directory server and the Exchange Server 5.5 server that you want to replicate public folder objects, specifying the appropriate account and credentials for each.

  7. On the Schedule tab, select the replication schedule.

  8. Click OK.

For more information about public folder and configuration connection agreements, see the following Microsoft Knowledge Base articles:

  • 264889, " XADM: Public Folder Connection Agreements" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=264889)

  • 281223, "Understanding Connection Agreements in Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=281223).


Offline Address Book generation is set to update continuously
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-12-04

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the value for the offLineABSchedule attribute in the msExchOAB class has been configured for offline address book generation. The offLineABSchedule attribute determines the schedule for the offline address list. If the Exchange Server Analyzer finds that the offline address book generation schedule for the offline address list has been set to update continuously, the Exchange Server Analyzer displays an error.

An offline address book is a container that stores a collection of offline address lists. Administrators configure available offline address books. Microsoft Office Outlook® 2003 and Outlook 2007 users can choose which offline address lists they want to download. MAPI clients, such as Outlook 2003 and Outlook 2007, can download offline address lists. Therefore, users can compose e-mail messages even when they are disconnected from their Exchange server.

You can schedule when offline address lists are updated. However, make sure that you configure an update schedule that allows enough time for generation of the offline address list to complete before the next update starts. For example, there must be at least four hours between each update interval if the following conditions exist:

  • You specify three updates in a 24-hour period.

  • It takes four hours to update the offline address lists.

Frequent updating is generally not recommended because frequent updating may affect client and server performance in the following ways:

  • The server has to generate the offline address book more frequently. It might take hours to complete, depending on the size of Active Directory.

  • For each update, Outlook must make a copy of the offline address book on the local computer and apply the incremental changes that are fetched from the server. If the offline address book on the local computer is 150 MB, Outlook must create a copy of that much data with each update.

  • Outlook has a "throttling" mechanism that slows down the offline address book update when user activity is detected. When there is continuous user activity, the size of the offline address book affects the time that is required for updates. This time period can vary from one hour to eight hours.

If you want to increase the frequency of your updates, make sure your offline address book is reasonably small. A reasonable uncompressed size is from 1 MB to 25 MB.

To schedule a time for updating offline address lists in Exchange 2000 Server and Exchange Server 2003

  1. In System Manager, double-click Recipients, and then click Offline Address Lists.

  2. In the details pane, double-click the offline address list for which you want to set an update schedule.

    1. To choose a preconfigured update interval, in the General tab, select one of the intervals provided from the Update interval drop-down list.

      Important:
      If you select Never run from the drop-down list, the offline address list will not be updated.
    2. To set a specific update schedule, click Customize. In the Schedule dialog box, set the update schedule on the day and time grid displayed, and then click OK.

To correct this warning for Exchange Server 2007

  1. Open the Exchange Management Console.

  2. Expand Microsoft Exchange, expand Organization Configuration, and then select Mailbox.

  3. In the results pane, click the Offline Address Book tab.

  4. On the Offline Address Book tab, select "Default Offline Address Book". In the action pane, click Properties.

  5. On the General tab, select the run time from the Update Schedule drop-down list, or click Customize to set a custom schedule.

  6. Click OK to save the changes.
To use the Exchange Management Shell to set Offline Address Book generation schedule

  • Run the following command:

    Copy Code
    Set-OfflineAddressBook -Identity <OAB Name> -Schedule <Schedule>

    Where: <OAB> is the distinguished name (DN), Domain\Account name, or GUID of the OAB and <Schedule> specifies the scheduled times to start OAB generation and the format is StartDay.Hour:Minute [AM/PM]. You can use the following values for the days:

    • Full name of the day

    • Abbreviated name of the day

    • Integer from 0 to 6, where 0 = Sunday

    If you prefer to use a 24-hour clock, omit AM/PM.

    For example, to set the Default Offline Address Book generation schedule to daily between 1AM and 3AM, you would enter:
Copy Code
Set-OfflineAddressBook -Identity "\Default Offline Address Book" -Schedule 0.01:00-0.03:00,1.01:00-1.03:00,2.01:00-2.03:00,3.01:00-3.03:00,4.01:00-4.03:00,5.01:00-5.03:00,6.01:00-6.03:00

For more information, see the Offline Address Book Best Practices Guide (http://go.microsoft.com/fwlink/?LinkId=47583).

For more information about working with offline address books in Exchange Server 2003, see "Configuring Exchange Server 2003 Offline Address Books" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).

For more information about working with offline address books in Exchange Server 2007, see "Organization Configuration > Mailbox > Offline Address Books" (http://go.microsoft.com/fwlink/?LinkId=79247).


Offline Address Book generation schedule has been set to Never
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-12-04

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the offLineABSchedule attribute of the offline address book configuration object. The offLineABSchedule attribute represents the offline address book generation schedule for the Default Offline Address List object in the Address Lists container in Active Directory. If the Exchange Server Analyzer finds the offLineABSchedule attribute set to Never, a warning is displayed.

By default, Exchange maintains a single offline address book. Exchange updates this offline address book (or generates a new version of it) every night during its maintenance cycle. You can create additional offline address books, and use the following procedure to check their generation schedule.

This warning indicates that the schedule has been changed to Never. Exchange will not update the existing offline address book until you set a new schedule. This means that while users will be able to download the existing offline address book, they will not receive any updates.

To correct this warning for Exchange 2000 Server and Exchange Server 2003

  1. Open Exchange System Manager.

  2. Under Recipients, click Offline Address Lists.

  3. In the right pane, right-click Default Offline Address List and then click Properties. If you do not want to use an offline address book, right-click Default Offline Address Book, and then click Delete. Otherwise, use the rest of this procedure to set a schedule.

  4. On the General tab, select the run time from the Update interval drop-down list, or click Customize to set a custom schedule.

  5. Click OK to save the changes.

To correct this warning for Exchange Server 2007

  1. Open the Exchange Management Console.

  2. Expand Microsoft Exchange, expand Organization Configuration, and then select Mailbox.

  3. In the results pane, click the Offline Address Book tab.

  4. On the Offline Address Book tab, select "Default Offline Address Book". In the action pane, click Properties.

  5. On the General tab, select the run time from the Update Schedule drop-down list, or click Customize to set a custom schedule.

  6. Click OK to save the changes.

To use the Exchange Management Shell to set Offline Address Book generation schedule

  • Run the following command:

    Copy Code
    Set-OfflineAddressBook -Identity <OAB Name> -Schedule <Schedule>

    Where: <OAB> is the distinguished name (DN), Domain\Account name, or GUID of the OAB and <Schedule> specifies the scheduled times to start OAB generation and the format is StartDay.Hour:Minute [AM/PM]. You can use the following values for the days:

    • Full name of the day

    • Abbreviated name of the day

    • Integer from 0 to 6, where 0 = Sunday

    If you prefer to use a 24-hour clock, omit AM/PM.

    For example, to set the Default Offline Address Book generation schedule to daily between 1AM and 3AM, you would enter:
Copy Code
Set-OfflineAddressBook -Identity "\Default Offline Address Book" -Schedule 0.01:00-0.03:00,1.01:00-1.03:00,2.01:00-2.03:00,3.01:00-3.03:00,4.01:00-4.03:00,5.01:00-5.03:00,6.01:00-6.03:00

For more information about working with offline address books in Exchange Server 2003, see "Configuring Exchange Server 2003 Offline Address Books" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).

For more information about working with offline address books in Exchange Server 2007, see "Organization Configuration > Mailbox > Offline Address Books" (http://go.microsoft.com/fwlink?LinkId=79247).


Old connection agreement version detected
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute on each Active Directory Connector (ADC) connection agreement.

If the Exchange Server Analyzer finds the value for the versionNumber attribute of any connection agreement is less than 16973842 in an Exchange organization that contains one or more Exchange Server 2003 computers, a warning is displayed.

A value less than 16973842 indicates that the connection agreement has been created and is being managed by an Exchange 2000 Server ADC. If you are running any instances of Exchange Server 2003 in your organization where either Exchange 2000 Server or Exchange Server 5.5 are running, you must upgrade all instances of ADC to the version that is included with Exchange Server 2003. After upgrading to Exchange Server 2003 or the Exchange Server 2003 Service Pack 1 (SP1) version of ADC, the connection agreements owned by that version of ADC will also be updated. The versionNumber attribute of each connection agreement will be updated with the latest value.

To correct this warning

  1. Download Exchange Server 2003 SP1 from http://go.microsoft.com/fwlink/?LinkId=29090.

  2. Perform a complete backup of the Exchange Server computer.

  3. On your server that is running Exchange 2000 Server ADC, click Start, click Run, and then type <path>\adc\i386\setup.exe, where <path> is the location of the Exchange Server 2003 SP1 download.

  4. On the Welcome to the Active Directory Connector Installation Wizard page, click Next.

  5. On the Previous Installation Detected page, click Reinstall to upgrade your Exchange 2000 Server ADC to the Exchange Server 2003 ADC.

  6. On the Completing the Active Directory Connector Installation Wizard page, click Finish.

For more information about installing and upgrading ADC, see the following Microsoft Knowledge Base articles:

  • 823601, "Active Directory Connector requirements and implications throughout an organization" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823601)

  • 822942, "Considerations when you upgrade to Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822942)


PDC Emulator FSMO role did not respond
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the fSMORoleOwner attribute of the root of domain directory partition in the Domain Naming Context. For example, in a domain called contoso.com, fSMORoleOwner for the primary domain controller (PDC) emulator is an attribute of DC=contoso,DC=com. The Exchange Server Analyzer then tries to open a Lightweight Directory Access Protocol (LDAP) connection to TCP port 389 on the domain controller that currently holds this role. If the Exchange Server Analyzer cannot connect to this domain controller, an error is displayed.

The PDC emulator serves as primary domain controller for compatibility with earlier Microsoft Windows® operating systems. Microsoft Windows 2000 Server and Microsoft Windows Server™ 2003 interoperate with Microsoft Windows NT® workstations, member servers, and backup domain controllers. The PDC in a Microsoft Windows NT 3.51 or Microsoft Windows NT 4.0 domain is responsible for the following:

  • Processing password changes from both users and computers

  • Replicating updates to backup domain controllers

  • Running the Domain Master Browser

At any time, the PDC emulator master role can be assigned to only one domain controller in each domain.

To correct this error

  1. Verify that the directory server specified in the error is online and accessible by Exchange servers in your organization.

  2. If this directory server has been decommissioned, you must assign the PDC emulator role to another domain controller.

For more information about transferring the PDC emulator role from one domain controller to another domain controller, see the following Microsoft Knowledge Base articles:

  • For Windows Server 2003, see 324801, "How To View and Transfer FSMO Roles in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801)

  • For Windows 2000 Server, see 255690, "HOW TO: View and Transfer FSMO Roles in the Graphical User Interface" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690)


Permissions Inheritance Block on Configuration Object
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-04-13

The Microsoft® Exchange Server Analyzer Tool queries every Exchange configuration object in the Active Directory® database to determine whether any object has inheritance permissions blocked. If permissions inheritance is blocked for an Exchange Configuration object, the Exchange Server Analyzer displays an error.

The Exchange Server Analyzer identifies the configuration object for which permissions inheritance is blocked.

The Exchange Server Analyzer retrieves discretionary access control lists (DACLs) from Active Directory for Exchange configuration objects. By default, configuration objects such as Exchange servers and Exchange Server protocols are set to inherit permissions when Exchange is installed. When permissions are accidentally unchecked or modified, a configuration object can be blocked from inheriting permissions. In this condition, mail flow problems, such as messages sticking in the queues, and store mounting problems can slow Exchange Server responsiveness.

Note:
The access control list (ACL) is a list of security protections that apply to all of a object, a set of the object's properties, or an individual property of an object. There are two types of access control lists: discretionary and system.

The problem can be remedied by re-enabling permissions inheritance for the object.

To re-enable permissions inheritance for an Exchange configuration object

  1. Enable the Security tab for the object properties box of Exchange System Manager by setting a registry parameter. For detailed steps, see Microsoft Knowledge Base article 264733, "How to enable the Security tab for the organization object in Exchange 2000 and in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264733).

    Note:
    By default, the Security tab is not enabled in the configuration object properties box.

  2. Open Exchange System Manager, find the object in question, and re-enable permissions inheritance.

  3. Restart Exchange Server.

For more information about discretionary access control lists in Windows Server 2003 Active Directory, see "How Security Descriptors and Access Control Lists Work"

(http://go.microsoft.com/fwlink/?LinkId=64193).

For more information about permissions inheritance, see "How Permissions Work" (http://go.microsoft.com/fwlink/?LinkId=64195).


Permissions Inheritance Block on Domain Object
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-04-13

The Microsoft® Exchange Server Analyzer Tool checks Active Directory® domain objects such as containers and organizational units. If permissions inheritance is blocked in the containers or organizational units, the Exchange Server Analyzer displays an error.

The Exchange Server Analyzer identifies the specific object.

When changes are made to an Active Directory domain object, changes to the access control list (ACL) are overwritten. Even if 'Inherit from parent' is manually enabled, applied inheritance is disabled when changes are applied to the ACL. This condition causes Recipient Update Service (RUS) issues, because RUS does not have the necessary permissions for an Active Directory organizational unit that the accounts reside in.

This behavior can occur if you disabled the Allow inheritable permissions from parent to propagate to this object check box in the Active Directory organizational unit that the accounts reside in.

To resolve the problem, use the Active Directory Users and Computers snap-in or Active Directory Service Interfaces (ADSI) Edit to reestablish inheritable permissions for the organizational unit. Follow the detailed steps under scenario two in the Microsoft Knowledge Base article 254030, "Missing permissions cause the Recipient Update Service not to process accounts in Exchange 2000 Server and Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=254030).

For more information about access control lists (ACLs) in Microsoft Windows Server 2003™ Active Directory, see "How Security Descriptors and Access Control Lists Work" (http://go.microsoft.com/fwlink/?LinkId=64193).

For more information about permissions inheritance, see "How Permissions Work" (http://go.microsoft.com/fwlink/?LinkId=64195).


Public folder hierarchy not found
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of public folder hierarchies that have a value of 1 for the msExchPFTreeType attribute. A value of 1 for the msExchPFTreeType attribute indicates that a particular public folder hierarchy is the designated public folder hierarchy for MAPI clients. If the Exchange Server Analyzer determines that none of the public folder hierarchies in the Exchange organization has a value of 1 for the msExchPFTreeType attribute, the Exchange Server Analyzer displays an error.

This error indicates that no public folder hierarchy for MAPI clients exists in the organization. The absence of a public folder hierarchy for MAPI clients can cause problems. For example, the absence of a public folder hierarchy for MAPI clients may cause a failure to upgrade an Exchange Virtual Server that is running in a Microsoft Windows® server cluster.

To resolve this problem, you can use an Active Directory editing tool to set the value for the msExchPFTreeType attribute of the public folder hierarchy for MAPI clients to 1. The following tools are Active Directory editing tools:

  • Active Directory Service Interfaces (ADSI) Edit (AdsiEdit.msc)

  • LDP (ldp.exe) tool

You should modify the MAPI public folder hierarchy only. If your Exchange organization includes application public folder hierarchies, make sure that you modify the attribute for the MAPI public folder hierarchy only.

After you have set the value for the msExchPFTreeType attribute of the MAPI public folder hierarchy to 1, you configure the mailbox stores on your Exchange servers to point to the MAPI public folder hierarchy as the default public folder store.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this error

  1. Use an Active Directory editing tool to locate the public folder hierarchy objects in Active Directory. The public folder objects can be found at CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=<OrganizationName>, CN=Administrative Groups, CN=<AdminGroupName>, CN=Folder Hierarchies

  2. Change the msExchPFTreeType attribute by entering 1 as the new value.

  3. Close the Active Directory editor.

  4. Open Exchange System Manager.

  5. To access Properties for each mailbox store, click Administrative Groups, expand your administrative group, expand Servers, expand your server, and expand your storage group. Then, right-click the mailbox store whose Properties you want to change, and select Properties.

  6. On the General tab, for the Default public store field, click Browse.

  7. Select the MAPI public folder hierarchy, and then click OK two times to save the changes.

  8. Repeat steps 5-7 for each mailbox store.

For more information about modifying Active Directory with the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about public folder hierarchies for MAPI and for applications, see the following resources:

  • Microsoft Knowledge Base article 258509, "Description of public folder tree types in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258509)

  • Exchange Team Blog entry, "How mail-enabled Public Folders work" (http://go.microsoft.com/fwlink/?LinkId=41913)


Recipient connection agreement replication schedule is not set to 'Always'
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine what the activationStyle attribute on each Active Directory Connector (ADC) connection agreement is set to. The activationStyle attribute corresponds to how frequently an ADC connection agreement is run. A value of 0 indicates the replication schedule is set to Never. A value of 1 indicates the schedule is set to Selected Times. A value of 2 indicates the schedule is set to Always.

The Exchange Server Analyzer also queries Active Directory to determine the value of the msExchServer2SearchFilter attribute on each ADC connection agreement object. The msExchServer2SearchFilter attribute represents the search filter that will be used when you search the directory.

If the Exchange Server Analyzer finds that the activationStyle attribute is not set to Always, and that the msExchServer2SearchFilter attribute is replicating recipient information, a warning is displayed.

Generally, it is best practice to set the replication schedule of a recipient connection agreement to always replicate. In some cases, setting the connection agreement to any other schedule may cause non-deliverable reports (NDRs) after mailboxes are moved from Exchange Server 5.5 sites to Exchange Server 2003 organizations.

To correct this warning

  1. Open the Active Directory Connector Services MMC snap-in.

  2. Open the Connection Agreement.

  3. On the Connection_Agreement Properties page, select the Schedule tab, select Always, and then click OK.

For more information about deploying ADC and configuring connection agreements, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).


Recipient policy includes variables
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the gatewayProxy attribute of each recipient policy object. If the Exchange Server Analyzer finds a recipient policy object that contains the string SMTP:% in its gatewayProxy attribute, a non-default configuration message is displayed.

If you have modified a recipient policy to generate Simple Mail Transfer Protocol (SMTP) addresses by using replacement strings, your recipient policy will include variables. Using variables in the default recipient policy can cause problems with replication in Exchange 2000 Server prior to Service Pack 2 (SP2). Therefore, it is recommended that you do not use variables in recipient policies, or that you upgrade Exchange 2000 Server to the latest service pack. Exchange 2000 Server SP2 and later support variables in the default recipient policy.

To modify any recipient policy

  1. Start Exchange System Manager.

  2. Click Organization, click Recipients, and then click Recipient Policies.

  3. Double-click the policy that you want to change.

  4. Click the E-Mail Addresses tab, and then edit the appropriate SMTP address or generation rule.

For more information about how to configure recipient policies, see the Microsoft Knowledge Base article 249299, "HOW TO: Configure Recipient Policies in Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=249299).

For more information about using generation rules to customize SMTP addresses, see the Knowledge Base article 822447, "How to Modify an SMTP E-mail Address by Using Recipient Policies" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822447).

For more information about problems that can occur in Exchange 2000 Server if the default recipient policy includes variables, see the Knowledge Base article 271339, "XADM: Cannot Mount Database and Event ID 9546 Occurs" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=271339).

To obtain the latest Exchange 2000 Server service packs, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


Recipient Update Service appears to be stalled
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchServer1HighestUSN attribute of each Recipient Update Service object in Active Directory. The Exchange Server Analyzer also queries Active Directory to determine the value for the activationStyle attribute of each Recipient Update Service object in Active Directory. The activationStyle attribute indicates the update interval for the Recipient Update Service.

The Exchange Server Analyzer also queries Active Directory to determine the value for the highestCommittedUSN attribute for the RootDSE attribute of the domain controller being used by the Recipient Update Service. The highestCommittedUSN attribute is the highest update sequence number (USN) for any object on the server that has been committed to the database on this domain controller.

The Exchange Server Analyzer also queries Active Directory to determine the value for the msExchServer1LastUpdateTime attribute of each Recipient Update Service object. The msExchServer1LastUpdateTime attribute indicates the date and time of the most recent update of the last successful synchronization from this directory.

If the Exchange Server Analyzer finds the following three conditions, a warning is displayed:

  • The activationStyle attribute is set to 2, which indicates that the schedule for this Recipient Update Service is set to Always.

  • The sequence number listed in msExchServer1HighestUSN value is 5,000 or more behind the sequence number listed in highestCommittedUSN.

  • Six or more hours have elapsed since the time stamp recorded in the msExchServer1LastUpdateTime attribute.

This warning indicates that the specified Recipient Update Service has not run for several hours and may have stalled.

To correct this warning

  1. Open Exchange System Manager.

  2. Expand Recipients, and then select Recipient Update Services.

  3. Right-click the specified Recipient Update Service, and then select Update Now.

  4. Wait 30 minutes, and then rerun the Exchange Server Analyzer to see if this warning condition still exists. If it does, continue to step 5. If it no longer exists, no further action is required.

  5. Restart the Microsoft Exchange System Attendant service.

For more information about the Recipient Update Service, see the following Microsoft Knowledge Base articles:

  • 253770, "Tasks performed by the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 253828, "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 253838, "XADM: How the Recipient Update Service Applies System Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253838)

  • 328738, "XADM: How the Recipient Update Service Applies Recipient Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)


Recipient Update Service Did Not Process All Changes
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether values exist for the gatewayProxy attribute of any Recipient Update Service object in Active Directory. If the Exchange Server Analyzer finds values set for the gatewayProxy attribute of any Recipient Update Service object, a warning is displayed.

This warning indicates that the gatewayProxy attribute of a Recipient Update Service object contains old data that was not fully processed. This data should be removed manually.

Old data from the gatewayProxy attribute must be removed; otherwise, these addresses will be in an 'applied' state. If the administrator chooses to change a policy using 'Rebuild' or 'Update Now' options, then valid user addresses may be accidentally overwritten, causing SMTP addresses to be changed for each user. For more information, see Exchange blog article Recipient Policies and pure Exchange 2000/2003 sites.

Note:
The link to this blog is provided for informational purposes. The content may change without notice.

The gatewayProxy attribute of a Recipient Update Service object may contain old data that was not fully processed if any of the following conditions exist:

  • There are problems with Active Directory replication. If Exchange System Manager uses a domain controller that is not the domain controller that is used by the Exchange server that runs the Recipient Update Service, latency issues or other issues with Active Directory replication may exist.

  • There are non-transaction timing issues that cause changes to be lost. This behavior may occur when Exchange System Manager and System Attendant access the gatewayProxy attribute at the same time. Both Exchange System Manager and System Attendant try to read the attribute, make changes, and then write back the attribute.

You must remove the old data by using a tool, such as Active Directory Service Interfaces (ADSI) Edit (AdsiEdit.msc), the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this warning

  1. Set the update interval to the Recipient Update Service to Never as follows:

    1. Open Exchange System Manager.

    2. Expand Recipients and expand Recipient Update Services.

    3. Right-click the Recipient Update Service that you want to modify, and then select Properties.

    4. On the General tab, using the Update interval list, set the schedule to Never run.

  2. Wait approximately one to two minutes.

  3. Next, use ADSI Edit or a similar tool to locate the Recipient Update Service object whose gatewayProxy attribute contains old data. Recipient Update Service objects are located at:

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Address Lists Container,CN=Recipient Update Services

    1. Right-click the Recipient Update Service object that contains the old data, and then select Properties.

    2. On the Attribute Editor tab, scroll down and select the gatewayProxy attribute.

    3. Click Edit to edit this attribute.

    4. In the Value(s) box, select the legacy address type to be removed, click Remove, and click OK. Repeat this step until all address types have been removed.

    5. Click OK to save the changes, and then close ADSI Edit.

  4. Force a directory replication to occur after you clear the gatewayProxy attribute. Make sure that replication occurs before you let the domain Recipient Update Service run again.

  5. Reconfigure the Recipient Update Service to its original schedule.

  6. If you have to, reapply the specific recipient policies. Use the Active Directory Sites and Services snap-in to perform a manual Active Directory replication.

For more information about this issue, see Microsoft Knowledge Base article 821743, "The gatewayProxy attribute on the Recipient Update Service object is not cleared" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821743).

For more information about using the LDP tool, see Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about forcing directory replication, see Microsoft Knowledge Base article 232072, "Initiating Replication Between Active Directory Direct Replication Partners" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072).

For more information about using ADSI Edit, see the "Adsiedit.msc: ADSI Edit" topic in Windows Server 2003 Help.


Recipient Update Service full rebuild
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msDS-ReplAttributeMetaData attribute of the Recipient Update Service object from the configuration domain controller that is used by Exchange Server. The msDS-ReplAttributeMetaData attribute contains the date and time at which the last change was made to this attribute, as well as other information. If the Exchange Server Analyzer finds that less than five days have elapsed since the date and time listed in the msDS-ReplAttributeMetaData attribute, a warning is displayed.

This warning indicates that a full rebuild of this Recipient Update Service was recently scheduled. When a full rebuild is configured, the next time that the Recipient Update Service is started by the schedule or by the Update Now command, the Recipient Update Service examines every object instead of querying for new objects only. This process can take a long time and may cause a system delay.

If a full rebuild is intended, you can safely ignore this warning. If a full rebuild is not intended, you can resolve this issue by using Active Directory Service Interfaces (ADSI) Edit (AdsiEdit.msc) and the following procedure to change the value of the msExchDoFullReplication attribute in Active Directory from True to False.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this warning

  1. Use ADSI Edit or a similar tool to locate the msExchDoFullReplication attribute of the specified Recipient Update Service object. Recipient Update Service objects are located at: CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Address Lists Container,CN=Recipient Update Services

  2. Right-click the specified Recipient Update Service, and then select Properties.

  3. On the Attribute Editor tab, scroll down and select the msExchDoFullReplication attribute.

  4. Click Edit to edit this attribute.

  5. In the Boolean Attribute Editor dialog box, change the selection from True to False and click OK.

  6. Click OK again to save the changes, and close ADSI Edit.

For more information about the Recipient Update Service, see the following Microsoft Knowledge Base articles:

  • 253770, "Tasks performed by the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 253828, "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 253838, "XADM: How the Recipient Update Service Applies System Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253838)

  • 328738, "XADM: How the Recipient Update Service Applies Recipient Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)


Recipient Update Service is configured for full rebuild
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchDoFullReplication attribute of each Recipient Update Service object in Active Directory. If the Exchange Server Analyzer finds that the value for the msExchDoFullReplication attribute for any Recipient Update Service object is set to True, a warning is displayed.

This warning indicates that this Recipient Update Service is configured to perform a full rebuild on the next processing cycle. When the msExchDoFullReplication attribute is set to True, the next time that the Recipient Update Service is started by the schedule or by the Update Now command, the Recipient Update Service examines every object instead of querying for new objects only. This process can take a long time and may cause a system delay.

If a full rebuild is intended, you can safely ignore this warning. If a full rebuild is not intended, you can resolve this issue by using Active Directory Service Interfaces (ADSI) Edit (AdsiEdit.msc) and the following procedure to change the value of the msExchDoFullReplication attribute in Active Directory from True to False.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this warning

  1. Use ADSI Edit or a similar tool to locate the msExchDoFullReplication attribute of the specified Recipient Update Service object. Recipient Update Service objects are located at: CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Address Lists Container,CN=Recipient Update Services

  2. Right-click the specified Recipient Update Service, and then select Properties.

  3. On the Attribute Editor tab, scroll down and select the msExchDoFullReplication attribute.

  4. Click Edit to edit this attribute.

  5. In the Boolean Attribute Editor dialog box, change the selection from True to False and click OK.

  6. Click OK again to save the changes, and close ADSI Edit.

For more information about the Recipient Update Service, see the following Microsoft Knowledge Base articles:

  • 253770, "Tasks performed by the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 253828, "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 253838, "XADM: How the Recipient Update Service Applies System Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253838)

  • 328738, "XADM: How the Recipient Update Service Applies Recipient Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)


Recipient Update Service is inactive
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the activationStyle attribute of each Recipient Update Service object in Active Directory. If the Exchange Server Analyzer finds that the value for the activationStyle attribute for any Recipient Update Service object is set to 0, a warning is displayed.

This warning indicates that the schedule for this Recipient Update Service object is set to Never. When the schedule for a Recipient Update Service is set to Never, new objects are not processed.

If you no longer need this Recipient Update Service object, it is recommended that you delete it. If you need this Recipient Update Service object, it is recommended that you configure its schedule.

To correct this warning by configuring a schedule

  1. Open Exchange System Manager.

  2. Expand Recipients, and then select Recipient Update Services.

  3. Right-click the Recipient Update Service for which the schedule is set to Never, and then select Properties.

  4. Select a predefined schedule by using the Update interval list, or click Customize to create a custom schedule.

  5. Click OK to save the changes.

  6. Right-click this Recipient Update Service, and select Update Now.

For more information about the Recipient Update Service, see the following Microsoft Knowledge Base articles:

  • 253770, "Tasks Performed by the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 253828, "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 253838, "XADM: How the Recipient Update Service Applies System Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253838)

  • 328738, "XADM: How the Recipient Update Service Applies Recipient Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)


Recipient Update Service software update required
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the Address Book View and Dynamic Groups Service (abv_dg.dll), also known as the Recipient Update Service. The Version WMI key indicates the build number for this file.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value for the msDS-Behavior-Version attribute of the NTDS Settings object. This value indicates the Active Directory forest functional level. Valid values for the msDS-Behavior-Version attribute are shown in the following table.

Value | Forest functional level
0 | Microsoft Windows 2000 Server mixed
1 | Microsoft Windows Server™ 2003 interim
2 | Microsoft Windows Server 2003 native

If the Exchange Server Analyzer finds that the build number for abv_dg.dll is less than 6.0.6615.0 on an Exchange server in an Active Directory forest in Windows Server 2003 interim or native mode, an error is displayed. This error indicates that an Exchange 2000 Server version of the Recipient Update Service is running in an incompatible Windows Server 2003 Active Directory forest level. An update to the Recipient Update Service is required to resolve this issue.

When you use the Recipient Update Service in Exchange 2000 Server to update recipient objects in a Windows Server 2003 forest, the Recipient Update Service does not update the objects correctly. For example, the Recipient Update Service does not recognize changes that are made to group membership. Also, if you use Exchange 2000 Server Active Directory Connector (ADC), ADC may not replicate group membership changes from Active Directory to the Exchange Server 5.5 directory.

To upgrade to the latest version of Recipient Update Service

  1. Obtain the required update by following the instructions in the Microsoft Knowledge Base article 873059, "The Recipient Update Service does not update objects correctly when Exchange 2000 Server is running in a Windows Server 2003 forest" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=873059).

  2. Apply the update. You do not have to restart your computer after you apply this update. However, Exchange-related services are automatically restarted when you apply this update.


RUS Instance does not exist for the domain
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to return a list of the domains in the forest. The Exchange Server Analyzer also queries the msExchangeDomainLink attribute for a list of existing domain Recipient Update Service (RUS) instances. The Exchange Server Analyzer then compares the list of domains returned with the list of RUS instances returned and determines whether there is a match. The Exchange Server Analyzer displays an error if the following conditions are true:

  • A domain exists

  • An RUS instance does not exist for that domain

This Exchange Server Analyzer displays this error if the domain has been prepared by using DomainPrep but no RUS instance for the domain exists. A mismatch can occur in scenarios where an administrator adds a new Active Directory domain to the forest, prepares the domain for Exchange using DomainPrep, but then forgets to add a RUS instance for the domain. If this behavior occurs, new user objects created in the domain will not receive e-mail addresses issued to them. If you receive this error message, create a new Recipient Update Service for the domain.

To correct this error

  1. Open Exchange System Manager.

  2. Expand Recipients.

  3. Right-click the Recipient Update Services node, click New, and then click Recipient Update Service.

  4. In the New Object window, click Browse to locate the name of the domain.

  5. Select the name of the domain and then click OK.

  6. In the New Object, window click Next and then Finish.

For more information about Recipient Update Service, see the following Microsoft Knowledge Base articles:

  • 328738, "How the Recipient Update Service applies recipient policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 253828, "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 246127, " How to check the progress of the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 253770, "Tasks performed by the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


Replication epoch change
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the ms-DS-ReplicationEpoch attribute of the NTDS Settings object for any domain controller has been set.

An epoch is the time period during which a domain has a specific name. A new epoch starts when a domain is first created, and when a domain name changes.

The ms-DS-ReplicationEpoch attribute is applied to the epoch under which all domain controllers are replicating. If the Exchange Server Analyzer finds that a value has been set for this attribute, a non-default configuration message is displayed.

The presence of a value for the ms-DS-ReplicationEpoch attribute typically indicates that the domain in which the affected server resides was renamed. Microsoft Windows Server™ 2003, Standard Edition, Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition enable administrators to rename domains in an Active Directory forest after the forest structure is in place. The Windows® 2000 Server operating system does not enable administrators to rename domains in an Active Directory forest after the forest structure is in place.

The structure of an Active Directory forest is determined by the order in which you create domains and the hierarchical names of those domains. You start with the forest root domain. All child domains derive their distinguished names and default DNS names from the forest root domain name. You continue in the same way for every additional tree in the forest.

You change the hierarchical structure of an existing domain tree by renaming the domains. For example, you can rename a child domain to have a different parent, or you can rename a child domain to be a new tree-root domain. In both examples, you reposition an existing domain to create a different domain-tree structure.

Also, you can rename domains without affecting the structure. For example, if you rename a root domain, you change the names of all child domains below that root domain. However, you have not created a different domain-tree structure.

Domain renaming is not supported in forests that contain Exchange 2000 Server or Exchange Server 5.5. The Windows Server 2003 domain rename tools were designed for renaming domains in Active Directory forests that do not contain Exchange 2000 Server servers or Exchange Server 5.5 servers. The Windows Server 2003 domain rename tools have this limitation because of the following conditions:

  • The renaming of a domain affects several Exchange attributes.

  • The Windows Server 2003 domain rename tools have no functionality to fix these attributes.

Domain renaming is supported in forests that contain Exchange Server 2003. The Exchange Domain Rename Fix-Up tool (XDR-fixup.exe) fixes Exchange Server attributes after you rename a domain that contains Exchange 2003 Server servers. You can use the Exchange Domain Rename Fix-Up tool with the Windows Server 2003 directory rename tool (Rendom.exe).

For more information about the Windows Server 2003 Active Directory domain rename tools and to download the Windows Server 2003 Active Directory domain rename tools, see "Windows Server 2003 Active Directory Domain Rename Tools" (http://go.microsoft.com/fwlink/?LinkId=40992).

To rename a domain, you must run the XDR-fixup tool. The XDR-fixup tool modifies Active Directory attributes in Exchange Server to reflect the new domain name. The XDR-fixup tool does not replace the Windows Server 2003 domain rename tools. The XDR-fixup tool also does not extend the functionality of the Windows Server 2003 domain rename tools. You must run the XDR-fixup tool every time that you run Rendom.exe.

For more information about the process for renaming domains and how the process for renaming domains affects Exchange Server, see the following tools and documents:

  • "Windows Server 2003 Active Directory Domain Rename Tools" (http://go.microsoft.com/fwlink/?LinkId=40992)

  • "Understanding How Domain Rename Works" (http://go.microsoft.com/fwlink/?LinkId=41906)

  • "Step-by-Step Guide to Implementing Domain Rename" (http://go.microsoft.com/fwlink/?LinkId=41359)

  • "Exchange Server Domain Rename Fixup" (http://go.microsoft.com/fwlink/?LinkId=34171)

  • "Exchange and Domain Rename Operations" (http://go.microsoft.com/fwlink/?LinkId=41908)


Replica of Offline Address Book version 2 not found
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2007-01-29

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_Public_Folder Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for HasLocalReplica. If the Exchange Server Analyzer finds that the value for HasLocalReplica is set to False for the offline address book version 2 instance for an offline address list, an error is displayed.

When HasLocalReplica is set to False for the offline address book version 2 instance for an offline address list, offline address lists are not correctly generated. As a result, users of Microsoft Outlook® 2002 and earlier cannot download offline address lists.

This issue can occur if you have not configured any public folder stores to contain replicas for offline address book version 2. By default, the offline address book replicates its contents to the public folder store of the server on which it is installed. If the public folder store is removed from the offline address book's replication configuration, the issue that is described in the previous paragraph occurs.

To correct this error

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, and then click Folders.

  3. Right-click Public Folders, and then click View System Folders.

  4. Click to expand the OFFLINE ADDRESS BOOK object.

  5. Under OFFLINE ADDRESS BOOK, right-click o=org/cn=addrlists/cn=oabs/cn=Default Offline Address List, and then click Properties.

  6. On the Replication tab, verify that a public folder store is entered in the Replicate content to these public stores box. If a public folder store is not entered, click Add and enter the appropriate public store for the offline address book.

  7. Click Apply, and then click OK.

  8. Click to expand o=org/cn=addrlists/cn=oabs/cn=Default Offline Address List.

  9. Under o=org/cn=addrlists/cn=oabs/cn=Default Offline Address List, right-click offline Address Book Version 2, and then click Properties.

  10. On the Replication tab, verify that a public folder store is entered in the Replicate content to these public stores box. If a public folder store is not entered, click Add and then enter the appropriate public store for the offline address book.

  11. Click Apply, and then click OK.

For more information about this issue, see the Microsoft Knowledge Base article 286328, "Offline Address Book Is Missing and Cannot Be Generated in Microsoft Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=286328).

For more information about Offline Address Book list generation, see "Offline Address List Generation Overview" (http://go.microsoft.com/fwlink/?LinkId=82242).

For more information about how to correctly remove the first computer running Exchange Server 2003 from an administrative group, see the Knowledge Base article 822931, "How to remove the first Exchange Server 2003 computer from the administrative group" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822931).


Replica of Offline Address Book version 3a not found
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_Public_Folder Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for HasLocalReplica. If the Exchange Server Analyzer finds that the value for HasLocalReplica is set to False for the offline address book version 3a instance of an offline address list, an error is displayed.

When HasLocalReplica is set to False for the offline address book version 3a instance for an offline address list, offline address lists are not correctly generated. As a result, Microsoft Office Outlook® 2003 users cannot download any offline address lists.

This issue can occur if you have not configured any public folder stores to contain replicas for offline address book version 3a. By default, the offline address book replicates its contents to the public folder store of the server on which it is installed. If the public folder store is removed from the offline address book's replication configuration, the issue that is described in the previous paragraph occurs.

To correct this error

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, and then click Folders.

  3. Right-click Public Folders, and click View System Folders.

  4. Click to expand the OFFLINE ADDRESS BOOK object.

  5. Under OFFLINE ADDRESS BOOK, right-click o=org/cn=addrlists/cn=oabs/cn=Default Offline Address List, and then click Properties.

  6. On the Replication tab, verify that a public folder store is entered in the Replicate content to these public stores box. If a public folder store is not entered, click Add, and then enter the appropriate public store for the offline address book.

  7. Click Apply, and then click OK.

  8. Click to expand o=org/cn=addrlists/cn=oabs/cn=Default Offline Address List.

  9. Under o=org/cn=addrlists/cn=oabs/cn=Default Offline Address List, right-click offline Address Book Version 3a, and then click Properties.

  10. On the Replication tab, verify that a public folder store is entered in the Replicate content to these public stores box. If a public folder store is not entered, click Add and then enter the appropriate public store for the offline address book.

  11. Click Apply, and then click OK.

For more information about this issue, see the Microsoft Knowledge Base article 286328, "Offline Address Book Is Missing and Cannot Be Generated in Microsoft Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=286328).

For more information about how to correctly remove the first computer running Exchange Server 2003 from an administrative group, see the Knowledge Base article 822931, "How to remove the first Exchange Server 2003 computer from the administrative group" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822931).


Directory Replication Connector schedule
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine what the value is for the activationSchedule attribute of each Active Directory Connector (ADC) connection agreement object. The activationSchedule attribute corresponds to how frequently an ADC connection agreement is run. A value of 0 indicates the replication schedule is set to Never. A value of 1 indicates the schedule is set to Selected Times. A value of 2 indicates the schedule is set to Always.

The Exchange Server Analyzer also queries Active Directory to determine the value of the msExchServer2SearchFilter attribute on each ADC connection agreement object. The msExchServer2SearchFilter attribute represents the search filter that will be used when you search the directory.

If the Exchange Server Analyzer finds that the activationSchedule attribute is set to Selected Times, with a replication interval longer than 6 hours, and that the msExchServer2SearchFilter attribute is replicating recipient information, a warning is displayed.

Generally, it is best practice to set the replication schedule of recipient connection agreement to always replicate (Always). In some cases, setting the connection agreement to any other schedule may cause non-delivery reports (NDRs) after mailboxes are moved from Exchange Server 5.5 sites to Exchange 2000 Server or Exchange Server 2003.

To correct this warning

  1. Open the Active Directory Connector Services MMC snap-in.

  2. Open the Connection Agreement.

  3. On the Connection_Agreement Properties page, click the Schedule tab, click Always, and then click OK.

For more information about deploying ADC and configuring connection agreements, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).


RID FSMO server role did not respond
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the fSMORoleOwner attribute of the relative ID (RID) operations master in the Domain Naming Context. For example, in a domain called contoso.com, fSMORoleOwner for the RID operations master is an attribute of CN=RID Manager$, CN=System, DC=contoso, DC=com. The Exchange Server Analyzer then tries to open a Lightweight Directory Access Protocol (LDAP) connection to TCP port 389 on the domain controller that currently holds this role. If the Exchange Server Analyzer cannot connect to this domain controller, an error is displayed.

The RID master allocates relative IDs to all domain controllers to ensure that all security principals have a unique identifier. You can create a new security principal object (user, group, or computer) on any domain controller. When you create a security principal object, the domain controller attaches a unique security identifier (SID) to the object. There are four elements of a domain SID, one of which is the RID for the domain. The RID operations master is responsible for processing RID pool requests from all domain controllers in a particular domain. At any time, there can be only one domain controller acting as the RID master in the domain.

To correct this error

  1. Verify that the directory server specified in the error is online and accessible by Exchange servers in your organization.

  2. If this directory server has been decommissioned, you must assign the RID master role to another domain controller.

For more information about transferring the RID operations master role from one domain controller to another domain controller, see the following Microsoft Knowledge Base articles:

  • For Microsoft Windows Server™ 2003, see 324801, "How To View and Transfer FSMO Roles in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801)

  • For Microsoft Windows® 2000 Server, see 255690, "HOW TO: View and Transfer FSMO Roles in the Graphical User Interface" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690)


Schema FSMO role not found
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the domain controller that is specified as the schema FSMO (fSMORoleOwner at the Schema Naming Context). If the Exchange Server Analyzer finds that the domain controller specified in the fSMORoleOwner attribute does not exist in the forest, an error is displayed.

The fSMORoleOwner attribute at the Schema Naming Context (CN=Schema,CN=Configuration,DC=domain,DC=com) defines the domain controller that is the schema master for the forest. The schema master domain controller controls all updates and modifications to the schema. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.

You must have a schema master defined for your Active Directory forest. Exchange 2000 Server Setup and Exchange 2000 Server Service Pack Setup will fail (even if you are not updating the schema) if a schema master domain controller is not online during setup. If the domain controller listed as the schema master is offline, it must be brought back online. This does not apply to Exchange Server 2003. Exchange Server 2003 Setup only contacts the schema master if it determines that the schema has not been extended.

To correct this error

  1. Verify that the designated Active Directory server is physically present.

  2. If this directory server has been decommissioned, assign the role of schema master to another domain controller.

For more information about how to assign the role of schema master to another domain controller, see the following Microsoft Knowledge Base articles:

  • 280178, "XADM: Exchange 2000 Installation Requires Access to Schema Master" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=280178)

  • For Microsoft Windows Server™ 2003, see 324801, "How To View and Transfer FSMO Roles in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801)

  • For Microsoft Windows® 2000 Server, see 255690, "HOW TO: View and Transfer FSMO Roles in the Graphical User Interface" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690)


Schema FSMO role did not respond
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the fSMORoleOwner attribute of the schema operations master in the Schema Naming Context. For example, in a domain called contoso.com, fSMORoleOwner for the schema operations master is an attribute of CN=Schema,CN=System,DC=contoso,DC=com. The Exchange Server Analyzer then tries to open a Lightweight Directory Access Protocol (LDAP) connection to TCP port 389 on the domain controller that currently holds this role. If the Exchange Server Analyzer cannot connect to this domain controller, an error is displayed.

The domain controller that holds the schema master role is the only domain controller that can perform write operations to the directory schema. Those schema updates are replicated from the schema master to all other domain controllers in the forest. The schema master is a per-forest operations master role, because regardless of the number of domains, there is only one schema in the forest. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.

To correct this error

  1. Verify that the directory server specified in the error is online and accessible by Exchange servers in your organization.

  2. If this directory server has been decommissioned, you must assign the schema master role to another domain controller.

For more information about transferring the schema operations master role from one domain controller to another domain controller see the following Microsoft Knowledge Base articles:

  • For Microsoft Windows Server™ 2003, see 324801, "How To View and Transfer FSMO Roles in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801).

  • For Microsoft Windows® 2000 Server, see 255690, "HOW TO: View and Transfer FSMO Roles in the Graphical User Interface" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690).


A Secure Sockets Layer Certificate Will be Expiring Soon
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Server Certificate object in the Exchange server system to retrieve various properties on X509 certificates. For each Secure Sockets Layer (SSL) certificate found, the Exchange Server Analyzer evaluates the ExpirationDate attribute to identify the expiration date of the certificate.

Note:
A server must have a server certificate when it runs a SSL protocol. The server certificate contains the Web site name. The browser verifies that the Web site is the name that was entered. For example, if there is a Web site such as https://www.example.com, the name of the certificate should be www.example.com.

The Exchange Server Analyzer displays a warning when the ExpirationDate is between 3 and 20 days away. The Exchange Server Analyzer displays an error when the ExpirationDate is less than 3 days away.

If the certificate has expired, SSL connections to the URL specified in this message will fail. Similarly, RPC over HTTP and Exchange Server ActiveSync connections that use that URL will fail.

To resolve this certificate expiration warning or error, renew the certificate specified in this message. The steps that you must follow to renew a certificate depend on the certification authority that you use.

For More Information

For more information about SSL and the use of certificates with virtual servers in Exchange Server, see the following Exchange resources:

  • For information about how to use certificates with virtual servers in Exchange Server 2003, see Microsoft Knowledge Base Article 823024, "How to Use Certificates with Virtual Servers in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823024).

  • For information about how to use SSL and how to obtain and install server certificates, see "Configuring Exchange Server 2003 for Client Access" in the Exchange Server 2003 Client Access Guide (http://go.microsoft.com/fwlink/?LinkId=47568).

  • For information about how to use SSL and how to obtain and install server certificates for Exchange Server 2007, see "How to Configure SSL for Outlook Anywhere" (http:// go.microsoft.com/fwlink/?LinkId =80875).


Servers container is missing
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service for the value of the distingushedName attribute for each Routing Group object discovered in the current administrative group.

The Exchange Server Analyzer then queries Active Directory to determine whether a Servers container is present in the current administrative group.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The current administrative group contains one or more routing groups.

  • A Servers container does not exist.

This error indicates that no servers are installed in the administrative group and that routing information may not be dynamically propagated across servers throughout the Exchange organization.

To address this error, make sure that the Exchange organization is in native mode and follow these steps.

Resolution Steps

  1. Create a new administration group.

  2. Create a new Routing Groups container in the new administration group.

  3. Drag the existing routing groups from the old Routing Groups container into the new one.

  4. Restart all Exchange services.

For more information about this error, see Microsoft Knowledge Base article 318491 "XADM: Routing Information Is Not Propagated Across an Exchange 2000 Organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=318491).


Service Principal Name Missing from Global Catalog Server
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-05-12

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service global catalog server to find the values returned for the Fully Qualified Domain Name (FQDN) and NetBIOS name for the servicePrincipalName attribute of the exchangeAB and HOST resources.

The Exchange Server Analyzer displays an error if either of the following conditions is true:

  • The servicePrincipalName attribute for the exchangeAB resource is missing one of the expected FQDN or NetBIOS name values.

  • The servicePrincipalName attribute for the HOST Exchange resource is missing one of the expected FQDN or NetBIOS name values.

A Service Principal Name (SPN) is a unique name that identifies an instance of a service and is associated with the logon account under which the service instance runs. Kerberos authentication is not possible for Exchange services without correctly set SPNs.

  • If clients that run Microsoft Outlook® 2003 or a later version have Active Directory authentication issues, these issues may indicate the lack of a valid SPN for the exchangeAB resource.

  • Authentication failures between servers may indicate the lack of a valid SPN for the HOST resource.

To resolve this issue, follow these steps to add the missing values for the servicePrincipalName attribute.

Use the SETSPN.exe tool to add an SPN with the missing values

  1. Install the Setspn.exe tool. To obtain the Setspn.exe tool, see "Windows 2000 Resource Kit Tool : Setspn.exe" (http://go.microsoft.com/fwlink/?LinkId=28103).

    The Windows Server 2003 version of the Setspn.exe command-line tool is available in the Windows Server 2003 Support Tools that are included on the Windows Server 2003 CD. To install the Server 2003 Support Tools, double-click the Suptools.msi file in the Support/Tools folder.

  2. Follow the guidance in the SETSPN.EXE Setspn_d.txt file to add the missing value to the Active Directory object for your Exchange server. The following example demonstrates adding the FQDN value for a virtual SMTP server SPN:

    • Start a command prompt, and then change to the directory where you installed Setspn.exe.

    • At the command prompt, type the following command:

      setspn.exe-a SMTPSVC/ mail.yourdomain.com YOURSERVERNAME

      Note:
      Replace mail.yourdomain.com with your SMTP virtual server FQDN and YOURSERVERNAME with the name of the Exchange server.
      Then press Enter.


The Site Folder Server public folder store for this administrative group does not exist within this administrative group
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the distinguishedName of each public folder store. In addition, the Exchange Server Analyzer queries Active Directory to determine the values for the siteFolderServer and msExchAdminGroupMode attributes of each administrative group. The siteFolderServer attribute represents the name of the server that is responsible for hosting the site folders (normally the first server in the site or administrative group). The msExchAdminGroupMode attribute represents the mode for the administrative group, which can be:

  • Pure Exchange Server 5.5

  • Exchange Server 5.5, Exchange 2000 Server, and Exchange Server 2003 Server mixed-mode

  • Exchange 2000 Server or Exchange Server 2003 native mode

If the Exchange Server Analyzer determines that the administrative group is not in native mode, and the value for the siteFolderServer does not match the value for the distinguishedName of any public folder store, and the siteFolderServer attribute value does not contain the string, DEL:, a warning is displayed.

By default, the Site Folder Server is the first server that is installed in the administrative group. The public folder store on this server is the default location of the free/busy folders and offline address book folders for the administrative group. If you remove or decommission the Site Folder Server without replicating these folders to another server and designating that server as the offline address book server, Outlook users will see problems with the offline address book and with free/busy data.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this warning

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Locate the public folder information store you want to designate as the Site Folder Server, by expanding the following: CN=<PublicFolderStoreName>, CN=<StorageGroupName>, CN=InformationStore, CN=<ServerName>, CN=Servers, CN=<AdministrativeGroupName> ,CN=Administrative Groups, CN=<OrganizationName>, CN=Microsoft Exchange, CN=Services, CN=Configuration,DC=<DomainName>,DC=com.

  3. In the right pane, right-click CN=<PublicFolderStoreName> and select Properties.

  4. In the Attributes field, scroll down and select the distinguishedName attribute.

  5. Click the Edit button, and then copy the entire attribute to the Clipboard.

  6. Expand the Configuration container, and then expand CN=Administrative Groups,CN=<OrganizationName>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<DomainName>,DC=com.

  7. Right-click the administrative group you want to modify and select Properties.

  8. In the Attributes field, scroll down and select the siteFolderServer attribute.

  9. Click the Edit button and paste the value for the distinguishedName attribute into the Value field.

  10. Double-check the contents of the Value field to ensure the paste was done correctly, and then click OK to save the change.

  11. Click OK to close the administrative group properties dialog box.

  12. Exit ADSI Edit and restart the Microsoft Exchange Information Store service on all Exchange Server computers in the site for the change to take effect.

For more information about re-creating system folders and resetting the Site Folder Server, see the following Microsoft Knowledge Base articles:

  • 275171, "How to Reset System Folders on an Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=275171)

  • 284200, "Schedule+ Free/Busy System Folder Is Missing" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=284200)

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic, "Adsiedit.msc: ADSI Edit" in Windows Server 2003 Help.


The Site Folder Server public folder store used by the offline address book was not detected
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2007-02-01

The Microsoft® Exchange Server Analyzer Tool queries the Active® Directory directory service to determine the value for the siteFolderServer attribute on all Exchange public folder stores (stores that have an objectClass of objectClass=msExchPublicMDB). The siteFolderServer attribute represents the public folder store used for the offline address book server.

If the Exchange Server Analyzer determines that a server is not listed, the listed server is down, or the listed server does not exist, a warning is displayed. If the siteFolderServer attribute contains the string, DEL:, the Exchange Server Analyzer displays an error message.

By default, Exchange Server 2003 generates offline address book files on the Site Folder Server (the first server that is installed in the administrative group). If you have designated a different server to act as the offline address book server, the public folder store listed in this attribute will be the store on the new offline address book server, and not the store on the administrative group's actual Site Folder Server.

When Exchange Server 2003 generates offline address book files, it attaches the files to mail messages and puts the messages in special public folders. Microsoft Office Outlook® 2003 retrieves the messages from the folder and downloads the attached files.

In Exchange Server 2003, the offline address book messages are stored in subfolders of the OFFLINE ADDRESS BOOK folder, which is one of the system folders in the default Public Folders tree. This folder contains a subfolder for each administrative group or site in your topology. By default, a content replica of a specific administrative group folder resides on the first server that is installed in the administrative group (named the Site Folder Server).

If your Exchange organization is Exchange Server 2007, with no down level (Outlook 2003 or earlier) clients, you can safely disregard this warning or Error. If your Exchange Server 2007 organization is hosting clients running Outlook 2003 or earlier, follow the procedure below to enable public folder distribution of the offline address book files. Public folder distribution is the distribution method by which clients running Outlook 2003 or earlier that are working offline or through a dial-up connection access the OAB.

To correct this warning for Exchange Server 2003

  1. If you know that the server does exist, in Exchange System Manager, under Servers, expand the server, expand the storage group, and then click Public Folder Store. Check the right pane to make sure that the store is running.

  2. To designate a new offline address book server, under Recipients, click Offline Address Lists. Then in the right pane, click Default Offline Address List (or any other offline address list that produces this message).

    If you do not want to use an offline address book, right-click Default Offline Address Book, and then click Delete. Otherwise, use the rest of this procedure to set a schedule.

  3. Right-click Default Offline Address List, and then click Properties.

  4. On the General tab, under Offline Address Book server, click Browse to select a server.

To correct this warning for Exchange Server 2007

  1. Open the Exchange Management Console.

  2. Expand Microsoft Exchange, expand Organization Configuration, and then select Mailbox.

  3. In the results pane, click the Offline Address Book tab.

  4. On the Offline Address Book tab, select "Default Offline Address Book".

    1. To enable public folder distribution of the offline address book, from the Distribution tab, select Enable public folder distribution.

    2. Click OK to save the changes

  5. To designate a new offline address book server, from the action pane, click Move to start the Move Offline Address Book wizard. This wizard allows you to move OAB generation to a different server. It will also copy the existing OAB files to the specified server.

To use the Exchange Management Shell to enable public folder distribution of the offline address book files.

  • Run the following command:

    Copy Code
    Set-OfflineAddressBook -Identity <OAB> -PublicFolderDistributionEnabled $true

    Where: <OAB> is the distinguished name (DN), Domain\Account name, or GUID of the OAB.

    For example, to enable public folder distribution of the default offline address book, you would enter:
Copy Code
Set-OfflineAddressBook -Identity "\Default Offline Address Book" -PublicFolderDistributionEnabled $true

To use the Exchange Management Shell to set the server that will host Offline Address Book generation

  • Run the following command:

    Copy Code
    Move-OfflineAddressBook -Identity <OAB> -Server <Server>

    Where: <OAB> is the distinguished name (DN), Domain\Account name, or GUID of the OAB and <Server> specifies the Exchange server on which to perform the selected operation.

    For example, to move OAB generation to the SERVER01., you would enter:
Copy Code
Move-OfflineAddressBook -Identity "My OAB" -Server "Server1"

For more information about working with offline address books in Exchange Server 2003, see "Configuring Exchange Server 2003 Offline Address Books" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).

For more information about working with offline address books in Exchange Server 2007, see "Organization Configuration > Mailbox > Offline Address Books" (http://go.microsoft.com/fwlink/?LinkId=79247).


SiteName is hard-coded
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the SiteName registry value is present on the Exchange server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\SiteName

If the Exchange Server Analyzer finds the SiteName registry value present, a warning is displayed.

This warning indicates that the Active Directory® directory service site membership has been hard-coded on this computer running the Microsoft Windows® operating system. This configuration is not recommended for Exchange Server.

When you hard-code a Windows site, you can cause failures of the Microsoft Exchange System Attendant service and general Exchange Server failures. You should consider removing the SiteName registry value. If you remove the SiteName registry value, Windows automatically joins the appropriate Active Directory site.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To remove the SiteName registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters

  3. In the right pane, locate and delete the SiteName registry value.

  4. Close the registry editor, and restart the server to have the change take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the SiteName registry value, see the Knowledge Base article 322834, "XADM: Event 1005, System Attendant Does Not Start" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322834).


There are more than 900 Administrative Groups in your Exchange organization
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of administrative groups that are present in the Exchange organization. If the Exchange Server Analyzer finds more than 900 administrative groups, a warning message is displayed.

It is recommended that you have a maximum of 900 instances for any single Exchange object type. This is because Active Directory defaults to 1,000 as the maximum page size that it returns for any given request. This means that if a Lightweight Directory Access Protocol (LDAP) request is made for an object, and more than 1,000 instances of that object exist in Active Directory, no results will be returned because the maximum page size is exceeded.

In the case of Exchange, various processes request instantiation of specific object types. For example, Exchange System Manager makes an LDAP request to Active Directory to create a list view of all administrative groups within the Exchange organization. If there are more than 1,000 administrative groups, Active Directory will not return any results. As a result, an error is displayed in Exchange System Manager, and no administrative groups are displayed.

Although the maximum page size value for Active Directory can be increased, this is not recommended or supported for Exchange. Odd behavior and failures have been exposed in Exchange environments where the maximum page size value has been increased.

Although the recommendation is to remain at or below 900 for any single object type in Exchange, up to 1,000 object types are supported.

To remedy this issue, consider consolidating your administrative groups.

For more information about consolidating Exchange sites and administrative groups, see:

  • Deploying a Worldwide Site Consolidation Solution for Exchange Server 2003 at Microsoft (http://go.microsoft.com/fwlink/?LinkId=33531)


There are more than 900 Exchange servers in your Exchange organization
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-03-30

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to obtain the count of objects in the directory that have an objectCategory of msExchExchangeServer. The count represents the number of Exchange Server computers found in Active Directory. If the Exchange Server Analyzer finds more than 900 Exchange Server computers, a warning is displayed.

It is recommended that you use a maximum of 900 instances for any single Exchange object type. This is because Active Directory defaults to 1,000 as the maximum page size that it returns for any given request. This means that if a Lightweight Directory Access Protocol (LDAP) request is made for an object, and more than 1,000 instances of that object exist in Active Directory, no results will be returned because the maximum page size is exceeded.

In the case of Exchange Server, various processes request instantiation of specific object types. For example, Exchange System Manager makes an LDAP request to Active Directory to create a list view of all Exchange servers within the Exchange organization. If there are more than 1,000 Exchange servers, Active Directory will not return any results. As a result, an error is displayed in Exchange System Manager and no Exchange Server computers are displayed.

Although the maximum page size value for Active Directory can be increased, this is not recommended or supported for Exchange. Odd behavior and failures have been exposed in Exchange environments where the maximum page size value has been increased.

Although the recommendation is to remain at or below 900 for any single object type in Exchange Server, up to 1,000 object types are supported.

To correct this warning

  1. Consider consolidating Exchange servers in your organization.

  2. Examine Active Directory for orphaned Exchange Server computers, and remove them from Active Directory.

For more information about consolidating Exchange servers, see "Server Consolidation Using Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=47586).


There are more than ten administrators delegated at the organizational level
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-12-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of users who have permissions as either Exchange Administrators or Exchange Full Administrators. The Exchange Server Analyzer counts the number of entries listed in the msExchAdmins attribute, which represents a link to all Exchange administrators within the organization together with the appropriate permissions. If the Exchange Server Analyzer finds there are more than 10 users with Exchange Administrator and/or Exchange Full Administrator permissions, a warning is displayed.

msExchAdmins is a multi-value attribute of the Exchange root organization container. It contains a list of security identifiers (SIDs) that represent the user accounts with delegated Exchange permissions.

It is a best practice to limit the number of users with write access to the Exchange organization. Consider reducing the number of Exchange Administrators and Exchange Full Administrators at the organization level. By reviewing administrative roles against the requirements of your messaging infrastructure, you may find that you can convert many of these users to Exchange View-only Administrators at the organizational level, while delegating to them the Exchange Administrator role at the Administration Group level.

To correct this warning

  1. Consider decreasing the number of users that have Exchange Administrator and/or Exchange Full Administrator permissions.

  2. Consider performing an audit of Exchange Server permissions in your organization to ensure that they are appropriate.

For more information about planning and configuring permissions in Exchange, see:

  • "Working with Active Directory Permissions in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=47592).

  • Microsoft Exchange Server 2007, Operations "Configuring Permissions" (http://go.microsoft.com/fwlink/?LinkId=78432).

  • Microsoft Exchange Server 2007, Planning and Architecture, Planning Active Directory "Permission Considerations" (http://go.microsoft.com/fwlink/?LinkId=78433).

For more information about administrative roles in Exchange Server 2003, see the Microsoft Knowledge Base article 823018, "Overview of Exchange Administrative Role Permissions in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823018).

For more information about administrative roles in Exchange 2000 Server, see the Knowledge Base article 289811, "XGEN: Exchange 2000 Role Permissions" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=289811).


This connection agreement is not set to create disabled accounts when no match is made
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchServer1AlwaysCreateAs attribute of each connection agreement object. If the Exchange Server Analyzer determines that the msExchServer1AlwaysCreateAs attribute is not set to 1, a warning is displayed.

The msExchServer1AlwaysCreateAs attribute determines how X.500 objects are synchronized with Active Directory. A value of 0 indicates the connection agreement has been configured to create Microsoft Windows® contacts. A value of 1 for this attribute indicates that the connection agreement has been configured to create disabled Windows user accounts in Active Directory. A value of 2 indicates the connection agreement has been configured to create new Windows user accounts.

The Exchange Server Analyzer issues a warning because in a situation where Exchange Server 5.5 must coexist with Active Directory and a full migration to Exchange Server 2003 is planned, it is important to have Active Directory Connector (ADC) create disabled Windows user accounts. These disabled Windows user accounts are "mailbox-enabled" meaning they are logically attached to a mailbox that exists on the Exchange Server 5.5 computer. Having disabled Windows user accounts created is necessary for the user object that represents this disabled Windows account, to eventually have access to public folders and other secured objects in Active Directory.

In the ADC user interface, there are three options for creating new objects when a matching object is not found in Active Directory for a mailbox in Exchange Server 5.5. These are listed on the Advanced tab in the properties of the connection agreement, as follows:

  • Create a Windows Contact This is not recommended because a Contact object has no security context.

  • Create a new Windows user account This is not recommended because the new account that is created will have a new SID and, therefore, the SID history of the Microsoft Windows NT® Server 4.0 user account will not be carried over to this new account during migration (because the SIDs are different).

  • Create a disabled Windows user account This is recommended because it allows the Windows NT Server 4.0 user to coexist (with correct access to resources) until the full migration is complete.

To correct this warning

  1. Configure the Active Directory Recipient Connection Agreement to create mailbox-enabled disabled Windows user accounts.

  2. Use the Active Directory Migration Tool, which migrates Windows NT Server 4.0 user accounts to Active Directory and creates enabled Windows accounts. These enabled Windows accounts will have the same SID as the disabled Windows accounts created by ADC.

  3. Use the Active Directory Cleanup Wizard (ADClean), which merges the information from the Active Directory Migration Tool-created account into the ADC-created account.

For more information about Active Directory Connector recipient connection agreements, see the following Microsoft Knowledge Base articles:

  • 823601, "Active Directory Connector Requirements and Implications Throughout an Organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 303180, "Active Directory Connector Requirements for Mixed Administrative Groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)

  • 296260, "XGEN: How to Configure a Two-Way Recipient Connection Agreement for Exchange 5.5 Users" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=296260)

  • For more information about the Active Directory Cleanup Wizard, see the following Knowledge Base article:

  • 270652, "Possible Uses of the Active Directory Account Cleanup Wizard" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270652)

  • For more information about the Active Directory Migration Tool, see the following Knowledge Base article:

  • 260871, "How To Set Up ADMT for Windows NT 4.0 to Windows 2000 Migration" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260871)


This is a one-way connection agreement from Exchange
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchSynchronizationDirection attribute on each connection agreement object. The msExchSynchronizationDirection attribute represents the direction in which the directories will be synchronized. If this attribute is set to 2, a warning is displayed.

The msExchSynchronizationDirection attribute can have a value of 0 or 2. If this attribute is set to 0, it indicates a two-way connection agreement. If this attribute is set to 2, it is a one-way connection agreement from the Exchange Server computer.

As a best practice, it is recommended that you use two-way connection agreements. Mixed-mode Exchange environments (those where Exchange Server 5.5 coexists with Exchange 2000 Server and/or Exchange Server 2003) require a two-way connection agreement.

To correct this warning

  1. Remove the existing one-way connection agreement.

  2. Create a replacement two-way connection agreement.

For more information about Active Directory Connector (ADC) connection agreements, see the following Microsoft Knowledge Base articles:

  • 823601, "Active Directory Connector Requirements and Implications Throughout an Organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 303180, "Active Directory Connector Connection Agreement Requirements for Mixed Administrative Groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)

  • 317721, "XADM: Exchange Server 5.5 Mailbox Owner Rights Are Removed When You Change the ADC Connection Agreement from a One-Way Connection Agreement to a Two-Way Connection Agreement" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=317721)


This is a one-way connection agreement from Windows
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchSynchronizationDirection attribute on each connection agreement object. The msExchSynchronizationDirection attribute represents the direction in which the directories will be synchronized. If this attribute is set to 1, a warning is displayed.

The msExchSynchronizationDirection attribute can have a value of 0, 1, or 2. A value of 0 indicates a two-way connection agreement, a value of 1 indicates a one-way connection from Active Directory, and a value of 2 indicates a one-way connection agreement from the Exchange Server computer.

It is recommended as a best practice to use two-way connection agreements. Mixed-mode Exchange environments (those where Exchange Server 5.5 coexists with Exchange 2000 Server and/or Exchange Server 2003) require a two-way connection agreement.

To correct this warning

  1. Remove the existing one-way connection agreement.

  2. Create a replacement two-way connection agreement.

For more information about Active Directory Connector (ADC) connection agreements, see the following Microsoft Knowledge Base articles:

  • 823601, "Active Directory Connector Requirements and Implications Throughout an Organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 303180, "Active Directory Connector Connection Agreement Requirements for Mixed Administrative Groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)

  • 317721, "XADM: Exchange Server 5.5 Mailbox Owner Rights Are Removed When You Change the ADC Connection Agreement from a One-Way Connection Agreement to a Two-Way Connection Agreement" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=317721)


Timestamp comparison between Exchange and Active Directory exceeds 5 minutes
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_UTCTime Microsoft Windows® Management Instrumentation (WMI) class to determine the date and time on each Exchange server. The Exchange Server Analyzer also retrieves the current date and time on the default domain controller. If the Exchange Server Analyzer determines that there is a difference of five minutes or more between the two servers, an error is displayed.

Microsoft Windows 2000 Server and Windows Server™ 2003 use the Windows Time service to synchronize the date and time of computers that are running on a Windows-based network. Synchronized time is critical in Windows 2000 Server and Windows Server 2003 because the default authentication protocol uses workstation time as part of the authentication ticket generation process. MIT Kerberos version 5 is the default authentication protocol.

For all Windows-based servers in an Active Directory® directory service domain, the Windows Time service configures itself automatically by using the Windows Time service that is available on domain controllers. The Windows Time service configures a domain controller in its domain as a reliable time source and synchronizes itself periodically with this source.

To correct this error, synchronize the clock on the Exchange server with the directory server.

To synchronize the clock on a server in an Active Directory domain

  1. Open a command prompt.

  2. Type w32tm /resync, and then press ENTER.

If this error persists or if many computers in your organization are generating this error, review how the Windows Time service has been deployed and configured in your Active Directory forest. For more information about the Windows Time service, see "Windows Time Service Technical Reference" (http://go.microsoft.com/fwlink/?LinkId=40648).

When Exchange front-end servers are out of synchronization with the Active Directory time, clients may receive "HTTP 500 internal server" errors when they try to connect to Microsoft Office Outlook® Web Access. For more information about this situation, see Microsoft Knowledge Base article 841546, "Known issues that cause the 'HTTP 500 internal server error' error message in Exchange 2000 Outlook Web Access" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=841546).


Timestamp comparison between the Active Directory Connector server and Active Directory exceeds 5 minutes
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_UTCTime Microsoft Windows® Management Instrumentation (WMI) class to determine the date and time on each Active Directory Connector (ADC) server. The Exchange Server Analyzer also retrieves the current date and time on the default domain controller. If the Exchange Server Analyzer determines that there is a difference of five minutes or more between the two servers, an error is displayed.

Microsoft Windows 2000 Server and Windows Server™ 2003 use the Windows Time service to synchronize the date and time of computers that are running on a Windows-based network. Synchronized time is critical in Windows 2000 Server and Windows Server 2003 because the default authentication protocol uses workstation time as part of the authentication ticket generation process. MIT Kerberos version 5 is the default authentication protocol.

For all Windows servers in an Active Directory® directory service domain, the Windows Time service configures itself automatically by using the Windows Time service that is available on domain controllers. The Windows Time service configures a domain controller in its domain as a reliable time source and synchronizes itself periodically with this source.

To correct this error, synchronize the clock on the ADC server with the directory server.

To synchronize the clock on a server in a Windows 2000 Server or Windows Server 2003 domain

  1. Open a command prompt.

  2. Type w32tm /resync, and then press ENTER.

If this error persists or if many computers in your organization are generating this error, review how the Windows Time service has been deployed and configured in your Active Directory forest. For more information about the Windows Time service, see "Windows Time Service Technical Reference" (http://go.microsoft.com/fwlink/?LinkId=40648).


Windows Server 2003 is not running the final released build
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the Version key on Active Directory Connector (ADC) servers in your Exchange organization. The Exchange Server Analyzer also examines the following registry entry to determine the version of Windows that is running on the ADC servers:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

If the Exchange Server Analyzer finds the value for the second instance of CurrentVersion to be 5.2, and the value of Version does not equal 5.2.3790, an error is displayed.

A CurrentVersion value of 5.2 indicates the computer is running a Windows Server 2003 operating system. The Version value for the released version of all Windows Server 2003 operating systems is 5.2.3790. Any other value for the Version key indicates that a pre-release version of Windows Server 2003 is in use.

Unless you are part of a Technology Adoption Program (TAP) or similar Microsoft-sponsored program, Microsoft does not support or recommend the use of pre-release software in production environments.

To correct this error

  1. Upgrade all Exchange infrastructure servers, including domain controllers, global catalog servers, ADC servers, and Exchange Server computers to the latest released software.

  2. If the upgrade option is available or supported, rebuild the operating system and restore the Exchange Server settings and data.

Upgrade all Exchange infrastructure servers, including domain controllers, global catalog servers, ADC servers, and Exchange Server computers to the latest released software.

For more information about Windows Server 2003 software updates, see the Windows Server 2003 Software Updates Web site (http://go.microsoft.com/fwlink/?LinkId=33760).


Windows Server 2003 is running pre-release software
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool examines the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the ServicePackMajorVersion key. The Exchange Server Analyzer also examines the following registry entry to determine the version of Windows that is running on the destination computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

If the value for the second instance of CurrentVersion is 5.2, and the value of ServicePackMajorVersion is greater than 1, the Exchange Server Analyzer displays a warning message.

A CurrentVersion value of 5.2 indicates the computer is running a Microsoft Windows Server™ 2003 operating system. A ServicePackMajorVersion greater than 1 indicates that a service pack later than Service Pack 1 (SP1) has been installed. Because SP1 is the only released service pack for Windows Server 2003, any Windows Server 2003 Service Pack 2 or later that is installed must be pre-release software.

Unless you are part of a Technology Adoption Program (TAP) or a similar Microsoft sponsored program, it is recommended not to run pre-release software in production environments.

To correct this warning

  1. Uninstall any pre-release software that has been installed.

  2. If the uninstall option is available, rebuild the operating system and restore the Exchange Server settings and data.

For more information about Windows Server 2003 software updates, see the Windows Server 2003 Software Updates Web site (http://go.microsoft.com/fwlink/?LinkId=33760).


Windows 2000 Server is not running Service Pack 4
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool examines the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the ServicePackMajorVersion key. The Exchange Server Analyzer also examines the following registry entry to determine the version of Windows that is running on the target computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

If the Exchange Server Analyzer determines that the target system is running a Windows 2000 Server operating system but is not running Service Pack 4 for Windows 2000 Server, a warning is displayed.

As a best practice, it is recommended that you install the latest service packs for all software in your Exchange deployment.

To correct this warning

  1. Update all domain controllers and global catalog servers that are running a Windows 2000 Server operating system to Service Pack 4, plus the latest hotfixes and updates from Windows Update.

  2. Update all Exchange Server computers to the latest service pack and update rollup.

For more information about obtaining and installing service packs for Windows 2000 Server operating systems, see the Web site, "Windows 2000 Service Packs" (http://go.microsoft.com/fwlink/?linkid=18353).

For more information about obtaining and installing Exchange Server service packs and roll-ups, see the Web site "Microsoft Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=21573).


Windows 2000 Server is not running the final released build
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2005-11-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key.

The Exchange Server Analyzer also examines the following registry entry to determine the version of Windows that is running on the computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 5.0 indicates the computer is running a Microsoft Windows 2000 Server operating system. The Version value for the release version of all Windows 2000 Server operating systems is 5.0.2195. Any other value for the Version key indicates a pre-release version of Windows 2000 Server is being used.

If the Exchange Server Analyzer finds the value for the second instance of CurrentVersion to be 5.0, and the value of Version does not equal 5.0.2195, an error is displayed.

Unless you are part of a Technology Adoption Program (TAP) or similar Microsoft-sponsored program, Microsoft does not support or recommend using pre-release software in production environments.

To correct this error

  1. Upgrade all Exchange infrastructure servers, including domain controllers, global catalog servers, Active Directory Connector (ADC) servers, and Exchange Server computers to the latest released software.

  2. If the upgrade option is available or supported, rebuild the operating system and restore the Exchange Server settings and data.

For information about obtaining and installing Windows 2000 Service Pack 4, see the Windows 2000 Service Pack 4 Web site (http://go.microsoft.com/fwlink/?LinkId=33241).


X.400 address has an invalid termination character
Microsoft Exchange Server Analyzer - Articles > Active Directory >

Topic Last Modified: 2006-12-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of gatewayProxy on your recipient policies and verify that the X.400 address ends in a semi-colon.

Correct formatting of an X.400 address in a recipient policy dictates that the address ends with a semi-colon. The semi-colon not being present will cause message routing to the X.400 address to be broken.

To correct this problem you will have to add a semi-colon to the end of the address using Active Directory Service Interfaces (ADSI) Edit or the LDP tool.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.
To correct this error

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Expand Configuration [DomainName], expand, CN=Configuration, DC=DomainName, DC=DomainSuffix.

  3. Expand CN=Services, and then expand CN=Microsoft Exchange.

  4. Expand CN=OrganizationName, expand CN=Administrative Groups, and then expand CN=Recipient Policies.

  5. right-click CN=PolicyName, and select Properties.

  6. Scroll down to locate gatewayProxy, select it, and then click Edit.

  7. In the Value field, enter the correct gatewayProxy.

  8. Close the Active Directory editor and restart the Exchange Server computer for the change to take effect.


Database Recovery
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2007-01-22

The articles in this section provide details on database errors and warning events detected by the Microsoft® Exchange Database Troubleshooter Tool in the Application event log. The Database Troubleshooter uses the same engine as the Microsoft Exchange Troubleshooting Assistant to programmatically execute a set of troubleshooting steps to determine the root causes of database mounting issues. Additionally, these articles provide steps that you can take to determine symptoms and resolve database-related issues.

For more information and to download the tool, see Microsoft Exchange Troubleshooting Assistant v1.0.


ESE 428 (0xfffff8f0): Insufficient Free Space Remaining on Transaction Log Drive
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-04-02

The Microsoft® Exchange Database Troubleshooter Tool detected one or more ESE 428 events in the Application log. This event indicates that there is insufficient free space on the transaction log drive. When this error is generated, Exchange Server will be unable to create a new transaction log file. This will cause all databases in the affected storage group to go offline because updates to the databases must be recorded in the transaction log.

Explanation

Exchange Server provides two mechanisms to prevent the transaction log drive from filling up:

  • Circular logging. Transaction logs are automatically deleted after the database checkpoint has advanced past them. Disk space that is used for transaction log files will remain under 50 MB under most conditions. During backup, removal of transaction logs may be suspended until the backup is complete.

    Note:
    By default, circular logging is not enabled in Microsoft Exchange 2000 Server and later versions.
  • Storage group backup. Exchange Server removes excess logs after a full or incremental online backup of all the databases in a storage group is performed by using a backup method that implements the Volume Shadow Copy Service (VSS) or streaming online backup APIs for Exchange Server.

If circular logging is not enabled and any one of the following conditions is true, the transaction log files will increase in number until the hard disk drive space is exhausted:

  • The backup program does not remove the transaction log files.

  • The backup program has stopped running.

  • The transaction log files are not purged by using some other method.

You may occasionally have to manually remove transaction log files if you have run out of hard disk space. Or you may occasionally have to manually remove transaction log files if you expect to out of hard disk space before you can run a full or incremental online backup of all the databases in a particular storage group. If you remove logs that are still ahead of any database checkpoint, and the database is then stopped abnormally, the database cannot be mounted until the necessary logs are restored. Therefore, you must determine which logs are safe to remove before you manually remove any Exchange Server transaction log files.

The error may also be reported as JET_errDiskFull or error code 0xfffff8f0. This error applies to the following versions of Exchange Server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve the error, select either of the following solutions:

  • Run the Database Recovery Management tool. In Microsoft Exchange Server 2007, the tool is listed under Database recovery tools in the Toolbox in the Exchange Management Console. The Exchange Server Analyzer can automatically determine which log files can be safely removed and will copy them to a backup location for you. We strongly recommend that you use the Exchange Server Analyzer to move log files.

    Note:
    The Exchange Server Analyzer will not work in Exchange 2007 if the storage group that contains the database is enabled for cluster continuous replication (CCR).
  • Check the State and Log Required values in each database header to determine which transaction log files are safe to be manually removed.

    Note:
    For the purposes of this article, removing a transaction log file means moving that transaction log file to another location where the transaction log file can be backed up, stored, or deleted. The action will depend on your requirements. For the purposes of this article, deleting a transaction log file refers to the kind of removal that does not let you to back up or restore that transaction log file.

Follow these detailed steps to determine which transaction log files are safe to be manually removed.

To examine the header of the database and remove unnecessary log files

  1. Dismount the database whose header you want to examine.

  2. Click Start, click Run, and then type cmd to open the Command Prompt window.

  3. At a command prompt, move to the directory path where the databases file is located.

    Note:
    In Exchange 2000 Server and Exchange Server 2003, to determine the path and the file name of the .edb and .stm files for a database, use Exchange System Manager to view the Database tab of the properties dialog box for each database object. In Exchange Server 2007, to determine the name and path of the database file, expand the Exchange Management Console under Server Configuration, click Mailbox, and then view the Database Management tab.

  4. Type the following Eseutil command together with the /MH switch at a command prompt:

    Copy Code
    "eseutil /MH databasefilename.edb"
    Note:
    In the syntax, databasefilename is the name of the database that you want to examine.

  5. Examine the State and Log Required values in the header information that appears.

    The State value provides the following information about whether the database has been correctly detached:

    • If the database has been correctly detached, the State value is either Clean Shutdown or Consistent. This value depends on the version of Exchange Server that is running. You may remove all the transaction log files except for the current transaction log file.

      Note:
      If you remove the current log file when all databases are in a Clean Shutdown state, you will cause a reset of the log file sequence. This does not prevent databases from starting. However, a reset of the log file sequence affects the ability to roll a database forward from a previous backup if the situation occurs.
    • If the database was incorrectly detached, the State value is Dirty Shutdown or Inconsistent. Determine which transaction log files can be removed by checking the Log Required field in the database header.

      Note:
      When the database is in a Dirty Shutdown or is Inconsistent, this means that some of the existing transaction log files contain outstanding transactions that are required by the database. If you remove the transaction log files in this situation, the database cannot be started again unless you restore the database from a backup. Alternatively, you can repair the database by using the Eseutil command and the Isinteg command.
      You should examine the Log Required values for each database in a storage group before you remove any logs for that storage group.

      The Log Required field lists the range of numbered log files that are required to start this database. If the range is 0 - 0, no log files are required to start this database. This indicates that the database is in a Clean Shutdown or Consistent state. If there are log files older than the checkpoint log, you can remove those log files excluding the checkpoint log.

      If you are running a version of Exchange Server that is earlier than Exchange Server 2003 Service Pack 1 (SP1), you must convert the decimal range that is listed in the Log Required field to hexadecimal values. For example, if the Log Required value is 28217 - 28221, log files from 06E39 to 06E3D are required by this database. In Exchange 2003 SP1, the Log Required field has been enhanced to report both decimal and hexadecimal values.

      Note:
      You can use the Scientific mode of the Windows Calculator to convert from decimal to hexadecimal. Start the Calculator, and then click Scientific on the View menu. Enter the decimal number, and then click Hex.
      Because you can have up to four storage groups in Exchange 2000 and in Exchange 2003 with each storage group having a particular set of log files, the Edb prefix does not appear in the transaction log file names. In Exchange 2000 and in Exchange 2003, the Edb prefix is replaced with E00, E01, E02, or E03. For a Recovery Storage Group, the Edb prefix is replaced with R00. The storage group log file name prefix appears in Exchange System Manager on the General tab of the properties dialog box for the particular storage group object. Therefore, if the storage group prefix is E01 and if the Log Required entry is 28217 - 28221 (0x06E39 - 0x06E3D), the actual logs that are required are E0106E39.log to E0106E3D.log.

  6. You can safely remove all the numbered log files that are less than the lowest entry in any Log Required field for any database in the storage group.

    Note:
    Remember to move, not delete, the log files.
    Note:
    As a best practice, you should not remove the most recent transaction log file. This is the log file that has the most recent timestamp and that does not yet have a sequence number in its file name. Even if you have determined that it is safe to remove this file, let it remain to avoid resetting the log file sequence back to 0. If you reset the log file sequence, you will affect backup cycles. You may be unable to roll the database forward from a backup taken before the reset.


ESE 454 -515: Missing Required Transaction Log File
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Server Analyzer Tool found an ESE event 454 with error code -515. This error indicates that the Exchange database could not be mounted because a required transaction log file is missing

Explanation

An ESE 454 event with a -515 error can occur if the Extensible Storage Engine (ESE) tries to bring all databases in a storage group to a consistent state during the recovery process. If any required transaction log file are missing, the recovery process fails, and the database cannot mount with the -515 error.

User Action

To resolve this issue, do one or more of the following:

  • Using the procedures here, determine which transaction log files are missing and where they are located. Then move them back into the transaction log directory for the storage group.

  • Restore the affected database(s) from backup.

Caution:
You should not try to restore the database unless the prior solution of locating and restoring the specific missing transaction log files has failed. Doing this will cause all data since the last backup to be overwritten.
Note:
Prior to restoring the database(s), move or delete any transaction log files that are associated with the affected storage group from the destination path.
To identify missing transaction log files by using the Microsoft Exchange Troubleshooting Assistant in Exchange Server 2003 and Exchange Server 2007

  1. From the Microsoft Exchange Troubleshooting Assistant Display Examining Event Log Results window, click the Use related Database Recovery Management task to verify and resolve this issue link to identify the missing required transaction log files.

  2. Record the log file names reported in step 1.

  3. Determine the current location of the log files and move them back to the expected location.
Note:
Be sure to search the Recycle Bin and any antivirus quarantine folders when you determine the current location of the missing transaction log files.
  1. Try to mount the affected Exchange database.

 To manually identify and restore missing transaction logs on Exchange 2000 Server or Exchange Server 2003

  1. Start Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, right-click your storage group, and then click Properties.

  3. On the General tab, under Transaction log location, record the path of the location of the transaction log files.

  4. At a command prompt, open the directory where Eseutil.exe is located. The default path for Eseutil.exe in Exchange 2000 Server and Exchange Server 2003 is C:\program files\exchsrvr\bin.

  5. At the command prompt, enter the following command:

    Copy Code
    eseutil /ml "logpath\logprefix"

    Where logpath is the path of the transaction log files recorded in step 3 and logprefix is the prefix of the transaction log files, usually e00.

    An example of this command using the defaults would be as follows:

    eseutil /ml "c:\program files\exchsrvr\mdbdata\e00".

  6. Transaction log files that are missing will be reported in one of the following two formats depending on which of the log files is missing:

    • Missing log file: c:\program files\exchsrvr\mdbdata\E0002BE2.log

    • ERROR: Missing log file(s). Log file is generation 11,235 (0x2BE3), but expected generation is 11,234 (0x2BE2).

    Where 0x2BE2 would be the missing log file, E0002BE2.log.

  7. Record the log file names reported in step 6.

  8. Determine the current location of the log files and move them back to the expected location from step 3.
Note:
Be sure to search the Recycle Bin and any antivirus quarantine folders when you determine the current location of the missing transaction log files.
  1. Try to mount the affected Exchange database.

 To manually identify and restore missing transaction logs on Exchange Server 2007

  1. Start the Exchange Management Console on the server on which the storage group is located.

  2. In the console tree, expand Server Configuration, and then click Mailbox.

  3. In the results pane, click the Mailbox server that contains the storage group for which you want to restore the missing transaction log files.

  4. Right-click your storage group, and then click Properties

  5. . On the General tab, under Log path, record the path of the location of the transaction log files.

  6. At a command prompt, open the directory where Eseutil.exe is located. In Exchange Server 2007 Eseutil is located in the Exchange default install folder. This is <SystemDrive>:\Program Files\Microsoft\Exchange Server\Bin.

  7. At the command prompt, enter the following command:

    Copy Code
    eseutil /ml "logpath\logprefix"

    Where logpath is the path of the transaction log files recorded in step 5 and logprefix is the prefix of the transaction log files, usually e00.

    An example of this command using the defaults would be as follows:

    eseutil /ml "c:\Program Files\Microsoft\Exchange Server\Bin\e00".

  8. Transaction log files that are missing will be reported in one of the following two formats depending on which of the log files is missing:

    • Missing log file: c:\Program Files\Microsoft\Exchange Server\Bin\E000000049A.log

    • ERROR: Missing log file(s). Log file is generation 11,235 (0x2BE3), but expected generation is 11,234 (0x2BE2).

    Where 0x2BE2 would be the missing log file, E0002BE2.log.

  9. Record the log file names reported in step 8.

  10. Determine the current location of the log files and move them back to the expected location from step 5.
Note:
Be sure to search the Recycle Bin and any antivirus quarantine folders when you determine the current location of the missing transaction log files.
  1. Try to mount the affected Exchange database.

For more information about ESE Event 454, see the "Events and Errors Message Center" (http://go.microsoft.com/fwlink/?LinkId=81883).


ESE 455 -1811 (0xfffff8ed): Missing Current (Exx.log) Transaction Log File
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-05-31

The Microsoft Exchange Database Troubleshooter Tool detected one or more ESE 455 events with error code -1811 (0xfffff8ed) in the Application log. This event indicates that the current transaction log (exx.log) is missing, inaccessible, or has a mismatched signature.

Explanation

The error may be caused by the following:

  • Error 1811 that corresponds to JET_errFileNotFound. This issue may occur in an Exchange log file that has a mismatching signature and an internal log generation number (LGeneration). Typically, the Exchange log file is the E00.log file. If the E00.log file has a mismatched signature, the information store might not mount even if the database is consistent.

  • An antivirus program quarantines or deletes the current Exchange log file.

  • The eseutil /p repair command was run on the affected databases and the log files were not removed.

  • The eseutil /r recovery command was run with an incorrect log file base name, as in the example, eseutil /r Exx.log, where Exx.log is a three-character log file base name.

This error can also be identified as error -1811, JET_errFileNotFound. This error applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve the error, do one or more of the following:

  • If the log file has a mismatched signature and log generation number, contact Microsoft Customer Support Services. For more information, visit the Contact Us page of the Microsoft Help and Support Web site.

  • If an antivirus program quarantines or deletes the current Exchange log file, follow these steps:

    • Examine the configuration of the antivirus program.

    • Make sure that the antivirus program is not configured to scan the Exchange Server directories.

    • By default, some antivirus programs are set to scan drives and directories weekly in a manual mode or in an automatic mode. This setting may be easily overlooked. Make sure that you add the Exchange Server directories to the excluded locations for the antivirus program. For more information about how to configure antivirus programs to work together with Exchange, see Microsoft Knowledge Base article 823166, Overview of Exchange Server 2003 and antivirus software.

    • Review the antivirus program log files to verify that the Exchange log file was quarantined or deleted.

    Use one of the following methods to recover the Exchange log file:

Method 1: If the Exchange log file was quarantined

  1. Recover the Exchange log to the folder that contains your production log files.

  2. Start the Microsoft Exchange Information Store service. If no other log files are missing, the database mounts. If other log files are missing, see whether the missing log files are located in the quarantine folder of the antivirus program. If the log files are not located in the quarantine folder, see Method 2.

If the Exchange log file was deleted, you must restore the storage group database from a backup. Then, you must replay the log files. To restore an available database, follow these steps:

Method 2: If the Exchange log file was deleted

  1. Move all inconsistent databases to a backup folder.

  2. If a new E00.log file was created, move the new E00.log file to the backup folder. Additionally, move the E00.chk file to the backup folder.

  3. Copy all existing log files to the backup folder.Note You must copy the log files. Do not move the log files.

  4. Rename the last E00*.log file to E00.log.

  5. Restore the database from a backup. Then, replay the log files. This brings the database to a consistent state. However, the database does not include the E00.log file that was copied to the backup folder. Although there is some data loss, you now have a database that can be mounted.

    Note:
    If you cannot restore the database from a backup, run repair utilities against the database to bring the database to a consistent state

  6. Start the Microsoft Exchange Information Store service.

If the eseutil /p repair command was run on the affected databases and the log files were not removed, follow these steps:

To determine whether the eseutil /p command was run

  1. Click Start, click Run, type cmd, and then click OK.

  2. Type the following at the command prompt:

    Copy Code
    c:\program files\exchsrvr\bin\eseutil /mh "c:\program files\exchsrvr\mdbdata\<name of Exchange database.edb>"

    This syntax earlier assumes the following:

    • The Exchange Server program files were installed in the c:\program files\exchsrvr folder.

    • Your database is in the c:\program files\exchsrvr\mdbdata folder.

  3. Read the repair count attribute. If the repair count attribute is 0 (zero), the eseutil /p command was not run. If the repair count attribute is a number other than 0, the eseutil /p command was run on the database.

If the public and private databases are in a consistent or clean shutdown state, you can move the transaction log files to another folder. To determine whether the databases are in a consistent or clean shutdown state, follow these steps:

To determine whether the databases are in a consistent or clean shutdown state

  1. Click Start, click Run, type cmd, and then click OK.

  2. To examine the private information store, type the following:

    Copy Code
    c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\priv1.edb"

  3. To examine the public information store, type the following:

    Copy Code
    c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\pub1.edb"

    The syntax in steps 2 and 3 assume the following:

    • The Exchange Server program files were installed in the c:\program files\exchsrvr folder.

    • Your database is in the c:\program files\exchsrvr\mdbdata folder.

  4. Review the results of the consistency check. If a database is consistent (state = clean shutdown), all the log files have been committed to the information store. If the database is not consistent (state = dirty shutdown), the database may not be corrupted. The log files may not have been committed to the database yet.

  5. If the state reports clean shutdown, move all log files from all the mdbdata directories to a backup folder.

  6. Mount the databases.
  • If the eseutil /r recovery command was run with an incorrect log file base name, use the correct switch to successfully run the command. The common logfile base names are e00, e01, e02 and e03. For example, the following command contains a correct logfile base name:

    Copy Code
    eseutil /r e00
  • If the problem persists, contact Microsoft Customer Support Services. For more information, visit the Contact Us page of Microsoft Help and Support Web site.


ESE 474 -1018: Unrecoverable Error Detected in Database
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-03-28

The Microsoft Exchange Database Troubleshooter tool detected one or more ESE 474 events with error code -1018 in the Application log. This error is generated if the Microsoft Exchange integrity verification component determines that Exchange Server could not correctly store or retrieve Exchange database file data from the hard disk subsystem.

Explanation

An ESE 474 event with a -1018 error can occur because of a defective hard disk subsystem hardware component, or because of outdated or incompatible drivers and or firmware in the hard disk subsystem.

After encountering a -1018 error, diagnostic hardware tests run against the server may report no disk subsystem hardware issues, and the assumption might reasonably be that Exchange Server is responsible for the issue.

Extensive investigation by Microsoft and the hardware vendors has determined that subtle issues with the disk subsystem hardware components, supporting drivers and or firmware, are responsible for most -1018 errors.

Exchange reports a -1018 error when an initialized page in the database file is found with either of the following conditions:

  • The checksum that is stored on the page does not match the result of the checksum recalculation that is performed as the page is read.

  • The page number that is stored on the page does not match the page number that should be on the page, given the page's physical location in the database file.

Exchange might be responsible for self-generating a -1018 error if one of the following scenarios occurs:

  • Exchange builds a page that has the wrong checksum.

  • Exchange builds a page correctly, but tells the operating system to write the page to the wrong location.

Exchange generates a checksum for a page that is about to be written to disk after all the data has been written to the page. This includes the page number itself. After Exchange adds the checksum to the page, Exchange instructs the Windows operating system to write the page to disk by using standard, published Windows-based APIs.

Transient memory errors may cause the page to then be written to the wrong location on the hard disk.

Even though the page checksum is correct, Exchange reports a -1018 error because the logical page number does not match the physical page number.

A single -1018 error that is reported in an Exchange database generally does not cause the Exchange database to stop or result in a symptom other than the presence of the -1018 error itself. The affected page might be in a folder that is infrequently accessed, such as the Sent or Deleted Items folders, or in an attachment that is rarely opened, or even empty.

Although a single -1018 error is unlikely to cause extensive data loss, -1018 errors are a problem because they can indicate that the storage system did not reliably store or retrieve data at least once. The -1018 error is an early warning of an issue that will probably become progressively worse. Even if the first -1018 error is reported for an empty page in the database, it is unknown which page might be damaged next. If a critical global table is damaged, the Exchange database may not start, and database repair might be unsuccessful or only partly successful.

After a -1018 error is logged, consider and plan for the possibility of imminent failure or additional random damage to the database until you find the root cause of the error.

User Action

Before you try to correct the ESE 474 -1018 error(s) logged in the Application log, make sure that the disk subsystem of the server is stable.

To troubleshoot the disk subsystem, do the following:

  1. Open the Application log, and search for ESE 474 events. In each event, note the full path of the affected database. After you compile a list of affected databases, note the drive letters referenced in the database paths. This information will enable you to target your troubleshooting efforts directly toward these physical disks.

  2. Review the System log, and make sure that there are no disk read, write, or time-out errors being logged.

  3. Use manufacturer provided disk subsystem diagnostic utilities, and contact the disk subsystem hardware vendor for more help in verifying the integrity of the disk subsystem.

Having corrected any issues with the disk subsystem, or having otherwise verified its stability, use the following methods to recover from the -1018 error. These methods are listed in preferred order or usage:

First Method Move mailboxes from the database(s) referenced in the ESE 474 event(s) from the Application log. Either move the mailboxes to an existing, known good store(s), or create a new Mailbox Store(s) specifically for this purpose. When all mailboxes have been moved, delete the corrupted Mailbox Store(s).

To move mailboxes (Exchange 2000 Server or Exchange Server 2003)

  1. In Active Directory Users and Computers, select the user or users whose mailboxes you want to move.

  2. Right-click the user list you selected in the previous step, and then click Exchange Tasks.

  3. In the Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

  4. Carefully read and follow the remaining steps in the wizard.
To move mailboxes (Exchange Server 2003 only)

  1. In Exchange System Manager, expand Servers, expand the server from which you want to move mailboxes, expand the Storage Group from which you want to move mailboxes, expand the Mailbox Store that contains the mailboxes that you want to move, and then click Mailboxes.

  2. In the details pane, right-click the user or users whose mailboxes you want to move, and then click Exchange Tasks.

  3. In the Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

  4. Carefully read and follow the remaining steps in the wizard.
To move mailboxes using the Exchange Management Console for Exchange Server 2007 only

  1. Start the Exchange Management Console.

  2. In the console tree, expand Recipient Configuration, and then click Mailbox.

  3. In the result pane, click the mailbox or mailboxes that you want to move.

  4. In the action pane, click Move Mailbox.

  5. In the Move Mailbox Wizard, on the Introduction page, select the server, storage group, and mailbox database to where you want to move the mailbox, and then click Next.

  6. On the Move Options page, select an option for handling corrupted messages in a mailbox, and then click Next.

  7. On the Move Schedule page, specify when the move should occur, and then click Next.

  8. On the Move Mailbox page, review the summary to confirm the mailbox moves, and then click Move.

  9. On the Completion page, click Finish.

For more information about supported scenarios for using the Move Mailbox wizard and the Move-Mailbox cmdlet, see "Moving Mailboxes" (http://go.microsoft.com/fwlink/?LinkId=85754) in the Exchange Server 2007 product documentation.

Second Method Restore the database(s) from a known good backup. For more information about how to restore Exchange Server databases, see the following articles:

  • Exchange Server 2007 "Disaster Recovery" (http://go.microsoft.com/fwlink/?LinkId=85802)

  • "Exchange 2003 Disaster Recovery Operations Guide" (http://go.microsoft.com/fwlink/?linkid=30250)

Third Method Use Eseutil to perform a hard repair of the affected database(s). This method should only be performed if the previous two methods have failed. After you run the hard repair, you must also perform an offline defragmentation of the repaired database, and run the Isinteg tool to repair logical corruption. These steps can be performed by using the Exchange Database Troubleshooter Repair Task. This will automatically run the Eseutil /P, Eseutil /D, and Isinteg regimen for you.

For More Information

For more information about this issue, see the following Microsoft Knowledge Base articles and Exchange Resources:

  • 314917, "Understanding and analyzing -1018, -1019, and -1022 Exchange database errors" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=314917)

  • 867626, "New error correcting code is included in Exchange Server 2003 SP1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=867626)

  • 259851, "Ramifications of running the eseutil /p or edbutil /d /r command in Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=259851)

  • "Exchange Server Error -1018" (http://go.microsoft.com/fwlink/?LinkId=85807)


MSExchangeIS 1003: Insufficient Free Space Remaining on Exchange Database Drive
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-22

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 1003 events in the Application log. This error can occur if there is insufficient amount of free disk space on the drive that contains the databases that you are trying to mount.

Explanation

When the disk that contains the Exchange databases runs out of free disk space, the Microsoft Exchange Information Store service will log an MSExchangeIS 1003 event, and the affected databases will dismount. After this occurs, you may be unable to mount the databases for the affected storage group. This error applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve this issue, free some disk space on the database drive, and then try to mount the databases again. To do this, perform one or more of the following:

  • If the Exchange database files are the only files that are located on the hard disk, you may have to perform an offline defragmentation of the databases to free disk space.

    Note:
    Depending on how much free space is available in the database, this step may not resolve your issue.
    For more information about performing this step, see Microsoft Knowledge Base article 328804, How to defragment Exchange databases.

    In addition, see How to Run Eseutil /D ( Defragmentation ).

  • If the Exchange transaction log files are also located on this drive, you may be able to free disk space by removing unnecessary log files.

    For more information about performing this step, see Microsoft Knowledge Base article 240145, How to remove Exchange Server transaction log files.


MSExchangeIS 1088: Cannot mount database because of invalid legacyExchangeDN
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected an MSExchangeIS 1088 event. This event indicates that the Exchange database could not be mounted because it has a legacyExchangeDN attribute value that is different from what is stored in Active Directory.

Explanation

An MSExchangeIS 1088 event can occur if an Exchange database is restored to an Administrative Group that has a different value for the legacyExchangeDN attribute than its original Administrative Group. This behavior is by design. To mount stores on an Exchange Server, the value for the legacyExchangeDN attribute of the Organization and the Administrative Group of the Exchange databases must match the value for legacyExchangeDN attribute of the Organization and the Administrative Group in Active Directory.

User Action

To resolve this issue, do the following:

  • Restore the Exchange database to its original Administrative Group.

  • If the Exchange database cannot be restored to its original Administrative Group, rename the Active Directory objects of the intended destination so that they have the same value for the legacyExchangeDN attribute as the Exchange database. You can correct the value using a tool such as Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.
To correct this error

  1. Using ADSI Edit or a similar tool, locate the administrative group object in Active Directory.

    The legacyExchangeDN attribute can be found at:

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group

  2. Type a new string value of the form:

    /o= organization /ou= administrative group

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in Windows Server 2003 Help.

For more information about the MSExchangeIS Event 1088, see the following resources:

  • Events and Errors Message Center

  • Microsoft Knowledge Base article 280652, "XADM: "Event ID 1088" Is Logged and Store Fails to Mount" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=280652)


MSExchangeIS 5000 (0x3f5): Invalid Service Account Configured for the Information Store Service
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-02-27

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 5000 events with error code 0x3f5 in the Application Log. This error occurs when the Microsoft Exchange Information Store service is configured to start with an account other than Local System.

Explanation

This issue can occur if the Microsoft Exchange Information Store service (Store.exe) is using an account other than the Local System account, or if the domain controller, the domain, or the Local Machine Security Policy does not include the Local Service account in the Generate Security Audits policy. When this problem occurs, the Exchange Information Store service fails to initialize. The error applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve this issue, perform one or more of the following:

  • By default, the Exchange Information Store service uses the Local System account to start the Information Store service (MACHINENAME$). Use the Services.msc snap-in to check which account is being used to start the Information Store service. If the account is the Local System account, you must grant the Local System account the Generate Security Audits right. To do this, use one of the following methods:

    • Rerun the Exchange Setup /domainprep command from this computer.

    • Manually grant the Local System account the Generate Security Audits right on one of the following policies:

    1. The domain controller's policy

    2. The domain policy

    3. The Local Machine Security Policy

      To re-grant this right to the Local Machine Security Policy of a member server, follow these steps.

      Note:
      This is the recommended solution if this issue is only occurring on one server.
      To re-grant audits right to the Local Machine Security Policy of a member server

      1. Click Start, click Administrative Tools, and then click Local Security Policy.

      2. Expand Security Settings, click Local Policies, and then click User Rights Assignment.

      3. In the right pane, double-click Generate security audits, click Add, enter the MACHINENAME$, and then click OK two times.

      4. Exit the Group Policy snap-in.
  • If you start the Information Store service by using an account that is not the Local System account, you should change it back to the Local System account (MACHINENAME$). Then, try to start the Information Store service. For more information about why Exchange 2000 Server and Exchange Server 2003 use the Local System account to start Exchange services, see Microsoft Knowledge Base article 239762, Exchange S ervices R un U nder LocalSystem.

For More Information

For more information, see Microsoft Knowledge Base article 281850, Information store does not start with event ID 9530 and 5000 messages in Exchange 2000 Server and in Exchange Server 2003.


MSExchangeIS 5000 (0x80004005): Cannot Mount Database Because of Incorrect Service Account or Missing SeSecurityPrivilege Permissions or Incorrect Group Membership
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-02-19

The Microsoft Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 5000 events with error code 0x80004005 in the Application log. The event indicates that a database or databases on the Exchange server cannot be mounted because of an incorrect service account, missing SeSecurityPrivilege permissions, or incorrect group membership.

Explanation

The event can occur when any of the following is true:

  • The Manage auditing and Security log permission (SeSecurityPrivilege) is removed from the Exchange Enterprise Servers group on one or more domain controllers. The Exchange Enterprise Servers group must have the Manage auditing and Security log permission on all domain controllers in the domain. When this condition is true, one or more Exchange Server related services will not start.

  • The Microsoft Exchange Information Store service is starting with an account other than Local System, or if the domain controller, the domain, or the Local Machine Security Policy does not include the Local Service account in the Generate Security Audits policy. When this condition is true, the Exchange Information Store service does not start.

  • The Exchange Enterprise Servers group from the parent domain does not contain the Exchange Domain Servers group from the child domain.

The event can also be identified as MAPI_E_CALL_FAILED. The event applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve the issue, do one or more of the following:

  • If Manage auditing and Security log permission (SeSecurityPrivilege) is removed from the Exchange Enterprise Servers group on one or more domain controllers, follow these steps:

    To add permissions on one or more domain controllers

    1. Use Policytest.exe to troubleshoot permissions issues. Policytest.exe is located in the Support\Utils\I386 folder on the Exchange 2000 Server CD, or in the Support\ExDeploy folder on the Exchange Server 2003 CD. Use Policytest.exe to determine whether the "Manage auditing and security log" permission for the Exchange Enterprise Servers group is missing from a domain controller. A successful result returns information that resembles the following:

      Local domain is "<contoso.com>" (contoso) Account is "CONTOSO\Exchange Enterprise Servers" DC = "<ComputerName>" In site = "<Default-First-Site-Name>" Right found: "SeSecurityPrivilege"

      Note A successful result shows that the "Manage auditing and security log" permission exists. You must have domain administrator rights to run Policytest.exe. For more information about the Policytest.exe utility, see Microsoft Knowledge Base 281537, XADM: Description of the Policytest.exe Utility.

    2. Reset the Exchange Enterprise Server default permissions at the domain level. To do this, follow these steps:

      1. Run the setup /domainprep command from the Exchange Server CD or from a network installation point. The setup /domainprep command adds the Exchange Enterprise Servers group to the domain that has default permissions. When you run the setup /domainprep command, the permissions are immediately added to one domain controller. Then, the change replicates to the other domain controllers.

      2. Restore permissions inheritance to other organizational units. Then, wait for the domain controllers to replicate the changes throughout the domain.

      3. Run Policytest.exe. Note which domain controllers return the following successful result:

        Right found: "SeSecurityPrivilege"

        If all domain controllers have the correct permissions, restart the Exchange Server services. If no domain controllers have the correct permissions, see step 3.

    3. Verify the default domain controllers' policy. To do this, follow these steps:

      1. Start the Active Directory Users and Computers snap-in.

      2. Right-click the Domain Controllers container, and then click Properties.

      3. Click the Group Policy tab, and then make sure that Default Domain Controllers Policy is listed in the Group Policy Object Links box.Note If Default Domain Controllers Policy is not listed, click Add, click Default Domain Controllers Policy, and then click OK. Then, wait for this change to replicate to all other domain controllers.

      4. Run the setup /domainprep command from the Exchange Server CD or from a network installation point. The setup /domainprep command adds the Exchange Enterprise Servers group to the domain that has default permissions.

      5. Run Policytest.exe. Note which domain controllers return the following successful result:

      Right found: "SeSecurityPrivilege"

      If all domain controllers have the correct permissions, restart the Exchange Server services. If some domain controllers do not have the correct permissions, see step 4.

    4. Manually add permissions to the domain controller. The File Replication Service (FRS) may not replicate the updated security policy to one or more domain controllers after you run the setup /domainprep command. If this problem occurs, you must manually assign the correct permissions to the Exchange Enterprise Servers group. If some domain controllers or all domain controllers do not have the correct permissions, assign the "Manage auditing and security log" permission to the Exchange Enterprise Servers group. Then, wait for the setting to replicate to the other domain controllers. To do this, follow these steps:

      1. Start the Active Directory Users and Computers snap-in.

      2. Right-click the Domain Controllers container, and then click Properties.

      3. Click the Group Policy tab, click Default Domain Controllers Policy in the Group Policy Object Links box, and then click Edit.

      4. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click User Rights Assignment.

      5. In the right pane, double-click Manage auditing and security log, click Add, click Browse, and then add the Exchange Enterprise Servers group.

      6. In the Add user or group dialog box, click OK. Then, click OK again.

      7. Exit the Group Policy snap-in, and then click OK in the Domain Controllers Properties dialog box.Note Sometimes, the Exchange Enterprise Servers group may not be visible when you click Browse in the Add user or group dialog box. If this behavior occurs, add the Exchange Domain Servers group. Then, run the setup /domainprep command again. This process makes the addition of the Exchange Enterprise Servers group persist across all domain controllers.
  • If the Exchange Information Store service is starting with an account other than Local System, or if the domain controller, the domain, or the Local Machine Security Policy does not include the Local Service account in the Generate Security Audits policy, follow the resolution prescribed here.

    By default, the Exchange Information Store service uses the Local System account to start the Information Store service (MACHINENAME$). Use the Services.msc snap-in to check which account is being used to start the Information Store service. If the account is the Local System account, you must regrant the Local System account the Generate security audits right. To do this, use one of the following methods:

    To regrant the Generate security audits right to the Local System account

    1. Rerun the Exchange Setup /domainprep command from this computer.

    2. Manually grant the Local System account the Generate security audits right on one of the following policies:

      • The domain controller's policy

      • The domain policy

      • The Local Machine Security policy

    To regrant the Generate security audits right to the Local Machine Security policy of a member server

    1. Click Start, click Administrative Tools, and then click Local Security Policy.

    2. Expand Security Settings, click Local Policies, and then click User Rights Assignment.

    3. In the right pane, double-click Generate security audits, click Add, enter the MACHINENAME$, and then click OK two times.

    4. Exit the Group Policy snap-in.

    If you start the Information Store service by using an account that is not the Local System account, you should change it back to the Local System account (MACHINENAME$). Then, try to start the Information Store service. For more information about why Exchange 2000 Server and Exchange Server 2003 use the Local System account to start Exchange services, see Microsoft Knowledge Base article 239762, Exchange Services Run Under LocalSystem.

  • If Exchange Enterprise Servers group from the parent domain does not contain the Exchange Domain Servers group from the child domain, add the Exchange Domain Servers group from the child domain to the Exchange Enterprise Servers group in the parent domain. You can also resolve this problem by creating the Recipient Update Service in the root domain.

    To resolve this issue, run Exchange Setup with the /domainprep switch on a server in the remote Windows domain. Then, on the Exchange server use the Exchange System Manager to create a Recipient Update Service for the remote domain. To do this, follow these steps:

    To create a Recipient Update Service for the remote domain

    1. Click Start, click Programs, click Microsoft Exchange, and then click System Manager.

    2. Expand the Organization object, and then expand the Recipients container.

    3. Click Recipient Update Service.

    4. In the right pane, right-click New, and then click Recipient Update Service.

    5. Click the domain that does not have an instance of the Recipient Update Service and that has users who must be updated by Exchange.

    6. Click Next.

    7. Select the server where you want to run the Recipient Update Service and process all the necessary users with the Exchange attributes.

    8. Click Next.

    9. Click Finish.

    10. To manually initiate an update of the recipients in that domain, right-click the Recipient Update Service, and then click Update Now to force an update.
    For more information, see Microsoft Knowledge Base article 253770 Tasks performed by the Exchange Recipient Update Service.


MSExchangeIS 5000 (0x80040154): Missing or Corrupted SMTP Service Extensions
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-02-19

The Microsoft Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 5000 events with error code 0x80040154 in the Application log. This error can occur if the Exchange Server Simple Mail Transfer Protocol (SMTP) Service extensions are either missing or corrupted.

Explanation

This problem occurs because the Exchange SMTP Service extensions are either missing or corrupted. This behavior causes loss of functionality between Exchange and the SMTP Service. The SMTP Service is a necessary service that is installed as a subcomponent of Microsoft Internet Information Services (IIS).

The error may occur for the following reasons:

  • IIS has been removed.

  • The SMTP Service subcomponent has been removed from IIS.

  • IIS has been removed, and then reinstalled as a Windows component that does not have the required SMTP Service subcomponent.

  • IIS has been removed and then reinstalled as a Windows component that has the appropriate list of subcomponents. However, the Exchange SMTP Service extensions have not been reinstalled.

This error applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve this error, see Microsoft Knowledge Base article 326305, The Information Store does not start and MSExchangeIS Event ID 5000 and 9538 messages occur in Exchange 2000 Server and Exchange Server 2003.

To restore SMTP service extensions

  1. Confirm that the Exchange SMTP Service extensions are missing. To do this, follow these steps:

    1. Log on to the computer that is running Microsoft Exchange by using an account that has administrative credentials.

    2. Click Start, click Run, type cmd, and then click OK.

    3. Type telnet 127.0.0.1 25 at the command prompt to view the "220 server.domain.com Microsoft ESMTP Mail Service" entry.

    4. Type EHLO, and then press Enter to view a list of 250 command verbs.If there are no verbs whose names start with "X," the SMTP Service Extensions are missing.

  2. Completely back up the system partition. Include the system state and the Exchange database files. For more information about how to do this, see Microsoft Knowledge Base article 258243, How to back up and restore an Exchange computer by using the Windows Backup program.

  3. Confirm that IIS has been correctly reinstalled to include the required Exchange-dependent subcomponents.

    IIS 6.0

    1. Click Start, point to Settings, and then click Control Panel.

    2. Double-click Add/Remove Programs.

    3. In the left pane, click Add/Remove Windows Components.

    4. In the Windows Components wizard, locate Application Server in the list of components, and then click Details.

    5. If any of the following components are not installed, install them:

      ASP.NET

      Enable network COM+ access

      Internet Information Services (IIS)

    6. Click Internet Information Services (IIS), and then click Details

    7. If any of the following components are not installed, install them:

      Common Files

      Internet Information Services Manager

      NNTP Service

      SMTP Service

      World Wide Web Service

    8. Click OK two times. On the main Windows Components page, click Next, and then click Finish.

    IIS 5.0

    1. Click Start, point to Settings, and then click Control Panel.

    2. Double-click Add/Remove Programs.

    3. In the left pane, click Add/Remove Windows Components.

    4. In the Windows Components Wizard dialog box, locate Internet Information Services (IIS) in the list of components. If the Internet Information Services (IIS) check box is selected, IIS is installed. To view the IIS subcomponents that are installed, click Internet Information Services (IIS), and then click Details.

    5. If IIS is not installed, click to select the Internet Information Services (IIS) check box, and then click Details. Install the IIS 5.0 subcomponents, and then click OK. The minimum IIS 5.0 subcomponents that are required before you install Exchange 2000 are as follows:

      Common files

      Internet Information Services snap-in

      SMTP service

      Network News Transfer Protocol (NNTP) service (for newsgroups)

      World Wide Web service

    6. Click Next, and then click Finish.

  4. Restore the Exchange SMTP Service extensions.

    Exchange Server 2003

    If you reinstall Exchange 2003 over an existing Exchange 2003 installation, the database files and permissions remain intact. To do this, follow these steps:

    1. Insert the Exchange 2003 CD.

    2. In the \SETUP\I386 folder, double-click the Setup.exe file.

    3. On the Welcome page, click Next until you reach the Component Selection page.

    4. On the Component Selection page, click Reinstall in the Action column, and then click Next.

    5. Verify the selection on the Installation Summary page, and then click Next to continue the Exchange 2003 installation.

    Exchange 2000 Server

    The methods that you can use to restore the Exchange 2000 SMTP Service extensions depend on how many IIS subcomponents were removed. If the SMTP Service is the only IIS subcomponent that was removed, and Exchange 2000 Server Service Pack 2 (SP2) or a later service pack has been installed, use the Smtpreinstall.exe command-line utility. The Smtpreinstall.exe command-line utility is located in the Server\Support\Utils\I386 folder.

    To use the Smtpreinstall.exe utility

    1. Copy the Smtpreinstall.exe file to the Exchsrvr\Bin folder.

    2. At the command prompt, change to the Exchsrvr\Bin folder, and then type the following command:

      smtpreinstall.exe

    3. Restart the computer when you are prompted.

    If IIS 5.0 was removed as a component or if more than the SMTP Service subcomponent was removed from IIS 5.0, reinstall Exchange 2000 over the existing installation as part of the integrated setup of Microsoft Small Business Server 2000.

    To reinstall Exchange 2000 Server

    Note:
    If you reinstall Exchange 2000 over an existing Exchange 2000 installation, the database files and permissions remain intact.
    1. Insert the Exchange 2000 Server CD.

    2. In the \SETUP\I386 folder, double-click the Setup.exe file.

    3. On the Welcome page, click Next.

    4. Enter your CD key if you are prompted, and then click Next.

    5. On the Component Selection page, click Reinstall in the Action column, and then click Next.

    6. Verify the selection in the Installation Summary page, and then click Next to continue the Exchange 2000 installation.

  5. Reinstall the Exchange service packs and hotfixes.

    For more information, see the following Microsoft Knowledge Base articles:

    836993 How to obtain the latest service packs for Exchange Server 2003.

    301378 How to obtain the latest Exchange 2000 Server service pack.


MSExchangeIS 5000 (0xc004038a): Cannot Mount Database Because of Incorrect Permissions or Deleted Routing Group
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-05-31

The Microsoft Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 5000 events with error code 0xc004038a in the Application log. When this error occurs, the Microsoft Exchange Information Store service will not initialize and databases will not be mounted.

Explanation

The event MSExchangeIS 5000 with error code 0xc004038a can occur because of incorrect permissions or a deleted routing group. This event may be caused by one or more of the following:

  • The Exchange Server is no longer a member of a routing group, or its routing group was deleted from Active Directory.

  • The Exchange Domain Servers group does not have the appropriate permissions in Active Directory.

This event applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve the error, do one or more of the following:

  • If the Exchange Domain Servers group does not have appropriate permissions, use the Active Directory Service Interfaces (ADSI) Edit utility to make sure that the Exchange Domain Servers group has the required permissions in Active Directory. Make sure that the Allow inheritable permissions from parent to propagate this object check box is selected on the Security tab in the Administrators group, Exchange Domain Servers group, and any other groups that are relevant to your configuration.

    Note:
    If you must, force replication among the domain controllers to make sure that the changes are propagated throughout your domain.
    Note:
    The ADSI Edit tool is included in Microsoft Windows 2000 Support Tools and in Microsoft Windows Server 2003 Support Tools available on the Windows 2000 and Windows 2003 installation CD.
  • If the Exchange server is no longer a member of a routing group, or if its routing group was deleted from Active Directory, add the routing group or restore the routing group. Follow the resolutions here for the problem that best fits your scenario:

Resolution 1: Add the server to the routing group. Verify that the server is no longer a member of the routing group by following these steps:

  1. Start Exchange System Manager.

  2. Expand Organization, expand Administrative Groups, expand AdministrativeGroupName, and then expand Routing Groups.

    Note:
    In this step, AdministrativeGroupName is the name of the administrative group.
  3. Browse through all the available routing groups and verify that this server is not listed.

    Note:
    If no routing groups are visible, see Resolution 2.
  4. After you verify that this server is not a member of a routing group, add the server back to an existing routing group. To do this, follow these steps:

    Important:
    If you use the ADSI Edit snap-in, the LDAP utility, or any other LDAP version 3 clients, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require that you reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.
To add the server back to the routing group

  1. Click Start, click Run, type adsiedit.msc, and then click OK.

    Note:
    The ADSI Edit tool is included in Microsoft Windows 2000 Support Tools and in Microsoft Windows Server 2003 Support Tools. To install these support tools, follow these steps:
    • For Windows 2000 Server-based computers, double-click Setup.exe in the Support\Tools folder on the Windows 2000 CD, and then follow the steps in Windows Support Tools Setup Wizard to complete the installation of Windows 2000 Support Tools.

    • For Windows Server 2003-based computers, right-click Suptools.msi in the Support\Tools folder on the Windows Server 2003 CD, click Install, and then follow the steps in Windows Support Tools Setup Wizard to complete the installation of Windows Server 2003 Support Tools.

  2. Expand Configuration [ servername.domain_name.com ], expand CN=Configuration, DC= domain_name, DC= com, expand CN=Services, expand CN=Microsoft Exchange, expand CN= OrganizationName, expand CN=Administrative Groups, expand CN= AdministrativeGroupName, and then click CN=Routing Groups.

    Note:
    In this step, servername is the name of the server, domain_name.com is the name of the domain, OrganizationName is the name of the Exchange Server organization, and AdministrativeGroupName is the name of the administrative group.

  3. Right-click the routing group of which you want this server to be a member, and then click Properties.

  4. Click the distinguishedName attribute, and then click Edit

  5. Copy the value of the distinguishedName attribute into Notepad.

  6. Click Cancel two times to close the properties.

  7. In the ADSIEdit tool, expand Configuration [ servername.domain_name.com ], expand CN=Configuration,DC= domain_name ,DC= com, expand CN=Services, expand CN=Microsoft Exchange, expand CN= OrganizationName, expand CN=Administrative Groups, expand CN= AdministrativeGroupName, and then expand CN=Servers.

  8. Right-click servername, and then click Properties.

  9. Click the msExchHomeRoutingGroup attribute, and then click Edit.

  10. Paste the value that you copied to Notepad in step 5, and then click OK two times to save the new value.

  11. In Exchange System Manager, locate the routing group to which you added this server.

  12. Update Exchange System Manager to view this server.

    Note:
    If the Exchange server does not appear immediately, wait for Active Directory replication to occur.

  13. If no other Exchange servers in this routing group have the Server Type set to Master, right-click this Exchange server, and then click Set as Master.

  14. Start the Information Store service and the MTA Stacks service.

Resolution 2: Restore the routing group. If you accidentally remove a routing group, restore the routing group by using the most recent backup of the System State data. If you do not have a recent backup of the System State data, and if you have more than one domain controller, perform an authoritative restore operation of the routing group that you removed.

To restore the routing group

  1. Start Exchange System Manager, and then create a new routing group that has the same name as the routing group that you removed. To do this, follow these steps:

    1. Expand Administrative Groups, expand AdministrativeGroupName, and then expand Routing Groups.

      In this step, AdministrativeGroupName is the name of your administrative group.

    2. Right-click Routing Groups, point to New, and then click Routing Group.

    3. In the Name box, type the routing group name, and then click OK.

      Use the same name that was used for the routing group that you accidentally removed.

    4. Exit Exchange System Manager.

  2. Start ADSI Edit. To do this, click Start, click Run, type adsiedit.msc in the Open box, and then click OK.

    Note:
    The ADSI Edit tool is included in Microsoft Windows 2000 Support Tools and in Microsoft Windows Server 2003 Support Tools. To install these support tools:
    • For Windows 2000 Server-based computers, double-click Setup.exe in the Support\Tools folder on t/he Windows 2000 CD, and then follow the steps in Windows Support Tools Setup Wizard to complete the installation of Windows 2000 Support Tools.

    • For Windows Server 2003-based computers, right-click Suptools.msi in the Support\Tools folder on the Windows Server 2003 CD, click Install, and then follow the steps in Windows Support Tools Setup Wizard to complete the installation of Windows Server 2003 Support Tools.

  3. Expand Configuration [servername.domain_name.com], expand CN=Configuration, DC=domain_name, DC=com, expand CN=Services, expand CN=Microsoft Exchange, expand CN=OrganizationName, expand CN=Administrative Groups, expand CN=AdministrativeGroupName, and then click CN=Routing Groups.

    In this step, servername is the name of your server; domain_name.com is the name of your domain; OrganizationName is the name of your Exchange Server organization; and AdministrativeGroupName is the name of your administrative group.

  4. In the right pane, right-click the new routing group that you created, and then click Properties.

  5. Click to select the Show mandatory attributes check box and the Show optional attributes check box if they are not already selected.

  6. In the Attributes list, click msExchRoutingGroupMembersBL, and then click Edit.

    The Values list is blank.

  7. Click Cancel.

  8. In the Attributes list, double-click distinguishedName.

  9. Right-click the distinguished name in the Value box, and then click Copy.

  10. Start a text editor such as Notepad, and then click Paste on the Edit menu to paste the distinguished name.

  11. In the String Attribute Editor dialog box, click Cancel, and then click Cancel to close the CN=RoutingGroupName dialog box.

    In this step, RoutingGroupName is the name of your routing group.

  12. In ADSI Edit, under CN=AdministrativeGroupName, click CN=Servers.

  13. In the right pane, right-click CN=ServerName, and then click Properties.

    In this step, ServerName is one of the Exchange computers in this routing group.

  14. In the Attributes list, click msExchHomeRoutingGroup, and then click Edit.

  15. In the Value box, paste the distinguished name that you copied in steps 9 and 10, and then click OK.

  16. Click Apply, and then click OK.

  17. Repeat steps 13 through 15 for each server that was a member of the routing group that was removed by accident.

  18. Under CN=AdministrativeGroupName, click CN=Routing Groups.

  19. In the right pane, right-click the new routing group that you created, and then click Properties.

  20. In the Attributes list, click msExchRoutingGroupMembersBL, and then click Edit.

    The Values list is no longer blank.

  21. Click Cancel two times.

  22. Exit ADSI Edit.

  23. Set the routing group master by using Exchange System Manager. To do this, follow these steps:

    1. Start Exchange System Manager.

    2. Expand Administrative Groups, expand AdministrativeGroupName, and then expand Routing Groups.

    3. Expand the new routing group that you created, and then click Members.

    4. In the right pane, right-click the Exchange computer that you want to configure as the routing group master, and then click Set as Master.

    5. Exit Exchange System Manager.

  24. Wait for the changes to propagate throughout the domain.

  25. Start the Microsoft Exchange services that are stopped.


MSExchangeIS 5000 (0x8004010f): Cannot Mount Database Because of Incorrect Permissions or Invalid Characters in the Organization Name
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 5000 events with error code 0x8004010f in the Application log. The event indicates that a database or databases on the Exchange server cannot be mounted because of incorrect permissions or invalid characters in the Exchange organization name.

Explanation

The MSExchangeIS 5000 event with error code 0x8004010f can occur if any of the following is true:

  • The authenticated users do not have read access in the Domain or Configuration containers in Active Directory. When this condition is true, if you try to install a second Exchange server in an administrative group that already contains an Exchange server, you may be unable to install the second server. Additonally, the Microsoft Exchange Information Store service may not start.

  • Read access permission for the Everyone account is missing from the WellKnown Security Principals container underneath the Configuration container in Active Directory. When this condition is true, the Exchange Information Store service does not start on a member server.

  • The Exchange organization name contains unsupported characters. When this condition is true, after you install Exchange 2000 Server or Exchange Server 2003, the Exchange Information Store service may not start, and you may find that events MSExchangeIS 5000 and MSExchangeIS 1121 are logged in the Application log.

The event can also be identified as MAPI_E_NOT_FOUND. The event applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve the issue, do one or more of the following.

Important:
If you use the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require that you reinstall Microsoft Windows® 2000 Server, Microsoft Windows Server™ 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.
  • If authenticated users do not have read access in the Domain or Configuration containers in Active Directory, use the ADSI Edit Tool in Exchange Server 2003 and Exchange 2000 Server to grant authenticated users read access in the Domain container and in the Configuration container in Active Directory. Follow these steps:

    Note:
    The ADSI Edit Tool is located in the Microsoft Windows 2000 Support Tools and in the Microsoft Windows Server 2003 Support Tools. To install the Windows Support Tools, run Setup in the Support\Tools folder on the Windows CD. For more information about the Windows Support Tools, see the Sreadme.doc file in the Support\Tools folder on the Windows CD.
To grant authenticated users read access in the Domain or Configuration containers in Active Directory

  1. Click Start, click Run, type adsiedit.msc, and then click OK.

  2. Expand the Domain NC container, right-click the folder for the domain (DC=domain,DC=com), and then click Properties to open the folder properties.

  3. Click the Security tab, and then make sure that the Authenticated Users group has Read access selected in the Allow column. If Read is not selected, click to select Read, and then click OK.

  4. Expand the Configuration Container, right-click the folder for configuration (CN=Configuration,DC=domain,DC=com), and then click Properties to open the folder properties.

  5. Click the Security tab, and then make sure that the Authenticated Users group has Read access selected in the Allow column. If Read is not selected, click to select Read, and then click OK.

  6. Exit ADSI Edit.

  7. Allow time for the change to replicate among the domain controllers.

  8. Start the Information Store service.
  • If read access permission for the Everyone account is missing from the WellKnown Security Principals container underneath the Configuration container in Active Directory, follow these steps to resolve the problem:

To grant read access permission for the Everyone account in the WellKnown Security Principals container in Active Directory

  1. Log on as domain administrator, and then start ADSI Edit.

  2. Expand the Configuration container, and click the CN=WellKnown Security Principals container.

  3. Right-click Properties, and then locate the Security tab.

  4. Click Add, type everyone, and then click OK.

  5. Under the Allow column, click to select the Read check box.
  • If there are invalid characters in the Exchange organization name, remove the invalid character from the organization name. For more information about what characters are invalid, see Microsoft Knowledge Base article 329599, Exchange Information Store Does Not Start and Events 1121 and 5000 Are Logged.


MSExchangeIS 9518 (0xfffffddc): Exceeded the Maximum Number of Transaction Logs Available for this Storage Group
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-22

The Microsoft® Exchange Server Database Troubleshooter Tool detected one or more MSExchangeIS 9518 events with error code 0xfffffddc in the Application log. This indicates that the maximum number of transaction logs available for this storage group has been exceeded.

Explanation

An MSExchangeIS 9518 event with error code 0xfffffddc is logged when it is trying to mount the databases of a storage group, and both of the following are true:

  • The maximum number of transaction logs available to this storage group has been exceeded.

  • All databases in the this storage group are in a Clean Shutdown state

Additionally, an MSExchangeIS 1159 event with error code 0xfffffdf9 should have been logged in the Application log before the affected databases shutting down. This event identifies that the Exchange Server has used all the available transaction log files for this storage group. When the last transaction log is filled, all databases within this storage group will be dismounted and cannot be restarted.

Exchange uses transaction log files that are numbered sequentially. In Exchange 2000 Server and Exchange Server 2003, transaction log files start with Exx00001.log, and then increment sequentially to ExxFFFF0.log. The maximum number of transaction log files that can be generated in a single sequence is 1,048,560 (0xFFFF0). Typically, it will take several years of operation before this many log files will be generated.

In Exchange Server 2007, the transaction log files are larger. There can be at most 2,147,483,647 log files (0x7FFFFFFF in hexadecimal, because log file names are in hexadecimal) in a log stream. The transaction log files are 1 megabyte (MB) each. This error will most likely not occur in Exchange Server 2007.

User Action

To resolve the error, you must remove all transaction log files and reset the transaction log file sequence back to 1. After resetting the log file sequence, the log file name is Exx00001.log in Exchange Server 2003 or older versions, and Exx00000001.log in Exchange Server 2007.

Use the Reset log generation number task in the Database Recovery Management tool that is part of the Microsoft Exchange Troubleshooting Assistant to perform this operation. The tool will verify that all databases were shut down correctly and then will safely move all transaction log files to a backup location.

Note:
The transaction log files can also be removed manually, but manual removal may result in a database in the storage group may not shutting down correctly and that database not being mountable again. To prevent such failures we recommend that you use the Database Recovery Management tool.

For more information and to download the tool, see Microsoft Exchange Troubleshooting Assistant v1.0.


MSExchangeIS 9518 (0xfffff745): Unable to Create or Access TMP Files
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9518 events with error code 0xfffff745 in the Application log. This error occurs if Exchange cannot create or access files in the folders that are specified in the TMP or TEMP system environment variables.

Explanation

This issue can be caused if any of the following is true:

  • The path where the TMP or TEMP environment variable points is unavailable or is read-only. For example, this issue occurs if the TMP environment variable is mapped to a remote drive or to a storage area network (SAN), and that mapped drive or SAN is no longer available.

  • The TMP or TEMP environment variable has an incorrect registry setting.

  • Exchange does not have full control permissions from the root of the drive down to the transaction logs and databases.

User Action

To resolve this issue, you can perform one or more of the following:

Note Because there are several versions of Microsoft Windows, the following steps may be different on your computer. If they are, see the product documentation to complete these steps.

  • Verify that both the TMP environment variable and the TEMP environment variable point to a valid location in Windows. To do this, follow these steps:

    To set a valid path for the Temp and TMP variables

    1. Click Start, point to Settings, and then click Control Panel.

    2. Double-click System, click the Advanced tab, and then click Environment Variables.

    3. Under System variables, click TEMP, and then click Edit.

    4. If a valid path does not appear in the Variable Value box, type a valid path for the TEMP variable, and then click OK. For example, type %systemroot%\Temp, and then click OK.

    5. Under System variables, click TMP, and then click Edit.

    6. If a valid path does not appear in the Variable Value box, type a valid path for the TMP variable, and then click OK. For example, type %systemroot%\Temp, and then click OK.

    7. Click OK two times to close the System Properties dialog box.

    8. Restart the computer.
  • Verify and assign the local Administrators group or the SYSTEM account Full Control permissions to the Temp folder. It is insufficient to assign Full Control permissions to the Domain Admins group. By default, the following path is specified for both the TMP and the TEMP system environment variables:

    %SYSTEMROOT%\Temp

    Exchange must access this folder location by using the SYSTEM account. To view these permissions follow these steps:

    To verify permissions to the Temp folder

    1. Right-click Start, and then click Explore.

    2. Right-click the Temp folder that is specified in the system environment variable, then click Properties. Typically, this is %systemroot%\Temp.

    3. Click the Security tab.

    4. In the Name list, click SYSTEM, and then view the assigned permissions that appear in the Permissions list.
    If permissions to the Temp folder are correct, verify the permissions on each drive that contains the Exchange database files or the Exchange log files. The SYSTEM account must have Full Control permissions at the root of the drive and at each folder that contains Exchange database files or the Exchange transaction log files. For example, if you have transaction logs in the C:\Exchsrvr\Mdbdata folder, the SYSTEM account must have Full Control permissions to the root directory of drive C, the Exchsrvr folder, and the Mdbdata folder.

  • Check whether the problem is because of incorrect registry settings. Follow these steps:

    To verify registry settings

    1. Click Start, click Run, type Regedt32.exe, and then click OK.

    2. Locate the following registry key:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

    3. Locate the TMP (or TEMP) name. This key should be of the REG_EXPAND_SZ type.

    4. If either of the keys is incorrect, back up the Environment subkey and then delete the TMP or TEMP value on the right.

    5. Click Start, click Run, type Sysdm.cpl, and then click OK.

    6. On the Advanced tab, click Environment Variables.

    7. In the System variables list, verify that the value(s) you deleted in step 4 is not present in the list.

      Note:
      You may have to scroll down to see the TEMP or TMP variables.

    8. Click New. In the Variable Name box, type the names that you deleted in step 4. For example, type C:\Winnt\TEMP.

    9. Click OK three times, and then restart the computer.


MSExchangeIS 9518 0xfffffbc4: Log File Path Already in Use
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-05-14

The Microsoft Exchange Database Troubleshooter tool detected one or more MSExchangeIS 9518 events with error code 0xfffffbc4 in the Application log. This error code indicates that one or more Storage Groups are configured to use the same Log files path or System files path.

Explanation

This error can occur if multiple Storage Groups have been configured to use the same Log files path or System files path. Exchange requires that each Storage Group have a unique path for log and system files.

User Action

To resolve this issue, make sure that each Storage Group is configured with a unique Log files path and System files path.

Note:
A discrete Storage Group can share the same Log files path and System files path. But that same path cannot be used as a Log files path or System files path for another Storage Group.
To verify or set the Log files path and System files path on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, right-click your storage group, and then click Properties.

  3. On the General tab, under Transaction log location, click Browse.

  4. Verify that the Log files path and System files path are unique to the Storage Group.

  5. If the Storage Group Log files path and System files path are not unique to the Storage Group, enter the path of the new location for the log files and or system files, and then click OK.

  6. Click OK.
To verify or set the Log files path and System files path for a Storage Group for Exchange Server 2007

  1. Open the Exchange Management Console.

  2. Expand Server Configuration, and highlight Mailbox.

  3. In the Mailbox pane, select the server you want to work with.

  4. In the Database Management pane, right-click the Storage Group you want to work with and select Properties.

  5. Verify that the Log files path and System files path are unique to the Storage Group.

  6. If the Storage Group Log files path and System files path are not unique to the Storage Group, follow the guidance in the Exchange Server 2007 documentation, "How to Set or Change the Location of Storage Group Log Files" (http://go.microsoft.com/fwlink/?LinkId=80702) to set the file paths to a unique location for each Storage Group.

For more information about how to move log files on Exchange Server 2003, see Microsoft Knowledge Base article 821915, "How to Move Exchange Databases and Logs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821915).

For more information about how to move log files on Exchange 2000 Server, see Microsoft Knowledge Base article 239944, "XADM: How to Move the Transaction or System Logs to Another Location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239944).


MSExchangeIS 9518 (0xfffffd9a): Missing Checkpoint File, and More Than 1,008 Transaction Log Files Exist
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9518 events with error code 0xfffffd9a in the Application log. This error indicates that the checkpoint file (Exx.chk) for this storage group is missing or deleted, and there are more than 1,008 transaction log files to be played into the database.

Explanation

This issue may occur if the following conditions are true:

  • The log files and databases are shut down correctly. Therefore there is no crash to recover from.

  • You rename or delete the Exx.chk checkpoint file.

  • There are more than 1,008 log files between checkpoints to replay on the server.

  • In a "roll-forward" recovery, one or more databases in the storage group are lost, but the log files remain intact on the server at the time of recovery. The "roll-forward" recovery operation is not completed successfully.

In this situation, the Microsoft Exchange Information Store service performs a soft recovery and replays all log files during startup. Because the log files and the database were shut down correctly, there is no recovery to perform. Because there is no checkpoint, Exchange processes all the logs until it reaches a record of a clean shutdown. Because there are more than 1,008 log files, Exchange reaches the limit of 1,008 log files before it can locate the record of a Clean Shutdown state.

Note:
The symptoms described may also occur if the conditions listed earlier are true, and you replay the log files by using the eseutil /r command. The eseutil /r command also performs a soft recovery on the mailbox store.

The error can also be identified as error JET_errCheckpointDepthTooDeep, -614. This error applies to Microsoft Exchange Server 2003 only.

User Action

To resolve this issue in Exchange Server 2003, apply the hotfix prescribed in Microsoft Knowledge Base article 836611, Information Store databases do not mount and you receive an "Operation terminated with error -614" error message when you start a computer that is running Exchange Server 2003.


MSExchangeIS 9518 0xfffffb40: Missing Database File
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-05-23

The Microsoft Exchange Database Troubleshooter tool detected one or more MSExchangeIS 9518 events with error code 0xfffffb40 in the Application log. This indicates that one or more database files for the Storage Group are missing.

Explanation

This error can occur when the Extensible Storage Engine (ESE) attempts to bring all databases in a storage group to a consistent state during recovery, but finds that database files are missing or have been replaced with different versions.

If any database file from the Storage Group is missing, or has been replaced with different versions, ESE returns the error -1216, aborts the recovery, and does not start the storage group.

User Action

To resolve this issue, do one or more of the following:

  • Method one: If the missing database file has been moved or renamed, locate any ESE 494 events in the application log that occurred after the attempt was made to mount the database. For each event, note the specific database file that is reported missing, find the file's current location and move it to the proper location.

Note:
If file-level antivirus software is installed on this server, and exclusions have not been configured correctly, it is possible that the database could have been deleted or quarantined by the antivirus software. Make sure to check the antivirus quarantine and deletion log to see if this has occurred.
  • Method two:

    • Method two A: If the missing database file has been deleted or lost, restore the file from a backup to the production storage group. You can use the Exchange Database Recovery Management tool's Verify database and transaction log files task to verify the restored database file is available to perform a restore.

      While you are restoring this database file, you can also mount and access the other unaffected databases in the storage group by completing the following steps:

To allow user mailbox access to unaffected databases

  1. Run eseutil /R /L <Path to Log Files> /S <Path to System Files> Log Base Name /I (where Log Base Name is the first three characters of the log files for this storage group, i.e. E00, E01, etc.). This allows ESE to take the database files present to a consistent state while ignoring the missing database files. After running this command, any missing database files will need to be restored from backup.
Note:
The /L and /S switches are optional, and do not need to be used if eseutil is being run from the same location as the log files and system files.
  1. Mount the database files in the storage group that are now present and consistent.

  2. Users with mailboxes hosted by the currently mounted database may now access their mail.
  • Method two B: Restore the database file from backup to a Recovery Storage Group. You can provide send/receive functionality immediately by starting up with a new database as soon as possible (known as dial tone recovery). Clients see an empty mailbox, but they have send and receive capability more quickly than if they had to wait for restoration or repair to complete.

Note:
The dial tone option will require the eventual merging of any new (post dial tone) data with the restored data.

For more information about the dial tone recovery, see "Dial Tone Portability" () in the Disaster Recovery topic of the Exchange 2007 product documentation.

For more information about the Recovery Storage Groups, see "Understanding Recovery Storage Groups" () in the Disaster Recovery topic of the Exchange 2007 product documentation.
  • Method three: If a hard repair was run, either manually or from the Repair Database task of the Exchange Troubleshooting Assistant, against one or more databases in the Storage Group, and the database(s) are in a consistent state, it may be that the log files for the Storage Group were not removed. If all databases for the Storage Group are in their correct location, verify that all databases are in a consistent state by running the following command.

To manually verify database file consistency state:

  1. Run eseutil /mh <path to database .edb file>

  2. In the output of this command, look for the State: field and verify that its value is Clean Shutdown.

  3. If all databases for the Storage Group are in a Clean Shutdown state, move all the transaction logs and system logs for the Storage Group to a backup location, and then attempt to mount the store. If you are able to mount all databases correctly, we recommend making a backup of the Storage Group immediately.

For More Information

For more information about MSExchangeIS 9518 event with error code 0xfffffb40, see the "Events and Errors Message Center" (http://go.microsoft.com/fwlink/?LinkId=91705).

For more information about recovering from this error, see Microsoft Knowledge Base article 296843, "How to recover an Exchange 2000 Server database after error -1216" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=296843).

For more information about Exchange Disaster Recovery Planning, see "A Guide to Exchange Disaster Recovery Planning" (http://go.microsoft.com/fwlink/?LinkId=91706).

For more information about database recovery management and database troubleshooter wizards, see "Database Recovery Management and Database Troubleshooter Tool" (http://go.microsoft.com/fwlink/?LinkId=91707).

For more information about the dial tone recovery, see "Dial Tone Portability" (http://go.microsoft.com/fwlink/?LinkId=91703) in the Disaster Recovery topic of the Exchange 2007 product documentation.

For more information about the Recovery Storage Groups, see "Understanding Recovery Storage Groups" (http://go.microsoft.com/fwlink/?LinkID=80784) in the Disaster Recovery topic of the Exchange 2007 product documentation.


MSExchangeIS 9518 (0xfffffea8): Mismatched Database Time Stamp in the Database File
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9518 events with error code 0xfffffea8 in the Application log. This error occurs if the dbtime on the current page of the affected database is greater than the global database dbtime of the database.

Explanation

When this error occurs, the affected mailbox or public folder databases will not mount. The error is also identified as JET_errDbTimeCorrupted.

The error applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve the database time stamp mismatch, run the eseutil /d command to defragment the database that is experiencing this issue, and then mount the database. For more information about how to run eseutil /d, see How to Run Eseutil /D ( Defragmentation ). In addition, see Microsoft Knowledge Base article 328804, How to defragment Exchange databases.


MSExchangeIS 9518 (0xfffff764): Missing or Inaccessible Streaming File
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9518 events with error code 0xfffff764 in the Application log. This error can occur if Exchange is unable to access the streaming file (.stm) that is associated with a database.

Explanation

This error can occur if the streaming file (.stm) that is associated with a database has been deleted, moved, or if Exchange cannot access the streaming file because of a permissions change.

Note:
Under certain circumstances, antivirus programs can delete or change the permissions on Exchange files, including the .stm file, if you have not excluded the Exchange directories from scanning per Microsoft Exchange best practices. For more information about this topic, see Microsoft Knowledge Base article 823166, Overview of Exchange Server 2003 and antivirus software.

This error can also be identified as -2204. This error applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve this issue, do one or more of the following:

  • Restore the streaming file from a backup copy of the database.

  • Check whether your antivirus software has moved the streaming file to the Quarantine folder. If the file is in the Quarantine folder, move it to the original location, and then configure the antivirus program so that it does not scan the Exchange Server 2003 folders.

    Note:
    Some antivirus programs change the file properties to Read-only when the files are moved to the Quarantine folder. If you find the streaming file in the Quarantine folder, right-click the file, and then click Properties. Click to clear the Read-only check box before you try to mount the database.
  • You can run the Microsoft Exchange Database Recovery Management Tool that is part of the Microsoft Exchange Troubleshooting Assistant. The Database Recovery Management Tool can analyze the database and transaction log files for this storage group and give you additional details about the issue. For more information and to download the tool, see Microsoft Exchange Troubleshooting Assistant v1.0.


MSExchangeIS 9518 (0xfffffbf8): Missing Required Permissions on Exchange Database Folder or Drive
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-03-15

The Microsoft Exchange Database Troubleshooter tool detected one or more MSExchangeIS 9518 events with error code 0xfffffbf8 in the Application log. This indicates that the folder or drive that contains the Exchange database(s) does not have the appropriate permissions assigned to them.

Explanation

This error indicates that the folder or drive that hosts the Exchange database files does not have the permissions assigned that are required to perform minimum functions. You may experience difficulties in accessing or mounting the mailbox stores or public folder stores.

User Action

To resolve the issue, grant the default permissions to the folder that contains the Exchange databases and to the drive on which this folder resides.

To grant the default permissions to the folder that contains the Exchange databases in Exchange 2007

  1. Start Windows Explorer, and then navigate to the folder that contains the Exchange databases. By default this is C:\Program Files\Microsoft\Exchange\Mailbox\Storage Group Name\

  2. Right-click that folder and then click Properties.

  3. Click the Security tab, and then grant the following default permissions

Account | Permissions
Administrators | Full Control
System | Full Control
 To grant the default permissions to the drive that contains the Exchange databases in Exchange 2007

  1. Start Windows Explorer.

  2. Right-click the Local Disk object that contains the Exchange database folder, and then click Properties.

  3. Select the Security tab, and then grant the following default permissions, depending on the operating system installed:

For Windows 2000 Server:

Account | Permissions
Everyone | Full Control

For Windows Server 2003:

Account | Permissions
Administrators | Full Control
Creator Owner | None
Everyone | None
System | Full Control
Users | Read and Execute, List Folder Contents, Read
 To grant the default permissions to the Mdbdata folder Exchange 2000 Server and Exchange Server 2003

  1. Start Windows Explorer, and then navigate to and expand the Exchsvr folder.

  2. Right-click the Mdbdata folder, and then click Properties

  3. Click the Security tab, and then grant the following default permissions:

Account | Permissions
Administrators | Full Control
Authenticated Users | Read and Execute, List Folder Contents, Read
Creator Owner | None
Server Operators | Modify, Read and Execute, List Folder Contents, Read, Write
System | Full Control
 To grant the default permissions to the drive that contains the Mdbdata folder in Exchange 2000 Server and Exchange Server 2003

  1. Start Windows Explorer.

  2. Right-click the Local Disk object that contains the Mdbdata folder, and then click Properties.

  3. Select the Security tab, and then grant the following default permissions, depending on the operating system installed:

For Windows 2000 Server:

Account | Permissions
Everyone | Full Control

For Windows Server 2003:

Account | Permissions
Administrators | Full Control
Creator Owner | None
Everyone | None
System | Full Control
Users | Read and Execute, List Folder Contents, Read

For More Information

For more information about this issue, see Microsoft Knowledge Base article 823022, "Event ID 490 is logged, and you receive the following error message when you try to mount the mailbox store or the public store in Exchange Server: "ID No: c1041724"" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823022).


MSExchangeIS 9518 (0xfffff743): Too Many Temp Files
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-03-14

The Microsoft Exchange Database Troubleshooter tool detected one or more MSExchangeIS 9518 events with error code 0xfffff743 in the Application log. This indicates that the temporary file namespace for a server has becomes exhausted, or there is no space available to write to the temp folder.

Explanation

Exchange 2000 Server and Exchange Server 2003 create temporary files in the Temp folder when a large object, such as a message or a file, is streamed into the store and the .stm file is too fragmented to have the entire object written in it.

During normal operation, when the Exchange services are stopped, these files are removed from the Temp folder. If the Exchange server shuts down unexpectedly or the Exchange services terminate unexpectedly, these files are not removed. When the Exchange services are later restarted, new temporary files are created. This results in decreased performance. When the 64,000 temporary file namespace is exhausted, the Exchange services fail to start and the 9518 events with error code 0xfffff743 are logged in the Event Viewer Application log.

User Action

To resolve the issue, do the following:

  • Check the Windows Temp folder for the existence of lb*.tmp files. If these files exist, follow the steps in the following procedure to remove them.

  • Check the drive that hosts the Temp folder for free disk space. If the disk is out of free space, use the following procedure to move the Temp and Tmp folders to a different drive.

To remove the lb*.tmp files from the Windows Temp folder

  1. Click Start, select Programs, select Administrative Tools, and then click Services.

  2. Scroll down to the Microsoft Exchange Information Store.

  3. If the status of the service is Started, right-click the service, and then click Stop
Note:
This will disconnect all users from their mailboxes.
  1. Navigate to the %windir%\temp folder, where %windir% is your Windows system root folder, by default this is C:\Windows\Temp.

  2. Delete all lb*.tmp files.

  3. In the Services management console, right-click the Microsoft Exchange Information Store service, and then click Start.

 To move the Temp and Tmp folders to a different drive

  1. On the Exchange Server computer, click Start, click Control Panel, and then double-click System.

  2. Click the Advanced tab, and then click Environmental Variables.

  3. Under System Variables, click the line that includes the TEMP variable and the drive, click Edit, and then type the new drive location.

  4. Under System Variables, click the line that includes the TMP variable and the drive, click Edit, and then type the new drive location
Note:
Make sure this change is applied to the System Variables and not the User Variables.
Note:
If the procedures outlined here do not resolve this issue, consider the information in Microsoft Knowledge Base article 307242, "Information store does not mount with 0xfffff745 and -2235 errors" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307242).

For More Information

For more information about this issue, see the following Microsoft Knowledge Base articles:

  • 294462, "Exchange lb*.tmp files in the Windows Temp folder cause ESE -2237 error" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=294462)

  • 307242, "Information store does not mount with 0xfffff745 and -2235 errors" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307242)


MSExchangeIS 9519 (0xfffffb3a): Detected Multiple Databases With Same Signature In Use
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9519 events with error code 0xfffffb3a in the Application log. This error indicates that another copy of the same database is already running.

Explanation

Each Exchange database has its own unique signature. If the Microsoft Exchange Information Store service detects multiple databases with the same signature, it will prevent the duplicate database from mounting.

The event can also be identified as error -1222, JET_errDatabaseSignInUse.

User Action

You can verify that two copies of the same database are present within a single storage group by following these steps:

  1. Dismount all other databases in the storage group, and try to mount the database that caused this error message.

  2. If the database is able to mount, you must then try to mount all the other databases in the storage group.

  3. If a different database in the storage group now gives the same error in the Application log, then two databases have the same signature; therefore, they are copies of the same database.

To resolve this issue, make sure that only one copy of the database is present within this particular storage group.


MSExchangeIS 9519 (0xfffffe07): Unable to Mount Database Due to Running Backup Process
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-02-27

The Microsoft Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9519 events with error code 0xfffffe07 in the Application log. This error indicates that the database specified could not be mounted because of a running backup process.

Explanation

This error can occur if the storage group that this database belongs to has multiple databases (either mailbox databases or public folder databases), and if one of those databases is being backed up at the time that you tried to mount this database. This behavior is by design. You cannot mount a database in a storage group while you are backing up another database in that same storage group.

The error could also be identified as error -505, JET_errBackupInProgress.

User Action

Make sure that no other databases in the storage group are being backed up, and then try to mount the database. Alternatively, wait for the backup of the other database in the storage group to finish before you try to mount this database.


MSExchangeIS 9519 (0x3f3): Unchecked "This database can be overwritten by a restore" Check Box After Restore
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9519 events with error code 0x3f3 in the Application log. This error indicates that a restore was performed on a database without the "This database can be overwritten by a restore" check box being selected.

Explanation

This event occurs when a database restore operation has taken place, and Exchange detects that the "This database can be overwritten by a restore" checkbox on the properties of the store has not been checked.

User Action

To resolve this issue, ensure that the database can be overwritten by a restore by performing the following actions.

To enable the option on Exchange Server 2003 and Exchange 2000 Server

  1. Start the Exchange System Manager.

  2. Expand Administrative Groups (if applicable)

  3. Expand Servers, expand <Server Name>, expand <Storage Group>, and then click the database that was restored.

  4. Right-click the database, and then click Properties.

  5. Click the Database tab.

  6. Click to select the This database can be overwritten by a restore check box.

  7. Click OK.

  8. To mount the database, right-click the database, and then click Mount Store.
To enable the option on Exchange Server 2007

  1. Start the Exchange Management Console

  2. Under Server Configuration, select Mailbox

  3. In the Database Management pane, right-click the database that was restored.

  4. Click Properties

  5. Select the General tab

  6. Click to select the This database can be overwritten by a restore check box.

  7. Click OK.

  8. To mount the database, right-click the database, and then click Mount Database.


MSExchangeIS 9518 (0xfffffc01): Incorrect Database or Transaction Log Drive or Directory
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9518 events with error code 0xfffffc01 in the Application log. This indicates that an incorrect drive letter or path has been set for the Exchange database or log files.

Explanation

This error indicates that the database or log file path in the affected storage group points to an invalid drive letter or that the file path is incorrect. When this error occurs, all databases in the affected storage group will be unable to mount.

This problem may also occur if antivirus software is blocking write access to the drives that contain the Exchange database or transaction log files.

The event can also be identified as error -1023, JET_errInvalidPath.

User Action

To resolve the issue, do one or more of the following:

  • To determine whether your antivirus software is causing this problem, temporarily disable the antivirus software in the Services console. Then, try to mount the affected databases. If the databases mount successfully, contact the antivirus vendor for the latest build of the software.

  • Verify and set the correct system, database, and transaction log file paths for each storage group and database affected by this error. Follow these steps.

To verify and set correct file paths in Exchange Server 2003 or Exchange 2000 Server

  1. Start Exchange System Manager. Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.

  2. If administrative groups are displayed in Exchange System Manager, expand Administrative Groups, and then expand the administrative group in which you experience the problem.

  3. Expand Servers, and then expand the server on which you experience the problem.

  4. Right-click the storage group that contains the store that you cannot mount, and then click Properties.

  5. On the General tab, examine the path that appears in the Transaction log location box. Examine the path in the System path location box.

    If these paths are incorrect, contact Microsoft Product Support Services for help in resolving this issue.

  6. Follow steps 3 through 5 for each storage group that may be present to verify the database path and the transaction log file path.

  7. After you verify the system path and the transaction log file path for each storage group, verify the database paths for each store in each storage group. To do this, follow these steps:

    1. Expand a storage group. For example, expand First Storage Group.

    2. Right-click StoreName (ServerName), and then click Properties.

    3. Click the Database tab, and then verify the path that appears in the Exchange database box. Then, verify the path that appears in the Exchange streaming database box.

      If a particular path is incorrect, contact Microsoft Product Support Services for help in resolving this issue.

    4. Repeat steps 7b and 7c to verify the paths for each mailbox store or public folder store that is present in each storage group.

  8. Mount the mailbox store or the public folder store.

To verify and set correct file paths in Exchange Server 2007

  1. Start Exchange Management Console. Click Start, point to Programs, point to Microsoft Exchange, and then click Exchange Management Console.

  2. Expand Server Configuration, select Mailbox

  3. In the Database Management pane, select the storage group that contains the databases that you cannot mount.

  4. Right-click the storage group, and then click Properties.

  5. On the General tab, examine the path listed in the Log path and System path locations.

    If these paths are incorrect, right-click the storage group and select Move Storage Group Path. Under Log files path and System files path click Browse to locate the folder that contains the transaction log files or the database files. By default, the transaction log files and the database files are located in the following folder:

    %PROGRAMFILES%\Microsoft\Exchange Server\Mailbox\<storage group name>

  6. Click OK.

  7. Follow steps 3 through 5 for each storage group that may be present to verify the system path and the transaction log file path.

  8. After you verify the system path and the transaction log file path for each storage group, verify the database paths for each database in each storage group. To do this, follow these steps:

    1. Expand a storage group. For example, expand First Storage Group.

    2. Verify the path that appears under Database File Path in the Database Management pane.

    3. If a particular path is incorrect, right-click the database, and then click Move Database Path.

    4. Click Browse to locate the correct folder for the database file. By default, the Exchange database file (.edb) is located in the following folder:

      %PROGRAMFILES%\Microsoft\Exchange Server\Mailbox\<storage group name>\<database name.edb>

    5. Click OK.

    6. Follow steps 8b through 8e to verify the paths for each mailbox or public folder database that is present in each storage group.

  9. Mount the mailbox database or the public folder database.


MSExchangeIS 9519 (0xfffffbda): Missing Double Byte Character Set Locale Configured as the Default System Locale
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9519 events with error code 0xfffffbda in the Application log. The event indicates that a non-English default system locale was installed. After Exchange Server was installed, the default system locale was uninstalled.

Explanation

If the event MSExchangeIS 9519 with error code 0xfffffbda triggers on restarting the Exchange server, the Exchange databases will not mount. In addition, error events ESE 604 and MSExchangeIS 9519 are logged in the Application event log.

This behavior may occur if you previously had a non-English locale set as the default system locale. If you chose another locale as the default system locale, removed the non-English locale, and then restarted the Exchange 2000 Server or Exchange Server 2003, you experienced this event.

The event can also be identified as -1062, JET_errInvalidLanguageId. The event applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve the issue, reinstall the non-English locale or create new databases. If you reinstall the non-English locale, it does not have to be set as the default system locale.


MSExchangeIS 9519 (0xfffff05b): Database or Logs Compressed on a Server Running Exchange Server 2000 SP3 or Higher
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-02-19

The Microsoft Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9519 events with error code 0xfffff05b in the Application log. This error indicates that the Exchange database or transaction log files are located on a drive that has file system compression enabled.

Explanation

This event may occur when you apply Exchange 2000 Server Service Pack 3 (SP3) to an Exchange 2000 Server that contains an information store database that is compressed by using NTFS file system compression. This issue may also occur when you upgrade an Exchange 2000 Server computer to Exchange Server 2003. Exchange 2000 Server SP3, Exchange Server 2003, and Exchange Server 2007 prevent compressed information store databases from mounting.

This error can also be identified as -4005, JET_errFileCompressed. This error applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server SP3

User Action

To resolve this issue, you must decompress the folders where the information store databases and logs reside, defragment the databases, and then perform an online Exchange-aware backup of the Information Store storage groups where the databases and logs reside. To do this, see Microsoft Knowledge Base article 327772, Database does not mount, and you receive error 0xfffff05b after you apply SP3 to Exchange 2000.


MSExchangeIS 9519 (0xfffffa84): Missing or Corrupted Database Indexes
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-01-22

The Microsoft® Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9519 events with error code 0xfffffa84 in the Application log. This event indicates that the indexes for this database are either corrupted or missing.

Explanation

The following reasons could result in a corrupted or missing database index:

  • This can occur during index cleanup of an Exchange database after you apply a new Microsoft Windows service pack. After you apply the service pack, you cannot mount the mailbox or the public folder databases in the Exchange server. Additionally, events ESE 609 and ESE 611 are logged in the Application event log.

  • This can occur after you run a database repair operation (eseutil /p). This can remove an index that is generated when the database is first created. Running the Eseutil repair command removes the index.

This error can also be identified as -1404, JET_errIndexNotFound. This error applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

User Action

To resolve this issue, follow the resolution that matches the problem scenario described earlier:

  • If an index is corrupted during index cleanup of an Exchange database after you apply a new Windows service pack, follow these steps:

    1. Restore the affected mailbox or public folder database from a known good backup.

    2. Perform an offline defragmentation of the affected database by running eseutil /d. For information about how to defragment the affected database offline, see the following topics:

      Exchange 2000 Server and Exchange Server 2003 databases: How to Run Eseutil /D (Defragmentation)

      Exchange Server 2007 databases: How to Run Eseutil /D (Defragmentation)

  • If an index is missing after you run a database repair (eseutil /p) operation, apply the hotfix prescribed in Microsoft Knowledge Base article 924627, Event ID 9519 that includes error 0xfffffa84 is logged when you try to mount a database after you use the Eseutil and Isinteg utilities to recover the database in Exchange 2003.


MSExchangeIS 9519 0x972: Public Folders Container Deleted, or Missing Required Attributes
Microsoft Exchange Server Analyzer - Articles > Database Recovery >

Topic Last Modified: 2007-08-30

The Microsoft Exchange Database Troubleshooter tool detected one or more MSExchangeIS 9519 events with error code 0x972 in the Application log. This indicates a failure of Public Folder databases to mount because the Public Folders container has been deleted or is missing needed attributes.

Explanation

This error can occur when the Public Folders container has been deleted from Active Directory, or if the affected Public Store is not configured to use the Public Folders container, i.e., the value for the Public Folder Containers msExchOwningPFTreeBL attribute does not point to the Public Store. The most likely cause for this error is that the Administrative Group that contained the public folders container was deleted without the public folders container first being moved to a new Administrative Group.

User Action

To resolve this issue, use the ADSI Edit, or a similar tool, to determine whether the public folders container exists and the msExchOwningPFTreeBL attribute is properly configured to point to the relevant Public Store.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.
To determine the cause of the error

  1. Using ADSI Edit or a similar tool, locate each administrative group object in Active Directory.

    The Administrative Group object can be found at:

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group

  2. Expand each Administrative Group and check for the existence of a CN=Folder Hierarchies container. If the CN=Folder Hierarchies container exists, highlight the container and verify that a CN=Public Folders object exists in the right-hand pane. If no CN=Public Folders object exists under any Administrative Group, move on to Solution 1, Recreate Folder Hierarchies and Public Folders containers. If you do find a CN=Public Folders container, proceed to step 3.

  3. Right-click the CN=Public Folders object, and then click Properties.

  4. In the Attributes list, select the msExchOwningPFTreeBL attribute, and then click Edit.

  5. Make sure that the affected Public Folder Store is shown in the Values list. If it is not listed, proceed to Solution 2.
Solution 1: Recreate Folder Hierarchies and Public Folders containers

  1. Using ADSI Edit or a similar tool, locate and expand Exchange Administrative Group (FYDIBOHF23SPDLT).

    The Exchange Administrative Group (FYDIBOHF23SPDLT) object can be found at:

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups

  2. Right-click the Exchange Administrative Group (FYDIBOHF23SPDLT) object, and then click New, and then Object.

  3. From the Select a class list, select msExchPublicFolderTreeContainer and then click Next.

  4. For the Value box, type Folder Hierarchies, and then click Next, and then Finish.

  5. Right-click the newly created Folder Hierarchies object and then click New, and then Object.

  6. From the Select a class list, select msExchPFTree and then click Next.

  7. For the Value box, type Public Folders, and then click Next.

  8. Click More Attributes.

  9. From the Select a property to view dropdown, select msExchPFTree.

  10. For the Edit Attribute box, type 1, and then click Set, click OK, and then click Finish.

  11. To assign the Public Folders container to each Public Store, right-click the Public Folders container and select Properties.

  12. From the Attributes list, select distinguishedName, and then click Edit.

  13. Copy the contents of the Value box to the clipboard, and then click Cancel.

  14. For each server exhibiting the MSExchangeIS 9519 event with error code 0x972, navigate to the Public Folder Store object. The default location for this object is:

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups, CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Servers, CN= ServerName , CN= InformationStore , CN=Second Storage Group.

  15. Right-click the Public Folder Store object, and then click Properties.

  16. From the Attributes list, select msExchOwningPFTree, and then click Edit.

  17. Paste the value copied into the clipboard in step 13 into the Value box and then click OK twice to finish.

  18. Repeat steps 15 through 17 for each server exhibiting the MSExchangeIS 9519 event with error code 0x972.

  19. Restart the Microsoft Exchange Information Store service on the affected servers.

Solution 2: Repopulating the value of the msExchOwningPFTreeBL attribute for the Public Folders container object

  1. Using ADSI Edit or a similar tool, locate the Public Folders object in Active Directory.

    The Public Folders object can be found at:

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group,CN=Folder Hierarchies,CN=Public Folders

  2. Right-click the Public Folders container and select Properties.

  3. From the Attributes list, select distinguishedName, and then click Edit.

  4. Copy the contents of the Value box to the clipboard, and then click Cancel.

  5. For each server exhibiting the MSExchangeIS 9519 event with error code 0x972, navigate to the Public Folder Store object. The default location for this object is:

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups, CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Servers, CN= ServerName , CN= InformationStore , CN=Second Storage Group.

  6. Right-click the Public Folder Store object, and then click Properties.

  7. From the Attributes list, select msExchOwningPFTree, and then click Edit.

  8. Paste the value copied into the clipboard in step 4 into the Value box and then click OK twice to finish.

  9. Repeat steps 6 through 8 for each server exhibiting the MSExchangeIS 9519 event with error code 0x972.

  10. Restart the Microsoft Exchange Information Store service on the affected servers.


Exchange Cluster
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2005-11-18

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating with regard to Exchange clusters. Additionally, these articles describe actions that you can take to resolve Exchange cluster-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


Cluster debugging is enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether cluster debugging is enabled on the server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Cluster\Debug

If the Exchange Server Analyzer finds that the Debug value equals 1, the Exchange Server Analyzer displays a warning.

Cluster debugging with this registry value prevents cluster resources from failing over between nodes. You should use this registry value only when debugging a problem that requires preventing resources from failing over.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To disable the cluster debugging registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to HKLM\Software\Microsoft\Exchange\Cluster.

  3. Change the Debug value to 0.

  4. Exit the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about Exchange clusters, see the topic, "Managing Exchange Clusters in Exchange Server 2003" in the Exchange 2003 Server Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


Cluster dedicated heartbeat network priority set incorrectly
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the priority ordering of each network interface resource in the Exchange server cluster:

HKEY_LOCAL_MACHINE\Cluster\Networks\<NetworkInterfaceGUID>\Priority

The value of Priority indicates the network priority configured for the network interface resource. The network interface resource with the highest priority has a value of 1, the next highest has a value of 2, and so forth.

The Exchange Server Analyzer also reads the following registry entry to determine the defined role for each network in the Exchange server cluster:

HKLM\Cluster\Networks\<NetworkInterfaceGUID>\Role

A value of 1 indicates the network resource has been configured as a dedicated private (heartbeat) network. A value of 2 indicates the network resource has been configured as a dedicated public network (client access). A value of 3 indicates the network resource has been configured as a mixed network that allows both heartbeat traffic and client access traffic.

If the Exchange Server Analyzer determines that a network interface resource with a Role value of 1 has a Priority value that is greater than 1, a warning is displayed. This warning indicates that a dedicated heartbeat network was found, but its network priority is not set correctly.

Configuring a dedicated private network to use for the cluster heartbeat is a recommended best practice for all Exchange Server clusters. Communication between nodes is critical for smooth cluster operations. Use the following instructions to correctly configure the network priority for the dedicated heartbeat network.

To correct this warning

  1. Open Cluster Administrator and connect to the Exchange server cluster.

  2. In the left pane, right-click the Cluster object at the top of the hierarchy, and then click Properties.

  3. Click Network Priority.

  4. Select the dedicated heartbeat network resource.

  5. Click Move Up until the dedicated heartbeat network resource is at the top of the listed network resources.

  6. Click OK.

For more information about cluster heartbeat networks, see the following Microsoft Knowledge Base articles:

  • 258750, "Recommended Private "Heartbeat" Configuration on a Cluster Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750)

  • 307962, "Multicast Support Enabled for the Cluster Heartbeat" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307962)

For additional details, review the Exchange Server 2003 Cluster Configuration Checklist (http://go.microsoft.com/fwlink/?linkid=36083).


Cluster Node Windows build number does not match first node
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the core version of the Microsoft Windows® operating system running on each node in the cluster:

HKEY_LOCAL_MACHINE\Cluster\Nodes\ <Node Number> \BuildNumber

If the Exchange Server Analyzer finds the value for BuildNumber on the second or subsequent node in the Exchange cluster different from the value for BuildNumber on the first node in the Exchange cluster, an error is displayed.

If an Exchange cluster is running across disparate versions of Windows, failover may not occur as expected or configured. In a mixed vintage Windows environment, failover will only occur from an earlier operating system to a later operating system (for example, from Windows 2000 Advanced Server to Windows Server™ 2003, Enterprise Edition). It will not occur from a later operating system to an earlier operating system (for example, from Windows Server 2003 to Windows 2000 Server).

To resolve this problem, you must upgrade all nodes to the same operating system and service pack. To minimize downtime, you can perform a rolling upgrade of your cluster.

To correct this error

  1. Review the instructions for performing a rolling upgrade of a cluster, by reading the Microsoft Knowledge Base article 811272, "How to Perform a Rolling Upgrade of Windows Server 2003 Server Clusters" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=811272).

  2. Review the article, "Windows 2000 Clustering: Performing a rolling upgrade" (http://go.microsoft.com/fwlink/?linkid=1718).

  3. Perform a rolling upgrade of each node whose BuildNumber value is not the same as the first node in the cluster.

For information about alternative procedures, see "Alternatives to Rolling Upgrades" (http://go.microsoft.com/fwlink/?LinkId=41363).


Cluster Node Windows service pack version does not match first node
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the Microsoft Windows® service pack version installed on each node in the cluster:

HKEY_LOCAL_MACHINE\Cluster\Nodes\<Node Number>\CSDVersion

If the Exchange Server Analyzer finds the value for CSDVersion on the second or subsequent node in the Exchange cluster different from the value for CSDVersion on the first node in the Exchange cluster, an error is displayed.

This error indicates that the nodes in this Exchange cluster are not running the same level of Windows service pack. It is recommended as a best practice that all nodes in an Exchange cluster run the same level of operating system and service pack.

To resolve this problem, you must upgrade all nodes to the same operating system and service pack. To minimize downtime, you can perform a rolling upgrade of your cluster.

To correct this warning

  1. Review the instructions for performing a rolling upgrade of a cluster, by reading the Microsoft Knowledge Base article 811272, "How to Perform a Rolling Upgrade of Windows Server 2003 Server Clusters" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=811272).

  2. Review the article, "Windows 2000 Clustering: Performing a Rolling Upgrade" (http://go.microsoft.com/fwlink/?linkid=34288).

  3. Perform a rolling upgrade of each node whose CSDVersion value is different from the first node in the cluster.

For information about alternative procedures, see "Alternatives to rolling upgrades" (http://go.microsoft.com/fwlink/?linkid=34289).


Cluster TEMP/TMP path is on the same drive as the system partition
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

On a non-clustered Exchange Server computer, the Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine the value for the TEMP and TMP environment variables:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\TEMP

HKLM\System\CurrentControlSet\Control\Session Manager\Environment\TMP

When the Exchange Server Analyzer is run against Exchange Virtual Server (EVS) in a Microsoft Windows® server cluster, it does not read HKLM registry hive. Instead, it reads the following registry entries:

HKEY_USERS \<Cluster service account SID> \Environment\TEMP

HKEY_USERS \<Cluster service account SID> \Environment\TMP

If the Exchange Server Analyzer finds that either the TEMP and/or TMP environment variable begins with %SYSTEMROOT, a warning is displayed.

The Microsoft Exchange Information Store service process uses the TEMP and TMP folders as temporary storage during various operations, such as message conversion and mailbox move operations. On a non-clustered Exchange server, the Microsoft Exchange Information Store service uses the SYSTEM (for example, Local System), which uses a default environment variable setting of %Systemroot%\Temp for both TEMP and TMP.

EVS running in a Windows server cluster uses the environment variable settings for the Cluster Service account, which runs under the context of a specific user security principle. For user accounts, the default environment variable for TEMP and TMP is set to %Userprofile%\temp.

The TEMP and TMP environment variables are used to designate which folders in the file system (for example, which path) should be used by applications that require a temporary workspace. TEMP is typically used by applications, such as Exchange, and TMP is typically used by development tools, such as Microsoft Visual C++®. The path for each variable is usually relative to the security context of the application or tool.

For optimal performance, it is recommended that you do not use the disk containing the operating system for the TEMP and TMP folders used by Exchange. In addition, you should ensure that these environment variables are set to paths on a fast disk or disk subsystem, such as a RAID 0+1 spindle set. It is also recommended that you do not use the disk containing the operating system for the TEMP and TMP folders used by Exchange or EVS.

To correct this warning

  1. Log on to a node in the cluster as the Cluster service account.

  2. Right-click My Computer and select Properties.

  3. Select Advanced.

  4. Click Environment Variables.

  5. In the User variables for <account name> area, select TEMP and click Edit.

  6. In the Variable value field, enter the new path for the TEMP environment variable and click OK.

  7. In the User variables for <account name> area, select TMP and click Edit.

  8. In the Variable value field, enter the new path for the TMP environment variable and click OK.

  9. Click OK to close the Environment Variables dialog box and OK once more to close the System Properties dialog box.

  10. Restart the node to apply the change.

  11. Repeat steps 1 through 10 for each node in the cluster.

For information about changing the TEMP/TMP environment variables on a non-clustered Exchange Server computer, see The TEMP/TMP variable appears to point to an invalid or inappropriate folder.


Dedicated cluster heartbeat not found
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the defined role for each network interface resource in the Exchange server cluster:

HKEY_LOCAL_MACHINE\Cluster\Networks\<NetworkInterfaceGUID>\Role

A value of 1 indicates the network resource has been configured as a dedicated private (heartbeat) network. A value of 2 indicates the network resource has been configured as a dedicated public network (client access). A value of 3 indicates the network resource has been configured as a mixed network that allows both heartbeat traffic and client access traffic.

The Exchange Server Analyzer queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Cluster service (ClusSvc). A value of True indicates the Cluster service is started and a value of False indicates the Cluster service is not running.

If the Exchange Server Analyzer does not find a network resource in an Exchange cluster configured as a dedicated private network, a warning is displayed.

Configuring a dedicated private network to use for the cluster heartbeat is a recommended best practice for all Exchange Server clusters. Communication between nodes is critical for smooth cluster operations. You must configure the networks that you use for cluster communication optimally and follow all hardware compatibility list requirements. For networking configuration, two or more independent networks must connect the nodes of a cluster to avoid a single point of failure. Using two local area networks is typical. Microsoft Product Support Services does not support the configuration of a cluster with nodes connected by only one network.

To correct this warning

  1. If not already present, add network interface cards to each node in the Exchange cluster and configure the network interface cards as a private network in Cluster Administrator.

  2. If additional network cards are present but being used for mixed networks, you should modify the configuration by re-configuring the appropriate networks to act as a dedicated private network.

For more information about cluster heartbeat networks, see the following Microsoft Knowledge Base articles:

  • 258750, "Recommended Private "Heartbeat" Configuration on a Cluster Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750)

  • 307962, "Multicast Support Enabled for the Cluster Heartbeat" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307962)

For additional details, review the document, Exchange Server 2003 Cluster Configuration Checklist (http://go.microsoft.com/fwlink/?linkid=36083).


Default file size for cluster.log should be raised to 32
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the ClusterLogSize parameter has been set:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\

If the Exchange Server Analyzer finds the value for ClusterLogSize is not present, or the value for ClusterLogSize is equal to or less than 8, a warning is displayed. On a busy cluster, the cluster.log file wraps around so quickly that entries may be lost when you troubleshoot fail-over situations under the following conditions:

  • Troubleshooting requires a detailed review of the cluster log file.

  • The cluster is managing many resources.

Therefore, when troubleshooting requires use of the cluster.log file, create the ClusterLogSize parameter, if not already present, and increase the default size to at least 32, 64, or 96.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To create the ClusterLogSize parameter and set its value

  1. Open a registry editor, such as Regedit.exe or Regedit32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

  3. In the left pane, click Environment.

  4. On the Edit menu, point to New and then click DWORD Value.

  5. Type ClusterLogSize, and then press ENTER to name the new registry entry.

  6. Right-click ClusterLogSize, and then click Modify.

  7. Modify the ClusterLogSize Value data to the new log file size. For example, modify the ClusterLogSize value to 32, 64, or 96, and then press ENTER.

  8. Quit Registry Editor
To modify the default size of the cluster.log file

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

  3. Right-click ClusterLogSize, and then click Modify.

  4. Modify the ClusterLogSize Value data to the new log file size. For example, modify the ClusterLogSize value to 32, 64, or 96, and then press ENTER.

  5. Quit Registry Editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about cluster logging in Microsoft Cluster Server, see the Microsoft Knowledge Base article 168801, "How to Turn on Cluster Logging in Microsoft Cluster Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=168801)


Enable Kerberos Authentication for SMTP
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2006-05-12

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether a Microsoft Exchange Server 2003 server that is installed on a Windows™ Server 2003 Cluster service has the Fully Qualified Domain Name (FQDN) of the server as a value for the SMTPSVC resource on the servicePrincipalName attribute.

If the Exchange Server Analyzer finds that the servicePrincipalName attribute for the SMTPSVC Exchange resource on the Cluster service does not contain the server's FQDN as a value, the Exchange Server Analyzer displays a best practice message.

It is a best practice to enable Kerberos authentication for Simple Mail Transfer Protocol (SMTP) Services on Windows Server 2003 cluster servers that are running Exchange Server 2003. You can enable Kerberos authentication by manually setting a new Service Principal Name (SPN) value for the SMTPSVC Exchange resource.

By default, Windows Server 2003 uses NTLM authentication. The Kerberos protocol is more flexible and efficient than NTLM, and more secure. The benefits gained by using Kerberos authentication are as follows:

  • Faster connections. With NTLM authentication, an application server must connect to a domain controller in order to authenticate each client. With Kerberos authentication, the server does not have to locate a domain controller. The server can authenticate the client by examining credentials presented by the client. Clients can obtain credentials for a particular server one time and reuse them throughout a network logon session.

  • Mutual authentication. NTLM enables servers to verify the identities of their clients. NTLM does not enable clients to verify a server's identity, or one server to verify the identity of another. NTLM authentication was designed for a network environment in which servers were assumed to be genuine. The Kerberos protocol makes no such assumption. Parties at both ends of a network connection can know that the party on the other end is who it claims to be.

  • Delegated authentication. Windows services impersonate clients when they access resources on the clients' behalf. Frequently, a service can complete its work for the client by accessing resources on the local computer. Both NTLM and Kerberos provide the information that a service must have in order to impersonate its client locally. However, some distributed applications are designed so that a front-end service must impersonate clients when it connects to back-end services on other computers. The Kerberos protocol has a proxy mechanism that enables a service to impersonate its client when it connects to other services. No equivalent is available with NTLM.

To resolve this issue, follow these steps to add the missing values for the affected attributes.

Use the SETSPN.exe tool to add an SPN with the missing values

  1. Install the Setspn.exe tool. To obtain the Setspn.exe tool, see "Windows 2000 Resource Kit Tool : Setspn.exe" (http://go.microsoft.com/fwlink/?LinkId=28103).

    The Windows Server 2003 version of the Setspn.exe command-line tool is available in the Windows Server 2003 Support Tools that are included on the Windows Server 2003 CD. To install the Server 2003 Support Tools, double-click the Suptools.msi file in the Support/Tools folder.

  2. Follow the guidance in the SETSPN.EXE Setspn_d.txt file to add the missing value to the Active Directory object for your Exchange server. The following example demonstrates adding the FQDN value for a virtual SMTP server SPN:

    • Start a command prompt, and then change to the directory where you installed Setspn.exe.

    • At the command prompt, type the following command:

      setspn.exe-a SMTPSVC/ mail.yourdomain.com YOURSERVERNAME

      Note:
      Replace mail.yourdomain.com with your SMTP virtual server FQDN and YOURSERVERNAME with the name of the Exchange server.
    • Then press Enter.


Exchange cluster node could not be contacted
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Cluster service (ClusSvc). A value of True indicates the Cluster service is started and a value of False indicates the Cluster service is not running.

The Exchange Server Analyzer also reads the following registry entry to determine the version of Windows that is running on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the computer is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the computer is running Windows 2000 Server, and a value of 5.2 indicates the computer is running Windows Server™ 2003.

If the Exchange Server Analyzer cannot determine the version of Windows running in the cluster, or if the Exchange Server Analyzer cannot determine whether the Cluster service is running, an error is displayed. This error indicates that the Exchange Server Analyzer could not contact a node in an Exchange Server cluster.

To correct this error

  1. Ensure that the Exchange Server computer has been started and is connected to the network.

  2. Use the ping command to see if the Exchange Server computer is reachable.

  3. If there is a firewall in place, check to see if remote procedure call (RPC) ports are blocked.

  4. Ensure that the Remote Registry service on the Exchange Server computer has been started.

  5. Check the permissions for the account under which the Exchange Server Analyzer is running to ensure that the account has sufficient permissions to read the registry on the Exchange Server computer.

For more information about troubleshooting network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).


Exchange data path in Active Directory does not match cluster registry
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2006-04-28

The Microsoft® Exchange Server Analyzer Tool queries both the cluster registry (HKEY_LOCAL_MACHINE\Cluster) and the Active Directory® directory service to determine if the paths for Exchange data files (for example, message tracking log files) are the same in both places. Exchange Server configures these values in the registry and in Active Directory when the Exchange Setup program is used to install Exchange on a node in a Microsoft Windows® server cluster.

The registry value created by Exchange Setup and read by the Exchange Server Analyzer is:

HKLM\Cluster\Resources\<Resource GUID of Information Store resource>\Parameters\DestPath

The Active Directory value created by Exchange Setup and read by the Exchange Server Analyzer is: msExchDataPath. This value is an attribute of the Exchange Server computer object in Active Directory, which is found at:

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN= OrganizationName =Administrative Groups, CN= AdministrativeGroupName , CN=Servers, CN= ServerName

If the Exchange Server Analyzer finds that the values for DestPath and msExchDataPath do not match, an error is displayed.

A common cause for these values to be different is when the location of some or all Exchange data files changes after Exchange has been in production. For example, if hardware is upgraded, message tracking log files are moved, and a drive letter is changed, the change is reflected in the cluster registry but not in Active Directory. After such a change has been made, service startup errors, database mounting issues, and other problems may result, especially when applying an Exchange service pack or installing a roll-up package.

Note:
You should resolve this discrepancy as soon as possible. Do not install any service packs or updates to Exchange Server until this problem is corrected.

To perform the following procedure, you will need to use an Active Directory editor such as Active Directory Service Interfaces (ADSI) Edit or the LDP (ldp.exe) tool.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Modify the affected Exchange Virtual Server (EVS) value for msExchDataPath so that it matches the value in the cluster registry for DestPath. The msExchDataPath attribute can be found at: CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=OrganizationName=Administrative Groups, CN=AdministrativeGroupName, CN=Servers, CN=ServerName

  2. Restart the virtual server's Exchange System Attendant resource for the change to take effect.

For more information about modifying Active Directory with the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260745).

For more information about how to use ADSI Edit to modify the msExchDataPath attribute, see the Knowledge Base article 288362, "XADM: "The System Cannot Find the Path Specified" Event ID 5007 Message is Logged by the Microsoft Exchange System Attendant" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=288362).


Event log replication is enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry on each server that is a node of a cluster:

HKEY_LOCAL_MACHINE\Cluster\Nodes\X\EnableEventLogReplication

Note:
X is the number of the node, starting with 1.

If the Exchange Server Analyzer finds that the value for EnableEventLogReplication is 1, the Exchange Server Analyzer displays a best practice message.

If the EnableEventLogReplication registry entry is set to 1, the cluster node replicates events in the event log to all other nodes in the cluster. If event log replication is enabled, tools that monitor multiple servers, such as Microsoft Operations Manager (MOM), report a single event multiple times, one time from each node. If you use automated monitoring, it is recommended that you disable event log replication on cluster nodes.

To disable event log replication on all nodes of a cluster

  1. Log on to any node of the cluster with an account that is a domain user account or a member of a global group.

  2. Click Start, click Run, and then type

    cluster /prop EnableEventLogReplication=0

To disable event log replication on a single cluster node

  1. Log on to any node of the cluster with an account that is a domain user account or a member of a global group.

  2. Click Start, click Run, and then type

    Cluster <name of node to disable> /prop EnableEventLogReplication=0

For more information about how to configure event log replication, see the Microsoft Knowledge Base article 224969, "HOW TO: Configure Event Log Replication in Windows 2000 Cluster Servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224969).

For more information about administering server clusters, see Administering Server Clusters (http://go.microsoft.com/fwlink/?LinkId=45971).


Kerberos disabled on Network Name resource
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of the Microsoft Windows® operating system that is running on the server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the computer is running Windows NT® Server 4.0. A value of 5.0 indicates the computer is running a Windows 2000 Server operating system, and a value of 5.2 indicates the computer is running a Windows Server™ 2003 operating system.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects with an object class of msExchExchangeServer. If the string value includes "Version 5.5," the computer is running Exchange Server 5.5. If the string value includes "Version 6.0," the computer is running Exchange 2000 Server. If the string value includes "Version 6.5," the computer is running Exchange Server 2003.

Finally, the Exchange Server Analyzer reads the following registry value to determine whether Exchange Server is running in a cluster with a Kerberos-enabled Network Name cluster resource:

HKLM\Cluster\Resources\<Resource GUID for Network Name resource>\Parameters\RequireKerberos

A value of 0 for RequireKerberos indicates that the Network Name resource is not enabled for Kerberos, and a value of 1 indicates that the Network Name resource is enabled for Kerberos.

If the Exchange Server Analyzer finds the value for RequireKerberos set to 0 on an Exchange Server 2003 virtual server that is running in a Windows Server 2003 server-based cluster, a warning is displayed.

This warning indicates that a Kerberos-enabled Network Name cluster resource is not being used for an Exchange Server 2003 virtual server. This is not a supported configuration, and should be corrected as soon as possible.

To correct this warning

  1. Open the Cluster Administrator program.

  2. Take the Network Name resource offline. This will also take all resources offline that depend on the Network Name resource, including the Microsoft Exchange System Attendant resource.

  3. Right-click the Network Name resource, and then click Properties.

  4. On the Parameters tab, click the Enable Kerberos Authentication option, and then click OK.

  5. Bring the Network Name resource online, and then bring the remaining offline resources online.

For more information about using Kerberos-enabled Network Name resources on a Windows Server 2003 cluster, see the Microsoft Knowledge Base article 302389, "Description of the Properties of the Cluster Network Name Resource in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=302389).

For more information about clustering, see the following topics:

  • "Deploying Exchange Server 2003 in a Cluster" in the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?linkid=47569)

  • "Planning for Exchange Clustering" in the Exchange Server 2003 High Availability Guide (http://go.microsoft.com/fwlink/?linkid=47571)


Kerberos enabled on Network Name resource
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of the Microsoft Windows® operating system that is running on the server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the computer is running Windows NT® Server 4.0. A value of 5.0 indicates the computer is running a Windows 2000 Server operating system, and a value of 5.2 indicates the computer is running a Windows Server™ 2003 operating system.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects with an object class of msExchExchangeServer. If the string value includes "Version 5.5," the computer is running Exchange Server 5.5. If the string value includes "Version 6.0," the computer is running Exchange 2000 Server. If the string value includes "Version 6.5," the computer is running Exchange Server 2003.

Finally, the Exchange Server Analyzer reads the following registry value to determine whether Exchange is running in a cluster with a Kerberos-enabled Network Name cluster resource:

HKLM\Cluster\Resources\<Resource GUID for Network Name resource>\RequireKerberos

A value of 0 for RequireKerberos indicates that the Network Name resource is not enabled for Kerberos and a value of 1 indicates that the Network Name resource is enabled for Kerberos.

If the Exchange Server Analyzer finds the value for RequireKerberos set to 1 on an Exchange 2000 Server virtual server that is running in a Windows 2000 Server server-based cluster, a warning is displayed.

This warning indicates that a Kerberos-enabled Network Name cluster resource is being used for an Exchange 2000 Server virtual server. This is not a supported configuration, and should be corrected as soon as possible. As stated in the Microsoft Knowledge Base article 235529, "Kerberos support on Windows 2000-based server clusters" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=235529), Kerberos authentication for an Exchange 2000 Server Network Name resource is not supported. Exchange 2000 Server has not been tested to ensure that a clustered Exchange 2000 Server virtual server supports Kerberos authentication.

To correct this warning

  1. Open a command prompt on any node in the cluster.

  2. Run the following command: cluster res "Name of Network Name Resource" /priv requirekerberos=0:dword

    Note:
    The resource name should be enclosed in quotation marks.

  3. Take the Network Name resource offline and delete it.

  4. Open Active Directory Users and Computers.

  5. Locate the computer account object for the deleted Network Name resource and delete it from Active Directory.

  6. Create a new Network Name resource for this Exchange Virtual Server (EVS) and do not make it Kerberos-enabled. You can use the same name and configuration as the Network Name resource that you deleted in step 3.

  7. Bring the new Network Name resource online, and then bring the remaining resources in the EVS online.

For more information about using Kerberos-enabled Network Name resources on a Windows 2000 Server cluster, see the Microsoft Knowledge Base article 235529, "Kerberos support on Windows 2000-based server clusters" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=235529).


MSDTC Appears to Be Missing from a Cluster
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2006-04-20

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Microsoft Distributed Transaction Coordinator (MSDTC) resource exists in a cluster:

HKEY_LOCAL_MACHINE\Cluster\Resources\

The Exchange Server Analyzer displays a warning if the value of ClusterMSDTCInstance is 0.

The MSDTC resource must be present in an Exchange Server cluster to support initial installation and service pack upgrades. However, it is not a critical component and is not required while Exchange is running.

You or another administrator in your organization might have removed the MSDTC resource because you know that it is not required when Exchange is running.

However, it is recommended that you do not remove the MSDTC resource after your initial setup of Exchange Server 2003. If you keep the MSDTC resource in the cluster, you will be able to run Service Pack setups and other updates.

To resolve this warning, create a new MSDTC resource. For specific steps about how to create an MSDTC resource, see "How to Install the Microsoft Distributed Transaction Coordinator in a Windows Server 2003 Server Cluster" in "Deploying Exchange Server 2003 in a Cluster" in the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For More Information

For more information about MSDTC and Exchange see "Cluster Groups" in "Understanding Exchange Server 2003 Clustering" in the Exchange Server 2003 High Availability Guide (http://go.microsoft.com/fwlink/?LinkId=47571).

For more information about how to add the MSDTC resource in Microsoft Windows Server™ 2003, see Microsoft Knowledge Base article 301600, "How to Configure Microsoft Distributed Transaction Coordinator on a Windows Server 2003 Cluster" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301600).

Note:
Knowledge Base article 301600 includes a reference to article 817064, "How to enable network DTC access in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=817064). It is an Exchange Server security best practice not to enable network DTC access for an Exchange cluster. If you are configuring the Distributed Transaction Coordinator resource for an Exchange cluster, do not enable network DTC access.


MSDTC Outages Will Affect Cluster Group
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether you have configured a failure of the Microsoft Distributed Transaction Coordinator (MSDTC) resource to affect the group:

HKEY_LOCAL_MACHINE\Cluster\Resources\

If the value of ClusterMSDTCInstance is 2, the Exchange Server Analyzer displays a warning.

The MSDTC resource must be present in an Exchange cluster to support initial installation and service pack upgrades. However, it is not required while Exchange is running.

By default, a failure to the MSDTC resource will affect the group. Two examples of resource failure are as follows:

  • The log file size exceeds the capacity of the disk.

  • The physical disk for the MSDTC resource fails.

Specifically, a failure to the MSDTC resource will cause a failover of all Exchange services that are running on that cluster node to a different node in the cluster. However, because the MSDTC resource is not a required resource, it does not have to be configured to affect the group.

To resolve this warning, configure the Exchange Cluster so that a failure to the MSDTC resource does not affect the group.

To configure Exchange so that a failure to the MSDTC resource does not affect the group

  1. Log on to any node of the cluster.

  2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

  3. Under Groups, right-click the cluster group that includes the MSDTC resource.

  4. Right-click the MSDTC resource, and then click Properties.

  5. On the Advanced tab, clear the Affect the group check box, and then click OK.

For More Information

For specific steps about how to create an MSDTC resource, see "How to Install the Microsoft Distributed Transaction Coordinator in a Windows Server 2003 Server Cluster" in "Deploying Exchange Server 2003 in a Cluster" in the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about MSDTC and Exchange, see "Cluster Groups" in "Understanding Exchange Server 2003 Clustering" in the Exchange Server 2003 High Availability Guide (http://go.microsoft.com/fwlink/?LinkId=47571).

For more information about how to add the MSDTC resource in Microsoft Windows Server™ 2003, see Microsoft Knowledge Base article 301600, "How to Configure Microsoft Distributed Transaction Coordinator on a Windows Server 2003 Cluster" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301600).

Note:
Knowledge Base article 301600 includes a reference to article 817064, "How to enable network DTC access in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=817064). It is an Exchange Server security best practice not to enable network DTC access for an Exchange cluster. If you are configuring the Distributed Transaction Coordinator resource for an Exchange cluster, do not enable network DTC access.


MTA Outages Will Affect Cluster Group
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool examines the Cluster\Resources registry settings of the Exchange server system.

HKEY_LOCAL_MACHINE\Cluster\Resources

If the Exchange Server Analyzer finds that the Message Transfer Agent (MTA) Stacks service resources are running on the Exchange Server 2003 cluster in a native mode organization, the Exchange Server Analyzer displays a best practice message.

As a best practice, it is recommended that the Exchange Administrator configure the MTA resource so that MTA does not cause a possible Exchange Virtual Server failover when MTA stops or fails.

Note:
The MTA Stacks service in Microsoft Exchange 2000 Server and in Microsoft Exchange Server 2003 is frequently used to provide backward-compatible message transfer services between Exchange 2000 Server or Exchange Server 2003 servers and Microsoft Exchange Server 5.5 servers in a mixed-mode environment. When the transition is made to a pure Exchange 2000 Server or Exchange Server 2003 native-mode environment, MTA is not a critical resource for Exchange services to run.

If the MTA Stacks service stops running or fails, a possible Exchange Virtual Server failover may be set off. To prevent a possible Exchange Virtual Server (EVS) failover, it is recommended as a best practice that you configure the MTA Stacks service to avoid a failover by doing the following.

To configure the MTA Stacks service to an unaffected state in an Exchange server cluster

  1. Open Cluster Administrator

  2. Clear the Affect this Group option for the MTA Stack service resource.

For More Information

For information about MTA Stacks service supportability guidelines for Exchange Server 2003, see Microsoft Knowledge Base article 810489, "MTA Stacks service supportability guidelines for Exchange 2000 Server and Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810489).

For more information about MTA in the Exchange Server 2003 architecture, see Exchange MTA in Exchange Server 2003 Architecture (http://go.microsoft.com/fwlink/?LinkId=63496).

For information about how to deploy Exchange Server 2003 in a cluster, see Deploying Exchange Server 2003 in a Cluster (http://go.microsoft.com/fwlink/?LinkId=63495).

For information about how to use Cluster Administrator, see Using Cluster Administrator to Manage Exchange Clusters (http://go.microsoft.com/fwlink/?LinkId=63493).


This is a 2-node Active/Active Cluster
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2006-04-28

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for ClusSvc, the Cluster service. A value of True indicates the Cluster service is running, and a value of False indicates it is not running.

The Exchange Server Analyzer also reads the following registry entry to determine the number of nodes in the cluster:

HKEY_LOCAL_MACHINE\Cluster\Nodes\ <Node Number> \NodeName

The count of instances of NodeName represents the number of nodes in the cluster. In addition, the Exchange Server Analyzer reads the following registry entry to determine the number of Exchange Server resources in the cluster:

HKLM\Cluster\Resources\ <Cluster Resource GUID> \Parameters\DestPath

The following resources on an Exchange Server cluster will have a DestPath value:

  • Microsoft Exchange Message Transfer Agent

  • Microsoft Exchange Information Store

The count of the instances of DestPath indicates the number of servers running Exchange Virtual Server (EVS) in the cluster.

If the Exchange Server Analyzer determines that there are 3 instances of DestPath in a cluster that has 2 instances of NodeName, a warning is displayed. This warning indicates that this is a two-node cluster with two servers running EVS, known as an Active/Active cluster.

  • In the Active/Active cluster model, the number of Exchange virtual servers in the cluster is equal to or greater than the number of physical nodes in the cluster.

Note:
Active/Active Exchange clusters can only be created in clusters made up of two nodes. If you have three or more nodes in your cluster, you must use the Active/Passive model.
  • In the Active/Passive cluster model, the number of Exchange virtual servers in the cluster is less than the number of physical nodes in the cluster.

Although Microsoft supports Active/Active clustering for Exchange Server, it is strongly recommended that Active/Passive implementations be used for Exchange clusters. Microsoft only supports Active/Active Exchange clusters that adhere to the following scaling limits:

  • The number of concurrent user connections per Exchange virtual server per physical node should never be greater than 1,900. If one node of the cluster is unavailable and if all Exchange virtual servers are online on a single node, the scaling limits remain at 3,800 connections for the two Exchange virtual servers. Because each user may make multiple connections, the number of mailboxes is not an accurate way to estimate the number of connections.

  • The average CPU utilization per Exchange store process should not be more than 40 percent. If the total CPU utilization by the STORE.EXE process on a node is more than 40 percent for a period of 10 minutes or more, you must move users to another Exchange virtual server or Exchange server. Note that this load does not include the CPU utilization consumed because of administrative tasks.

Migrating from an Active/Active cluster configuration to an Active/Passive configuration involves moving resources off the second EVS and then decommissioning it.

To migrate from an Active/Active cluster to an Active/Passive cluster

  1. Move the mailboxes hosted on the second EVS to the first EVS in the cluster. The first EVS in the cluster always contains the only Microsoft Exchange message transfer agent (MTA) resource in the cluster.

  2. After all of the mailboxes have been moved to the first EVS, take the second EVS offline.

  3. Remove the second EVS by doing one of the following:

    • On an Exchange Server 2003 cluster, right-click the Microsoft Exchange System Attendant resource and click Remove Exchange Virtual Server.

    • On an Exchange 2000 Server cluster, right-click the Microsoft Exchange System Attendant resource and click Delete.

  4. Verify that the EVS object has been removed from the Active Directory® directory service. Because of Cluster service account permission changes in Exchange Server 2003, your account must have permission to remove Active Directory objects.

  5. Take the remaining resources in the second EVS (for example, Physical Disk, Network Name, and IP Address) offline, and then delete them.

  6. Delete the resource group that contained the second EVS.

For more information about how to remove an EVS, see the section, "Removing an Exchange virtual server from a Cluster" in Deploying Microsoft Exchange 2000 Server Clusters Exchange (http://go.microsoft.com/fwlink/?LinkId=9393).

For more information about best practices and recommendations for Exchange clusters, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about deploying Exchange in a Windows server cluster, see the Microsoft Knowledge Base article 815180, "Considerations when deploying Exchange on an Active/Active cluster" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815180).


Quorum log too small
Microsoft Exchange Server Analyzer - Articles > Exchange Cluster >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the size of the quorum log configured for the cluster:

HKEY_LOCAL_MACHINE\Cluster\Quorum\MaxQuorumLogSize

If the Exchange Server Analyzer finds the value for MaxQuorumLogSize less than 4194304 decimal (0x400000 hexadecimal), a warning is displayed.

The MaxQuorumLogSize registry value represents the currently configured value for the Reset quorum log at cluster quorum parameter. This warning is generated if the MaxQuorumLogSize is less than 4096 kilobytes (KB).

The cluster records all changes to the cluster database in the quorum log file. When the quorum log attains the specified size, the cluster saves the database and resets the log file. On Microsoft Windows® 2000 Server-based clusters, the default quorum size limit is 64 KB. On Windows Server™ 2003-based clusters, the default quorum size limit is 4096 KB. For Exchange Server clusters, it is recommended that the Reset quorum log at property be configured to 4096 KB. This ensures that there will be sufficient space to hold the cluster configuration information, such as which servers are part of the cluster, what resources are installed in the cluster, and what state those resources are in (for example, online or offline).

To correct this warning

  1. Open Cluster Administrator.

  2. In the left pane, right-click the object that represents the cluster, and then click Properties.

  3. On the Quorum tab, configure Reset quorum log at with a value of 4096.

  4. Click OK to save the changes.

For more information about the default quorum log size limit, see the Microsoft Knowledge Base article 225081, "Cluster Resources Quorum Log Size Defaults to 64 KB" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=225081).


Exchange Server
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2005-11-18

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating with regard to Exchange Server computers. Additionally, these articles describe actions that you can take to resolve Exchange-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


Account Lockout installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-08-28

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine whether a file named ALockout.dll is present in the System32 folder on the Exchange server. ALockout.dll is part of the Account Lockout and Management Tools (ALTools.exe). These tools help administrators manage accounts and troubleshoot problems with account lockout.

If the Exchange Server Analyzer finds ALockout.dll present on an Exchange server, the Exchange Server Analyzer displays an error.

The Account Lockout and Management Tools should not be used on servers that host network applications or services, including Exchange servers. If the Account Lockout and Management Tools are installed on an Exchange server, they could prevent the Exchange services from starting. Therefore, it is strongly recommended that you uninstall the Account Lockout and Management Tools from this Exchange server.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this error

  1. At a command prompt, type regsvr32 /u alockout.dll.

  2. Delete the ALockout.dll value that is under the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
Note:
After you delete the ALockout.dll value, the AppInit_DLLs registry entry is blank. Restart the computer.
  1. Delete the ALockout.dll file from the System32 folder.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Account Lockout and Management Tools, see "Account Lockout Tools" in Account Passwords and Policies (http://go.microsoft.com/fwlink/?LinkId=52465).


Active Directory Site Mismatch
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool implements the Win32 API DsGetSiteName function to query for the Active Directory® directory service site name of the domain controller and the Active Directory site name of the local Exchange Server.

If the Exchange Server Analyzer determines that the Active Directory site name of the domain controller and the Active Directory site name of the local Exchange Server do not match, the Exchange Server Analyzer displays a warning.

This warning indicates that the Directory Service Access (DSAccess) process is going out of the local Active Directory site for its Lightweight Directory Access protocol (LDAP) requests which can cause a severe degradation in Exchange Server performance.

This situation can be caused by the static configuration of an off-site domain controller, a network or domain controller computer outage that makes the site resident domain controller unreachable, or an incorrectly designed Active Directory topology that does not include an Active Directory domain controller in the same site as the Exchange Server.

DSAccess is a shared Exchange Server component that accesses and stores directory information in a cache. DSAccess dynamically detects the directory servers that other Exchange components should contact, based on criteria such as Active Directory site configuration and Active Directory server availability. Exchange front-end servers use DSAccess to determine which server contains a particular user's mailbox, the Simple Mail Transfer Protocol (SMTP) addresses that exist for a user object, and the servers that contain public folder stores.

Upon initialization, if DSAccess does not find a set of statically configured domain controllers or global catalogs in the registry, DSAccess uses a discovery process to identify the network topology and assess the availability and suitability of directory servers. Part of the determination of a domain controllers' suitability is whether the domain controller is in the same Active Directory site as the Exchange Server.

To reduce latency that may be introduced by cross-site LDAP requests, Exchange Servers should be located in an Active Directory site that has a resident domain controller.

To address this issue:

  • Evaluate the site definitions for the Active Directory topology to verify that each Exchange Server has access to a domain controller in the same Active Directory site.

  • Verify that any statically configured domain controllers reside in the same Active Directory site as the Exchange Server.

For More Information

For more information about how to configure and troubleshoot DSAccess, see the following Exchange resources:

  • Directory Integration and Exchange Server (http://go.microsoft.com/fwlink/?LinkId=63447)

  • Understanding and Troubleshooting Directory Access (http://go.microsoft.com/fwlink/?LinkId=39012)

  • Microsoft knowledge Base article 250570, "Directory service server detection and DSAccess usage" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570)


Administrative file shares disabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default administrative shares have been disabled:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\AutoShareServer

If the Exchange Server Analyzer finds that the value for AutoShareServer is set to 0, an error is displayed.

This error indicates that the default server-created administrative shares have been disabled on this server. An online backup or restoration of Exchange Server may not work when the default administrative shares have been disabled. Depending on the backup program, you may receive the error messages when trying to restore data. You may also see error messages in the tape backup log.

Additionally, when the administrative shares have been removed, you may receive the following message during an online backup of Exchange Server: Unexpected error 0xc0040000 the Microsoft Exchange Server computer is not available. To resolve this problem, it is recommended that the default administrative shares be re-enabled by editing the registry and restarting the Server service.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters

  3. In the right pane, locate and double-click AutoShareServer.

  4. Change the value from 0 to 1.

  5. Close the registry editor, and restart the Server service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about restoring the default administrative shares in Microsoft Windows Server™ 2003, see the Knowledge Base article 816113, "HOW TO: Use Registry Editor to Restore Administrative Shares in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=816113).


AFD.SYS driver and X.400 connector interoperability
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of Microsoft Windows® running on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates that the Exchange Server computer is running on Microsoft Windows NT® Server 4.0. A value of 5.0 indicates that the Exchange Server computer is running Windows 2000 Server and a value of 5.2 indicates the Exchange Server computer is running Windows Server™ 2003.

The Exchange Server Analyzer also queries the Win32_ComputerSystem Microsoft Windows Management Instrumentation (WMI) class to determine the value set for the NumberOfProcessors key. This value represents the number of processors installed on the computer. These processors include both physical processors and logical processors. A physical processor can be split into two logical processors by using hyper-threading technology from Intel.

The Exchange Server Analyzer also reads the following registry entry to determine whether the Exchange Server is a bridgehead for an X.400 connector:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeMTA

Finally, the Exchange Server Analyzer queries the CIM_Datafile Windows Management Instrumentation (WMI) class to determine the value of the Version key for a file named Afd.sys.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • The Exchange Server computer is running on Windows Server 2000.

  • The value for NumberOfProcessors is larger than 1.

  • The Exchange Server is a bridgehead for an X.400 connector.

  • The value of the Version key for WINDOWSPATH%\\system32\\drivers\\afd.sys is in the range of 5.0.2195.7036 and 5.0.2195.7060.

This warning indicates that the version of Afd.sys installed on the server may cause mail flow issues with X.400 connectors homed on this server.

To resolve this problem, obtain the update referenced in Microsoft Knowledge Base article 904712, "Mail delivery is slower than expected, or mail delivery stops, on an X.400 connector to a remote site in Exchange Server 5.5" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=904712).


Aging Keep Time interval for database is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchAgingKeepTime attribute has been set. This attribute represents the time value used to determine when to remove indexes, views, and categorizations. If the Exchange Server Analyzer finds that this attribute is set, a non-default configuration message is displayed.

Indexes used for views that are created in Exchange database tables by an Exchange client that have not been used for a specific time are cleaned up at this time. The msExchAgingKeepTime attribute specifies the minimum index age before it is deleted. The default value in the original release version of Exchange 2000 Server was eight days. In Service Pack 1 (SP1) for Exchange 2000 Server, and in all subsequent versions of Exchange Server, including Exchange Server 2003 and Exchange Server 2007, the default value is 40 days.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.
To view or modify the Aging Keep Time value

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=<ExchangeOrganizationName>.

  3. Expand CN=Administrative Groups, expand CN=<AdministrativeGroupName>, and then expand CN=Servers.

  4. Expand CN=<ServerName>, expand CN=InformationStore, and then select CN=<StorageGroupName>.

  5. In the details pane, right-click CN=<MailboxStoreName>, and then click Properties.

  6. In the Attribute Editor, click the msExchAgingKeepTime attribute, and then click Edit.

  7. In the Edit Attribute box, click Clear to clear the value.

  8. Click Apply, and then click OK.

  9. Close ADSI Edit. If a change is made, restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about potential issues accessing information store folders in Exchange Server, see Microsoft Knowledge Base article 216076, "Accessing information store folders may become slow in Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=216076).


Antigen Update Available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-06-20

The Microsoft Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft® Windows® Management Instrumentation (WMI) class to determine the value of the Version key for MimeNavigator.dll. This module is included with Microsoft Antigen versions 8 and 9.

If the Exchange Analyzer finds the value of the Version key for MimeNavigator.dll to be less than 8.00.1517.0 for version 8 and less than 9.00.1055.0 for version 9, the Exchange Analyzer displays a warning.

This warning indicates that Microsoft Antigen version 8 or 9 is installed on the Exchange server and that a software update is available. This update is highly recommended and can improve the overall performance and reliability of the server.

To address this issue, review and apply the recommendations found in Microsoft Knowledge Base article 928082, Size of SMTP messages may increase during the scanning process in Antigen.


Application log size
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-11-09

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the maximum size of the Application log file:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\MaxSize

If the Exchange Server Analyzer finds that the value for MaxSize is less than 41,943,040 bytes (40 megabytes ), the Exchange Server Analyzer displays a best practice message.

By default, the maximum log size for the Application log file is 16,777,216 bytes (16384 KB) for Windows Server 2003 and 524288 (512 KB) for Windows 2000 Server. For computers that are running Exchange Server, the best practice is to set the maximum size of the Application log file at 40 MB (entered as 40960KB) or more. By increasing the Application log file size, you preserve more application events. The additional event information helps when you troubleshoot.

To increase the maximum size of the Application log

  1. Open the Event Viewer Microsoft Management Console (MMC) snap-in.

  2. Right-click the Application log and then click Properties.

  3. On the General tab, under Log size, enter 40960 or more in the Maximum log size box, and then click OK.


ASP.NET Rootver is damaged
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value set on the Rootver key for ASP.NET:

HKEY_LOCAL_MACHINE\Software\Microsoft\ASP.NET

The Exchange Server Analyzer displays an error if the following conditions exist:

  • The Exchange Server Analyzer finds that the Rootver value is set to 0.0.0.0.

  • The Cluster service is running.

Sometimes ASP.NET Setup fails without providing a notification of the failure. In these cases, the Rootver key is set to 0.0.0.0. Setting the Rootver value to 0.0.0.0 causes the Microsoft Exchange System Attendant service or other Exchange Server services to fail to start on Exchange Server 2003 and Exchange Server 2007 clusters. You must correct this error by setting the Rootver value to one of the following:

  • Exchange Server 2003 Rootver key = 1.1.4322.0.

  • Exchange Server 2007 Rootver key = 2.0.50727.0

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To set Rootver to 1.1.4322.0

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\ASP.NET\

  3. In the details pane, double-click the RootVer key.

  4. In the Edit String dialog box, set the Value data to the appropriate value from the article above, and then click OK.

  5. Exit the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Automatic Operating System debugging has been disabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether operating system debugging has been disabled:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Auto

If the Exchange Server Analyzer finds the value for Auto set to 0, a warning is displayed.

By default, an application debugger named Dr. Watson is installed with Microsoft Windows® 2000 Server and Windows Server™ 2003 operating systems. A debugger is a program that helps detect, locate, and correct errors in another program by enabling a programmer to step through the program, examine the data, and monitor conditions such as the values of variables.

The default options are set the first time Dr. Watson runs, which can be either when a program error occurs or when you start Dr. Watson yourself.

When an application error occurs, Windows searches for a program error handler. A program error handler deals with errors as they occur during the running of a program. If Windows does not find a program error handler, it verifies that the program is not currently being debugged and considers the error to be unhandled. Windows then processes unhandled errors by looking in the registry for a program error debugger.

The behavior of Windows depends on the settings of two registry values under: HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

The entries are named Debugger and Auto. The value for the Debugger entry specifies the command for the debugger that will be used to analyze program errors. If the value for the Debugger entry is found, Windows checks to see if the value for the Auto entry is set to 0 or 1:

  • If the value for Auto entry is set to 0, Windows generates a message box that notifies you that a program error has occurred. If the value for the Debugger entry specifies the command for a valid debugger, the message box will display two buttons: OK and Cancel. If you click OK, the program is stopped. If you click Cancel, the specified debugger is started. If the value for the Debugger entry is empty, the message box will display only OK, and no debugger will start.

  • If the value for the Auto entry is set to 1 and the value for the Debugger entry specifies the command for a valid debugger, the system automatically starts the debugger and does not generate a message box.

When Windows is installed, the value for the Auto entry is set by default to 1 and the value for the Debugger entry specifies the command to start Dr. Watson (drwtsn32 -p %ld -e %ld -g). This means that when a program error occurs, Dr. Watson automatically diagnoses the error and logs the appropriate diagnostic information.

It is recommended that a program error debugger be used on Exchange Server computers as a best practice. If you have been using a program other than Dr. Watson as your default debugger, and you want to use Dr. Watson instead, go to the command prompt and type the command drwtsn32 -i to start Dr. Watson. Typing -i causes the required changes to be made to the registry.

To register Dr. Watson as the default debugger from the command prompt

  1. Open a Command Prompt window.

  2. Run the following command: drwtsn32 -i

  3. You will receive a message that says "Dr. Watson has been installed as the default application debugger." Click OK to acknowledge this message.

To register Dr. Watson as the default debugger from the user interface

  1. Click Start, click Run, type drwtsn32, and then press ENTER. The Dr. Watson for Windows user interface will appear.

  2. Select the Create Crash Dump File check box.

  3. Click OK to save the changes and close the Dr. Watson for Windows user interface.

For more information about Dr. Watson for Windows, see the Dr. Watson Help file by pressing F1 in the Dr. Watson user interface.

If you plan on using a program error debugger other than Dr. Watson, you can disable Dr. Watson using the procedure in the Microsoft Knowledge Base article 188296, "How to Disable Dr. Watson for Windows" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=188296).


Average LDAP read latency has exceeded 50 milliseconds
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-14

The Microsoft Exchange Analyzer tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the LDAP Read Time performance counter of the MSExchangeDSAccess Process performance object to analyze performance data.

The LDAP Read Time performance counter shows the time in milliseconds that it takes a Lightweight Directory Access Protocol (LDAP) read request to be fulfilled. The Exchange Analyzer retrieves a sample every 5 seconds for 5 minutes. The Exchange Analyzer then reports the maximum value for the performance counter during the collection interval. If the average value exceeds 50 milliseconds, the Exchange Analyzer displays a warning.

High LDAP read latencies can be caused by high remote procedure call (RPC) latencies and by increasing queues. High LDAP read latencies generally indicate one of the following problems:

  • A performance problem with the network connection to the domain controller.

  • Performance problems with the domain controller itself.

Note:
LDAP latencies are generally higher when users connect to domain controllers that are located in different physical sites. However, the recommended maximum latencies stated in this article should generally be followed.

If the domain controller that has logged this warning is located in a different physical site, you may be able to safely ignore this error if you can determine that the domain controller that reports this warning is not used by the Exchange server. One way to determine whether a domain controller is used by Exchange is to increase diagnostic logging for the Topology component of the MSExchangeDSAccess service to Minimum. If you do not see MSExchangeDSAccess event ID event 2080, you can safely ignore this warning.

To resolve this warning, do the following:

  • Verify that all network connections to the domain controller are functional and support Internet Control Monitoring Protocol (ICMP) traffic.

  • Consider the best practices in the following articles:

    • For information about the LDAP Read Time performance counter and other counters you can use to troubleshoot Active Directory-bound problems, see the "Ruling Out Active Directory-Bound Problems" topic in Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588). This article also includes information about how to improve Active Directory performance.

    • For more information about how to maximize Active Directory performance, see the "Active Directory Integration Tuning" topic in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

    • For information about making sure of high availability for your Active Directory servers, see the sections under Ensuring Reliable Access to Active Directory and Domain Name System in the "System-Level Fault Tolerant Measures" topic of the Exchange 2003 High Availability Guide (http://go.microsoft.com/fwlink/?LinkId=47571).

    • For information about network bandwidth considerations, see the Network Performance section of the "Understanding Exchange Performance" topic in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).


Maximum LDAP read latency has exceeded 100 milliseconds
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-14

The Microsoft Exchange Analyzer tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the LDAP Read Time performance counter of the MSExchangeDSAccess Process performance object to analyze performance data.

The LDAP Read Time performance counter shows the time in milliseconds that it takes a Lightweight Directory Access Protocol (LDAP) read request to be fulfilled. The Exchange Analyzer retrieves a sample every 5 seconds for 5 minutes. The Exchange Analyzer then reports the maximum value for the performance counter during the collection interval. If the maximum value exceeds 100 milliseconds, the Exchange Analyzer displays an error.

High LDAP read latencies can be caused by high remote procedure call (RPC) latencies and by increasing queues. High LDAP read latencies generally indicate one of the following problems:

  • A performance problem with the network connection to the domain controller.

  • Performance problems with the domain controller itself.

Note:
LDAP latencies are generally higher when users connect to domain controllers that are located in different physical sites. However, the recommended maximum latencies stated in this article should generally be followed.

Exchange servers will query out-of-domain global catalog servers every 15 minutes to keep an up-to-date list of global catalog servers and Domain Controllers. Because some of these directory servers may be remote, the latencies on these queries may be high. This is acceptable as long as the requests are infrequent, that is, the rate is less than 0.5 requests a second.

If the domain controller that has logged this error is located in a different physical site, you may be able to safely ignore this error if you can determine whether the domain controller that reports this error is not used by the Exchange server. One way to determine whether a domain controller is used by Exchange is to increase diagnostic logging for the Topology component of the MSExchangeDSAccess service to Minimum. If you do not see MSExchangeDSAccess event ID event 2080, you can safely ignore this error.

Important:
For mixed mode environments only, behavior was introduced around the Exchange 2000 SP2 timeframe for certain specific security related user attributes like tokenGroups and tokengroupsGlobalandUniversal, used to determine what security groups a user is a member of and therefore what permissions s/he has to secure resources such as public folders, that requires the Exchange server to query a domain controller that is authoritative for the user's home domain. The authoritative domain controller may be in a remote site and queries from lots of remote homed domain users accessing local public folders could contribute to high RPC latencies.

For more information about this behavior, see the following Exchange Server blog topic:

  • Exchange Does Not Always Use Local GCs

    Note:
    Links to blogs are provided to help you find the technical information you need. The content of each blog and its URL are subject to change without notice.

To resolve this error, do the following:

  • Verify that all network connections to the domain controller are functional and support Internet Control Monitoring Protocol (ICMP) traffic.

  • Consider the best practices in the following articles:

    • For information about the LDAP Read Time performance counter and other counters you can use to troubleshoot Active Directory-bound problems, see the "Ruling Out Active Directory-Bound Problems" topic in Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588). This article also includes information about how to improve Active Directory performance.

    • For more information about how to maximize Active Directory performance, see the "Active Directory Integration Tuning" topic in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

    • For information about making sure of high availability for your Active Directory servers, see the sections under Ensuring Reliable Access to Active Directory and Domain Name System in the "System-Level Fault Tolerant Measures" topic of the Exchange 2003 High Availability Guide (http://go.microsoft.com/fwlink/?LinkId=47571).

    • For information about network bandwidth considerations, see the Network Performance section of the "Understanding Exchange Performance" topic in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).


Average LDAP search latency has exceeded 50 milliseconds
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-14

The Microsoft Exchange Analyzer tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the LDAP Search Time performance counter of the MSExchangeDSAccess Process performance object to analyze performance data.

The LDAP Search Time performance counter shows the time in milliseconds that it takes a Lightweight Directory Access Protocol (LDAP) search request to be fulfilled. The Exchange Analyzer retrieves a sample every 5 seconds for 5 minutes. The Exchange Analyzer then reports the maximum value for the performance counter during the collection interval. If the average value exceeds 50 milliseconds, the Exchange Analyzer displays a warning.

High LDAP search latencies can be caused by high remote procedure call (RPC) latencies and by increasing queues. High LDAP search latencies generally indicate one of the following problems:

  • A performance problem with the network connection to the domain controller.

  • Performance problems with the domain controller itself.

Note:
LDAP latencies are generally higher when users connect to domain controllers that are located in different physical sites. However, the recommended maximum latencies stated in this article should generally be followed.

If the domain controller that has logged this warning is located in a different physical site, you may be able to safely ignore this error if you can determine whether the domain controller that reports this warning is not used by the Exchange server. One way to determine whether a domain controller is used by Exchange is to increase diagnostic logging for the Topology component of the MSExchangeDSAccess service to Minimum. If you do not see MSExchangeDSAccess event ID event 2080, you can safely ignore this warning.

To resolve this warning, do the following:

  • Verify that all network connections to the domain controller are functional and support Internet Control Monitoring Protocol (ICMP) traffic.

  • Consider the best practices in the following articles:

    • For information about the LDAP Read Time performance counter and other counters you can use to troubleshoot Active Directory-bound problems, see the "Ruling Out Active Directory-Bound Problems" topic in Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588). This article also includes information about how to improve Active Directory performance.

    • For more information about how to maximize Active Directory performance, see the "Active Directory Integration Tuning" topic in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

    • For information about making sure of high availability for your Active Directory servers, see the sections under Ensuring Reliable Access to Active Directory and Domain Name System in the "System-Level Fault Tolerant Measures" topic of the Exchange 2003 High Availability Guide (http://go.microsoft.com/fwlink/?LinkId=47571).

    • For information about network bandwidth considerations, see the Network Performance section of the "Understanding Exchange Performance" topic in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).


Maximum LDAP search latency has exceeded 100 milliseconds
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-14

The Microsoft Exchange Analyzer tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the LDAP Search Time performance counter of the MSExchangeDSAccess Process performance object to analyze performance data.

The LDAP Search Time performance counter shows the time in milliseconds that it takes a Lightweight Directory Access Protocol (LDAP) search request to be fulfilled. The Exchange Analyzer retrieves a sample every 5 seconds for 5 minutes. The Exchange Analyzer then reports the maximum value for the performance counter during the collection interval. If the maximum value exceeds 100 milliseconds, the Exchange Analyzer displays an error.

High LDAP search latencies can be caused by high remote procedure call (RPC) latencies and by increasing queues. High LDAP search latencies generally indicate one of the following problems:

  • A performance problem with the network connection to the domain controller.

  • Performance problems with the domain controller itself.

Note:
LDAP latencies are generally higher when users connect to domain controllers that are located in different physical sites. However, the recommended maximum latencies stated in this article should generally be followed.

Exchange servers will query out-of-domain global catalog servers every 15 minutes for to keep an up-to-date list of global catalog servers and domain controllers. Because some of these directory servers may be remote, the latencies on these queries may be high. This is acceptable, as long as the requests are infrequent, that is, the rate is less than 0.5 requests a second.

If the domain controller that has logged this error is located in a different physical site, you may be able to safely ignore this error if you can determine that the domain controller that reports this error is not used by the Exchange server. One way to determine whether a domain controller is used by Exchange is to increase diagnostic logging for the Topology component of the MSExchangeDSAccess service to Minimum. If you do not see MSExchangeDSAccess event ID event 2080, you can safely ignore this error.

Important:
For mixed mode environments only, behavior was introduced around the Exchange 2000 SP2 timeframe for certain specific security-related user attributes like tokenGroups and tokengroupsGlobalandUniversal. These were used to determine what security groups a user is a member of and therefore what permissions he or she has to secure resources such as public folders that requires the Exchange server to query a domain controller that is authoritative for the user's home domain. The authoritative domain controller may be in a remote site and queries from a large number of remote homed domain users accessing local public folders could contribute to high RPC latencies.

For more information about this behavior, see the following Exchange Server blog article:

  • Exchange Does Not Always Use Local GCs

    Note:
    Links to blogs are provided to help you find the technical information you need. The content of each blog and its URL are subject to change without notice.

To resolve this error, do the following:

  • Verify that all network connections to the domain controller are functional and support Internet Control Monitoring Protocol (ICMP) traffic.

  • Consider the best practices in the following articles:

    • For information about the LDAP Read Time performance counter and other counters you can use to troubleshoot Active Directory-bound problems, see the "Ruling Out Active Directory-Bound Problems" topic in Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588). This article also includes information about how to improve Active Directory performance.

    • For more information about how to maximize Active Directory performance, see the "Active Directory Integration Tuning" topic in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

    • For information about making sure of high availability for your Active Directory servers, see the sections under Ensuring Reliable Access to Active Directory and Domain Name System in the "System-Level Fault Tolerant Measures" topic of the Exchange 2003 High Availability Guide (http://go.microsoft.com/fwlink/?LinkId=47571).

    • For information about network bandwidth considerations, see the Network Performance section of the "Understanding Exchange Performance" topic in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).


Cannot identify the specified Exchange gateway
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-08-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service for the name (cn) of each directory object that has an object class of msExchExchangeServer to determine whether there is a match for the user-specified Exchange gateway server.

The cn value is a string that contains the short name of the Exchange Server computer.

If the Exchange Server Analyzer cannot find a cn value match for the user-specified Exchange gateway server in the Active Directory, the Exchange Server Analyzer displays an error.

This error indicates that one of the following conditions is true:

  • The user-specified Exchange gateway server does not exist in the local Exchange Server organization.

  • The user-specified Exchange gateway server was incorrectly entered.

To address this error, verify the specified Exchange gateway server was entered correctly and retry the operation.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To verify the server name (cn) value

  1. Using ADSI Edit or a similar tool, locate the server object in Active Directory.

    The CN attribute can be found at:

    Copy Code
    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group,CN=Servers,CN=Server.


Categorizer queue length beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Categorizer Queue Length performance counter of the SMTP Server performance object to analyze performance data.

If the Exchange Server Analyzer determines that the Categorizer Queue Length counter has exceeded the peak value of 10 during the sample time slice, the Exchange Server Analyzer displays an error.

The SMTP Server\Categorizer Queue Length counter indicates the number of messages in the Simple Mail Transfer Protocol (SMTP) Categorizer queue waiting for directory service attribute searches using global catalog servers.

The categorizer performs the following core operations:

  • Resolves and validates all recipients.

  • Determines limits and restrictions for all recipients.

  • Expands distribution lists if that is required.

  • Determines whether the message is for local or remote delivery

This error indicates that there may be problems with server or network performance, Directory Service Access (DSAccess), the Active Directory® directory service, or outages with key servers in the Exchange Server organization. An increase in the Categorizer Queue Length counter may indicate a either a slow response or no response in consulting Active Directory or in handing off messages for local delivery or SMTP. This might cause delayed mail delivery.

To address this error:

  • Verify that sufficient Active Directory resources are available to the Exchange server. This includes both domain controllers and global catalog servers. The recommended practice is to maintain a 4:1 ratio between Exchange server processors and global catalog server processors of similar speed.

  • From Exchange System Manager, verify that all domain controllers listed on the Exchange server's DSAccess tab are functioning correctly. This includes servers listed in the ConfigDC, domain controller, and global catalog server roles.

  • Monitor network performance between the Exchange server and its chosen domain controllers and global catalog servers to determine whether there is a network performance bottleneck.

  • Monitor processor utilization on the Exchange server and also processor utilization of the Inetinfo.exe process. This includes the categorizer component.

  • Verify the health of Exchange-related user and group objects by using the e2kdsinteg configuration object from the ConfigDSInteg tool in Microsoft Exchange Server Deployment Tools (http://go.microsoft.com/fwlink/?LinkId=21231). Objects that have malformed addresses or incomplete information can cause delays in recipient determination and delay categorization.

For More Information

For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


CDO.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


CimWin32.dll update available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-09-19

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of Microsoft Windows® running on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates that the Exchange Server computer is running on Microsoft Windows NT® Server 4.0. A value of 5.0 indicates that the Exchange Server computer is running Windows 2000 Server and a value of 5.2 indicates the Exchange Server computer is running Windows Server™ 2003.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows Management Instrumentation (WMI) class to determine the value that is set for the Version key of the Cimwin32.dll file.

The Exchange Server Analyzer displays a best practice message if the following conditions are true:

  • The Exchange Server computer is running on Windows 2000 Server.

  • The value for the Version key corresponds to a specific version of the Cimwin32.dll file.

There is an update to the Cimwin32.dll file that will allow the Exchange Server Analyzer to work more efficiently.

To address this issue, review and apply the recommendations in the Microsoft Knowledge Base article 820608, "CIM_DataFile class returns an incorrect or null value for files that are larger than 2 GB in Windows 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=820608).


Client Applications Impact on Server Performance
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that you have specific types of client computers or client-side applications that may be increasing server load in your Exchange organization.

Many applications can increase the load on the server. If the load has increased, you should investigate what applications users are running and decide whether you want to restrict users from running certain applications. Some applications that access e-mail (third-party applications or Microsoft Office Outlook® plug-ins) may increase the load on the server. If the server experiences an increase in remote procedure call (RPC) latencies or an increase in load, it is recommended that you investigate the source.

You can use the Exchange Server User Monitor (ExMon) to identify users who are experiencing high latencies or are increasing the load on the server. To download ExMon, see the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=54983).

Procedure

To correct this warning

  • Use ExMon to identify which users causing an increase in server load. After the users are identified, contact the users and determine whether the following applications are causing the additional load:

    • Third-party client computer plug-ins

    • Desktop synchronization devices, such as Exchange ActiveSync® or Blackberry

    • Other MAPI applications, such as desktop search engines

    If these applications are not required for business purposes, or if the applications have a published hotfix, turn off the applications or update them to reduce the load to an appropriate level.

  • Configure the most operationally expensive client computers (especially those with long latencies on Restrict, SetColumns or FindRow operations) to use Cached Exchange Mode. Cached Exchange Mode isolates the server from most of the excess RPC traffic.

    Additionally, encourage users who have many items in their folders to archive older data to a .pst file. Or, if these users want to keep their data on the server, encourage them to move the older items into newly created folders.

    Lastly, it is recommended that you keep items in the Inbox, Calendar, Sent Items, Contacts and Deleted Items folders under 5,000.
Note:
Some applications can significantly increase server load without issuing a large number of MAPI operations. This is because some operations are more expensive than others. It may take only a small increase in the number of costly operations to noticeably impact server performance. In ExMon, these users are reported as having a relatively high CPU impact, without necessarily having issued a large number of MAPI operations.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

  • For more information about troubleshooting Outlook client performance issues, see "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)

  • For more information about desktop search software, see the Microsoft Knowledge Base article 905184, "Exchange 2000 Server and Exchange Server 2003 performance may be affected when desktop search engine software is running on Outlook or other MAPI client computers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905184).


Cluster TEMP path is invalid or non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

On a non-clustered Exchange Server computer, the Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for the TEMP environment variable:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\TEMP

When the Exchange Server Analyzer is run against an Exchange Virtual Server (EVS) in a Microsoft Windows® server cluster, the Exchange Server Analyzer does not read the HKLM registry hive. Instead, the Exchange Server Analyzer reads the following registry entry:

HKEY_USERS\< Cluster service account SID >\Environment\TEMP

If the Exchange Server Analyzer finds that the TEMP environment variable is not set to a path available on the current system, a warning is displayed. If this path is invalid, your organization may experience mail delivery failure. By default, the Exchange Server Analyzer in its default configuration will expect to find this path set to %USERPROFILE%\Local Settings\Temp. Although this path can be modified to point to other locations, after a hotfix or update is applied and the cluster node is restarted, the system may expect to find the path set to the default.

The TEMP environment variable is used to designate the folder in the file system that should be used by applications that require temporary workspace. TEMP is typically used by applications, such as Exchange Server. The path for each variable is typically relative to the context of the application. For example, the Microsoft Exchange Information Store service processes use the TEMP folder as temporary storage during various operations, such as message conversion and mailbox move operations.

To correct this warning

  1. Log on to a node in the cluster as the Cluster service account.

  2. Right-click My Computer and select Properties.

  3. Select Advanced.

  4. Click Environment Variables.

  5. In the User variables for <account name> area, select TEMP and then click Edit.

  6. In the Variable value field, enter the default path for the TEMP environment variable and then click OK.

  7. Click OK to close the Environment Variables dialog box and then click OK again to close the System Properties dialog box.

  8. Restart the node to apply the change.

  9. Repeat steps 1 through 8 for each node in the cluster that has the non-default setting.


Consider multiple offline address book replicas
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-08-14

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_PublicFolder Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine the number of entries in the ReplicaList key. The number of entries represents the number of offline address book replicas that are present in each administrative group.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the number of public folder database objects that have the legacyExchangeDN attribute set. The number of objects that have this attribute set represents the number of public folder stores that exist in the organization.

If the Exchange Server Analyzer determines that only one replica of an offline address book exists in an Exchange organization that has multiple public folder stores, the Exchange Server Analyzer displays a best practice message.

For availability and performance, we recommend that you consider deploying multiple replicas of each offline address book. Sometimes, multiple offline address book replicas can increase performance and resilience. In large Exchange organizations, a single replica of an offline address book may become overloaded. In all Exchange organizations, a single replica of an offline address book is a single point of failure.

Although multiple replicas means additional replication traffic over the network, it is recommended that multiple replicas be used. At a minimum, there should be two replicas of each offline address book.

To add replicas of an offline address book to an Exchange organization

  1. Open Exchange System Manager

  2. Expand Folders, right-click Public Folders, and select View System Folders. Note If the Folders node is not visible, expand Administrative Groups, and then expand the administrative group that contains the system folders that you want to view. Then right-click Public Folders and select View System Folders.

  3. Expand the OFFLINE ADDRESS BOOK container and then right-click the Offline Address Book you want to add a replica for by selecting Properties from the resultant drop-down list.

  4. Select the Replication tab and then clicklick Add to select the Public Store that you want to add the replica to. Click OK to finish.

  5. Repeat steps 3 and 4 for all child objects under the Offline Address Book container that you want a replica for. This repetition will make sure that all formats supported are included in the replica. that is, specifically Add the child objects OAB Version 2, OAB Version 3a, and so on.

For more information about how to manage and configure offline address books, see the following Microsoft Exchange Server TechCenter articles:

  • "Offline Address Book - Things to Consider" (http://go.microsoft.com/fwlink/?LinkId=57581)

  • "Working with Exchange Server 2003 Stores" (http://go.microsoft.com/fwlink/?LinkId=47595).

  • The "Offline Address Book Best Practices Guide" (http://go.microsoft.com/fwlink/?LinkId=47583).

  • "OAB Version 4 in Exchange Server 2003 Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=53097).

  • "How Outlook 2003 SP2 and Exchange Server 2003 SP2 OAB Version 4 Work Together" (http://go.microsoft.com/fwlink/?linkid=53099).


Connection to Recipient Update Service domain controller
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-05-18

The Microsoft® Exchange Server Analyzer Tool opens a TCP socket connection to port 389 on each domain controller. This connection is made by using a custom object processor that returns a specific string if the connection is successful.

If the Exchange Server Analyzer does not receive 389 Available as part of the returned string, a warning is displayed.

This warning indicates that the domain controller did not respond to a connection attempt on TCP port 389. TCP port 389 is the default port for Lightweight Directory Access Protocol (LDAP) communications. If you receive this warning, any of the following conditions may exist:

  • There may be connectivity issues between the Exchange Server Analyzer and the domain controller.

  • The server may be down.

  • The server may have been decommissioned.

There are many reasons why LDAP requests may not be correctly serviced by a domain controller when the Exchange Server Analyzer queries it.

To correct this warning

  1. Verify that the account running the Exchange Server Analyzer is authorized to query the domain controller. You must have User level permissions in the domain where the domain controller is running. You can find more information about permissions that are required to run the Exchange Server Analyzer in the Help file included with the Exchange Server Analyzer. To open the Exchange Server Analyzer Help file, in the Exchange Server Analyzer, click Help, and then click Microsoft Exchange Server Analyzer Tool Help.

  2. Verify that there are no firewalls or port restrictions between the computer that is running the Exchange Server Analyzer and the domain controller that did not respond.

  3. Verify that the domain controller is connected to the network and functioning correctly.

  4. Verify that the server has not been decommissioned and is still listed as an available domain controller to Exchange Server.

For more information, see the following Microsoft Knowledge Base articles:

  • 319065, "How to work with the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319065)

  • 816103, "HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816103)


Content Update Available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-06-21

For more information, see the Exchange Server 2007 Documentation Download page.


Content indexing is enabled for this public folder store but updates are not scheduled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchCIAvailable attribute of each public folder store. The value of this attribute indicates whether content indexing has been enabled for the public folder store. A value of True indicates that a content index exists for a public folder store and that the Exchange System Manager setting This index is currently available for searching by clients is selected. A value of False indicates that a content index exists for a public folder store, but the Exchange System Manager setting This index is currently available for searching by clients is cleared. A value of <Not Set> indicates that a content index does not exist for the public folder store.

The Exchange Server Analyzer also queries Active Directory to determine the value for the msExchCIRebuildSchedule attribute of each public folder store. The value of this attribute indicates the rebuild schedule settings for the content index. This attribute is stored as an octet string with 82 pairs of hexadecimal values.

If the Exchange Server Analyzer finds the value of the msExchCIAvailable attribute set to True, but the octet string value for the msExchCIRebuildSchedule attribute translates to Never run, a warning is displayed.

The recommended best practice for setting the update interval is to schedule incremental updates at least once a day. You may want to schedule more frequent updates because the index is only as current as the last time it was populated. Indexes that are not regularly updated can produce inaccurate and out-of-date results.

You should also consider the time that is required to complete an incremental population. For example, a typical schedule sets incremental updates at the beginning of each hour. However, if the update lasts more than an hour, the next incremental population begins at the start of the following hour.

Generally, if the public folder store is 6 gigabyes (GB) or smaller, you can perform incremental updates hourly. If the store is larger than 6 GB, or the server has high memory usage, you may want to update the index less frequently.

To set the full-text indexing Update Interval on a specific public folder store

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, expand your server, expand your storage group, right-click your public folder store, and then click Properties. If the Administrative Groups node is not displayed in Exchange System Manager, expand Servers, right-click your server, and then click Properties.

  3. On the Full-Text Indexing tab, select an option other than Never run.

  4. If you choose Use custom schedule, click Customize, set your own custom schedule, and then click OK.

  5. Click Apply.

For more information about full-text indexing for Exchange Server, see Best Practices for Deploying Full-Text Indexing (http://go.microsoft.com/fwlink/?linkid=5223).


Content indexing is enabled for this mailbox store but updates are not scheduled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchCIAvailable attribute of each mailbox store. The value of this attribute indicates whether content indexing has been enabled for the mailbox store. A value of TRUE indicates that a content index exists for a mailbox store and that the Exchange System Manager setting "This index is currently available for searching by clients" is selected. A value of FALSE indicates that a content index exists for a mailbox store, but the Exchange System Manager setting "This index is currently available for searching by clients" is cleared. A value of <Not Set> indicates that a content index does not exist for the mailbox store.

The Exchange Server Analyzer also queries Active Directory to determine the value for the msExchCIRebuildSchedule attribute of each mailbox store. The value of this attribute indicates the rebuild schedule settings for the content index. This attribute is stored as an octet string with 82 pairs of hexadecimal values.

If the Exchange Server Analyzer finds the value of the msExchCIAvailable attribute set to TRUE, but the octet string value for the msExchCIRebuildSchedule attribute translates to "Never run", a warning is displayed.

The recommended best practice for setting the update interval is to schedule incremental updates at least once a day. You may want to schedule more frequent updates because the index is only as current as the last time it was populated. Indexes that are not regularly updated can produce inaccurate and out-of-date results.

You should also consider the time it takes to complete an incremental population. For example, a typical schedule sets incremental updates at the beginning of each hour. However, if the update lasts more than an hour, the next incremental population begins at the start of the following hour.

Generally, if the mailbox store is 6 gigabytes (GB) or smaller, you can perform incremental updates hourly. If the store is larger than 6 GB, or the server has high memory usage, you may want to update the index less frequently.

To set the full-text indexing Update Interval on a particular mailbox store

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, expand your server, expand your storage group, right-click your mailbox store, and then click Properties. If the Administrative Groups node is not displayed in Exchange System Manager, expand Servers, right-click your server, and then click Properties.

  3. On the Full-Text Indexing tab, choose an option other than Never run.

  4. If you choose Use custom schedule, click Customize, set your own custom schedule, and then click OK.

  5. Click Apply.

For more information about configuring and troubleshooting full-text indexing in Exchange, see the Microsoft Knowledge Base articles, 822932, "HOW TO: Configure Full-Text Indexing on Mailbox Stores in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkID=3052&kbid=822932) and 319436, "How to configure full-text indexing on mailbox stores in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319436).

For more information about full-text indexing for Exchange Server, see Best Practices for Deploying Full-Text Indexing (http://go.microsoft.com/fwlink/?LinkId=5223).


CQPCIDRV.SYS driver update available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-08-14

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of Microsoft Windows® running on the server that is running Exchange Server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates that the Exchange server is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates that the Exchange server is running Windows 2000 Server. A value of 5.2 indicates the Exchange Server computer is running Windows Server™ 2003.

The Exchange Server Analyzer also examines the Win32_Processor Windows Management Instrumentation (WMI) class to determine the value for the DataWidth key.

A DataWidth key value of 32 indicates the server is running a 32-bit version of the Windows operating system whereas a DataWidth key value of 64 indicates the server is running a 64-bit version of the Windows operating system.

Finally, the Exchange Server Analyzer queries the CIM_Datafile WMI class to determine the value of the Version key for a file that is named CpqCiDrv.sys.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The Exchange server is running Windows Server 2003.

  • The Exchange server is running a 64-bit version of the Windows operating system.

  • The version of the HP Integrated Lights-Out Management Interface driver, CPQCIDRV.sys, is earlier than 1.8.

This error indicates that the version of CpqCiDrv.sys installed on the server may cause kernel memory allocation errors.

To resolve this problem, follow the guidance of the vendor in Document ID: c00688313 (http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c00688313).

Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.


CrashOnAuditFail in effect
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the CrashOnAuditFail parameter has been set:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\CrashOnAuditFail

If the Exchange Server Analyzer finds the value for CrashOnAuditFail is equal to 2, an error is displayed.

The purpose of the CrashonAuditFail registry key is to configure a server so that the end users are not permitted access to the computer when the security logs reach the configured size limit. Disallowing access to the computer ensures that audit information that would otherwise be logged is not missed.

When enabled, the CrashonAuditFail registry key is set to a value of 1. However, when the Security log limit is reached, the server will set the registry key to a value of 2, which in turn, stops processing on the server. Sometimes, this process will cause a complete failure, or STOP 0xC0000244, also known as a Stop error. At a minimum, users will not be able to access server resources and performance will be greatly diminished. Additionally, when the server is in this state, only users with administrator permissions can access the computer.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\LSA.

  3. Delete the value called CrashOnAuditFail (you must delete the entire value, not only the value data).

  4. Copy the security event logs to a separate location. By default, the security event logs (SecEvent.Evt) are located at %SystemRoot%\System32\Config, where %SystemRoot% is the path to where the Microsoft Windows® operating system is installed.

  5. Open Event Viewer, right-click Security, and then click Properties.

  6. On the Security Properties page, click Clear Log. When prompted to save the log, click Yes, and then specify a location to save the log file.

    Note On the Security Properties page, you can also increase the log size by editing the Maximum log size field, and then clicking Apply.

  7. Restart the server.

  8. Verify that users can access server resources by logging on to an Exchange mailbox.

  9. Re-create the CrashonAuditFail registry key, and set the value data to 1.

  10. Restart the server so the CrashonAuditFail settings take effect.

  11. Periodically clear and save the server's Security Logs, so that the maximum log size is not exceeded. For more information, see the Microsoft Knowledge Base article 312571, "The event log stops logging events before reaching the maximum log size" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=312571).

Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about recovering from CrashOnAuditFail failures, see the following Knowledge Base articles:

  • 232564, "STOP 0xC0000244 when security log full" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232564)

  • 829082, "You receive a "Stop error 0xC0000244 {Audit Failed}" error message when the crashonauditfail registry key is set to 1 on a Windows Server 2003-based computer" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=829082)


Custom public folder referral list
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchFolderAffinityCustom attribute contains any Exchange server names. If the Exchange Server Analyzer finds that the msExchFolderAffinityCustom attribute lists server names, the Exchange Server Analyzer displays a non-default configuration message.

By default, Exchange Server 2003 uses routing groups to determine public folder referrals.

The default for Exchange Server 2007 is to use Active Directory directory service inter-site costs to determine routing for public folder referrals.

If the msExchFolderAffinityCustom attribute lists server names, custom referrals have been configured on the Exchange server. The msExchFolderAffinityCustom attribute is a per-server attribute.

As a general best practice, it is recommended that you use the default behavior for public folder referrals. However, you may have to create a custom referral list. The non-default configuration message is an informational message. No action is required.

To revert to the default configuration in Exchange Server 2003

  1. Open Exchange System Manager.

  2. Locate the server object where custom public folder referrals are configured. The Exchange server name where custom public folder referrals are configured is specified in the Exchange Server Analyzer message.

  3. Right-click Server_Name, and then click Properties.

  4. On the Public Folder Referrals tab, select Use Routing Groups in the Public Folder referral options drop-down box.

  5. Click Apply, and then click OK.
To revert to the default configuration in Exchange Server 2007

  1. The following code is an example of the Exchange Management Shell Set-PublicFolderDatabase command that disables the use of the PublicFolderRefferalServerList for the 'MyServer\First Storage Group\Public Folder Database' public folder database.
Copy Code
Set-PublicFolderDatabase -Identity "MyServer\First Storage Group\Public Folder Database" -UseCustomReferralServerList $false

The UseCustomReferralServerList parameter specifies whether to use the server costs specified by the PublicFolderReferralServerList parameter. If set to $true, the server uses the PublicFolderReferralServerList parameter costs to make public folder referrals. If set to $false, the server uses Active Directory inter-site costs to make public folder referrals.

Note:
Setting this parameter to $false also clears the PublicFolderReferralServerList parameter.

For more information about the Exchange Management Shell Set-PublicFolderDatabase command, see the Exchange Server 2007 product documentation technical reference "Set-PublicFolderDatabase" (http://go.microsoft.com/fwlink/?LinkId=80813).

For more information about public folder replication, see Best Practices for Exchange Server Public Folders (http://go.microsoft.com/fwlink/?LinkId=46437).


Database performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Log Record Stalls/sec performance counter of the Database performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions is true:

  • The Database performance object is disabled.

  • The Database performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry.

The following procedure explains how to fix the first two conditions. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the Database performance object is enabled.

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at Exctrlst.exe: Extensible Performance Counter List (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300965, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall Exchange Server in the Repair mode, and then apply the latest Exchange Server service packs.


DAVEX.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


DHCP Client service is not running
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Dynamic Host Configuration Protocol (DHCP) Client service. If the Exchange Server Analyzer finds that the value of the Started key for the DHCP Client service on an Exchange server is set to False, the Exchange Server Analyzer displays a warning.

This warning indicates that the DHCP Client service is not running. The DHCP Client service performs dynamic Domain Name System (DNS) updates. If the DHCP Client service is not running, dynamic update failures will occur. If an Exchange server is not running this service, the most common problem will be mail flow problems.

To correct this problem, set the DHCP Client Service to automatic startup, and then start the service.

Note:
The DHCP Client service must be running, even if the server is configured to use static IP addresses rather than DHCP.
To enable the DHCP Client service

  1. Open the Services snap-in.

  2. In the details pane, right-click the DHCP Client Service, and then click Properties.

  3. On the General tab, click the Startup type, and select Automatic.

  4. Click Start, and then click OK.

For more information about the DHCP Client service, see Microsoft Knowledge Base article 264539, "Dynamic DNS updates do not work if the DHCP client service stops" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264539).

For more information about the DNS dynamic update protocol, see Microsoft Knowledge Base article 816592, "How to configure DNS dynamic updates in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592).


Dr. Watson not enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the value for the following registry key to determine whether Dr. Watson is configured as the default application debugger in the Microsoft Windows® operating system:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger

If the Exchange Server Analyzer finds that the value for Debugger does not start with drwtsn32, a non-default configuration message is displayed.

This message indicates that Dr. Watson is not enabled. Starting with Windows NT®, an application-mode debugger referred to as Dr. Watson has been included with Windows. When an application crashes, the fault can be trapped by Dr. Watson, which logs a variety of information, such as platform information, a list of running processes, the identification of the faulting process, a memory dump of the faulting process, one or more call stacks, and a pointer to the fault itself. Most of the information gathered is low-level debugging information that is intended for the developer of the faulting process.

The recommended best practice is to run Windows with an application-mode debugger enabled. If Dr. Watson is not enabled and you are not using an alternative application debugger, it is recommended that you enable Dr. Watson using the following procedure.

To enable Dr. Watson

  1. Open a Command Prompt window.

  2. At the command prompt, type drwtsn32 -i.

For more information about enabling and disabling Dr. Watson, see the Microsoft Knowledge Base article 188296, "How to Disable Dr. Watson for Windows" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=188296).


DSA Computer name mismatch
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the setting for the DSA Computer value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the name attribute for each Exchange server object.

Finally, the Exchange Server Analyzer queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Cluster service (ClusSvc). A value of True indicates the Cluster service is started and a value of False indicates the Cluster service is not running.

If the Exchange Server Analyzer finds that the value for the DSA Computer key does not match the value for the server object's name attribute in Active Directory for any Exchange Server computer that is not running in a Windows Server cluster, an error is displayed.

To correct this error, you must edit the DSA Computer registry key to match the value of the name attribute in Active Directory.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to edit the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, double-click DSA Computer, enter the correct name for this computer, and then click OK.

  4. Close the registry editor and restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


DSACCESS.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


The DSAccess configuration cache is full
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-05-24

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_MSExchangeDSAccess_MSExchangeDSAccessCaches Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for TotalEntriesMemoryConfigurationData. If the Exchange Server Analyzer Tool finds that the value for TotalEntriesMemoryConfigurationData equals the total size of the Directory Service Access (DSAccess) configuration cache (MaxMemoryConfig), a warning is displayed.

DSAccess is an internal component in Exchange 2000 Server and Exchange Server 2003 that controls how all Exchange components access the Active Directory® directory service. The primary function of DSAccess is to maintain information about various directory-related events and operations. For example, DSAccess discovers the Active Directory topology and detects if domain controllers and global catalog servers are available and responding to queries. In addition, all directory queries made by internal Exchange components such as the Microsoft Exchange store are routed through DSAccess, such as recipient resolution, configuration setting lookups, and others. As part of its job, DSAccess maintains an in-memory cache of the results of some of these queries so that if the same information is requested twice, it can be retrieved from the DSAccess cache instead of through another Lightweight Directory Access Protocol (LDAP) query against Active Directory.

Because the default setting maximum size for the DSAccess configuration cache was reduced from a value of 25 megabytes (MB) in Exchange 2000 Server to a value of 5 MB in Exchange Server 2003, this warning message can be generated on either version of Exchange. Regardless of what version of Exchange generates this warning message, the problem should be corrected as soon as possible.

The MaxMemoryConfig value is often used in conjunction with the MaxMemoryUser value, which controls the maximum amount of memory that user data objects in the DSAccess cache are allowed to consume. If you edit or remove the MaxMemoryConfig value as described in the procedure that follows, you should similarly edit or remove the MaxMemoryUser value as described in DSAccess user cache value is non-default.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. Increase the value for MaxMemoryConfig. If the Instance0 key or the MaxMemoryConfig DWORD value does not exist, you can manually create it. The value data for the MaxMemoryConfig registry entry is in kilobytes (KB); therefore a decimal entry of 15000 equals 15 MB. If the value exists, increase it by 10 percent. If the value does not exist, an initial starting point of 10 MB is recommended.

  4. Close the registry editor and then restart Microsoft Exchange System Attendant for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


DSAccess configuration cache value is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine if the size of the Directory Service Access (DSAccess) configuration object cache has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0\MaxMemoryConfig

If the Exchange Server Analyzer finds MaxMemoryConfig to be present and configured, a non-default configuration message is displayed.

MaxMemoryConfig is an Exchange 2000 Server registry parameter that typically is no longer needed in Exchange Server 2003. MaxMemoryConfig controls the maximum amount of memory that configuration data objects in the DSAccess configuration cache are allowed to consume.DSAccess is an internal component in Exchange 2000 Server and Exchange Server 2003 that controls how all Exchange components access the Active Directory® directory service. The primary function of DSAccess is to maintain information about various directory-related events and operations. For example, DSAccess discovers the Active Directory topology and detects if domain controllers and global catalog servers are available and responding to queries. In addition, all directory queries made by internal Exchange components such as the Microsoft Exchange store are routed through DSAccess, such as recipient resolution, configuration setting lookups, and others. As part of its job, DSAccess maintains an in-memory cache of the results of some of these queries so that if the same information is requested twice, it can be retrieved from the DSAccess cache instead of through another Lightweight Directory Access Protocol (LDAP) query against Active Directory.

In Exchange 2000 Server, the configuration cache was initially set at 25 megabytes (MB) in size. On most Exchange servers this setting was much larger than it needed to be. The MaxMemoryConfig setting was used to reclaim and reallocate some of the memory used by the DSAccess configuration cache. Typically it was configured for 5 MB. Based on internal testing and customer feedback, Microsoft has found 3 MB to be the optimal size, which Exchange Server 2003 uses as an out-of-the-box setting. When upgrading from Exchange 2000 Server to Exchange Server 2003, any manual setting will be preserved. If this Exchange server was upgraded from Exchange 2000 Server to Exchange Server 2003, you should make sure the value for MaxMemoryConfig is no more than 5 MB.

The MaxMemoryConfig value is often used in conjunction with the MaxMemoryUser value, which controls the maximum amount of memory that user data objects in the DSAccess cache are allowed to consume. If you edit or remove the MaxMemoryConfig value as described in the procedure that follows, you should similarly edit or remove the MaxMemoryUser value as described in DSAccess user cache value is non-default.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To use the MaxMemoryConfig registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. Examine or edit the value for MaxMemoryConfig.
Note:
The value for this registry entry is in kilobytes (KB). If the value is set to 3000 or less, you should delete MaxMemoryConfig and restart the Microsoft Exchange System Attendant service to default to the Exchange Server 2003 setting.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about DSAccess, see the Knowledge Base article 250570, "Directory Service Server Detection and DSAccess Usage" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570).


DSAccess DisableNetLogonCheck registry parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Directory Service Access (DSAccess) has been configured to use a non-default ping protocol:

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAccess\DisableNetLogonCheck

If the Exchange Server Analyzer finds DisableNetLogonCheck is present and configured with a value greater than 0, a non-default configuration message is displayed.

After DSAccess discovers the Active Directory® directory service topology, it determines whether the discovered domain controllers and global catalog servers are suited for use. During initial discovery and ongoing rediscovery, DSAccess determines server suitability by running a series of tests. One test sends a remote procedure call (RPC) to the directory server to test its general suitability. In a perimeter network scenario where RPC traffic is typically not allowed, the DSAccess RPC request fails. However, DSAccess continues to issue RPCs until it fails, which can take a long time. Such repeated checks can adversely affect the performance of computers that are running Exchange Server. For this reason, administrators frequently add the DisableNetLogonCheck registry key and configure it with a value of 1 on Exchange servers located on a perimeter network.

If the Exchange server that generated the non-default configuration message is in a perimeter network where RPC is disabled, or if you have determined that you do not want DSAccess to perform this suitability test, you should set the DisableNetLogonCheck key to 1. Otherwise, you should delete the DisableNetLogonCheck key.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To use the DisableNetLogonCheck key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. Double-click the DisableNetLogonCheck key, and set the DWORD value to 1.

  4. Close the registry editor. You do not have to restart any services to make the change take effect.

To delete the DisableNetLogonCheck key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. Delete the value called DisableNetLogonCheck.

  4. Close the registry editor. You do not have to restart any services to make the change take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the DisableNetLogonCheck registry key, see the Knowledge Base article 320228, "XGEN: The DisableNetLogonCheck Registry Value and How to Use It" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320228).


DSAccess has been hard-coded
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_DSAccessDC Microsoft Windows® Management Instrumentation (WMI) class in the ROOT\MicrosoftExchangeV2 namespace to determine the value for the ConfigurationType key. If the value for this key is 0, a non-default configuration message is displayed.

The ConfigurationType property indicates whether the instance describes a domain controller that was detected automatically, or one that was specified manually. Out-of-the-box, the Directory Service Access (DSAccess) component in Exchange Server dynamically detects the Active Directory® directory service topology and locates domain controllers and global catalog servers automatically. On computers that are running Exchange Server 2000 Service Pack 2 or later versions, or Exchange Server 2003, Exchange System Manager includes the ability to enter a hard-coded list of Active Directory servers for use by DSAccess.

Unless the hard-coding of directory servers for DSAccess was performed for a specific reason, you should remove the list of servers and revert to the default setting of auto-discovery. It is recommended that you use automatic topology discovery to take advantage of global catalog failover.

To revert to the default setting

  1. Click Start, click Programs, click Microsoft Exchange, and then click System Manager.

  2. Expand Administrative Groups, <AdminGroupName>, Servers, <ServerName> (where AdminGroupName is the name of the administrative group that contains the Exchange server, and ServerName is the name of the Exchange server that you want to configure).

  3. Right-click the Exchange server, and then click Properties.

  4. Click the Directory Access tab.

  5. In the Show list box, select Configuration Domain Controller.

  6. Select the Automatically discover servers check box.

  7. Click Yes when the following Exchange System Manager prompt appears: "The manually selected server(s) that have been specified will be cleared. Do you want to continue?"

  8. In the Show list box, select Domain Controllers.

  9. Select the Automatically discover servers check box.

  10. Click Yes when the following Exchange System Manager prompt appears: "The manually selected server(s) that have been specified will be cleared. Do you want to continue?"

  11. In the Show list box, select Global Catalog Servers.

  12. Select the Automatically discover servers check box.

  13. Click Yes when the following Exchange System Manager prompt appears: "The manually selected server(s) that have been specified will be cleared. Do you want to continue?"

  14. Click OK to save the changes.

For more information about DSAccess and directory services detection, see the Microsoft Knowledge Base article 250570, "Directory Service Server Detection and DSAccess Usage" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570).


DSAccess is not using port 389 for LDAP domain controller requests
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_DSAccessDC Microsoft Windows® Management Instrumentation (WMI) class in the ROOT\MicrosoftExchangeV2 namespace to determine the value for the LDAPPort key. If the value for the LDAPPort key is not set to 389, a non-default configuration message is displayed.

The LDAPPort key represents the TCP port number on which the domain controller listens for Lightweight Directory Access Protocol (LDAP) requests. Administrators can use LDAP over Secure Sockets Layer (SSL) on TCP port 636 (domain controller) or TCP port 3269 (global catalog) as a security measure.

By default, a global catalog server listens on port 3268 for LDAP communications. However, if an Enterprise certification authority is installed, all domain controllers automatically request a certificate and can support LDAP over SSL communications on TCP port 636. If the domain controller is also configured as a global catalog, it can also support LDAP over SSL communications on TCP port 3269.

To correct this error

  • There is no action required. The Exchange Server Analyzer is identifying a non-default configuration.

For more information about DSAccess and LDAP ports, see the following Microsoft Knowledge Base articles:

  • 247078, "How to Enable Secure Sockets Layer (SSL) Communication over LDAP for Windows 2000 Domain Controllers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=247078)

  • 246228, "XGEN: DSAccess Profiles" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246228)


DSAccess is not using port 3268 for LDAP global catalog requests
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_DSAccessDC Microsoft Windows® Management Instrumentation (WMI) class in the ROOT\MicrosoftExchangeV2 name space to determine the value for the LDAPPort key. If the value for the LDAPPort key is not set to 3268, a non-default configuration message is displayed.

The LDAPPort key represents the TCP port number on which the domain controller listens for Lightweight Directory Access Protocol (LDAP) requests. Administrators can use LDAP over Secure Sockets Layer (SSL) on TCP port 636 (domain controller) or TCP port 3269 (global catalog) as a security measure.

By default, a global catalog server listens on port 3268 for LDAP communications. However, if an Enterprise certification authority is installed, all domain controllers automatically request a certificate and can support LDAP over SSL communications on TCP port 636. If the domain controller is also configured as a global catalog, it can also support LDAP over SSL communications on TCP port 3269.

For more information about DSAccess and LDAP ports, see the following Microsoft Knowledge Base articles:

  • 247078, "How to Enable Secure Sockets Layer (SSL) Communication over LDAP for Windows 2000 Domain Controllers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=247078)

  • 246228, "XGEN: DSAccess Profiles" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246228)


DSAccess LdapKeepAliveSecs registry parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Directory Service Access (DSAccess) has been configured to use the Lightweight Directory Access Protocol (LDAP) Microsoft Windows® operating system implementation (wLDAP) protocol:

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAccess\ LdapKeepAliveSecs

If the Exchange Server Analyzer finds that LdapKeepAliveSecs is present and configured with a value of 0, a non-default configuration message is displayed.

After DSAccess discovers the Active Directory® directory service topology, it determines whether the discovered list of working domain controllers and global catalog servers is suited for use. During initial discovery and ongoing rediscovery, DSAccess determines server suitability by running a series of tests. By default, one of the suitability tests uses the Internet Control Message Protocol (ICMP) to ping domain controllers to verify that the servers are available.

Not all connections in your network may support ICMP. A specific example of this situation is in a perimeter network where ICMP connectivity between the Exchange server and domain controllers is not permitted. For these cases, setting the LdapKeepAliveSecs registry parameter to 0 will force DSAccess to use the Windows implementation of LDAP (wLDAP) for suitability tests.

If the Exchange server that generated the non-default configuration message is in a perimeter network where remote procedure call (RPC) is disabled or in a network where ICMP is not allowed, you should keep the LdapKeepAliveSecs key configured as it is. Otherwise, you should delete the key.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To delete the LdapKeepAliveSecs key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. Delete the value called LdapKeepAliveSecs.

  4. Close the registry editor. You do not have to restart any services to make the change take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the LdapKeepAliveSecs registry key, see the Knowledge Base article 320529, "XADM: Using DSAccess in a Perimeter Network Firewall Scenario Requires a Registry Key Setting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320529).


DSAccess LdapKeepAliveSecs registry parameter is set to non-supported value
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Directory Service Access (DSAccess) has been configured to use the Lightweight Directory Access Protocol (LDAP) Microsoft Windows® operating system implementation (wLDAP) protocol:

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAccess\ LdapKeepAliveSecs

If the Exchange Server Analyzer finds that LdapKeepAliveSecs is present and configured with a value other than 0, a warning is displayed.

After DSAccess discovers the Active Directory® directory service topology, it determines whether the discovered list of working domain controllers and global catalog servers is suited for use. During initial discovery and ongoing rediscovery, DSAccess determines server suitability by running a series of tests. By default, one of the suitability tests uses the Internet Control Message Protocol (ICMP) to ping domain controllers to verify that the servers are available.

Not all connections in your network may support ICMP. A specific example of this situation is in a perimeter network where ICMP connectivity between the Exchange server and domain controllers is not permitted. For these cases, setting the LdapKeepAliveSecs registry parameter to 0 will force DSAccess to use wLDAP for suitability tests.

If the Exchange server that generated this warning is in a perimeter network where remote procedure call (RPC) is disabled or in a network where ICMP is not allowed, set the LdapKeepAliveSecs key to 0. Otherwise, you should delete the key. Any value that is not zero is not a supported value for this registry key.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To modify the LdapKeepAliveSecs key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. Double-click the LdapKeepAliveSecs key, and set the DWORD value to 0 (zero).

  4. Close the registry editor. You do not have to restart any services to make the change take effect.

To delete the LdapKeepAliveSecs key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. Delete the value called LdapKeepAliveSecs.

  4. Close the registry editor. You do not have to restart any services to make the change take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the LdapKeepAliveSecs registry key, see the Knowledge Base article 320529, "XADM: Using DSAccess in a Perimeter Network Firewall Scenario Requires a Registry Key Setting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320529).


DSAccess PreloadBaseDNs registry parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the search preloading functionality of Directory Service Access (DSAccess) has been changed from its default configuration:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\PreloadBaseDNs

The default value data for PreloadBaseDNs is:

'"'

'"'

'"'

'"'

'"'

If the Exchange Server Analyzer finds that the value for PreloadBaseDNs has been modified from these default values, a warning message is displayed. The Exchange Server Analyzer reports this configuration because it is a setting that should only be changed after consultation with Microsoft Product Support Services.

The DSAccess cache resides on the Exchange server and collects configuration and user records that are retrieved from the Active Directory® directory service. Records in the DSAccess cache are accessed by using an object's distinguished name, globally unique identifier (GUID), or a key constructed from the scope, BaseDN, and the search filter used to find the object in Active Directory. Subsequent accesses that use the same distinguished name, GUID, or key find the record in the cache. Therefore, unnecessary load on Active Directory is prevented for identical searches. However, DSAccess does not prevent load on Active Directory when the search filter is different from the search filter that is contained in the cache, even though DSAccess requests the same attribute set for the user object.

Search preloading is a means of avoiding the multiple Active Directory search problem that can occur when various search filters are issued on the same user object. Search preloading works by the previously mentioned key construction where a search entry is constructed by the scope, BaseDN, and the search filter.

For more information about configuring DSAccess search preloading, see the Microsoft Knowledge Base article 250572, "XCON: Preloading and the DSAccess Cache" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250572).


DSAccess PreloadFilters registry parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the search preloading functionality of Directory Service Access (DSAccess) has been changed from its default configuration:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\PreloadFilters

The default value data for PreloadFilters is:

(&(|(msExchMasterAccountSID=%)(objectSid=%))(!(objectClass=foreignSecurityPrincipal)))(|(msExchMailboxGUID=%)(objectGUID=%))(legacyExchangeDN=%)(msExchMailboxGUID=%)(&(proxyAddresses=%)(|(objectClass=user)(objectClass=contact)))

If the Exchange Server Analyzer finds that the value for PreloadFilters has been modified from these defaults, a warning is displayed. The Exchange Server Analyzer reports this configuration because the PreloadFilters registry setting should be changed only after you have consulted with Microsoft Product Support Services.

The DSAccess cache resides on the Exchange server and collects configuration and user records that are retrieved from the Active Directory® directory service. Records in the cache are accessed by using an object's distinguished name, globally unique identifier (GUID), or a key constructed from the scope, BaseDN, and the search filter used to find this object in Active Directory. Subsequent accesses that use the same distinguished name, GUID, or key find the record in the cache. Therefore, unnecessary load on Active Directory is prevented for identical searches. However, DSAccess does not prevent load on Active Directory when the search filter is different from the search filter that is contained in the cache, even though DSAccess requests the same attribute set for the user object.

Search preloading is a means to avoid the multiple Active Directory search problems that can occur when various search filters are issued on the same user object. Search preloading works by the previously mentioned key construction where a search entry is constructed by the scope, BaseDN, and the search filter.

For more information about configuring DSAccess search preloading, see the Microsoft Knowledge Base article 250572, "XCON: Preloading and the DSAccess Cache" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250572).


DSAccess reports that this Active Directory server is not functional
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_DSAccessDC Microsoft Windows® Management Instrumentation (WMI) class in the ROOT\MicrosoftExchangeV2 namespace to determine the value for the IsUp key. If the IsUp key is set to False, an error is displayed.

If the IsUp key is set to True, it indicates that the domain controller responded the last time the Exchange server tried to establish a connection. If IsUp is set to False, it indicates that the domain controller did not respond to connection attempts.

The lack of response does not always mean that the domain controller or global catalog is down or malfunctioning. Sometimes, there may network connectivity issues between the Exchange server and the domain controller that could cause this failure. Such a failure could also be the result of a firewall between the Exchange server and the domain controller on which the appropriate ports have not been opened.

To correct this error

  1. Check that the domain controller is running by trying to ping to it.

  2. If there is a firewall, make sure that the firewall has the correct ports open. Be aware that firewalls can be configured to drop PING packets also. Check your firewall documentation for details about how to open or close specific ports.

  3. Make sure that there are no other network related issues, such as malfunctioning switches, routers, and cables.

For more information about DSAccess and directory services detection, see the Microsoft Knowledge Base article 250570, "Directory Service Server Detection and DSAccess Usage" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570).

For more information about troubleshooting network connectivity issues, see the Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).


DSAccess reports that this Active Directory server is not synchronized with the rest of the topology
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_DSAccessDC Microsoft Windows® Management Instrumentation (WMI) class in the ROOT\MicrosoftExchangeV2 namespace to determine the values for the IsInSync key. If the value for IsInSync is False, an error is displayed.

The IsInSync key indicates whether the domain controller is synchronized with the global catalog server and with the configuration domain controller. A value of True indicates the server is synchronized, and a value of False indicates that the domain controller is not synchronized.

To correct this error

  1. Examine the time on the domain controller or global controller. Make sure that the Time Service is started or manually synchronize the time on the Exchange server with the global catalog server or configuration domain controller.

  2. Use the Replication Monitor tool (Replmon) to check, verify, and, if required, fix domain controller replication issues. Replmon is a part of the Microsoft Windows 2000 Server and Microsoft Windows Server™ 2003 Support Tools, which are in the Support\Tools folder of the Windows Server CD.

For more information about DSAccess and Directory Services detection, see the following Microsoft Knowledge Base articles:

  • 316300, "Event ID 2080 and MSExchangeDSAccess" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316300)

  • 250570, "Directory Service Server Detection and DSAccess Usage" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570)


DSAccess reports that this Active Directory server is taking longer than 2 seconds to respond to LDAP requests
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_DSAccessDC Microsoft Windows® Management Instrumentation (WMI) class in the ROOT\MicrosoftExchangeV2 namespace to determine the values for the IsFast key and the IsUp key. If the value for the IsUp key is True, it indicates the directory server used by the Directory Service Access (DSAccess) component in Exchange Server is connected to the network and responding. A value of False indicates the directory server is not responding. If the value of IsFast is True, it indicates the response time of this directory server is less than two seconds. A value of False indicates the response time is more than two seconds. If the value of IsUp is True but the value of IsFast is False, an error is displayed.

To correct this error

  1. Examine the load on the domain controller and global catalog. An overloaded domain controller and global catalog can be slow to respond to Lightweight Directory Access Protocol (LDAP) calls.

  2. Make sure that there is at least one global catalog in the local Active Directory® directory service site for optimal performance.

For more information about DSAccess and directory services detection, see the Microsoft Knowledge Base article 250570, "Directory Service Server Detection and DSAccess Usage" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570).


DSAccess TopoCreateTimeoutSecs registry parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Directory Service Access (DSAccess) initialization time-out default has been changed:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\TopoCreateTimeoutSecs

If the Exchange Server Analyzer finds that the TopoCreateTimeoutSecs key exists and has a value greater than 0, a non-default configuration message is displayed.

At startup, DSAccess uses a discovery process to identify the Active Directory® directory service topology and assess the availability of domain controllers and global catalog servers. After startup is complete and every 15 minutes thereafter, DSAccess uses almost the same process to rediscover the topology and check for changes in server availability. By default, DSAccess initialization during startup must finish within one minute. Otherwise, DSAccess stops. One minute is generally long enough for DSAccess to initialize.

Note:
If you hard code the directory servers that are used by DSAccess, DSAccess bypasses the discovery process and checks for server suitability only.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess

  3. Delete the value called TopoCreateTimeoutSecs.

  4. Close the registry editor.

If this registry key is present, you should consider evaluating your network topology. If additional DSAccess initialization time is required in your organization, it could indicate a design or network problem. Quick and reliable access to domain controllers, especially global catalog servers, is necessary for optimal Exchange operation.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about directory access, see Understanding and Troubleshooting Directory Access (http://go.microsoft.com/fwlink/?LinkId=39012).


The DSAccess user cache is full
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-20

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_MSExchangeDSAccess_MSExchangeDSAccessCaches Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for TotalEntriesMemoryUserData. If the Exchange Server Analyzer Tool finds that the value for TotalEntriesMemoryUserData equals the total size of the Directory Service Access (DSAccess) user cache (MaxMemoryUser), a warning is displayed.

DSAccess is an internal component in Exchange 2000 Server and Exchange Server 2003 that controls how all Exchange components access the Active Directory® directory service. The primary function of DSAccess is to maintain information about various directory-related events and operations. For example, DSAccess discovers the Active Directory topology and detects if domain controllers and global catalog servers are available and responding to queries. Additionally, all directory queries made by internal Exchange components such as the Exchange store are routed through DSAccess, such as recipient resolution, configuration setting lookups, and others. As part of its job, DSAccess maintains an in-memory cache of the results of some of these queries so that if the same information is requested twice, it can be retrieved from the DSAccess cache instead of through another Lightweight Directory Access Protocol (LDAP) query against Active Directory.

In Exchange 2000 Server, the user cache was initially set at 25 megabytes (MB). On Exchange 2000 Server computers that service a large number of Microsoft Office Outlook® 2003 clients, the default DSAccess user cache size was not sufficient. To improve performance, the default value for the user cache has been optimized and set to 140 MB in Exchange Server 2003.

Because the default setting maximum size for the DSAccess user cache was raised from a value of 25 MB in Exchange 2000 Server to a value of 140 MB in Exchange Server 2003, this warning message will likely be generated on Exchange 2000 Server computers. Regardless of what version of Exchange generates this warning message, the problem should be corrected as soon as possible. On systems with an undersized DSAccess cache, local message delivery and address book name resolution may be slower than you want.

The maximum size of the user cache can be manually configured with a registry entry on the Exchange server. MaxMemoryUser is an Exchange 2000 Server registry parameter that allows an Exchange administrator to control the maximum amount of memory that user data objects in the DSAccess cache are allowed to consume.

The MaxMemoryUser value is often used with the MaxMemoryConfig value, which controls the maximum amount of memory that configuration data objects in the DSAccess cache can consume. If you edit or remove the MaxMemoryUser value as described in the following procedure, you should similarly edit or remove the MaxMemoryConfig value as described in DSAccess configuration cache value is non-default.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this problem on an Exchange 2000 Server computer

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. Increase the value for MaxMemoryUser. If this DWORD value does not exist, you can manually create it. The value data for this registry entry is in kilobytes (KB); therefore a decimal entry of 140000 equals 140 MB.

  4. Decrease the value for MaxMemoryConfig. If this DWORD value does not exist, you can manually create it. The value data for this registry entry is also in kilobytes. A value of 5000 decimal, which equals 5 MB, is recommended.

  5. Exit the registry editor and restart Microsoft Exchange System Attendant for the change to take effect.

To correct this problem on an Exchange Server 2003 computer

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. If MaxMemoryUser exists and is configured for less than 140 MB, delete the MaxMemoryUser value. If MaxMemoryUser exists and is more than 140 MB, increase its value by 10 percent.

  4. If MaxMemoryConfig exists, delete it.

  5. Exit the registry editor and restart Exchange System Attendant for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" at (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about DSAccess, see the Knowledge Base article 250570, "Directory service server detection and DSAccess usage" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250570).


DSAccess user cache value is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine if the size of the Directory Service Access (DSAccess) user object cache has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0\MaxMemoryUser

If the Exchange Server Analyzer finds MaxMemoryUser to be present and configured, a non-default configuration message is displayed.

MaxMemoryUser is an Exchange server registry parameter that allows an Exchange administrator to control the maximum amount of memory that user data objects in the DSAccess cache are allowed to consume.

DSAccess is an internal component in Exchange 2000 Server and Exchange Server 2003 that controls how all Exchange components access the Active Directory® directory service. The primary function of DSAccess is to maintain information about various directory-related events and operations. For example, DSAccess discovers the Active Directory topology and detects if domain controllers and global catalog servers are available and responding to queries. In addition, all directory queries made by internal Exchange components such as the Exchange store are routed through DSAccess, such as recipient resolution, configuration setting lookups, and others. As part of its job, DSAccess maintains an in-memory cache of the results of some of these queries so that if the same information is requested twice, it can be retrieved from the DSAccess cache instead of through another Lightweight Directory Access Protocol (LDAP) query against Active Directory.

In Exchange 2000 Server, the user cache was initially set at 25 megabytes (MB) in size. On Exchange 2000 Server computers that service a large number of Microsoft Office Outlook® 2003 clients, the default DSAccess user cache size was not sufficient. On systems with an undersized DSAccess cache, local message delivery and address book name resolution may be slower than desirable.

To improve performance, the default value for the user cache has been optimized and set to 140 MB in Exchange Server 2003. When upgrading from Exchange 2000 Server to Exchange Server 2003, any manual setting will be preserved. If this Exchange server was upgraded from Exchange 2000 Server to Exchange Server 2003, you should make sure the value for MaxMemoryUser is at least 140 MB.

The MaxMemoryUser value was often used in conjunction with the MaxMemoryConfig value, which controls the maximum amount of memory that configuration data objects in the DSAccess cache are allowed to consume. If you edit or remove the MaxMemoryUser value as described in the procedure that follows, you should similarly edit or remove the MaxMemoryConfig value as described in DSAccess configuration cache value is non-default.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To use the MaxMemoryUser registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. Examine or edit the value for MaxMemoryUser.

    The value for this registry entry is in kilobytes (KB). If the value is set to 140000 or less, you should delete MaxMemoryUser and restart Microsoft Exchange System Attendant to default to the Exchange Server 2003 setting.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about DSAccess, see the Knowledge Base article 250570, "Directory Service Server Detection and DSAccess Usage" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570).


DSProxy RFR service has been disabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether the Directory Services Proxy referral (DSProxy RFR) service has been disabled:

HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Services\MSExchangeSA\Parameters\ No RFR Service

If the Exchange Server Analyzer finds No RFR Service to be present and set to 1, a non-default configuration message is displayed.

The DSProxy component in Exchange 2000 Server and Exchange Server 2003 provides directory access to a domain controller or global catalog for Microsoft Outlook® 98 and Outlook 97 clients. Outlook 2000 Service Release 2 (SR-2) and later versions can query a global catalog server directly.

The first time an Outlook 2000 SR-2 or a later version client connects to an Exchange 2000 server or later version computer, it looks for the directory service on the home Exchange server. Outlook at first goes through the DSProxy process for the very first session. After the client contacts the DSProxy service (it tries all available transport protocols), a referral is passed back to the client informing it that all future directory requests should go to the global catalog server. Outlook sets the referral in the MAPI profile in the registry. The DSProxy referral mechanism reduces load on the Exchange server and reduces the latency for address book searches. If an explicit server name is entered into the profile, Outlook must restart if that Active Directory® directory service server fails. If this occurs, the Exchange server sends Outlook a new referral.

In some scenarios you might want to force Outlook clients, even the latest versions, to always go through the DSProxy process without being referred. For example, you may need to do this if a firewall exists between Outlook and the Exchange server.

By adding the No RFR Service registry entry and setting it to 1, the Exchange server will behaves like a proxy for Outlook clients instead of referring the clients to the appropriate global catalog server for direct communication. Setting the No RFR Service registry parameter to 1 will decrease Exchange server performance because the Exchange server will be acting as a proxy for all Outlook clients, including Outlook 2000 SR-2 and newer clients that can communicate directly with Active Directory.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To enable the DSProxy RFR service

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Create a new DWORD value called No RFR Service.

  4. Configure the No RFR Service value with a setting of 1.

To disable the DSProxy RFR service, either delete the No RFR Service registry value or set it to 0.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about how Outlook 2000 SR-2 and newer clients interact with Active Directory, see the Knowledge Base article 256976, "XCCC: How Outlook 2000 Accesses Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=302914).

For information about how MAPI clients access Active Directory, see the Knowledge Base article 256976, "XCLN: How MAPI Clients Access Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256976).


EMSMTA.EXE file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


EnableAuthEpResolution registry key is enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the remote procedure call (RPC) Interface Restrictions registry key is enabled:

HKEY_LOCAL_MACHINE\ Software\Policies\Microsoft\Windows NT\RPC

If the Exchange Server Analyzer finds that the EnableAuthEpResolution registry value exists, the Exchange Server Analyzer displays a non-default configuration message.

RPC Interface Restrictions provides increased network protection that will make systems less vulnerable to attacks over the network.

An RPC interface that is remotely and anonymously available and is registered by default on Microsoft Windows® XP presents a significant attack surface. RPC itself must register such an interface to provide endpoint resolution for calls using dynamic endpoints. The RestrictRemoteClients registry key modifies the behavior of all RPC interfaces on the system. By default, the RestrictRemoteClients registry key prevents remote anonymous access to RPC interfaces on the system, with some exceptions. Therefore, the RPC Endpoint Mapper interface is no longer available anonymously.

An RPC client that tries to make a call by using a dynamic endpoint will first query the RPC Endpoint Mapper on the server to determine what dynamic endpoint the RPC client should connect to. This query is performed anonymously, even if the RPC client call itself is performed by using RPC security. By default, anonymous calls to the RPC Endpoint Mapper interface will fail on Microsoft Windows XP Service Pack 2 because the default RestrictRemoteClients functionality prevents remote anonymous access to RPC interfaces on the system. Because of this RPC Interface Restriction, the RPC client runtime is modified to perform an authenticated query to the Endpoint Mapper. This RPC Interface Restriction is the default behavior in Windows XP Service Pack 2. The RPC client runtime then uses Integrated Windows authentication, formerly named NTLM, to authenticate to the Endpoint Mapper. The Integrated Windows authentication occurs if the actual RPC client call uses this kind of authentication. A non-default configuration exists if the following conditions exist:

  • The RPC registry key and EnableAuthEpResolution value described have been created.

  • The EnableAuthEpResolution registry value has been set to 0.

For more information about changes to RPC service with Windows XP Service Pack 2, see "RPC Interface Restrictions" (http://go.microsoft.com/fwlink/?LinkId=47371).


Epoxy Client Out Queue Length (IMAP) beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Client Out Queue Length (IMAP) performance counter of the Epoxy performance object to analyze performance data.

The Client Out Queue Length (IMAP) performance counter indicates the number of messages in the queue that contain IMAP4 messages sent by the Inetinfo.exe process to the Store.exe process. The queues should be under 50 at all times. If the Exchange Server Analyzer determines that the Client Out Queue Length (IMAP) counter has exceeded the peak value of 50 during the sample time slice, the Exchange Server Analyzer displays an error.

Epoxy (ExIPC) is a shared memory mechanism that enables the processes of the Microsoft Internet Information Services (IIS) (Inetinfo.exe) and Microsoft Exchange Information Store services (Store.exe) to quickly shuttle data back and forth. This allows for bi-directional, interprocess communication between the Inetinfo.exe process and the Store.exe process.

Note:
Inetinfo.exe accepts requests from Internet protocols such as WebDAV, IMAP4, NNTP, POP3, and SMTP.

This memory is also used by DSAccess, the Exchange component that caches Active Directory® information.

This error indicates that there are performance issues in the Store.exe process, or in resources that the Store.exe process depends on, that are causing this queue to grow. This will cause the server response time to increase.

To resolve this issue, use the resources referenced in the "More Information" section to identify the performance bottleneck with the Store.exe process or related resources. This bottleneck may be related to poor disk performance or high CPU utilization.

For More Information

  • For more information about identifying increasing queues in Epoxy, see "Identifying Rising Queues in Epoxy" in Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about processor bottlenecks, see Processor Bottleneck.

  • For more information about disk bottlenecks, see Disk Bottleneck Detected.

  • For more information about troubleshooting store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Epoxy Client Out Queue Length (POP) beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Client Out Queue Length (POP) performance counter of the Epoxy performance object to analyze performance data.

The Client Out Queue Length (POP) performance counter indicates the number of messages in the queue that contain POP3 messages sent by the Inetinfo.exe process to the Store.exe process. The queues should be under 50 at all times. The Exchange Server Analyzer retrieves a sample from this counter every 5 seconds for a five minute period. If the Exchange Server Analyzer determines that the Client Out Queue Length (POP) counter has exceeded the peak value of 50 during the sample time slice, the Exchange Server Analyzer displays an error.

Epoxy (ExIPC) is a shared memory mechanism that enables the processes of the Microsoft Internet Information Services (IIS) (Inetinfo.exe) and Microsoft Exchange Information Store services (Store.exe) to quickly shuttle data back and forth. This allows for bi-directional, interprocess communication between the Inetinfo.exe process and the Store.exe process.

Note:
Inetinfo.exe accepts requests from Internet protocols such as WebDAV, IMAP4, NNTP, POP3, and SMTP.

This memory is also used by DSAccess, the Exchange component that caches Active Directory® information.

This error indicates that there are performance issues in the Store.exe process, or in resources that the Store.exe process depends on, that are causing this queue to grow. This will cause the server response time to increase.

To resolve this issue, use the resources referenced in the "More Information" section to identify the performance bottleneck with the Store.exe process or related resources. This bottleneck may be related to poor disk performance or high CPU utilization.

For More Information

  • For more information about identifying increasing queues in Epoxy, see "Identifying Rising Queues in Epoxy" in Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about processor bottlenecks, see Processor Bottleneck.

  • For more information about disk bottlenecks, see Disk Bottleneck Detected.

  • For more information about troubleshooting store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


EPOXY.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To resolve this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running the Setup program in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD in your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


Epoxy performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Client Out Queue Length performance counter of the Epoxy performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions are true:

  • The Epoxy performance monitor object is disabled.

  • The Epoxy performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry. The following procedure explains how to fix the first two conditions. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the Epoxy performance object is enabled:

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at the Web site, "Exctrlst.exe: Extensible Performance Counter List" (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall Exchange Server in the Repair mode, and then apply the latest Exchange Server service packs.


Epoxy Store Out Queue Length (IMAP) beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Store Out Queue Length (IMAP) performance counter of the Epoxy performance object to analyze performance data.

The Store Out Queue Length (IMAP) performance counter indicates the number of messages in the queue that contain IMAP4 messages sent by the Store.exe process to the Inetinfo.exe process. The queue should be under 50 at all times. The Exchange Server Analyzer retrieves a sample from this counter every 5 seconds for a five minute period. If the Exchange Server Analyzer determines that the Store Out Queue Length (IMAP) counter has exceeded the peak value of 50 during the sample time slice, the Exchange Server Analyzer displays an error.

Epoxy (ExIPC) is a shared memory mechanism that enables the processes of the Microsoft Internet Information Services (IIS) (Inetinfo.exe) and Microsoft Exchange Information Store services (Store.exe) to quickly shuttle data back and forth. This allows for bi-directional, interprocess communication between the Inetinfo.exe process and the Store.exe process.

Note:
Inetinfo.exe accepts requests from Internet protocols such as WebDAV, IMAP4, NNTP, POP3, and SMTP.

This memory is also used by DSAccess, the Exchange component that caches Active Directory® information.

This error indicates that there are performance issues in the Inetinfo.exe process, or in resources that the Inetinfo.exe process depends on, that are causing this queue to grow. This may cause server response time to increase. Therefore, users will experience delays in response from the server.

To resolve this issue, use the resources referenced in the "More Information" section to identify the performance bottleneck with Inetinfo.exe or related resources. This bottleneck may be related to poor disk performance or high CPU utilization.

For More Information

  • For more information about identifying increasing queues in Epoxy, see "Identifying Rising Queues in Epoxy" in Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about processor bottlenecks, see Processor Bottleneck.

  • For more information about disk bottlenecks, see Disk Bottleneck Detected.

  • For more information about troubleshooting store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Epoxy Store Out Queue Length (POP) beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Store Out Queue Length (POP) performance counter of the Epoxy performance object to analyze performance data.

The Store Out Queue Length (POP) performance counter indicates the number of messages in the queue that contain POP3 messages sent by the Store.exe process to the Inetinfo.exe process. The queue should be under 50 at all times. The Exchange Server Analyzer retrieves a sample of this counter every 5 seconds for a five minute period. If the Exchange Server Analyzer determines that the Store Out Queue Length (POP) counter has exceeded the peak value of 50 during the sample time slice, the Exchange Server Analyzer displays an error.

Epoxy (ExIPC) is a shared memory mechanism that enables the processes of the Microsoft Internet Information Services (IIS) (Inetinfo.exe) and Microsoft Exchange Information Store services (Store.exe) to quickly shuttle data back and forth. This allows for bi-directional, interprocess communication between the Inetinfo.exe process and the Store.exe process.

Note:
Inetinfo.exe accepts requests from Internet protocols such as WebDAV, IMAP4, NNTP, POP3, and SMTP.

This memory is also used by DSAccess, the Exchange component that caches Active Directory® information.

This error indicates that there are performance issues in the Inetinfo.exe process, or in resources that the Inetinfo.exe process depends on, that are causing this queue to grow. This may cause server response time to increase. Therefore, users will experience delays in response from the server.

To resolve this issue, use the resources referenced in the "More Information" section to identify the performance bottleneck with Inetinfo.exe or related resources. This bottleneck may be related to poor disk performance or high CPU utilization.

For More Information

  • For more information about identifying increasing queues in Epoxy, see "Identifying Rising Queues in Epoxy" in Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about processor bottlenecks, see Processor Bottleneck.

  • For more information about disk bottlenecks, see Disk Bottleneck Detected.

  • For more information about troubleshooting store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Error Accessing Exchange Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool cannot access your Exchange server. This error indicates that configuration information for the Exchange server you specified was not found in the Active Directory® directory service.

To correct this error

  • Make sure that you typed the server name correctly.

  • Enter only the host or NetBIOS name of the server (for example, Server1) instead of the fully qualified domain name (for example, Server1.example.com).

  • Verify that you have the permissions that are required to access Active Directory configuration information for this server.


Error Accessing Exchange Server Information
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool is having a problem accessing the Active Directory® directory service configuration information for the Exchange server.

To correct this error:

  • Verify that your current logon account has appropriate permissions for reading Exchange server configuration information in Active Directory.

  • Verify that you have network connectivity to an Active Directory domain controller.

  • Enter explicit account credentials into the Exchange Server Analyzer Tool for accessing Active Directory.

  • Specify an Active Directory domain controller in the Exchange Server Analyzer.

  • Ensure that the Exchange server you specified exists and that you typed the server name correctly.


Error Accessing Message Tracking Log
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-06

The Microsoft® Exchange Server Analyzer Tool queries the MessageID property for each instance of the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class.

If the Exchange Server Analyzer does not receive a result from the query, the Exchange Server Analyzer displays an error.

The most likely cause of this error is that the Message Tracking Center is disabled.

The Message Tracking Center, when it is enabled, logs information about the sender, the mail message, and the message recipients. Specifically, you can review statistics such as the time the message was sent or received, the message size and priority, and the list of message recipients. You can also log the subject line of e-mail messages. The Message Tracking Center searches for messages such as system messages, public folder messages, and e-mail messages.

You must enable Message Tracking Center on each server for which you want to track messages. When it is enabled, all messages that are routed through a server are added to the message tracking logs.

The Exchange Server Analyzer requires that message tracking be enabled for it to start its scans.

Note:
The following permissions are required to perform this procedure: member of the local administrators group and member of a group that has had the Exchange Administrators role applied at the administrative group level
To enable Message Tracking Center on a server

  1. In Exchange System Manager, expand Servers, right-click the server on which you want to enable message tracking, and then click Properties.

  2. On the General tab, select the Enable message tracking check box.

  3. To record the subject of any message sent to, from, or through the server, select the Enable subject logging and display check box.

    Note:
    If you enable subject logging, you may cause some decrease in performance.

  4. Under Log file maintenance, you can prevent the removal of log files or modify the length of time that the log files are kept. The default period that tracking logs are kept is seven days.

    Note:
    On servers that process large quantities of mail, the tracking logs grow quickly. Make sure that you have sufficient disk space for the log files and for other services or applications that use this disk.

  5. Click OK or Apply. You do not have to restart services for this change to take effect.

For more information about how to use the Message Tracking Center, see Microsoft Knowledge Base article 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=262162).

For more information about how to troubleshoot Exchange Server 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).


Error while upgrading ACLs
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-15

The Microsoft Exchange Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows Management Instrumentation (WMI) class to determine whether an Event 9551 error has been logged for MSExchangeIS within the last hour.

If the Exchange Analyzer finds that an Event 9551 error has been logged in the last hour, the Exchange Analyzer then counts the total number of Event 9551 errors that have been logged for that hour.

Finally, if the Exchange Analyzer finds that an Event 9551 error has been logged 20 or more times in the last hour, the Exchange Analyzer displays a warning.

This error indicates that there may be user accounts that appear in an access control list (ACL) for a mailbox resource or public folder but are not associated with valid Active Directory directory service objects.

A mailbox that is on a server that is running Microsoft Exchange Server 2003 or Exchange 2000 Server must be represented in Active Directory by a valid Active Directory directory service user account to be accessible.

An account without valid representation in Active Directory can be created if the Exchange 2000 Server or Exchange Server 2003 mailbox resource or public folder is not updated after a mailbox is deleted on the Exchange Server 5.5-based computer.

If the deleted mailbox account remains on the ACL of a mailbox resource or public folder, every time that mailbox resource or public folder is accessed and Exchange tries to resolve the accounts listed, the account with no valid representation in Active Directory cannot be resolved. This process can manifest itself as a performance issue.

To address this issue:

  • Make sure that Exchange 2000 Server Service Pack 3 (SP3) or a later version is installed. To obtain the latest Exchange 2000 Server Service Pack, see Microsoft Knowledge Base article 301378, "How to obtain the latest Exchange 2000 Server service pack" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378).

  • Use Exchange System Manager to manually remove the invalid mailbox accounts from the ACL.

  • If the Exchange environment is in Exchange Mixed Mode, run the DS/IS consistency checker against the information store.

  • If the Exchange environment is in Exchange Native Mode, follow the guidance in Microsoft Knowledge Base article 324323, "XADM: Skipping User Accounts That Are Not Represented in Active Directory During Access Control List Conversion" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324323).

To use Exchange System Manager to manually remove the invalid accounts from the ACL

  1. Start Exchange System Manager and locate the folder identified by the 9551 error.

  2. Right-click the folder and select Properties.

  3. Select the Permissions tab and then click Client Permissions.

  4. In the Name pane, select the user account identified by the 9551 error and then click the Remove button to remove the account from the ACL.
To run the DS/IS consistency checker against the information store in Exchange Mixed Mode

  1. In the Exchange Server 5.5 Administrator program, click the Exchange 5.5 Server computer that contains the information store.

  2. On the File menu, click Properties, and then click the Advanced tab.

  3. Click Consistency Adjustment.

  4. Click to select the Remove unknown user accounts from public folder permissions and the Remove unknown user accounts from mailbox permissions check boxes, and then click All Inconsistencies.

  5. Click to clear all other check boxes, and then click OK

For More Information

For more information about this issue, see the following Microsoft Knowledge Base articles and Exchange Server Resources:

  • Events and Errors Message Center: Event Details: MSExchangeIS Mailbox Store Event 9551 details (http://go.microsoft.com/fwlink/?LinkId=83189).

  • Microsoft Knowledge Base article 301378, "How to obtain the latest Exchange 2000 Server service pack" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378).

  • Microsoft Knowledge Base article 324323, "XADM: Skipping User Accounts That Are Not Represented in Active Directory During Access Control List Conversion" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324323).


ESE.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=33457).


ESEUTIL.EXE file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkId=33457).


EXCDO.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


EXCHMEM.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To fix this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


EXMIME.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To resolve this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running the Setup program in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD in your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server Web site" (http://go.microsoft.com/fwlink/?LinkId=33457).


EXOLEDB.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


EXPOP3.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To resolve this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running the Setup program in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD in your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


EXPROX.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To fix this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


EXRES.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To fix this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


EXSMTP.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


EXSMTP.DLL file version is outdated
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

Error Message

Introduction

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for EXSMTP.DLL. If the Exchange Server Analyzer determines that the Version key for EXSMTP.DLL does not equal 6556.0, a warning is displayed.

This warning indicates that the version of EXSMTP.DLL on this Exchange Server computer is from the Version 1 May 2004 Exchange 2000 Server Post-Service Pack 3 Rollup. A later update rollup is available for download.

To correct this warning

  1. Download the latest update (August 2004) from "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).

  2. Read about the latest update by reviewing the Microsoft Knowledge Base article 870540, "Availability of the August 2004 Exchange 2000 Server Post-Service Pack 3 Update Rollup" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=870540).

  3. Take a complete backup of the Exchange Server computer.

  4. Apply the August 2004 update.

For more information about installing this and other Exchange Server updates, see the Microsoft Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


Exchange ActiveSync tracing is currently enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if tracing has been enabled for Exchange ActiveSync®:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Tracing\Microsoft Server ActiveSync\MasSync\Enabled

If the Exchange Server Analyzer finds the value for Enabled is present and configured with a value greater than 0, a warning is displayed.

Exchange ActiveSync is implemented as an Internet Server Application Programming Interface (ISAPI) extension in Internet Information Services (IIS). IIS, Exchange ActiveSync, and many of the client devices that use Exchange ActiveSync include native tracing capabilities, thereby obviating the need to use the native tracing capabilities of Microsoft Windows Server™ 2003.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Tracing\Microsoft Server ActiveSync\MasSync

  3. Delete the Enabled value.

  4. Close the registry editor and restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about tracing and logging for Exchange ActiveSync and Exchange ActiveSync clients, see the following Knowledge Base articles:

  • 330463, "XCCC: How to troubleshoot server ActiveSync HTTP error codes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=330463)

  • 330461, "HOW TO: Troubleshoot Server ActiveSync" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=330461)

  • 822176, "Troubleshoot Exchange 2003 Always-Up-To-Date Notification" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822176)


Exchange binary file version is newer than installed version of Exchange Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the files to be more than the Exchange Server Version value, a warning is displayed. A later version number indicates that a file is newer than what was expected. This can occur if a hotfix was installed.

To resolve this warning

  1. There is no action that needs to be taken. The warning only indicates the presence of newer files, which are probably the result of the installation of a hotfix or other update.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


This Exchange cluster node is also a domain controller
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Microsoft Windows® Management Instrumentation (WMI) object (Win32_ComputerSystem class) to determine the DomainRole value for the server. The DomainRole value represents the role of a computer in a domain. The table that follows lists the valid values for DomainRole.

Value | Meaning
0 | Stand-alone workstation
1 | Member workstation
2 | Stand-alone server
3 | Member server
4 | Backup domain controller
5 | Primary domain controller

In addition, the Exchange Server Analyzer queries the ClusSvc WMI object (Windows Cluster Service object, Win32_Service class) to determine its Started value. A value of True indicates the Cluster service is started and a value of False indicates the service is not started.

If the Exchange Server Analyzer determines that the value for the DomainRole value is greater that 3 on an Exchange Server computer where the Cluster service is started, an error is displayed. This error indicates that an Exchange server is running in a Windows server cluster whose nodes are domain controllers.

Running an Exchange Server cluster node as a domain controller is not a supported configuration.

To correct this error

  1. Choose a non-cluster server to act as the domain controller, and run the Active Directory Installation Wizard (dcpromo) to promote that server.

  2. After the Active Directory® directory service has been configured on the new domain controller, wait for the existing Active Directory content to replicate to the new server.

    Depending on the size of Active Directory, this operation could take several hours.

  3. Run the Active Directory Installation Wizard (dcpromo) on the cluster server to demote the server and remove Active Directory.

For more information about promoting and demoting domain controllers, see the Microsoft Knowledge Base article 238369, "How To Promote and Demote Domain Controllers in Windows 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=238369).


Exchange Error Reporting is disabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Exchange Error Reporting is enabled:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\DisableErrorReporting

If the Exchange Server Analyzer finds the value for DisableErrorReporting is 1, a warning is displayed. A value of 1 indicates that Exchange Error Reporting is disabled.

Support for Microsoft Error Reporting—also known as Windows Error Reporting, Microsoft Event Reporting, and Automatic Error Reporting—was first added with Exchange 2000 Server Service Pack 2. Exchange Server 2003 includes an enhanced version of Microsoft Error Reporting named Exchange Error Reporting that streamlines error reporting to administrators, integrates with Corporate Error Reporting, and provides enhanced reporting for the Exchange Server 2003 Recipient Update Service.

Exchange Error Reporting enables Exchange Server administrators to transmit crashes and other fatal errors through HTTPS over the Internet to a Microsoft error reporting server. It is recommended that you send error reports to Microsoft Online Crash Analysis. Collecting fatal error data from Exchange servers helps the Exchange product team find and fix errors in the software that you use.

If a fatal error occurs while using Exchange System Manager or while performing an Exchange-related task with Active Directory Users and Computers on a computer where Exchange System Manager has been installed, Exchange Error Reporting notifies the administrator about the error, and prompts them if they want to report the error to Microsoft. Additionally, Exchange Error Reporting also traps and reports errors encountered by Microsoft Exchange System Attendant, Microsoft Exchange Information Store, and other Exchange services. Additionally, because errors encountered by Recipient Update Service can leave the System Attendant component in a bad state, Exchange Error Reporting also reports access violations and other internal faults that occur in the Recipient Update Service.

You can configure each Exchange server to send fatal error information by selecting a box on the server property page in Exchange System Manager.

To configure Exchange 2000 Server or Exchange Server 2003 to send fatal server error data to Microsoft

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, right-click your server, and then click Properties. If the Administrative Groups node is not displayed in Exchange System Manager, expand Servers, right-click your server, and then click Properties.

  3. On the General tab of the <Server Name> Properties page, select the Automatically send fatal service error information to Microsoft box, and then click Apply.

  4. Click Yes to confirm that you want to enable Exchange Error Reporting.

  5. Click OK.

When a fatal error is encountered, a compressed error report file is created (typically 10-50 kilobytes). This report contains, among other things, a dump file. A dump file is a file that contains information about the process that experienced the fault. Although faults can occur at a variety of programmatic levels (for example, at the thread level, at the interface level, and at the method or function level), they all occur within the context of a single process. The dump file typically includes information about the faulting process, such as details of what each thread was doing, the various memory areas in use by the process, system information, and other relevant debugging information. With Exchange Server, the error reports also include information about the state of Exchange Server, operating system version information, details about the computer's hardware, the computer's IP address, and a digital product ID that is used to identify the product license.

While Microsoft does not intentionally collect personal information, we do acknowledge that some of the collected information could contain information that could be used to uniquely identify your system. However, Microsoft does not use the collected data in this manner, and uses the data only for crash reports and bug fixing. For more information, see the error reporting policy, "Data Collection Policy" (http://go.microsoft.com/fwlink/?LinkId=33818).


This Exchange front-end server has the /3GB startup switch in the Boot.ini file
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the amount of virtual address space allocated to user mode processes (MaxProcessMemorySize) on the Exchange Server computer. The Exchange Server Analyzer also examines the Exchange_Server WMI class in the root\MicrosoftExchangeV2 namespace to determine the value for the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is a front-end server.

If the Exchange Server Analyzer determines that the value for the MaxProcessMemorySize key is not equal to 2097024 and that the IsFrontEndServer key is set to True, a warning is displayed.

This warning indicates that the Exchange Server computer is not properly configured for optimal memory usage because the /3GB startup switch has been set in the Boot.ini file. This switch should only be used on Exchange Servers with 1 gigabyte (GB) or more of memory that are running any of the following operating systems:

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

Important:
The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the operating systems listed previously when 1 GB or more of physical memory is installed.

When the /3GB parameter is included in the Boot.ini file of a server running Microsoft Windows 2000 Server or Windows Server 2003, Windows allocates 3 GB out of a maximum of 4 GB of virtual address space to the user process and 1 GB to the kernel. Normally (when the /3GB parameter is not used), Windows allocates 2 GB to the user process and 2 GB to the kernel. Therefore, with the /3GB switch, memory intensive applications have a larger virtual memory address space to operate in and performance is improved.

Using the /3GB switch primarily helps memory-intensive applications like the Store.exe process on an Exchange server that hosts user mailboxes. A front-end server does not host user mailboxes and, therefore, there is no benefit derived from using the /3GB switch on a front-end server.

To correct this warning

  1. In Windows Explorer, navigate to the system partition.

  2. If you are unable to see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in the Windows Explorer window, click Tools, click Folder Options, and then click the View tab. Clear the Hide protected operating system files (Recommended) check box. When prompted with the warning box, click Yes.

  3. When the Boot.ini file is visible in Explorer, right-click the file, click Open With, and choose Notepad to open the file.

  4. In the [Operating Systems] section, delete the following switches from all startup lines: /3GB

  5. Save the changes and close Notepad.

  6. Restart the computer for the change to take effect.

For further details regarding the use of the /3GB startup switch, see the following Microsoft Knowledge Base articles:

  • 297812, "How to Use the 4GT RAM Tuning Feature" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 311901, "The effects of 4GT tuning on system Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 31679, "How to Use the /USERVA Switch in the Boot.ini File to Tune /3GB Configurations" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Exchange IFS drive has not been explicitly excluded from Windows Backup
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the files and folders that have been excluded from backups using Backup:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

The Exchange Server Analyzer specifically looks for a string value called Exchange IFS.

The Exchange Server Analyzer also reads the following registry entry to obtain the drive letter that represents the Exchange Installable File System (IFS) drive:

HKLM\System\CurrentControlSet\Services\EXIFS\Parameters\DriveLetter

In Exchange 2000 Server, the default drive letter is M. The IFS drive is turned off by default in Exchange Server 2003.

If the Exchange Server Analyzer finds that the FilesNotToBackup key does not contain a string value called Exchange IFS, or if it does contain Exchange IFS, but the value data for Exchange IFS does not equal M:\* /s (where M is the drive letter representing IFS), a warning is displayed.

By default, when the IFS drive letter mapping is enabled, Exchange IFS is added to the FilesNotToBackup registry key. The M:\ drive is a logical view of the Exchange store, and not a true drive, and backing it up can cause significant problems such as lost attachments. In addition, the backup software may not truncate the log files as appropriate, which can result in the server running out of disk space unexpectedly.

If you are not using Backup, you can safely ignore this warning. If you are using Backup, it is recommended that you exclude the IFS drive from all backup jobs. If you back up the IFS drive with Backup or any other backup program, you might corrupt your information store databases, lose data, and not be able to restore data from a backup of the IFS drive.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

  3. Right-click FilesNotToBackup and click New | Multi-string value. Type Exchange IFS for the name and press Enter.

  4. In the right pane, double-click Exchange IFS and enter a Value Data of M:\* /s. Be sure to use the correct drive letter in case your system does not use the default drive letter M.

  5. Close the registry editor.

For more information about the Microsoft Windows® registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information about backing up and restoring Exchange, see the Exchange Server 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?LinkId=47570). For additional information, see the following Knowledge Base articles:

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

  • 233427, "Files and folders that are not backed up when the Ntbackup.exe tool is used in Windows Server 2003, Windows XP, and Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=233427)

For more information about problems that may occur if you scan the IFS drive with antivirus software, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM:C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


This Exchange mailbox server has 1 GB or more of memory but does not have /3GB set in the Boot.ini file
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries two Microsoft Windows® Management Instrumentation (WMI) classes to determine the amount of physical memory in the Exchange server, and the amount of virtual address space allocated to user mode processes. The following table describes the classes and keys being evaluated by the Exchange Server Analyzer.

Class queried | Keys queried | Description
Win32_OperatingSystem | MaxProcessMemorySize | Maximum number of kilobytes of memory that can be allocated to a process.
Win32_OperatingSystem | OSProductSuite | Installed and licensed system product additions to the operating system.
Win32_ComputerSystem | TotalPhysicalMemory | Number of bytes of random access memory (RAM) installed in the computer.

If the Exchange Server Analyzer determines that the Exchange Server computer is not running Windows 2000 Server and has 1 gigabyte (GB) or more of physical memory installed, and the value for the MaxProcessMemorySize is more than 2097024 but less than 3104640, a warning is displayed.

This warning indicates that the Exchange server does not comply with the requirements set forth in the Microsoft Knowledge Base article 266096, "Exchange 2000 requires /3GB switch with more than 1 gigabyte of physical RAM" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096). This is not a recommended production configuration.

Microsoft Windows Server™ 2003 includes support for two startup switches—/3GB and /USERVA—that let you tune the allocation of use of memory and memory address space. Regardless of the amount of physical memory in your system, Windows uses a virtual address space of 4 GB, with 2 GB allocated to user-mode processes (for example, applications) and 2 GB allocated to kernel-mode processes (for example, the operating system and kernel-mode drivers). On systems that have 1 GB or more of physical memory, these two startup switches can be used to allocate more memory to applications (3 GB) and less memory to the operating system (1 GB). This additional virtual address space helps reduce the amount of memory fragmentation in the virtual address space of the Exchange information store process.

The /3GB switch is used to effect this allocation change. The switch is entered in the system's Boot.ini file and takes effect after a restart. This switch should only be used on Exchange servers with 1 GB or more of memory that are running any of the following operating systems:

  • Microsoft Windows Server 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

Important:
The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the operating systems listed previously when 1 GB or more of physical memory is installed.

The /USERVA switch is new to Windows Server 2003. Its purpose is to provide a finer level of control over the division of virtual address space between user-mode processes and kernel-mode processes. This switch should only be used for applications that support it, such as Exchange 2000 Server and Exchange Server 2003, and with the specific values supported by those applications.

Note:
Microsoft Product Support Services does not support arbitrary /USERVA settings. Customers should add this setting to the Boot.ini file based only on a manufacturer's recommendation.

When used on Exchange Server 2003 systems, the only supported value for /USERVA is 3030 (for example, /USERVA=3030). This value causes an additional 40 megabytes (MB) to be allocated to the operating system, and enables you to add more users without consuming all available system resources.

To correct this warning

  1. Right-click My Computer and select Properties. The System Properties dialog box will appear.

  2. Click the Advanced tab.

  3. In the Startup and Recovery area, click Settings. The Startup and Recovery dialog box will appear.

  4. In the System startup area, click Edit. This will open the Windows Boot.ini file in Notepad.

  5. In the [Operating Systems] section, add the following switches to the end of the startup line that includes the /fastdetect switch: /3GB /USERVA=3030

  6. Save the changes and close Notepad.

  7. Click OK two times to close the open dialog boxes, and then restart the Exchange Server computer for the change to take effect.

For more information about optimizing Exchange Server memory usage and performance, see the following Microsoft Knowledge Base articles:

  • 266096, "Exchange 2000 requires /3GB switch with more than 1 gigabyte of physical RAM" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096)

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 810371, "XADM: Using the /Userva Switch on Windows Server 2003-Based Exchange Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371)

  • 823440, "You Must Use the /3GB Switch When You Install Exchange Server 2003 on a Windows Server 2003-Based System" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440)

  • 822178, "Overview of Dependencies and Requirements for Exchange Server 2003 Features" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822178)


Exchange Provider Tracing is Enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-06-20

The Microsoft Exchange Server Analyzer Tool queries the Active Directory directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 5.5," the computer is running Microsoft Exchange Server 5.5. If the string value includes "Version 6.0," the computer is running Microsoft Exchange 2000 Server. If the string value includes "Version 6.5," the computer is running Microsoft Exchange Server 2003. If the string value includes "Version 8.0," the computer is running Microsoft Exchange Server 2007.

The Exchange Analyzer also queries the CIM_Datafile Microsoft® Windows® Management Instrumentation (WMI) class to determine the value of the Version key for Emsmdb32.dll, the Exchange Transport Provider. The Version WMI key indicates the build number for this file.

Finally, the Exchange Analyzer queries the following registry entry to determine whether Exchange provider tracing has been configured and enabled.

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Exchange Provider\Enable Tracing

The Exchange Analyzer displays an error message if the following conditions are true:

  • The server is not running Exchange Server 2007

  • The Version key for Emsmdb32.dll is 6.5.7233.47 or later versions

  • The HKML\Software\Microsoft\Exchange\Exchange Provider\Enable Tracing entry exists and is set to a value other than 0

This error indicates that Exchange Transport Provider Tracing is enabled on the computer.

Versions of the Exchange Transport Provider at version 6.5.7233.47 and later versions have built-in tracing features. A .ttd file enables tracing of the following programs:

  • Any program that uses MAPI on the server that is running Exchange Server 2003

  • Any program that is installed by using the Microsoft Exchange System Management Tools.

Exchange Transport Provider Tracing should only be enabled for active troubleshooting and might otherwise adversely affect typical server performance.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To disable Exchange provider tracing on Exchange Server 2003

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Browse: HKML\Software\Microsoft\Exchange\Exchange Provider\

  3. In the right navigation pane:

    1. Right-click and delete the Enable Tracing subkey, or

    2. Double-click Enable Tracing.

  4. Configure the Enable Tracing subkey with a value of 0.

  5. Close Registry Editor.

  6. Restart the Exchange Information Store service for these changes to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, Description of the Microsoft Windows Registry.


Exchange Management service is not running as LocalSystem
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the StartName property for the Microsoft Exchange Management (MSExchangeMGMT) service. If the Exchange Server Analyzer finds that the Exchange Management service is running under any account other than the LocalSystem (SYSTEM) account, the Exchange Server Analyzer displays an error.

This error indicates that the Exchange Management service is not running in a supported configuration. If you run the Exchange Management service under any other account, you will cause permission and access errors.

To resolve this error, you must configure the Exchange Management service to start under the LocalSystem (SYSTEM) account.

To configure the Exchange Management service account

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. Locate and stop the Microsoft Exchange Management service.

  3. Double-click Microsoft Exchange Management service.

  4. On the Log On tab of the Microsoft Exchange Management Properties page, select Local System account under Log on as, and then click Apply.

  5. Under Service status, click Start, and then click OK.

  6. Close the Services snap-in.

For more information about running Exchange services under the LocalSystem account, see the Microsoft Knowledge Base article 239762, "Exchange Services Run Under LocalSystem" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762).


Exchange Management service is stopped
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Process Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the MSExchangeMGMT instance, which represents the Microsoft Exchange Management service. If the Exchange Server Analyzer finds the value of the Started key for the MSExchangeMGMT instance does not equal True, a warning is displayed.

The Exchange Management service was introduced in Exchange 2000 Server Service Pack 2. Among other things, the Exchange Server Message Tracking Center functionality, and certain Exchange System Manager functions depend on this service to function.

The Exchange Management service lets you specify, through the user interface, which domain controller or global catalog server Exchange Server 2003 or Exchange 2000 Server use to access the Active Directory® directory service. This service is also required for message tracking. You can disable this service without affecting the core functionality of Exchange. However, when auditing your Exchange Server functionality, you may require message tracking capabilities on all Exchange Server computers that route mail.

Note:
Because front-end servers are most frequently used to access mail instead of to route mail, you may find that you do not need to run the Exchange Management service on your front-end servers.

To configure the Exchange Management service to start automatically

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. Double-click Microsoft Exchange Management service.

  3. On the General tab of the Microsoft Exchange Management properties page, select Automatic from the Startup type dialog box, and then click Apply.

  4. Under Server status, click Start, and then click OK.

For more information about the Exchange Management service, see the Microsoft Knowledge Base article 307413, "XGEN: General Information on Exchange Management Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307413).

For more general information about managing Exchange, see the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


Exchange 2000 Server is not running the latest Service Pack
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute for each Exchange Server object. The versionNumber attribute represents the version of Exchange Server that is running on the computer.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the STORE.EXE process. If the Exchange Server Analyzer determines that the Version key for STORE.EXE has a value greater than 4416 and less than or equal to 6249, a warning is displayed.

This warning indicates that the Exchange Server computer is not running the latest available code for the version of Exchange running on the computer.

To correct this warning

  1. Download Exchange 2000 Server Service Pack 3 (http://go.microsoft.com/fwlink/?LinkId=17058).

  2. Review the Exchange 2000 Server Service Pack 3 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=12337).

  3. Download the latest update (August 2004) (http://go.microsoft.com/fwlink/?LinkId=33457).

  4. Review the latest update information by reviewing the Microsoft Knowledge Base article 870540, "Availability of the August 2004 Exchange 2000 Server Post-Service Pack 3 Update Rollup" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=870540).

  5. Take a complete backup of the Exchange Server computer.

  6. Apply Exchange 2000 Server Service Pack 3.

  7. Apply the August 2004 update.

For more information about obtaining the latest service pack for Exchange 2000 Server, see the Microsoft Knowledge Base article 301378, "How to obtain the latest Exchange 2000 Server service pack" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378).

For more information about installing this and other Exchange Server updates, see the Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


Exchange 2000 Server is not supported on Windows Server 2003
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of the Microsoft Windows® operating system that is running on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the computer is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the computer is running Windows 2000 Server, and a value of 5.2 indicates the computer is running Windows Server™ 2003.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects with an object class of msExchExchangeServer. If the string value includes Version 5.5, the computer is running Microsoft Exchange Server version 5.5. If the string value includes Version 6.0, the computer is running Exchange 2000 Server. If the string value includes Version 6.5, the computer is running Exchange Server 2003.

If the Exchange Server Analyzer finds the value for CurrentVersion equal to 5.2 and the value for serialNumber contains Version 6.0, an error is displayed. This is not a supported configuration, and you should correct this error as soon as possible.

To correct this error

  1. Do one of the following:

    • Install Exchange 2000 Server on a server that is running a supported operating system, and move the mailboxes to that server.

    • Upgrade Exchange 2000 Server to Exchange Server 2003.

For more information about supported configurations, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about Exchange Server and Windows Server 2003, see the Microsoft Knowledge Base article 810591, "Exchange Server Compatibility with Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810591).


Exchange 2007 pre-release version is installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-20

The Microsoft Exchange Server Analyzer Tool queries the Active Directory directory service to determine the value of the serialNumber attribute for all Exchange Server objects in the directory. The serialNumber attribute is a string value that includes both the version of Exchange Server and if installed, the version of the service pack. For example, on an Exchange Server 2007 computer that has no Service Pack installed, the serialNumber attribute is equal to Version 8.0 (Build 0685).

If the Exchange Server Analyzer finds the value for the serialNumber attribute contains 8.0 in its string, but contains a build number that is less than 0685 in the string, an error is displayed.

This error indicates that the Exchange Server 2007 computer is running a prerelease version of Exchange Server 2007.

Prerelease installations of Exchange Server 2007 are not supported for production environments.

To address this error, install a production version of Exchange Server 2007.


Exchange 2007 server object has been moved to a different administrative group
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-08-11

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the serialNumber attribute for all Exchange Server objects in the directory.

The Exchange Server Analyzer also queries the value for the cn attribute of the administrative group the server that is running Exchange Server is homed in so that it can determine whether it is the dedicated Exchange 2007 administrative group, Exchange Administrative Group (FYDIBOHF23SPDLT).

If the Exchange Server Analyzer determines that the server is running Microsoft Exchange Server 2007, but is homed in an administrative group other than Exchange Administrative Group (FYDIBOHF23SPDLT), the Exchange Server Analyzer displays an error.

This error indicates that the server may have been manually moved from the dedicated Exchange 2007 administrative group and may be causing mail flow issues.

The serialNumber attribute is a string value that includes both the version of Exchange Server and the version of the service pack, if it is installed. A value of the serialNumber attribute equal to Version 8.0 indicates that the server is running Exchange 2007.

Microsoft Exchange Server 2003 and Microsoft Exchange 2000 Server use Administrative Groups to group Exchange objects for the purposes of delegating permission to manage those objects. Exchange 2007 does not use Administrative Groups as a logical management unit. To support coexistence between Exchange Server 2003 or Exchange 2000 Server and Exchange 2007, all Exchange 2007 servers are automatically added to a single Administrative Group when Exchange 2007 is installed. This Administrative Group is recognized in the Exchange System Manager in Exchange Server 2003 as Exchange Administrative Group (FYDIBOHF23SPDLT).

To resolve this issue, remove and reinstall the server.


Exchange resident on domain controller that is not a global catalog server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the DomainRole key. Valid values for this key are shown in the following table.

Value | Meaning
0 | Stand-alone workstation
1 | Member workstation
2 | Stand-alone server
3 | Member server
4 | Backup domain controller
5 | Primary domain controller

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine the value of the Started key for ClusSvc, the Cluster service. Additionally, the Exchange Server Analyzer queries the Win32_OperatingSystem WMI class to determine the value of the OSProductSuite key. The value of the OSProductSuite key indicates the version of Windows running on the computer.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute of all directory objects that have an object category of msExchExchangeServer. The value for the serialNumber attribute indicates the version of Exchange Server being used.

Finally, the Exchange Server Analyzer queries Active Directory to determine the value of the isGlobalCatalogReady attribute of this server. A value of True for this attribute indicates that the directory server is also a functioning global catalog server, and a value of False indicates that the directory server is not a global catalog server.

If the Exchange Server Analyzer determines that the value for the DomainRole key is greater than 3 on an Exchange Server computer; that the Exchange Server computer is not running Windows Small Business Server, Exchange Server version 5.5, or running in a Windows cluster; and that the isGlobalCatalogReady attribute is set to False, a warning is displayed.

This warning indicates that Exchange Server is running on a directory server that is not also a functioning global catalog server. This configuration is not supported, and it may cause Exchange services to fail.

If you are running Exchange Server on a domain controller without Small Business Server, consider the following issues:

  • Exchange Server and Active Directory are both resource-intensive applications. There are performance implications to be considered when both applications are running on the same computer.

  • If Exchange Server is running on a domain controller, you must also make that domain controller a global catalog server.

  • Several Exchange Server directory components, such as Directory Service Access (DSAccess), Directory Service Proxy (DSProxy), and the Message Categorizer will not fail over to any other domain controller or global catalog server.

  • You should not take advantage of the /3GB startup switch in Windows because it could cause Exchange Server to consume all memory, therefore reducing the memory available for Active Directory.

  • System shutdown will take much longer if the Exchange Server services are not stopped before you shut down or restart the server.

  • This configuration is less secure because Exchange administrators will have local administrative access to Active Directory. This enables them to elevate their own privileges. Additionally, any security vulnerability found in either Exchange Server or Active Directory exposes the other to compromise.

  • If you are running Exchange Server 2003 or Exchange Server 2007 on a domain controller, using the domain controller promotion tool (DCPromo) to change the computer role is not supported, and it is known to break components such as Microsoft Outlook® Mobile Access.

  • Running Exchange Server 2003 or Exchange Server 2007 on a clustered node that is also an Active Directory domain controller is not supported and should never be performed. In other words, if you are running Exchange 2000 Server on a node in a cluster that is also a domain controller, you must demote the server to a member server before upgrading from Exchange 2000 Server to Exchange Server 2003.

If the computer is running Exchange 2000 Server, we recommend that you demote the server to a member server using DCPromo at your earliest opportunity. If the computer is running Exchange Server 2003 or Exchange Server 2007, use one of the following procedures to correct this warning.

To correct this warning by moving Exchange to another computer

  1. Install Exchange Server on a different computer.

  2. Use Move Mailbox in the Exchange Task Wizard to move any existing mailboxes from the domain controller to the new Exchange server.

  3. Rehome any public folders and roles held by the old Exchange Server computer to the new Exchange Server computer.

  4. Uninstall Exchange Server from the domain controller.
To correct this warning by making the Exchange server a global catalog server

  1. Open Active Directory Sites and Services.

  2. Expand Sites, expand the Site, and then expand Servers.

  3. Select the domain controller that you want to specify as a global catalog server.

  4. In the right pane, right-click NTDS Settings and select Properties.

  5. On the General tab, select the Global Catalog check box. If the directory server is running Windows 2000 Server with Service Pack 2 or earlier, restart the server for the change to take effect. If the directory server is running Windows 2000 Server with Service Pack 3 or later or running Windows Server™ 2003, the change occurs dynamically without restarting the server.

For more information about installing Exchange Server on a domain controller, see the Microsoft Knowledge Base article 250989, "XADM: Installing the ADC on a Windows 2000 Domain Controller That Also Runs Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250989).


Exchange Server 5.5 detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes Version 5.5, the computer is running Microsoft Exchange Server version 5.5. If the string value includes Version 6.0, the computer is running Exchange 2000 Server. If the string value includes Version 6.5, the computer is running Exchange Server 2003.

If the Exchange Server Analyzer finds the value for serialNumber contains Version 5.5, an error is displayed.

This error indicates that the version of Exchange Server detected cannot be analyzed further by this version of the Exchange Server Analyzer.

The Exchange Server Analyzer depends on various, specific program interfaces that are unavailable in the detected version of Exchange Server.

To address this error, specify an Exchange Server that is running Exchange 2000 or a later version.

If you believe this rule has been triggered in error, verify that the value for the serialNumber attribute of the Exchange Server object in Active Directory is correctly set.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To view the value of the serialNumber attribute

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=<ExchangeOrganizationName>.

  3. Expand CN=Administrative Groups, expand CN=<AdministrativeGroupName>, and then expand CN=Servers.

  4. Right-click the server object, and then click Properties.

  5. Double-click the serialNumber attribute to display its current value.

For more information about how to deploy Exchange Server 2003, see the "Exchange Server 2003 Deployment Guide" (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about how to migrate from Exchange Server 5.5 to Exchange Server 2003, see Knowledge Base article 259912, "Prerequisites for Upgrading Exchange Server 5.5 to Exchange 2000 Server or to Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=259912).

For information about how to migrate and upgrade to Exchange Server 2003, see "Upgrade to Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=34186).


Exchange Server 5.5 is not running the latest Service Pack
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute for each Exchange Server object. The versionNumber attribute represents the version of Exchange Server that is running on the computer.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the STORE.EXE process. If the Exchange Server Analyzer determines that the Version key for STORE.EXE has a value greater than 1959, but less than 2653, a warning is displayed. This indicates that the computer is running Exchange Server 5.5 pre-Service Pack 4.

This warning indicates that the Exchange Server computer is not running the latest available code for the version of Exchange running on the computer.

To correct this warning

  1. Download Exchange Server 5.5 Service Pack 4 (http://go.microsoft.com/fwlink/?LinkId=33456).

  2. Download the latest update (May 2004) for Exchange Server 5.5 from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=33456).

  3. Review the information about this update by reading the Microsoft Knowledge Base article 841765, "May 2004 Update Rollup for Exchange Server 5.5" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=841765).

  4. Take a complete backup of the Exchange Server computer.

  5. Apply Exchange Server 5.5 Service Pack 4.

  6. Apply the May 2004 update.

For more information about installing this and other Exchange Server updates, see the Microsoft Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


Exchange Server 5.5 is not supported on Windows 2003
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of the Microsoft Windows® operating system running on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the computer is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the computer is running Windows 2000 Server, and a value of 5.2 indicates the computer is running Windows Server™ 2003.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects with an object class of msExchExchangeServer. If the string value includes Version 5.5, the computer is running Microsoft Exchange Server version 5.5. If the string value includes Version 6.0, the computer is running Exchange 2000 Server. If the string value includes Version 6.5, the computer is running Exchange Server 2003.

If the Exchange Server Analyzer finds the value for CurrentVersion equal to 5.2 and the value for serialNumber contains Version 5.5, an error is displayed. This is not a supported configuration, and you should correct this error as soon as possible.

To correct this error

  • Do one of the following:

    • Install Exchange Server 5.5 on a server that is running a supported operating system, and then move the mailboxes to that server.

    • Migrate from Exchange Server 5.5 to Exchange Server 2003.

For more information about deploying Exchange Server 2003, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about Exchange Server and Windows Server 2003, see the Microsoft Knowledge Base article 810591, "Exchange Server Compatibility with Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810591).

For more information about migrating from Exchange Server 5.5 to Exchange Server 2003, see the Knowledge Base article 259912, "Prerequisites for Upgrading Exchange Server 5.5 to Exchange 2000 Server or to Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=259912).

For information about migrating and upgrading to Exchange Server 2003, see the migration and upgrade page, "Upgrade to Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=34186).


Exchange Server 5.0 is not running the latest Service Pack or Update Rollup
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute for each Exchange Server object. The versionNumber attribute represents the version of Exchange Server that is running on the computer.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the STORE.EXE process. If the Exchange Server Analyzer determines that the Version key for STORE.EXE has a value greater than 1456 and less 1460, a warning is displayed.

This warning indicates that the Exchange Server computer is not running the latest available code for the version of Exchange running on the computer.

To correct this warning

  1. Download Service Pack 2 for Exchange Server 5.0 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=168858).

  2. Read the Service Pack 2 README.TXT file (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=168735).

  3. Visit the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=41361) to download the latest update (April 2004) for Exchange Server 5.0.

  4. Review the information about this update by reading the Microsoft Knowledge Base article 834130, "Microsoft Exchange Server 5.0 Update Rollup" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834130).

  5. Take a complete backup of the Exchange Server computer.

  6. Apply Service Pack 2 for Exchange Server 5.0.

  7. Apply the April 2004 update.

For more information about installing this and other Exchange Server updates, see the Microsoft Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


Exchange Server 5.5 resident on Active Directory domain controller
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the DomainRole key. Valid values for this key are shown in the following table.

Value | Meaning
0 | Stand-alone workstation
1 | Member workstation
2 | Stand-alone server
3 | Member server
4 | Backup domain controller
5 | Primary domain controller

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine the value of the Started key for ClusSvc, the Cluster service.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute of all directory objects that have an object category of msExchExchangeServer. The value for the serialNumber attribute indicates the version of Exchange Server being used.

If the Exchange Server Analyzer determines that the value for the DomainRole key is greater than 3 on an Exchange Server computer, that the Exchange Server computer is not running in a Windows cluster, and that the version of Exchange running is Exchange Server version 5.5, a warning is displayed.

This warning indicates that Exchange Server 5.5 is running on an Active Directory server. This situation can cause problems with Active Directory Connector (ADC) because of a potential port conflict. If ADC uses this server as a target, you should make sure that the correct Exchange Lightweight Directory Access Protocol (LDAP) port number is used. By default, the directory server listens on TCP port 389 for LDAP requests. Unless the port for Exchange is changed and ADC is configured to use the Exchange port, ADC will not be able to communicate with Exchange.

Active Directory uses the standard LDAP port 389 for LDAP access. However, using the standard port number overrides the Exchange server residing on the same server that is also trying to listen to LDAP port 389. You must reassign the Exchange LDAP port to grant the Exchange server LDAP access to its directory.

To correct this warning

  1. Open Exchange Administrator.

  2. Expand Site Name, expand Configuration, expand Protocols, and then expand LDAP (Directory) Site Defaults.

  3. Change the port assignment from 389 to a port that is currently not being used.

  4. Click OK to save the change.

  5. Restart the Microsoft Exchange Directory Service for the change to take effect.

  6. As needed, reconfigure ADC that uses this server as a target to use the new port.

For more information about how to change the LDAP port assignment in Exchange Server 5.5, see the Microsoft Knowledge Base article 224447, "XADM: How to Change LDAP Port Assignments in Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=224447).


Exchange Server DNS name resolution failure
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool attempts a Domain Name System (DNS) query against the configured DNS servers for each Exchange Server computer. This connection is made by using a custom object processor that performs a name resolution request and analyzes the results. If the Exchange Server Analyzer does not receive an Internet Protocol (IP) address as part of the query results, an error is displayed.

This error indicates that an Exchange Server computer was not found in DNS. Both Exchange Server and the Active Directory® directory service require correctly configured and healthy DNS to operate correctly. DNS registration and resolution issues can have widespread effects on the ability to send, receive, and deliver messages.

You must configure DNS correctly to ensure that Active Directory and Exchange Server will function correctly. For a more in-depth treatment of DNS configuration for Active Directory, see the Microsoft Knowledge Base article 237675, "Setting Up the Domain Name System for Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=237675).

To correct this error

  1. Review the following configuration items to ensure that DNS is healthy and that the Exchange Server DNS entries will be registered correctly:

    • DNS IP configuration

    • Dynamic zone updates

    • DNS forwarders

  2. Check for the existence of a Root Zone entry. View the Forward Lookup zones in the DNS Management console. There should be an entry for the domain. Other zone entries may exist. There should not be a dot (".") zone. If the dot (".") zone exists, delete the dot (".") zone. The dot (".") zone identifies the DNS server as a root server. Typically, an Active Directory domain that needs external (Internet) access should not be configured as a root DNS server. Manually reregister the Exchange Server IP address using Ipconfig /registerdns on the directory server after you delete the dot ("."). The Netlogon service may also need to be restarted.

  3. Manually repopulate Exchange Server DNS entries using netdiag /fix on the Exchange Server computer.

For more information about using DNS with Active Directory, see the Microsoft Knowledge Base article 323418, "How To Integrate DNS with an Existing DNS Infrastructure If Active Directory Is Enabled in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=323418).

For more information about troubleshooting DNS and Active Directory issues, see the Knowledge Base article 260371, "Troubleshooting Common Active Directory Setup Issues in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260371).


The Exchange server has been designated as a front-end and appears to host mailboxes
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Exchange Server Microsoft Windows® Management Instrumentation (WMI) object (Exchange_Server class) to determine the IsFrontEndServer value for the server. If the value is True, the Exchange server is acting as a front-end server. If the server has mailbox stores, the Exchange Server Analyzer queries the Active Directory® directory service to determine how many mailboxes are on the server. Each mailbox store object (msExchPrivateMDB class) has a multi-valued attribute homeMDBBL that lists all of the mailboxes in the store. By counting these values, the Exchange Server Analyzer obtains the total number of mailboxes on the server.

If the Exchange server is designated as a front-end server and also has more than 20 mailboxes configured, a warning is displayed.

Depending on your configuration, Exchange may need to put service mailboxes on the front-end server. For example, if the front-end server accepts Simple Mail Transfer Protocol (SMTP) mail from the Internet, the Exchange SMTP service may need a dedicated mailbox on the server. The Exchange Server Analyzer accounts for these service mailboxes by only displaying a warning if there are more than 20 mailboxes configured on the Exchange server.

You should not put user mailboxes on the front-end server. Such a configuration is not supported.

If user mailboxes reside on the front-end server, use Exchange System Manager (Exchange Server 2003 only) or Active Directory Users and Computers to move them to a suitable back-end server.

To move mailboxes (Exchange 2000 Server or Exchange Server 2003)

  1. In Active Directory Users and Computers, select the user or users whose mailboxes you want to move.

  2. Right-click the user list you selected in the previous step, and then click Exchange Tasks.

  3. In the Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

  4. Carefully read and follow the remaining steps in the wizard.

To move mailboxes (Exchange Server 2003 only)

  1. In Exchange System Manager, expand Servers, expand the server from which you want to move mailboxes, expand the Storage Group from which you want to move mailboxes, expand the Mailbox Store that contains the mailboxes that you want to move, and then click Mailboxes.

  2. In the details pane, right-click the user or users whose mailboxes you want to move, and then click Exchange Tasks.

  3. In the Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

  4. Carefully read and follow the remaining steps in the wizard.

For more information about correct configurations of Exchange front-end servers, see the Microsoft Knowledge Base article 822443, "Front-End Server Considerations in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822443).

For general recommendations about deploying and configuring Exchange front-end servers, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about errors that can occur from running user mailboxes on an Exchange front-end server, see the Knowledge Base article 273296, "XCON: Users Cannot Retrieve Mail on a Front-End Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=273296).

For more information about moving mailboxes on Exchange Server 2003, see the following Knowledge Base articles:

  • 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829)

  • 822892, "Move Mailbox Improvements in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)


This Exchange server is also a domain controller, which is not a recommended configuration
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-28

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the DomainRole key. Valid values for this key are shown in the following table.

Value | Meaning
0 | Stand-alone workstation
1 | Member workstation
2 | Stand-alone server
3 | Member server
4 | Backup domain controller
5 | Primary domain controller

In addition, the Exchange Server Analyzer also queries the Win32_Service WMI class to determine the value of the Started key for ClusSvc, the Cluster service.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute of all directory objects that have an object category of msExchExchangeServer. The value for the serialNumber attribute indicates the version of Exchange Server in use.

If the Exchange Server Analyzer determines that the value for the DomainRole key is greater than 3 on an Exchange Server computer, and that the Exchange Server computer is not running Exchange Server version 5.5 or running in a Windows cluster, a warning is displayed.

If you are running Exchange Server as a part of Microsoft Small Business Server 2000 or Windows Small Business Server 2003, you can install Exchange Server on a domain controller. However, if you are not running Exchange Server as part of Small Business Server, it is recommended that you avoid running Exchange Server on a domain controller.

If you are running Exchange Server on a domain controller without Small Business Server, be aware of the following issues:

  • Exchange Server and Active Directory are both resource-intensive applications. There are performance implications to be considered when both are running on the same computer.

  • If Exchange Server is running on a domain controller, you must also make that domain controller a global catalog server. For more information about creating a global catalog server, see the Microsoft Knowledge Base article 313994, "How to create or move a global catalog in Windows Server 2003, Windows 2000, or Small Business Server 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid= 313994).

  • Several Exchange Server directory components, such as Directory Service Access (DSAccess), Directory Service Proxy (DSProxy) and the Message Categorizer will not fail over to any other domain controller or global catalog server.

  • You should not take advantage of the /3GB startup switch in Windows because it could cause Exchange Server to consume all memory, thus reducing the memory available for Active Directory.

  • System shutdown will take considerably longer if the Exchange Server services are not stopped before shutting down or restarting the server.

  • This configuration is less secure because Exchange administrators will have local administrative access to Active Directory, enabling them to elevate their own privileges. In addition, any security vulnerability found in either Exchange Server or Active Directory exposes the other to compromise.

  • If you are running Exchange Server 2003 or Exchange Server 2007 on a domain controller, using the domain controller promotion tool (DCPromo) to change the computer role is not supported, and is known to break components such as Microsoft Outlook® Mobile Access.

  • Running Exchange Server 2003 or Exchange Server 2007 on a clustered node that is also an Active Directory domain controller is not supported and should never be done. This means that if you are running Exchange 2000 Server on a node in a cluster that is also a domain controller, you must demote the server to a member server prior to upgrading from Exchange 2000 Server to Exchange Server 2003.

If the computer is running Exchange 2000 Server, it is recommended that you demote the server to a member server using DCPromo at your earliest opportunity. If the computer is running Exchange Server 2003, use the following procedure to correct this warning.

To correct this warning

  1. Install Exchange Server on a different computer.

  2. Use Move Mailbox in the Exchange Task Wizard to move any existing mailboxes from the domain controller to the new Exchange server.

  3. Rehome any public folders and roles held by the old Exchange Server computer to the new Exchange Server computer.

  4. Uninstall Exchange Server from the domain controller.

For more information about installing Exchange Server on a domain controller, see the Microsoft Knowledge Base article 250989, "XADM: Installing the ADC on a Windows 2000 Domain Controller That Also Runs Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250989).


This Exchange server is down or unreachable
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-20

The Microsoft® Exchange Server Analyzer Tool uses remote procedure calls (RPCs) to read the CurrentVersion string value from the following registry key on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

If the Exchange Server Analyzer cannot read this registry value for any reason, an error is displayed.

To correct this error

  1. Ensure that the Exchange Server computer has been started and is connected to the network.

  2. Use the Ping command to see if the Exchange Server computer is reachable.

  3. If there is a firewall in place, check to see if RPC ports are blocked.

  4. Ensure that the Remote Registry service on the Exchange Server computer has been started.

  5. Check the permissions for the account under which the Exchange Server Analyzer Tool is running to ensure that it has sufficient permissions to read the registry on the Exchange Server computer.

For more information about troubleshooting network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about troubleshooting Exchange Server Best Practices Analyzer Tool connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?linkid=56285).


This Exchange server is running on Windows NT4.0; limited diagnostic information is available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of the Microsoft Windows® operating system running on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the computer is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the computer is running Windows 2000 Server, and a value of 5.2 indicates the computer is running Windows Server™ 2003.

If the Exchange Server Analyzer finds the value for CurrentVersion equal to 4.0, a warning is displayed.

This warning indicates that this Exchange Server computer is running Windows NT Server 4.0. Windows NT Server 4.0 does not provide as much diagnostic information as later versions of Windows Server. As a result, the Exchange Server Analyzer will only be able to gather and analyze a limited amount of information.

To correct this warning

  1. There is no immediate action to be taken. This warning is for informational purposes.

  2. Because Windows NT Server 4.0 and Exchange Server version 5.5 are reaching the end of their product lifecycle, you should consider upgrading to Windows Server 2003 and Exchange Server 2003.

For more information about the product lifecycle for Windows NT Server 4.0 and Exchange Server 5.5, see the Microsoft Support Lifecycle Web site (http://go.microsoft.com/fwlink/?LinkId=21759).

For more information about Windows Server 2003, see the product home page, "Microsoft Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=26095).

For more information about Exchange Server 2003, see the product home page, "Microsoft Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=21573).


This Exchange Server 2003 server is not running the final Service Pack 2 build
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the serialNumber attribute for all Exchange Server objects in the directory. The serialNumber attribute is a string value that includes both the version of Exchange Server and the version of the service pack, if installed. For example, on an Exchange Server 2003 computer that has Service Pack 1 installed, the serialNumber attribute is equal to Version 6.5 (Build 7638: Service Pack 2).

If the Exchange Server Analyzer finds the value for the serialNumber attribute contains 6.5 and Service Pack 2 in its string, but does not contain 7638 in the string, the Exchange Server Analyzer displays a warning.

This warning indicates that the Exchange Server 2003 computer is running a pre-release version of Exchange Server 2003 Service Pack 2.

Note:
Because Exchange Server service packs cannot be uninstalled, it is strongly recommended that you do a full backup of the computer running Exchange Server before applying any service packs.
To correct this warning

  1. Obtain the final version of Exchange Server 2003 Service Pack 2 at the Exchange Server 2003 Service Pack 2 Web site (http://go.microsoft.com/fwlink/?LinkId=52073).

  2. Review the Exchange Server 2003 Service Pack 2 Release Notes (http://go.microsoft.com/fwlink/?LinkId=52072).

  3. Completely back up the Exchange Server computer.

  4. Apply Service Pack 2 for Exchange Server 2003.

  5. Take another complete backup of the computer running Exchange Server.

For more information about how to install an Exchange Server service pack, see Microsoft Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


Exchange Server is running SharePoint Portal Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for Microsoft Windows SharePoint® Portal Server (MSDMSERV). A value of True indicates that SharePoint Portal Server is running on this Exchange server.

If the Exchange Server Analyzer determines that SharePoint Portal Server is running on an Exchange Server computer, a warning is displayed.

SharePoint Portal Server is not compatible with Exchange Server and should be removed. SharePoint Portal Server and Exchange Server are designed to work together and play a role in your organization's collaborative environment. However, SharePoint Portal Server and Exchange Server are designed to work alongside each other and are not designed to coexist on the same hardware.

To correct this warning

  • Move either Exchange Server or SharePoint Portal Server to another computer. It is recommended that you remove one of these programs from the computer.

For more information about how to move Exchange Server mailboxes, see the Microsoft Knowledge Base article 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829).

For more information about Exchange Server and SharePoint Portal Server compatibility, see Knowledge Base article 277567, "Cannot Install SharePoint Portal Server on a Computer Running Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=277567).


Exchange Server is running Virtual Server 2005 with another Exchange Server installed as a Guest
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads values in the following registry key to determine whether the server is a virtual server:

HKEY_LOCAL_MACHINE\Software\Classes\Installer\Products\354F2D7F395B57846953B997DF778AC1

The Exchange Server Analyzer also checks for the following registry value:

HKLM\Software\Microsoft\Virtual Machine\Guest\Parameters

Additionally, the Exchange Server Analyzer queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether the Microsoft Exchange Information Store service (MSExchangeIS) is running on the physical computer that is running Microsoft Virtual Server 2005.

If the Exchange Server Analyzer finds that the server is a virtual server, that the registry branch previously described exists, and MSExchangeIS is running on the physical computer, an error is displayed.

The presence of the HKLM\Software\Classes\Installer\Products\354F2D7F395B57846953B997DF778AC1 key indicates that the Exchange Server computer has Virtual Machine Additions installed. This, and the existence of the HKLM\Software\Microsoft\Virtual Machine\Guest\Parameters key means that the Exchange Server computer is running as a guest virtual computer in Virtual Server 2005.

Microsoft does not support running any version of Exchange Server on a virtual computer or on an emulator. This is true for Exchange Server running on Virtual Server 2005, Microsoft Virtual PC 2004, or any third-party virtual computer program. Exchange Server platforms are designed and tested to run only on physical hardware, particularly those hardware platforms that are listed in the Windows Server Catalog (http://go.microsoft.com/fwlink/?linkid=17219).

Additionally, running Exchange as a virtual server guest on a computer that is running Exchange Server is not a best practice because it does not allow for adequate redundancy across services.

To correct this error

  1. Move the mailboxes from the Exchange Server running under Virtual Server 2005 to a non-virtual Exchange Server computer.

  2. Rehome any public folders and transfer any roles held by the virtual Exchange server as required.

  3. Uninstall Exchange from the virtual computer to decommission and remove from your Exchange infrastructure and from the Active Directory® directory service.

For more information about moving mailboxes, see the following Microsoft Knowledge Base articles:

  • 822892, "Move Mailbox improvements in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 224975, "XADM: Differences Between Move Mailbox Methods" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

For more information about support for Exchange Server computers that are running in virtual environments, see the Knowledge Base article 320220, "Support Boundaries for Exchange Server on a Virtual Machine or an Emulation Machine" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220).

For more information about Virtual Server 2005, see "Microsoft Virtual Server 2005" (http://go.microsoft.com/fwlink/?linkid=34938).

For more information about Virtual PC 2004, see "Microsoft Virtual PC 2004" (http://go.microsoft.com/fwlink/?linkid=34663).


Exchange server running DNS services
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the DNS Server service (DNS). A value of True indicates that the DNS Server service is running on this Exchange server.

The Exchange Server Analyzer also queries the Win32_OperatingSystem WMI class to determine the value for the OSProductSuite key. The value returned for this key indicates the version of Windows operating system that is running on the Exchange Server computer.

Additionally, the Exchange Server Analyzer also queries the Active Directory® directory service to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer determines that the DNS Server service is started on an Exchange Server computer that meets the following criteria, a warning is displayed:

  • The Exchange Server computer hosts more than 100 mailboxes.

  • The Exchange Server computer is not running on Windows Small Business Server 2003 or Small Business Server 2000.

Running DNS Server service on the same computer as a production Exchange mailbox server is not recommended. Co-hosting DNS Server service and Exchange Server on the same computer in a production environment will likely lead to poor performance by one or both of the servers.

To correct this warning

  1. You should consider one of the following options to correct this warning:

    • Move either Exchange Server or DNS Server service off the computer. Completely removing one of the server applications from the computer is recommended.

    • Move the Exchange mailboxes off the server. At a minimum, you should remove the mailboxes and convert the Exchange server to a protocol or infrastructure server. This will reduce the load considerably for disk I/O and marginally for CPU (the latter depends on the Exchange infrastructure role).

    • Consider installing Small Business Server instead. If you are running Exchange in a small environment with less than 75 users where you do not require more than one Exchange server, you may benefit from installing Small Business Server. Small Business Server includes both Microsoft SQL Server™ and Exchange Server, along with other core Microsoft server applications and has been developed, tested, and optimized for a single-computer installation.

For more information about moving mailboxes and Exchange servers, see the following Microsoft Knowledge Base articles:

  • 822892, "Move Mailbox improvements in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 224975, "XADM: Differences Between Move Mailbox Methods" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

  • 297289, "How to move Exchange 2000 to new hardware and keep the same server name" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=297289)

For more information about Small Business Server, see "Microsoft Windows Small Business Server 2003" (http://go.microsoft.com/fwlink/?linkid=23456).


Exchange server running SQL Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Microsoft SQL Server™ service (MSSQLSERVER). A value of True indicates that the SQL Server service is running on this Exchange server.

The Exchange Server Analyzer also queries the Win32_OperatingSystem WMI class to determine the value for the OSProductSuite key. The value returned for this key indicates the version of Windows operating system that is running on the Exchange Server computer.

Additionally, the Exchange Server Analyzer also queries the Active Directory® directory service to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer determines that the SQL Server service is started on an Exchange Server computer that meets all the following criteria, a warning is displayed:

  • The Exchange Server computer hosts more than 100 mailboxes.

  • The Exchange Server computer is not running on Windows Small Business Server 2003 or Small Business Server 2000.

Running SQL Server on the same computer as a production Exchange mailbox server is not recommended. Both SQL Server and Exchange mailbox servers consume a large amount of memory and disk resources to operate optimally. Co-hosting SQL Server and Exchange Server on the same computer in a production environment will likely lead to poor performance by one or both of the servers. Additionally, troubleshooting and securing such an installation is not well understood.

Finally, there are a number of known interoperability issues that you may encounter if you are running SQL Server and Exchange Server on the same computer. Most of these issues are the result of version inconsistencies with files or programs common to the two servers, such as Microsoft Distributed Transaction Coordinator (MS DTC), Microsoft ActiveX® Data Objects (ADO), and OLE Database (OLE DB).

To correct this warning

  • You should consider one of the following options to correct this warning:

    • Move either Exchange Server or SQL Server off the computer. Completely removing one of these programs from the computer is recommended.

    • Move the Exchange mailboxes off the server. At a minimum, you should remove the mailboxes and convert the Exchange server to a protocol or infrastructure server. This will reduce the load considerably for disk I/O and marginally for CPU (the latter is dependent on the Exchange infrastructure role).

    • Consider installing Small Business Server instead. If you are running Exchange in a small environment where you do not require more than one Exchange server, you may benefit from installing Small Business Server. Small Business Server includes both SQL Server and Exchange Server, along with other core Microsoft server applications and has been developed, tested, and optimized for a single-computer installation.

For more information about moving mailboxes and Exchange servers, see the following Microsoft Knowledge Base articles:

  • 822892, "Move Mailbox improvements in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 224975, "XADM: Differences Between Move Mailbox Methods" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

  • 297289, "How to move Exchange 2000 to new hardware and keep the same server name" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=297289)

For more information about Small Business Server, see "Microsoft Windows Small Business Server 2003" (http://go.microsoft.com/fwlink/?linkid=23456),


Exchange server running under VMware
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-10-26

For more information about support for Exchange Server computers running in virtual environments, see the Knowledge Base article 897615, "Support policy for Microsoft software running in non-Microsoft hardware virtualization software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=897615).


This Exchange server has less than 1 GB of memory but has the /3GB and /USERVA=3030 switches in the boot.ini file
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries two Microsoft Windows® Management Instrumentation (WMI) classes to determine the amount of physical memory in the Exchange Server computer and the amount of virtual address space allocated to user mode processes. The following table describes the classes and keys being evaluated by the Exchange Server Analyzer.

Class | Key | Description
Win32_OperatingSystem | MaxProcessMemorySize | Maximum number of kilobytes of memory that can be allocated to a process.
Win32_OperatingSystem | OSProductSuite | Installed and licensed system product additions to the operating system.
Win32_ComputerSystem | TotalPhysicalMemory | Number of bytes of random access memory (RAM) installed in the computer.

If the Exchange Server Analyzer determines that the Exchange Server computer has less than 950 megabytes (MB) of RAM, and that the value for the MaxProcessMemorySize is greater than 2097024 but less than 3104640, a warning is displayed.

This warning indicates that the Exchange Server computer is not correctly configured for optimal memory usage in two respects:

  • The /USERVA=3030 startup switch has been set. This switch is necessary only on Exchange Server computers with 1 gigabyte (GB) or more of memory that are running on a Microsoft Windows Server™ 2003 operating system.

  • The /3GB startup switch has been set. This switch should only be used on Exchange Servers with 1 GB or more of memory that are running any of the following operating systems:

    • Microsoft Windows Server 2003 Standard Edition

    • Microsoft Windows Server 2003 Enterprise Edition

    • Microsoft Windows Server 2003 Datacenter Edition

    • Microsoft Windows 2000 Advanced Server

    • Microsoft Windows 2000 Datacenter Server

Important:
The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the operating systems listed previously when 1 GB or more of physical memory is installed.

If you encounter this warning on a system in which 1 GB of physical memory is installed, it could indicate that another component, such as a video card, has been allocated some of this physical memory at the hardware level, thereby making the allocated physical memory unavailable to the operating system. In these cases, the amount of memory installed physically according to Windows will be less than the actual amount of physical memory installed in the computer. If you encounter this situation, you should compare the amount of installed memory reported by the BIOS with the amount of installed memory reported by Windows.

To correct this warning on Windows Server 2003

  1. Right-click My Computer, and then click Properties. The System Properties dialog box will appear.

  2. Click Advanced.

  3. In the Startup and Recovery area, click Settings. The Startup and Recovery dialog box will appear.

  4. In the System startup area, click Edit. This will open the Windows Boot.ini file in Notepad.

  5. In the [Operating Systems] section, delete the following switches from all startup lines: /3GB /USERVA=3030

  6. Save the changes and close Notepad.

  7. Click OK twice to close the open dialog boxes and then restart the computer for the change to take effect.

To correct this warning on Windows 2000 Server

  1. In Windows Explorer, navigate to the system partition.

  2. If you cannot see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in the Windows Explorer window, click Tools, click Folder Options, and then click View. Clear the Hide protected operating system files (Recommended) check box. When prompted with the warning box, click Yes.

  3. When the Boot.ini file is visible in Windows Explorer, right-click the file, click Open With, and then click Notepad to open the file.

  4. Remove /3GB and, if present, /USERVA=3030.

  5. Save the changes and close Notepad.

  6. Restart the computer for the change to take effect.

For more information about using the /3GB and /USERVA startup switches, see the following Microsoft Knowledge Base articles:

  • 308356, "Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356)

  • 297812, "How to Use the 4GT RAM Tuning Feature" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 311901, "The effects of 4GT tuning on system Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 316739, "How to Use the /USERVA Switch in the Boot.ini File to Tune /3GB Configurations" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


This Exchange server has less than 1 GB of memory but has the /3GB switch set in the Boot.ini file
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries two Microsoft Windows® Management Instrumentation (WMI) classes to determine the amount of physical memory in the Exchange Server computer and the amount of virtual address space allocated to user mode processes running on the Exchange Server computer. The following table describes the classes and keys being evaluated by the Exchange Server Analyzer.

Class queried | Keys queried | Description
Win32_OperatingSystem | MaxProcessMemorySize | Maximum number of kilobytes of memory that can be allocated to a process.
Win32_ComputerSystem | TotalPhysicalMemory | Number of bytes of random access memory (RAM) installed on the computer.

If the Exchange Server Analyzer determines that the value for TotalPhysicalMemory is less than 1073741824, and that the value for MaxProcessMemorySize is equal to 3145600, a warning is displayed.

This warning indicates that the system has less than 950 megabytes (MB) of physical memory, but it has been configured with the /3GB startup switch in the Boot.ini file. This switch should only be used on Exchange Servers with 1 gigabyte (GB) or more of memory that are running any of the following operating systems:

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

Important:
The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the operating systems listed previously when 1 GB or more of physical memory is installed.

If you encounter this warning on a system in which 1 GB of physical memory is installed, it could indicate that another component, such as a video card, has been allocated some of this physical memory at the hardware level, thereby making the allocated physical memory unavailable to the operating system. In these cases, the amount of memory installed physically according to Windows will be less than the actual amount of physical memory installed in the computer. If you encounter this situation, you should compare the amount of installed memory reported by the BIOS with the amount of installed memory reported by Windows.

To correct this warning on Windows Server 2003

  1. Right-click My Computer, and then click Properties. The System Properties dialog box appears.

  2. Click Advanced.

  3. In the Startup and Recovery area, click Settings. The Startup and Recovery dialog box appears.

  4. In the System startup area, click Edit. This will open the Windows Boot.ini file in Notepad.

  5. In the [Operating Systems] section, delete the following switches from all startup lines: /3GB

  6. Save the changes and close Notepad.

  7. Click OK twice to close the open dialog boxes and then restart the computer for the change to take effect.

To correct this warning on Windows 2000 Server

  1. In Windows Explorer, navigate to the System Partition. This is the partition that holds the hardware-specific files such as Boot.ini and NTLDR.

  2. If you cannot see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in the Windows Explorer window, click Tools, click Folder Options, and then click View. Clear the Hide protected operating system files (Recommended) check box. When prompted, click Yes.

  3. When the Boot.ini file is visible in Windows Explorer, right-click the file, click Open With, and then click Notepad to open the file.

  4. In the [Operating Systems] section, delete the following switches from all startup lines: /3GB

  5. Save the changes and close Notepad.

  6. Restart the computer for the change to take effect.

For more information about optimizing memory usage for Exchange Server, see the following Microsoft Knowledge Base articles:

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


This Exchange server has the /3GB startup switch set in the Boot.ini file
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the amount of virtual address space allocated to user mode processes (MaxProcessMemorySize) on the Exchange Server computer.

The Exchange Server Analyzer also examines the Exchange_Server WMI class in the root\MicrosoftExchangeV2 namespace to determine the value for the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is a front-end server.

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine if the Cluster service (ClusSvc) is present and started.

Finally, the Exchange Server Analyzer queries the Active Directory® directory service to determine the count for the homeMDBBL attribute of the mailbox store object (msExchPrivateMDB). The resulting count is the number of mailboxes found on the Exchange Server computer.

If the Exchange Server Analyzer determines that the value for the MaxProcessMemorySize key is not equal to 2097024, that the IsFrontEndServer key is set to False, that the Cluster service is not running, that the Exchange Server mailbox store contains fewer than 20 mailboxes, and that Exchange is not running on Microsoft Windows Small Business Server 2003, a warning is displayed.

This warning indicates that the directory server is not properly configured for optimal memory usage because the /3GB startup switch has been set in the Boot.ini file. This switch should only be used on Exchange servers with 1 gigabyte (GB) or more of memory that are running any of the following operating systems:

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

Important:
The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the operating systems listed previously when 1 GB or more of physical memory is installed.

When the /3GB parameter is included in the Boot.ini file of a supported operating system, Windows allocates 3 GB out of a maximum of 4 GB of virtual address space to the user process and 1 GB to the kernel. Normally (when the /3GB parameter is not used), Windows allocates 2 GB to the user process and 2 GB to the kernel. Therefore, with the /3GB switch, memory-intensive applications have a larger virtual memory address space to operate in and performance is improved.

Using the /3GB switch primarily helps memory-intensive applications like the Store.exe process on an Exchange server that hosts user mailboxes. A front-end server does not host user mailboxes and, therefore, there is no benefit derived from using the /3GB switch on a front-end server.

To correct this warning

  1. In Windows Explorer, navigate to the system partition.

  2. If you are unable to see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in the Windows Explorer window, click Tools, clickFolder Options, and then click the View tab. Clear the Hide protected operating system files (Recommended) check box. When prompted with the warning box, click Yes.

  3. When the Boot.ini file is visible in Windows Explorer, right-click the file, click Open With, and choose Notepad to open the file.

  4. In the [Operating Systems] section, delete the following switches from all startup lines: /3GB

  5. Save the changes and close Notepad.

  6. Restart the computer for the change to take effect.

For more information about the use of the /3GB switch, see the following Microsoft Knowledge Base articles:

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000"

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003"

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)


This Exchange 2003 server is not running the final Service Pack 1 build (7226.6)
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the serialNumber attribute for all Exchange Server objects in the directory. The serialNumber attribute is a string value that includes both the version of Exchange Server and if installed, the version of the service pack installed. For example, on an Exchange Server 2003 computer that has Service Pack 1 installed, the serialNumber attribute is equal to Version 6.5 (Build 7226.6: Service Pack 1).

If the Exchange Server Analyzer finds the value for the serialNumber attribute contains 6.5 and Service Pack 1 in its string, but does not contain 7226.6 in the string, a warning is displayed.

This warning indicates that the Exchange Server 2003 computer is running a pre-release version of Exchange Server 2003 Service Pack 1.

Note:
Because Exchange service packs cannot be uninstalled, it is strongly recommended that you do a full backup of the Exchange Server computer before applying any service packs.

To correct this warning

  1. Obtain the final version of Exchange Server 2003 Service Pack 1 (http://go.microsoft.com/fwlink/?linkid=29090).

  2. Review the Exchange Server 2003 Release Notes (http://go.microsoft.com/fwlink/?linkid=23235).

  3. Review the updates included in Service Pack 1 (http://go.microsoft.com/fwlink/?linkid=34272).

  4. Completely back up the Exchange Server computer.

  5. Apply Service Pack 1 for Exchange Server 2003.

  6. Take another complete backup of the Exchange Server computer.

For more information about installing an Exchange Server service pack, see the Microsoft Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


This Exchange server is running Windows 2000 Server but has the /3GB switch set in the boot.ini file
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries two Microsoft Windows® Management Instrumentation (WMI) classes to determine the amount of physical memory in the Exchange Server computer, and the amount of virtual address space allocated to user mode processes. The following table describes the classes and keys being evaluated by the Exchange Server Analyzer.

Class | Key | Description
Win32_OperatingSystem | MaxProcessMemorySize | Maximum number of kilobytes of memory that can be allocated to a process.
Win32_OperatingSystem | OSProductSuite | Installed and licensed system product additions to the operating system.
Win32_ComputerSystem | TotalPhysicalMemory | Number of bytes of random access memory (RAM) installed in the computer.

If the Exchange Server Analyzer determines that the value for the MaxProcessMemorySize key is not equal to 2097024 and that the OSProductSuite key value resolves to Windows 2000 Server, an error is displayed.

This warning indicates that the directory server is not properly configured for optimal memory usage because the /3GB startup switch has been set in the Boot.ini file. This switch should only be used on Exchange servers with 1 gigabyte (GB) or more of memory that are running any of the following operating systems:

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

Important:
The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the operating systems listed previously when 1 GB or more of physical memory is installed.

To correct this error on Windows Server 2003

  1. Right-click My Computer and select Properties. The System Properties dialog will appear.

  2. Click the Advanced tab.

  3. In the Startup and Recovery area, click the Settings button. The Startup and Recovery dialog box will appear.

  4. In the System startup area, click the Edit button. This will open the Windows Boot.ini file in Notepad.

  5. In the [Operating Systems] section, delete the following switches from all startup lines: /3GB.

  6. Save the changes and close Notepad.

  7. Click OK twice to close the open dialog boxes and then restart the directory server for the change to take effect.

To correct this error on Windows 2000 Server

  1. In Windows Explorer, navigate to the system partition.

  2. If you are unable to see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in the Windows Explorer window, click Tools, click Folder Options, and then click the View tab. Clear the Hide protected operating system files (Recommended) check box. When prompted with the warning box, click Yes.

  3. When the Boot.ini file is visible in Windows Explorer, right-click the file, click Open With, and choose Notepad to open the file.

  4. Remove /3GB and save the file.

  5. Restart the directory server for the change to take effect.

For further details regarding the use of the /3GB and /USERVA startup switches, see the following Microsoft Knowledge Base articles:

  • 297812, "How to Use the 4GT RAM Tuning Feature" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 311901, "The effects of 4GT tuning on system Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 316739, "How to Use the /USERVA Switch in the Boot.ini File to Tune /3GB Configurations" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Exchange Server WMI could not be accessed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-08-24

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the Name key. If the WMI query fails, and the Exchange Server is not running on Microsoft Windows NT® Server°4.0, the Exchange Server Analyzer displays an error.

There are two likely causes for this error:

  • The account that runs the Exchange Server Analyzer does not have sufficient permissions to query WMI classes.

  • A network issue is preventing the Exchange Server Analyzer from contacting the computer.

To correct this error

  1. Make sure that the Exchange Server computer has been started and is connected to the network.

  2. Use the PING command to see if the Exchange Server computer is reachable.

  3. If there is a firewall, check to see if remote procedure call (RPC) ports are blocked.

  4. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange server that it is scanning.

    Alternatively, you can grant specific WMI permission to the account under which the Exchange Server Analyzer is running:

    1. On the Exchange computer, open the Computer Management Microsoft Management Console (MMC) tree.

    2. Under Services and Applications, right-click WMI Control, and then click Properties.

    3. On the WMI Controls Property page, click the Security tab, and then expand Root.

    4. Select the CIMV2 folder, and click Security.

    5. On the Security for ROOT\CIMV2 page, add the account under which the Exchange Server Analyzer runs.

  5. Select the account that you added in Step 5 above. In Permissions for Selected_Account, under the Allow column, select both Remote Enable and Read Security, and then click OK.

For more information about troubleshooting network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about troubleshooting Exchange Server Best Practices Analyzer Tool connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).

For more information about port requirements, see the Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


The Exchange System Attendant service is not running on this front-end server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Microsoft Exchange System Attendant service. A value of False indicates that the Exchange System Attendant service is not running. A value of True indicates that the Exchange System Attendant service is running.

The Exchange Server Analyzer also examines the Exchange_Server WMI class in the root\MicrosoftExchangeV2 namespace to determine the value of the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is a front-end server.

If the Exchange Server Analyzer finds the value for the Started key on an Exchange front-end server is set to False, a warning is displayed.

Generally, most Exchange servers will have the System Attendant service running at all times. However, sometimes running the System Attendant service is not required. For example, on a front-end server, the System Attendant service is required only for making configuration changes to the server.

Exchange Server stores all its configuration information in the Active Directory® directory service, including information about recipient policies, Simple Mail Transfer Protocol (SMTP) virtual server configuration, remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) settings, and user mailboxes. However, SMTP reads its settings from the Internet Information Services (IIS) metabase. To populate the IIS metabase with the information Exchange needs for SMTP and RPC over HTTP functionality, the directory service to metabase (DS2MB) component of the System Attendant replicates the configuration information from Active Directory to the IIS metabase. If System Attendant is not running, changes made to Exchange Server configuration settings that are stored in Active Directory will not be copied to the Exchange Server IIS metabase. If configuration changes are not being made, and if SMTP messages are not being processed, the System Attendant service can remain in a stopped state.

If you do have configuration changes to make, start the System Attendant service, make the configuration changes, and then wait for those changes to be replicated to the IIS metabase. To determine whether the changes have been replicated from Active Directory to the IIS metabase, check for the presence of three entries in the application event log of the Exchange server that have an event source of MSExchangeMU and an event ID of 1005. These events will be logged after a successful DS2MB replication. As soon as these events are logged, you can stop the System Attendant service.

Unless SMTP is being used on a front-end server, the recommended configuration is to stop the System Attendant service and then set it to disabled. On front-end servers that use SMTP, and on all other Exchange Server computers, the Exchange System Attendant service must be running to deliver messages, service SMTP and mailbox store transactions, and perform DS2MB replication.

The Exchange System Attendant service should always be running on back-end servers and any other Exchange servers that contain mailboxes or public folders.

To correct this warning

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. In the right pane, scroll down to the Microsoft Exchange System Attendant service and double-click it. This will display the System Attendant Service Properties dialog box.

  3. Set the value in the Startup type drop-down list to Automatic.

  4. Click Start to start the System Attendant service.

  5. Click OK to save the changes and close the System Attendant Service Properties dialog box.

  6. Close the Services snap-in.

For more information about disabling the System Attendant service and securing Exchange servers, see the following Exchange Server topics:

  • "Securing Exchange 2000 Servers Based on Role" (http://go.microsoft.com/fwlink/?LinkId=35585)

  • "Exchange Server 2003 Security Hardening Guide" (http://go.microsoft.com/fwlink/?LinkId=47578)


The Exchange System Attendant service is not running
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Microsoft Exchange System Attendant service. A value of False indicates that the Exchange System Attendant service is not running. A value of True indicates that the Exchange System Attendant service is running.

The Exchange Server Analyzer also examines the Exchange_Server WMI class in the root\MicrosoftExchangeV2 namespace to determine the value for the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is a front-end server.

If the Exchange Server Analyzer finds the value for the Started key is set to False on an Exchange Server computer that is not a front-end server, a warning is displayed.

Generally, most Exchange servers will have the System Attendant service running at all times. However, sometimes running the System Attendant service is not required. For example, on an Exchange 2000 Server or Exchange Server 2003 front-end server, the System Attendant service is required only for making configuration changes to the server.

Exchange Server stores all its configuration information in the Active Directory® directory service, including information about recipient policies, Simple Mail Transfer Protocol (SMTP) virtual server configuration, remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) settings, and user mailboxes. However, SMTP reads its settings from the Internet Information Services (IIS) metabase. To populate the IIS metabase with the information Exchange needs for SMTP and RPC over HTTP functionality, the directory service to metabase (DS2MB) component of the System Attendant replicates the configuration information from Active Directory to the IIS metabase. If the System Attendant is not running, changes made to Exchange Server configuration settings that are stored in Active Directory will not be copied to the Exchange Server IIS metabase. If configuration changes are not being made, and if SMTP messages are not being processed, the System Attendant service can remain in a stopped state.

If you do have configuration changes to make, start the System Attendant service, make the configuration changes, and then wait for those changes to be replicated to the IIS metabase. To determine whether the changes have been replicated from Active Directory to the IIS metabase, check for the presence of three entries in the application event log of the Exchange server that have an event source of MSExchangeMU and an event ID of 1005. These events will be logged after a successful DS2MB replication. As soon as these events are logged, you can stop the System Attendant service.

Unless SMTP is being used on an Exchange 2000 Server or Exchange Server 2003 front-end server, the recommended configuration is to stop the System Attendant service and then set it to disabled. On Exchange 2000 Server or Exchange Server 2003 front-end servers that use SMTP, and on all other Exchange Server computers, the Exchange System Attendant service must be running to be able to deliver messages, service SMTP and mailbox store transactions, and perform DS2MB replication.

The Exchange System Attendant service should always be running on back-end servers and any other Exchange servers that contain mailboxes or public folders.

To correct this warning

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. In the right pane, scroll down to the Microsoft Exchange System Attendant service and double-click it. This will display the System Attendant Service Properties dialog box.

  3. Set the value in the Startup type drop-down menu to Automatic.

  4. Click Start to start the System Attendant service.

  5. Click OK to save the changes and close the System Attendant Service Properties dialog box.

  6. Close the Services snap-in.

For more information about disabling the System Attendant service and securing Exchange Servers, see "Securing Exchange 2000 Servers Based on Role" (http://go.microsoft.com/fwlink/?linkid=35585).


Exchmem Heaps Indicating Performance Issue
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has analyzed the Exchmem Heap performance counters under the MSExchangeIS performance object to determine whether performance on the Exchange server has decreased. The Exchange Server Analyzer Tool reports on the Exchmem counters as follows:

  • If the number of Exchmem: Number of heaps with memory errors is more than zero, the Exchange Server Analyzer reports a warning. If this value is more than five, the Exchange Server Analyzer reports an error.

  • If the number of Exchmem: Number of memory errors is more than 500, the Exchange Server Analyzer reports an error.

  • If the number of Exchmem: Number Additional Heaps is more than three, the Exchange Server Analyzer reports an error.

The Store.exe process uses its own heap allocation mechanism and structures. These are called Exchmem. At startup, the Store.exe process creates several Exchmem heaps. Store.exe does not increase the number of heaps unless the existing number is either fully used or is fragmented to a point where an allocation cannot find enough contiguous memory to succeed.

If there is a memory utilization problem or internal fragmentation (that is, fragmentation in the Exchmem heaps, which reside inside the Exchange store's virtual memory space), the Store.exe process creates new Exchmem heaps.

Generally, if the Store.exe process must repeatedly create additional heaps, the overall Exchange store virtual memory becomes fragmented or depleted. By tracking the counters that are listed above, you can determine whether the Exchmem heaps are a source of the problem or if they decrease in performance as the heaps become fragmented.

To correct the warning or error

  • Download and install the latest Exchange store updates.

    • For the latest Exchange Server 2003 downloads, see the Downloads for Exchange Server 2003 Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

    • For the latest Exchange 2000 Server downloads, see the Downloads for Exchange 2000 Server Web site (http://go.microsoft.com/fwlink/?LinkId=33457).

  • Download and install the latest updates for all applications that are running in the Store.exe process. Sometimes third-party applications that are running in the Store.exe process can cause heap fragmentation.

  • Consider moving user mailboxes from the affected server to another server to reduce server load. For more information, see Move User Mailboxes to Another Server.

  • Until you have identified the cause of the problem, you can restart as necessary to reset memory.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


EXCHMEM.DLL present in Windows System32 folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine whether it can read the value of the Version key for \Windows\System32\Exchmem.dll. If the Exchange Server Analyzer can read the Version key, Exchmem.dll is present in the System32 folder.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 6", the computer is running Exchange 2000 Server or Exchange Server 2003.

The Exchange Server Analyzer displays a best practice message if the following conditions are true:

  • Exchmem.dll is present in the System32 folder.

  • The computer is running Exchange 2000 Server or Exchange Server 2003.

Ordinarily, two copies of Exchmem.dll will not exist on an Exchange server. However, sometimes a second Exchmem.dll file is added by using an in-place upgrade from previous releases of the product. The presence of two versions of the file can cause setup to fail during the installation of service packs. To prevent problems, it is recommended that you rename or remove the Exchmem.dll file in the \Windows\System32 folder.

To remove or rename a second version of Exchmem.dll

  1. Stop all Exchange services.

  2. Rename or remove the Exchmem.dll file in the \Windows\System32 folder.

  3. Restart all Exchange services.


Fatal error found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool tries to access various, specific resources to perform its analysis:

  • Microsoft Active Directory® directory service

  • Exchange Server Message Tracking Center

  • Microsoft Windows® Registry

  • Microsoft Windows® Management Instrumentation (WMI)

  • Internet Information Services (IIS) metabase

If the Exchange Server Analyzer cannot access one or more of the required resources, the Exchange Server Analyzer displays an error.

This error indicates that, because one or more of these basic resources cannot be accessed, additional analysis is not possible.

To address this error, review the resource specific error guidance and links provided by the Exchange Server Analyzer.


FCL logging is not Enabled for the server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-20

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes Version 5.5, the computer is running Microsoft Exchange Server version 5.5. If the string value includes Version 6.0, the computer is running Exchange 2000 Server. If the string value includes Version 6.5, the computer is running Exchange Server 2003.

The Exchange Server Analyzer also queries for the presence of the Disable Call Tracing subkey from following registry entry to determine whether the Microsoft Exchange Function Call Logging (FCL) feature is enabled for the Exchange server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Exchange Server can trace the performance of internal calls that the Microsoft Exchange Information Store service (Store.exe) makes. You can use FCL to isolate the component and the function call that may be the root cause of the performance issue.

The FCL functionality in the Microsoft Exchange Information Store service keeps track of the relevant calls to the following components:

  • Local Security Authentication Server (Lsass.exe)

  • DSAccess

  • Extensible Storage Engine (ESE)

  • IMAIL

  • Virusscan

FCL is low-overhead logging that gathers data about problem scenarios such as shutdown issues in Exchange Server or situations when the Exchange Information Store service (Store.exe) exhibits a decrease in performance or is unresponsive.

As soon as it is enabled, FCL automatically logs the function call data. User intervention or a specific configuration, such as acquiring a user dump file of the production server or the use of a debugger, is not required.

By default, FCL is enabled on Exchange Server 2003 but must be specifically enabled on Exchange 2000 Server.

The Exchange Server Analyzer displays a best practices message if the following conditions are true:

  • The server is running Exchange 2000 Server and the Disable Call Tracing subkey is not present or, the Disable Call Tracing subkey is present, but contains a value other than 0.

  • The server is running Exchange Server 2003 and the Disable Call Tracing subkey is present and contains a value other than 0

This best practices message indicates that FCL is disabled.

It is a recommended best practice to enable FCL on all Exchange servers.

Important:
This article contains information about how to edit the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To enable Function Call Logging on an Exchange 2000 Server

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ Disable Call Tracing

  3. In the right pane, double-click Disable Call Tracing. If the Disable Call Tracing subkey is not present, create it as a new DWORD value.

  4. Configure the Disable Call Tracing subkey with a value of 0.
Note:
By default, FCL is turned off on Exchange 2000 Server, and this value is set to 1.
  1. Close Registry Editor.

  2. Restart the Exchange Information Store service for these changes to take effect.

 To enable Function Call Logging on an Exchange Server 2003

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ Disable Call Tracing.

  3. In the right pane, double-click Disable Call Tracing.

  4. Configure the Disable Call Tracing subkey with a value of 0.
Note:
By default, FCL is turned on in Exchange Server 2003, and the Disable Call Tracing subkey was created and its value set to something other than 0 to turn it off.
  1. Close Registry Editor.

  2. Restart the Exchange Information Store service for these changes to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Free Page Table entries is at the critical threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_PerfOS_Memory Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for the FreeSystemPageTableEntries object. If the value for FreeSystemPageTableEntries is less than or equal to 5000, an error is displayed.

Microsoft Windows Server™ 2003 and Windows 2000 Server can directly address up to 4 gigabytes (GB) of memory address space, regardless of how much physical RAM is installed. From the process perspective, each element of virtual address conceptually refers to a byte of physical memory. It is the responsibility of the Virtual Memory Manager (VMM) in conjunction with processor memory manager unit (MMU) to translate or map each virtual address into a corresponding physical address. The VMM performs the mapping by dividing the RAM into fixed-size page frames, creating system page table entries (PTEs) to store information about these page frames, and mapping them. System PTEs are small kernel mode buffers of memory that are used to communicate with the disk I/O subsystem and the network. Each PTE represents a page frame and contains information necessary for the VMM to locate a page.

On an x86-based system that uses a 4 kilobyte (KB) page size, the maximum number of PTEs required to map 2 GB of address space is 524,288 (2 GB/4 KB). On a similar system using the /3GB switch, the number of PTEs required to map 3 GB of address space is 786,432 (3 GB/4 KB). On a typical system, this space is used as follows:

  • A maximum of 50,000 PTEs (approximately 195 MB address space) are reserved for general use.

  • The rest is used in mapping system cache, hyperspace, paged pool, non-paged pool, crash dump area, and so on.

This PTE pool size is automatically determined at system startup based on the amount of physical memory in the system. This pool is squeezed in between paged pool and non-paged pool, which also grows with the amount of physical memory in the system.

The system PTE pool can become heavily used and heavily fragmented. This can lead to situations where a driver may not load. Also, if the system PTE pool is depleted entirely, other parts of the system will degrade, even resulting in threads not being created, system stalls and potential system crashes.

A healthy Exchange Server computer should have at least 8,000 system PTEs available at all times. If the number of free system PTEs drops below 8,000 but remains above 5,000, the warning described in Free Page Table entries is at the warning threshold will be displayed. When the number of free system PTEs drops below 5,000, this error is displayed.

To resolve this problem, you can use the procedure that follows to configure the SystemPages registry value appropriately for your Exchange Server computer's operating system. When you are running Exchange Server 2003 Service Pack 1 (SP1) on Windows Server 2003 with 1 GB or more of RAM, it is recommended that you set the SystemPages registry key to zero. This recommendation contrasts with the recommendation for Windows 2000 Server, which is to set SystemPages to a value of 31000 decimal.

After performing the procedure that follows, you should monitor the number of free system PTEs. You can do this by monitoring the Memory | Free System Page Table Entries performance counter with the Windows System Monitor (also known as Performance Monitor). If, after making the registry change, the number of free system PTEs remains low, you should check the following to ensure your Exchange Server computer is optimally configured:

  • Drivers A malfunctioning driver is one of the most common causes of low system PTEs. Check with your hardware manufacturer to ensure that you are using the latest drivers for all of your hardware. There may be opportunities to downgrade to a more basic driver, as well. For example, computers that run server-based applications such as Exchange Server generally do not need the most advanced video drivers with all of the features. Instead, a more basic driver is often sufficient. Switching from an advanced video driver to a basic video driver should increase the number of free system PTEs.

  • System configuration If your Windows Server 2003 system has 1 GB or more of physical memory installed, you should check to ensure that its Boot.ini file is properly configured with the /3GB and /USERVA=3030 switches as described in the Microsoft Knowledge Base article 823440, "You Must Use the /3GB Switch When You Install Exchange Server 2003 on a Windows Server 2003-Based System" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440) and the Knowledge Base article 810371, "XADM: Using the /Userva Switch on Windows Server 2003-Based Exchange Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371).

  • Event logs Check the application event log on the Exchange server for errors and warnings, especially MSExchangeIS events 9582 (errors and warnings), 9665 (warning), and 12880 (error). The presence of event 9665 could also indicate that SystemPages is not configured for optimal performance. For more information about these events, see the 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).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error on a computer running Windows 2000 Server

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. In the right pane, double-click SystemPages.

  4. In the Value data field, type a value of 31000 Decimal (31000 is the decimal representation of 7918 hex. Regedit.exe defaults to hexadecimal values), and then click OK.

  5. Close the registry editor and restart the computer for the change to take effect.

To correct this error on a computer running the original release version of Windows Server 2003

  • Review the information in Microsoft Knowledge Base article 894067, "The Performance tool does not accurately show the available Free System Page Table entries in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067), to determine the actual Free System Page Table Entries.

To correct this error on a computer running Windows Server 2003 SP1

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. In the right pane, double-click SystemPages.

  4. In the Value data field, type 0, and then click OK.

  5. Close the registry editor.

  6. Right-click My Computer, and then click Properties. The System Properties dialog box will appear.

  7. Click Advanced.

  8. In the Startup and Recovery area, click Settings. The Startup and Recovery dialog box will appear.

  9. In the System startup area, click Edit. This will open the Windows Boot.ini file in Notepad.

  10. Review the [Operating Systems] section.

    1. If the /3GB switch exists but not the /USERVA=3030 switch, add the /USERVA=3030 switch to the startup line so that it is configured as /3GB /USERVA=3030.

    2. If the /3GB /USERVA=3030 switches are already configured, change the /USERVA switch value to /USERVA=2970.

  11. Save the changes and close Notepad.

  12. Click OK twice to close the open dialog boxes and then restart the computer for the changes to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about optimizing memory for Exchange Server, see the following Knowledge Base articles:

  • 894067, "The Performance tool does not accurately show the available Free System Page Table entries in Windows Server 2003" http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 823150, "How to gather data to troubleshoot Exchange Server 2003 virtual memory issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823150)

  • 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 311901, "The effects of 4GT tuning on System Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


Free Page Table entries is at the warning threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_PerfOS_Memory Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for the FreeSystemPageTableEntries object. If the value for FreeSystemPageTableEntries is more than 5000 but less than or equal to 8000, a warning is displayed.

Microsoft Windows Server™ 2003 and Windows 2000 Server can directly address up to 4 gigabytes (GB) of memory address space, regardless of how much physical RAM is installed. From the process perspective, each element of virtual address conceptually refers to a byte of physical memory. It is the responsibility of the virtual memory manager (VMM) in conjunction with processor memory manager unit (MMU) to translate or map each virtual address to a corresponding physical address. The VMM performs the mapping by dividing the RAM into fixed-size page frames, creating system page table entries (PTEs) to store information about these page frames, and mapping them. System PTEs are small kernel mode buffers of memory that are used to communicate with the disk I/O subsystem and the network. Each PTE represents a page frame and contains information required for the VMM to locate a page.

On an x86-based system that uses a 4 kilobyte (KB) page size, the maximum number of PTEs required to map 2 GB of address space is 524,288 (2 GB/4 KB). On a similar system using the /3GB switch, the number of PTEs requires to map 3 GB of address space is 786,432 (3 GB/4 KB). On a typical system, this space is used as follows:

  • A maximum of 50,000 PTEs (approximately 195 MB address space) are reserved for general use.

  • The remainder is used in mapping system cache, hyperspace, paged pool, nonpaged pool, crash dump area, and so on.

This PTE pool size is automatically determined at system startup based on the amount of physical memory in the system. This pool is squeezed in between paged pool and nonpaged pool, which also grows with the amount of physical memory in the system.

The system PTE pool can become heavily used and heavily fragmented. This could lead to situations where a driver might not load. Also, if the system PTE pool is depleted completely, other parts of the system will degrade, even resulting in threads not being created, system stalls, and potential system crashes.

A healthy Exchange Server computer should have at least 8,000 system PTEs available at all times. If the number of free system PTEs drops below 5,000, the error described in Free Page Table entries is at the critical threshold will be displayed. When the number of free system PTEs drops below 8,000, but remains above 5,000, this warning is displayed.

To resolve this problem, you can use the procedure that follows to configure the SystemPages registry value appropriately for your Exchange Server computer's operating system. When you are running Exchange Server 2003 Service Pack 1 (SP1) on Windows Server 2003 with 1 GB or more of RAM, it is recommended that you set the SystemPages registry key to zero. This recommendation contrasts with the recommendation for Windows 2000 Server, which is to set SystemPages to a value of 31,000 decimal.

After performing the following procedure, monitor the number of free system PTEs. You can do this by monitoring the Memory | Free System Page Table Entries performance counter with the Windows System Monitor (also known as Performance Monitor). If, after you make the registry change described in this article, the number of free system PTEs remains low, check the following to ensure that your Exchange Server computer is optimally configured:

  • Drivers A malfunctioning driver is one of the most common causes of low system PTEs. Contact your hardware manufacturer to ensure that you are using the latest drivers for all of your hardware. There may be opportunities to downgrade to a more basic driver, as well. For example, computers that run server-based applications such as Exchange Server generally do not need the most advanced video drivers with all of the features. Instead, a more basic driver is often sufficient. Switching from an advanced video driver to a basic video driver should increase the number of free system PTEs.

  • System configuration If your Windows Server 2003 system has 1 GB or more of physical memory installed, you should check to ensure that its Boot.ini file is properly configured with the /3GB and /USERVA=3030 switches as described in the Microsoft Knowledge Base article 823440, "You Must Use the /3GB Switch When You Install Exchange Server 2003 on a Windows Server 2003-Based System" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440) and Knowledge Base article 810371, "XADM: Using the /Userva Switch on Windows Server 2003-Based Exchange Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371).

  • Event logs Check the application event log on the Exchange server for errors and warnings, especially MSExchangeIS events 9582 (errors and warnings), 9665 (warning), and 12880 (error). Event 9665 could also indicate that SystemPages is not configured for optimal performance. For more information about these events, see the Knowledge Base article 324044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning on a computer running Windows 2000 Server

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. In the right pane, double-click SystemPages.

  4. In the Value data field, type a value of 31000 Decimal (31000 is the decimal representation of 7918 hex. Regedit.exe defaults to hexadecimal values), and then click OK.

  5. Close the registry editor and restart the computer for the change to take effect.

To correct this warning on a computer running the original release version of Windows Server 2003

  • Review the information in Microsoft Knowledge Base article 894067, "The Performance tool does not accurately show the available Free System Page Table entries in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067), to determine the actual Free System Page Table Entries.

To correct this warning on a computer running Windows Server 2003 SP1

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. In the right pane, double-click SystemPages.

  4. In the Value data field, type 0, and then click OK.

  5. Close the registry editor.

  6. Right-click My Computer, and then click Properties. The System Properties dialog box will appear.

  7. Click Advanced.

  8. In the Startup and Recovery area, click Settings. The Startup and Recovery dialog box will appear.

  9. In the System startup area, click Edit. This will open the Windows Boot.ini file in Notepad.

  10. Review the [Operating Systems] section.

    1. If the /3GB switch exists but not the /USERVA=3030 switch, add the /USERVA=3030 switch to the startup line so that it is configured as /3GB /USERVA=3030.

    2. If the /3GB /USERVA=3030 switches are already configured, change the /USERVA switch value to /USERVA=2970.

  11. Save the changes and close Notepad.

  12. Click OK twice to close the open dialog boxes and then restart the computer for the changes to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about optimizing memory for Exchange Server, see the following Knowledge Base articles:

  • 894067, "The Performance tool does not accurately show the available Free System Page Table entries in Windows Server 2003" http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 823150, "How to gather data to troubleshoot Exchange Server 2003 virtual memory issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823150)

  • 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 311901, "The effects of 4GT tuning on System Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


Front-end server is running Site Replication Service
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Exchange Server Microsoft Windows® Management Instrumentation (WMI) object (Exchange_Server class) to determine the IsFrontEndServer value for the server. If the value is True, the Exchange server is acting as a front-end server. The Exchange Server Analyzer also queries the MSExchangeSRS WMI object (Win32_Service class) to determine the value of the Started property for that object. If the value is True, the Site Replication Service is running on this server.

If the Exchange server is designated as a front-end server and also has a running instance of the Site Replication Service, a warning is displayed.

Exchange uses the Site Replication Service if your topology includes servers running Exchange Server version 5.5 and Exchange 2000 Server or Exchange Server 2003. With this service, later versions of Exchange can replicate server configuration information to Exchange Server 5.5 servers in a form that is compatible with the Exchange Server 5.5 directory, and they can also correctly process configuration information replicated from the Exchange Server 5.5 directory so it can be stored in the Active Directory® directory service. If your topology is configured to use front-end and back-end servers, the Site Replication Service should only run on back-end servers. As of Exchange 2000 Server Service Pack 2, the Site Replication Service does not function correctly on front-end servers and may cause problems.

To fix this issue, convert the front-end server to a back-end server, and configure a new front-end server. Attempting to remove the Site Replication Service from the server is not recommended.

To correct this error

  1. Configure a new front-end server.

  2. On the problem front-end server, in Exchange System Manager, under Servers, right-click the problem server, and click Properties.

  3. Clear the This is a front-end server check box.

For more information about the front-end server and Site Replication Service, see the Microsoft Knowledge Base article 313646, "Services are Disabled on Front-end Servers After an Exchange 2000 Server SP2 Upgrade" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=313646).


GAPI32.DLL file is missing from bin folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


GAPI32.DLL file is missing from system32 folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To fix this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


GlobalFlag has been set
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine the value for the GlobalFlag entry:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\STORE.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MAD.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\INETINFO.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\EMSMTA.EXE

If the Exchange Server Analyzer finds the value for GlobalFlag to be present and configured with any value other than 0 or null, a warning is displayed.

The GlobalFlag registry value setting is a bitmask that determines what debugging options have been enabled for a particular process. In this case, the Exchange Server Analyzer is specifically looking to see if any debugging options have been enabled for a variety of Exchange components:

  • STORE.EXE (the information store process)

  • MAD.EXE (the system attendant process)

  • INETINFO.EXE (the IIS admin and parent process)

  • EMSMTA.EXE (the message transfer agent process)

Unless you are actively engaged in debugging or tracing a problem with the help of Microsoft Product Support Services, it is recommended that the GlobalFlag value be set to 0 at all times, or deleted completely, which has the same effect.

By default, the GlobalFlag registry value is not present and must be manually added if debugging of the STORE.EXE process (or any other process) is required. You can use the Gflags tool included with Microsoft Windows Server™ 2003 Support Tools, on the Windows CD in the \Support folder. Alternatively, you can manually set the value to 0, or delete the GlobalFlag value completely by using a registry editor. Both procedures are described in this article.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error using Gflags

  1. Click Start, click Run, and in the Open field execute GFlags. The Global Flags user interface will appear.

  2. In the Image File Name field, type STORE.EXE.

  3. Select Image File Options.

  4. Clear all the check boxes, and then click Apply.

  5. Repeat steps 2 through 4 for each of the Exchange processes listed in this article.

  6. Click OK to exit the GFlags tool and restart the affected services for the change to take effect.

To correct this error using a registry editor

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\STORE.EXE

  3. Delete the value called GlobalFlag.

  4. Repeat steps 2 and 3 for each of the Exchange processes listed in this article.

  5. Exit the registry editor and restart the affected services for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


A high number of ACL upgrade failures are occurring
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft Windows® Management Instrumentation (WMI) class to determine the current value of the ACLUpgradefailures key. The ACLUpgradefailures key represents the ACL Upgrade: failures performance counter under the MSExchangeIS performance object.

If the Exchange Server Analyzer finds that the value for the ACLUpgradefailures key is larger than 500, the Exchange Server Analyzer displays a warning.

This warning indicates that the Exchange server has reported many access control list (ACL) upgrade failures. Excessive ACL upgrade failures can cause severe performance problems that include random stops in the Information Store process (store.exe).

ACL upgrade failures can occur for a variety of reasons and are known to occur when the following conditions are true:

  • In a mixed mode Exchange organization, the Exchange Server version 5.5 consistency adjuster was not run before you implemented the Active Directory Connector (ADC) server. The Exchange Server 5.5 consistency adjuster removes orphaned ACLs.

  • Active Directory replication is not working correctly.

  • Active Directory Connector replication is not correctly replicating accounts over from Exchange Server 5.5 to Active Directory.

  • There was an incorrect migration of user accounts.

To correct this warning

  1. Review the Microsoft Knowledge Base article 812963, "Using the Ignore Zombie Users Registry Key" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812963).

  2. After you understand the implications of using the Ignore Zombie Users registry key, add the key at your own discretion.

  3. Run the Exchange Server Analyzer or monitor the ACL Upgrade: failures performance counter to look for excessive ACL upgrade failures.


Highly Active Exmon User
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether a user or a process (or a group of users or processes) is the cause of a disproportionately large percentage of the current server load.

There are several scenarios that ExMon evaluates:

  • Client restrictions

  • High bulk remote procedure call (RPC) operations

  • High RPC synchronization operations

  • Large number of client online operations

  • User view operations

The following sections provide details about and recommended actions for each scenario.

Client Restrictions

In this scenario, the ExMon RPC data indicates that client computer restrictions are causing a high load on this server. In the context of MAPI, a restriction refers to the MAPI operation called Restrict. This operation is used to select items that match particular criteria. The Restrict operation is part of the process to request that Exchange creates a view on a folder or set of folders (effectively, a database table with associated criteria). If the view on the folder or set of folders already has a matching restriction, Exchange uses the existing view to satisfy the user request. If a view does not have a matching restriction, Exchange creates a new view. Creating a view is more costly than using an existing view.

After many mailbox moves, client restrictions will be more costly for a short time. The move-mailbox operation causes a server to rebuild indexes on folders. Therefore, when clients view folders for first time on new server, all restrictions must be created anew and, as a result, performance may be poor. If you have not moved mailboxes recently, investigate that the following:

  • Another MAPI application is not installed on the client computers. Frequently, Microsoft Office Outlook® add-ins or other MAPI applications may cause too many restrictions to be created.

  • Mailboxes are sized and limits are set appropriately throughout your organization.

For more information about mailbox size and item numbers, see the Microsoft Exchange Team blog, "Recommended Mailbox Size Limits" (http://go.microsoft.com/fwlink/?linkid=55097).

High Bulk RPC Operations

Examples of high bulk RPC operations include moving, deleting, or setting properties (that is, the read flag) on hundreds or thousands of items in one operation. These types of operations may cause poor server performance for a short time. If you perform high bulk RPC operations frequently, and the server becomes bottlenecked at the disk or the processor, Outlook performance for the other users on the same server will be decreased.

To correct this error

  1. Verify that mailbox limits are set.

  2. Recommend that your users archive items to .pst files.

    Note:
    As a general best practice, folders that are used frequently should contain fewer than 5,000 items.

High RPC Synchronization Operations

High RPC synchronization operations indicate that many users are currently synchronizing items. As a result, server load is increased.

To correct this error

  • Make sure that you have scaled your Exchange servers according to how many client computers are running Outlook in Cached Exchange Mode. For more information, see Exchange Server 2003 RPC over HTTP Deployment Scenarios (http://go.microsoft.com/fwlink/?LinkId=47577).

  • Slowing down Cached Exchange Mode client requests may help prevent high RPC synchronization operations from becoming a performance problem. For more information, see Microsoft Knowledge Base article 818484, "Registry Values and Counters That You Can Use to Configure and Monitor Outlook Client Synchronization" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=818484).

Large Number of Client Online Operations

Sometimes, Exchange may experience an unusual spike in performance problems caused by high load that is distributed across users. This may be the result of poor planning as an organization grows. If you followed Microsoft best practices when scaling your organization, but you still experience poor performance caused by many client online operations, this may indicate that your users are running third-party MAPI applications or Outlook plug-ins.

User View Operations

ExMon RPC data indicates that a user is building new views, which causes high load on the server. In this scenario, a single user accounts for a significant percentage of the RPC CPU utilization.

To investigate this issue, consider the following scenarios:

  • The user may be performing operations on a folder that contains many items. To correct this problem, encourage users to reduce the number of items in any single folder. As a general best practice, folders should contain less than 2,000 items.

  • The user may be running a poorly written application that is causing excessive load. To correct this problem, remove the application.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about mailbox size and item numbers, see the Microsoft Exchange Team blog, "Recommended Mailbox Size Limits" (http://go.microsoft.com/fwlink/?linkid=55097).

  • For more information about mailbox restrictions, see the Microsoft Exchange Team blog, "Putting the Restrictions on Restrictions" (http://go.microsoft.com/fwlink/?LinkId=55098).

  • For more information about ExMon, see the ExMon download Web site (http://go.microsoft.com/fwlink/?LinkId=54983).


IIS is Creating 32-bit processes on a 64-bit Machine
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-05-03

The Microsoft Exchange Server Analyzer tool queries the Internet Information Services (IIS) metabase for the value of the w3svc/AppPools/Enable32BitAppOnWin64 metabase property on all 64-bit Windows Server 2003 Service Pack 1 (SP1) servers that are running Exchange Server 2007 to determine whether IIS is configured to create 32-bit worker processes.

A value of 1 (true) indicates that IIS is configured to create 32-bit worker processes. A value of 0 (false) indicates that IIS is configured to create 64-bit worker processes.

If the Exchange Analyzer determines that the value for the w3svc/AppPools/Enable32BitAppOnWin64 metabase property is set to 1 (true), the Exchange Analyzer displays an error. This error indicates that IIS is configured to create 32-bit worker processes on a 64-bit Windows server that is running Exchange 2007. This configuration will cause the Exchange 2007 virtual directories to become dysfunctional.

To address this error, configure IIS to create 64-bit worker processes on the 64-bit Windows Server 2003 (SP1) server that is running Exchange 2007.

To switch IIS to 64-bit mode

  1. Open a command prompt.

  2. Type the following:

    cscript c:\inetpub\adminscripts\adsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 False

  3. Press enter

For more information about running IIS 6.0 32-bit worker processes on 64-bit Windows Server 2003 SP1 server, see Microsoft Knowledge Base article 895976 "Windows Server 2003 SP1 enables WOW64 compatibility for 32-bit Web applications in IIS 6.0" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=895976).


Improve Kernel Memory
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool tests system memory levels to verify that they are within an acceptable range. If the Exchange Server Analyzer finds that any of the Performance Monitor (Perfmon) kernel memory counters are below appropriate levels, the Exchange Server Analyzer displays a troubleshooting message.

Microsoft Windows® kernel memory consists of several memory structures, including paged and non-paged pool memory and system page table entries. These memory structures, also referred to as kernel memory, are used by the operating system to provide an environment for applications such as Exchange. To maintain a healthy Exchange deployment, make sure that you monitor the kernel memory.

Optimizing kernel memory can be a complex task. For detailed information about kernel memory usage, including troubleshooting information, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588). One consideration for freeing up server resources is to look at the user mailbox load on the server. Consider moving user mailboxes to another server to reduce server load and see if the problem stops. For more information, see Move User Mailboxes to Another Server.

For More Information

For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information on moving user mailboxes to reduce server load, see Move User Mailboxes to Another Server


Improve User Memory
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-28

The Microsoft® Exchange Server Analyzer Tool has determined that the user memory performance counters are above the threshold of what is considered healthy for the Exchange server. The Exchange Server Analyzer queries the Available Mbytes performance counter and the Memory Pages/sec counter under the Memory performance object. When the server is low on memory or has high paging, it indicates a memory bottleneck.

The Available MBytes performance counter shows the amount of physical memory in megabytes (MB) immediately available for allocation to a process or for system use. The amount of memory available is equal to the sum of memory assigned to the standby (cached), free, and zero page lists.

Memory Pages/sec performance counter indicates the rate at which pages are read from or written to disk to resolve hard page faults. As the server uses memory and free memory becomes scarce, the operating system starts trimming the working set of the process and using the page file more aggressively. Using the page file affects overall performance because disk operations take longer than memory operations. This counter is a primary indicator of the types of faults that cause system-wide delays. It includes pages retrieved to satisfy page faults in the file system cache. These pages are usually requested by applications. This counter should be below 1,000 at all times.

If the Exchange Server Analyzer finds that the Available Mbytes performance counter indicates less than 50 MB of memory is available or that the rate at which Memory Pages are being written or read to or from disk is greater than 1,000 pages per second, the Exchange Server Analyzer displays an error.

The following list describes how you can improve the performance of user space memory.

To address this issue

  1. Use the Microsoft Exchange Server Best Practices Analyzer Tool (http://go.microsoft.com/fwlink/?LinkId=34705) to verify that the memory settings for the server are configured appropriately.

  2. Remove superfluous software. To make more memory resources available for Exchange, remove any third-party software tools that perform monitoring functions or any type of non-essential service. The Performance snap-in (Perfmon.msc) can help you to understand how much memory applications are consuming.

  3. Run server maintenance tasks off peak times. Running maintenance tools (such as Eseutil) or tasks (such as mailbox management) during peak times can use memory that would otherwise be used by Exchange. As a best practice, run these tools and tasks during non-peak times or during low usage periods.

  4. Consider moving user mailboxes from the affected server to another server to reduce server load. For more information, see Move User Mailboxes to Another Server.

For More Information

For more information, see the following Microsoft resources:

  • Move User Mailboxes to Another Server

  • Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

  • "Optimizing Memory Usage in Exchange Server 2003" in the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576)

  • Microsoft Exchange Server Best Practices Analyzer Tool (http://go.microsoft.com/fwlink/?LinkId=34705)

  • Microsoft Knowledge Base article 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • "Exchange 2003 Memory Configuration change for Windows 2003 (PAE Support)" (http://go.microsoft.com/fwlink/?LinkId=54979)

    Note:
    The content of each blog and its URL are subject to change without notice.


Improve Virtual Memory
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that your server as virtual memory fragmentation issues.

In 32-bit Microsoft Windows® systems, there are two kinds of memory:

  • Physical memory Amount of actual memory installed in the system

  • Virtual memory address space A virtualized 4-GB memory space

Regardless of how much physical memory is installed on the system, the total size of the virtual address space is always the same: 4 GB. Although it is not the case for all 32-bit applications, in the case of Exchange Server, virtual address space equals virtual memory. The terms are used interchangeably.

During the normal course of its operations, the Exchange store will repeatedly allocate, use, and de-allocate virtual memory. When virtual memory is allocated, used, and de-allocated frequently, virtual memory fragmentation can result. Virtual memory fragmentation is analogous to file system fragmentation that can occur over time. After a while, allocated segments of virtual memory are no longer contiguous, and performance begins to suffer. In the case of the file system, you can run an application that performs defragmentation of the file system. In most cases, defragmentation can be done while the system is online and being accessed. In the case of virtual memory fragmentation, there is no defragmentation tool. Instead, to correct the problem, you must stop and start the Microsoft Exchange Information Store service or reboot the system.

Virtual memory fragmentation can be caused by third-party software running in the store/inetinfo processes. Make sure you have the latest drivers for any third-party applications. If the problem is reproduced after restarting, consider disabling third-party software or moving user mailboxes to another server to reduce server load and see if the problem stops. For more information, see Move User Mailboxes to Another Server.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about troubleshooting virtual memory fragmentation in Microsoft Exchange Server 2003 and Exchange 2000 Server, see Microsoft Knowledge Base article 325044, "How to troubleshoot virtual memory fragmentation in Exchange Server 2003 and Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044).

  • For more information about how to optimize virtual memory usage, see Knowledge Base article 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372).

  • For more information about moving user mailboxes to reduce server load, see Move User Mailboxes to Another Server.


Intelligent Message Filter is not installed on one or more servers running Exchange Server 2003
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchExchangeServer attribute for each Exchange Server object in the organization. The Exchange Server Analyzer uses the results of this query to determine the total number of servers in the organization that are running Exchange Server 2003. The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine whether Microsoft Exchange Intelligent Message Filter is installed on all the Exchange Server 2003 servers in the organization. If the Exchange Server Analyzer finds that Intelligent Message Filter is not installed on one or more servers running Exchange Server 2003, the Exchange Server Analyzer displays a best practice message.

Intelligent Message Filter identifies messages that are likely to be unsolicited commercial e-mail (UCE). In a typical Exchange Server 2003 topology, Intelligent Message Filter is installed on gateway servers to filter incoming Internet e-mail messages. If you use a non-Microsoft e-mail system as your Internet gateway server, you should install Intelligent Message Filter on the Exchange bridgehead server that accepts incoming Internet e-mail messages from your gateway servers.

To install Intelligent Message Filter, use an account that has local administrative rights and a member of a group that has been assigned the Exchange Administrator role.

For more information, see "Exchange Intelligent Message Filter" (http://go.microsoft.com/fwlink/?LinkId=21607).


ISA Server 2000 Update is available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the version of the smtpfltr.dll file that is used by the Microsoft Internet Security and Acceleration (ISA) Server 2000 Simple Mail Transfer Protocol (SMTP) Message Screener feature. If the Exchange Server Analyzer finds that the value of the version number is older than 2004, a warning is displayed.

This warning indicates that a more recent version of ISA Server 2000 is available. It is recommended that you install ISA Server 2000 Service Pack 2. Upgrading to Service Pack 2 is especially critical if you are running the SMTP Message Screener feature. Older versions of the SMTP Message Screener cause a bottleneck and subsequently degrade overall message throughput performance.

To correct this warning

  1. Download ISA Server 2000 Service Pack 2 from the Microsoft Download Center (http://go.microsoft.com/fwlink/?linkid=37592).

  2. Review the Service Pack 2 Release Notes (http://go.microsoft.com/fwlink/?linkid=37584).

  3. Install Service Pack 2 using the instructions in the Release Notes.

For more information about ISA Server downloads, including ISA Server 2000 Service Pack 2, see "ISA Server 2000 Downloads" (http://go.microsoft.com/fwlink/?LinkId=18919).


Journaling recipient is not valid
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-27

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the value for the mailNickname attribute on the journaling recipient object is valid. The nickname must be set for the mailNickname attribute to be valid. If the mailNickname attribute for the nominated journaling recipient object is not valid, journaling messages will queue. Also, the invalid mailNickname may indicate that journaling has been configured to copy journaling messages to a recipient object that is mailbox-disabled. If the Exchange Server Analyzer finds that the value for the mailNickname attribute for the journaling recipient object is not valid, the Exchange Server Analyzer displays an error.

To correct this error for Exchange Server 2003, use Active Directory Users and Computers and Exchange System Manager to accomplish the following as required:

  • Mailbox-enable the journal-recipient object.

  • Designate a new user mailbox as the journaling recipient.

To correct this error for Exchange Server 2003, use Active Directory Users and Computers and Exchange System Manager to accomplish the following as required

To mailbox-enable the journal recipient object for Exchange Server 2003

  1. Open Active Directory Users and Computers.

  2. In the console tree, expand the domain.

  3. Navigate to the parent container of the recipient that you want to modify.

  4. In the details pane, right-click the recipient that you want to modify and select Exchange Tasks.

  5. In the Exchange Tasks Wizard, from the Available Tasks dialog box, select Create Mailbox and then click Next.

  6. On the Create Mailbox dialog box, verify the information for the Alias, Store, and Mailbox Server fields, and then click Next.

  7. Click Finish to close the Exchange Tasks Wizard.
To designate a new user mailbox as the journaling recipient Exchange Server 2003

  1. Start Exchange System Manager.

  2. Expand Servers, expand <your Exchange server>, expand <storage group>, and then right-click the mailbox store and select Properties.

  3. Click Browse, to the right of the Archive all messages sent or received by mailboxes on this store text, to specify a mailbox as the journaling mailbox.

    Note:
    All journalized messages for senders on this mailbox store are sent to the mailbox you specify.

To correct this error for Exchange Server 2007, use the Exchange Management Console or the Exchange Management Shell to accomplish the following as required:

  • Create a mailbox for the journal-recipient object.

  • Designate a new user mailbox as the journaling recipient.

To mailbox-enable the journal recipient object for Exchange Server 2007 using the Exchange Management Console

  1. In Exchange Management Console, expand Recipient Configuration, right-click the Mailbox object, and then select New Mailbox to start the New Mailbox wizard.

  2. At the Introduction window, select User Mailbox and click Next.

  3. At the User Type window, select Existing user and use the Browse button to select the journal recipient object to create the mailbox for.

  4. At the Mailbox Settings window, verify the information for the Alias, Server, Storage Group, and Mailbox Database fields, and then click Next.

  5. At the New Mailbox window, click New to create the mailbox for the journal recipient object.

  6. Click Finish to close the New Mailbox wizard
To mailbox-enable the journal recipient object for Exchange Server 2007 using the Exchange Management Shell

  1. Follow the guidance in the Exchange Server 2007 product documentation, "Enable-Mailbox" (http://go.microsoft.com/fwlink/?LinkID=80827)

To designate a new user mailbox as the journaling recipient in Exchange Server 2007

  1. In Exchange Management Console, expand Server Configuration, expand <your Exchange server>, expand <storage group>, right-click the mailbox database, and then select Properties.

  2. On the General tab, under Journal Recipient, click Browse to specify a mailbox as the journaling mailbox.

For more information about how to deploy a journaling solution with Exchange Server 2003, see Journaling with Exchange Server (http://go.microsoft.com/fwlink/?LinkId=47581).

For more information about deploying a journaling solution with Exchange Server 2007, see Overview of Journaling (http://go.microsoft.com/fwlink/?LinkId=80820)


Journaling recipient points to a deleted object
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-01

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the value for the msExchMessageJournalRecipient attribute contains the string DEL:. This attribute indicates that journaling has been configured to copy messages to a mailbox that has been deleted. For journaling to work correctly there must be a valid journaling recipient mailbox where the copied messages are sent. The msExchMessageJournalRecipient attribute is set when journaling is enabled on a mailbox database. This attribute is a mailbox database attribute and holds the distinguished name of the journaling mailbox.

If the journaling recipient mailbox has been deleted, journaling messages will start to queue. If the Exchange Server Analyzer finds that the value for the msExchMessageJournalRecipient attribute contains the string DEL:, the Exchange Server Analyzer displays an error.

To correct this error, use Exchange System Manager or Exchange Management Console to designate a new mailbox as the journaling recipient.

To designate a new user mailbox as the journaling recipient in Exchange Server 2003

  1. Start Exchange System Manager.

  2. Expand Servers, expand <your Exchange server>, expand <storage group>, and then right-click the mailbox store and select Properties.

  3. Click Browse, to the right of the Archive all messages sent or received by mailboxes on this store text, to specify a mailbox as the journaling mailbox.

    Note:
    All journalized messages for senders on this mailbox store are sent to the mailbox you specify.
To designate a new user mailbox as the journaling recipient in Exchange Server 2007

  1. In Exchange Management Console, expand Server Configuration, expand <your Exchange server>, expand <storage group>, right-click the mailbox database, and then select Properties.

  2. On the General tab, under Journal Recipient, click Browse to specify a mailbox as the journaling mailbox.

For more information about how to deploy a journaling solution for Exchange Server 2003, see Journaling with Exchange Server (http://go.microsoft.com/fwlink/?LinkId=47581).

For more information about deploying a journaling solution with Exchange Server 2007, see Overview of Journaling (http://go.microsoft.com/fwlink/?LinkId=80820).


Journaling recipient points to a disabled account
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the value for the msExchUserAccountControl attribute on the journaling recipient object is set to indicate a disabled user account. If the value of the journaling recipient object msExchUserAccountControl attribute is 2, this indicates that journaling has been configured to copy journaling messages to a user account that is disabled. This configuration can cause the journaling messages to queue or to be sent to the Badmail folder. If the Exchange Server Analyzer finds that the value of the journaling recipient's msExchUserAccountControl attribute is set to indicate a disabled journaling recipient user account, Exchange Server Analyzer displays an error.

To correct this error for Exchange Server 2003, use Active Directory Users and Computers and Exchange System Manager to accomplish the following as required:

  • Enable the current journaling recipient's user account.

  • Designate a new user mailbox as the journaling recipient.

To enable the journal recipient account for Exchange Server 2003

  1. Open Active Directory Users and Computers.

  2. In the console tree, expand the domain.

  3. Navigate to the parent container of the journal recipient that you want to modify.

  4. In the details pane, right-click the recipient that you want to modify and select Enable Account.
To designate a new user mailbox as the journaling recipient for Exchange Server 2003

  1. Start Exchange System Manager.

  2. Expand Servers, expand <your Exchange server>, expand <storage group>, and then right-click the mailbox store and select Properties.

  3. Click Browse, to the right of the Archive all messages sent or received by mailboxes on this store text, to specify a mailbox as the journaling mailbox.

    Note:
    All journalized messages for senders on this mailbox store are sent to the mailbox you specify.

To correct this error for Exchange Server 2007, use the Exchange Management Console or the Exchange Management Shell to accomplish the following as required:

  • Create a mailbox for the journal-recipient object.

  • Designate a new user mailbox as the journaling recipient.

To mailbox-enable the journal recipient object for Exchange Server 2007 using the Exchange Management Console

  1. In Exchange Management Console, expand Recipient Configuration, right-click the Mailbox object, and then select New Mailbox to start the New Mailbox wizard.

  2. At the Introduction window, select User Mailbox and click Next.

  3. At the User Type window, select Existing user and use the Browse button to select the journal recipient object to create the mailbox.

  4. At the Mailbox Settings window, verify the information for the Alias, Server, Storage Group, and Mailbox Database fields, and then click Next.

  5. At the New Mailbox window, click New to create the mailbox for the journal recipient object.

  6. Click Finish to close the New Mailbox wizard
To mailbox-enable the journal recipient object for Exchange Server 2007 using the Exchange Management Shell

  1. Follow the guidance in the Exchange Server 2007 product documentation, "Enable-Mailbox" (http://go.microsoft.com/fwlink/?LinkId=80827).

To designate a new user mailbox as the journaling recipient in Exchange Server 2007

  1. In Exchange Management Console, expand Server Configuration, expand <your Exchange server>, expand <storage group>, right-click the mailbox database, and then select Properties.

  2. On the General tab, under Journal Recipient, click Browse to specify a mailbox as the journaling mailbox.

For more information about how to deploy a journaling solution with Exchange Server 2003, see Journaling with Exchange Server (http://go.microsoft.com/fwlink/?LinkId=47581).

For more information about deploying a journaling solution with Exchange Server 2007, see Overview of Journaling (http://go.microsoft.com/fwlink/?LinkID=80820).


Journaling recipient points to the local server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the value for the msExchHomeServerName attribute on the journaling recipient object for a mailbox store matches the value for the legacyExchangeDN attribute for the local server. If the values of these attributes match, this indicates that journaling messages are copied to a mailbox on the server that has active journaling running against it. Because of the high volume of journaling traffic that can be generated, it is recommended that the journal recipient mailbox reside on a dedicated journaling server.

If the Exchange Server Analyzer finds that the values for the msExchHomeServerName attribute for the journaling recipient object matches the value for the legacyExchangeDN of the local server, the Exchange Server Analyzer displays a best practice message.

For more information about how to deploy a journaling solution with Exchange Server 2003, see Journaling with Exchange Server (http://go.microsoft.com/fwlink/?LinkId=47581).

For more information about deploying a journaling solution with Exchange Server 2007, see Overview of Journaling (http://go.microsoft.com/fwlink/?LinkId=80820).


Journaling recipient should be hidden
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the value for the msExchHideFromAddressLists attribute of the journaling recipient object is set to True. A value other than True for this attribute indicates that the journaling recipient for the mailbox store is not hidden from Exchange Server address lists and could become the recipient of non journaling related messages. If the Exchange Server Analyzer finds that the value for the msExchHideFromAddressLists attribute for the journaling recipient object is not set to True, the Exchange Server Analyzer displays a best practice message.

To address this issue for Exchange Server 2003, use the Active Directory Users and Computers tool to hide the journaling recipient mailbox from Exchange Server address lists.

To address this issue for Exchange Server 2007, use the Exchange Management Console to hide the journaling recipient mailbox from Exchange Server address lists.

To hide the nominated journal recipient mailbox from Exchange Server address lists with Exchange Server 2003

  1. Open Active Directory Users and Computers.

  2. In the console tree, expand the domain.

  3. Navigate to the parent container of the recipient that you want to modify.

  4. In the details pane, double-click the recipient that you want to modify.

  5. On the Exchange Advanced tab, select the Hide from Exchange address Lists check box.

  6. Click OK.
To hide the nominated journal recipient mailbox from Exchange Server address lists with Exchange Server 2007

  1. Open Exchange Management Console

  2. In the console tree, Navigate to the parent container of the recipient that you want to modify.

  3. In the detail pane, double-click the mailbox object for the designated journaling recipient to display its properties.

  4. On the General tab, select the Hide from Exchange address lists check box.

  5. Click OK.

For more information about how to deploy a journaling solution with Exchange Server 2003, see Journaling with Exchange Server (http://go.microsoft.com/fwlink/?LinkId=47581).

For more information about how to deploy a journaling solution with Exchange Server 2007, see Overview of Journaling (http://go.microsoft.com/fwlink/?LinkId=80820).


Junk store threshold not configured
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-07-30

The Microsoft Exchange Analyzer Tool queries the Exchange environment for the presence of Exchange Server 2007 Hub Transport or Mailbox server roles.

If either Exchange Server 2007 Hub Transport or Mailbox server roles are found, the Exchange Analyzer executes the following Exchange Management Shell cmdlet to query for value of the SCLJunkThreshold parameter for the Exchange organization:

Get-OrganizationConfig

The SCLJunkThreshold parameter for an organization specifies the Spam Confidence Level (SCL) at which a message is moved to the Junk E-mail folder.

If the Exchange Analyzer determines that the SCLJunkThreshold parameter for an organization is set to the default value of 8, the Exchange Analyzer displays a warning.

This warning indicates that the spam confidence level threshold for moving messages to the Junk E-mail folder is set so that mail from legitimate users may be filtered and moved to the Junk E-mail folder as Junk Mail. The recommended value for the SCLJunkThreshold parameter is 4.

To address this warning, use the Set-OrganizationConfig cmdlet in the Exchange Management Shell to set the value of the SCLJunkThreshold parameter to 4.

To set the value of the SCLJunkThreshold parameter to 4 using the Set-OrganizationConfig cmdlet

  1. The following code is an example of the Set-OrganizationConfig command that sets the value of the SCLJunkThreshold parameter to 4.

  2. Set-OrganizationConfig -SCLJunkThreshold 4


Kernel memory depletion
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-15

The Microsoft Exchange Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows Management Instrumentation (WMI) class to determine whether an Event 2000, Event 2019, or Event 2020 error has been logged for the SRV (server) or NCP Server source within the last 24 hours.

  • An SRV (server) Event ID 2000 indicates a server's call to a system service failed unexpectedly due to a general system kernel memory depletion.

  • An SRV Event ID 2019 indicates a depletion of the system non-paged pool memory.

  • An SRV Event ID 2020 indicates a depletion of the system paged pool memory.

If the Exchange Analyzer finds that one or more of these events has been logged within the last 24 hours, the Exchange Analyzer displays an error.

This warning indicates that the server's kernel memory is depleted and the server may be experiencing performance issues.

Microsoft Windows kernel memory consists of several memory structures, including paged and non-paged pool memory and system page table entries. These memory structures, also referred to as kernel memory, are used by the operating system to provide an environment for applications such as Exchange.

To address this issue, follow the guidance of the issue-specific Exchange Analyzer articles listed below:

  • Improve Kernel Memory

  • Paged pool is over the warning threshold

  • Nonpaged Pool is over the warning threshold

  • Nonpaged Pool is over the error threshold

In general, to maintain a healthy Exchange deployment, make sure that you regularly monitor the Exchange Server's kernel memory.

For More Information

For more information about SRV Events 2000, 2019, or 2020 see the "Events and Errors Message Center: Event Details"

  • SRV Event ID 2000 http://go.microsoft.com/fwlink/?LinkId=83250

  • SRV Event ID 2019 http://go.microsoft.com/fwlink/?LinkId=83251

  • SRV Event ID 2020 http://go.microsoft.com/fwlink/?LinkId=83252

For more information about optimizing memory for Exchange Server, see the following Microsoft Knowledge Base articles:

  • 912376, "How to monitor and troubleshoot the use of paged pool memory in Exchange Server 2003 or in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=912376)

  • 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 894067, "The Performance tool does not accurately show the available Free System Page Table entries in Windows Server 2003" http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067

  • 311901, "The effects of 4GT tuning on System Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 912376, "How to monitor and troubleshoot the use of paged pool memory in Exchange Server 2003 or in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=912376)


Kernel Resource Depletion: Volume Shadow Copy Service Update
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows Management Instrumentation (WMI) class to verify that the Vssvc.exe file exists.

In the registry, the Exchange Server Analyzer queries to determine whether Volume Shadow Copy Service (VSS) or Virtual Disk service (VDS) is running on the Windows Server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS

Additionally, the Exchange Server Analyzer reads the following registry value to determine which version of the Microsoft Windows® operating system is running on the Exchange server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

If the CurrentVersion value equals 5.0, the Exchange server is running on Microsoft Windows 2000 Server. If the CurrentVersion value is 5.2, the Exchange server is running on Microsoft Windows Server™ 2003.

Finally, the Exchange Server Analyzer queries the Win32_OperatingSystem Windows Management Instrumentation (WMI) class to determine the value for the ServicePackMajorVersion key. The value for the ServicePackMajorVersion key indicates which Windows service pack is installed on the computer.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • Exchange Server is installed on Windows Server 2003 Service Pack 1 (SP1).

  • Volume Shadow Copy Service or Virtual Disk service is running on Windows Server 2003 SP 1.

  • The VSS update is not installed on this Exchange Server configuration.

If you apply the VSS update, issues such as kernel resource depletion will be resolved.

To fix the error

  • Apply the VSS update that is downloadable from Microsoft Knowledge Base article 891957, "Update is available that fixes various Volume Shadow Copy Service issues in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=891957).

For information about best practices for using VSS with Exchange Server 2003, see Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=56571).


LeakDiag is installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether LeakDiag.exe is installed on the computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\LeakDiag

If the Exchange Server Analyzer finds this registry branch present, a non-default configuration message is displayed.

LeakDiag is a set of tools that helps developers, support professionals, and information technology (IT) personnel diagnose memory leaks, fragmentation, and other memory-related issues in applications or services that are on computers running Microsoft Windows NT® Server 4.0, Windows® 2000 Server, Windows XP, and Windows Server™ 2003.

The LeakDiag tools can be used to pinpoint memory leaks down to the line of code. Using the Detours technology from Microsoft, LeakDiag intercepts calls to specified memory allocations and tracks the various call stacks. It reports on the memory that has been allocated but not yet freed. This information lets you troubleshoot a memory leak problem to see exactly what components made the allocations. With correct debug symbols, even the line of code that requested the allocations can be seen.

It is recommended that you do not run LeakDiag on Exchange servers that are in a production environment. When enabled, LeakDiag will track all memory allocations for all processes every time the Exchange server is started. This will consume a massive amount of processor and memory resources and is not recommended unless you are actively troubleshooting a memory-related problem. If you are not actively troubleshooting a memory-related problem, you should turn off LeakDiag. Running LeakDiag in a production Exchange Server environment could lead to memory fragmentation and depletion, and ultimately Exchange failure.

Note:
You should always troubleshoot problems with LeakDiag during off-peak hours. Using LeakDiag during periods of heavy or peak usage can cause a significant decrease in the performance of your Exchange Server computer.

Information about this message

  1. This message is for informational purposes only. As long as LeakDiag is not enabled and running, just having it installed does not affect Exchange Server performance. LeakDiag does require almost 4 megabytes (MB) of hard disk space (not including logs).

  2. To free this hard disk space, you can remove LeakDiag.exe by going to Control Panel, clicking Add/Remove Programs, clicking LeakDiag, and then clicking Remove.

For the latest version of LeakDiag, see the Microsoft public FTP site (http://go.microsoft.com/fwlink/?LinkId=41401).


LeakDiag is enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether LeakDiag.exe is enabled on the computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\LeakDiag\EnableAutoStart

If the Exchange Server Analyzer finds the value for EnableAutoStart set to 1, a warning is displayed. EnableAutoStart is configured using the LeakDiag user interface. The default value is 0. A value of 1 indicates that LeakDiag is enabled and active.

LeakDiag is a set of tools that helps developers, support professionals, and information technology (IT) personnel diagnose memory leaks, fragmentation, and other memory-related issues in applications or services that are on computers running Microsoft Windows NT® Server 4.0, Windows® 2000 Server, Windows XP, and Windows Server™ 2003.

The LeakDiag tools can be used to pinpoint memory leaks down to the line of code. Using Detours technology from Microsoft, LeakDiag intercepts calls to specified memory allocations and tracks the various call stacks. It reports on the memory that has been allocated but not yet freed. This information lets a person who is troubleshooting a memory leak problem see exactly what components made the allocations. With correct debug symbols, even the line of code that requested the allocations can be seen.

It is recommended that you do not run LeakDiag on Exchange servers that are in a production environment. When enabled, LeakDiag will track all memory allocations for all processes every time the Exchange server is started. This will consume a massive amount of processor and memory resources and is not recommended unless you are actively troubleshooting a memory-related problem. If you are not actively troubleshooting a memory-related problem, you should turn off LeakDiag. Running LeakDiag in a production Exchange Server environment could lead to memory fragmentation and depletion, and ultimately Exchange failure.

Note:
You should always troubleshoot problems with LeakDiag during off-peak hours. Using LeakDiag during periods of heavy or peak usage can cause a significant decrease in the performance of your Exchange Server computer.

To turn off Auto Start in LeakDiag.exe

  1. Click Start, and then click LeakDiag.

  2. On the Tools menu, click Options.

  3. On the Options page, clear the Allow AutoStart check box, and then click OK.

For the latest version of LeakDiag, see the Microsoft public FTP site (http://go.microsoft.com/fwlink/?LinkId=41401).


Less Than Seven Days of Log Space Left
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-13

The Microsoft Exchange Server Analyzer Tool estimates the time that remains before the transaction log drive space on an Exchange Server storage group will be full. The Exchange Server Analyzer estimates the time for the log drive to reach capacity by checking the timestamps on transaction log files on the drive. When the Exchange Server Analyzer finds that less than seven days remain before the log drive becomes full, the Exchange Server Analyzer displays an error.

The drive housing the log files for the Exchange Server databases is running out of disk space.

When log drive runs out of drive space, the following problems can occur:

  • The database will not start or will shutdown.

  • The database will go into a dirty shutdown and become inconsistent.

  • Users will be unable to access mail and or public folders.

The log drive space may become full because circular logging is disabled. Therefore, transaction log files are left on the drive until a full or incremental online backup that uses Exchange Server-aware backup software is performed.

In versions of Exchange Server earlier than Exchange 2003, databases may not be able to reach Clean Shutdown state before they stop. Two reserve transaction log files, Res1.log and Res2.log, are converted to ordinary transaction logs in a disk space emergency.

In Exchange Server 2003, optimizations were implemented so that the databases can be shut down cleanly until the reserve log files are exhausted. When a database has not been shut down cleanly, it is very important that the last several transaction logs associated with the database not be deleted. These transaction logs still contain information that must be applied to the database to restore it to consistency. If you delete these log files, the database cannot be started again until you have repaired or restored it.

If all databases in a storage group are in a Clean Shutdown state, the removal of all transaction logs will not prevent the databases from starting. However, if you remove the transaction logs, this will invalidate previous backups. This removal does not mean that previous backups cannot be restored. It does mean that you will not be able to roll a restored database forward past the point at which the log files were deleted.

The log space wizard in the Exchange Server Analyzer will analyze the existing transaction log files and help you move the ones that are no longer needed by the database. The log space wizard will also make sure that even if all databases are in a Clean Shutdown state, the current log file is not removed. If the current log file is not removed, the previous backups will remain valid.

To regain log drive space, you should remove unnecessary log files. The following actions are recommended.

To regain log drive space when log drive space is full or nearing capacity

  • Take an Exchange-aware online streaming backup or Volume Shadow Copy Service (VSS) backup of the database. For more information about VSS backup, see "Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=56571).

    Note:
    The preferred method for clearing unnecessary log files is to take an online streaming backup or a VSS backup.

  • If the database shuts down because it is about to run out of log drive space, you can use the Exchange Server Analyzer log space management wizard. You can use the wizard to move excess log files. Alternatively, you can manually move excess log files before you remount the database.

    To manually remove log files, follow the procedures and recommendations in Microsoft Knowledge Base article 240145, "How to remove Exchange Server transaction log files" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240145).


The LegacyExchangeDN for this Exchange server does not match the parent administrative group
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to verify the legacyExchangeDN value of a server by checking the attributes of the server object in the Servers container in Active Directory by comparing it to the actual name of the organization and administrative group in which the server resides. If the server's legacyExchangeDN value is different from the organization or administrative group, an error is displayed.

Exchange uses the legacyExchangeDN value to identify Exchange objects in Active Directory. The legacyExchangeDN value is a distinguished name that indicates where the object fits in the Exchange organization, for example:

/o= organization /ou= administrative group /ou= server

Objects such as mailbox stores and public folder stores inherit part of their legacyExchangeDN values from the server. This means that if there is a problem with the server value, other objects may inherit the same problem.

Generally, problems with the legacyExchangeDN occur when an administrator has tried to directly modify the value. You must correct the value using a tool such as Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Using ADSI Edit or a similar tool, locate the administrative group object in Active Directory.

    The legacyExchangeDN attribute can be found at:

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group,CN=Servers,CN=server

  2. Type a new string value of the form:

    /o= organization /ou= administrative group /ou= server

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in Windows Server 2003 Help.


The LegacyExchangeDN for this Exchange server is invalid
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to verify the legacyExchangeDN value of the Exchange server. This error is displayed if the organization or administrative group named in the legacyExchangeDN value does not match the actual name of the organization or administrative group, or if part of the value is missing entirely.

Exchange uses the legacyExchangeDN value to identify Exchange objects in Active Directory. The legacyExchangeDN value is a distinguished name that indicates where the object fits in the Exchange organization, for example:

/o= organization /ou= administrative group

Objects such as servers and folder hierarchies inherit part of their legacyExchangeDN values from the administrative group. This means that if there is a problem with the administrative group value, many other objects may inherit the same problem.

Usually problems with the legacyExchangeDN arise when an administrator has attempted to directly modify the value. You must correct the value using a tool such as Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or any other Lightweight Directory Acess Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Using ADSI Edit or a similar tool, locate the administrative group object in Active Directory.

    The legacyExchangeDN attribute can be found at:

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group

  2. Type a new string value of the form:

    /o= organization /ou= administrative group

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in Windows Server 2003 Help.


License logging service is set to Automatic
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the License Logging service (LicenseService). A value of False indicates that the License Logging service is not running on this Exchange server. A value of True indicates that the License Logging service is running.

The Exchange Server Analyzer also queries the Exchange_Server WMI class in the root\MicrosoftExchangeV2 namespace to determine the value for the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is a front-end server.

The Exchange Server Analyzer also queries the Win32_OperatingSystem WMI class to determine the value for the OSProductSuite key. The value returned for this key indicates the version of the Windows operating system that is running on the Exchange Server computer.

Additionally, the Exchange Server Analyzer also queries the Active Directory® directory service to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer determines that the License Logging service is started on an Exchange Server computer that meets all the following criteria, a warning is displayed:

  • The Exchange Server computer is not a front-end server.

  • The Exchange Server computer hosts more than 20 mailboxes.

  • The Exchange Server computer is not running on Microsoft Windows Small Business Server 2003 or Small Business Server 2000.

The License Logging service is a tool that was originally designed to help customers manage licenses for Microsoft server products that are licensed in the Server Client Access License (CAL) model.

By default, the License Logging service is disabled in Microsoft Windows Server™ 2003. Because of original design constraints and evolving license terms and conditions, the License Logging service cannot provide an accurate view of the total number of CALs that are purchased as compared to the total number of CALs that are used on a single server or across the enterprise. The CALs that are reported by the License Logging service may conflict with the interpretation of the End User License Agreement (EULA) and with Product Usage Rights (PUR). The License Logging service will not be included in future versions of the Windows operating system.

Microsoft has specific requirements and recommendations for usage of the License Logging service on Exchange Server computers:

  • On front-end Exchange servers that use Secure Sockets Layer (SSL), you must enable and start the License Logging service. If the License Logging service is not running, Internet Information Services (IIS) will limit the number of simultaneous authenticated SSL connections to 10.

  • On back-end Exchange servers, it is recommended that the License Logging service be stopped and set to Disabled.

  • On clustered Exchange servers, it is recommended that the License Logging service be stopped and set to Disabled.

  • On Exchange servers that are running on Microsoft Windows Small Business Server 2003 or Small Business Server 2000, the License Logging service is required only when more than 10 authenticated SSL connections are required.

To set the state of the License Logging service

  1. Start the Services snap-in from the Administrative Tools menu.

  2. Locate and double-click the License Logging Service.

  3. In the Startup type dropdown list, select the appropriate option:

    • Set the service to Automatic on front-end Exchange servers that use SSL.

    • Set the service to Disabled on back-end Exchange servers and clustered Exchange servers.

  4. If you are disabling the License Logging service, also click Stop to stop the service.

  5. Click OK to save the changes, and close the Services snap-in.

For more information about the License Logging service, see the following Microsoft Knowledge Base articles:

  • 824196, "Description of the License Logging Service in Windows Server Operating Systems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=824196)

  • 316631, "How to Turn Off the License Logging Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316631)


Log Filename does not Match Log Generation Number
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool compares the value of the lGeneration internal generation number from the transaction log file header against the file name of the transaction log file to determine whether they match.

If the internal generation number from the transaction log file does not match the representation of the internal generation number in transaction log file name, the Exchange Server Analyzer displays an error.

Unless a log file is the current log, the newest available log file must have a file name that matches its generation number. If a log file is the current log, its file name should not contain its generation number, but only the log prefix for the storage group. For example, previous transaction logs in a series might be named E0154321.LOG, E0154322.LOG, E0154323.LOG, and so on, with the current log named E01.LOG.

You can use the Eseutil /ML LOGFILE command to display the internal lGeneration value for a log file.

For more information about Exchange Server transaction logging, see "Exchange Transaction Logging in Exchange Server 2003" in Using Recovery Storage Groups in Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47589).


Log Sequence Signature Mismatch
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool compares the value of a log file's Signature against the subsequent log file's Signature value to determine whether they match.

If the value of the log file's Signature value does not match the value of the subsequent log file's Signature, the Exchange Server Analyzer displays an error.

Exchange uses a series of log files, each exactly five megabytes, instead of writing all log information to a single large file. When a log file is full, Exchange closes it and renames it with a sequence number.

When a new sequence of transaction log files for an Exchange storage group is initialized, a Signature is written into the first log file, and copied into every subsequent log file. The Signature uniquely identifies a particular log file as a member of a particular log sequence.

There is never a case where log files that have different signatures should be found in the same folders. If this occurs, it indicates that foreign log files have been copied into the storage group or that the log files were reset without deleting all previous log files first.

The command Eseutil /ML LOGFILE can be used to display the Signature value for a log file.

For more information about Exchange Server transaction logging, see "Exchange Transaction Logging in Exchange Server 2003" in Using Recovery Storage Groups in Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47589).


Log Signature Issue
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool compares the signature in the header of the current Exchange transaction log file on a server against the log signature in the storage group database file.

If the signature of the transaction log file does not match the log signature in any of the database files, the Exchange Server Analyzer displays an error.

This error indicates that one of the following conditions is true:

  • The current transaction log file does not exist.

  • The current transaction log file does not match one of the databases in the storage group.

This behavior may occur for the following reasons:

  • The transaction logs for the storage group have been manually deleted.

  • A database from another storage group has been restored or copied into this storage group.

  • Transaction log files from a different sequence or storage group have been copied into this storage group.

Whether this condition will prevent a database from mounting depends on whether a database file is in a Clean Shutdown or Dirty Shutdown state.

Note:
A database may be in a Clean Shutdown state, but still be unable to mount because other databases in the storage group are unmountable. Use the Exchange Server Disaster Recovery Analyzer to diagnose and advise you about how you can mount the databases in these cases.

When an Exchange database shuts down correctly, all outstanding data is written to the database files. After ordinary shutdown, the database file set (.edb and .stm extensions) is considered consistent. Exchange then detaches the database file set from its log stream. This means that the database files are now self-contained, that is, they are completely up-to-date. The previous transaction logs are not required to start the database files.

Databases in a Clean Shutdown state have been detached from their log files and may be attached to a different log stream. Therefore, the mismatch between the log files and the database is not necessarily a problem.

Databases in a Dirty Shutdown state have been incorrectly detached from their log files. These databases must be recovered with their attached log files. If the attached log files cannot be located, the database cannot be mounted. You must restore from backup or repair the database before it will be mountable.

You can tell whether a database has been shut down cleanly if you enter the Eseutil /mh command and examine the file headers. In Microsoft Exchange 2000 Service Pack 1 and later versions, a line in the header reads either "State: Clean Shutdown" or "State: Dirty Shutdown." In earlier versions of Exchange, the same state is reported as "State: Consistent" or "State: Inconsistent."

For more information about Exchange Server transaction logging, see "Exchange Transaction Logging in Exchange Server 2003" in Using Recovery Storage Groups in Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47589).


Log record bytes/sec beyond error threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are performing as should reasonably be expected on a healthy Exchange server.

As part of its analysis, the Exchange Server Analyzer reviews transaction log usage to determine whether user MAPI operations cause more than 5MB per minute of data to be written to the Exchange transaction logs.

Excessive transaction log file growth from MAPI operations may cause server resource bottlenecks and errors such as checkpoint depth exceeded, disk I/O bottlenecks, and insufficient disk space.

If the Exchange Server Analyzer determines that one or more user MAPI operations cause more than 5MB of data per minute to be written to the Exchange transaction logs, the Exchange Server Analyzer displays an error.

MAPI operations writing more than 5MB of data per minute to the Exchange transaction logs is not always an issue. Writing at a high rate is expected for some actions, such as mailbox moves or other bulk operations against many messages that generate large amounts of transaction log data. In this case, high rates should not be sustained for more than a few minutes.

If the server is experiencing other issues such as high RPC latency, work with the user generating the transaction log data to determine what user activity is causing the high log record write rate.

For More Information

For more information, see the following Exchange Server resources:

  • Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)

  • Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

  • Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkId=56460)

  • Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


LogicalDisk performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Avg. Disk sec/Read performance counter of the LogicalDisk performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions are true:

  • The LogicalDisk performance object is disabled. By default, in Microsoft Windows Server™ 2003, the LogicalDisk performance object is enabled. However, in Microsoft Windows® 2000 Server, LogicalDisk is not enabled by default.

  • The LogicalDisk performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows Management Instrumentation (WMI) modify the registry.

The following procedure explains how to fix the first two conditions. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the LogicalDisk performance object is enabled:

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at Exctrlst.exe: Extensible Performance Counter List (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall the Windows operating system in the Repair mode, and then apply the latest Windows service packs.


Long-latency MAPI operations found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-11-22

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to collect data, in a five minute sample, toward determining whether user MAPI operations are taking longer than should reasonably be expected on a healthy Exchange server.

If the Exchange Server Analyzer determines that, over the timeframe data was collected, a user has had one or more MAPI operations take longer than 30 seconds, the Exchange Server Analyzer displays an error and performs additional analysis on the actions of the users who triggered the error.

MAPI operations taking longer than 30 seconds may not always be a problem. Saving large amounts of message data or file attachments could cause the MAPI operations to take longer than normal.

If the user or users are experiencing frequent delays, or delays that adversely affect their messaging experience, these MAPI operation delays should be investigated further to make sure they are not symptomatic of more serious latency issues such as resource bottlenecks or nested dependencies.

To address this error:

  • Consider using the ExMon tool to capture a larger data sample for the Exchange Server Analyzer to review. Because of the large volume of data generated by ExMon, we recommend that the data collection sample be kept to 30 minutes or less.

  • Review any related latency errors and accompanying articles describing the particular operation and the steps to resolve them. If there are no related latency errors reported by the Exchange Server Analyzer, additional analysis of the user's actions revealed no issues.


Long-running MAPI bulk operation
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy Exchange server.

As part of its analysis, the Exchange Server Analyzer reviews the ExMon data for user-issued MAPI Bulk operations that have taken longer than 30 seconds to complete.

MAPI Bulk operations are operations that act on more than one object and are typically expensive (require many I/Os).

If the Exchange Server Analyzer determines that a user has had one or more MAPI Bulk operations take longer than 30 seconds, the Exchange Server Analyzer displays an error.

MAPI Bulk operations taking longer than 30 seconds may not always be a problem. If the user is acting on (copying, deleting, setting attribute flags, and so on) a thousand or more messages at one time, it could cause the MAPI Bulk operations to take longer than normal.

If the user or users are experiencing frequent delays, or delays that adversely affect their messaging experience, these MAPI Bulk operation delays should be investigated further to make sure they are not symptomatic of more serious latency issues such as resource bottlenecks or nested dependencies.

To address this error:

  • Consider using the ExMon tool to capture a larger data sample for the Exchange Server Analyzer to review. Because of the large volume of data generated by Exchange, we recommended that the data collection sample be kept to 30 minutes or less.

For More Information

For more information, see the following Exchange Server resources:

  • Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)

  • Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

  • "Exchange Server 2003 Performance: 10 Things to Think About" (http://go.microsoft.com/fwlink/?LinkId=56460)

  • Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


Long-running MAPI 'FindRow' operation
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-11-22

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy Exchange server.

As part of its analysis, the Exchange Server Analyzer reviews the ExMon data for user issued MAPI FindRow operations that have taken longer than 30 seconds to be completed.

An increase in the number of views for each folder can add overhead to many MAPI operations. Client applications use the MAPI operations SeekRow or FindRow to move the pointer between rows in a view. SeekRow specifies how many rows to move the pointer, and is very low-cost with regard to CPU time. FindRow is very expensive because it moves the pointer to the first item in a non-materialized (will not be cached) view that matches the restriction criteria, and then discards the view after the client application is finished with the action. The ultimate CPU cost of FindRow depends on the complexity of the restriction, and how many rows the store has to review before finding the first item that matches the criteria and so is loosely correlated with the number of items in the folder.

The high costs that can occur with FindRow make it a good candidate for running cached mode which would get the cost off the server. Be aware that, sometimes, the high CPU percentage consumed by this may merely be caused by shared calendars, in which case cached mode will not help. High consumption of percentage of CPU time by the FindRow operations could indicate lots of view creation, expensive views, or large folder item counts.

If the Exchange Server Analyzer determines that a user issued MAPI FindRow operation has taken longer than 30 seconds, the Exchange Server Analyzer displays an error.

MAPI FindRow operations taking longer than 30 seconds may not always be a problem. If the identified user or users are experiencing frequent delays, or delays that adversely affect their messaging experience, you should understand why. Work with the user experiencing the high latency to determine:

  • If the item counts in folders are high.

  • What applications the user is running.

To address this issue:

  • Encourage users who have many items in their folders to reduce the number of items per folder. We recommend that you keep items in the Inbox, Calendar, Sent Items, Contacts and Deleted Items folders under 5,000.

  • Configure the most operationally expensive client computers (especially those with long latencies on Restrict, SetColumns or FindRow operations) to use Cached Exchange Mode. Cached Exchange Mode isolates the server from most of the excess RPC traffic.

  • Try turning off all the applications and then turn them on one by one to find which one might be causing the problem. If these applications are not required for business, or if the applications have a published hot fix, permanently turn off the applications or update them to reduce the load to an appropriate level.

Note:
Some applications can significantly increase server load without issuing lots of MAPI operations. This is because some operations are more expensive than others. It may take only a small increase in the number of costly operations to noticeably affect server performance. In ExMon, these users are reported as having a high CPU effect, without necessarily having issued lots of MAPI operations.

Also be aware that when there is a bottleneck for resources (generally a disk or CPU bottleneck), the latencies for the FindRow operations will increase.

For More Information

For more information, see the following Exchange Server resources:

  • Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)

  • Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

  • Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkId=56460)

  • Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


Long-running MAPI online operation
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI Online operations are taking longer than should reasonably be expected on a healthy Exchange server.

An example of a MAPI online operation is the QueryRows operation.

The QueryRows operation is used to return rows in the current view. QueryRows uses the data in a table to satisfy the user request. The SetColumns operation determines the data available to QueryRows. The cost of QueryRows increases with the size of the properties requested, the number of properties requested, and the number of rows of data requested. QueryRows can also be expensive if many columns and rows are requested.

As the number of items in the core Exchange Server 2003 folders increase, the physical disk cost to perform some operations will also increase for users of Outlook. Sorting the Inbox by size for the first time is very expensive (requires many disk I/Os). Future sorts of the Inbox by size will be very inexpensive.

If the Exchange Server Analyzer determines that, over the timeframe data was collected, a user has had one or more MAPI Online operations take longer than 30 seconds, the Exchange Server Analyzer displays an error.

Long latency in MAPI Online Operations can indicate a server resource bottleneck. For the QueryRows operation, it may also indicate a high-item count in a folder or many properties set on the internal tables.

If the high-latency Online operation is operating on lots of data at the same time, the high latency may not indicate a problem with server performance. An example of this is when a user selects all the items in a folder and marks them as read in a single operation. Work with the user experiencing the high latency to determine:

  • If the item counts in folders are high.

  • What applications the user is running.

To address this issue:

  • Encourage users who have many items in their folders to reduce the number of items per folder. We recommended that you keep items in the Inbox, Calendar, Sent Items, Contacts and Deleted Items folders under 5,000.

  • Try turning off all the applications and then turn them on one by one to find which one might be causing the problem. If these applications are not required for business, or if the applications have a published hotfix, permanently turn off the applications or update them to reduce the load to an appropriate level.

Note:
Some applications can significantly increase server load without issuing lots of MAPI Online operations. This is because some operations are more expensive than others. It may take only a small increase in the number of costly operations to noticeably affect server performance. In ExMon, these users are reported as having a relatively high CPU impact, without necessarily having issued lots of MAPI operations.

Also be aware that whenever there is a bottleneck for resources (generally a disk or CPU bottleneck), the latencies for the MAPI Online operations will increase. Identify server resource bottlenecks and either increase server resource capacity or move users to a less-loaded server.

For More Information

For more information, see the following Exchange Server resources:

  • Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)

  • Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

  • Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkId=56460)

  • Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


Long-running MAPI operation
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-11-22

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy Exchange server.

If the Exchange Server Analyzer determines that a user has had one or more MAPI operations take longer than 30 seconds, the Exchange Server Analyzer displays an error.

An increase in the number of views for each folder can add overhead to many MAPI operations. Two the most common, SeekRow and FindRow, are discussed in this topic. Other MAPI operations identified by the Exchange Server Analyzer as 'long running' can usually be resolved by the same actions as the SeekRow and FindRow MAPI operations.

Client applications use the MAPI operations SeekRow or FindRow to move the pointer between rows in a view. SeekRow specifies how many rows to move the pointer, and is very low-cost with regard to CPU time. FindRow is very expensive because it moves the pointer to the first item in a non-materialized (will not be cached) view that matches the restriction criteria, and then discards the view after the client application is finished with the action. The ultimate CPU cost of FindRow depends on the complexity of the restriction, the number of message properties that are accessed for each message, and how many rows the store has to review before finding the first item that matches the criteria and so is loosely correlated with the number of items in the folder.

MAPI operations taking longer than 30 seconds may not always be a problem. If the identified user or users are experiencing frequent delays, or delays that adversely affect their messaging experience, you should understand why. Work with the user experiencing the high latency to determine:

  • If the item counts in folders are high.

  • What applications the user is running.

To address this issue:

  • Encourage users who have many items in their folders to reduce the number of items per folder. We recommend that you keep items in the Inbox, Calendar, Sent Items, Contacts and Deleted Items folders under 5,000

  • Configure the most operationally expensive client computers (especially those with long latencies on Restrict, SetColumns or FindRow operations) to use Cached Exchange Mode. Cached Exchange Mode isolates the server from most of the excess RPC traffic.

  • Try turning off all the applications and then turn them on one by one to find which one might be causing the problem. If these applications are not required for business, or if the applications have a published hot fix, permanently turn off the applications or update them to reduce the load to an appropriate level.

Note:
Some applications can significantly increase server load without issuing lots of MAPI operations. This is because some operations are more expensive than others. It may take only a small increase in the number of costly operations to noticeably affect server performance. In ExMon, these users are reported as having a high CPU effect, without necessarily having issued lots of MAPI operations.

Also be aware that when there is a bottleneck for resources (generally a disk or CPU bottleneck), the latencies for the MAPI operations will increase. Determine server resource bottlenecks and either increase server resource capacity or move users to less-loaded server.

For More Information

For more information, see the following Exchange Server resources:

  • Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)

  • Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

  • Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkId=56460)

  • Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


Long-running MAPI 'SaveChangesMessage' operation
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-11-22

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy Exchange server.

As part of its analysis, the Exchange Server Analyzer reviews the ExMon data for user-issued MAPI SaveChangesMessage operations that have taken longer than 30 seconds to be completed.

The MAPI SaveChangesMessage operation is called when an application is saving the content and or the properties of a message to the server. The time that is required to complete the operation depends on the data written, the speed of the database and the transaction log disks being written to, and whether a resource bottleneck is present.

If the Exchange Server Analyzer determines that a user-issued MAPI SaveChangesMessage operation has taken longer than 30 seconds, the Exchange Server Analyzer displays an error.

MAPI SaveChangesMessage operations taking longer than 30 seconds may not always be a problem. Saving large amounts of message data or file attachments could cause the MAPI SaveChangesMessage operation to take longer than normal. If the user or users are experiencing frequent delays, or delays that adversely affect their messaging experience, the most likely cause is a disk bottleneck.

For More Information

  • For more information about disk bottlenecks, see Disk Bottleneck Detected

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about how to troubleshoot Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about best practices for designing storage architectures, see Best Practices Common to Multiple Architectures (http://go.microsoft.com/fwlink/?LinkId=72988).

  • For more information about how to move user mailboxes to reduce server load, see Move User Mailboxes to Another Server.

  • For more information about disk sizing, latency, and I/O rates, see the following blogs on the Microsoft Exchange Team Blog Web site:

    • "A few basic concepts in disk sizing" (A few basic concepts in disk sizing (http://go.microsoft.com/fwlink/?linkid=39538)

    • "Some more thoughts on disk IO and calculations…." (http://go.microsoft.com/fwlink/?linkid=39539)

    • How to Calculate Your Disk I/O Requirements (http://go.microsoft.com/fwlink/?linkid=69747)


Long-running MAPI 'SetColumns' operation
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy server that is running Exchange Server.

As part of its analysis, the Exchange Server Analyzer reviews the ExMon data for user-issued MAPI SetColumns operations that have taken longer than 30 seconds to be completed.

A basic view is created by using the MAPI call SetColumns. The call to SetColumns defines the properties which will be columns in the new view table.

The first time that a property is requested in a view, the server must do extra work to generate the view. After that property is requested in a view, it will always be present for future views. This means that the first time new properties are requested, the call to SetColumns can take much longer. The time that is required is proportional to the number of new properties and the number of items in the folder. For example, the first time that a user views their inbox after a mailbox move, the server will take longer to generate the view. This is because views are not moved with a mailbox move. The views will be recreated.

It is generally very expensive to add properties to the view. The cost of adding properties is proportional to the number of items in the folder and to the number of properties that are being added. General Microsoft Office® Outlook® usage will not cause many properties to be added to the message folder table, but more can be added manually. This is not generally a problem. However, you may experience delays if an application regularly adds columns, adds many columns, or if any client adds several columns over many items. The more columns in the message folder table, the more overhead there is to all other actions on items in that folder. As soon as a column is added, it cannot be removed. Each property in the Message-Folder table adds overhead to insert items in that folder.

If the Exchange Server Analyzer determines that a user-issued MAPI SetColumns operation has taken longer than 30 seconds, the Exchange Server Analyzer displays an error.

The first time that a user accesses their mailbox after it has been moved to a new database or a new server, the server will have to create new views. In that case, long SetColumns and long Restrict calls are expected. You can safely ignore these errors for several days after you move a mailbox.

Some applications will create new views and cause properties to be promoted to internal store data structures. This can have a long-term performance effect on the server when the server accesses that user's data. If the identified user or users experience frequent delays or delays that adversely affect their messaging experience, you should understand why. Work with the user who is experiencing the high latency to determine the following:

  • Whether the item counts in folders are high.

  • What applications the user is running.

To address this issue, follow these steps:

  • Encourage users who have many items in their folders to reduce the number of items per folder. It is recommended that you keep items in the Inbox, Calendar, Sent Items, Contacts and Deleted Items folders to fewer than 5,000.

  • Configure the most operationally expensive client computers to use Cached Exchange Mode. Pay extra attention to client computers that have long latencies on Restrict, SetColumns or FindRow operations. Cached Exchange Mode isolates the server from most of the excess RPC traffic.

  • Try turning off all the applications. Then turn them on one by one to find which one might be causing the problem. Permanently turn off any problem applications or update them to reduce the load to an appropriate level if either of the following conditions is true:

    • The application is not required for business.

    • The application has a published update.

Note:
Some applications can significantly increase server load without issuing lots of MAPI operations. This is because some operations are more expensive than other operations. It may take only a small increase in the number of costly operations to noticeably affect server performance. In ExMon, users are reported as having a high CPU effect, without necessarily having issued many MAPI operations.

Also, you should be aware that when there is a bottleneck for resources, generally a disk or CPU bottleneck, the latencies for the SetColumns operations will increase.

For More Information

For more information, see the following Exchange Server resources:

  • "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576)

  • "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588)

  • Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkId=56460)

  • Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


Long-running MAPI synchronization operation
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy Exchange server.

As part of its analysis, the Exchange Server Analyzer reviews the ExMon data for user issued MAPI Synchronization operations that have taken longer than 30 seconds to complete.

MAPI Synchronization operations are performed to keep the Microsoft Office® Outlook® Offline Folder file (.ost) or local copy of the user's mailbox in sync with the user's mailbox data on the server.

MAPI Synchronization operations taking longer than 30 seconds may not always be a problem. By default, all e-mail messages that are stored on the Exchange Server and that are full copies of the Global Address List are downloaded to the user's computer when Cached Exchange Mode is first enabled in Outlook 2003.

During an initial synchronization with the Exchange Server, Outlook 2003 users may experience delayed responses.

If the user or users are experiencing frequent delays, or delays that adversely affect their messaging experience, subsequent to the initiation cached mode synchronization, these MAPI Synchronization operation delays should be investigated further to ensure they are not symptomatic of more serious latency issues such as resource bottlenecks.

Anytime there is a bottleneck for resources (generally a disk or CPU bottleneck), the latencies for the MAPI synchronization operations will increase. Identify server resource bottlenecks and either increase server resource capacity or move users to less-loaded server.

For More Information

For more information, see the following Exchange Server resources:

  • Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)

  • Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

  • "Exchange Server 2003 Performance: 10 Things to Think About" (http://go.microsoft.com/fwlink/?LinkId=56460)

  • Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


Long-running MAPI 'TaskQ' operation
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-20

Microsoft Exchange Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy Exchange server.

As part of its analysis, the Exchange Analyzer reviews the ExMon data for user-issued MAPI TaskQ operations that have taken longer than 30 seconds to complete.

TaskQ operations are asynchronous tasks run outside the context of an RPC call. TaskQ and TaskQ User Unknown operations are tasks run at the request of Exchange and include store maintenance. TaskQ User Known operations are asynchronous tasks initiated by a direct user request and include search folder population, sorting, and bulk operations such as move, copy, delete, and marking messages as read on multiple messages.

If the Exchange Analyzer determines that user-issued MAPI TaskQ operations have taken longer than 30 seconds to complete, the Exchange Analyzer displays a warning.

This may not always indicate a performance problem as TaskQ operations are typically operations that can take a long time to finish.

To address this issue, do the following:

  • Consider using the ExMon tool to capture a larger data sample for the Exchange Server Analyzer to review. Because of the large volume of data generated by Exchange, we recommended that the data collection sample be kept to 30 minutes or less.

For More Information

For more information, see the following Exchange Server resources:

  • Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)

  • Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

  • Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkId=56460)


Long-running operation due to MAPI 'Restrict' operation
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-23

The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy server that is running Exchange Server.

As part of its analysis, the Exchange Server Analyzer reviews the ExMon data for user-issued MAPI Restrict operations that have taken longer than 30 seconds to be completed.

The MAPI Restrict operation is used by client applications to select items that match particular criteria. The server creates a view that is, effectively, a table with associated criteria called a restriction. If the view that has a matching restriction already exists, the server uses the existing view to satisfy the user request. When the server uses this view, this is a less expensive operation than when the server creates a new view. By default, the store caches only 11 views for each folder. If the server is asked to create a twelfth view, it deletes the oldest cached view and creates a new view. Views add overhead to all actions on items.

If the Exchange Server Analyzer determines that a user-issued MAPI Restrict operation has taken longer than 30 seconds, the Exchange Server Analyzer displays an error.

MAPI Restrict operations that take longer than 30 seconds may not always be a problem. However, if the user or users experience frequent delays or delays that adversely affect their messaging experience, these delays may indicate that a user application is causing new views to be created.

To address this error, work with the user who is experiencing the high latency to determine the following:

  • Whether the item counts in folders are high.

  • What applications the user is running.

To address this issue, follow these steps:

  • Encourage users who have many items in their folders to reduce the number of items per folder. It is recommended that you keep items in the Inbox, Calendar, Sent Items, Contacts and Deleted Items folders to fewer than 5,000.

  • Configure the most operationally expensive client computers to use Cached Exchange Mode. Pay extra attention to client computers that have long latencies on Restrict, SetColumns or FindRow operations. Cached Exchange Mode isolates the server from most of the excess RPC traffic.

  • Follow the guidance from the Exchange Team Blog referenced in the following section to turn on event log restriction tracing. Then turn on the user applications one by one to trace which application may be causing the long-running restriction.

  • Try turning off all the applications. Then turn them on one by one to find which one might be causing the problem. Permanently turn off any problem applications or update them to reduce the load to an appropriate level if either of the following conditions is true:

    • The application is not required for business.

    • The application has a published update.

Note:
Some applications can significantly increase server load without issuing lots of MAPI operations. This is because some operations are more expensive than other operations. It may take only a small increase in the number of costly operations to noticeably affect server performance. In ExMon, users are reported as having a high CPU effect, without necessarily having issued many MAPI operations.

Also, you should be aware that when there is a bottleneck for resources, generally a disk or CPU bottleneck, the latencies for the Restrict operations will increase.

For More Information

For more information about the MAPI Restrict operation, see the Microsoft Exchange Team Blog, "Putting the Restrictions on Restrictions" (http://go.microsoft.com/fwlink/?linkid=55098).

Note:
The content of each blog and its URL are subject to change without notice.

For more information, see the following Exchange Server resources:

  • "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576)

  • "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588)

  • "Exchange Server 2003 Performance: 10 Things to Think About" (http://go.microsoft.com/fwlink/?LinkId=56460)

  • Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


MAD.EXE file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


MAD NSPI port is below 5000
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the TCP/IP NSPI Port setting for the Microsoft Exchange System Attendant service:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

If the Exchange Server Analyzer finds that the value for TCP/IP NSPI Port is set to a value below 5000 (decimal), a warning is displayed.

If you must set TCP/IP NSPI Port to a static value, it is recommended that you set it to a value that is just over 5000. Assigning static port numbers under 5000 may cause a port conflict with another process and lead to failure of the Exchange System Attendant service process.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the TCP/IP NSPI port registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the TCP/IP NSPI Port key, and set the Value data field to an integer just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the Microsoft Exchange System Attendant service for this change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about port limits, see the Knowledge Base article 194952, "XADM: Statically Mapped Port Limitations for Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=194952).


MAD RFR port has been manually overridden
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the port value for the Microsoft Exchange System Attendant directory referral port has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

If the Exchange Server Analyzer finds that TCP/IP Port is present and configured, a non-default configuration message is displayed.

The most common reason that this value is configured is to enable MAPI clients to connect to an Exchange server that is on the other side of a firewall. This scenario involves opening multiple ports on a firewall to enable Microsoft Office Outlook® 2003 clients to connect using MAPI to an Exchange server, typically over the Internet. This configuration is supported. For more information about configuring MAPI clients to connect to Exchange through a firewall, see the Microsoft Knowledge Base article 270836, "Exchange 2000 and Exchange 2003 Static Port Mappings" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836). If you are not using this scenario, you should remove the registry key.

The recommended deployment for using Outlook in MAPI Mode to connect to an Exchange server over the Internet is to use the remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) features found in Microsoft Windows Server™ 2003, Exchange Server 2003, Outlook 2003, and Windows® XP Professional. MAPI Mode was formerly referred to as Corporate or Workgroup mode.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To remove the TCP/IP port registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Delete the registry value called TCP/IP Port.

  4. Close the registry editor, and restart the Microsoft Exchange System Attendant service.

To deploy RPC over HTTPS

  1. Review Exchange Server 2003 RPC over HTTP Deployment Scenarios (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review the Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  3. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  4. Review the Microsoft Support WebCast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MAD RFR port is below 5000
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the TCP/IP Port setting for the Microsoft Exchange System Attendant service:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

If the Exchange Server Analyzer finds that the value for TCP/IP Port is set to a value below 5000 (decimal), a warning is displayed.

In the case where you must set TCP/IP Port to a static value, it is recommended that you set it to a value that is just over 5000. Assigning static port numbers under 5000 may cause a port conflict with another process and lead to failure of the Microsoft Exchange System Attendant service process.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the TCP/IP port registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the TCP/IP Port key, and set the Value data field to an integer just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the Microsoft Exchange System Attendant service for this change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about port settings, see the Knowledge Base article 194952, "XADM: Statically Mapped Port Limitations for Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=194952).


MAPI32.DLL file is missing from bin folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


MAPI32.DLL file is missing from system32 folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


MAPISTUB.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


MAPISP32.EXE file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To fix this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


Maximum ESE Cache size larger than 1.2 GB
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the DataBase Cache Size (DBCacheSize) performance counter of the DataBase performance object to analyze performance data.

The DataBase Cache Size (DBCacheSize) performance counter represents the current cache size used by the store. If the Exchange Server Analyzer finds that the value of the DataBase Cache Size (DBCacheSize) performance counter to be larger than 307200 (1.2 GB), the Exchange Server Analyzer displays an error.

This error indicates that value of the msExchESEParamCacheSizeMax attribute for the Microsoft Exchange Information Store (MSExchangeIS) object has been increased beyond the maximum recommended value of 307200 (1.2 GB).

The store database cache is also referred to as the ESE (Extensible Storage Engine) buffer. It caches database transactions before they are committed to the database.

In Exchange 2000 Server, a large area of the virtual memory used by Store.exe is allocated for the ESE Buffer. Exchange 2000 Server uses a hard-coded default of 858 megabytes (MB) for this buffer. In Exchange Server 2003, the ESE buffer allocation is based on the presence of the /3GB switch in the Boot.ini file. If the /3GB switch is present, the ESE buffer is tuned to 896 MB. If /3GB is not present, the ESE buffer is tuned to 576 MB. Although auto-tuning is always good, you may want to override the auto-tuning and manually set a value more appropriate for your environment.

Although you can tune this value to any number in such a way that the actual memory allocated is a multiple of 8,192 bytes, it is recommended that you use only a value from the following table.

Recommended Value | Memory Allocated | Comments
147456 | 576 MB | This is the recommended minimum. Do not set the value any lower. This value is useful on virtual memory-constrained servers, and on Exchange Server 2003 computers that run on Microsoft Windows® 2000 Server. This does not support the /3GB switch. This is also the default value on systems that do not use the /3GB switch.
196608 | 768 MB | This value is recommended on servers that have lots of virtual memory and log event 9582 frequently.
219726 | 858 MB | This is the default value in Exchange 2000 Server. It is a good value to use on systems you are upgrading in-place that have lots of virtual memory.
229376 | 896 MB | This is the default value in Exchange Server 2003, and a good value to use on new systems unless your Application event log indicates otherwise with the presence of 9582 events.
307200 | 1.2 GB | This is the maximum value that you can set. This value should only be used on systems with 2 gigabytes (GB) or more of physical memory.

Before you reconfigure this value, you should monitor the amount of virtual memory consumed by the Store.exe process. You can do this by monitoring the Process performance object in Microsoft Windows. On systems with the /3GB switch, the Virtual Bytes counter for the Store.exe instance of the Process object should be less than 2.8 GB. On systems without the /3GB switch, the Virtual Bytes counter for the Store.exe instance of the Process object should be less than 1.8 GB. If the values are more than these amounts, you may have to decrease the value for msExchESEParamCacheSizeMax. If the values are less than this, you may want to increase the value for msExchESEParamCacheSizeMax.

Caution:
If you incorrectly modify the attributes of Active Directory® objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To tune the msExchESEParamCacheSizeMax attribute

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Double-click the Configuration container.

  3. Expand CN=Services.

  4. Expand CN=Microsoft Exchange.

  5. Expand CN=<Exchange Organization Name>.

  6. Expand CN=Administrative Groups.

  7. Expand CN=<Administrative Group Name>.

  8. Expand CN=Servers.

  9. Expand CN=<Exchange Server Name>.

  10. Right-click CN=InformationStore, and then click Properties.

  11. In the attributes field, scroll to and then double-click msExchESEParamCacheSizeMax.

  12. In the Value field, type the value that you want to set. Use the table to determine the optimal value for your system.

  13. Click OK, and then click OK again.

  14. Close the Active Directory editor, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about optimizing memory usage, see "Optimizing Memory Usage for Exchange Server 2003" in Planning a Microsoft Exchange Server 2003 Messaging System (http://go.microsoft.com/fwlink/?LinkId=47584).

For more information about the msExchESEParamCacheSizeMax attribute, see Microsoft Knowledge Base article 266768, "How to modify the Store Database maximum cache size in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768).


Maximum recipient limit has been changed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchRecipLimit attribute has been changed from its default value. The msExchRecipLimit attribute stores the value for the global maximum number of recipients for each e-mail message. By default, the value of the msExchRecipLimit attribute is 5000. If the Exchange Server Analyzer finds that the value of the msExchRecipLimit attribute does not equal 5000, the Exchange Server Analyzer displays a non-default configuration message.

The global maximum recipient limit applies to the whole Exchange organization. The value of the msExchRecipLimit attribute limits the number of recipients for a single e-mail message. The global maximum recipient limit affects system messages and non-system messages. System messages include public folder replication messages.

Note:
You can also set recipient limits on a per-user basis by using Active Directory Users and Computers. The per-user setting has precedence over the global setting and will override the global setting. By default, the per-user recipient limit is set to use the global maximum recipient limit.
Note:
On a Simple Mail Transfer Protocol (SMTP) virtual server, you can set a limit on the number of recipients per message for messages that are received from Internet users. This limit differs from the global maximum recipient limit and from the per-user recipient limit. The global maximum recipient limit and the per-user recipient limit both limit the number of recipients to which an Exchange user can send a message.
To change the global maximum recipient limit to its default value

  1. Start Exchange System Manager.

  2. In the left pane, expand Global Settings.

  3. Right-click Message Delivery, and then click Properties.

  4. On the Defaults tab, under Recipient Limits, click Maximum Recipients, and then type 5000.

  5. Restart the Microsoft Exchange Information Store service.

For more information about setting recipient limits and configuring Microsoft Office Outlook® Web Access clients, see "Outlook Web Access S/MIME Control-Related Settings" in the Exchange Server 2003 Message Security Guide (http://go.microsoft.com/fwlink/?LinkId=47574).

For more information about the history of the maximum recipient limit, see the Exchange weblog article, "Me Too!" (http://go.microsoft.com/fwlink/?LinkId=41848).


Maximum recipient limit is high
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchRecipLimit value for messages exceeds 7500. If the Exchange Server Analyzer finds that the value of the msExchRecipLimit attribute is more than 7500, the Exchange Server Analyzer displays a warning.

The msExchRecipLimit attribute stores the value for the global maximum number of recipients for each e-mail message. The value limits the number of recipients for a single e-mail message. The value also affects system messages and non-system messages. System messages include public folder replication messages. By default, the value of the msExchRecipLimit attribute is 5000.

If the value of the msExchRecipLimit attribute exceeds 7500, the risk of problems that are caused by messages with many recipients increases.

Note:
You can also set recipient limits on a per-user basis by using Active Directory Users and Computers. The per-user setting has precedence over the global setting and will override the global setting. By default, the per-user recipient limit is set to use the global maximum recipient limit.
Note:
On a Simple Mail Transfer Protocol (SMTP) virtual server, you can set a limit on the number of recipients per message for messages that are received from Internet users. This limit differs from the global maximum recipient limit and from the per-user recipient limit. The global maximum recipient limit and the per-user recipient limit both limit the number of recipients to which an Exchange user can send a message.
To change the global maximum recipient limit to its default value

  1. Start Exchange System Manager.

  2. In the left pane, expand Global Settings.

  3. Right-click Message Delivery, and then click Properties.

  4. On the Defaults tab, under Recipient Limits, click Maximum Recipients, and then type 5000.

  5. Restart the Microsoft Exchange Information Store service.

For more information about setting recipient limits and configuring Microsoft Office Outlook® Web Access clients, see "Outlook Web Access S/MIME Control-Related Settings" in the Exchange Server 2003 Message Security Guide (http://go.microsoft.com/fwlink/?LinkId=47574).

For more information about the history of the global maximum recipient limit, see the Exchange weblog article, "Me Too!" (http://go.microsoft.com/fwlink/?LinkId=41848).


Maximum recipient limit is too low
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchRecipLimit value for messages is less than the number of public folder stores in the Exchange organization. If the Exchange Server Analyzer finds that the value of the msExchRecipLimit attribute is less than the number of public folder stores, the Exchange Server Analyzer displays an error.

The msExchRecipLimit attribute stores the value for the global maximum number of recipients for each e-mail message. The value limits the number of recipients for a single e-mail message. The value also affects system messages and non-system messages. System messages include public folder replication messages. By default, the value of the msExchRecipLimit attribute is 5000. If the value of the msExchRecipLimit attribute is less than the number of public folder stores in the Exchange organization, you will have problems with public folder hierarchy replication.

Note:
You can also set recipient limits on a per-user basis by using Active Directory Users and Computers. The per-user setting has precedence over the global setting and will override the global setting. By default, the per-user recipient limit is set to use the global maximum recipient limit.
Note:
On a Simple Mail Transfer Protocol (SMTP) virtual server, you can set a limit on the number of recipients per message for messages that are received from Internet users. This limit differs from the global maximum recipient limit and from the per-user recipient limit. The global maximum recipient limit and the per-user recipient limit both limit the number of recipients to which an Exchange user can send a message.
To change the global maximum recipient limit to its default value

  1. Start Exchange System Manager.

  2. In the left pane, expand Global Settings.

  3. Right-click Message Delivery, and then click Properties.

  4. On the Defaults tab, under Recipient Limits, click Maximum Recipients, and make sure that the value is not less than the number of public folder stores in the Exchange organization.

  5. Restart the Microsoft Exchange Information Store service.

For more information about setting recipient limits and configuring Microsoft Office Outlook® Web Access clients, see "Outlook Web Access S/MIME Control-Related Settings" in the Exchange Server 2003 Message Security Guide (http://go.microsoft.com/fwlink/?LinkId=47574).

For more information about the history of the global maximum recipient limit, see the Exchange weblog article, "Me Too!" (http://go.microsoft.com/fwlink/?LinkId=41848).


MaxUserPort Key is Missing or Non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-23

The Microsoft Exchange Analyzer tool queries the Active Directory directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 5.5", the computer is running Exchange Server 5.5. If the string value includes "Version 6.0", the computer is running Exchange 2000 Server. If the string value includes "Version 6.5", the computer is running Exchange Server 2003. If the string value includes "Version 8.0", the computer is running Exchange Server 2007.

The Exchange Analyzer tool then reads the following registry branch for each Exchange Server 2007 server found to determine whether the value for the MaxUserPort key is set to the default value of 60000.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

The MaxUserPort key determines the highest port number TCP can assign when an application requests an available user port from the system.

By default, Microsoft Windows Server 2003 sets the MaxUserPort value to 5000. Microsoft Windows 2000 does not add the MaxUserPort value to the registry. However, it can be manually added. However, on Windows Server 2003 and Windows 2000 Server, Exchange Server 2003 and Exchange Server 2007 sets the default value to 60000. Exchange 2000 Server does not set a value.

We recommended that you set the MaxUserPort value to 60000. If you set the MaxUserPort value lower than 60000, you may cause Name Service Provider Interface (NSPI) proxy warnings, such as Event 9040. Event 9040 is documented in the following table:

Event ID | 9040
Event Category | NSPI Proxy
Event Source | MSExchangeSA
Event Type | Warning
Event Description | NSPI Proxy encountered an error while receiving a packet. The target domain controller or the network or a client might be down. The Winsock subsystem returned the error:[0x2746]. The circuit that received this error is being closed.
Important:
This topic contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  3. Double-click MaxUserPort, set the Value data field to 60000 (Decimal), and then click OK.

  4. Close the registry editor and restart the computer for this setting to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

This issue is related to the TcpTimedWaitDelay Key is Missing or Non-default Analyzer issue.

For more information about the effect of the MaxUserPort and TcpTimedWaitDelay registry keys, see the "Transmission Control Protocol" topic in the Windows 2000 Resource Kit (http://go.microsoft.com/fwlink/?LinkId=85654).


MaxUserPort value is too low
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine the maximum value for the TCP ephemeral port:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort

An ephemeral port is a port that is used briefly.

If the Exchange Server Analyzer finds the value of the MaxUserPort registry key is less than 50000, the Exchange Server Analyzer displays a warning.

The MaxUserPort value specifies the highest port number that TCP can assign when an application requests an available user port from the system. Typically, ephemeral ports are allocated port number 1024 through port number 5000.

By default, Microsoft Windows Server™ 2003 sets the MaxUserPort value to 5000. Microsoft Windows® 2000 does not add the MaxUserPort value to the registry. You can manually add the MaxUserPort value to the registry. However, on Windows Server 2003 and Windows 2000 Server, Exchange Server 2003 sets the default value to 60000. Exchange 2000 Server does not set a value.

It is recommended that you set the MaxUserPort value to 60000. If you set the MaxUserPort value lower than 60000, you may cause Name Service Provider Interface (NSPI) proxy warnings, such as Event 9040. Event 9040 is documented in the following table.

Event ID | 9040
Event Category | NSPI Proxy
Event Source | MSExchangeSA
Event Type | Warning
Event Description | NSPI Proxy encountered an error while receiving a packet. The target domain controller or the network or a client might be down. The Winsock subsystem returned the error:[0x2746]. The circuit that received this error is being closed.

To correct this warning, set the value of the MaxUserPort registry key to 60000.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  3. Double-click MaxUserPort, set the Value data field to ea60 (Hexadecimal), and then click OK.

  4. Close the registry editor and restart the computer for this setting to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MDBSZ.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To fix this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD in your CD drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


Memory performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Available Mbytes performance counter of the Memory performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions is true:

  • The Memory performance object is disabled.

  • The Memory performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry.

Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the Memory performance object is enabled:

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at Exctrlst.exe: Extensible Performance Counter List (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall the Windows operating system in the Repair mode, and then apply the latest Windows service packs.


MSExchangeDSAccess Processes performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the LDAP Read Time performance counter of the MSExchangeDSAccess performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions is true:

  • The MSExchangeDSAccess performance object is disabled.

  • The MSExchangeDSAccess performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry. The following procedure explains how to fix the first two conditions. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions.

For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the MSExchangeDSAccess performance object is enabled:

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at Exctrlst.exe: Extensible Performance Counter List (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall Exchange Server in the Repair mode, and then apply the latest Exchange Server service packs.


MSExchangeIS Mailbox performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Send Queue Size performance counter of the MSExchangeIS Mailbox performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions is true:

  • The MSExchangeIS Mailbox performance object is disabled.

  • The MSExchangeIS Mailbox performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry.

Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the MSExchangeIS Mailbox performance object is enabled:

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at Exctrlst.exe: Extensible Performance Counter List (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall Exchange Server in the Repair mode, and then apply the latest Exchange Server service packs.


MSExchangeIS performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-03

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the RPC Operations/sec performance counter of the MSExchangeIS performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions is true:

  • The MSExchangeIS performance object is disabled.

  • The MSExchangeIS performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the MSExchangeIS performance object is enabled:

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at Exctrlst.exe: Extensible Performance Counter List (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select this check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall Exchange Server in the Repair mode, and then apply the latest Exchange Server service packs.

For more information about troubleshooting Exchange Server Best Practices Analyzer Tool connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).


MSExchangeIS Public performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Send Queue Size performance counter of the MSExchangeIS Public performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions is true:

  • The MSExchangeIS Public performance object is disabled.

  • The MSExchangeIS Public performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the MSExchangeIS Public performance object is enabled:

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at Exctrlst.exe: Extensible Performance Counter List (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall Exchange Server in the Repair mode, and then apply the latest Exchange Server service packs.


MSGINA.DLL driver update available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of Microsoft Windows® running on the server that is running Exchange Server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates that the Exchange server is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates that the Exchange server is running Windows 2000 Server. A value of 5.2 indicates that the Exchange server is running Windows Server™ 2003.

The Exchange Server Analyzer also examines the Win32_OperatingSystem Microsoft Windows Management Instrumentation (WMI) class to determine the value for the ServicePackMajorVersion key.

A ServicePackMajorVersion key value of 1 indicates the server has Service Pack 1 (SP1) installed.

Finally, the Exchange Server Analyzer queries the CIM_Datafile WMI class to determine the value of the Version key for the Msgina.dll file.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The server is running Windows Server™ 2003 SP1.

  • The build number of the Msgina.dll file is less than 5.2.3790.2525.

This error indicates that the version of Msgina.dll installed on the server may cause excessive page file activity and a decrease in performance.

To resolve this problem, obtain the update referenced in Microsoft Knowledge Base article 905865, "The sizes of the working sets of all the processes in a console session may be trimmed when you use Terminal Services to log on to or log off from a computer that is running Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905865).


MTA APDU logging required parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\APDU logging required

If the Exchange Server Analyzer finds the value for APDU logging required present and set to anything other than 0, a non-default configuration message is displayed.

Application Protocol Data Unit (APDU) text logs are binary representations of communication among Exchange message transfer agents (MTAs) in different sites and between MTA and client applications within a site. APDU logs can be instrumental in diagnosing problems with the MTA. However, they are valuable only to those familiar with ASCII translations of X.400 protocol.

When the APDU logging required registry parameter is present and configured with a value of 0, all the APDUs sent or received by the MTA are logged as binary data to binary data to MTADATA\BF*.LOG.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to edit the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default MTA APDU logging configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the APDU logging required value.

  4. In the Value data field, enter 0 and click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about APDU logs, see the Knowledge Base article 163324, "XCON: Application Protocol Data Unit (APDU) Logs (BF0.LOG)" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=163324).


MTA Call-stack diagnostics required parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Call-stack diagnostics required

If the Exchange Server Analyzer finds the value for Call-stack diagnostics required present and set to anything other than 1, a non-default configuration message is displayed.

The Call-stack diagnostics required registry value is used for advanced debugging purposes only, and is only read by a debug version of the message transfer agent (MTA). Its value data should always be set to 1. When a debug version of the MTA is used, this value provides a call stack for each MTA thread at termination time.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Call-stack diagnostics required value.

  4. In the Value data field, enter 1 and click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA Computer name mismatch
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the setting for the message transfer agent (MTA) Computer value: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the name attribute for each Exchange server object.

Finally, the Exchange Server Analyzer queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Cluster service (ClusSvc). A value of True indicates the Cluster service is started and a value of False indicates the Cluster service is not running.

If the Exchange Server Analyzer finds that the value for the MTA Computer key does not match the value for the server object's name attribute in Active Directory for any Exchange Server computer that is not running in a Windows Server cluster, an error is displayed.

To correct this error, you must edit the MTA Computer registry key to match the value of the name attribute in Active Directory.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to edit the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, double-click MTA Computer, enter the correct name for this computer, and then click OK.

  4. Close the registry editor and restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA Concurrent connections to LAN-MTAs parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Concurrent connections to LAN-MTAs

If the Exchange Server Analyzer finds the value for Concurrent connections to LAN-MTAs present and set to anything other than 0x28 (hex) or 40 (decimal), a non-default configuration message is displayed.

The Concurrent connections to LAN-MTAs registry value determines the maximum number of concurrent connections to message transfer agents (MTAs) over the local area network (LAN). MTAs that communicate over a LAN are known as LAN-MTAs. The local MTA may have multiple connections to a remote MTA, depending on its configuration and system load. The maximum number of concurrent LAN-based MTA connections is 240.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default MTA Concurrent connections configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Concurrent connections to LAN-MTAs value.

  4. Make sure the Base is set to hexadecimal and in the Value data field, enter 28 and click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the maximum number of concurrent LAN-based MTA connections, see the Knowledge Base article 243402, "XCON: Exchange Server MTA Event ID 9280" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=243402).


MTA Concurrent connections to X.400 gateways parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Concurrent connections to X.400 gateways

If the Exchange Server Analyzer finds the value for Concurrent connections to X.400 gateways present and set to anything other than 6, a non-default configuration message is displayed.

The Concurrent connections to X.400 gateways registry value is the maximum number of concurrent connections to remote X.400 message transfer agents (MTAs). The default value of 6 is sufficient for most organizations. There is a known issue when you use more than 4 EDK Connectors on a server running Exchange Server version 5.5 that requires the value for Concurrent connections to X.400 gateways to be increased to 0x12 (hexadecimal) or 18 (decimal). For more information about this issue, see the Microsoft Knowledge Base article 282115, "If more than 4 Exchange EDK connectors are installed, mail flow stops" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=282115). Unless you are experiencing the issue described in that article you should leave the Concurrent connections to X.400 gateways registry value set at 6.

To correct this, revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Concurrent connections to X.400 gateways value.

  4. In the Value data field, enter 6, and then click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA Concurrent MDB/delivery queue clients parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Concurrent MDB/delivery queue clients

If the Exchange Server Analyzer finds the value for Concurrent MDB/delivery queue clients present and set to anything other than 3, a non-default configuration message is displayed.

The Concurrent MDB/delivery queue clients value is the maximum number of message database (MDB) and Exchange API message access delivery queue clients that the message transfer agent (MTA) can support. Each client can have more than one session. This value should be set to at least two to support the private and public MDB entities.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Concurrent MDB/delivery queue clients value.

  4. In the Value data field, enter 3 and click OK.

  5. Exit the registry editor and restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA data files are being written to a compressed folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Compressed key for the message transfer agent (MTA) data path. If the Exchange Server Analyzer determines that the value for the Compressed key is True, an error is displayed.

Microsoft does not support the storage of Exchange data files on an NTFS file system compressed volume. When you store your Exchange data files on a compressed volume, the additional overhead significantly affects Exchange performance. Additionally, after an Exchange store database reaches a certain size, approximately 4 gigabytes (GB), it may not always mount or it may become corrupted.

The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

Files that are managed by Extensible Storage Engine (ESE) are not designed to be stored on a compressed drive. ESE depends on sector independence for log-based recovery, and compression of files invalidates sector independence. Compression should not be turned on for volumes hosting ESE databases, or any database that uses write-ahead logging.

Before Exchange 2000 Server Service Pack 3, compressed Exchange store databases were able to mount. However, corruption can result in any Exchange 2000 Exchange store databases or logs that have been compressed using NTFS compression.

With Exchange 2000 Server Service Pack 3, compressed information store database files of 128 megabytes (MB) or fewer are automatically decompressed. When database files grow to larger than 128 MB, the database does not mount and the error messages are generated in the application log. Exchange 2000 Server Service Pack 3 prevents compressed databases larger than 128 MB from mounting.

To turn off file compression on a specified folder

  1. Right-click the folder for which you want to turn off file compression, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Compress contents to save disk space check box, and then click OK.

To move the location of the MTA database files

  1. On Exchange Server version 5.5, you can move the MTA database files using the Performance Optimizer tool. For more information about how to do this on Exchange 2000 Server or Exchange Server 2003, see the Microsoft Knowledge Base article 259896, "XCON: How to Change the Location of the MTA Database and Run Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=259896).

For more information about Exchange data files and NTFS compression, see the following Microsoft Knowledge Base articles:

  • 170009, "XADM: NTFS Compressed Volume Causes Store to Fail" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=170009)

  • 327772, "XADM: Database Does Not Mount and You Receive Error 0xfffff05b After You Apply SP3" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327772)


MTA data files are being written to an encrypted folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Encrypted key for the message transfer agent (MTA) data path. If the Exchange Server Analyzer finds the value for this key is True, an error is displayed.

On an Exchange 2000 Server or an Exchange Server 2003 computer, the MTA files are written to the following default location:

<drive> :\Program Files\Exchsrvr\MTAdata

Microsoft does not support the storage of Exchange data files on an Encrypting File System (EFS) encrypted volume. When you store your Exchange data files on an encrypted volume, the additional overhead significantly affects Exchange performance. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To help secure your Exchange data files, it is recommended that you prevent unauthorized access to the Exchange computer and that you use the S/MIME message format to encrypt message data.

To turn off file encryption on a specified folder

  1. Right-click the folder where you want to turn off file compression, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Encrypt contents to secure data check box, and then click OK.

For more information about Exchange Server data files and EFS, see the Microsoft Knowledge Base article 834638, "Information about the storage of data files on an encrypted volume in Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638).

For information about how to secure messages in Microsoft Exchange Server 2003, see the Exchange Server 2003 Message Security Guide (http://go.microsoft.com/fwlink/?linkid=47574).


MTA data files are being written to a non-NTFS partition
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FSName key for the Exchange message transfer agent (MTA) data folder. If the Exchange Server Analyzer determines that the value for the FSName key does not equal NTFS, an error is displayed.

Microsoft does not support the storage of Exchange data files on non-NTFS volumes. The Exchange data files include all of the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

If you encounter this error, you must move the MTA data folder to an NTFS drive. Alternatively, if the drive on which the MTA data folder is stored is formatted as a file allocation table (FAT) drive, you can use the convert.exe command-line tool to convert the drive to NTFS.

To move the Exchange mtadata folder

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, right-click your storage group, and then click Properties.

  3. On the storage group property page, next to the System path location field, click Browse.

  4. Type the new path for the mtadata folder, and then click OK.

  5. Click OK.

As an alternative to this procedure, if the drive on which the files are stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS. For more information about using the convert.exe command-line tool to convert a FAT partition into an NTFS partition, see the Microsoft Knowledge Base article 214579, "How to Use Convert.exe to Convert a Partition to the NTFS File System" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579).


MTA DB data buffers per object parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\DB data buffers per object

If the Exchange Server Analyzer finds the value for DB data buffers per object present and more than zero but set to anything other than 3 or 6, a non-default configuration message is displayed.

The DB data buffers per object value is the number of 4 kilobyte (KB) database server buffers that are configured for each database object. More buffers require more memory, but make it less likely for a database object to be rolled out to disk because of a lack of buffer space. One recommended reason for changing this value is in the case when a message transfer agent (MTA) communicates with multiple Exchange Server version 5.5 computers either within a site, or between sites. Then, it is recommended that you change the value to 6. If this MTA does not meet this criterion, you should change the value back to its default setting of 3.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the DB data buffers per object value.

  4. In the Value data field, enter 3, and then click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA DB file handles parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\DB file handles

If the Exchange Server Analyzer finds the value for DB file handles present and set to anything other than 192, a non-default configuration message is displayed.

The DB file handles value is the number of database server file handles that are configured. This determines the maximum number of database files that can be open concurrently. If more open files are required than the configured value, database objects are copied to disk.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the DB file handles value.

  4. In the Value data field, enter 192 and click OK.

  5. Exit the registry editor and restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA Diagnostic Logging level is greater than 5 (MTA is in debug mode)
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads a series of registry keys to determine the level of message transfer agent (MTA) diagnostic logging set on the Exchange server. The registry keys reside at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Diagnostics

The default value for these keys is 0. If the Exchange Server Analyzer finds the value of any of these keys to be greater than 5, an error is displayed.

These registry keys are set by Exchange System Manager when you tune the logging levels on the Diagnostic Logging tab of a particular server's property page. Exchange System Manager lets an administrator set a specified logging level to None, Minimum, Medium, and Maximum. The corresponding values of the registry keys, respectively, are 0, 1, 3, or 5.

Therefore, a value greater than 5 can only be set by manually editing the registry, and should only be set at such a level during non-peak hours for very short debugging and troubleshooting. Setting these keys to integers above 5 heightens logging to debugging levels, which is extremely resource intensive. In addition to the debugging-level logging, setting these keys higher than 5 will output a "call.out" debug trace file every few seconds that is about 40 megabytes (MB) in size. This can fill the computer's event log in less than a minute.

The following table shows the MTA logging categories as they are listed on the Diagnostic Logging tab in Exchange System Manager and their corresponding key names in the registry.

Category as displayed in Exchange System Manager | Corresponding registry key name
X.400 Service | 1 X.400 Service
Resource | 2 Resource
Security | 3 Security
Interface | 4 Interface
Field Engineering | 5 Field Engineering
MTA Administration | 6 MTA Administration
Configuration | 7 Configuration
Directory Access | 8 Directory Access
Operating System | 9 Operating System
Internal Processing | 10 Internal Processing
Interoperability | 11 Interoperability
APDU (Application Protocol Data Unit) | 12 APDU

The reference at the end of this article provides more information about what each MTA category logs.

It is recommended that you set the logging for each MTA category at None (0) unless you are actively troubleshooting. The reason for this recommendation is to maintain a manageable number of events being logged. Even a level of Minimum (1) will likely produce hundreds of event logs over the course of a few days, depending on the category where the level is set.

If you are not currently troubleshooting, it is likely that these values were set higher during a troubleshooting exercise and were inadvertently left set. You must set these values to at least Maximum (5), but you should consider setting the logging level to None (0) for each MTA diagnostic logging category unless you are actively troubleshooting.

To set the MTA Diagnostic Logging categories to none

  1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In the console tree, expand Servers, expand the server that you want, and then click Properties.

  3. On <Server> Properties, click Diagnostic Logging.

  4. Under Services, click MSExchangeMTA.

  5. For each entry under Categories, set the logging level to none by selecting the category and then selecting None under Logging level.

  6. When you have set all categories to None, click Apply, and then click OK.

For more information about MTA diagnostic logging in Exchange 2000 Server and Exchange Server 2003, see the Microsoft Knowledge Base article 163033, "XCON: Description of Diagnostics Categories for MTA" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=163033).

For more information about MTA diagnostic logging in Exchange Server version 5.5, see the Knowledge Base article 163032, "XCON: Description of Diagnostics Logging for MTA" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=163032).


MTA Diagnostic logging level is non-zero
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads a series of registry keys to determine the level of message transfer agent (MTA) diagnostic logging set on the Exchange server. The registry keys reside at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Diagnostics

The default value for these keys is 0. If the Exchange Server Analyzer finds the value of any of these keys to be more than 1 but less than 6, a non-default configuration message is displayed.

These registry keys are set by Exchange System Manager when you tune the logging levels on the Diagnostic Logging tab of a specified server's property page. Exchange System Manager allows an administrator to set a specified logging level to None, Minimum, Medium, and Maximum. The corresponding values of the registry keys, respectively, are 0, 1, 3, or 5.

The following table shows the MTA logging categories as they are listed on the Diagnostic Logging tab in Exchange System Manager and their corresponding key names in the registry.

Category as displayed in Exchange System Manager | Corresponding registry key name
X.400 Service | 1 X.400 Service
Resource | 2 Resource
Security | 3 Security
Interface | 4 Interface
Field Engineering | 5 Field Engineering
MTA Administration | 6 MTA Administration
Configuration | 7 Configuration
Directory Access | 8 Directory Access
Operating System | 9 Operating System
Internal Processing | 10 Internal Processing
Interoperability | 11 Interoperability
APDU (Application Protocol Data Unit) | 12 APDU

The reference at the end of this article provides more information about what each MTA category logs.

The general best practice for diagnostic logging is to set the logging for each MTA category at None (0) unless you are actively troubleshooting. The reason for this recommendation is to maintain a manageable number of events being logged. Even a level of Minimum (1) will likely produce hundreds of event logs over the course of a few days, depending on the category where the level is set.

If you are not currently troubleshooting, it is likely that these values were set higher during a troubleshooting exercise and were unintentionally left set. Consider setting the logging level to None (0) for each MTA diagnostic logging category.

To correct this error on Exchange Server 2003 or Exchange 2000 Server

  1. Open Exchange System Manager.

  2. In the console tree, expand Servers, expand the server that you want, and then click Properties.

  3. In <Server> Properties, click the Diagnostic Logging tab.

  4. Under Services, select MSExchangeMTA.

  5. For each entry under Categories, set the logging level to none by selecting the category and then selecting None under Logging level.

  6. When you have set all categories to None, click Apply, and then click OK.

To correct this error on Exchange Server version 5.5

  1. Start the Microsoft Exchange Server Administrator program.

  2. Open the object that represents the server that is having difficulties with the MTA.

  3. Double-click the Message Transfer Agent object in the right pane.

  4. On the Diagnostics Logging tab, select the X.400 Service, and then click Maximum.

  5. Select Resource.

  6. Hold down the CTRL key, and then click each resource you want to debug.

  7. Click Option for a logging level of None.

  8. Click OK.

For more information about MTA diagnostic logging on Exchange 2000 Server, see the Microsoft Knowledge Base article 163033, "XCON: Description of Diagnostics Categories for MTA" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=163033).

For more information about rolling back advanced logging on Exchange Server 5.5, see the Knowledge Base article 168906, "XCON: Setting up Advanced Logging on the Exchange 5.0 and 5.5 MTAs" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=168906).

For more information about MTA diagnostic logging on Exchange Server 5.5, see the Knowledge Base article 163032, "XCON: Description of Diagnostics Categories for MTA" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=163032).


MTA Dispatcher threads parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

Error Message

Introduction

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Dispatcher threads

If the Exchange Server Analyzer finds the value for Dispatcher threads present and larger than zero but set to anything other than 1 or 2, a non-default configuration message is displayed.

The Dispatcher threads value is the number of message transfer agent (MTA) Dispatcher threads. This is multiplied by three for the three subtypes (Router, Fanout, Result) of the Dispatcher thread. One recommended reason for changing this value is when an MTA communicates with more than five Exchange Server version 5.5 computers either within a site, or between sites, or if distribution lists are heavily used. In that event, it is recommended that you change the value to 3. If this MTA does not meet this criterion, you should change the value back to its default setting of 1.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and then double-click the Dispatcher threads value.

  4. In the Value data field, enter 1 and then click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA is not running under LocalSystem account
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value set for the StartName key for the Microsoft Exchange MTA Stacks service. The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value for the serialNumber attribute on the Exchange Server object in the directory. The serialNumber attribute on the Exchange Server object identifies the version of Exchange Server running on the computer represented by the object. If the value for StartName key does not equal LocalSystem on an Exchange server running Exchange 2000 Server or Exchange Server 2003, an error is displayed.

Running the Exchange MTA Stacks service under any other account will cause permission and access errors and is not a supported configuration.

To resolve this error, you must configure the Exchange MTA Stacks service to start under the LocalSystem (aks SYSTEM) account.

Note:
This error does not apply to Exchange Server version 5.5. Only Exchange 2000 Server and Exchange Server 2003 require the Exchange MTA Stacks service to run under the LocalSystem account.

To configure the Exchange MTA Stacks service account

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. Locate and stop the Microsoft Exchange MTA Stacks service.

  3. Double-click Microsoft Exchange MTA Stacks service.

  4. On the Log On tab of the Microsoft Exchange MTA Stacks Properties page, select LocalSytem account under Log on as, and then click Apply.

  5. Under Service status, click Start, and then click OK.

  6. Close the Services snap-in.

For more information about running Exchange services under the LocalSystem account, see the Microsoft Knowledge Base article 239762, "Exchange Services Run Under LocalSystem" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762).


MTA Kernel threads parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Kernel threads

If the Exchange Server Analyzer finds the value for Kernel threads present and greater than 0 but set to anything other than 1 or 3, a non-default configuration message is displayed.

The Kernel threads value is the number of platform threads that handle the Presentation and Session level of the Open Systems Interconnection (OSI) stack. These threads are at the heart of message transfer agent (MTA) message processing. If this MTA communicates with many other Exchange Server version 5.5 servers using remote procedure call (RPC) over slow or highly latent network connections, it is recommended that you use a value listed in the following table.

Value | Description
0x3 (hex) | Standard recommendation. Use this for any MTA that communicates with other Exchange Server 5.5 servers using RPC over slow or highly latent network connections.
0x8 (hex) | Use this for Exchange 2000 Server or Exchange Server 2003 MTAs that belong to a site containing more than 15 Exchange Server 5.5 computers.
0xC (hex) | Use this for Exchange 2000 Server or Exchange Server 2003 MTAs that belong to a site containing more than 30 Exchange Server 5.5 computers.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to edit the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the Kernel threads value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Kernel threads value.

  4. In the Value data field, enter the value that is appropriate for your organization and click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA LAN-MTAs parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\LAN-MTAs

If the Exchange Server Analyzer finds the value for LAN-MTAs present and set to anything other than 20, a non-default configuration message is displayed.

The LAN-MTAs value is the number of network message transfer agents (MTAs) that are supported by the MTA. It is recommended that you use a value of 20 for this registry value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the LAN-MTAs value.

  4. In the Value data field, enter 20, and then click OK.

  5. Exit the registry editor and restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA MDB users parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\MDB users

If the Exchange Server Analyzer finds the value for MDB users present and set to anything other than 500, a non-default configuration message is displayed.

The MDB users value is the maximum number of message database (MDB) users who are supported by the message transfer agent (MTA). All Exchange Server users are MDB users by default unless they are explicitly set otherwise.

The MDB users registry value defines the number of distinguished names to cache from the directory. If your organization contains more than 1500 users, you should change the value to one-third the size of the global address list, but only to a maximum of 5000.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the MDB users value.

  4. In the Value data field, enter 500 and then click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA Max RPC calls outstanding parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Max RPC Calls Outstanding

If the Exchange Server Analyzer finds the value for Max RPC Calls Outstanding present and set to anything other than 50, a non-default configuration message is displayed.

The Max RPC Calls Outstanding value is the maximum number of remote procedure call (RPC) threads. This limits the maximum number of RPCs that are guaranteed to be processed at one time. This value is used by RpcServerUseAllProtSeqs() and RpcServerListen().

In mixed-vintage scenarios where Exchange 2000 Server and/or Exchange Server 2003 coexists with Exchange Server version 5.5 computers and you have increased the number of Gateway In/Out threads in the Store.exe process, it is recommended that you increase the value data to 0x80 (hex) or 128 (decimal).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Max RPC Calls Outstanding value.

  4. In the Value data field, enter 50 and click OK.

  5. Exit the registry editor and restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA Min RPC threads parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

Error Message

Introduction

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Min RPC Threads

If the Exchange Server Analyzer finds the value for Min RPC Threads present and set to anything other than 4, a non-default configuration message is displayed.

The Min RPC Threads value is the minimum number of remote procedure call (RPC) threads. This identifies the minimum number of call threads. This value is used by RpcServerListen(). Generally, you should not modify this registry value from its default setting.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Min RPC Threads value.

  4. In the Value data field, enter 4 and then click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA RTS threads parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\RTS threads

If the Exchange Server Analyzer finds the value for RTS threads present and greater than 0 but set to anything other than 1 or 3, a non-default configuration message is displayed.

The RTS threads value is the number of platform threads that handle the Reliable Transfer Service Element (RTSE) level of the Open Systems Interconnection (OSI) stack. RTS threads are responsible for putting data in the queues. You should adjust the RTS threads registry value from the default of 1 to a value of 3 if this message transfer agent (MTA) communicates with multiple Exchange Server version 5.5 computers either within a site or between sites.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To optimize the RTS threads registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the RTS threads value.

  4. In the Value data field, enter the appropriate value (1 or 3) and click OK.

  5. Exit the registry editor and restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA service is not running
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-19

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether the value set for following service's Started keys are set to True or False:

  • Microsoft Exchange MTA Stacks service

  • Cluster service

A value of False indicates that the service is not running on this Exchange Server computer. A value of True indicates that the service is running.

The Exchange Server Analyzer also examines the Exchange_Server WMI class in the root\MicrosoftExchangeV2 namespace to determine the value for the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is a front-end server.

If the value for all three evaluated keys is False, a warning is displayed.

It is recommended that all Exchange Server computers that route mail have the Exchange MTA Stacks service started. This is especially important in a mixed-mode environment where messages are transferred between Exchange Server version 5.5 and Exchange Server 2003 and/or Exchange 2000 Server. Additionally, any X.400 connectors require the Exchange MTA Stacks service, so disabling the service will produce errors and functionality may fail. Mailbox moves also require the Exchange MTA Stacks service to be started.

To resolve this warning, start the Exchange MTA Stacks service.

To start the Exchange MTA Stacks service

  1. From the Start menu, select Programs, Administrative Tools, and then the Services Microsoft Management Console (MMC) snap-in.

  2. Right-click Microsoft Exchange MTA Stacks service, and then click Properties.

  3. On the General tab of the Microsoft Exchange MTA Stacks property page, make sure the Start-up type is set to Automatic. If it is not, click Apply, and then click OK.

  4. Right-click Microsoft Exchange MTA Stacks service, and then click Start.

  5. Close the Services snap-in.

For more information about keeping the Exchange MTA Stacks service running in a mixed-code Exchange environment, see the Microsoft Knowledge Base article 810489, "MTA Stacks Service Must Remain Enabled on Exchange 2000 and 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810489).


MTA service is set to Disabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value set for the Microsoft Exchange MTA Stacks service StartMode key. A value of Disabled indicates that the Exchange MTA Stacks service has been disabled and cannot be started until the StartMode value is changed to either Manual or Automatic.

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine the value of the Started key for the Simple Mail Transfer Protocol (SMTP) service. A value of False indicates that the service is not running. A value of True indicates that the service is running.

Finally, the Exchange Server Analyzer queries the Win32_OperatingSystem WMI class to determine the value of the OSProductSuite key. The value of this key corresponds to a specific version of the Microsoft Windows Server™ 2003 operating system.

If the Exchange Server Analyzer finds the value for the StartMode key is set to Disabled on an Exchange Server computer that has the SMTP service started, and that the Exchange Server computer is not part of a Microsoft Windows Small Business Server 2003 installation, a warning is displayed.

Unless the server is part of a Microsoft Windows Small Business Server 2003 installation, or is in a pure Exchange Server 2003 native-mode environment, all Exchange Server computers that route mail must have the Exchange MTA Stacks service set to Automatic. Routing mail on a server where the Exchange MTA Stacks service is disabled may produce a variety of error messages. In some cases, errors will be logged if you are running in an Exchange 2000 Server or Exchange Server 2003 environment where Exchange Server version 5.5 is still running. Additionally, any X.400 connectors require the Exchange MTA Stacks service, so disabling the service will produce errors and functionality may fail.

Note:
Except for direct connectivity with external X.400 mail systems or running Exchange Development Kit (EDK) connectors such as Novell GroupWise Connector, Lotus Notes Connector, or a third-party Fax connector, dependencies on the MTA Stacks service have been removed in Exchange Server 2003. Therefore, Microsoft now supports pure, native-mode Exchange Server 2003 deployments in which the MTA Stacks service is disabled.

To resolve this error, you must configure the Exchange MTA Stacks service to start automatically on servers that route mail.

To configure the Exchange MTA Stacks service for automatic startup

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. Double-click Microsoft Exchange MTA Stacks service.

  3. On the General tab of the Microsoft Exchange MTA Stacks Properties page, select Automatic from the Startup type drop-down dialog box, and then click Apply.

  4. Under Server status, click Start, and then click OK.

  5. Close the Services snap-in.

For more information about keeping the Exchange MTA Stacks service running in Exchange, see the Microsoft Knowledge Base article 810489, "MTA Stacks service supportability guidelines for Exchange 2000 Server and Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810489).


MTA Submit/deliver threads parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\ Submit/deliver threads

If the Exchange Server Analyzer finds the value for Submit/deliver threads present and set to anything other than 2, a non-default configuration message is displayed.

The Submit/deliver threads value is the number of message transfer agent (MTA) Submit/Deliver threads. The MTA uses these threads to pass messages to the information store. On some Exchange Server version 5.5 computers, it is possible that this value was automatically changed by the Exchange Performance Optimizer from its default value of 2 to a value more appropriate for the Exchange server.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to edit the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Submit/deliver threads value.

  4. In the Value data field, ensure that a value of 2 is entered, and click OK.

  5. Exit the registry editor and restart the Microsoft Exchange MTA Stacks service for the change to take effect.

On Exchange 2000 Server and Exchange Server 2003 computers, the value for this entry should be set no greater than 3. For Exchange Server 5.5 computers, as an alternative to the preceding procedure, you can run the Exchange Performance Optimizer in verbose mode (perfwiz.exe -v) and set the value using that tool.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about situations in which the MTA Submit/deliver threads registry value should be changed from its default value, see the following Knowledge Base articles:

  • 234280, "XCON: How to Increase the Ability of the MTA to Pass Mail over Slow Network Connections" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=234280)

  • 265186, "XCON: MTA Fanout Slows on Multiprocessor Servers and Messages Back Up in Information Store" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=265186)

  • 234702, "XGEN: MTA Queue to Information Store Processing Slowly" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=234702)

  • 327260, "MTA slows down or stalls in Exchange Server 5.5 and messages back up in the private information store" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327260)

  • For more information about using the Exchange Performance Optimizer in verbose mode, see the Knowledge Base article 246125, "XADM: Exchange Server 5.5 Performance Optimizer Verbose Mode" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246125).


MTA TCP/IP control blocks parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

Error Message

Introduction

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\TCP/IP control blocks

If the Exchange Server Analyzer finds the value for TCP/IP control blocks present and set to anything other than 20, a non-default configuration message is displayed.

The TCP/IP control blocks value is the maximum number of concurrent RFC1006 (TCP/IP) connections that are supported. This setting controls the number of buffers available for X.400 connections. If this message transfer agent (MTA) hosts more than one X.400 connector, the TCP/IP control blocks value should be adjusted. There should be 10 control blocks for each X.400 connector being hosted, and one control block to service incoming connections. Therefore, for a system with three X.400 connections, the appropriate value would be 33.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the TCP/IP control blocks value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the TCP/IP control blocks value.

  4. In the Value data field, enter the value appropriate for this MTA, and then click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA TCP/IP threads parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

Error Message

Introduction

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\TCP/IP threads

If the Exchange Server Analyzer finds the value for TCP/IP threads present and set to anything other than 2, a non-default configuration message is displayed.

The TCP/IP threads value is the maximum number of message transfer agent (MTA) dynamic address module (DMOD) threads that handle RFC1006 connections. This number is multiplied by two for the two subtypes (Driver and Async Notify) of RFC1006 threads. On X.400 directory replication bridgehead servers and dedicated public folder servers that handle a large number of connections, it is recommended that this value be modified from its default of 2 to a value of 10.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to edit the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the TCP/IP threads value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the TCP/IP threads value.

  4. In the Value data field, enter the appropriate value and click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


MTA Transfer threads parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

Error Message

Introduction

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Transfer threads

If the Exchange Server Analyzer finds the value for Transfer threads present and greater than 0 but set to anything other than 1 or 2, a non-default configuration message is displayed.

The Transfer threads value is the number of message transfer agent (MTA) Transfer threads. This is multiplied by two for the two subtypes (Transfer In and Transfer Out) of each Transfer thread. This is the equivalent of the Submit/deliver threads value (which relates to MTA and information store message transfer) but for gateways and MTAs. For more information about the Submit/deliver threads value, see MTA Submit/deliver threads parameter is non-default.

If this is an Exchange 2000 Server or Exchange Server 2003 MTA that communicates with more than one Exchange Server version 5.5 computer either within a site or between sites, it is recommended that you adjust the value for Transfer threads to 3.

On some Exchange Server 5.5 computers, it is possible that this value was automatically changed by the Exchange Performance Optimizer from its default value of 2 to a value more appropriate for the Exchange Server computer.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the Transfer threads value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Transfer threads value.

  4. In the Value data field, enter the appropriate value and click OK.

  5. Close the registry editor and restart the Microsoft Exchange MTA Stacks service for the change to take effect.

On Exchange 2000 Server and Exchange Server 2003 computers, the value for this entry should be set no greater than 3. As an alternative to the preceding procedure, you can run the Exchange Performance Optimizer in verbose mode (perfwiz.exe -v) and set the value using that tool.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about situations in which the MTA Transfer threads registry value should be altered from its default value, see the following Knowledge Base articles:

  • 234280, "XCON: How to Increase the Ability of the MTA to Pass Mail over Slow Network Connections" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=234280)

  • 265186, "XCON: MTA Fanout Slows on Multiprocessor Servers and Messages Back Up in Information Store" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=265186)

  • 327260, "MTA slows down or stalls in Exchange Server 5.5 and messages back up in the private information store" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327260)


MTA Transport threads parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

Error Message

Introduction

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine its current value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Transport threads

If the Exchange Server Analyzer finds the value for Transport threads present and set to anything other than 1, a non-default configuration message is displayed.

The Transport threads value is the number of message transfer agent (MTA) Transport threads. The default value of 1 is generally sufficient for all organizations. Unless directed to do so by Microsoft Product Support Services, you should leave this value set at 1.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the Transport threads value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. In the right pane, locate and double-click the Transport threads value.

  4. In the Value data field, enter 1 and click OK.

  5. Close the registry editor and then restart the Microsoft Exchange MTA Stacks service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Message tracking Disabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-06

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the messageTrackingEnabled property of the server object is set to TRUE (enabled) or FALSE (disabled).

If the Exchange Server Analyzer determines that the messageTrackingEnabled property of the server object is set to False, the Exchange Server Analyzer displays an error.

The messageTrackingEnabled property of the server object determines the state of the Message Tracking Center for the server.

The Message Tracking Center, when it is enabled, logs information about the sender, the mail message, and the message recipients. Specifically, you can review statistics such as the time the message was sent or received, the message size and priority, and the list of message recipients. You can also log the subject line of e-mail messages. The Message Tracking Center searches for messages such as system messages, public folder messages, and e-mail messages.

You must enable the Message Tracking Center on each server for which you want to track messages. When it is enabled, all messages that are routed through a server are added to the message tracking logs.

The Exchange Server Analyzer requires that message tracking be enabled for it to start its scans.

Note:
The following permissions are required to perform this procedure: member of the local administrators group and member of a group that has had the Exchange Administrators role applied at the administrative group level
To enable Message Tracking Center on a server

  1. In Exchange System Manager, expand Servers, right-click the server on which you want to enable message tracking, and then click Properties.

  2. On the General tab, select the Enable message tracking check box.

  3. To record the subject of any message sent to, from, or through the server, select the Enable subject logging and display check box.

    Note:
    If you enable subject logging, you may cause some decrease in performance.

  4. Under Log file maintenance, you can prevent the removal of log files or modify the length of time that the log files are kept. The default period that tracking logs are kept is seven days.

    Note:
    On servers that process large quantities of mail, the tracking logs grow quickly. Make sure that you have sufficient disk space for the log files and for other services or applications that use this disk.

  5. Click OK or Apply. You do not have to restart services for this change to take effect.

For more information about how to use the Message Tracking Center, see Microsoft Knowledge Base article 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=262162).

For more information about how to troubleshoot Exchange Server 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).


Message tracking logs are being written to a compressed folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Compressed key for the message tracking log file path. If the Exchange Server Analyzer determines that the value for the Compressed key is True, an error is displayed.

When message tracking is enabled on an Exchange 2000 Server or an Exchange Server 2003 computer, the tracking logs are written to the following default location:

<drive> :\Program Files\Exchsrvr\ ServerName .log

where <drive> is the drive containing the \Program Files\Exchsrvr path and ServerName is the host name of the Exchange Server computer.

Microsoft does not support the storage of Exchange data files on an NTFS compressed volume. When you store your Exchange data files on a compressed volume, the additional overhead significantly impacts the performance of Exchange. In addition, after an information store database reaches a certain size, approximately 4 gigabytes (GB), it may fail to mount or it may become corrupted.

The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

Files that are managed by Extensible Storage Engine (ESE) are not designed to be stored on a compressed drive. The ESE depends on sector independence for log-based recovery, and compression of files invalidates sector independence. Compression should not be turned on for volumes hosting ESE databases or any database that uses write-ahead logging.

Before Exchange 2000 Server Service Pack 3, compressed information store databases were allowed to mount. However, corruption can result in any Exchange 2000 Server information store databases or information store logs that have been compressed by using NTFS compression.

With Exchange 2000 Server Service Pack 3, compressed information store database files of 128 megabytes (MB) or fewer are automatically decompressed. When database files grow to larger than 128 MB, the database does not mount and the error messages are generated in the application log. Exchange 2000 Server Service Pack 3 prevents compressed databases larger than 128 MB from mounting.

To turn off file compression for a specified folder

  1. Right-click the folder for which you want to turn off file compression, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Compress contents to save disk space check box, and then click OK.

As an alternative to the preceding procedure, you can move the message tracking log files to a different, uncompressed folder. For more information about moving the message tracking log files, see the following Microsoft Knowledge Base articles:

  • 84103, "How to change the location of the message tracking logs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=841089)

  • 317700, "How to change the location of the message tracking logs in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317700)

For more information about Exchange data files and NTFS compression, see the following Knowledge Base articles:

  • 170009, "XADM: NTFS Compressed Volume Causes Store to Fail" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=170009)

  • 327772, "XADM: Database Does Not Mount and You Receive Error 0xfffff05b After You Apply SP3" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327772)


Message tracking logs are being written to a non-NTFS partition
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FSName key for the Exchange message tracking logs file path. If the Exchange Server Analyzer determines that the value for the FSName key does not equal NTFS, an error is displayed.

Microsoft does not support the storage of Exchange data files on non-NTFS volumes. Exchange data files include all of the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

If you encounter this error, you must move the message tracking logs to a folder on an NTFS drive. Alternatively, if the drive on which the message tracking logs are stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS.

To move the message tracking logs in Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, right-click your server, and then click Properties.

  3. On the General tab, click Change.

  4. Type the new path of the message tracking logs, and then click OK.

  5. Click OK.
Note:
By default, the modification of the tracking log file location takes effect at midnight coordinated universal time (UTC). After this change takes effect, the Exchange message tracking component creates new log files in the new location that you specified. However, previous log files are not moved to the new location. Because of this, wait until the new log file location change has taken effect, and then manually move the log files from the old location to the new log file location. If the Microsoft Exchange System Attendant service is restarted, the log file path is immediately changed to the new location. In this scenario, Exchange message tracking creates a new log file in the new location when a user sends a message. In this scenario, you might have two log files that have the same name: one log file in the original location and one log file in the new location that you specified. If this behavior occurs, rename the log file that is stored in the original log file location before you move it to the new log file location. Use the same naming convention that is used by Exchange message tracking (yyyymmdd). However, in this case, use a date that is earlier than any one of the existing log files so that this renamed log file does not interfere with a future log file.

For more information about moving the message tracking log files on a computer running Exchange 2000 Server, see the Microsoft Knowledge Base article 317700, "How to change the location of the message tracking logs in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317700).

As an alternative to the preceding procedure, if the drive on which the files are stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS. For more information about using the convert.exe command-line tool to convert a FAT partition into an NTFS partition, see the Microsoft Knowledge Base article 214579, "How to Use Convert.exe to Convert a Partition to the NTFS File System" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579).


Message tracking logs are being written to an encrypted folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Encrypted key for the message tracking log files. If the value for this key is True, an error is displayed.

When message tracking is enabled on an Exchange 2000 Server or an Exchange Server 2003 computer, the tracking logs are written to the following default location:

<drive>:\Program Files\Exchsrvr\ ServerName .log

where <drive> is the drive containing the \Program Files\Exchsrvr path and ServerName is the host name of the Exchange Server computer.

Microsoft does not support the storage of Exchange data files on an Encrypting File System (EFS) encrypted volume. When you store your Exchange data files on an encrypted volume, the additional overhead significantly impacts the performance of Exchange. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To help secure your Exchange data files, it is recommended that you prevent unauthorized access to the Exchange computer and that you use the S/MIME message format to encrypt message data.

To turn off file encryption for a specified folder

  1. Right-click the folder for which you want to turn off file encryption, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Encrypt contents to secure data check box, and then click OK.

As an alternative to the preceding procedure, you can move the message tracking log files to a different, non-encrypted folder. For more information about moving the message tracking log files, see the following Microsoft Knowledge Base articles:

  • 841089, "How to change the location of the message tracking logs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=841089)

  • 317700, "How to change the location of the message tracking logs in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317700)


Metabase cannot be accessed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-13

The Microsoft® Exchange Server Analyzer Tool tries to read various properties of the Simple Mail Transfer Protocol (SMTP) virtual server instance from the Internet Information Services (IIS) metabase path:

/LM/SmtpSvc/<SMTP virtual server instance>

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The metabase query fails.

  • Exchange Server is not running on Microsoft Windows NT® Server 4.0.

This error indicates that the Exchange Server Analyzer cannot connect to the IIS metabase.

The IIS metabase includes information that affects Exchange Server, such as protocol settings for HTTP, virtual directories for mailbox and mobile device access, and HTTP security settings.

To resolve this issue, verify the integrity of the metabase and that IIS is installed correctly.

To verify that the metabase is not corrupted and IIS is installed correctly, see the following resources:

  • Microsoft Knowledge Base article 240225, "Description of Adsutil and MetaEdit Utilities Used to Modify the Metabase" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240225).

  • Microsoft Knowledge Base article 317678, "HOW TO: Restart Internet Information Services (IIS) on Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=317678).

If the guidance in these resources does not resolve the issue, you may have to uninstall and then reinstall IIS.

To uninstall IIS using Add or Remove a Windows Component in Control Panel

  1. Click Start, and then click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list click the Application Server check box.

  5. Click Details.

  6. Click Internet Information Services Manager.

  7. Click Next.

  8. Click Finish when IIS is uninstalled.
To install IIS using Control Panel

  1. Click Start, and then click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list click the Application Server check box.

  5. Click Details.

  6. Click the Internet Information Services Manager check box.

  7. Click OK until you are returned to the Windows Component Wizard.

  8. Click Next, and then complete the Windows Component Wizard.


MinUserDC value is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether the Active Directory® directory service domain controller acting as the primary domain controller (PDC) emulator has been manually excluded from the list of domain controllers available for use by Exchange:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

If the Exchange Server Analyzer finds MinUserDC to be present and configured, a non-default configuration message is displayed.

A PDC emulator is an Active Directory operations master role computer that processes replication requests from Microsoft Windows NT® Server 4.0 backup domain controllers and processes all password updates for clients that are not running Active Directory-enabled client software. PDC emulators are also domain controllers, and are therefore available for use by applications such as Exchange.

Directory Service Access (DSAccess) is an internal component in Exchange 2000 Server and Exchange Server 2003 that controls how all Exchange components access Active Directory. The primary function of DSAccess is to maintain information about various directory-related events and operations. For example, DSAccess discovers the Active Directory topology and detects if domain controllers and global catalog servers are available and responding to queries.

By default, DSAccess includes the PDC emulator computer in its list of available and usable domain controllers. If non-Exchange programs are making heavy use of the PDC emulator, using the PDC emulator by DSAccess could cause performance problems on the PDC emulator computer, as well as on the Exchange server and the non-Exchange program computer.

To prevent such performance issues, the MinUserDC registry value can be added to the registry on an Exchange server to force DSAccess to query all other available domain controllers before querying the domain controller that holds the PDC emulator operations master role.

Note:
An Exchange server configured with the MiniUserDC registry value will try to use other servers in the same domain first so it is recommended that this configuration only be set if the site contains at least two domain controllers for the domain containing the Exchange servers.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To examine and edit the MinUserDC registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

  3. Locate the MinUserDC value and make any required changes. If this DWORD value does not exist, you can manually create it.

  4. The value data that is configured for the MinUserDC registry entry is the maximum number of domain controllers to contact before contacting the PDC emulator. For example, setting MinUserDC to 4 configures DSAccess to exclude the PDC emulator only when a total of 4 domain controllers are available. When this condition is met, the PDC emulator is excluded from use and DSAccess communicates only with the remaining 3 domain controllers.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about using the MinUserDC registry entry, see the Knowledge Base article 298879, "XADM: Exchange 2000 May Experience Performance Problems When PDC Emulator Is Used for DSAccess" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298879).


More than 1000 mailbox stores are present
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-12-13

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service and maintains a count of Microsoft Exchange Information Store objects, with object class of msExchPrivateMDB. If the Exchange Server Analyzer determines that there are more than 1,000 mailbox stores in an organization, a warning is displayed.

A warning is displayed because a known issue exists where users accessing mailboxes from Microsoft Office Outlook® Web Access 2003 through front-end servers in organizations with more than 1,000 mailbox stores, cannot access their mailboxes. This issue is caused by how the front-end Exchange server proxies the authentication request to the back-end Exchange server.

If you have users who are accessing their mailbox stores from front-end Exchange servers and you are getting this warning, you must do one of the following:

  • Obtain and install the Exchange Server hotfix that is described in the Microsoft Knowledge Base article 899902, "Users receive a 401 error message when they try to access a mailbox that is in an Exchange Server 2003 front-end server by using Outlook Web Access" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=899902).

  • If you can, consolidate mailboxes onto fewer mailbox stores.

  • Set the front-end servers to authenticate to the back-end servers with Basic authentication. The rest of this article describes this option.

By default, Exchange Server 2003 front-end servers will use Kerberos authentication to help protect user credentials between the front-end and back-end servers. If Kerberos authentication fails, a Warning event will be logged and the front-end server will try NTLM instead. If NTLM fails, an error will be logged. Kerberos authentication is re-tried in 30 minutes. When Exchange 2000 Server or Exchange Server 2003 front-end computers authenticate with Exchange 2000 Server back-end computers, NTLM is used. There is no user interface in either Internet Information Services (IIS) or Exchange System Manager to select authentication mechanisms.

Configuring the front-end Exchange server to use Basic authentication requires that you set a registry key on all front-end servers in your organization. The following procedure explains how to manually set the key.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure Exchange front-end servers to use Basic authentication against Exchange back-end servers

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

    Navigate to:= HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\MSExchangeWeb

  2. Right-click MSExchangeWeb, point to New, and then click Key. Name the new key Dav.

  3. Right-click the new Dav key, point to New, and then click DWORD Value.

  4. Name the new value UseBasicAuthToBE and then set the value to 1.

  5. Open the Services Microsoft Management Console (MMC) snap-in, right-click IIS Admin Service, and then click Restart.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Most Ongoing store.exe calls are waiting for a response from ESE
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for events that indicate ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the Exchange Extensible Storage Engine (ESE).

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

The Microsoft Exchange Information Store sits on top of an ESE database. ESE is a sophisticated, transaction-based database engine. A transaction is a series of operations that are treated as an atomic (indivisible) unit. All operations in a transaction are either completed and permanently saved, or else no operations are performed.

Exchange Server uses ESE as an embedded database engine that determines the structure of the databases and manages memory. The database engine caches the databases in memory by transferring four-kilobyte (KB) chunks of data (pages) in and out of memory. It updates the pages in memory and writes new or updated pages back to the disk. When requests come to the system, the database engine can buffer data in memory. Therefore, it does not have to access the disk constantly.

Although caching data in memory is the fastest and most efficient way to process data, it means that when Exchange is running, the information on disk is never completely up-to-date. The latest version of the database is in memory. However, because many changes in memory are not yet on disk, the database and memory are not synchronized. The transaction log disk is always kept current with information about each transaction.

If the Exchange Server Analyzer finds that events in the Store.fcl logging file reflect a predominance of calls from the Exchange Information Store service (Store.exe) to the ESE database, the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Microsoft Exchange Information Store service to the ESE can be caused by the following conditions:

  • Exchange online defragmentation.

  • Data backups.

    Note:
    If a data backup or online defragmentation was in process during the Exchange Call Trace logging collection, you can safely ignore the error message as an indicator of an Exchange Server performance issue.
  • Bottlenecks on the database drives, for example, insufficient capacity for the number of users on the server.

  • Bottlenecks on the TEMP and TMP drives.

To resolve this error, take the following steps:

  • As a best practice, we recommend that you not overlap backup windows or online maintenance with peak-user demand intervals.

  • Make sure that the database disk drives are healthy and have sufficient throughput for the I/O load.

  • Run the Exchange Server Analyzer for an additional analysis of the server. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about how to configure the online defragmentation time windows, see Microsoft Knowledge Base article 244524, "XADM: How to Configure the Exchange Server Online Defragmentation Time Window" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=244524).

For more information about Exchange Server Disk Bottleneck issues, see Disk Bottleneck Detected.

For more information about how to size and optimize disks for Exchange Server, see "How to Calculate Your Disk I/O Requirements" and "Best Practices Common to Multiple Architectures" in Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=49324).

For more information about ESE, see "Extensible Storage Engine Architecture" (http://go.microsoft.com/fwlink/?linkid=67009).


Most Ongoing store.exe calls are waiting for a response from IMAIL
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Server Function Call Log (FCL), the Store.fcl file, for events that indicate a predominance of ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the IMAIL component of the MAPI client.

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

The IMAIL component of Exchange Server is a flexible conversion service that is used by the Microsoft Exchange Information Store service between Internet and MAPI messages. This allows for interoperability between clients that use RFC-822 or Internet format and clients that use the Exchange Server internal storage format, such as MAPI clients or internal STORE tasks.

Exchange uses the IMAIL mechanism to apply message formats to the content, as defined for Internet domains in Exchange System Manager or as specified by the user per recipient in Microsoft Office Outlook®. If no formatting parameters are passed to IMAIL, IMAIL formats MAPI messages in Summary TNEF (S/TNEF) format for transfer between servers.

If the Exchange Server Analyzer finds events in the Store.fcl logging file that reflect a predominance of ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to the IMAIL component of the MAPI client, the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Microsoft Exchange Information Store service to the IMAIL component of the MAPI client can occur when one or more of the following conditions are true:

  • IMAIL tries to process much data in a message or attachment.

  • Many clients request data conversion.

  • DSAccess requests encounter a slow response.

  • There are bottlenecks on the TEMP and TMP drives.

  • There are ongoing mailbox moves.

To resolve this error, take the following steps:

  • Schedule any mailbox moves for off-peak hours.

  • Run the Exchange Server Analyzer for an additional analysis of server issues such as message and attachment size limits. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about disk bottleneck issues with Exchange Server, see Disk Bottleneck Detected.

For more information about how to size and optimize disks for Exchange Server, see "How to Calculate Your Disk I/O Requirements" and "Best Practices Common to Multiple Architectures" in Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=49324).

For more information about best practices for message size limits on Exchange Server, see Maximum outgoing message size has not been set.

For more information about DSAccess and Exchange Server performance, see "How to Configure the DSAccess User Cache" in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).


Most Ongoing store.exe calls are waiting for a response from LSASS
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-11

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Server Function Call Log (FCL), the Store.fcl file, for events that indicate a predominance of ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the Local Security Authentication Server (Lsass.exe) process.

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

The Local Security Authentication Server process (Lsass.exe) is a security subsystem invoked by other processes to verify account information and logon validation.

Every Exchange client logon causes the server that is running Exchange Server to send a request to look up the account security identifier (SID) for the client and creates a call within the Local Security Authentication Server (Lsass.exe) process.

If the Exchange Server Analyzer finds events in the Store.fcl logging file that reflect a predominance of ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to the Local Security Authentication Server (Lsass.exe) process, the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Microsoft Exchange Information Store service to the LSASS process can be caused by the following conditions:

  • Server resource issues related to the number of users who authenticate at the same time.

  • Network latency between the Exchange server and the Domain Controller or global catalog server.

  • Server resource bottleneck issues.

To resolve this error, take the following steps:

  • Consider implementing the NeverPing parameter as described in 'NeverPing' Parameter Recommended.

  • Review the articles in the For More Information section of this document.

For More Information

For more information about the Lsass.exe process and memory usage, see Microsoft Knowledge Base article 308356, "Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356).

For more information about Exchange client logons and LSASS issues, see Microsoft Knowledge Base article 161938, "Slow Exchange Client Logons Due to Resource Deadlock" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=161938).

For more information about network latency between the Exchange server and the Domain Controller or global catalog server, see the following Exchange Server Team Blog article, "Exchange Does Not Always Use Local GCs" (http://go.microsoft.com/fwlink/?LinkId=69166).

Note:
The content of each blog and its URL are subject to change without notice.

For more information about server resource bottleneck issues, see Processor Bottleneck.

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).


Most Ongoing store.exe calls are waiting for a response from the directory
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-14

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), Store.fcl file, for events that indicate a predominance of ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the Active Directory® directory service.

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

Active Directory provides all mailbox information, address list services, and other recipient-related information. Most Exchange Server 2003 configuration information is also stored in Active Directory.

Exchange Server services access information that is stored in Active Directory and writes information to Active Directory.

If the Exchange Server Analyzer finds events in the Store.fcl logging file that reflect a predominance of calls from the Microsoft Exchange Information Store service (Store.exe) to Active Directory, the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Microsoft Exchange Information Store service to Active Directory can be caused by the following conditions:

  • Network latency between the Exchange server and the Domain Controller.

  • Static or otherwise incorrect configuration of DSAccess.

  • An overloaded domain controller and global catalog.

  • An incorrectly designed Active Directory topology.

To resolve this error, take the following steps:

  • Run the Exchange Server Analyzer for an additional analysis of server issues such as message and attachment size limits. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Check the performance of the Active Directory Domain Controller servers.

  • Review the articles in the For More Information section of this document.

For More Information

For more information about Exchange performance and DSAccess, see Microsoft Knowledge Base article 250570, "Directory service server detection and DSAccess usage" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250570).

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).

For more information about Domain Controller performance, see the following Windows Server resources:

  • "Planning Domain Controller Capacity" (http://go.microsoft.com/fwlink/?LinkId=70191).

  • "Active Directory Monitoring of Domain Controllers" in the Windows 2000 Server Active Directory Planning and Deployment Guides (http://go.microsoft.com/fwlink/?LinkId=70193).


Most Ongoing store.exe calls are waiting for a response from the Virus Scanner
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for events that indicate a predominance of ongoing cross component calls from the Exchange Information Store service (Store.exe) to the Virusscan Virus API (VAPI) component.

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

If the Exchange Server Analyzer finds that events in the Store.fcl logging file reflect a predominance of ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to the Virusscan VAPI component, the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Microsoft Exchange Information Store service to the Virusscan VAPI component can be caused by the following conditions:

  • Updates to a virus scanner that generate a re-scan of items in the information store.

  • A misconfigured virus scanner

  • Virus scanner software processes a large message or attachment

To resolve this error, take the following steps:

  • Schedule updates to your virus engine for times when resource consumption is low, that is, off-peak demand hours.

  • Consider reinstalling the virus scanning software, but reinstall at off-peak demand intervals.

  • Examine the configuration of your virus scanning engine for the correct thread configuration, file level exclusions, and so on. See Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about virus-scanning programs that are typically used with Microsoft Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

For more information about virus-scanning programs that are typically used with Microsoft Exchange 2000 Server, see the Knowledge Base article 328841, "Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).


Most Ongoing store.exe calls are waiting for a response from VSS Snapshot
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for events that indicate ongoing cross-component calls from the Exchange Information Store service (Store.exe) to the Volume Shadow Copy Service (VSS) snapshot component.

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

VSS is a set of COM APIs that implements a framework that enables volume backups to be performed when applications on a system continue to write to the volumes.

Microsoft Exchange Server 2003 uses the VSS that is included in the Microsoft Windows Server™ 2003 operating system to take volume shadow copies of Exchange Server 2003 databases and transaction log files.

A VSS snapshot is not fully independent of the original data. Generically, snapshots are created when you define a marker in time and make sure that the data can be rolled back to that time.

If the Exchange Server Analyzer finds that events in the Store.fcl logging file reflect ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to the VSS snapshot component, the Exchange Server Analyzer displays a best practices message.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Note:
If a VSS snapshot was intentionally initiated within 20 seconds of the Exchange Call Trace logging collection, you can safely ignore this message as an indicator of an Exchange Server performance issue.

As a best practice, we recommend that you not overlap backup windows with online maintenance or peak-user demand intervals.

For More Information

For more information about VSS, see "Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=56571).


The MOUNTMGR.SYS File is an Incorrect Version
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether Microsoft Windows® Server 2003 is installed: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\

The Exchange Server Analyzer also performs the following queries:

  • The Win32_OperatingSystem Microsoft Windows Management Instrumentation (WMI) class to determine whether Windows Server 2003 Service Pack 1 is installed.

  • The Win32_Service WMI class to determine whether Cluster service is running.

  • The Win32_Volume WMI class to determine whether there are Volume Mount Points present.

  • The CIM_Datafile WMI class to determine whether the value of the Version key for Mountmgr.sys is less then 2443.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The Version key for Mountmgr.sys is less then 2443.

  • The server is a node of a Cluster running Windows Server 2003 Service Pack 1.

  • The server has volume mount points.

The version of Mountmgr.sys installed on the cluster node may cause volume mount point failures. This problem occurs because of a problem in the Mountmgr.sys driver. This is an intermittent timing problem that can occur when a volume arrives to be mounted to a mount point.

Note:
Generally, this problem does not occur in a non-clustered environment. In a non-clustered environment, the timing of the volume mount process is different.

For more information about this issue, see Microsoft Knowledge Base article 898790, "Volume mount points on disks in a server cluster may intermittently become unavailable after you install Windows Server 2003 Service Pack 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=898790).


Move Temp and TMP Directories
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-09-01

The Microsoft® Exchange Server Analyzer Tool has determined that the TEMP and TMP folders for the server may not be located for optimal disk performance. As a best practice, it is recommended that the TEMP and TMP folders be stored on a disk subsystem that is not shared by your system folder or the Exchange data files.

The Microsoft Exchange Information Store service uses the TEMP and TMP folders as temporary storage during various operations, such as message conversion, working with large attachments, and mailbox move operations. The TEMP and TMP environment variables are used to designate which folders in the file system (for example, which path) should be used by applications that require a temporary workspace. TEMP is typically used by applications, such as Microsoft Exchange, and TMP is typically used by development tools, such as Microsoft Visual C++®. The path for each variable is usually relative to the security context of the application or tool.

On a non-clustered Exchange server, the Exchange store uses the SYSTEM (for example, Local System) folder, which uses a default environment variable setting of %Systemroot%\Temp for both TEMP and TMP. Exchange Virtual Servers that are running in a Microsoft Windows® server cluster use the environment variable settings for the Cluster service account, which runs under the context of a specific user security principle. For user accounts, the default environment variable for TEMP and TMP is set to %Userprofile%\Temp.

This article explains how to move the TEMP and TMP directories in clustered and non-clustered environments. Before you perform the procedures in this article, consider the following recommendations:

  • For optimal performance, it is recommended that you do not use the disk containing the operating system for the TEMP and TMP folders used by Exchange. In addition, you should ensure that these environment variables are set to paths on a fast disk or disk subsystem, such as a RAID-0+1 spindle set.

  • It is recommended that you do not use the disk Exchange transaction logs for the TEMP and TMP folders used.

To move the TEMP or TMP folders in a non-clustered environment

  1. Log on to the computer that is running Exchange Server with an account that has administrative rights.

  2. Right-click My Computer, and then select Properties.

  3. Select the Advanced tab.

  4. Click Environment Variables.

  5. In the System variables area, select TEMP and then click Edit.

  6. In the Variable value field, enter the new path for the TEMP environment variable and then click OK.

  7. In the System variables area, select TMP and then click Edit.

  8. In the Variable value field, enter the new path for the TMP environment variable and then click OK.

  9. Click OK to close the Environment Variables dialog box and then click OK to close the System Properties dialog box.

  10. Reboot the server to apply all the changes.
To move the TEMP or TMP folders in a clustered environment

  1. Log on to a node in the cluster as the Cluster service account.

  2. Right-click My Computer, and then select Properties.

  3. Select Advanced.

  4. Click Environment Variables.

  5. In the User variables for <account name> area, select TEMP and then click Edit.

  6. In the Variable value field, enter the new path for the TEMP environment variable and then click OK.

  7. In the User variables for <account name> area, select TMP and then click Edit.

  8. In the Variable value field, enter the new path for the TMP environment variable and then click OK.

  9. Click OK to close the Environment Variables dialog box and then click OK to close the System Properties dialog box.

  10. Restart the node to apply the change.

  11. Repeat steps 1 through 10 for each node in the cluster.
Important:
You must give the Authenticated Users account the appropriate permissions to the new path for the TMP and TEMP folders.
To assign the Authenticated Users group permissions to the TMP or TEMP folders

  1. Start Windows Explorer, locate and then right-click the folder that the TEMP variable or the TMP variable points to, and then click Properties.

  2. In the Temp Properties dialog box, click the Security tab, and then click Add.

  3. In the Select Users, Computers, or Groups dialog box, add the Authenticated Users group to the object names list and click OK.

  4. Click Advanced to access advanced security settings.

  5. Select Authenticated Users in the Name list and then click Edit to display the Permission Entry dialog box.

  6. Use the fields in the Permissions area to allow the following special permissions:

    Traverse Folder / Execute File

    Create Files / Write Data

    Create Folders / Append Data

  7. Click OK three times to apply the permissions and exit.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Move User Mailboxes to Another Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool has determined that your server currently has a higher user load than it can support efficiently. The current user load is causing performance issues. It is recommended that you move users to another location by moving a small number of them (typically five percent of your total users) each night until the performance issues are resolved.

This approach is recommended because one of the following issues has occurred:

  • Some Exchange database files are on disks which are at or beyond the limit of their throughput capacity.

  • Other server resources (such as memory or CPU) are over capacity.

  • A disk is over capacity, which means that the disk subsystem that currently supports one or more of your Exchange stores has an average disk I/O latency that exceeds current recommended levels. You should move five percent of your users to a database on a different disk subsystem until the problem is resolved. If the database drives are a bottleneck, move the users to a database that is located on a different drive. If a storage group drive is the bottleneck, move the users to a database in another storage group that is located on another database. If the drives are shared by another resource, another possible solution is to reduce the load of other applications on those drives.

  • Your physical server is over capacity. You currently do not have enough processor or memory to support the server load that your users are generating. You should move five percent of your users to another server until the performance problems are resolved.

Note:
While the Exchange clients are not required to be disconnected from their mailboxes during a move mailbox operation, it is recommended that the move take place when Exchange client activity is low, such as off peak hours, to avoid possible service disruption.
To move mailboxes on Exchange Server 2003

  1. Start Exchange System Manager on the Exchange Server 2003 computer where you want to run the process.

  2. Double-click Servers, and then locate the server container where the mailboxes of the users are located.

    For example, if you want to move mailboxes from the default storage group and mailbox store, double-click First Storage Group, double-click Mailbox Store, and then click Mailboxes.

  3. In the details pane, click the mailboxes you want to move.

  4. Right-click the selected users, and then click Exchange Tasks.

  5. In the Exchange Task Wizard, click Next.

  6. On the Available Tasks page, click Move Mailbox under Select a task to perform, and then click Next.

  7. On the Move Mailbox page, in the Server list, click the server you want, and then, in the Mailbox Store list, click the mailbox store you want.

  8. Click Next.

  9. Configure how you want any corrupted messages that are found during the move to be handled, and then click Next.

  10. Click Next.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about moving mailboxes with Exchange Server 2003, see Microsoft Knowledge Base article 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829).

  • For more information about moving mailboxes between Exchange 2000 Server and Exchange Server 5.5, see Microsoft Knowledge Base article 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810).


NAS configuration problem
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchESEParamLogFilePath attribute of each storage group object. This attribute specifies the location of the transaction log files used by databases in the storage group.

The Exchange Server Analyzer also queries Active Directory to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

Additionally, the Exchange Server Analyzer also queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Microsoft Windows Storage Server 2003 feature pack service (wssexchmap). A value of False indicates that the Windows Storage Server 2003 feature pack service is not running on this Exchange server. A value of True indicates that the Windows Storage Server 2003 feature pack service is running.

If the Exchange Server Analyzer determines that the value for any msExchESEParamLogFilePath attribute starts with S:\{, and that the Windows Storage Server 2003 feature pack service is started on an Exchange Server computer with more than 1500 mailboxes, a warning is displayed.

Windows Storage Server 2003 is the Microsoft platform for NAS devices. The Windows Storage Server 2003 storage layout is recommended for use with Exchange Server 2003 and is somewhat different from the standard Exchange Server layout. The recommended configuration is to put the Exchange Server databases on Windows Storage Server 2003 and put the transaction log files on a local disk inside the Exchange Server computer.

Microsoft developed the Windows Storage Server 2003 feature pack for three specific types of workload:

  • Small workloads, for up to 250 mailboxes hosted by one Exchange Server connected to one Windows Storage Server computer. In this scenario, the recommended Windows Storage Server configuration is a 1 gigahertz (GHz) or faster processor, 512 megabytes (MB) of RAM, four SCSI or IDE/SATA disks configured as a RAID-5 volume, and two network interface cards (NICs): one for connection to the LAN and a private Gigabit Ethernet adapter for connection directly to the Exchange server. The Exchange databases are stored on the RAID-5 volume; transaction logs remain on the Exchange server's local RAID-1.

  • Medium workloads, with up to 750 mailboxes in one storage group, hosted by one Exchange Server and a single Windows Storage Server computer. In this configuration, the Windows Storage Server computer should have a pair of 1 GHz or faster processors, 1 gigabyte (GB) of RAM, six SCSI disks, and a pair of NICs. The disks should be configured as a 4-disk RAID-5 array for databases and a separate two-disk mirror set for the transaction logs.

  • Large workloads, with one or two Exchange Server 2003 servers hosting up to 1,500 mailboxes in two storage groups. In this configuration, the Windows Storage Server should have two 1 GHz or faster processors, 2 GB of RAM, and a total of 14 disks: 10 for a RAID 0+1 array to hold the databases and two sets of mirrored disks for transaction logs.

This warning indicates that the Exchange Server computer has been configured to use Windows Storage Server 2003 for storage. When using Windows Storage Server for Exchange Server data storage, it is recommended that fewer than 1,500 concurrent users access the Exchange Server.

To correct this warning

  • Do one of the following:

    • Move the transaction logs to a local disk in the Exchange Server computer

    • Move some of the mailboxes on this Exchange Server computer to another Exchange Server computer so that there are 1,500 or fewer mailboxes on the Exchange Server computer using Windows Storage Server.

For more information about using the Windows Storage Server 2003 feature pack with Exchange Server 2003, see the document, Managing Exchange Storage with the Windows Storage Server 2003 Feature Pack (http://go.microsoft.com/fwlink/?linkid=34942).

For further information, see the following additional resources:

  • Introduction to Windows Storage Server 2003 Architecture and Deployment (http://go.microsoft.com/fwlink/?linkid=34943)

  • Building Better Protected Storage using Windows Storage Server 2003 (http://go.microsoft.com/fwlink/?linkid=34944)

  • Server Consolidation Using Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=47586)


networkAddress attribute is not set correctly
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the networkAddress attribute contains the ncacn_ip_tcp string. The Exchange Server Analyzer displays an error if either of the following conditions exist:

  • The ncacn_ip_tcp string does not exist.

  • The ncacn_ip_tcp string is corrupted.

In Microsoft Office Outlook® Web Access for Exchange Server 2003, the front-end server examines the networkaddress attribute value when it tries to connect to an Exchange back-end server.

Note:
Exchange 2000 Server does not do this with Outlook Web Access.

The front-end server requires a fully qualified domain name (FQDN) value. The front-end server checks for a period in the value that is returned for networkaddress ncacn_ip_tcp. The connection request for the mailbox on the specific back-end server fails and the front-end server returns an "HTTP 500 Internal Server Error" error message to the user if the following conditions exist:

  • The networkaddress ncacn_ip_tcp value is just a host name or a network basic input/output system (NetBIOS) name.

  • The networkaddress ncacn_ip_tcp value is not an FQDN.

You must update the networkaddress ncacn_ip_tcp value on the server object in Active Directory to ensure appropriate functionality of Outlook Web Access 2003. The affected server name is provided in the Exchange Server Analyzer error message.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
Note:
Before you update the ncacn_ip_tcp value, read the rest of this article. To minimize the downtime that is caused when you restart Exchange Server services, you should perform an additional procedure before you restart the Exchange Server services.
To update the ncacn_ip_tcp value on the networkAddress attribute

  1. Start the ADSI Edit tool from Windows 2000 Server support tools or from Windows Server 2003 support tools.

  2. Expand the following nodes:

    • Configuration Container

    • Configuration

    • Services

    • Microsoft Exchange

    • Organization_Name

    • Administrative Groups

    • Administrative_Group_Name

    • Servers

  3. Right-click Exchange_Server_Name, and then click Properties.

  4. Click networkaddress in the Attributes list, and then click Edit.

  5. Add a new value for ncacn_ip_tcp. Use the FQDN of the server instead of the NetBIOS name or the host name of the server.

    The syntax for this value is ncacn_ip_tcp:FQDN. For example, if your Exchange back-end server has a host name of EXCHANGE1 and the FQDN is EXCHANGE1.contoso.com, use the following value for ncacn_ip_tcp: ncacn_ip_tcp:EXCHANGE1.contoso.com

  6. Click OK two times to apply the change.

  7. Restart all Exchange Server services on the server.

  8. If there are multiple domain controllers, wait for replication to occur before you try to log on from the front-end server. If the problem is not resolved after replication is complete, restart the IIS Admin Service on the front-end server.

If you maintain host files on back-end servers to correlate a server IP address that has a short host name, you must also update the UpdateProtocols registry value. If a host file is used, Exchange Server may change back the ncacn_ip_tcp value when Microsoft Exchange System Attendant is restarted. If the back-end server is clustered, Exchange Server may change back the ncacn_ip_tcp value after fail over.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To modify the UpdateProtocols registry value for back-end servers that use host files

  1. Use a registry editor to configure the following registry value on the back-end server or servers: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\UpdateProtocols

    Note:
    If the UpdateProtocols value is not present, you must create it. To do this, follow these steps:

  2. Open a registry editor and locate the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\

    1. Right-click Parameters, point to New, and then click DWORD Value.

    2. Type UpdateProtocols, and then press ENTER.

  3. Right-click UpdateProtocols, click Modify, type 0 in the Value data field, and then click OK.

  4. If your network uses a Hosts file on the back-end cluster node, modify UpdateProtocols order of entry as follows:

    IPAddress to FQDN

    IPAddress to NetBIOS

    instead of:

    IPAddress to NetBIOS

    IPAddress to FQDN

  5. Restart all Exchange Server services on the server.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Network Interface performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Bytes Total/sec performance counter of the Network Interface performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions is true:

  • The Network Interface performance object is disabled.

  • The Network Interface performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the Network Interface performance object is enabled.

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at "Exctrlst.exe: Extensible Performance Counter List" (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall the Windows operating system in the Repair mode, and then apply the latest Windows Server service packs.


Newer MSGTRACK.dll available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-10-05

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from multiple performance counters of the Processor performance object to analyze performance data.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value that is set for the Version key of the Msgtrak.dll file.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • The server is experiencing high CPU usage.

  • The value of the Version key for the Msgtrak.dll file is earlier than 6.0.6373.0.

This warning indicates that the version of Msgtrack.dll found can potentially cause the high CPU usage. The warning also indicates that the version of Msgtrack.dll found may cause the Inetinfo.exe process to show very high memory use.

To address this issue, obtain the update referenced by Microsoft Knowledge Base article 811409, "XADM: Message Tracking May Cause the Inetinfo.exe Process to Show Very High Memory Use" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=811409).


Newer WLDAP32.DLL available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from multiple performance counters of the Processor performance object to analyze performance data.

The Exchange Server Analyzer also reads the following registry entry to determine the version of Microsoft Windows® running on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates that the Exchange Server computer is running Microsoft Windows NT® 4.0. A value of 5.0 indicates that the Exchange Server computer is running Windows 2000 Server and a value of 5.2 indicates the Exchange Server computer is running Windows Server™ 2003.

Finally, the Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows Management Instrumentation (WMI) class to determine the value that is set for the Version key of the Wldap32.dll file.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • The Exchange Server Analyzer has detected high CPU utilization on the server being analyzed.

  • The Exchange Server computer is running Windows 2000 Server.

  • The value for the version key of the Wldap32.dll file indicates a version that is earlier than version 5.0.2195.7044.

This warning indicates that the version of Wldap32.dll found can potentially cause the Inetinfo.exe process to consume 100% of the CPU on Windows 2000 Server systems.

To address this issue, obtain the update referenced by Microsoft Knowledge Base article 899019, "The Inetinfo.exe process may use 100 percent of the CPU resources on a Windows 2000 Server computer that is running Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=899019).


NNTP service enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Network News Transfer Protocol service (NntpSvc). A value of True indicates that the Network News Transfer Protocol (NNTP) service is running on this Exchange server.

The Exchange Server Analyzer also reads the following property in the Internet Information Services (IIS) metabase to determine if an NNTP feed is configured for the Exchange server:

/LM/NNTPSVC/1/Feeds

If the Exchange Server Analyzer finds that the NNTP service is started, but no feeds have been configured for the server, a warning is displayed.

To save resources, and as a general security precaution, you should not run any services for components that are not being used. Each service that is run exposes functionality that malicious users may be able to exploit. It is recommended that you disable all services that are not being used.

To disable the NNTP Service

  1. Click Start, click Programs, click Administrative Tools, and then click Services.

  2. Right-click the Network News Transfer Protocol (NNTP) service and click Properties.

  3. On the General tab, click Stop.

  4. Under Startup type, select Disabled, and then click OK.

For more information about securing Exchange Server 2003, see the Exchange Server 2003 Security Hardening Guide (http://go.microsoft.com/fwlink/?linkid=47578).


No DNS servers are available for tests
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-12-05

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows® Management Instrumentation (WMI) class to obtain the DNSServerSearchOrder attribute for remote servers that the server that is running Exchange Server tries to send messages to. This attribute is an array of server IP addresses that are used to query for Domain Name System (DNS) servers.

The Exchange Server Analyzer also queries the Microsoft Active Directory® directory service to determine the value for the msExchSMTPExternalDNSServers attribute in the protocolCfgSMTPServer class for the Exchange 2000 Server and Exchange Server 2003 server objects. The protocolCfgSMTPServer class contains the settings for a Simple Mail Transfer Protocol (SMTP) virtual server. If the msExchSMTPExternalDNSServers attribute is set, the SMTP virtual server uses an external DNS server.

Finally, the Exchange Server Analyzer uses the following Exchange Management Shell cmdlet to query for the values of the ExternalDNSServers and InternalDNSServers properties of any target Exchange 2007 Transport server roles. The ExternalDNSServers property specifies the list of external DNS servers that the server queries when it resolves a remote domain. The InternalDNSServers property specifies the list of DNS servers that should be used to resolve a local domain name for the target server.

Copy Code
get-TransportServer -Identity %ExchangeServerName% -DomainController %DomainControllerName%

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The Exchange Server Analyzer is unable to successfully retrieve the value of the DNSServerSearchOrder attribute. Alternatively, the attribute contains no data.

  • The msExchSMTPExternalDNSServers attribute for the Exchange 2000 Server and Exchange Server 2003 server objects is not set.

  • The values of the ExternalDNSServers and InternalDNSServers properties for the target Exchange 2007 Transport server roles contain no data.

This error indicates that the Exchange Server Analyzer cannot identify any DNS servers that are used by the target Exchange server. In addition, mail flow may be adversely affected by this condition.

Possible causes of this condition may include the following:

  • DNS is configured incorrectly on the target server.

  • WMI is failing or cannot be accessed.

To resolve this issue:

  • Review the DNS configuration on the target server.

  • Verify that the Exchange WMI can be accessed.

To verify that the Exchange WMI can be accessed

  1. Make sure that the Exchange server has been started and is connected to the network.

  2. Use the PING command to see whether the Exchange server is reachable.

  3. If there is a firewall, check to see whether remote procedure call (RPC) ports are blocked.

  4. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange server that it scans.

    Alternatively, you can grant specific WMI permission to the account under which the Exchange Server Analyzer runs:

    1. On the Exchange server, open the Computer Management Microsoft Management Console (MMC) tree.

    2. Under Services and Applications, right-click WMI Control, and then click Properties.

    3. On the WMI Controls Property page, click the Security tab, and then expand Root.

    4. Select the CIMV2 folder, and then click Security.

    5. On the Security for ROOT\CIMV2 page, add the account under which the Exchange Server Analyzer runs.

  5. Select the account that you added in step 4. In Permissions for Selected_Account, under the Allow column, select both Remote Enable and Read Security, and then click OK.

For more information about how to configure DNS to work with Exchange Server, see Microsoft Knowledge Base article 322856, "How to configure DNS to use with Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322856).

For more information about network connectivity problems, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about Exchange Server Analyzer connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).

For more information about port requirements, see Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


No Master Account SID
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-14

The Microsoft Exchange Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows Management Instrumentation (WMI) class to determine whether an Event 9548 warning has been logged for MSExchangeIS within the last hour.

If the Exchange Analyzer finds that an Event 9548 warning has been logged in the last hour, the Exchange Analyzer then counts the total number of Event 9548 warnings that have been logged for that hour.

Finally, if the Exchange Analyzer finds that an Event 9548 warning has been logged 20 or more times in the last hour, the Exchange Analyzer displays a warning.

This warning indicates that there may be disabled Active Directory directory service user accounts that are associated with Exchange Server mailboxes and do not have valid msExchMasterAccountSID attributes.

A mailbox that is on a server that is running Microsoft Exchange Server 2003 or Exchange 2000 Server must be linked to an Active Directory directory service user account to be available. This link is accomplished, in part, by setting the msExchMasterAccountSid Active Directory attribute on the mailbox. The Active Directory account to which the Exchange mailbox is linked can be in either an enabled or disabled state. Only disabled accounts should have a user who has the msExchMasterAccountSid attribute.

If the value for the msExchMasterAccountSid attribute on a disabled user account is blank or has become corrupted, and an access control list (ACL) is built that includes that user account, performance issues might occur when that ACL is used to access mailbox or public folder resources.

To address this warning:

  • Make sure that Exchange Server 2003 Service Pack 2 (SP2) is installed with the hotfix referenced by Microsoft Knowledge Base article 916783, "A hotfix is available to change the way that Exchange Server 2003 SP2 handles a disabled Active Directory user account that is associated with an Exchange Server 2003 mailbox" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=916783)

  • Examine the ACL and user account referenced by the Event 9548 warning to determine whether the msExchMasterAccountSid attribute value is blank or corrupted and, if it is needed, generate a valid msExchMasterAccountSID attribute value for the account following the guidance in Microsoft Knowledge Base article 328880, "How to troubleshoot public folder performance issues that are related to ACL conversions in Exchange 2000 and in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328880)

  • Remove the disabled user account from the ACL following the guidance in Microsoft Knowledge Base article 278966, "You cannot move or log on to an Exchange resource mailbox" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=278966)

For More Information

For more information about this issue, see the following Microsoft Knowledge Base articles and Exchange Server Resources:

  • Events and Errors Message Center: Event Details: MSExchangeIS Mailbox Store Event 9548 details (http://go.microsoft.com/fwlink/?LinkId=83135)

  • Microsoft Knowledge Base article 916783, "A hotfix is available to change the way that Exchange Server 2003 SP2 handles a disabled Active Directory user account that is associated with an Exchange Server 2003 mailbox" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=916783)

  • Microsoft Knowledge Base article 328880, "How to troubleshoot public folder performance issues that are related to ACL conversions in Exchange 2000 and in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328880)

  • Microsoft Knowledge Base article 278966, "You cannot move or log on to an Exchange resource mailbox" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=278966)


No SMTP instance found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-08-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service distingushedName attribute of the protocolCfgSMTPServer object class to determine whether a Simple Mail Transfer Protocol (SMTP) virtual server instance is running for the user-specified Exchange gateway server name.

If the Exchange Server Analyzer cannot find an SMTP virtual service instance for the user-specified Exchange gateway server, the Exchange Server Analyzer displays an error.

This error may be caused by temporary networking issues but may also indicate incorrect information in Active Directory.

To resolve this issue, review the SMTP virtual server configuration for the user-specified Exchange gateway server.

To view the SMTP virtual server instance configuration

  1. Start Exchange System Manager:

    Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.

  2. Navigate to the following container:

    \Administrative Groups\GroupName\Servers\ServerName\Protocols\SMTP\SMTP Virtual Server Instance\

  3. Right-click the SMTP virtual server instance you want and then select Properties.

  4. Verify the SMTP virtual server instance configuration is correct.

For more information about SMTP virtual server settings, see the following Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686).

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163).

For more information about SMTP Service Design, see "SMTP Service Design" in the Technical Reference Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=58876).

For more information about network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).


NSPI target server has been manually overridden
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether the Name Service Provider Interface target server (NSPI target server) service has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\NSPI Target Server

If the Exchange Server Analyzer finds NSPI Target Server to be present and configured, a non-default configuration message is displayed.

Different types of clients use domain controllers and global catalog servers differently to obtain access to the global address list (GAL). Exchange clients earlier than Microsoft Outlook® 2000 Service Release 2 (SR-2) expect to find a directory service on the Exchange server. Exchange 2000 Server and Exchange Server 2003 use a mechanism named Directory Service Proxy (DSProxy) to establish a connection to the nearest global catalog server on the client's behalf and proxy communications between Outlook and the global catalog server. Depending on your deployment requirements, you may explicitly specify a particular global catalog server that should be used to handle DSProxy requests. You can do this by hard coding the NSPI Target Server entry in the registry on the Exchange server.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To manually specify an NSPI Server

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Create a new REG_MULTISZ value called NSPI Target Server.

  4. Configure the NSPI Target Server value with the fully qualified domain name for the servers you want to specify.

To disable a static setting for the NSPI server, remove the fully qualified domain name entry for the server you want removed. If there is only one NSPI target server entered, delete the NSPI Target Server registry value.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about how Outlook 2000 SR-2 and newer clients interact with the Active Directory® directory service, see the following Knowledge Base articles:

  • 302914, "XCCC: How Outlook 2000 Accesses Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=302914)

  • 256976, "XCLN: How MAPI Clients Access Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256976)


A non-Exchange Server MAPI subsystem is installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the version of MAPI32.dll that is in the two following folders:

<drive>:\Program Files\Exchsrvr\Bin

%Systemroot%\System32

If the same version and copy of MAPI32.dll is not found in both folders, an error is displayed.

To ensure that a single version of the MAPI is in use, Exchange Server Setup copies MAPI32.dll to both the <drive>:\Program Files\Exchsrvr\Bin and %Systemroot%\system32 directories. If another MAPI application, such as Microsoft Office Outlook® 2003 or a third-party program is installed on the Exchange Server computer, it may copy a different version of MAPI32.dll into the System32 folder and potentially break Exchange functionality. These issues occur because versions of these two products produce a conflict of the MAPI subsystem that may not be cleanly reconciled without breaking either Exchange Server or the other MAPI application.

It is strongly recommended that you not install Outlook 2000 or a later version of Outlook, and Exchange Server 2003, Exchange 2000 Server or Exchange Server 5.5 on the same computer.

A common reason to want to install Outlook on the same computer with Exchange Server is to take advantage of certain Outlook components in server-side programs. For most program development requirements, Outlook is not required on an Exchange computer. Exchange Server includes Collaboration Data Objects (CDO), which can provide functionality that is similar to the Outlook object model. CDO is designed for server-side use and also avoids the implications that are included in later versions of Outlook. For more information, see the Microsoft Knowledge Base article 290500, "OL2002: Developer Information About E-Mail Security Features" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=290500).

Another common reason is the requirement to create MAPI profiles. Exchange Server includes all the functionality needed to create MAPI profiles and does not require Outlook for any reason. For more information about how to create MAPI profiles without installing Outlook, see the Knowledge Base article 306962, "HOWTO: Create MAPI Profiles Without Installing Outlook" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306962).

If you have to install Outlook and Exchange Server on the same computer for demonstration purposes, it is recommended that you use one of the following configurations, which have been tested for demonstration purposes:

  • Exchange 2000 Server used with Outlook 2000

  • Exchange 2000 Server used with Outlook 2002

To correct this error

  1. Uninstall Microsoft Outlook or the third-party MAPI application from the Exchange server.

  2. Rerun Exchange Server Setup, and click Reinstall.

For more information about using Microsoft Office Outlook 2003 and Microsoft Exchange Server on the same computer, see the Microsoft Knowledge Base article 266418, " XCCC: Microsoft Does Not Recommend Installing Exchange 2000 Server and Outlook 2000 or Later on the Same Computer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266418).

For more information about resolving MAPI conflicts, see the Knowledge Base article 229700, "HOWTO: Find the Correct Path to MAPISVC.INF Under Outlook 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=229700).

For more information about the MAPI32 stub library, see Messaging API (MAPI) (http://go.microsoft.com/fwlink/?linkid=34395).


Non-Microsoft ESE engine detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for Ese.dll, the Exchange Database Storage Engine, also known as the Extensible Storage Engine (ESE).

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects with an object class of msExchExchangeServer. If the string value includes "Version 5.5," the computer is running Microsoft Exchange Server 5.5. If the string value includes "Version 6.0," the computer is running Microsoft Exchange 2000 Server. If the string value includes "Version 6.5," the computer is running Microsoft Exchange Server 2003.

If the Exchange Server Analyzer finds the value for Version does not contain a substring of 6 as part of its version information, but the value for serialNumber indicates that Exchange 2000 Server or Exchange Server 2003 is installed, a warning is displayed. This warning indicates that a non-Microsoft version of Ese.dll is installed and being used on this Exchange Server computer. You should correct this problem as soon as possible.

One possible cause of this is the use of ESE-based antivirus software. Some ESE-based antivirus programs use an unsupported interface between the Exchange information store and the ESE. When you use this kind of software, you run the risk of database damage and data loss if there are errors in the implementation of the software.

During installation, the ESE-based scanner changes the Microsoft Exchange Information Store service so that it depends on the ESE-based antivirus program's service. This makes sure that the ESE-based antivirus program's service starts before the Microsoft Exchange Information Store service starts. When the ESE-based antivirus program starts, the version of Ese.dll included with Exchange Server is temporarily renamed as Xese.dll, and the ESE-based antivirus program's version of Ese.dll replaces the original file. After the ESE-based antivirus program's version of Ese.dll is loaded, the version included with Exchange Server is renamed back to Ese.dll, and the Microsoft Exchange Information Store service completes the startup process.

It is strongly recommended that you do not use non-Microsoft implementations of the ESE on Exchange Server computers. Customers who contact Microsoft Product Support Services may be asked to disable the ESE-based antivirus program to help identify issues, but customers are free to enable the software again after the root cause of the issue is correctly diagnosed.

The most widely used ESE-based antivirus program is Antigen for Microsoft Exchange from Sybari Software. Microsoft and Sybari agree that disabling Sybari Antigen is a valid troubleshooting step to determine the cause of issues. To contact Sybari Software, visit the Sybari Software Web site ( http://www.sybari.com).

Note:
The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.

It is also recommended that you use antivirus programs that support the Virus Scanning Application Programming Interface (VSAPI), also known as the Antivirus API (AVAPI).

To correct this warning

  1. Perform a full backup of the Exchange Server computer.

  2. Uninstall Exchange Server from the computer.

  3. Reinstall Exchange Server on the computer.

  4. Apply the latest service pack and updates for Exchange Server.

For more information about running antivirus software on Exchange Server, see the following Microsoft Knowledge Base articles:

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841)


Non-Microsoft Extensible Storage Engine detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for Ese.dll, the Exchange Database Storage Engine, also known as the Extensible Storage Engine (ESE).

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects with an object class of msExchExchangeServer. If the string value includes "Version 5.5," the computer is running Microsoft Exchange Server 5.5. If the string value includes "Version 6.0," the computer is running Microsoft Exchange 2000 Server. If the string value includes "Version 6.5," the computer is running Microsoft Exchange Server 2003.

If the Exchange Server Analyzer finds the value for Version does not contain a substring of 5.5 as part of its version information, but the value for serialNumber indicates that Exchange Server 5.5 is installed, a warning is displayed. This warning indicates that a non-Microsoft version of Ese.dll is installed and being used on this Exchange Server computer. You should correct this problem as soon as possible.

One possible cause of this is using ESE-based antivirus software. Some ESE-based antivirus programs use an unsupported interface between the Exchange information store and the ESE. When you use this kind of software, you run the risk of database damage and data loss if there are errors in the implementation of the software.

During installation, the ESE-based scanner changes the Microsoft Exchange Information Store service so that it depends on the ESE-based antivirus program's service. This makes sure that the ESE-based antivirus program's service starts before the Microsoft Exchange Information Store service starts. When the ESE-based antivirus program starts, the version of Ese.dll included with Exchange Server is temporarily renamed as Xese.dll, and the ESE-based antivirus program's version of Ese.dll replaces the original file. After the ESE-based antivirus program's version of Ese.dll is loaded, the version included with Exchange Server is renamed back to Ese.dll, and the Microsoft Exchange Information Store service finishes the startup process.

It is strongly recommended that you do not use non-Microsoft implementations of the ESE on Exchange Server computers. Customers who contact Microsoft Product Support Services may be asked to disable the ESE-based antivirus program to help identify issues, but customers are free to enable the software again after the root cause of the issue is correctly diagnosed.

To correct this warning

  1. Perform a full backup of the Exchange Server computer.

  2. Reinstall Exchange Server on the computer.

  3. Apply the latest service pack and updates for Exchange Server, which you can obtain from the Microsoft Exchange Server Web site (http://go.microsoft.com/fwlink/?LinkId=21573).
  • For more information about running antivirus software on Exchange Server, see the Microsoft Knowledge Base article 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

  • For more information about rebuilding an Exchange Server 5.5 computer using the same computer name, see the Knowledge Base article 155216, "XADM: How to Move Exchange Server to a New Computer That Has the Same Name" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=155216).


Nonpaged Pool is over the warning threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_PerfOS_Memory Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for the PoolNonpagedBytes key. The actions taken by the Exchange Server Analyzer depends on the underlying operating system, the presence or absence of the /3GB switch in the Windows Boot.ini file, and the discovered value for this key.

The following table displays the matrix of evaluations used by the Exchange Server Analyzer to determine whether this value is out-of-bounds for a specified Exchange server. If the conditions in the following table are matched, a warning is displayed.

Operating System | Boot.ini Setting | Current Non-Paged Pool is
Microsoft Windows 2000 Server or Advanced Server | /3GB | 100 MB or more
Microsoft Windows 2000 Server or Advanced Server | None | 200 MB or more
Microsoft Windows Server™ 2003 | /3GB | 100 MB or more
Microsoft Windows Server 2003 | None | 200 MB or more

The PoolNonpagedBytes key value is the size, in bytes, of the kernel memory non-paged pool. This is an area of physical system memory for objects that cannot be written to disk even when they are not being used. This value for this key is the last observed value. On a healthy Exchange server, unless a backup or restore is occurring, there should be no more than 85 MB of non-paged pool memory being used.

In Windows 2000 Server and Windows 2000 Advanced Server, the maximum value for non-paged pool memory is 256 MB. Because you cannot increase the limit for non-paged pool memory beyond the values listed above, this condition should be corrected as soon as possible. Regardless of the operating system in use or the presence or absence of the /3GB switch, only so much non-paged pool memory can be accessed by Windows. If Windows runs out of kernel memory, it can display error messages and crash. Kernel memory is essential to the correct operation of the system, and therefore you should monitor kernel memory carefully.

If after restarting the Exchange Server this condition recurs, the next step is to ensure that your system is tuned correctly and that all of the software and hardware on this system is up to date. This includes installing the latest:

  • Windows operating system service pack

  • Exchange Server service pack

  • Hardware firmware and drivers

  • System BIOS updates

  • Updates for any third-party applications that are installed and running

If software and hardware updates do not resolve this problem, you should disable all third-party software, restart the Exchange Server computer, and monitor kernel memory.

To correct this error

  1. Restart the Exchange Server computer at the earliest convenience.

  2. Monitor the Memory | Pool Nonpaged Bytes performance counter to ensure it is not climbing over the above listed threshold for your system.

For more information about tuning Exchange Server correctly, see the following Microsoft Knowledge Base articles and white papers:

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096)

  • "Troubleshooting Exchange Server 2003 Performance" (http://go.microsoft.com/fwlink/?LinkId=47588)

  • "Troubleshooting Exchange 2000 Server Performance" (http://go.microsoft.com/fwlink/?LinkId=18177)

  • "Exchange Server 2003 Performance and Scalability Guide" (http://go.microsoft.com/fwlink/?LinkId=47576)

For more information about the nonpaged pool memory and related topics, see the following Knowledge Base articles:

  • 294418, "Comparison of 32-Bit and 64-Bit Architecture" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=294418)

  • 177415, "How to Use Memory Pool Monitor (Poolmon.exe) to Troubleshoot Kernel Mode Memory Leaks" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=177415)

  • 268343, "Umdhtools.exe: How to Use Umdh.exe to Find Memory Leaks" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268343)


The number of free page table entries is low, which can cause system instability
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the setting for the SystemPages registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages

If the Exchange Server Analyzer finds the value for SystemPages is set to 0 and the number of free system page table entries (PTEs) is less than 3001, a warning is displayed.

Microsoft Windows Server™ 2003 and Windows® 2000 Server can directly address up to 4 gigabytes (GB) of memory address space, regardless of how much physical RAM is installed. From the process perspective, each element of virtual address conceptually refers to a byte of physical memory. It is the responsibility of the Virtual Memory Manager (VMM) in conjunction with processor memory management unit (MMU) to translate or map each virtual address into a corresponding physical address. The VMM performs the mapping by dividing the RAM into fixed-size page frames, creating system PTEs to store information about these page frames, and mapping them. System PTEs are small kernel-mode buffers of memory that are used to communicate with the disk I/O subsystem and the network. Each PTE represents a page frame and contains information necessary for the VMM to locate a page.

On an x86-based system that uses a 4 KB page size, the maximum number of PTEs required to map 2 GB of address space is 524,288 (2 GB/4 KB). On a similar system using the /3GB switch, the number of PTEs requires to map 3 GB of address space is 786,432 (3 GB/4 KB). On a typical system, this space is used as follows:

  • A maximum of 50,000 PTEs (approximately 195 MB address space) are reserved for general use.

  • The rest is used in mapping system cache, hyperspace, paged pool, non-paged pool, crash dump area, and so on.

This PTE pool size is automatically determined at system startup based on the amount of physical memory in the system. This pool is squeezed in between paged pool and non-paged pool, which also grows with the amount of physical memory in the system as well.

The system PTE pool can become heavily used and heavily fragmented. This can lead to situations where a driver may not load. Also, if the system PTE pool is depleted entirely, other parts of the system will degrade, even resulting in threads not being created, system stalls, and potential system crashes.

A healthy Exchange Server computer should have at least 5,000 system PTEs available at all times. If the number of free system PTEs drops below 5,000 but remains above 3,001, the warning described in Free Page Table entries is at the warning threshold will be displayed. When the number of free system PTEs drops below 3,001, this error is displayed. To resolve this problem, you can use the procedure below to configure the SystemPages registry value appropriately for your Exchange Server computer's operating system. When you are running Exchange Server 2003 Service Pack 1 (SP1) on Windows Server 2003 with 1 GB or more of RAM, it is recommended that you set the SystemPages registry key to 0. This recommendation contrasts with the recommendation for Windows 2000 Server, which is to set SystemPages to a value between 24,000 and 31,000.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

After performing the procedure described below, you should monitor the number of free system PTEs. You can do this by monitoring the Memory | Free System Page Table Entries performance counter with the Windows System Monitor (also known as Performance Monitor). If, after making the registry change described below, the number of free system PTEs remains low, you should check the following to ensure your Exchange Server computer is optimally configured:

  • Drivers A malfunctioning driver is one of the most common causes of low system PTEs. Check with your hardware manufacturer to ensure you are using the latest drivers for all of your hardware. There may be opportunities to downgrade to a more basic driver, as well. For example, computers that run server-based applications such as Exchange Server generally do not need the most advanced video drivers with all of the features. Instead, a more basic driver is often sufficient. Switching from an advanced video driver to a basic video driver should increase the number of free system PTEs.

  • System configuration If your system has 1 GB or more of physical memory installed, you should check to ensure that its Boot.ini file is properly configured with the /3GB and /USERVA=3030 switches as described in the following Microsoft Knowledge Base articles:

    • 823440, "You Must Use the /3GB Switch When You Install Exchange Server 2003 on a Windows Server 2003-Based System" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440)

    • 810371, "XADM: Using the /Userva Switch on Windows Server 2003-Based Exchange Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371)

  • Event Logs Check the application event log on the Exchange Server for errors and warnings, especially MSExchangeIS events 9582 (errors and warnings), 9665 (warning) and 12880 (error). The presence of event 9665 could also indicate that SystemPages is not configured for optimal performance. For more information about these events, see the 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).

To correct this warning on Windows 2000 Server

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. In the right pane, double-click SystemPages.

  4. In the Value data field, type a value between 24000 and 31000 (decimal), and then click OK.

  5. Close the registry editor and restart the computer for the change to take effect.

To correct this warning on Windows Server 2003

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. In the right pane, double-click SystemPages.

  4. In the Value data field, type 0, and then click OK.

  5. Close the registry editor and restart the computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about optimizing memory for Exchange Server, see the following Knowledge Base articles:

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 311901, "The effects of 4GT tuning on System Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


The number of Ongoing Calls currently waiting on virus-scanning is near the limit.
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, to determine the number of current, ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the Virus API (VAPI) component.

The Exchange Server Analyzer also queries the ScanningThreads key from the following registry entry to determine the maximum number of threads allowed for VAPI component calls:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

If the Exchange Server Analyzer finds that the number of ongoing calls from the Exchange Information Store service (Store.exe) to the VAPI component approaches the maximum number of threads allowed, the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Microsoft Exchange Information Store service to the VAPI component can be caused by conditions:

  • Updates to a virus scanner which generate a re-scan of items in the information store.

  • A misconfigured virus scanner

  • Virus scanner software processes a large message or attachment

To resolve this error, take the following steps:

  • Schedule updates to your virus engine for times when resource consumption is low, that is, off-peak demand intervals.

  • Consider reinstalling the virus scanning software, but reinstall at off-peak demand intervals.

  • Examine the configuration of your virus scanning engine for the correct thread configuration, file level exclusions, and so on. See Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • Increase the thread count for the virus scanning API:

    The optimal value for ScanningThreads is equal to (2 * NumberOfProcessors) + 1. For example, on a server running Exchange Server That has two processors, the optimal value for ScanningThreads is 5.

    Note:
    If hyper-threading is enabled, the value for NumberOfProcessors will be double the number of physical processors. It is recommended that you check with your antivirus software manufacturer to determine whether physical or logical processors should be used in this formula.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To increase the thread count

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

  3. In the right pane, double-click ScanningThreads.

  4. Enter the value returned from the previous formula.

  5. Close Registry Editor, and then restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about virus-scanning programs that are typically used with Microsoft Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

For more information about virus-scanning programs that are typically used with Microsoft Exchange 2000 Server, see the Knowledge Base article 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).

For more information about hyper-threading technology, see the Intel Web site (http://www.intel.com/technology/hyperthread).

Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.


OABGEN.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the above files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Obtaining the latest service pack/update rollup for Exchange Server 5.0
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute for each Exchange Server object. The versionNumber attribute represents the version of Exchange Server that is running on the computer.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the STORE.EXE process. If the Exchange Server Analyzer determines that the Version key for STORE.EXE has a value greater than or equal to 1460 and less 1462, a warning is displayed.

This warning indicates that the Exchange Server computer is not running the latest available code for the version of Exchange running on the computer.

To correct this warning

  1. Visit the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=41361) to download the latest update (April 2004) for Exchange Server 5.0.

  2. Review the information about this update by reading the Microsoft Knowledge Base article 834130, "Microsoft Exchange Server 5.0 Update Rollup" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834130).

  3. Take a complete backup of the Exchange Server computer.

  4. Apply the April 2004 update.

To obtain the latest update rollup for Exchange Server 5.0 Service Pack 2, see the Knowledge Base article 168858, "XGEN: How to Obtain Exchange Server 5.0 U.S. Service Pack 2" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=168858).

For more information about installing this and other Exchange Server updates, see the Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


Obtaining the latest service pack/update rollup for Exchange Server 5.5
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute for each Exchange Server object. The versionNumber attribute represents the version of Exchange Server that is running on the computer.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the STORE.EXE process. If the Exchange Server Analyzer determines that the Version key for STORE.EXE has a value greater than or equal to 2653, but less than 2658, a warning is displayed. This indicates that the computer is running Exchange Server 5.5 Service Pack 4 or Exchange Server 5.5 Service Pack 4 with hotfixes.

This warning indicates that the Exchange Server computer is not running the latest available code for the version of Exchange running on the computer.

To correct this warning

  1. Visit the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=33456) to download the latest update (May 2004) for Exchange Server 5.5.

  2. Review the information about this update by reading the Microsoft Knowledge Base article 841765, "May 2004 Update Rollup for Exchange Server 5.5" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=841765).

  3. Take a complete backup of the Exchange Server computer.

  4. Apply the May 2004 update.

For more information about installing this and other Exchange Server updates, see the Microsoft Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


Obtaining the latest service pack/update rollup for Exchange Server 2003
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute for each Exchange Server object. The versionNumber attribute represents the version of Exchange Server that is running on the computer.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the STORE.EXE process.

  • A value of 7638 for the Version key indicates Exchange Server 2003 Service Pack 2

  • A value of 7226 for the Version key indicates Exchange Server 2003 Service Pack 1

  • A value of 6944 for the Version key indicates the original release of Exchange Server 2003

  • A value in between the versions above indicates a that the server is running a hotfix update version of the Store.exe process.

If the Exchange Server Analyzer determines that the Version key for Store.exe has a value less than 7638, a warning is displayed.

This warning indicates that the Exchange Server computer is not running the latest available code for the version of Exchange Server running on the computer.

To correct this warning

  1. Download or order Service Pack 2 for Exchange Server 2003 from the "Service Pack 2 for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=54751).

  2. Review the Service Pack 2 release notes at the Exchange Server 2003 Service Pack 2 (SP2) Release Notes Web site (http://go.microsoft.com/fwlink/?LinkId=52072).

  3. Make a complete backup of the Exchange Server computer.

  4. Apply Service Pack 2 for Exchange Server 2003.

For more information about installing this and other Exchange Server updates, see the Microsoft Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


Obtaining the latest service pack/update rollup for Exchange 2000 Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute for each Exchange Server object. The versionNumber attribute represents the version of Exchange Server that is running on the computer.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the STORE.EXE process. If the Exchange Server Analyzer determines that the Version key for STORE.EXE has a value in one of the following ranges, a warning is displayed:

  • Greater than 6249 and less than or equal to 6396

  • Greater than 6396 and less than or equal to 6487

  • Greater than 6487 and less than or equal to 6556

  • Greater than 6556 and less than or equal to 6603

  • Greater than 6603 and less than 6700

This warning indicates that the Exchange Server computer is not running the latest available code for the version of Exchange running on the computer.

To correct this warning

  1. Download the latest update (August 2004) from the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).

  2. Review information about the latest update by reviewing the Microsoft Knowledge Base article 870540, "Availability of the August 2004 Exchange 2000 Server Post-Service Pack 3 Update Rollup" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=870540).

  3. Take a complete backup of the Exchange Server computer.

  4. Apply the August 2004 update.

For more information about installing this and other Exchange Server updates, see the Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


Offline address book server has been deleted
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-12-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the offLineABServer attribute of the offline address book configuration object. If the Exchange Server Analyzer finds that the value of the offLineABServer attribute contains the string DEL:, an error is displayed.

The offLineABServer attribute is a single-valued distinguished name attribute that stores the distinguished name of the Exchange Server computer that is responsible for generating an offline address book. For each offline address book, Exchange generates and stores the offline address book files in a set of public folders on a specified server. This error indicates that the server specified in the offLineABServer attribute of the offline address book configuration object does not exist. This situation can occur if the old offline address book server has been decommissioned or incorrectly removed from the topology. Exchange will not generate the offline address book until you specify a new server.

To correct this error in Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, under Recipients, click Offline Address Lists. In the right pane, right-click Default Offline Address List (or any other offline address list that produces this message), and then click Properties.

  2. On the General tab, under Offline address list server, click Browse, and then click the server you want to use.

To correct this warning for Exchange Server 2007

  1. Open the Exchange Management Console.

  2. Expand Microsoft Exchange, expand Organization Configuration, and then select Mailbox.

  3. In the results pane, click the Offline Address Book tab.

  4. On the Offline Address Book tab, select "Default Offline Address Book". In the action pane, Click Move to start the Move Offline Address Book wizard. This wizard allows you to move OAB generation to a different server. It will also copy the existing OAB files to the specified server.

To use the Exchange Management Shell to set the server that will host Offline Address Book generation

  • Run the following command:

    Copy Code
    Move-OfflineAddressBook -Identity <OAB> -Server <Server>

    Where: <OAB> is the distinguished name (DN), Domain\Account name, or GUID of the OAB and <Server> specifies the Exchange server on which to perform the selected operation.

    For example, to move OAB generation to the SERVER01., you would enter:
Copy Code
Move-OfflineAddressBook -Identity "My OAB" -Server "Server1"

For more information about working with offline address books in Exchange Server 2003, see "Configuring Exchange Server 2003 Offline Address Books" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).

For more information about working with offline address books in Exchange Server 2007, see "Organization Configuration > Mailbox > Offline Address Books" (http://go.microsoft.com/fwlink/?LinkId=79247).


Offline address book server is running on a front-end server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the offLineABServer attribute of the offline address book configuration object. The offLineABServer attribute is a single-valued distinguished name attribute that stores the distinguished name of the Exchange Server computer that is responsible for generating an offline address book.

The Exchange Server Analyzer also queries the Exchange_Server Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the IsFrontEndServer key for the Exchange server. If the value for the IsFrontEndServer key is True, the Exchange server is acting as a front-end server.

If the Exchange Server Analyzer determines that a designated offline address book server is also a front-end server, the Exchange Server Analyzer displays an error message.

This error indicates that the nominated Exchange server for generating offline address books is a front-end server. If the designated offline address book server is also a front-end server, offline address book generation will fail. A new server should be nominated for this task. When a server running Microsoft Exchange 2000 Server that uses Service Pack 2 or later is designated as a front-end server, the following services no longer run:

  • DSProxy

  • Offline Address List Generation

  • Recipient Update Service

  • Free and Busy Tasks

  • Mailbox Cleanup Agent

  • Exchange Event Service

  • Site Replication Service (SRS)

Front-end servers are designed to handle incoming client requests from Microsoft Office Outlook® Web Access, POP3, IMAP4, Exchange ActiveSync, Outlook Mobile Access, and Outlook clients that are configured to use RPC over HTTP. Front-end servers are also sometimes used to relay SMTP messages to internal Exchange servers.

To resolve this problem, it is recommended that you designate a back-end Exchange server as the offline address book server.

To correct this error

  1. Open Exchange System Manager

  2. Under Recipients, click Offline Address Lists.

  3. In the right pane, right-click Default Offline Address List and then click Properties.

    Note:
    Use the same procedure for any other offline address list that produces this message.

  4. On the General tab, under Offline address list server, click Browse, and then click the back-end Exchange server that you want to use.

For more information about how to work with offline address books, see "Configuring Exchange Server 2003 Offline Address Books" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Offline address book site public folder deleted
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-12-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the siteFolderServer attribute of each public folder store object. If the Exchange Server Analyzer finds that the value of the siteFolderServer attribute contains the string DEL:, an error is displayed.

The siteFolderServer attribute represents the public folder store used for the offline address book server. By default, Exchange Server generates offline address book files on the Site Folder Server (the first server that is installed in the administrative group). If you have designated a different server to act as the offline address book server, the public folder store listed in this attribute will be the store on the new offline address book server, and not the store on the administrative group's actual Site Folder Server.

When Exchange Server 2003 generates offline address book files, it attaches the files to mail messages and puts the messages in special public folders. Microsoft Office Outlook® 2003 retrieves the messages from the folder and downloads the attached files.

The offline address book messages are stored in subfolders of the Offline Address Book folder, which is one of the system folders in the default Public Folders tree. This folder contains a subfolder for each administrative group or site in your topology. By default, a content replica of a specific administrative group folder resides on the first server that is installed in the administrative group (named the Site Folder Server).

If your Exchange organization is Exchange Server 2007, with no down level (Outlook 2003 or earlier) clients, you can safely disregard this warning or Error. If your Exchange Server 2007 organization is hosting clients running Outlook 2003 or earlier, follow the procedure below to enable public folder distribution of the offline address book files. Public folder distribution is the distribution method by which clients running Outlook 2003 or earlier that are working offline or through a dial-up connection access the OAB.

To correct this error

  1. If you know that the server exists, in Exchange System Manager, under Servers, expand the server, expand the storage group, and then click Public Folder Store. Check the right pane to make sure that the Exchange store is running.

  2. To designate a new offline address book server, under Recipients, click Offline Address Lists. Then in the right pane, click Default Offline Address List (or any other offline address list that produces this message).

    If you do not want to use an offline address book, right-click Default Offline Address Book, and then click Delete. Otherwise, use the rest of this procedure to set a schedule.

  3. Right-click Default Offline Address List, and then click Properties.

  4. On the General tab, under Offline Address Book server, click Browse to select a server.

To correct this warning for Exchange Server 2007

  1. Open the Exchange Management Console.

  2. Expand Microsoft Exchange, expand Organization Configuration, and then select Mailbox.

  3. In the results pane, click the Offline Address Book tab.

  4. On the Offline Address Book tab, select "Default Offline Address Book".

    1. To enable public folder distribution of the offline address book, from the Distribution tab, select Enable public folder distribution.

    2. Click OK to save the changes

  5. To designate a new offline address book server, from the action pane, click Move to start the Move Offline Address Book wizard. This wizard allows you to move OAB generation to a different server. It will also copy the existing OAB files to the specified server..

To use the Exchange Management Shell to enable public folder distribution of the offline address book files.

  • Run the following command:

    Copy Code
    Set-OfflineAddressBook -Identity <OAB> -PublicFolderDistributionEnabled $true

    Where: <OAB> is the distinguished name (DN), Domain\Account name, or GUID of the OAB.

    For example, to enable public folder distribution of the default offline address book, you would enter:
Copy Code
Set-OfflineAddressBook -Identity "\Default Offline Address Book" -PublicFolderDistributionEnabled $true

To use the Exchange Management Shell to set the server that will host Offline Address Book generation

  • Run the following command:

    Copy Code
    Move-OfflineAddressBook -Identity <OAB> -Server <Server>

    Where: <OAB> is the distinguished name (DN), Domain\Account name, or GUID of the OAB and <Server> specifies the Exchange server on which to perform the selected operation.

    For example, to move OAB generation to the SERVER01., you would enter:
Copy Code
Move-OfflineAddressBook -Identity "My OAB" -Server "Server1"

For more information about working with offline address books in Exchange Server 2003, see "Configuring Exchange Server 2003 Offline Address Books" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).

For more information about working with offline address books in Exchange Server 2007, see "Organization Configuration > Mailbox > Offline Address Books" (http://go.microsoft.com/fwlink/?LinkId=79247).


Older CDO.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older DAVEX.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older DRVIIS.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • DrvIis.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of these files is less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates potential use of out-of-date files.

To correct this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. If you run setup in Re-install mode, you install only binary files. Re-install mode does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or updates that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into the CD drive.

  2. Click Start, click Run, and then type <drive>:\setup\i386\setup, where <drive> is the CD drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


Older DSACCESS.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EMSMTA.EXE file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EPOXY.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older ESE.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-06-20

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older ESEUTIL.EXE file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EXCDO.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EXCHMEM.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EXCHMEM.DLL present
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange Server binary files. These files include Exchmem.dll. If the Exchange Server Analyzer determines that the Exchmem.dll file in the \%systemroot%\system32 folder is older then the Exchmem.dll file in the \%exchangeroot%\bin folder, the Exchange Server Analyzer displays a warning.

Normally, two copies of Exchmem.dll will not exist on a server. However, sometimes a second Exchmem.dll file is added with an in-place upgrade from previous releases of the product. The presence of two versions of the file can cause setup to fail during the installation of service releases. To prevent problems, it is recommended that you rename the Exchmem.dll file in the \%systemroot%\system32 folder.

To correct this warning

  1. Stop all Exchange services.

  2. Rename the Exchmem.dll file in the \%systemroot%\system32 folder to Exchmem.dll.old.

  3. Restart all Exchange services.


Older EXMIME.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EXOLEDB.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EXPOP3.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EXPROX.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EXRES.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2000" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older EXSMTP.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older MAD.EXE file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older MAPI32.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older MAPI32.DLL file detected in system32 folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older MDBSZ.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older OABGEN.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older PHATCAT.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older PHATQ.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older REAPI.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older RESVC.DLL file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in both the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of the above files less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be in use.

To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Older STORE.EXE file detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds the Version value for any of these files is less than the Exchange Server Version value, a warning is displayed. An earlier version number indicates that out-of-date files may be used.

To correct this error, install the latest service pack or update rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. If you run setup in Re-install mode, you install only binary files. Re-install mode does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or updates that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into the CD drive.

  2. Click Start, and then click Run, and type <drive>:\setup\i386\setup, where <drive> is the CD drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).


Ongoing Calls to Active Directory found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-14

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for events that indicate ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the Active Directory® directory service.

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

Active Directory provides all mailbox information, address list services, and other recipient-related information. Most Exchange Server 2003 configuration information is also stored in Active Directory.

Exchange Server services access information that is stored in Active Directory and writes information to Active Directory.

If the Exchange Server Analyzer finds events in the Store.fcl logging file that reflect ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to Active Directory, the Exchange Server Analyzer displays a warning.

This warning indicates that performance may become an issue for this server. Occasional ongoing calls do not necessarily indicate a problem, but repeated ongoing calls to the same area might.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Microsoft Exchange Information Store service to the Active Directory can be caused by the following conditions:

  • Network latency between the Exchange server and the Domain Controller.

  • Static or otherwise incorrect configuration of DSAccess.

  • An overloaded domain controller and global catalog.

  • An incorrectly designed Active Directory topology.

To address this warning, take the following steps:

  • Run the Exchange Server Analyzer for an additional analysis of server issues. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Check the performance of the Active Directory Domain Controller servers.

  • Review the articles in the For More Information section of this document.

For More Information

For more information about Exchange performance and DSAccess, see Microsoft Knowledge Base article 250570, "Directory service server detection and DSAccess usage" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250570).

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).

For more information about Domain Controller performance, see the following Windows Server resources:

  • "Planning Domain Controller Capacity" (http://go.microsoft.com/fwlink/?LinkId=70191).

  • "Active Directory Monitoring of Domain Controllers" in the Windows 2000 Server Active Directory Planning and Deployment Guides (http://go.microsoft.com/fwlink/?LinkId=70193).


Ongoing Calls to ESE found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for events that indicate ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the Exchange Extensible Storage Engine (ESE).

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

The Microsoft Exchange Information Store sits on top of an Extensible Storage Engine (ESE) database. ESE is a sophisticated, transaction-based database engine. A transaction is a series of operations that are treated as an atomic (indivisible) unit. All operations in a transaction are either completed and permanently saved or else no operations are performed.

Exchange Server uses ESE as an embedded database engine that determines the structure of the databases and manages memory. The database engine caches the databases in memory by transferring chunks of data (pages) in and out of memory. It updates the pages in memory and writes new or updated pages back to the disk. When requests come to the system, the database engine can buffer data in memory. Therefore, it does not have to access the disk constantly.

Although caching data in memory is the fastest and most efficient way to process data, it means that when Exchange is running, the information on disk is never completely up-to-date. The latest version of the database is in memory. However, because many changes in memory are not yet on disk, the database and memory are not synchronized. The transaction log disk is always kept current with information about each transaction.

If the Exchange Server Analyzer finds that events in the Store.fcl logging file reflect ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to the Extensible Storage Engine (ESE) database, the Exchange Server Analyzer displays a warning.

This warning indicates that performance may become an issue for this server. Occasional ongoing calls do not necessarily indicate a problem, but repeated ongoing calls to the same area might.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Microsoft Exchange Information Store service to the Extensible Storage Engine (ESE) can be caused by the following conditions:

  • Exchange online defragmentation.

  • Data backups.

    Note:
    If a data backup or online defragmentation was in process during the Exchange Call Trace logging collection, you can safely ignore this warning as an indicator of an Exchange Server performance issue.
  • Bottlenecks on the database drives, for example, insufficient capacity for the number of users on the server.

  • Bottlenecks on the TEMP and TMP drives.

To resolve this error, take the following steps:

  • As a best practice, we recommend that you not overlap backup windows or online maintenance with peak-user demand intervals.

  • Make sure that the database disk drives are healthy and have sufficient throughput for the I/O load.

  • Run the Exchange Server Analyzer for an additional analysis of server issues such as message and attachment size limits. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about how to configure the online defragmentation time windows, see Microsoft Knowledge Base article 244524, "XADM: How to Configure the Exchange Server Online Defragmentation Time Window" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=244524).

For more information about Exchange Server Disk Bottleneck issues, see Disk Bottleneck Detected.

For more information about how to size and optimize disks for Exchange Server, see "How to Calculate Your Disk I/O Requirements" and "Best Practices Common to Multiple Architectures" in Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=49324).

For more information about ESE, see "Extensible Storage Engine Architecture" (http://go.microsoft.com/fwlink/?linkid=67009).


Ongoing Calls to IMail found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), Store.fcl file, for events that indicate ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the IMAIL component of the MAPI client.

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

The IMAIL component of Exchange Server is a flexible conversion service that is used by the Microsoft Exchange Information Store service between Internet and MAPI messages. This allows for the interoperability between clients which use RFC-822 or Internet format and clients that use the Exchange Server internal storage format, such as MAPI clients or internal store tasks.

Exchange uses the IMAIL mechanism to apply message formats to the content, as defined for Internet domains in Exchange System Manager or as specified by the user per recipient in Microsoft Office Outlook®. If no formatting parameters are passed to IMAIL, IMAIL formats MAPI messages in Summary TNEF (S/TNEF) format for transfer between servers.

If the Exchange Server Analyzer finds events in the Store.fcl logging file that reflect ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to the IMAIL component of the MAPI client, the Exchange Server Analyzer displays a warning.

This warning indicates that performance may become an issue for this server. Occasional ongoing calls do not necessarily indicate a problem, but repeated ongoing calls to the same area might.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Exchange Information Store service to the IMAIL component of the MAPI client can occur when one or more of the following conditions are true:

  • IMAIL tries to process much data in a message or attachment.

  • Many clients request data conversion

  • DSAccess requests encounter a slow response.

  • There are bottlenecks on the TEMP and TMP drives.

  • There are ongoing mailbox moves.

To address this warning, take the following steps:

  • Schedule any mailbox moves for off-peak demand intervals.

  • Run the Exchange Server Analyzer for an additional analysis of server issues such as message and attachment size limits. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about disk bottleneck issues with Exchange Server, see Disk Bottleneck Detected.

For more information about how to size and optimize disks for Exchange Server, see "How to Calculate Your Disk I/O Requirements" and "Best Practices Common to Multiple Architectures" in Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=49324).

For more information about best practices for message size limits on Exchange Server, see Maximum outgoing message size has not been set.

For more information about DSAccess and Exchange Server performance, see "How to Configure the DSAccess User Cache" in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).


Ongoing Calls to LSASS found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for events that indicate ongoing cross-component calls from the Exchange Information Store service (Store.exe) to the Local Security Authentication Server (Lsass.exe) process.

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

The Local Security Authentication Server process (Lsass.exe) is a security subsystem invoked by other processes to verify account information and logon validation.

Every Exchange client logon causes the server that is running Exchange Server to send a request to look up the account security identifier (SID) for the client and creates a call within the Local Security Authentication Server (Lsass.exe) process.

If the Exchange Server Analyzer finds events in the Store.fcl logging file that reflect ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to the Local Security Authentication Server (Lsass.exe) process, the Exchange Server Analyzer displays a warning.

This warning indicates that performance may become an issue for this server. Occasional ongoing calls do not necessarily indicate a problem, but repeated ongoing calls to the same area might.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Exchange Information Store service to the LSASS process can be caused by the following conditions:

  • Server resource issues related to the number of users who authenticate at the same time.

  • Network latency between the Exchange server and the Domain Controller or global catalog server.

  • Server resource bottleneck issues.

To address this warning, take the following steps:

  • Consider implementing the NeverPing parameter as described in 'NeverPing' Parameter Recommended

  • Review the articles in the For More Information section of this document.

For More Information

For more information about the Lsass.exe process and memory usage, see Microsoft Knowledge Base article 308356, "Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356).

For more information about Exchange client logons and LSASS issues, see Microsoft Knowledge Base article 161938, "Slow Exchange Client Logons Due to Resource Deadlock" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=161938).

For more information about network latency between the Exchange server and the Domain Controller or global catalog server, see the following Exchange Server Team Blog article, "Exchange Does Not Always Use Local GCs" (http://go.microsoft.com/fwlink/?LinkId=69166).

Note:
The content of each blog and its URL are subject to change without notice.

For more information about server resource bottleneck issues, see Processor Bottleneck.

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).


Ongoing calls to Virus Scanning found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), Store.fcl file for events that indicate ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the Virusscan Virus API (VAPI) component.

Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.

If the Exchange Server Analyzer finds events in the Store.fcl logging file that reflect ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to the VAPI component, the Exchange Server Analyzer displays a warning.

This warning indicates that performance may become an issue for this server. Occasional ongoing calls do not necessarily indicate a problem, but repeated ongoing calls to the same area might.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the Exchange Information Store service to the VAPI component can be caused by the following conditions:

  • Updates to a virus scanner that generate a re-scan of items in the information store.

  • A misconfigured virus scanner

  • Virus scanner software processes a large message or attachment.

To address this warning, take the following steps:

  • Schedule updates to your virus engine for times when resource consumption is low, that is, off-peak demand intervals.

  • Consider reinstalling the virus scanning software, but reinstall at off-peak demand intervals.

  • Examine the configuration of your virus scanning engine for the correct thread configuration, file level exclusions, and so on. See Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about virus-scanning programs that are typically used with Microsoft Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

For more information about virus-scanning programs that are typically used with Microsoft Exchange 2000 Server, see the Knowledge Base article 328841, "Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).


Operating System GlobalFlag has been set
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for the GlobalFlag entry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager

If the Exchange Server Analyzer finds the value for GlobalFlag to be present and configured with any value other than 0 or null, a warning is displayed.

  • The GlobalFlag registry value setting is a bitmask that determines what debugging options have been enabled for the operating system. Unless you are actively engaged in debugging or tracing a problem with the help of Microsoft Product Support Services, it is recommended that you set the GlobalFlag value to 0 at all times.

The GlobalFlag registry value is set to 0 by default. If this value has been altered from the default value of 0, you can use the Gflags tool included with the Microsoft Windows Server™ 2003 support tools, which can be found on the Windows Server 2003 CD-ROM in the \Support folder. Alternatively, you can manually set the value to 0 by using a registry editor. Both procedures are described below.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error using GFlags

  1. Click Start, click Run, and in the Open field type GFlags. The Global Flags user interface will appear.

  2. Clear all of the check boxes and click Apply.

  3. Click OK to exit the GFlags tool and restart the computer for the change to take effect.

To correct this error using a registry editor

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\ System\CurrentControlSet\Control\Session Manager

  3. Double-click the value called GlobalFlag and set its Value data to 0.

  4. Exit the registry editor and restart the computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).


The operating system is in debug mode
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the Debug property. If the value for this key on an Exchange Server computer is set to True, an error is displayed.

Windows debug mode is toggled by adding the /debug parameter in the Boot.ini file. When /debug is specified in the Boot.ini file of a Windows Server computer, the kernel debugger is loaded during startup and kept in memory at all times. This enables a support professional to dial in to the system being debugged and break in to the debugger, even when the system is not suspended at a Kernel STOP screen. Unlike the /crashdebug switch, the /debug switch uses the COM port whether you are debugging or not. This switch is used when debugging problems that are regularly reproducible. It is likely that the /debug parameter was set as a means to troubleshoot a problem, and was unintentionally left set.

Because of the additional processes that are being run, performance suffers greatly. Therefore, running Exchange Server on a computer where Windows is running in debug mode is not recommended.

To eliminate this error, edit the Boot.ini file and remove the /debug parameter.

To correct this error

  1. In Windows Explorer, navigate to the System Partition. This is the partition that holds the hardware specific files such as Boot.ini and NTLDR.

  2. If you cannot see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in the Windows Explorer window, click Tools, click Folder Options, and then click View. Clear the Hide protected operating system files (Recommended) check box. When prompted, click Yes.

  3. When the Boot.ini file is visible in Windows Explorer, right-click the file, click Open With, and then select Notepad to open the file.

  4. In the [Operating Systems] section, remove the /debug parameter.

  5. Save and close the file, and then restart the Exchange Server computer for the change to take effect.

For more information about the parameters that can be used in the Boot.ini file, see the Microsoft Knowledge Base article 833721, "Available switch options for the Windows XP and Windows Server 2003 Boot.ini files" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833721).


Outlook Web Access requires hotfix for Windows Server 2003 SP1
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-08-28

The Microsoft® Exchange Server Analyzer Tool queries various Microsoft Windows® Management Instrumentation (WMI) classes to collect the following information:

  • Which version of the Microsoft Windows Server operating system is Exchange Server installed on?

  • Is the Exchange server running on a cluster?

If the Exchange Server Analyzer determines that the following conditions are true, the Exchange Server Analyzer displays a warning:

  • Exchange Server 2003 Service Pack 1 (SP1) is installed.

  • Microsoft Windows Server™ 2003 SP1 is not installed.

  • Cluster service is running.

  • The Version value of Davex.dll is less than 6.5.7232.

If you are running this configuration, you must download and install an Exchange Server hotfix before you install Windows Server 2003 SP1. If you do not install the Exchange Server hotfix, Microsoft Office Outlook® Web Access for Exchange Server 2003 users will not be able to log on to their mailboxes. Users who have mailboxes that are hosted on the clusters will receive the following error message when they try to connect by using Outlook Web Access:

  • "500 - Internal Server Errors"

This error is caused by some of the security enhancements that are included with Windows Server 2003 SP1.

When a user tries to log on to a mailbox by using Outlook Web Access, HTTP submits requests to the clustering API by impersonating the logged-on user. However, there have been security changes in Windows Server 2003 SP1. The security restrictions for the APIs that perform remote registry access have been changed. Therefore, the logon attempt is not successful.

To fix this error, you must download and install the Exchange Server hotfix that is described in the Microsoft Knowledge Base article 841561, "'500 - Internal server error' error message when a user tries to access a clustered Exchange Server 2003 back-end server by using Outlook Web Access" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=841561).


Outlook Web Access template file mismatch
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the version number of the Wmtemplates.dll file. The Exchange Server Analyzer then compares the version number of Wmtemplates.dll on all servers in the administration group. If the Exchange Server Analyzer finds that the version number of Wmtemplates.dll does not match between front-end and back-end Exchange servers, the Exchange Server Analyzer displays a Best Practice message.

The Wmtemplates.dll file is used by Microsoft Office Outlook® Web Access controls. Mismatched versions of Wmtemplates.dll on the front-end and back-end Exchange servers may cause 400-level errors when users try to log on to Outlook Web Access by accessing the front-end Exchange server.

There have been two recent updates released by Microsoft that update Wmtemplates.dll:

  • "Microsoft Exchange Information Store service crashes periodically after you install Exchange Server 2003 SP1" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=872963)

  • "The S/MIME control does not load in OWA when you are running the Exchange Server 2003 OWA client on a Windows XP Service Pack 2-based computer" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=883543)

If you have recently installed either of these updates, the following conditions might be true:

  • The updates were not installed in the correct order.

  • The update was not installed on both the front-end and back-end servers.

When you install updates for Outlook Web Access, you should install the update on the front-end server, restart the server, and then install the update on the back-end server.

If you have not installed either of these updates, make sure that all servers are running the latest Exchange Server service packs and updates.

For information about the latest Exchange Server service packs and updates, visit the following Web sites:

  • Downloads for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=21236).

  • Downloads for Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkId=33457).


Outstanding RPC requests reached maximum threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the RPC Requests performance counter of the MSExchangeIS performance object to analyze performance data.

If the Exchange Server Analyzer determines that the number of RPC requests has reached the peak value of 100 during the sample time slice, the Exchange Server Analyzer displays an error.

The RPC Requests performance counter indicates the number of MAPI remote procedure call (RPC), or client, requests that are currently being processed by the Microsoft Exchange Information Store service. The average value of the RPC Requests performance counter should be under 30 at all times. By default, the maximum value for RPC requests is 100. Therefore, unless it is configured otherwise, the Microsoft Exchange Information Store service can service only 100 RPC requests at the same time before all new RPC operations will be rejected and users will not be able to connect to the server until the RPC requests drop below 100. The server will become unresponsive, mail flow may stop. The Outlook users may receive the RPC cancel Request dialog box.

This error indicates that the server is experiencing a performance bottleneck or that a process has stopped responding.

A performance bottleneck may be CPU, disk, network, or memory related and can be caused by an increase in load to the server or insufficient server resources. Use the Performance Monitor (Perfmon.msc) tool to determine whether the bottleneck is caused by an increase in load to the server or if the server is undersized. If the server load has increased, identify the source of the load and reduce it. If the server has insufficient resources, increase the necessary resources or move users off the server.

A process might stop responding because the store is waiting for a resource that never returns. Examples would be a cluster losing the drive that hosts message tracking or a virus scanner problem. When a process stops responding, RPC requests will never drop back down, and the store must be restarted.

For More Information

  • For more information about Processor Bottlenecks, see Processor Bottleneck

  • For more information about Disk Bottlenecks, see Disk Bottleneck Detected

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about how to plan for Exchange Server performance, see Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkID=56460).

  • For more information about how to move user mailboxes to reduce server load, see Move User Mailboxes to Another Server.


PHATCAT.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the above files are missing, an error is displayed. To fix this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest ExchangeServer 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


PHATQ.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the files are missing, an error is displayed. To resolve this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running the Setup program in Re-install mode only installs binary files. It does not remove or reset any user data or configuration data. If you renstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD in your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Page File Performance Issue
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Avg Disk sec/Read and Avg Disk sec/Write counters for the PAGEDISK instance of the LogicalDisk performance object to analyze performance data.

If the Exchange Server Analyzer determines that the Avg Disk sec/Read and Avg Disk sec/Write counters exceeded 10 milliseconds during the sample time slice, the Exchange Server Analyzer displays an error.

The LogicalDisk performance object consists of counters such as Avg Disk sec/Read and Avg Disk sec/Write that monitor logical partitions of hard disks. The Avg Disk sec/Read performance counter shows the average time, in seconds, of a read of data from the disk. The Avg Disk sec/Write performance counter shows the average time, in seconds, of a write of data to the disk The average value of the Avg Disk sec/Read and Avg Disk sec/Write performance counters should be under 10 milliseconds.

The PAGEDISK instance of the LogicalDisk performance object on a server represents the page file (Pagefile.sys). Pagefile.sys is a hidden system file on the hard disk that is used by Microsoft Windows® to store temporary data when your system is running low on RAM. The page file is also known as paging file or swap file.

This error indicates that there is a latency problem with the disk hosting the page file.

To resolve this error, take the following steps:

  • Identify the cause of the latency. If this issue is caused by excessive paging it may be caused by server memory issues.

  • Consider locating the page file on a dedicated partition or high speed disk.

  • Consider creating a secondary page file on an alternative drive as described in Microsoft Knowledge Base article 197379, "Configuring page files for optimization and recovery in Windows Server 2003, in Windows 2000, and in Windows NT" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379).

  • Run server maintenance tasks during non-peak times. If you run maintenance tools, such as Exchange Server Database Utilities (Eseutil.exe), or tasks, such as mailbox management, during peak times, you can use memory that would otherwise be used by Exchange. As a best practice, run these tools and tasks during non-peak times or during low usage periods.

For More Information

  • For more information about disk bottlenecks, see Disk Bottleneck Detected

  • For more information about optimizing page file performance, see Microsoft Knowledge Base article 197379, "Configuring page files for optimization and recovery in Windows Server 2003, in Windows 2000, and in Windows NT" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379).

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about best practices for designing storage architectures, see Best Practices Common to Multiple Architectures (http://go.microsoft.com/fwlink/?LinkId=72988).

  • For more information about disk sizing, latency, and I/O rates, see the following blogs on the Microsoft Exchange Team Blog Web site:

    • A few basic concepts in disk sizing (http://go.microsoft.com/fwlink/?linkid=39538)

    • Some more thoughts on disk IO and calculations... (http://go.microsoft.com/fwlink/?linkid=39539)

    • How to Calculate Your Disk I/O Requirements (http://go.microsoft.com/fwlink/?linkid=69747)


Page File Usage counter greater than 50%
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-09-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the % Usage counter of the Paging File performance object to analyze performance data.

If the Exchange Server Analyzer determines that the % Usage counter exceeded 50% during the sample time slice, the Exchange Server Analyzer displays an error.

The page file (Pagefile.sys) is a hidden system file on the hard disk that is used by Windows to store temporary data when your system is running low on RAM. The page file is also known as paging file or swap file. Page file use affects overall performance because disk operations take longer than memory operations. Also, when the paging to and from disk becomes high enough, a disk bottleneck eventually occurs and performance suffers. In this case, the real problem is memory, and the disk bottleneck is only a symptom.

Memory contention is tolerable until the system reaches a point where the system spends significant time managing the limited memory relative to the time that is required for the actual work. If you graph memory contention against average response times, you see a fairly smooth line from zero contention up to the point where response times increase significantly. This is referred to as the thrashing point. As memory contention increases past this point, response times increase exponentially. Temporary thrashing is tolerable in some environments, but you should work to avoid it.

This error indicates that there is a performance problem with the disk hosting the page file. This problem may ultimately be related to a memory issue on the server.

To resolve this error, take the following steps:

  • Consider creating a secondary page file on an alternative drive as described in Microsoft Knowledge Base article 197379, "Configuring page files for optimization and recovery in Windows Server 2003, in Windows 2000, and in Windows NT" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379).

  • Consider locating the page file on a dedicated partition or high speed disk.

  • Remove superfluous software. To make more memory resources available for Exchange, remove any third-party software tools that perform monitoring functions or any kind of non-essential service. The Performance snap-in (http://go.microsoft.com/fwlink/?LinkId=56118) can help you understand how much memory applications are using.

  • Run server maintenance tasks during non-peak times. If you run maintenance tools, such as Exchange Server Database Utilities (Eseutil.exe), or tasks, such as mailbox management, during peak times, you can use memory that would otherwise be used by Exchange. As a best practice, run these tools and tasks during non-peak times or during low usage periods.

  • Consider moving user mailboxes from the affected server to another server to reduce server load. For more information, see Move User Mailboxes to Another Server.

For More Information

  • For more information about disk bottlenecks, see Disk Bottleneck Detected.

  • For more information about optimizing page file performance, see Microsoft Knowledge Base article 197379, "Configuring page files for optimization and recovery in Windows Server 2003, in Windows 2000, and in Windows NT" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379).

  • For more information about improving memory performance, see Improve User Memory.

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about best practices for designing storage architectures, see Best Practices Common to Multiple Architectures (http://go.microsoft.com/fwlink/?LinkId=72988).

  • For more information about disk sizing, latency, and I/O rates, see the following blogs on the Microsoft Exchange Team Blog Web site:

    • A few basic concepts in disk sizing (http://go.microsoft.com/fwlink/?linkid=39538).

    • Some more thoughts on disk IO and calculations... (http://go.microsoft.com/fwlink/?linkid=39539).

    • How to Calculate Your Disk I/O Requirements (http://go.microsoft.com/fwlink/?linkid=69747).


PageHeapFlags has been set
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine the value for the PageHeapFlags entry:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\STORE.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MAD.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\INETINFO.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\EMSMTA.EXE

If the Exchange Server Analyzer finds the value for PageHeapFlags to be present and configured with any value other than 0 or null, a warning is displayed.

The PageHeapFlags option is used in tandem with the GlobalFlag registry value described in GlobalFlag has been set. The PageHeapFlags option lets you select standard heap verification, which writes fill patterns at the end of each heap allocation and examines the patterns when the allocations are freed, or full-page heap verification. This puts an inaccessible page at the end of each allocation so that the program stops immediately if it accesses memory beyond the allocation. Because full-page heap verification uses a full page of memory for each allocation, its widespread use can cause system memory shortages.

In this case, the Exchange Server Analyzer is specifically looking to see if any PageHeapFlags value has been enabled for a variety of Exchange components:

  • STORE.EXE - the information store process

  • MAD.EXE - the system attendant process

  • INETINFO.EXE - the IIS admin and parent process

  • EMSMTA.EXE - the message transfer agent process

Unless you are actively engaged in debugging or tracing a problem with the help of Microsoft Product Support Services, it is recommended that the PageHeapFlags value be set to 0 at all times, or deleted completely, which has the same effect.

The PageHeapFlags registry value is not present by default and must be manually added if debugging of the STORE.EXE process (or any other process) is required. You can use the Gflags tool included with the Microsoft Windows Server™ 2003 support tools, which is on the Windows Server 2003 CD in the \Support folder. Alternatively, you can manually set the value to 0, or delete completely the PageHeapFlags value by using a registry editor. Both procedures are described in this article.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error using GFlags

  1. Click Start | Run, and in the Open field execute GFlags. The Global Flags user interface will appear.

  2. In the Image File Name field, enter STORE.EXE.

  3. Click Image File Options.

  4. Clear all the check boxes, and then click Apply.

  5. Repeat steps 2 through 4 for each of the above listed Exchange processes.

  6. Click OK to exit the GFlags tool and restart the affected services for the change to take effect.

  7. When using the GFlags tool to clear this value, it does not delete or change the value for the PageHeapFlags. Instead, it sets the GlobalFlag value to 0, which overrides and disables the behavior configured with the PageHeapFlags entry.

To correct this error using a registry editor

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\STORE.EXE

  3. Delete the value named PageHeapFlags.

  4. Repeat steps 2 and 3 for each of the listed Exchange processes.

  5. Exit the registry editor and restart the affected services for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Nonpaged Pool is over the error threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_PerfOS_Memory Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for the PoolNonpagedBytes key. The actions taken by the Exchange Server Analyzer depend on the underlying operating system, the presence or absence of the /3GB switch in the Windows Boot.ini file, and the discovered value for this key.

The following is a matrix of evaluations used by the Exchange Server Analyzer to determine whether this value is out-of-bounds for a given Exchange server. If the conditions in the matrix are matched, an error is displayed.

Operating system | Boot.ini setting | Current nonpaged pool is
Windows 2000 Server or Advanced Server | /3GB | 110 MB or more
Windows 2000 Server or Advanced Server | None | 220 MB or more
Windows Server™ 2003 | /3GB | 110 MB or more
Windows Server 2003 | None | 220 MB or more

The PoolNonpagedBytes key value is the size, in bytes, of the kernel memory nonpaged pool. The nonpaged pool is an area of physical system memory for objects that cannot be written to disk but must remain in physical memory as long as they are allocated. This value for this key is the last observed value. On a healthy Exchange server, this value should remain level. If the value for this counter is steadily increasing, it could indicate a memory leak.

Because there is no way to increase the limit for nonpaged pool memory beyond the values listed above, this condition should be corrected as soon as possible. Regardless of the operating system in use or the presence or absence of the /3GB switch, only so much nonpaged pool memory can be accessed by the Windows operating system. If Windows runs out of kernel memory, it can display error messages and crash. Kernel memory is necessary for the correct operation of the system, and therefore you should monitor kernel memory carefully.

If after restarting the Exchange server, this condition is repeated, the next step is to ensure that your system is tuned correctly and that all the software and hardware on this system is up to date. This includes installing the latest:

  • Windows operating system service pack

  • Exchange Server service pack

  • Hardware firmware and drivers

  • System BIOS updates

  • Updates for any installed and running third-party applications

If software and hardware updates do not resolve this problem, disable all third-party software, restart the Exchange Server computer, and monitor kernel memory.

To correct this error

  1. Restart the Exchange Server computer at the earliest convenience.

  2. Monitor the Memory | Pool Nonpaged Bytes performance counter to ensure that it is not climbing over the above listed threshold for your system.

For more information about correctly tuning Exchange Server, see the following Microsoft Knowledge Base articles and topics:

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096)

  • "Troubleshooting Exchange Server 2003 Performance" (http://go.microsoft.com/fwlink/?LinkId=47588)

  • "Troubleshooting Exchange 2000 Server Performance" (http://go.microsoft.com/fwlink/?LinkId=18177)

  • "Exchange Server 2003 Performance and Scalability Guide" (http://go.microsoft.com/fwlink/?LinkId=47576)


Paged pool is over the warning threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_PerfOS_Memory Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for the PoolPagedBytes key. The actions taken by the Exchange Server Analyzer depends on the underlying operating system, the presence or absence of the /3GB switch in the Windows Boot.ini file, and the discovered value for this key.

The table displays the matrix of evaluations used by the Exchange Server Analyzer to determine whether this value is out-of-bounds for a given Exchange server. If the conditions in the table are matched, a warning is displayed.

Operating system | Boot.ini setting | Current paged pool is
Windows 2000 Server or Advanced Server | /3GB | 180 MB or more
Windows 2000 Server or Advanced Server | None | 180 MB or more
Windows Server™ 2003 | /3GB | 200 MB or more
Windows Server 2003 | None | 300 MB or more

The PoolPagedBytes key value is the size, in bytes, of the kernel memory paged pool. The paged pool is an area of physical system memory for objects that can be written to disk when they are not being used. This value for this key is the last observed value. On a healthy Exchange server, unless a backup or restore is taking place, there should be no more than 180 MB of paged pool memory being used.

In Windows 2000 Server and Windows 2000 Advanced Server, the maximum value for paged pool memory is 470 MB. When the /3GB switch is added to a computer running Windows 2000 Advanced Server, the maximum value for paged pool memory is 192 MB. On a computer running Windows Server 2003 without the /3GB switch, the maximum value for paged pool memory is 491 MB. On a computer running Windows Server 2003 with the /3GB switch, the maximum value for paged pool memory is 256 MB.

Because there is no way to increase the limit for paged pool memory beyond the values listed above, this condition should be corrected as soon as possible. Regardless of the operating system in use or the presence or absence of the /3GB switch, only so much paged pool memory can be accessed by Windows. If Windows runs out of kernel memory, it can display error messages and crash. Kernel memory is essential to the proper operation of the system, and therefore you should monitor kernel memory carefully.

If, after restarting the Exchange server, this condition recurs, the next step is to ensure that your system is tuned properly and that all of the software and hardware on this system is up to date. This includes installing the latest:

  • Windows operating system service pack

  • Exchange Server service pack

  • Hardware firmware and drivers

  • System BIOS updates

  • Updates for any third-party applications that are installed and running

If software and hardware updates do not resolve this problem, you should disable all third-party software, restart the Exchange Server computer and monitor kernel memory.

To correct this warning

  1. Restart the Exchange Server computer at the earliest convenience.

  2. Monitor the Memory | Paged Pool Bytes performance counter to ensure it is not climbing over the above listed threshold for your system.

For more information about tuning Exchange Server properly, see the following Microsoft Knowledge Base articles and Exchange topic:

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096)

  • "Troubleshooting Exchange Server 2003 Performance" (http://go.microsoft.com/fwlink/?LinkId=47588)

  • "Troubleshooting Exchange 2000 Server Performance" (http://go.microsoft.com/fwlink/?LinkId=18177)

  • "Exchange Server 2003 Performance and Scalability Guide" (http://go.microsoft.com/fwlink/?LinkId=47576)

For more information, see the following Exchange blog articles:

  • "Microsoft Windows Kernel Memory Management and Microsoft Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=63477)

  • "Configuring Hot-Add and Large Memory for Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=63478)

  • "Large Security Tokens and Kernel Memory Exhaustion" (http://go.microsoft.com/fwlink/?LinkId=63479)

    Note:
    The links to these blogs are provided for informational purposes. The content may change without notice.


Path for RPC proxy server extension is incorrect
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following property in the Internet Information Services (IIS) metabase to determine whether its value has been configured correctly:

LM/W3SVC/Filters/RpcProxy

This metabase property is the remote procedure call (RPC) proxy server extension property in the Web service extensions in IIS. The correct value for this property is the following:

<Windows Directory>\system32\rpcproxy\rpcproxy.dll

If the Exchange Server Analyzer finds that the property does not have the correct value, a warning is displayed.

The RPC proxy server extension property is set when you install the RPC over HTTP proxy subcomponent of the Networking Services Microsoft Windows® component. If the property is set incorrectly, or if you manually change the value, you should do the following:

  1. Remove the incorrect RPC proxy server extension property.

  2. Remove the RPC over HTTP proxy subcomponent.

  3. Reinstall the RPC over HTTP proxy subcomponent.

To remove the incorrect RPC proxy server extension property

  1. Open Internet Information Services (IIS) Manager.

  2. In the left pane of the Internet Information Services (IIS) Manager window, expand the server name, and then click Web Extensions.

  3. In the right pane of the IIS Manager window, right-click RPC Proxy Server Extension, and then click Properties.

  4. On the Required Files tab, select the incorrect file in the list of files, click Remove, and then click OK.

    Note:
    To see the complete path, adjust the width of the File Name column in the list of files.
To remove the RPC over HTTP proxy subcomponent

  1. Click Start, click Control Panel, and then click Add or Remove Programs.

  2. In the left pane, click Add/Remove Windows Components.

  3. Select Networking Services, and then click Details.

  4. Clear the check box for RPC over HTTP Proxy, click OK, and then click Next.

  5. When the Windows Components Wizard has completed, click Finish to close the wizard.
To reinstall the RPC over HTTP proxy subcomponent

  1. Click Start, click Control Panel, and then click Add or Remove Programs.

  2. In the left pane, click Add/Remove Windows Components.

  3. Select Networking Services, and then click Details.

  4. Select the check box for RPC over HTTP Proxy, click OK, and then click Next.

  5. When the Windows Components Wizard has completed, click Finish to close the wizard.

For more information about problems with the RPC proxy server extension not loading correctly, see the Troubleshooting section of the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=833401).

For more information about deploying RPC over HTTP on Exchange Server 2003, see Exchange Server 2003 RPC over HTTP Deployment Scenarios (http://go.microsoft.com/fwlink/?LinkId=24823).


PDC emulator is not excluded from DSAccess topology
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether the Active Directory® domain controller acting as the primary domain controller (PDC) emulator has been manually excluded from the list of domain controllers available for use by Exchange Server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default\MinUserDC

If the Exchange Server Analyzer finds that the domain controller acting as PDC emulator has not been manually excluded from the list of domain controllers available for use by Exchange Server, the Exchange Server Analyzer displays a best practice recommendation.

A PDC emulator is an Active Directory operations master role computer that processes replication requests from Microsoft Windows NT® Server 4.0 backup domain controllers and processes all password updates for clients that are not running Active Directory-enabled client software. PDC emulators are also domain controllers, and are therefore available for use by applications such as Exchange Server.

Directory Service Access (DSAccess) is an internal component in Exchange 2000 Server and Exchange Server 2003 that controls how all Exchange Server components access Active Directory. The primary function of DSAccess is to maintain information about various directory-related events and operations. For example, DSAccess discovers the Active Directory topology and detects if domain controllers and global catalog servers are available and responding to queries.

By default, DSAccess includes the PDC emulator computer in its list of available and usable domain controllers. If non-Exchange Server programs are making heavy use of the PDC emulator, use of the PDC emulator by DSAccess could cause performance problems on the PDC emulator computer and also on the Exchange server and the non-Exchange Server computer.

To prevent such performance issues, the MinUserDC registry value can be added to the registry on an Exchange server to force DSAccess to query all other available domain controllers before querying the domain controller that holds the PDC emulator operations master role.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To examine and change the MinUserDC registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

  3. Locate the MinUserDC value and make any required changes. If this DWORD value does not exist, you can manually create it.

    Note:
    The value data that is configured for the MinUserDC registry entry is the maximum number of domain controllers to contact before contacting the PDC emulator. For example, setting MinUserDC to 4 configures DSAccess to exclude the PDC emulator only when a total of 4 domain controllers are available.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about how to use the MinUserDC registry entry, see Knowledge Base article 298879, "Exchange 2000 may experience performance problems when PDC emulator is used for DSAccess" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298879).


Performance data for Available MBytes counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Available MBytes performance counter of the Memory performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Available MBytes performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Available MBytes performance counter shows the amount of physical memory in megabytes (MB) immediately available for allocation to a process or for system use. The amount of memory available is equal to the sum of memory assigned to the standby (cached), free, and zero page lists.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from Average Disk sec/Read counter of the LogicalDisk performance object
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Avg. Disk sec/Read performance counter of the LogicalDisk performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Avg. Disk sec/Read performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Logical Disk performance object is made up of counters such as Avg. Disk sec/Read that monitor logical partitions of hard disks. The Avg. Disk sec/Read performance counter shows the average time, in seconds, of a read of data from the disk. The average value of the Avg. Disk sec/Read performance counter should be under 10 milliseconds. The maximum value of the Avg. Disk sec/Read performance counter should not exceed 50 milliseconds.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about how to optimize your storage system for Exchange Server 2003, see Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=49324).

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from Average Disk sec/Read counter of the PhysicalDisk performance object
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Avg. Disk sec/Read performance counter of the PhysicalDisk performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Avg. Disk sec/Read performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Avg. Disk sec/Read performance counter indicates the average time, in seconds, of a read of data from the disk. The average value of the Avg. Disk sec/Read performance counter should be under 10 milliseconds. The maximum value of the Avg. Disk sec/Read performance counter should not exceed 50 milliseconds.

If you collect results from the Disk Reads/sec and Disk Writes/sec counters, you can determine whether the I/O generated by Exchange Server is increasing or decreasing over time. If you collect results from the Avg. Disk sec/Read and Avg. Disk sec/Write counters, you can determine whether storage latency has changed over time. For example, the following steps help you predict if storage throughput is or will become a bottleneck:

  1. Take measurements monthly, preferably on the same day each month and during the same hours on each day.

  2. Analyze the collected data.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from Average Disk sec/Write counter of the LogicalDisk performance object
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Avg. Disk sec/Write performance counter of the LogicalDisk performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Avg. Disk sec/Write performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Logical Disk performance object is made up of counters such as Avg. Disk sec/Write that monitor logical partitions of hard disks. The Avg. Disk sec/Write performance counter shows the average time in seconds that it takes to write data to the disk. The average value of the Avg. Disk sec/Write performance counter should be under 10 milliseconds. The maximum value of the Avg. Disk sec/Write performance counter should not exceed 50 milliseconds.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about how to optimize your storage system for Exchange Server 2003, see the Microsoft TechNet Web site Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=34649).

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data for Average Disk sec/Write counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Avg. Disk sec/Write performance counter of the Physical Disk performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Avg. Disk sec/Write performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Avg. Disk sec/Write performance counter shows the average time in seconds used to write data to the disk. The average value of the Avg. Disk sec/Write performance counter should be under 10 milliseconds. The maximum value of the Avg. Disk sec/Write performance counter should not exceed 50 milliseconds.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from Epoxy Client Out Queue Length (DSAccess) counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Client Out Queue Length (DSAccess) performance counter of the Epoxy performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Client Out Queue Length (DSAccess) performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Client Out Queue Length (DSAccess) performance counter indicates the number of messages in the queue that contains Directory Service Access (DSAccess) messages sent by the Inetinfo.exe process. The queues should be under 10 at all times.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from Epoxy Client Out Queue Length (SMTP) counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Client Out Queue Length (SMTP) performance counter of the Epoxy performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Client Out Queue Length (SMTP) performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Client Out Queue Length (SMTP) performance counter indicates the number of messages in the queue that contains Simple Mail Transfer Protocol (SMTP) messages sent by the Inetinfo.exe process. The queues should be under 50 at all times unless there is a mail queue.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from Epoxy Store Out Queue Length (DSAccess) counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Store Out Queue Length (DSAccess) performance counter of the Epoxy performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Store Out Queue Length (DSAccess) performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Store Out Queue Length (DSAccess) performance counter indicates the number of messages in the queue that contains Directory Service Access (DSAccess) messages sent by the Store.exe process. The queues should be under 10 at all times.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from Epoxy Store Out Queue Length (SMTP) counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Store Out Queue Length (SMTP) performance counter of the Epoxy performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Store Out Queue Length (SMTP) performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Store Out Queue Length (SMTP) performance counter indicates the number of messages in the queue that contains Simple Mail Transfer Protocol (SMTP) messages sent by the Store.exe process. The queues should be under 50 at all times unless there is a mail queue.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from RPC Averaged Latency counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the RPC Averaged Latency performance counter of the MSExchangeIS performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the RPC Averaged Latency performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The RPC Averaged Latency performance counter shows the remote procedure call (RPC) latency, in milliseconds, averaged for the past 1,024 packets. The maximum value of the RPC Averaged Latency performance counter should be less than 50 milliseconds at all times.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from RPC Operations/sec counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the RPC Operations/sec performance counter of the MSExchangeIS performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the RPC Operations/sec performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The RPC Operations/sec performance counter shows the rate at which remote procedure call (RPC) operations occur. The RPC Operations/sec performance counter is a good rate counter to measure Exchange Server workload because all MAPI-based actions use the RPC protocol.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from RPC Requests counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the RPC Requests performance counter of the MSExchangeIS performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the RPC Requests performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The RPC Requests performance counter indicates the number of MAPI remote procedure call (RPC), or client, requests that are currently being processed by the Microsoft Exchange Information Store service. The average value of the RPC Requests performance counter should be under 30 at all times. By default, the maximum value for RPC requests is 100. Therefore, unless it is configured otherwise, the Microsoft Exchange Information Store service can service only 100 RPC Requests at the same time before it rejects client requests.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from SMTP Categorizer Queue Length counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Categorizer Queue Length performance counter of the SMTP Server performance object to analyze performance data. The Exchange Server Analyzer reports the total number of messages found in the Categorizer queue.

The SMTP Server\Categorizer Queue Length counter indicates the number of messages in the Simple Mail Transfer Protocol (SMTP) Categorizer queue waiting for directory service attribute searches using global catalog servers. As a general guideline, the maximum value should be less than 10.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The Categorizer Queue Length counter indicates the number of messages in the message categorizer queue. The categorizer performs the following core operations:

  • It resolves and validates all recipients.

  • It determines limits and restrictions for all recipients.

  • It expands distribution lists if necessary.

  • It determines whether the message is for local or remote delivery

An increase in the Categorizer Queue Length counter indicates that there could be potential problems with server performance issues, Directory Service Access (DSAccess), the Active Directory® directory service, or outages with key servers in the Exchange Server organization. An increase in the Categorizer Queue Length counter would indicate slowness or no responsiveness in consulting Active Directory or in handing messages off for local delivery or SMTP.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from SMTP Local Queue Length counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Local Queue Length performance counter of the SMTP Server performance object to analyze performance data. The Exchange Server Analyzer reports the total number of messages found in the Simple Mail Transfer Protocol (SMTP) local queue.

The SMTP Server\Local Queue Length counter indicates the number of messages in the SMTP queue for local delivery. As a general guideline, the maximum value should be less than 1,000. The queue should remain steady near its average with a small amount of variance.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

A buildup of messages in the Local Delivery queue indicates a performance issue or outages on the server, because the server can no longer deliver the incoming mail in a timely manner. The following conditions can cause this delay:

  • The Active Directory® directory service is not being consulted promptly.

  • Messages are not being handed off promptly for local delivery or SMTP.

  • Databases have been dismounted.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from SMTP Remote Queue Length counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Remote Queue Length performance counter of the SMTP Server performance object to analyze performance data. The Exchange Server Analyzer reports the total number of messages found in the Simple Mail Transfer Protocol (SMTP) remote queue.

The SMTP Server\Remote Queue Length counter indicates the number of messages in the SMTP queue for remote delivery. As a general guideline, the maximum value should be less than 1,000. The queue should remain steady near its average with small variance.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

An increase in the remote queue length means that mail is not being sent to other servers. This failure to send mail can be explained by outages or performance issues with the network or remote servers. Those outages or performance issues prevent the network or remote servers from receiving the mail efficiently.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from Virus Scan Queue Length counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Virus Scan Queue Length performance counter of the MSExchangeIS performance object to analyze performance data. If the Exchange Server Analyzer collects any datafrom the Virus Scan Queue Length performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Virus Scan Queue Length performance counter indicates the current number of outstanding requests that are queued for virus scanning. The recommended value is of this counter is specific to your organization.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data for Log Record Stalls/sec counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Log Record Stalls/sec performance counter of the Database performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Log Record Stalls/sec performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Log Record Stalls/sec performance counter shows the number of log records that cannot be added to the log buffers per second because the log buffers are full. The average value of the Log Record Stalls/sec performance counter should be under 10 per second. The maximum value should not exceed 100 per second.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data for Log Threads Waiting counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Log Threads Waiting performance counter of the Database performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Log Threads Waiting performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Log Threads Waiting performance counter shows the number of threads waiting to complete an update of the database by writing their data to the log. If the value of the Log Threads Waiting performance counter is too high, the log may be a bottleneck for other transactions.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data for Pages/sec counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Pages/sec performance counter of the Memory performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Pages/sec performance counter, the Exchange Server Analyzer displays information about the collected data baseline information.

The Pages/sec performance counter shows the rate at which pages are read from or written to disk to resolve hard page faults. This counter is a primary indicator of the types of faults that cause system-wide delays. The count includes pages retrieved to satisfy page faults in the file system cache. These pages are ordinarily requested by applications. This counter should be under 1,000 at all times.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data for % Processor Time counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the % Processor Time performance counter of the Processor performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the % Processor Time performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The % Processor Time performance counter shows the percentage of time the processor is running non-idle threads. You can use this counter to monitor the overall utilization of the processors, or you can monitor the utilization per-processor. The average CPU utilization should be less than 90 percent at all times.

Note:
The % Processor Time displayed by the Exchange Server Analyzer is an aggregate value based on the total number of CPUs detected, both physical and logical, and divided by the sum of the CPU count.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data for Bytes Total/sec counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Bytes Total/sec performance counter of the Network Interface performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the Bytes Total/sec performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The Bytes Total/sec performance counter shows the rate at which the network adaptor is processing data bytes. This counter includes all application and file data, in addition to protocol information, such as packet headers. For a 100 megabits per second (Mbps) network adaptor, the value of the Bytes Total/sec performance counter should be under 7 megabytes/second. For a 1000 Mbps network adaptor, the value of the Bytes Total/sec performance counter should be under 70 megabytes/second.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from LDAP Read Time counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-06

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the LDAP Read Time performance counter of the MSExchangeDSAccess Process performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the LDAP Read Time performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The LDAP Read Time performance counter shows the time in milliseconds that a Lightweight Directory Access Protocol (LDAP) read request takes to be fulfilled. The average value should be under 50 milliseconds. Maximum values should not exceed 100 milliseconds.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Performance data from LDAP Search Time counter
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the LDAP Search Time performance counter of the MSExchangeDSAccess Processes performance object to analyze performance data. If the Exchange Server Analyzer collects any data from the LDAP Search Time performance counter, the Exchange Server Analyzer displays information about the collected data as baseline information.

The LDAP Search Time performance counter shows the time in milliseconds that a Lightweight Directory Access Protocol (LDAP) search request takes to be fulfilled. The average value should be under 50 milliseconds. Maximum values should not exceed 100 milliseconds.

By default, the Exchange Server Analyzer retrieves a sample every 30 seconds for a two-hour period. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. The Exchange Server Analyzer also reports the value that is at the ninetieth percentile of all collected values.

Note:
If you list in ascending order all the values that the Exchange Server Analyzer collected, the ninetieth percentile is the value at the ninetieth percent position in the list. The ninetieth percentile value indicates the high values of this counter during the collection interval.

In some instances, the maximum value will be the value at a peak point in the interval. Therefore the maximum value is not representative of the whole interval. The median value does not always accurately indicate load because the median value includes idle time during the collection interval. Therefore, the Exchange Server Analyzer reports the maximum value and the ninetieth percentile value.

The information in this baseline message is for information purposes only. There is no action required.

For more information about suggested thresholds of performance counters, see Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


PhysicalDisk performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Avg. Disk sec/Read performance counter of the PhysicalDisk performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions is true:

  • The PhysicalDisk performance object is disabled.

  • The PhysicalDisk performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry. The following procedure explains how to fix the first two conditions. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the PhysicalDisk performance object is enabled.

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at the Microsoft Web site, "Exctrlst.exe: Extensible Performance Counter List" (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall the Windows operating system in the Repair mode, and then apply the latest Windows service packs.


Port conflict: Site Replication Service
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether any port conflicts exist:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

If the Exchange Server Analyzer finds that the value for HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP matches any one of the values specified in the other six port registry values listed earlier in this article, an error is displayed. The Exchange Server Analyzer will also display an error for the port that conflicts with HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP.

To correct this error, you must change the value for this key or the conflicting key as specified by the Exchange Server Analyzer output to a unique value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the TCP/IP registry parameter

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters

  3. Double-click the TCP/IP key, and set the Value data field to a unique value that is just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

To deploy RPC over HTTP

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577 ).

  2. Review the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  3. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  4. Review the Microsoft Support WebCast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about statically mapping ports used by Exchange, see the following Knowledge Base articles:

  • 194952, "XADM: Statically Mapped Port Limitations for Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=194952)

  • 270836, "Exchange 2000 and Exchange 2003 static port mappings" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836).


Port conflict: Store HTTP
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether any port conflicts exist:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

The registry Rpc/HTTP Port key is used by Exchange to support the Microsoft Office Outlook® 2003 RPC/HTTP and Exchange Server 2007 Outlook Anywhere features. If the Exchange Server Analyzer finds that the value for HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters\Rpc/HTTP Port matches any one of the values specified in the other six port registry values listed earlier in this article, an error is displayed. The Exchange Server Analyzer will also display an error for the port that conflicts with HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters\Rpc/HTTP Port.

To correct this error, you must change the value for this key or the conflicting key as specified by the Exchange Server Analyzer output to a unique value.

If you are supporting RPC/HTTP Outlook 2003 or Outlook 2007 clients, you should set the Rpc/HTTP Port key to the decimal value of 6001. Additionally, you should review the RPC/HTTP configurations in your environment.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the Rpc/HTTP port registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters

  3. Double-click the Rpc/HTTP Port key, and set the Value data field to a unique value that is just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

To review RPC over HTTP configurations

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review "Deploying Outlook Anywhere" (http://go.microsoft.com/fwlink/?LinkId=80831).

  3. Review the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  4. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  5. Review the Microsoft Support WebCast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Port conflict: Store TCP
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-30

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether any port conflicts exist:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

If the Exchange Server Analyzer finds that the value for HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port matches any one of the values specified in the other six port registry values listed earlier in this article, an error is displayed. The Exchange Server Analyzer will also display an error for the port that conflicts with HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port.

The most common reason that this value is configured is to enable MAPI clients to connect to an Exchange server that is on the other side of a firewall. This scenario involves opening multiple ports on a firewall to enable Microsoft Office Outlook® 2003 or Outlook 2007 clients to connect using MAPI to an Exchange server, typically over the Internet.

The recommended deployment for using Outlook in MAPI Mode to connect to an Exchange server over the Internet is to use the RPC over HTTP features found in Microsoft Windows Server™ 2003, Exchange Server 2003, Outlook 2003, Exchange Server 2007, Outlook 2007, and Microsoft Windows® XP Professional. MAPI Mode was formerly referred to as "Corporate" or "Workgroup" mode.

To correct this error, you must change the value for this key or the conflicting key as specified by the Exchange Server Analyzer output to a unique value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the TCP/IP Port registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Double-click the TCP/IP Port key, and set the Value data field to a unique value that is just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

To deploy RPC over HTTP

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review "Deploying Outlook Anywhere" (http://go.microsoft.com/fwlink/?LinkId=80831).

  3. Review the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  4. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  5. Review the Microsoft Support WebCast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about statically mapping ports used by Exchange, see Microsoft Knowledge Base article 270836, "Exchange 2000 and Exchange 2003 static port mappings" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836)


Port conflict: System Attendant HTTP
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether any port conflicts exist:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

The HTTP Port key is used by Exchange to support the Microsoft Office Outlook® 2003 RPC/HTTP and Exchange Server 2007 Outlook Anywhere features. If the Exchange Server Analyzer finds that the value for HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port matches any one of the values specified in the other six port registry values listed earlier in this article, an error is displayed. The Exchange Server Analyzer will also display an error for the port that conflicts with HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port.

To correct this error, you must change the value for this key or the conflicting key as specified by the Exchange Server Analyzer output to a unique value.

If you are supporting RPC/HTTP Outlook 2003 or Outlook 2007 clients, you should set the HTTP Port key to the decimal value of 6002. Additionally, you should review the RPC/HTTP configurations in your environment.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the HTTP Port registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the HTTP Port key, and set the Value data field to a unique value that is just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

To review RPC over HTTP configurations

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review "Deploying Outlook Anywhere" (http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/7b2d1ce2-b6df-4604-80fd-2f6cafc47e82.mspx).

  3. Review the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  4. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  5. Review the Microsoft Support WebCast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Port conflict: System Attendant HTTP NSPI
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-30

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether any port conflicts exist:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

The registry Rpc/HTTP NSPI Port key is used by Exchange to support the Microsoft Office Outlook® 2003 RPC/HTTP and Exchange Server 2007 Outlook Anywhere features. If the Exchange Server Analyzer finds the value for HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port matches any one of the values specified in the other six port registry values listed earlier in this article, an error is displayed. The Exchange Server Analyzer will also display an error for the port that conflicts with HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\ Rpc/HTTP NSPI Port.

To correct this error, you must change the value for this key or the conflicting key as specified by the Exchange Server Analyzer output to a unique value.

If you are supporting RPC/HTTP Outlook 2003 clients or Outlook 2007 you should set the Rpc/HTTP NSPI Port key to the decimal value of 6004. Additionally, you should review the RPC/HTTP configurations in your environment.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the Rpc/HTTP NSPI Port registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the Rpc/HTTP NSPI Port key, and set the Value data field to a unique value that is just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

To review RPC over HTTP configurations

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review "Deploying Outlook Anywhere" (http://go.microsoft.com/fwlink/?LinkId=80831).

  3. Review the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  4. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  5. Review the Microsoft Support WebCast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Port conflict: System Attendant NSPI
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether any port conflicts exist:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

If the Exchange Server Analyzer finds that the value for HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port matches any one of the values specified in the other six port registry values listed earlier in this article, an error is displayed. The Exchange Server Analyzer will also display an error for the port that conflicts with HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port.

The most common reason that this value is configured is to enable MAPI clients to connect to an Exchange server that is on the other side of a firewall. This scenario involves opening multiple ports on a firewall to enable Microsoft Office Outlook® 2003 and Outlook 2007 clients to connect using MAPI to an Exchange server, typically over the Internet.

The recommended deployment for using Outlook in MAPI Mode to connect to an Exchange server over the Internet is to use the RPC over HTTP features found in Microsoft Windows Server™ 2003, Exchange Server 2003, Outlook 2003, Exchange Server 2007, Outlook 2007, and Microsoft Windows® XP Professional. MAPI Mode was formerly referred to as "Corporate" or "Workgroup" mode.

To correct this error, you must change the value for this key or the conflicting key as specified by the Exchange Server Analyzer output to a unique value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the TCP/IP NSPI Port registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the TCP/IP NSPI Port key, and set the Value data field to a unique value that is just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

To deploy RPC over HTTP

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review "Deploying Outlook Anywhere" (http://go.microsoft.com/fwlink/?LinkId=80831).

  3. Review the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  4. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  5. Review the Microsoft Support WebCast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about statically mapping ports used by Exchange, see the following Knowledge Base article:

  • 270836, "Exchange 2000 and Exchange 2003 static port mappings" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836).


Port conflict: System Attendant RFR
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-30

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether any port conflicts exist:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

If the Exchange Server Analyzer finds that the value for HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port matches any one of the values specified in the other six port registry values listed earlier in this article, an error is displayed. The Exchange Server Analyzer will also display an error for the port that conflicts with HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port.

The most common reason that this value is configured is to enable MAPI clients to connect to an Exchange server that is on the other side of a firewall. This scenario involves opening multiple ports on a firewall to enable Microsoft Office Outlook® 2003 or Outlook 2007 clients to connect using MAPI to an Exchange server, typically over the Internet.

The recommended deployment for using Outlook in MAPI Mode to connect to an Exchange server over the Internet is to use the RPC over HTTP features found in Microsoft Windows Server™ 2003, Exchange Server 2003, Outlook 2003, Exchange Server 2007, Outlook 2007, and Microsoft Windows® XP Professional. MAPI Mode was formerly referred to as "Corporate" or "Workgroup" mode.

To correct this error, you must change the value for this key or the conflicting key as specified by the Exchange Server Analyzer output to a unique value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the TCP/IP Port registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the TCP/IP Port key, and set the Value data field to a unique value that is just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

To deploy RPC over HTTP

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review "Deploying Outlook Anywhere" (http://go.microsoft.com/fwlink/?LinkId=80831).

  3. Review the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  4. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  5. Review the Microsoft Support WebCast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about statically mapping ports used by Exchange, see Microsoft Knowledge Base article 270836, "Exchange 2000 and Exchange 2003 static port mappings" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836)


Pre-release service pack update rollup detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the versionNumber attribute for each Exchange Server object. The versionNumber attribute represents the version of Exchange Server that is running on the computer.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the Exchange Collaboration Data Object (ExCDO) library file, ExCDO.dll. If the Exchange Server Analyzer determines that the Version key for ExCDO.dll has a value equal to 6603.0, a warning is displayed.

An Exchange 2000 Server computer that is running the 6603.0 version of ExCDO.dll indicates that the server is running the August 2004 Version 1 Exchange 2000 Server Post-Service Pack 3 (SP3) update rollup. Version 2 of this update rollup is now available. It is recommended that you install the August 2004 update rollup.

To correct this warning

  1. Learn about the latest update by reviewing the Microsoft Knowledge Base article 870540, "Availability of the August 2004 Exchange 2000 Server Post-Service Pack 3 Update Rollup" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=870540).

  2. Download the latest update (August 2004) from "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=33457).

  3. Back up the Exchange Server computer.

  4. Apply the August 2004 update rollup.

For more information about obtaining the latest service pack for Exchange 2000 Server, see the Microsoft Knowledge Base article 301378, "How to obtain the latest Exchange 2000 Server service pack" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378)

For more information about installing this and other Exchange Server updates, see the Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839)


Problem with Page File Location
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that your page file is in a location that can affect server performance negatively. The page file should not be located on the same disk as Exchange databases or the Exchange log files. It is also a good idea to isolate the page file from the system files.

It is recommended that your page file be located on a dedicated partition or high-speed disk.

To correct this warning

  • Move the page file to a location that does not contain Exchange database or log files and, if possible, to a location that does not contain the system partition.

For More Information

  • For more information about configuring the page file, see Microsoft Knowledge Base article 197379, "Configuring page files for optimization and recovery in Windows Server 2003, in Windows 2000, and in Windows NT" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=197379).

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Processor Bottleneck
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-24

The Microsoft® Exchange Server Analyzer Tool has identified that your server is experiencing a CPU bottleneck. Your server's CPU utilization has exceeded a recommended threshold. Counters that are used to identify processor bottlenecks or issues with processor utilization include:

  • Context Switches/sec performance counter under the System performance object.

  • % Processor Time (_Total) performance counter under the Processor performance object.

  • Processor Queue Length performance counter under the System performance object.

Detecting a Processor Bottleneck

If one of the following conditions is met, the Exchange Server Analyzer detects a bottleneck:

  • The average of the % Processor Time (_Total) performance counter under the Process performance object is greater than 70 percent.

  • The maximum of the % Processor Time (_Total) performance counter under the Process performance object is greater than 90 percent.

  • The average of Context Switches/second performance counter under the System performance object is greater than 20,000.

  • The Processor Queue Length performance counter under the System performance object is greater than two.

  • This % Processor Time (_Total) performance counter under the Process performance object provides overall utilization of the processors. The average CPU utilization should always be below 80 percent. Higher averages indicate a processor bottleneck. If the average processor utilization is higher than 70 percent, a warning is displayed. Frequent spikes in processor time above 90 percent also indicate a processor bottleneck.

  • The Processor Queue Length performance counter under the System performance object indicates the number of threads in the processor queue. There is a single queue for processor time, even on computers with multiple processors. A number higher than two indicates that threads are waiting for processor time and that there is a processor bottleneck.

Determining Sources of Processor Load

If a processor bottleneck is located, you must determine from where most of the CPU utilization is originating. On an Exchange back-end server, most of the CPU utilization should be originating from the Store.exe process. If more than 20 percent of the CPU utilization is coming from a process other than Store.exe, it is important that you find out what other processes are expending CPU utilization.

If the CPU utilization for the processes listed in the table below is higher than the threshold, the Exchange Server Analyzer displays an error.

Process | Threshold for %Processor Time performance counter under the Process performance object
Store | 90%
Inetinfo | 20%
Emsmts | 40%
Lsass | 40%
System | 40%
Mad | 40%
ExMGMT | 20%
W3WP | 40%

The Exchange Server Analyzer also measures the difference between the idle processor time that is measured by the %Processor Time performance counter (Idle instance) and the %Processor Time performance counter (_Total instance) under the Process performance object. On a healthy Exchange back-end server, at least 70 percent of the processor time that is in use should be in the Store.exe process.

The Exchange Server Analyzer displays an error under the following conditions:

  • If the amount of processor time that is not spent in the processes related to the Exchange server (Store.exe, inetinfo.exe, emsmta.exe, lsass.exe, w3wp.exe, exmgmt.exe or mad.exe processes) is higher than 35 percent.

  • If the non-Exchange-related processor time is greater than 20 percent.

  • If there is a processor bottleneck, and less than 70 percent of the processor time is in the Store.exe process.

In all of these cases, it is recommended that you find out what other processes are expending your server's CPU time.

Common Causes of Processor Bottlenecks on Back-End Servers

There are many possible causes for a performance bottleneck, including:

  • Other applications on the server expending CPU utilization

  • High RPC rates

  • Distribution list expansion

  • Backup and maintenance running during peak operating hours

  • Conversion of message content in messages caused by:

    • Multiple protocols running (for example, HTTP, POP3, IMAP4, Microsoft Office Outlook®)

    • Outlook 2000 or earlier versions that use offline folders (.ost files)

Removing Processor Bottlenecks

There are many ways to remove processor bottlenecks from your Exchange server.

To remove processor bottlenecks

  • If possible, add more or faster processors to the server. Also, enable hyper-threading if it is supported by the processors. You can enable hyper-threading by configuring the system BIOS. For more information, see your computer manufacturer's help documentation.

  • If increasing the processing power is not a viable option, you must reduce the load on the processors. To reduce the overall impact on the server, it is important to make sure that I/O-intensive, CPU-intensive, or memory-consuming tasks occur outside normal operation hours.

    First, identify which applications or tasks are causing load on the server. If a non-Exchange application is not important to that server, run that application on another server. If possible, move server roles to other computers as well. For example, if the Inetinfo process is consuming a lot of CPU utilization, consider adding front-end servers to assume responsibility of the protocol work that Inetinfo performs. You can also move public folder access to a dedicated public folder server. Finally, if a server performs a lot of distribution list expansions, you can reduce CPU utilization by moving distribution list expansion to a dedicated distribution-list expansion server.

  • Make sure that CPU-intensive tasks (such as backup and maintenance tasks) occur during off-peak hours. Also make sure and that these tasks are performed in a staged manner. Staging a task means setting different start times, and preferably end times, for each task. Staging the maintenance and backup of databases or storage groups also lessens the effect of these resource-intensive tasks.

  • If you have removed all optional sources of load, and the CPU utilization is still too high, you must move users to another server to reduce the load. For more information, see Move User Mailboxes to Another Server

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information on moving user mailboxes to reduce server load, see Move User Mailboxes to Another Server


Processor performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the % Processor Time performance counter of the Processor performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions is true:

  • The Processor performance object is disabled.

  • The Processor performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry. The following procedure explains how to fix the first two conditions. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the Processor performance object is enabled.

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at "Exctrlst.exe: Extensible Performance Counter List" (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select this check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall the Windows operating system in the Repair mode, and then apply the latest Windows service packs.


Public folder content replication is paused
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the heuristics attribute has been set on the Exchange Server organization. If the Exchange Server Analyzer finds that that bit 1024 is set in the heuristics, the Exchange Server Analyzer displays a warning.

Exchange Server 2003, SP2 introduced the ability for an administrator to stop all public folder content replication in the organization. You can stop all public folder replication by right-clicking the Organization name in Exchange System Management and clicking Stop Public Folder Content Replication. When Stop Public Folder Content Replication is clicked, bit 1024 is set in the heuristics attribute. You should only stop all public folder replication in extreme cases, such as troubleshooting an organization-wide public folder or mail flow issue.

You must resume public folder content replication if the following conditions are true:

  • You are not troubleshooting.

  • You do not otherwise need all public folder content replication stopped.

To resume public folder content replication at the organization level

  1. Open Exchange System Manager.

  2. Right-click Organization_Name, and then click Resume Public Folder Content Replication.

For more information about public folder replication, see Best Practices for Exchange Server Public Folders (http://go.microsoft.com/fwlink/?LinkId=46437).


Public folder store present on front-end server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-09-07

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether a public folder store is present on each Exchange server. If the Exchange Server Analyzer finds that the InformationStore object is of object class, msExchPublicMDB, the server is hosting a public folder store.

The Exchange Server Analyzer also queries the MicrosoftExchangeV2 Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the IsFrontEndServer key. A value of True indicates the Exchange server is configured as a front-end server and a value of False indicates the Exchange server is not configured as a front-end server. If the Exchange Server Analyzer finds that an Exchange server configured as a front-end server is hosting a public information store, a warning is displayed.

It is recommended that you not run public folder stores on front-end servers. Public folder stores are not required on front-end servers, because front-end servers do not host mailboxes. In addition, there are known issues with public folder replication, public folder referrals, and memory leaks when public folder stores are located on front-end servers running Exchange 2000 Server. Therefore, you should dismount all public folder stores on all front-end servers.

After you dismount the public folder stores, you can disable the Microsoft Exchange Information Store service because it no longer performs any functions on the front-end servers. By removing unnecessary services, you reduce loading and improve security and performance.

Note:
If the front-end server also receives Simple Mail Transfer Protocol (SMTP) messages from the Internet, the Microsoft Exchange Information Store service should remain running, and a mailbox store must remain mounted. However, you should never have a public folder store on a front-end server.

To stop and disable the mailbox and public folder databases

  1. In Exchange System Manager, expand Servers, expand your server, and then expand First Storage Group.

    Right-click Mailbox Store (ServerName), click Dismount Store, and then click Yes to dismount the store.

    Important:
    If you use the front-end server as an SMTP-bridgehead server, you must have a mailbox store mounted on the server. In this case, do not dismount and delete this store, but make sure you do not have any mailboxes stored on this server.

  2. Right-click Mailbox Store (ServerName), and then click Properties.

  3. Click the Database tab, select the Do not mount this store at startup check box, and then click OK.

    Right-click Public Folder Store (ServerName), and then click Dismount Store.

    Caution:
    Before you dismount the public folder store, make sure that the public folders have a replica on another public folder store. Otherwise, you may lose information.

  4. Click Yes to dismount the public folder store.

To disable the Microsoft Exchange Information Store service

  1. In the Services Microsoft Management Console (MMC) snap-in, right-click Microsoft Exchange Information Store in the Name list, and then click Properties.

  2. In the Startup type list, select Disabled, and then click Stop.

To permanently delete the mailbox and public folder databases

  • Follow the guidance in the Exchange Server Security Hardening Guide, How to Dismount and Delete the Mailbox and Public Folder Stores (http://go.microsoft.com/fwlink/?LinkId=25210)

For more information about issues related to running store services on front-end servers, see the following Microsoft Knowledge Base articles:

  • 286822, "XCCC: Front-End Servers Establish Large Number of Connections to Themselves" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=286822)

  • 320298, "Large number of connections established on front-end servers that are running Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320298)

For more information about front-end and back-end servers, see the Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Topology guide (http://go.microsoft.com/fwlink/?linkid=34216).


REAPI.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the above files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Recipient Update Service is missing or is not configured
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-07-11

The Microsoft Exchange Server Analyzer Tool queries the Active Directory directory service to determine the value of the msExchAddressListServiceLink attribute for each Recipient Update Service object in the directory. The msExchAddressListServiceLink attribute is a link from the address list service to the Exchange Server computer it should be running on. If the Exchange Analyzer finds that there is no msExchAddressListServiceLink attribute for a Recipient Update Service object, or the msExchAddressListServiceLink attribute value for the object is not populated, an error is displayed.

Each Recipient Update Service instance is usually associated with one Exchange Server computer that runs the Recipient Update Service. If you receive this message, the Recipient Update Service instance is not associated with any Exchange Server computer. This may cause Exchange address lists and recipients not to be updated.

For this instance of the Recipient Update Service to run, you must associate it with an existing Exchange server.

To correct this error

  1. Open Exchange System Manager.

  2. Under Recipients, click Recipient Update Services. In the right pane, right-click the appropriate instance of the Recipient Update Service, and then click Properties.

  3. On the General tab, under Exchange Server, click Browse and specify a server to run this instance.

  4. Click OK, and then click OK again for the change to take effect.

  5. Close Exchange System Manager.

For more information about Recipient Update Service, see the following topic and Microsoft Knowledge Base articles:

  • "Managing Recipients and Recipient Policies in Exchange Server 2003" in the Administration Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=47617)

  • 328738, "How the Recipient Update Service applies recipient policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 253828, "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 246127, "How to Check the Progress of the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 253770, "Tasks Performed by the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


Recommended updates for Windows 2000 Server SP 4 on a cluster
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of the Microsoft Windows® operating system that is running on the Exchange server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion

Note:
A CurrentVersion value of 4.0 indicates the computer is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the computer is running Microsoft Windows 2000 Server. A value of 5.2 indicates the computer is running Microsoft Windows Server™ 2003.

The Exchange Server Analyzer also queries the Win32_OperatingSystem Windows Management Instrumentation (WMI) class to determine the value of the ServicePackMajorVersion key.

Finally, the Exchange Server Analyzer queries the Win32_Service WMI class to determine whether the ClusSvc service is started.

The Exchange Server Analyzer displays a best practice configuration message if the following conditions exist:

  • The Exchange server is on a computer running Windows 2000 Server that has been upgraded with Service Pack 4.

  • The ClusSvc service is started.

It is recommended that you evaluate the updates and hotfixes that are available and determine whether they might resolve problems in your environment.

For more information and for the list of updates that are available for servers running Windows 2000 Server, see the Microsoft Knowledge Base article 895090, "Recommended hotfixes for Windows 2000 Service Pack 4-based server clusters" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895090).


Remote Queue length beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-04-09

The Microsoft Exchange Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Remote Queue Length performance counter of the SMTP Server performance object to analyze performance data.

If the Exchange Analyzer determines that the Remote Queue Length counter has exceeded the peak value of 1000 during the sample time slice, the Exchange Analyzer displays an error.

The SMTP Server\Remote Queue Length counter indicates the number of messages in the Simple Mail Transfer Protocol (SMTP) queue waiting for remote delivery. An increase in the Remote Queue Length means that mail is not being sent to other servers.

This failure to send mail can be explained by outages or performance issues with the network or remote servers. Those outages or performance issues prevent the network or remote servers from receiving the mail efficiently.

To resolve this error, use the resources in the following links to identify the problematic server or network component and address the performance issues.

For More Information

  • For more information about troubleshooting Exchange Server performance issues, see Identifying Rising Mail Queues in the "Identifying Symptoms of Poor Performance" section of Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about Exchange Server Performance, see Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkID=56460).


Remote Retry Queue length beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Remote Retry Queue Length performance counter of the SMTP Server performance object to analyze performance data.

The SMTP Server\Remote Retry Queue Length counter indicates the number of messages in the Simple Mail Transfer Protocol (SMTP) remote retry queue that cannot be sent to a destination server. If the Exchange Server Analyzer determines that the Remote Retry Queue Length counter has exceeded the peak value of 1000 during the sample time slice, the Exchange Server Analyzer displays an error.

This failure to send mail can be explained by outages or performance issues with the network or remote servers. Those outages or performance issues prevent the network or remote servers from receiving the mail efficiently.

To resolve this error, use the resources in the following links to identify the problematic server or network component and address the performance issues.

For More Information

  • For more information about troubleshooting Exchange Server performance issues, see Identifying Rising Mail Queues in the "Identifying Symptoms of Poor Performance" section of Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about Exchange Server Performance, see Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkID=56460).


Replica of Offline Address Book version 4 not found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_Public_Folder Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for HasLocalReplica. If the Exchange Server Analyzer finds that the value for HasLocalReplica is set to False for the offline address book version 4 instance of an offline address list, the Exchange Server Analyzer displays an error.

When HasLocalReplica is set to False for the offline address book version 4 instance of an offline address list, offline address lists are not correctly generated. As a result, users of Microsoft Office Outlook® 2003 cannot download any offline address lists.

This issue can occur if you have not configured any public folder stores to contain replicas for offline address book version 4. By default, the offline address book replicates its contents to the public folder store of the server on which it is installed. If the public folder store is removed from the offline address book's replication configuration, the issue that is described in the previous paragraph occurs.

To correct this error

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, and then click Folders.

  3. Right-click Public Folders, and click View System Folders.

  4. Click to expand the OFFLINE ADDRESS BOOK object.

  5. Under OFFLINE ADDRESS BOOK, right-click o=org/cn=addrlists/cn=oabs/cn=Default Offline Address List, and then click Properties.

  6. On the Replication tab, verify that a public folder store is entered in the Replicate content to these public stores box. If a public folder store is not entered, click Add, and then enter the appropriate public store for the offline address book.

  7. Click Apply, and then click OK.

  8. Click to expand o=org/cn=addrlists/cn=oabs/cn=Default Offline Address List.

  9. Under o=org/cn=addrlists/cn=oabs/cn=Default Offline Address List, right-click offline Address Book Version 4, and then click Properties.

  10. On the Replication tab, verify that a public folder store is entered in the Replicate content to these public stores box. If a public folder store is not entered, click Add and then enter the appropriate public store for the offline address book.

  11. Click Apply, and then click OK.

For more information about this issue, see the Microsoft Knowledge Base article 286328, "Offline Address Book Is Missing and Cannot Be Generated in Microsoft Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=286328).

For more information about how to correctly remove the first computer running Exchange Server 2003 from an administrative group, see the Knowledge Base article 822931, "How to remove the first Exchange Server 2003 computer from the administrative group" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822931).

For more information about offline Address Book issues, see the following Exchange Server Resources:

  • Offline Address Book - Things to Consider (http://go.microsoft.com/fwlink/?LinkId=57581)

  • How Outlook 2003 SP2 and Exchange Server 2003 SP2 OAB Version 4 Work Together (http://go.microsoft.com/fwlink/?linkid=53099)

  • OAB Version 4 in Exchange Server 2003 Service Pack 2 (http://go.microsoft.com/fwlink/?linkid=53097)


Replication Receive Queue queue length beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Replication Receive Queue Size performance counter of the MSExchangeIS Public performance object to analyze performance data.

If the Exchange Server Analyzer determines that the Replication Receive Queue Size counter has exceeded the peak value of 1000 during the sample time slice, the Exchange Server Analyzer displays an error.

Public folder replication messages are received by SMTP, categorized and handed to the local SMTP queue. The messages are then submitted to the Public Folder store. When they have been submitted to the Public Folder store the messages are put in the Replication Receive Queue. The messages in the Replication Receive Queue are then processed and the changes are performed on the appropriate public folder. The Replication Receive Queue Size performance counter indicates the number of public folder replication messages waiting to be processed.

The larger the replication queue becomes, the more out of synchronization the content in the folders becomes. When replication queues grow, there is an increased load on resources as the messages in the replication queue are processed. Also, growing replication queues indicate that public folder content on the server is outdated.

No action is required in the two instances where growth in the Replication Receive Queue is expected and can be planned for:

  • On a newly introduced public folder server, growth in the Replication Receive Queue can be caused by the expected initial backfill replication.

  • If site consolidation or other major changes in the Exchange topology are occurring, it is expected that there will be lots of replication as the content is moved.

For existing, steady state servers where public folder replicas are not being changed in bulk, this error may indicate:

  • Server resource performance bottlenecks such as disk, CPU, network, or memory. If there is a resource bottleneck on the server, the Store.exe process will not be able process the replication messages fast enough and a queue will grow.

  • The public folder replication interval is too small for the replication to complete before the next replication cycle starts.

To resolve this error, take the following steps:

  • Increase the replication interval time and monitor the MSExchangeIS Public\Replication Receive Queue Size until it shows that replication is completed before the next replication cycle starts.

  • Use the resources in the following links to determine whether a performance bottleneck is causing the queue growth and to address the bottleneck.

  • Consider reducing the total number of replicas in the Exchange organization to reduce the amount of replication traffic required.

For More Information

  • For more information about troubleshooting Exchange Server performance issues, see "Handling Special Exchange Roles and Performance" in Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about Exchange Server public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).

  • For more information about Exchange public folder best practices, see Exchange Public Folder Best Practices: Implementing Replication (http://go.microsoft.com/fwlink/?LinkId=46440).

  • For more information about improvements in public folder management introduced with Exchange Server 2003 Service Pack 2, see Microsoft Exchange Server 2003 Service Pack 2 Release Notes (http://go.microsoft.com/fwlink/?linkid=52072).


RESVC.DLL file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the above files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


RestrictRemoteClients registry key is enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether remote procedure call (RPC) Interface Restrictions is enabled:

HKEY_LOCAL_MACHINE\ Software\Policies\Microsoft\Windows NT\RPC

If the Exchange Server Analyzer finds that the RestrictRemoteClients registry key is configured, the Exchange Server Analyzer displays a non-default configuration message.

RPC Interface Restrictions provides increased network protection that will make systems less vulnerable to attacks over the network. The RestrictRemoteClients registry value modifies the behavior of all RPC interfaces on the system. By default, the RestrictRemoteClients registry value will prevent remote anonymous access to RPC interfaces on the system, with some exceptions.

When an interface is registered by using RpcServerRegisterIf, RPC allows the server application to restrict access to the interface, typically through a security callback. The RestrictRemoteClients registry value enables RPC to perform additional security checks for all interfaces, even if the interface does not have a registered security callback.

Note:
RPC clients that use the named pipe protocol sequence are exempt from all restrictions. The pipe protocol sequence cannot be restricted because of significant backward compatibility issues.
Note:
You can also configure the RestrictRemoteClients registry key by using the Group Policy Object Editor.

The RestrictRemoteClients registry key is configured by using DWORD values. If the registry value is not present, the absent value is the equivalent to the RPC_Restrict_Remote_Client_Default value.

The following table provides information about the RestrictRemoteClients configuration settings.

Registry Key Value (DWORD) Description

0 (Default)

The RPC_RESTRICT_REMOTE_CLIENT_NONE (0) represents the default value in Microsoft Windows Server™ 2003 Service Pack 1. The default value setting causes the system to bypass the RPC interface restriction.

The default value setting corresponds to the value of RPC_RESTRICT_REMOTE_CLIENT_NONE. The server application is responsible for imposing the appropriate RPC restrictions. This default setting is equivalent to the setting of RestrictRemoteClients in earlier versions of Windows.

1

A value of 1 on the RestrictRemoteClients registry key represents the default value in Microsoft Windows® XP Service Pack 2. The value setting of 1 restricts access to all RPC interfaces. All remote anonymous calls are rejected by the RPC runtime.

This value setting corresponds to the value of RPC_RESTRICT_REMOTE_CLIENT_DEFAULT. If an interface registers a security callback and provides the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag, this restriction does not apply to that interface.

2

A value of 2 on the RestrictRemoteClients registry key indicates that all remote anonymous calls are rejected by the RPC runtime without exceptions.

This value setting corresponds to the value of RPC_RESTRICT_REMOTE_CLIENT_HIGH. When the RestrictRemoteClients value is configured to 2, a system cannot receive remote anonymous calls by using RPC.

For more information about changes to RPC service with Windows XP Service Pack 2, see the MSDN® article, "RPC Interface Restrictions" (http://go.microsoft.com/fwlink/?LinkId=47371).


RFR target server has been manually over-ridden
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry on the Exchange server to determine if the Directory Services Proxy Referral (DSProxy referral) service has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\RFR Target Server

If the Exchange Server Analyzer finds RFR Target Server to be present and configured, a non-default configuration message is displayed.

The first time a Microsoft Outlook® 2000 Service Release 2 (SR-2) or later client connects to an Exchange 2000 Server or Exchange Server 2003 computer, it looks for the directory service on the home Exchange server. Outlook initially goes through the DSProxy process for the very first session. After the client contacts the DSProxy service, a DSProxy referral is passed back to the client informing it that all future directory requests should go to the global catalog server. Outlook sets the DSProxy referral information in the MAPI profile in the registry.

The DSProxy referral mechanism reduces load on the Exchange server and reduces the latency for address book searches. If an explicit server name is entered into the profile, Outlook must restart if that global catalog server fails. If this occurs, the Exchange server sends Outlook a new referral.

In some situations, it is preferable to hard code the RFR Target Server entry to specify the servers that should be used for MAPI client referral service. For example, one week prior to demoting a global catalog server to a member server, you should hard code the RFR Target Server entry to a defined group of global catalog servers. This ensures that the global catalog server being demoted is no longer referenced in the MAPI profiles on the Outlook clients. For more information about this specific use of the RFR Target Server registry entry, see the Microsoft Knowledge Base article 305065, "XADM: Exchange Server-Related Considerations for Demoting a Global Catalog Server to a Domain Controller" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=305065).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To use the RFR Target Server registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Create a new REG_MULTISZ value called RFR Target Server.

  4. Configure the RFR Target Server value with the fully qualified domain name for the server (or servers) you want to specify.

  5. Close the registry editor, and then restart the Microsoft Exchange System Attendant service for the change to take effect.

To disable a static setting for the RFR server, remove the fully qualified domain name entry for the server you want removed. If there is only one RFR target server entered, delete the RFR Target Server registry value.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about how Outlook 2000 SR-2 and newer clients interact with the Active Directory® directory service, see the following Microsoft Knowledge Base articles:

  • 302914, "XCCC: How Outlook 2000 Accesses Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=302914)

  • 256976, "XCLN: How MAPI Clients Access Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256976)


RegTrace is currently enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if advanced diagnostic tracing has been enabled on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\MosTrace\CurrentVersion\DebugAsyncTrace\EnabledTraces

If the Exchange Server Analyzer finds the EnabledTraces registry entry present and configured with any value other than 0, an error is displayed.

Advanced diagnostic tracing of Exchange Server transport and routing components can be accomplished using the Regtrace utility (Regtrace.exe). Regtrace is an especially useful tool for diagnosing and troubleshooting non-delivery reports (NDRs). The Regtrace utility can be found on the Exchange Server CD in the \Support\Utils\I386 folder.

The trace file is available at the location that is specified on the Output tab of the Regtrace utility. The default location for the file is C:\Trace.atf. The trace file is a binary-encoded file than contains debug-level information about the transport and routing components that are being traced. Because of this, Microsoft Product Support Services requires that customers send the trace files for internal analysis.

Unless you are actively troubleshooting a problem, Microsoft strongly cautions that having Regtrace enabled causes severe server performance degradation and should only be used for short periods of time under the strict guidance of Microsoft Product Support Services. In addition to performance, disk space for the trace file can be consumed at the rate of 10 or more megabytes (MB) per minute. To resolve this error, if you are not troubleshooting a problem, you can use Regtrace to disable tracing.

To disable advanced diagnostic tracing with Regtrace

  1. Copy Regtrace.exe from the Exchange Server CD to the Exchange Server computer.

  2. Execute Regtrace.exe on the Exchange Server computer. The Regtrace user interface will appear.

  3. On the Traces tab, clear all of the check boxes.

  4. Select the Output tab and select No Tracing.

  5. Click OK to save your changes and close the Regtrace utility.
  • For more information about the Regtrace tool, see the Microsoft Knowledge Base article 238614, "XCON: How to Set Up Regtrace for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=238614).

  • For more information about general messaging troubleshooting, see the Knowledge Base article 281800, "XCON: Troubleshooting Message Failures in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=281800).


Rejection threshold not configured
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-07-30

The Microsoft Exchange Analyzer Tool queries the Active Directory directory service for the value of the following attributes on all objects with a class of ContentFilterConfig:

msExchAgentsFlags The value of the msExchAgentsFlag attribute indicates the status of the Microsoft Exchange Server 2007 Content Filter agent and spam confidence level (SCL) reject action. When the Content Filter agent is enabled on a computer, the Content Filter agent filters all messages that come through all Receive connectors on that computer. The SCL Reject action, when enabled, sends a rejection response during the SMTP transaction for all messages that exceed the SCL reject threshold.

msExchMessageHygieneSCLRejectThreshold The value of the msExchMessageHygieneSCLRejectThreshold attribute indicates the level that is set for the SCL Reject action. This value represents the SCL rating that a particular message must exceed for the Content Filter agent to reject the message and send a non-delivery report (NDR) to the sender.

The Exchange Analyzer also executes the following Exchange Management Shell cmdlet to query for all Hub Transport server roles that have the anti-spam agents installed:

Get-TransportServer | where { $_.AntispamAgentsEnabled -eq $True}

If the Exchange Analyzer finds that all of the following conditions exist for a server, the Exchange Analyzer displays a warning:

  • Content Filtering is enabled

  • The SCL Reject action is enabled

  • The SCL Reject threshold is set to a value of 9

  • The server has the anti-spam agents enabled.

This warning indicates that although Content Filtering and the SCL Reject action are enabled, the SCL Reject action threshold is set to the default value of 9. This may cause rejection of messages that come from legitimate users. The recommended setting for the SCL Reject action threshold value is 7.

To address this warning, set the value of the SCL Reject action threshold to 7 using the Anti-spam tab in the Exchange Management Console or by using the Set-ContentFilterConfig cmdlet in the Exchange Management Shell.

To configure the SCL Reject action threshold, follow the guidance in the "How to Enable and Configure the Spam Confidence Level Thresholds" (http://go.microsoft.com/fwlink/?LinkId=96099) topic in the Exchange Server 2007 product documentation.

For More Information

For more information about managing the anti-spam and antivirus features of Exchange Server 2007, see "Managing Anti-Spam and Antivirus Features" (http://go.microsoft.com/fwlink/?LinkId=96103) in the Exchange Server 2007 product documentation.


Recipient Update Service deleted
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-20

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchAddressListServiceLink attribute for each Recipient Update Service object in the directory. The msExchAddressListServiceLink attribute is a link from the address list service to the Exchange Server computer it should be running on. If the Exchange Server Analyzer finds that the value for the msExchAddressListServiceLink attribute is set to DEL:, an error is displayed.

Each Recipient Update Service instance is associated with one Exchange Server computer that runs the Recipient Update Service. If you receive this message, the Recipient Update Service instance is associated with an Exchange Server computer that does not exist in the Exchange organization. The server may have been decommissioned or otherwise removed from the topology.

For this instance of the Recipient Update Service to run, you must associate it with an existing Exchange server.

To correct this error

  1. Open Exchange System Manager.

  2. Under Recipients, click Recipient Update Services. In the right pane, right-click the appropriate instance of the Recipient Update Service, and then click Properties.

  3. On the General tab, under Exchange Server, click Browse and specify a new server to run this instance.

  4. Click OK, and then click OK again for the change to take effect.

  5. Close Exchange System Manager.

For more information about Recipient Update Service, see the following Exchange topics and Microsoft Knowledge Base articles:

  • "Managing Recipients and Recipient Policies" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?linkid=47617)

  • 328738, "XADM: How the Recipient Update Service Applies Recipient Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 253828, "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 246127, "XADM: How to Check the Progress of the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 253770, "XADM: Tasks Performed by the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


RPC binding does not contain FQDN
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the ncacn_ip_tcp value for the networkAddress attribute contains a fully qualified domain name (FQDN). If the Exchange Server Analyzer finds that the ncacn_ip_tcp value does not contain a period (.), the Exchange Server Analyzer displays an error.

In Microsoft Office Outlook® Web Access for Exchange Server 2003, the front-end server examines the networkaddress attribute value when it tries to connect to an Exchange back-end server.

Note:
Outlook Web Access for Exchange 2000 Server does not do this. The front-end server requires a FQDN value.

The front-end server checks for a period in the value that is returned for networkaddress ncacn_ip_tcp. The connection request for the mailbox on the specific back-end server fails and the front-end server returns an "HTTP 500 Internal Server Error" error message to the user if the following conditions exist:

  • The ncacn_ip_tcp value is just a host name or a network basic input/output system (NetBIOS) name.

  • The ncacn_ip_tcp value is not an FQDN.

You must update the ncacn_ip_tcp value on the server object in Active Directory to make sure that Outlook Web Access for Exchange Server 2003 functions properly. The Exchange Server Analyzer output provides the name of the affected server.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
Note:
Before you update the ncacn_ip_tcp value, read the rest of this article. You may want to perform an additional procedure before you restart the Exchange Server services.
To update the ncacn_ip_tcp value on the networkAddress attribute

  1. Start the ADSI Edit tool from Windows 2000 Server support tools or from Windows Server 2003 support tools.

  2. Expand the following nodes:

    • Configuration Container

    • Configuration

    • Services

    • Microsoft Exchange

    • Organization_Name

    • Administrative Groups

    • Administrative_Group_Name

    • Servers

  3. Right-click Exchange_Server_Name, and then click Properties.

  4. Click networkaddress in the Attributes list, and then click Edit.

  5. Add a new value for ncacn_ip_tcp. Use the FQDN of the server instead of the NetBIOS name of the server or the host name of the server.

    The syntax for this value is ncacn_ip_tcp:FQDN. For example, if your Exchange back-end server has a host name of EXCHANGE1 and the FQDN is EXCHANGE1.contoso.com, use the following value for ncacn_ip_tcp: ncacn_ip_tcp:EXCHANGE1.contoso.com.

  6. Remove the original ncacn_ip_tcp value that contains the NetBIOS name or the host name of the back-end server by selecting the original value and clicking Remove. Click OK two times to apply the change.

  7. Restart all Exchange Server services on the server.

  8. If there are multiple domain controllers, wait for replication to occur before you try to log on from the front-end server. If the problem is not resolved after replication is complete, restart the IIS Admin Service on the front-end server.

If you maintain host files on back-end servers to correlate a server IP address that has a short host name, you must also update the UpdateProtocols registry value. If a host file is used, Exchange Server may change the ncacn_ip_tcp value back when Microsoft Exchange System Attendant is restarted. If the back-end server is clustered, Exchange Server may change the ncacn_ip_tcp value back after failover.

To minimize downtime that may be caused by restarting Exchange Server services, perform the following procedure before you restart the Exchange Server services by updating the ncacn_ip_tcp value on the networkaddress attribute as described in the preceding procedure.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To modify the UpdateProtocols registry value for back-end servers that use host files

  1. Using a registry editor, configure the following registry value on the back-end servers: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\UpdateProtocols

    Note:
    If the UpdateProtocols value is not present, you must create it. To do this, follow these steps:
    1. Open a registry editor and locate the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\

    2. Right-click Parameters, point to New, and then click DWORD Value.

    3. Type UpdateProtocols, and then press ENTER.

  2. Right-click UpdateProtocols, click Modify, type 0 in the Value data field, and then click OK.

  3. If your network uses a Hosts file on the back-end cluster node, modify UpdateProtocols order of entry as follows:

    IPAddress to FQDN

    IPAddress to NetBIOS

    instead of:

    IPAddress to NetBIOS

    IPAddress to FQDN

  4. Restart all Exchange Server services on the server.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


RPC binding does not match DNS resolved name
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool tries a Domain Name System (DNS) query against the configured DNS servers for each Exchange Server computer. This connection is made with a custom object processor that performs a name resolution request and analyzes the results. The Exchange Server Analyzer also queries the Active Directory® directory service to determine whether the server ncacn_ip_tcp value on the networkAddress attribute and the fully qualified domain name (FQDN) returned after DNS resolution are different. The networkAddress attribute is an attribute on each Exchange Server object in Active Directory. If the Exchange Server Analyzer finds that the server ncacn_ip_tcp value in Active Directory does not match the FQDN after DNS resolution, the Exchange Server Analyzer displays a warning.

This situation occurs if the FQDN of the server is changed after Exchange has been installed. Both Exchange Server and Active Directory require correctly configured and healthy DNS to operate correctly. Domain Naming Services registration and resolution issues can significantly affect the Exchange Server computer's ability to send, receive, and deliver messages. You can prevent problems if you make the two addresses match by manually editing the networkAddress attribute on the Exchange Server object in Active Directory.

You must update the ncacn_ip_tcp value on the server object in Active Directory to make sure that the ncacn_ip_tcp value matches the DNS FQDN of the server. The Exchange Server Analyzer output provides the name of the affected server.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.
To update the ncacn_ip_tcp value on the networkAddress attribute

  1. Start the ADSI Edit tool from Windows® 2000 Support Tools or from Windows Server 2003 Support Tools.

  2. Expand the following nodes:

    • Configuration Container

    • Configuration

    • Services

    • Microsoft Exchange

    • Organization_Name

    • Administrative Groups

    • Administrative_Group_Name

    • Servers

  3. Right-click Exchange_Server_Name, and then click Properties.

  4. Click networkaddress in the Attributes list, and then click Edit.

  5. Add a new value for ncacn_ip_tcp. Use the FQDN of the server instead of the current value.

    The syntax for this value is ncacn_ip_tcp:FQDN. For example, if your Exchange server has a host name of EXCHANGE1 and the FQDN is EXCHANGE1.contoso.com, use the following value for ncacn_ip_tcp: ncacn_ip_tcp:EXCHANGE1.contoso.com.

  6. Remove the original ncacn_ip_tcp value that contains the incorrect name of the server by selecting the original value and clicking Remove. Click OK two times to apply the change.

  7. Restart all Exchange Server services on the server.

For more information about how to use DNS with Active Directory, see Microsoft Knowledge Base article 323418, "How To Integrate DNS with an Existing DNS Infrastructure If Active Directory Is Enabled in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=323418).


The RPC binding order is not correct
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the remote procedure call (RPC) binding order in use by the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Exchange Provider\Rpc_Svr_Binding_Order

If the Exchange Server Analyzer finds the value for Rpc_Svr_Binding_Order does not start with ncacn_ip_tcp, an error is displayed.

The Rpc_Svr_Binding_Order registry entry is created when you install Exchange Server on a computer. This entry determines the protocol sequence that is used for server-to-server RPC communications.

By default, the Rpc_Svr_Binding_Order entry contains the following value data:

ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp

Note:
Additional values may be in the string if other protocols are also installed on the Exchange Server computer.

This entry specifies the order in which Exchange Server tries network communication protocols for RPC communications with other servers. For example, because TCP/IP is specified first, Exchange Server tries to communicate with other servers using RPC over TCP/IP first, before trying RPC over other protocols.

It is recommended that you not change the RPC binding order from the default value. If the default value is changed, you may encounter problems during server or service startup or with server-to-server communications.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Exchange\Exchange Provider

  3. In the right pane, double-click Rpc_Svr_Binding_Order.

  4. In the Value data dialog box, type ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp.

  5. Click OK, and then close the registry editor.

  6. Restart all Exchange Server services, or restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the RPC binding order, see the Knowledge Base article 325930, "How to troubleshoot connectivity issues that are caused by RPC client protocol registry entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325930).


The Rpc_Binding_Order registry entry is present
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to check for the presence of a client-oriented remote procedure call (RPC) binding order registry entry on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Exchange Provider\Rpc_Binding_Order

If the Exchange Server Analyzer finds the Rpc_Binding_Order present, a warning is displayed.

If the Rpc_Binding_Order value is present, it indicates that one or more of the following is installed on the computer:

  • Exchange Server version 5.5

  • Microsoft Office Outlook® 2003

  • Windows Clustering

  • The RPC_Binding_Order entry determines the protocol sequence that is used when Outlook RPC communications are initiated. This entry is not created in Exchange Server 2003 or in Exchange 2000 Server. This entry is only created in Exchange Server 5.5 and in earlier versions of Exchange. If Exchange Server 5.5 or Microsoft Outlook were previously installed on this computer and have since been removed, you can manually remove this registry entry. In addition, you should remove Outlook from any computer running Exchange Server, as that is an unsupported configuration. For more information about running Exchange and Outlook on the same computer, see the Microsoft Knowledge Base article 266418, "Microsoft does not recommend installing Exchange Server and Outlook on the same computer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266418).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To remove the Rpc_Binding_Order registry entry

  1. Open a registry editor such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Exchange\Exchange Provider

  3. Delete the Rpc_Binding_Order value.

  4. Close the registry editor, and restart all Exchange Server services or reboot the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the RPC_Binding_Order registry entry, see the following Knowledge Base articles:

  • 325930, "How to troubleshoot connectivity issues that are caused by RPC client protocol registry entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325930)

  • 326036, "XADM: Cannot Log On to Exchange 2000 Server Computer by Using the Correct Credentials" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=326036)


The Rpc_Svr_Binding_Order registry value has been modified from its default value
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the remote procedure call (RPC) binding order in use by the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Exchange Provider\Rpc_Svr_Binding_Order

If the Exchange Server Analyzer finds the value for Rpc_Svr_Binding_Order is not set to ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp, a warning is displayed.

The Rpc_Svr_Binding_Order registry entry is created when you install Exchange Server on a computer. This entry determines the protocol sequence that is used for server-to-server RPC communications.

By default, the Rpc_Svr_Binding_Order entry contains the following value data:

ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp

Note:
Additional values may be in the above string if other protocols are also installed on the Exchange Server computer.

This entry specifies the order in which Exchange Server tries network communication protocols for RPC communications with other servers. For example, because TCP/IP is specified first, Exchange Server tries to communicate with other servers using RPC over TCP/IP first, before trying RPC over other protocols.

Microsoft recommends that you not change the RPC binding order from the default value. If the default value is changed, you may encounter problems during server or service startup or with server-to-server communications.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Exchange\Exchange Provider

  3. In the right pane, double-click Rpc_Svr_Binding_Order.

  4. In the Value data dialog box, type ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp.

  5. Click OK, and then close the registry editor.

  6. Restart all Exchange Server services, or reboot the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the RPC binding order, see the Knowledge Base article 325930, "How to troubleshoot connectivity issues that are caused by RPC client protocol registry entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325930).


Round-trip times to Active Directory server are taking more than 100 ms
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool queries the WIN32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class in the root\cimv2 namespace to determine the value for the ResponseTime key. If the Exchange Server Analyzer finds the value for the ResponseTime key to be greater than 100 milliseconds (ms), an error is displayed.

The ResponseTime key represents the time elapsed (in milliseconds) to response to the Internet Control Message Protocol (ICMP) echo request (ping). Domain controllers used by an Exchange Server computer should always have a response time less than or equal to 10 ms. If the response time exceeds 100 ms, that could indicate performance or connectivity issues.

To correct this error

  1. Check to ensure that the domain controller in question is not overloaded. Use the ADTest.exe tool to perform tests against the domain controller to see if the hardware can handle the anticipated load.

  2. Check the event logs on the Exchange server and the domain controller to see if any network-related events have been logged that indicate one or more problems.

  3. Use the DCDiag.exe and NetDiag.exe commands on the domain controller to verify correct configuration and health.

  4. Finally, investigate the Active Directory® directory service site design. An Active Directory site is considered to be a network section that has high bandwidth and low latency. If the network is not partitioned according to this specification, consider partitioning the network into more Active Directory sites.
Note:
When the Analyzer tool runs the WMI query for the ping test, the default packet size and timeout values are overridden. Instead, the Analyzer uses a 4096 ICMP packet size (in place of the default 32 byte) and a 2000 ms timeout value (in place of the default 1000 ms).

Follow these steps to emulate the Analyzer's ping behavior manually.

To perform the ping test manually

  • Run the following command in the command line window of the Exchange server:ping -L 4096 -N 6 <Active Server server name>Note The command initiates six ping requests of 4096 bytes each.

For more information about the ADTest.exe tool, see the Active Directory Performance Testing Tool (ADTest.exe) Web site (http://go.microsoft.com/fwlink/?LinkId=33758).

For more information about the Win32_PingStatus WMI class, see the MSDN® article "Win32_PingStatus" (http://go.microsoft.com/fwlink/?LinkId=33549).

For more information about Active Directory site design, see "Designing the Site Topology" (http://go.microsoft.com/fwlink/?LinkId=33551).


Round-trip times to Active Directory server are taking more than 10 ms
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool queries the WIN32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class in the root\cimv2 namespace to determine the value for the ResponseTime key. If the Exchange Server Analyzer finds the value for the ResponseTime key to be greater than 10 milliseconds (ms) but less than 100 ms, a warning is displayed.

The ResponseTime key represents the time elapsed (in milliseconds) for the response to the Internet Control Message Protocol (ICMP) echo request (ping) packets sent from the Exchange server to the domain controller. Domain controllers used by an Exchange Server computer should always have a response time less than or equal to 10 ms. If the response time exceeds 10 ms, that could indicate performance or connectivity issues.

To correct this warning

  1. Check to ensure that the domain controller in question is not overloaded. Use the ADTest.exe tool to perform tests against the domain controller to see if the hardware can handle the anticipated load.

  2. Check the event logs on the Exchange server and the domain controller to see if any network-related events have been logged that indicate one or more problems.

  3. Use the DCDiag.exe and NetDiag.exe commands on the domain controller to verify correct configuration and health.

  4. Finally, investigate the Active Directory® directory service site design. An Active Directory site is considered to be a network section that has high bandwidth and low latency. If the network is not partitioned according to this specification, consider partitioning the network into more Active Directory sites.
Note:
When the Analyzer tool runs the WMI query for the ping test, the default packet size and timeout values are overridden. Instead, the Analyzer uses a 4096 ICMP packet size (in place of the default 32 byte) and a 2000 ms timeout value (in place of the default 1000 ms).

Follow these steps to emulate the Analyzer's ping behavior manually.

To perform the ping test manually

  • Run the following command in the command line window of the Exchange server:ping -L 4096 -N 6 <Active Server server name>Note The command initiates six ping requests of 4096 bytes each.

For more information about the ADTest.exe tool, see the Active Directory Performance Testing Tool (ADTest.exe) Web site (http://go.microsoft.com/fwlink/?LinkId=33758).

For more information about the Win32_PingStatus WMI class, see the MSDN® article "Win32_PingStatus" (http://go.microsoft.com/fwlink/?LinkId=33549).

For more information about Active Directory site design, see "Designing the Site Topology" (http://go.microsoft.com/fwlink/?LinkId=33551).


Round-trip times to global catalog server are taking more than 100 ms
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool queries the WIN32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class in the root\cimv2 namespace to determine the value for the ResponseTime key. If the Exchange Server Analyzer finds the value for the ResponseTime key to be more than 100 milliseconds (ms), an error is displayed.

The ResponseTime key represents the time elapsed (in milliseconds) for the response to the Internet Control Message Protocol (ICMP) echo request (ping) packets sent from the Exchange Server to the global catalog server. Global catalog servers used by an Exchange Server computer should always have a response time less than or equal to 10 ms. If the response time is more than 10 ms, there could be performance or connectivity issues.

To correct this error

  1. Check to ensure that the global catalog server in question is not overloaded. Use the ADTest.exe tool to perform tests against the global catalog server to see if the hardware can handle the anticipated load.

  2. Examine the event logs on the Exchange server and the global catalog server to see if any network-related events have been logged that indicate one or more problems.

  3. Use the DCDiag.exe and NetDiag.exe commands on the global catalog server to verify correct configuration and health.

  4. Finally, investigate the Active Directory® directory service site design. An Active Directory site is considered to be a network section that has high bandwidth and low latency. If the network is not partitioned according to this specification, consider partitioning the network into more Active Directory sites.
Note:
When the Analyzer tool runs the WMI query for the ping test, the default packet size and timeout values are overridden. Instead, the Analyzer uses a 4096 ICMP packet size (in place of the default 32 byte) and a 2000 ms timeout value (in place of the default 1000 ms).

Follow these steps to emulate the Analyzer's ping behavior manually.

To perform the ping test manually

  • Run the following command in the command line window of the Exchange server:ping -L 4096 -N 6 <Active Server server name>Note The command initiates six ping requests of 4096 bytes each.

For more information about the ADTest.exe tool, see the "Active Directory Performance Testing Tool (ADTest.exe)" Web site (http://go.microsoft.com/fwlink/?LinkId=33758).

For more information about the Win32_PingStatus WMI class, see the MSDN® article, "Win32_PingStatus" (http://go.microsoft.com/fwlink/?LinkId=33549).

For more information about Active Directory site design, see "Designing the Site Topology," (http://go.microsoft.com/fwlink/?LinkId=33551).

For information about installing the Windows 2000 Server support tools, see the Microsoft Knowledge Base article 301423, "How to install the Windows 2000 support tools to a Windows 2000 Server-based computer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301423).

For information about installing the Windows Server 2003 support tools, see "Install Windows Support Tools" (http://go.microsoft.com/fwlink/?LinkId=41362).


Round-trip times to global catalog server are taking more than 10 ms
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-03-16

The Microsoft® Exchange Server Analyzer Tool queries the WIN32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class in the root\cimv2 namespace to determine the value for the ResponseTime key. If the Exchange Server Analyzer finds the value for the ResponseTime key to be greater than 10 milliseconds (ms) but less than 100 ms, a warning is displayed.

The ResponseTime key represents the time elapsed (in milliseconds) for the response to the Internet Control Message Protocol (ICMP) echo request (ping) packets sent from the Exchange server to the global catalog server. Global catalog servers used by an Exchange Server computer should always have a response time less than or equal to 10 milliseconds. If the response time exceeds 10 milliseconds, there could be performance or connectivity issues.

To correct this warning

  1. Check to ensure that the global catalog server in question is not overloaded. Use the ADTest.exe tool to perform tests against the global catalog server to see if the hardware can handle the anticipated load.

  2. Check the event logs on the Exchange server and the global catalog server to see if any network-related events have been logged that indicate one or more problems.

  3. Use the DCDiag.exe and NetDiag.exe commands on the global catalog server to verify correct configuration and health.

  4. Finally, investigate the Active Directory® directory service site design. An Active Directory site is considered to be a network section that has high bandwidth and low latency. If the network is not partitioned according to this specification, consider partitioning the network into more Active Directory sites.
Note:
When the Analyzer tool runs the WMI query for the ping test, the default packet size and timeout values are overridden. Instead, the Analyzer uses a 4096 ICMP packet size (in place of the default 32 byte) and a 2000 ms timeout value (in place of the default 1000 ms).

Follow these steps to emulate the Analyzer's ping behavior manually.

To perform the ping test manually

  • Run the following command in the command line window of the Exchange server:

    ping -L 4096 -N 6 <Active Server server name>

    Note:
    The command initiates six ping requests of 4096 bytes each.

For more information about the ADTest.exe tool, see the "Active Directory Performance Testing Tool (ADTest.exe)" Web site (http://go.microsoft.com/fwlink/?LinkId=33758).

For more information about the Win32_PingStatus WMI class, see the MSDN® article, "Win32_PingStatus" (http://go.microsoft.com/fwlink/?linkid=33549).

For more information about Active Directory site design, see "Designing the Site Topology" (http://go.microsoft.com/fwlink/?linkid=33551).


Search filter change is required for Recipient Policy
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the purportedSearch attribute of each Exchange recipient policy object. The purportedSearch attribute indicates the search argument that is used when the policy is applied.

The Exchange Server Analyzer also queries Active Directory to determine the value for the msDS-Behavior-Version attribute of the forest object in Active Directory, NTDS Settings. This value indicates the Active Directory forest functional level. Valid values for the msDS-Behavior-Version attribute are shown in the following table.

Value | Forest functional level
0 | Microsoft Windows® 2000 Server mixed
1 | Microsoft Windows Server™ 2003 interim
2 | Windows Server 2003 native

The Exchange Server Analyzer also queries Active Directory to determine the value for the revision attribute of the Windows2003Update container. The value of this attribute indicates whether the Active Directory preparation tool (ADPrep.exe) has been run.

Finally, the Exchange Server Analyzer queries the Win32_OperatingSystem Windows Management Instrumentation (WMI) class to determine the value of the OSProductSuite key. The value of the OSProductSuite key indicates the version of Windows that is running on the computer.

If the Exchange Server Analyzer finds the following criteria to be true, the Exchange Server Analyzer displays a warning:

  • The value of the purportedSearch attribute of the recipient policy contains homeMdb.

  • The Active Directory forest functional level is Windows Server 2003 interim or Windows Server 2003 native mode.

  • The Exchange Server computer is not running Microsoft Windows Small Business Server 2003.

This warning indicates that the Active Directory forest has been prepared for Windows Server 2003. To avoid e-mail address stamping issues when the forest is upgraded to Windows Server 2003 full functionality level, a modification to the recipient policies is required. The affected recipient policy is specified in the Exchange Server Analyzer output.

If Windows Server 2003 is used as a domain controller and the recipient policy is not updated, linked value replication in Windows Server 2003 causes the Recipient Update Service to incorrectly write the e-mail addresses of new users. The first time the Recipient Update Service sees the user, it may be between the time that mailnickname replicates and the time that homeMDB replicates, due to linked value replication. Therefore, the user would fall under the default policy at that time, instead of under the homeMDB-based policy. A few minutes later, when homeMDB replicates, the user would fall under their homeMDB policy. However, the user already would have addresses that match the default policy.

To correct this warning

  1. Open Exchange System Manager.

  2. Expand Recipients, select Recipient Policies, right-click RecipientPolicyName, and then click Properties.

  3. On the RecipientPolicyName Properties page, on the General tab, under Filter rules, click Modify.

  4. On the Find Exchange Recipients menu, select Custom Search. If the recipient policy was originally created by a custom search, the Find Custom Search page is displayed after you click Modify in step 3.

  5. Change the Lightweight Directory Access Protocol (LDAP) query so that the homeMdb attribute is not used as part of the filter condition. Attributes such as extensionAttribute, msExchHomeServerName, or UPN are valid arguments that may help you achieve the same search result.

  6. Click OK to save the change, and then close Exchange System Manager.


Search filter change required for Recipient Policy
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the purportedSearch attribute of each Exchange recipient policy object. The purportedSearch attribute indicates the search argument that is used when the policy is applied.

The Exchange Server Analyzer also queries Active Directory to determine the value for the msDS-Behavior-Version attribute of the forest object in Active Directory, NTDS Settings. This value indicates the Active Directory forest functional level. Valid values for the msDS-Behavior-Version attribute are shown in the following table.

Value | Forest functional level
0 | Windows® 2000 Server mixed
1 | Windows Server™ 2003 interim
2 | Windows Server 2003 native

The Exchange Server Analyzer also queries Active Directory to determine the value for the revision attribute of the Windows2003Update container. The value of this attribute indicates whether the Active Directory preparation tool (ADPrep.exe) has been run.

Finally, the Exchange Server Analyzer queries the Win32_OperatingSystem Windows Management Instrumentation (WMI) class to determine the value of the OSProductSuite key. The value of the OSProductSuite key indicates the version of Windows running on the computer.

If the Exchange Server Analyzer finds the following criteria to be true, a warning is displayed:

  • The value of the purportedSearch attribute of the recipient policy contains (homeMdb=).

  • The Active Directory forest functional level is Windows 2000 Server mixed.

  • The Active Directory forest has been prepared for Windows Server 2003 domain controllers.

  • The Exchange Server computer is not running Microsoft Windows Small Business Server 2003.

This warning indicates that the Active Directory forest has been prepared for Windows Server 2003. To avoid e-mail address stamping issues when the Active Directory forest is upgraded to the full functional level of Windows Server 2003, you must modify the recipient policies. The affected recipient policy is specified in the Exchange Server Analyzer output.

If you use Windows Server 2003 as a domain controller and you do not update the recipient policy, linked value replication in Windows Server 2003 causes the Recipient Update Service to incorrectly write the e-mail addresses of new users.

Because of linked value replication, the Recipient Update Service may detect a new user for the first time between the time that mailnickname replicates and the time that homeMdb replicates. Therefore, the user would fall under the default policy at that time, instead of under the homeMdb-based policy. Several minutes later, when homeMdb replicates, the user would fall under the homeMdb policy. However, the user already would have addresses that match the default policy.

To correct this warning

  1. Open Exchange System Manager.

  2. Expand Recipients, select Recipient Policies, right-click RecipientPolicyName, and then click Properties.

  3. On the RecipientPolicyName Properties page, on the General tab, under Filter rules, click Modify.

  4. On the Find Exchange Recipients menu, select Custom Search. If the recipient policy was originally created by a custom search, the Find Custom Search page is displayed after you click Modify in Step 3.

  5. Change the Lightweight Directory Access Protocol (LDAP) query so that the homeMdb attribute is not used as part of the filter condition. Attributes such as extensionAttribute, msExchHomeServerName, or UPN are valid arguments that may help you achieve the same search result.

  6. Click OK two times to save the change, and then close Exchange System Manager.


Sender ID not Configured
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-05-10

The Microsoft Exchange Best Practices Analyzer tool uses the following Exchange Management Shell cmdlet to query for the values of the Enabled and ExternalMailEnabled properties of the SenderIdConfig object for any target Exchange Server 2007 Edge Transport or Hub Transport server roles.

Copy Code
- get-SenderIdConfig

The value of the Enabled property specifies whether the Sender ID agent is enabled. Valid input for the Enabled parameter is $true or $false. The default setting is $true. When the Enabled parameter is set to $true, the Sender ID agent is enabled.

The value of the ExternalMailEnabled property specifies whether all messages from unauthenticated connections are passed through the Sender ID agent for processing. Valid input for the ExternalMailEnabled parameter is $true or $false. The default setting is $true. When the ExternalMailEnabled parameter is set to $true, all messages from unauthenticated connections are passed through the Sender ID agent for processing.

If the Exchange Best Practices Analyzer determines that the values for the SenderIdConfig object Enabled or ExternalMailEnabled properties are not set to $true, the Exchange Best Practices Analyzer displays a best practices message.

This message indicates that Sender ID is not enabled on the target Exchange 2007 Edge Transport or Hub Transport server roles.

Sender ID seeks to verify that every e-mail message originates from the Internet domain from which it claims to have been sent.

When Sender ID is enabled on a computer, it filters all messages that come through all Receive connectors on that computer. Only messages that come from external sources are filtered. External sources are defined as non-authenticated sources. These are considered anonymous Internet sources.

To address this issue, enable Sender ID on the target Exchange 2007 Edge Transport or Hub Transport server roles.

To use the Exchange Management Shell to enable Sender ID functionality

  • To enable sender filtering, run the following command:

    Copy Code
    Set-SenderIdConfig -Enabled $true -ExternalMailEnabled $true

For more information about Sender ID, see the following topics:

  • Sender ID Home Page (http://go.microsoft.com/fwlink/?linkid=50977)

  • Exchange 2007 Sender ID (http://go.microsoft.com/fwlink/?LinkId=89719)

  • Configuring Sender ID (http://go.microsoft.com/fwlink/?LinkId=89720)


Server name case mismatch
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value stored in Active Directory for the name of the Exchange server (CN=<ExchangeServerName>). After the Exchange Server Analyzer retrieves this name, the Exchange Server Analyzer counts the number of characters in the name.

The Exchange Server Analyzer also reads the following registry entry to determine the value stored in the Exchange Server computer's registry for the host name of the Exchange server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Hostname

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Hostname

The Exchange Server Analyzer also queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for ClusSvc, the Windows® Cluster service.

The Exchange Server Analyzer displays a non-default configuration message if all the following conditions are true:

  • The value for CN=<ExchangeServerName> does not match the case for the value in Hostname. For example, CN=ComputerName and Hostname is set to COMPUTERNAME.

    Note:
    Although changing the case of the server name in the registry is supported, it is not recommended.
  • The Exchange server name is 15 characters or less.

  • The Exchange server is not running in a Windows cluster.

The most common cause of this error is that the name of the Exchange server has been changed manually in the registry.


Server name mismatch
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the setting for the This Server value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the name attribute for each Exchange server object.

Finally, the Exchange Server Analyzer queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Cluster service (ClusSvc). A value of TRUE indicates the Cluster service is started and a value of FALSE indicates the Cluster service is not running.

If the Exchange Server Analyzer finds that the value for the This Server key does not match the value for the server object's name attribute in Active Directory for any Exchange Server computer that is not running in a server cluster, an error is displayed.

To correct this error, you must edit the This Server registry key to match the value of the name attribute in Active Directory.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem.

  3. In the right pane, double-click This Server, enter the correct name for this computer, and then click OK.

  4. Close the registry editor and restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Server name too long
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-22

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the name (cn) of each directory object with an object class of msExchExchangeServer. The cn value is a string that contains the short name of the Exchange Server computer. The Exchange Server Analyzer retrieves the cn, and then determines the length of the string. The length of the string is the number of characters in the Exchange server name. If the Exchange Server Analyzer determines that an Exchange server name exceeds 15 characters, an error is displayed.

Exchange Server 2007, Exchange Server 2003, and Exchange 2000 Server have several NetBIOS dependencies that may require you to use NetBIOS name resolution across different subnets for the successful operation of all Exchange components, depending on the network topology. The NetBIOS naming convention allows for 16 characters in a NetBIOS name. Microsoft, however, limits NetBIOS names to 15 characters and uses the 16th character as a NetBIOS suffix.

Because Exchange Server has NetBIOS dependencies, and because NetBIOS names cannot exceed 15 characters, server names exceeding 15 characters are not supported in an Exchange organization. Additionally, because of the widespread effects that renaming an Exchange Server computer can have throughout Active Directory and the Exchange organization, renaming an Exchange Server computer is not supported.

To correct this error

  1. Remove the incorrectly-named Exchange Server computer by using the Remove option.

  2. Rename the computer with a name that has 15 characters or fewer.

  3. Reinstall Exchange Server on the computer.

For information about removing Exchange Server 2007, see "How to Completely Remove Exchange 2007 from a Server" (http://go.microsoft.com/fwlink/?LinkId=79246) in the Microsoft Exchange Server 2007 Deployment documentation.

For information about removing Exchange Server 2003, see "How to Uninstall Exchange Server 2003," in the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information, see the following Microsoft Knowledge Base articles:

  • 833396, "How to manually remove Exchange 2003 from your computer" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=833396)

  • 260378, "How to manually remove an Exchange 2000 installation" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260378)

  • 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810)

  • 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829)


Server RPC network address does not match Exchange server name
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the networkAddress attribute of each Exchange Server object in the directory. There are typically several entries listed for this multi-string attribute, as illustrated by the following examples:

ncacn_ip_tcp :<fully-qualified domain name of Exchange Server>

ncacn_np: <host name of Exchange Server>

ncacn_spx: <host name of Exchange Server>

ncacn_vns_spp: <host name of Exchange Server>

ncalrpc: <host name of Exchange Server>

netbios: <host name of Exchange Server>

The Exchange Server Analyzer also queries Active Directory to determine the value of the name attribute for each Exchange Server object.

If the Exchange Server Analyzer finds that the value for the name attribute does not match the name portion of any of the strings found in the networkAddress attribute, an error is displayed.

This error can occur if an administrator has manually changed the cn value of the server object. The networkAddress attribute is created and maintained by Exchange Server and it contains multiple string values to support the different network communication protocols supported by Exchange Server. Each value associates a protocol with the appropriate form of the server name as required by the particular protocol.

To correct this error, check to see whether the server name has been changed or whether the value is invalid, and then take the appropriate action:

  • If the server name has been changed, use the procedure later in this article to fix the values appropriately.

  • If the values are invalid for some other reason, re-run Exchange Setup on the server.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Using ADSI Edit or a similar tool, locate the administrative group object in Active Directory.

    The networkAddress attribute can be found at:

    CN=Configuration, CN=Services, CN=Microsoft Exchange, CN= OrganizationName , CN=Administrative Groups, CN= Administrative Group Name , CN=Servers, CN= Server Name

  2. Note the format of each of the values in the list. Update the values as needed, changing only the server name portion of each value.

    Note:
    Make sure that for the ncacn_ip_tcp value, the server name has the form of a fully qualified domain name, not a NetBIOS name or an Internet Protocol address.

  3. Close the Active Directory editor, and then restart the Exchange Routing Engine service.

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about Exchange routing issues, see "Troubleshooting Routing" in the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Service Principal Name Missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-08-14

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to find the values returned for the servicePrincipalName attribute of the Exchange server computer accounts for the Exchange resources listed in the table below.

Exchange Resource servicePrincipalName value | Expected Value Returned
exchangeMDB | Fully Qualified Domain Name (FQDN)
exchangeMDB | NetBIOS name
exchangeRFR | Fully Qualified Domain Name (FQDN)
exchangeRFR | NetBIOS name
SMTP | Fully Qualified Domain Name (FQDN)
SMTP | NetBIOS name
SMTPSVC | Fully Qualified Domain Name (FQDN)
SMTPSVC | NetBIOS name
HOST | Fully Qualified Domain Name (FQDN)
HOST | NetBIOS name

If the Exchange Server Analyzer finds that the servicePrincipalName attribute for the computer account of an Exchange resource is missing one of the expected values listed here, the Exchange Server Analyzer displays an error.

A Service Principal Name (SPN) is a unique name that identifies an instance of a service and is associated with the logon account under which the service instance runs. Kerberos authentication is not possible for Exchange services without properly set SPNs.

  • Authentication issues between clients that run Microsoft Office Outlook® 2003 or later and the Exchange Information Store (mailbox data) may indicate the lack of a valid SPN for the exchangeMDB resource.

  • Outlook 2003 or later clients that have Active Directory authentication issues may indicate the lack of a valid SPN for the exchangeRFR resource.

  • Authentication failures between Simple Mail Transport Protocol (SMTP) virtual servers may indicate the lack of a valid SPN for the SMTPSVC or HOST resource.

To resolve this issue, follow these steps to add the missing values for the affected attributes.

Use the SETSPN.exe tool to add an SPN with the missing values

  1. Install the Setspn.exe tool. To obtain the Setspn.exe tool, see "Windows 2000 Resource Kit Tool : Setspn.exe" (http://go.microsoft.com/fwlink/?LinkId=28103).

    The Windows Server 2003 version of the Setspn.exe command-line tool is available in the Windows Server 2003 Support Tools that are included on the Windows Server 2003 CD. To install the Server 2003 Support Tools, double-click the Suptools.msi file in the Support/Tools folder.

  2. Follow the guidance in the SETSPN.EXE Setspn_d.txt file to add the missing value to the Active Directory object for your Exchange server. The following example demonstrates adding the FQDN value for a virtual SMTP server SPN:

    • Start a command prompt, and then change to the directory where you installed Setspn.exe.

    • At the command prompt, type the following command:

      setspn.exe -a SMTPSVC/ mail.yourdomain.com YOURSERVERNAME

      Note:
      Replace mail.yourdomain.com with your SMTP virtual server FQDN and YOURSERVERNAME with the name of the Exchange server.
      Then press Enter.


A service terminated unexpectedly in the last 24 hours
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-14

The Microsoft Exchange Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows Management Instrumentation (WMI) class to determine whether an Event 7031 warning has been logged for the Service Control Manager source within the last 24 hours.

An Event 7031 warning means the specified service could not continue. The service is configured to report the number of failures and, after a specific number of failures are reported, the Service Control Manager will perform the recovery action configured for the specified service.

If the Exchange Analyzer finds that one or more of these events has been logged within the last 24 hours, the Exchange Analyzer displays an informational message.

This issue can be caused by various problems including, but not limited to, the following which are the most common:

  • A corrupted message being processed.

  • Antivirus application configuration issues.

To address this issue:

  • Follow the guidance in Microsoft Knowledge Base article 286350, "How to use ADPlus to troubleshoot "hangs" and "crashes"" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=286350) to isolate the cause of a process becoming unresponsive (hang) or stopping unexpectedly (crash).

  • Obtain the latest service pack for Microsoft Windows 2000.

  • Obtain the latest service pack for Microsoft Exchange Server.

  • Contact the antivirus application vendor to obtain the latest updates and configuration information.

For More Information

For more information about Event 7031 warning details, see the "Events and Errors Message Center: Event Details" (http://go.microsoft.com/fwlink/?LinkId=83114)

For more information about how to obtain the latest service pack for Windows 2000 Server, see Microsoft Knowledge Base article 260910, "How to obtain the latest Windows 2000 service pack" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260910)

For more information about how to obtain the latest service pack for Exchange 2000 Server, see Microsoft Knowledge Base article 301378, "How to obtain the latest Exchange 2000 Server service pack" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378).

For more information about how to obtain the latest service pack for Exchange Server 2003, see "Why Try Service Pack 2 for Exchange Server 2003?" (http://go.microsoft.com/fwlink/?LinkId=52073)

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange Server computer that has antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Services Value is Missing or Inaccessible
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-07-24

The Microsoft Exchange Analyzer Tool reads the following registry entry to verify the existence of the Services string type value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Setup

If the Exchange Analyzer finds that the Services string type value is missing or inaccessible, the Exchange Analyzer displays an error.

This error indicates that the Services string type value, which is used to hold the path to the Exchange installation root is missing or inaccessible. The absence of the path to the Exchange installation root may cause a failure to initialize critical drivers and protocols which in turn will cause the Exchange information store and dependent services to fail upon startup.

To address this error, follow the guidance in Microsoft Knowledge Base article 285116, "Exchange Store Does Not Start: Errors 7024, 1026, 9542, and 5000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=285116).


Single free/busy replica found
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_PublicFolder Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine the number of free/busy replicas that are present in each administrative group.

If the Exchange Server Analyzer finds that only a single free/busy replica exists in an administrative group, the Exchange Server Analyzer displays a best practice message.

It is generally recommended that more than one replica of the free/busy folder exist in each administrative group. Sometimes multiple free/busy replicas can increase performance and resilience. In large Exchange organizations, a single replica of free/busy data may become overloaded. In all Exchange organizations, a single replica of the free/busy data is a single point of failure.

It is recommended that multiple replicas be used despite the following considerations:

  • Multiple replicas cause additional replication traffic over the network.

  • The risk of scheduling conflicts increases with multiple replicas.

At a minimum, there should be one replica for every 10,000 mailboxes.

For more information about free/busy folders and publishing free/busy information, see "Working with Exchange Server 2003 Stores" (http://go.microsoft.com/fwlink/?LinkId=47595).


Single free/busy replica found for large number of mailboxes
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_PublicFolder Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine the number of entries in the ReplicaList key. The number of entries represents the number of free/busy replicas that are present in each administrative group.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer finds that only a single free/busy replica exists in an administrative group that contains more than 10,000 mailboxes, the Exchange Server Analyzer displays an error.

It is generally recommended that more than one replica of the free/busy folder exist in each administrative group. Sometimes multiple free/busy replicas can increase performance and resilience. In large Exchange organizations, a single replica of free/busy data may become overloaded. In all Exchange organizations, a single replica of the free/busy data is a single point of failure.

It is recommended that multiple replicas be used despite the following considerations:

  • Multiple replicas cause additional replication traffic over the network.

  • The risk of scheduling conflicts increases with multiple replicas.

At a minimum, there should be one replica for every 10,000 mailboxes.

For more information about free/busy folders and publishing free/busy information, see "Working with Exchange Server 2003 Stores" (http://go.microsoft.com/fwlink/?LinkId=47595).


Single global catalog is present in topology
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_DSAccess Microsoft Windows® Management Instrumentation (WMI) class in the root\MicrosoftExchangeV2 namespace to determine the number of global catalog servers present in the topology. The number of global catalog servers is determined by counting the number of entries for the DSAccessNameGC WMI key. If the Exchange Server Analyzer finds that only one global catalog server exists in the topology, the Exchange Server Analyzer displays a best practice recommendation.

For fault tolerance, it is a best practice to have at least two global catalog servers available to service Exchange Servers and users. A single global catalog server represents a single point of failure. Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007 depend on global catalog servers for a variety of functions. If a global catalog server is not available, mail delivery can become slow or stop completely. Also, if a global catalog server is not available, Exchange Server services may not start. If Exchange Server services do not start, users cannot access their mailboxes.

For scalability and for fault tolerance, it is recommended that you configure at least two global catalog servers in each Active Directory® directory service site. If a site spans multiple domains, it is recommended that you configure a global catalog for each domain where Exchange 2000 Server computers, Exchange Server 2003 computers, or Exchange Server 2007 computers and clients reside. Also, it is recommended that you deploy one global catalog server for every four Exchange Server computer processors.

For details about how to create additional global catalog servers, see the Microsoft Knowledge Base article 313994, "How To Create or Move a Global Catalog in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=313994).

For more information about global catalog server placement and availability as it relates to Exchange Server, see the following Knowledge Base articles:

  • 875427, "Global catalog server placement and ratios in an Exchange 2000 Server organization or in an Exchange Server 2003 organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=875427)

  • 322801, "Exchange System Attendant Does Not Start, and You Receive a 'Global Catalog Servers Not Responding' Error Message" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322801)

  • 829361, "Exchange Server 2003 Computer Takes Longer Than You Expect to Shut Down" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829361)

  • 304403, "Exchange Considerations for Promoting a Domain Controller to a Global Catalog Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=304403)

  • 305065, "Exchange Server-Related Considerations for Demoting a Global Catalog Server to a Domain Controller" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=305065)


Site folder server deleted
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-03-01

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the siteFolderServer attribute for each administrative group object. If the Exchange Server Analyzer determines that the value for the siteFolderServer attribute contains the string DEL:, an error is displayed.

The siteFolderServer attribute represents the Distinguished Name (DN) of the Public Folder store that is responsible for hosting the site folders (normally the first server in the site or administrative group).

By default, the Site Folder Server is the first server that is installed in the administrative group. The public folder store on this server is the default location of the free/busy folders and offline address book folders for the administrative group. If you remove or decommission this server without replicating these folders to another server and designating that server as the offline address book server, Microsoft Office Outlook® 2003 users will see problems with the offline address book and with free/busy data.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Locate the public folder information store you want to designate as the Site Folder Server, by expanding the following nodes in the Configuration container:

    CN=Configuration,DC=<DomainName>,DC=com, CN=Services, CN=Microsoft Exchange, CN=<OrganizationName>, CN=Administrative Groups, CN=<AdministrativeGroupName> CN=Servers, CN=<ServerName>, CN=InformationStore, CN=<StorageGroupName>

  3. In the right pane, right-click CN=<PublicFolderStoreName>, and then click Properties.

  4. In the Attributes field, scroll down and select the distinguishedName attribute.

  5. Click Edit, and then copy the entire attribute to the Clipboard.

  6. Expand the Configuration container, and then expand CN=Configuration,CN=<DomainName>,CN=com, CN=Services, CN=Microsoft Exchange, CN=<OrganizationName>, CN=Administrative Groups

  7. Right-click the administrative group you want to modify, and then click Properties.

  8. In the Attributes field, scroll down and select the siteFolderServer attribute.

  9. Click Edit, and then paste the value for the distinguishedName attribute into the Value field.

  10. Double-check the contents of the Value field to ensure the paste was performed correctly, and then click OK to save the change.

  11. Click OK to close the Administrative Group properties.

  12. Exit the Active Directory editor and restart the Microsoft Exchange Server Information Store service on all Exchange Server computers in the site for the change to take effect.

For more information about re-creating system folders and resetting the Site Folder Server, see the following Microsoft Knowledge Base articles:

  • 822444, "How To Reset a Site Folder in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822444)

  • 275171, "How to Reset System Folders on an Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=275171)

  • 284200, "Schedule+ Free/Busy System Folder Is Missing" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=284200)

For more information about using the LDP tool, see the Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in the Windows Server Help.


Slow Active Directory directory service calls
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-14

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for Active Directory® directory service component events that exceed a response time of 2.5 seconds.

Exchange FCL Active Directory component events represent Microsoft Exchange Information Store service (Store.exe) function calls to the Active Directory component.

Active Directory provides all mailbox information, address list services, and other recipient-related information. Most Exchange Server 2003 configuration information is also stored in Active Directory.

Exchange Server services access information that is stored in Active Directory and write information to Active Directory.

If the Exchange Server Analyzer finds events in the FCL file that reflect a response time of more than 2.5 seconds for Active Directory function calls from the Microsoft Exchange Information Store service (Store.exe), the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Calls from the Microsoft Exchange Information Store service to Active Directory that take more than 2.5 seconds can be caused by the following conditions:

  • Network latency between the Exchange server and the Domain Controller.

  • Static or otherwise incorrect configuration of DSAccess.

  • An overloaded domain controller and global catalog.

  • An incorrectly designed Active Directory topology.

To resolve this error, take the following steps:

  • Run the Exchange Server Analyzer for an additional analysis of server issues. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Check the performance of the Active Directory Domain Controller servers.

  • Review the articles in the For More Information section of this document.

For More Information

For more information about Exchange performance and DSAccess, see Microsoft Knowledge Base article 250570, "Directory service server detection and DSAccess usage" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250570).

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).

For more information about Domain Controller performance, see the following Windows Server resources:

  • "Planning Domain Controller Capacity" (http://go.microsoft.com/fwlink/?LinkId=70191).

  • "Active Directory Monitoring of Domain Controllers" in the Windows 2000 Server Active Directory Planning and Deployment Guides (http://go.microsoft.com/fwlink/?LinkId=70193).


Slow ESE Calls
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), Store.fcl file, for Exchange Extensible Storage Engine (ESE) component events that exceed a response time of 2.5 seconds.

Exchange FCL ESE component events are representations of Microsoft Exchange Information Store service (Store.exe) function calls to the ESE component.

The Exchange Information Store sits on top of an ESE database. ESE is a sophisticated, transaction-based database engine. A transaction is a series of operations that are treated as an atomic (indivisible) unit. All operations in a transaction are either completed and permanently saved, or else no operations are performed.

Exchange Server uses ESE as an embedded database engine that determines the structure of the databases and manages memory. The database engine caches the databases in memory by transferring four-kilobyte (KB) chunks of data (pages) in and out of memory. It updates the pages in memory and writes new or updated pages back to the disk. When requests come to the system, the database engine can buffer data in memory. Therefore, it does not have to access the disk constantly.

Although caching data in memory is the fastest and most efficient way to process data, it means that when Exchange is running, the information on disk is never completely up-to-date, however the transaction log disk is always kept current with information about each transaction. However, because many changes in memory are not yet on disk, the database and memory are not synchronized.

If Exchange Server Analyzer finds that events in the Store.fcl file reflect a response time of more than 2.5 seconds for the ESE component function calls from the Microsoft Exchange Information Store service (Store.exe), Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Ongoing calls from the ESE can be caused by the following conditions:

  • Exchange online defragmentation.

  • Data backups.

    Note:
    If a data backup or online defragmentation was intentionally in process during the Exchange Call Trace logging collection, you can safely ignore this message as an indicator of an Exchange Server performance issue
  • Bottlenecks on a database drive.

To resolve this error, take the following steps:

  • As a best practice, we recommend that you not overlap backup windows or online maintenance with peak-user demand intervals.

  • Run the Exchange Server Analyzer for an additional analysis of server. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about how to configure the online defragmentation time windows, see Microsoft Knowledge Base article 244524, "XADM: How to Configure the Exchange Server Online Defragmentation Time Window" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=244524).

For more information about Exchange Server Disk Bottleneck issues, see Disk Bottleneck Detected.

For more information about how to size and optimize disks for Exchange Server, see "How to Calculate Your Disk I/O Requirements" and "Best Practices Common to Multiple Architectures" in Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=49324).

For more information about ESE, see "Extensible Storage Engine Architecture" (http://go.microsoft.com/fwlink/?linkid=67009).


Slow IMAIL Calls
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-12

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for events that exceed a response time of 2.5 seconds for the IMAIL component of the MAPI client.

Exchange FCL IMAIL MAPI component events represent Microsoft Exchange Information Store service (Store.exe) function calls to convert messages to Internet format and from Internet format to MAPI format.

The IMAIL component of Exchange Server is a flexible conversion service that is used by the Microsoft Exchange Information Store service between Internet and MAPI messages. This allows for the interoperability between clients which use RFC-822 or Internet format and clients that use the Exchange Server internal storage format, such as MAPI clients or internal STORE tasks.

Exchange uses the IMAIL mechanism to apply message formats to the content, as defined for Internet domains in Exchange System Manager or as specified by the user per recipient in Microsoft Office Outlook®. If no formatting parameters are passed to IMAIL, IMAIL formats MAPI messages in Summary TNEF (S/TNEF) format for transfer between servers.

If Exchange Server Analyzer finds events in the Store.fcl logging file that reflect a response time for IMAIL component of the MAPI client component function calls from the Microsoft Exchange Information Store service (Store.exe) of more than 2.5 seconds, the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Slow response times for Exchange Information Store service (Store.exe) function calls to IMAIL can be caused by the following conditions:

  • IMAIL tries to process much data in a message or attachment.

  • Many clients request data conversion.

  • DSAccess requests encounter a slow response.

  • There are bottlenecks on the TEMP and TMP drives.

  • There are ongoing mailbox moves.

  • To resolve this error, take the following steps:

  • Schedule any mailbox moves for off-peak demand intervals.

  • Run the Exchange Server Analyzer for an additional analysis of server issues such as message and attachment size limits. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about Exchange Server Disk Bottleneck issues, see Disk Bottleneck Detected.

For more information about how to size and optimize disks for Exchange Server, see "How to Calculate Your Disk I/O Requirements" and "Best Practices Common to Multiple Architectures" in Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=49324).

For more information about best practices for message size limits on Exchange Server, see Maximum outgoing message size has not been set.


Slow LSASS calls
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-12-04

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for Local Security Authentication Server (Lsass.exe) process component events that exceed a response time of 25 milliseconds.

Exchange FCL LSASS process component events represent Microsoft Exchange Information Store service (Store.exe) function calls to the Local Security Authentication Server (Lsass.exe) process component.

The Local Security Authentication Server process (Lsass.exe) is a security subsystem invoked by other processes to verify account information and logon validation.

Every Exchange client logon causes the server running Exchange Server to send a request to look up the account security identifier (SID) for the client and creates a call within the Local Security Authentication Server (Lsass.exe) process.

If Exchange Server Analyzer finds events in the Store.fcl logging file that reflect a response time of more than 25 milliseconds for Local Security Authentication Server (Lsass.exe) component function calls from the Microsoft Exchange Information Store service (Store.exe), the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Slow response times for Microsoft Exchange Information Store service (Store.exe) function calls to LSASS can be caused by the following conditions:

  • Server resource issues related to the number of users who authenticate at the same time.

  • Network latency between the Exchange server and the Domain Controller or global catalog server.

  • Server resource bottleneck issues.

To resolve this error, take the following steps:

  • Consider implementing the NeverPing parameter as described in 'NeverPing' Parameter Recommended

  • Run the Exchange Server Analyzer for an additional analysis of server issues such as message and attachment size limits. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about the Lsass.exe process and memory usage, see Microsoft Knowledge Base article 308356, "Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356).

For more information about Exchange Client Logons and LSASS issues, see Microsoft Knowledge Base article 161938, "Slow Exchange Client Logons Due to Resource Deadlock" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=161938).

For more information about network latency between the Exchange server and the Domain Controller or global catalog server, see the following Exchange Server Team Blog article, "Exchange Does Not Always Use Local GCs" (http://go.microsoft.com/fwlink/?LinkId=69166).

Note:
The content of each blog and its URL are subject to change without notice.

For more information about Server Resource Bottleneck issues, see Processor Bottleneck.

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).


Slow Virus Scanner Calls
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-11

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), the Store.fcl file, for Virusscan Virus API (VAPI) component events that exceed a response time of 2.5 seconds.

Exchange FCL Virusscan VAPI component events represent Microsoft Exchange Information Store service (Store.exe) function calls to external virus scanner software.

To enhance the troubleshooting of the VAPI, Exchange Server implements event logging that can be used to track the performance of the virus-scanning API.

Events that are logged include the following:

  • Loading and unloading of vendor DLLs.

  • Successful scanning of items.

  • Viruses that are located in the information store.

  • Unexpected behavior in the VAPI.

If the Exchange Server Analyzer finds events in the Store.fcl logging file that reflect a response time of more than 2.5 seconds for external virus scanner software function calls from the Microsoft Exchange Information Store service (Store.exe), the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Slow response times for Microsoft Exchange Information Store service (Store.exe) external function calls to the virus scanning software can be caused by the following conditions:

  • Updates to a virus scanner that generate a re-scan of items in the information store.

  • A misconfigured virus scanner

  • Virus scanner software processes a large message or attachment.

To resolve this error, take the following steps:

  • Schedule updates to your virus engine for times when resource consumption is low, that is, off-peak demand intervals.

  • Consider re-installing the virus scanning software, but reinstall at off-peak demand intervals.

  • Examine the configuration of your virus scanning engine for the correct thread configuration, file level exclusions, and so on. See Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • Review the articles in the For More Information section of this document.

For More Information

For more information about virus-scanning programs that are typically used with Microsoft Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

For more information about virus-scanning programs that are typically used with Microsoft Exchange 2000 Server, see the Knowledge Base article 328841, "Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).


Slow VSS Snapshot Calls
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-13

The Microsoft® Exchange Server Analyzer Tool examines the Exchange Function Call Log (FCL), Store.fcl file, for Volume Shadow Copy Service (VSS) snapshot component events that exceed a response time of 20 seconds.

Exchange FCL VSS component events represent Microsoft Exchange Information Store service (Store.exe) function calls to the VSS snapshot component.

VSS is a set of COM APIs that implements a framework that enables volume backups to be performed when applications on a system continue to write to the volumes.

Microsoft Exchange Server 2003 uses the VSS that is included in the Microsoft Windows Server™ 2003 operating system to take volume shadow copies of Exchange Server 2003 databases and transaction log files.

A VSS snapshot is not fully independent of the original data. Generically, snapshots are created when you define a marker in time and make sure that the data can be rolled back to that time.

If the Exchange Server Analyzer finds that events in the Store.fcl file reflect a response time of more than 20 seconds for the SS snapshot component function calls from the Microsoft Exchange Information Store service (Store.exe), the Exchange Server Analyzer displays an error.

When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.

Note:
If a VSS snapshot was intentionally initiated within 20 seconds of the Exchange Call Trace logging collection, you can safely ignore this error message as an indicator of an Exchange Server performance issue.

As a best practice, we recommend that you not overlap backup windows with online maintenance or peak-user demand intervals.

For More Information

For more information about VSS, see "Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=56571).


An 'SMTPSVC' error event (ID: 429) was logged within the last 24 hours
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-16

The Microsoft Exchange Analyzer tool queries the IIS metabase to determine the value of the LM/SmtpSvc/%SMTPInstance%/ServerState property for each instance of a Simple Mail Transfer Protocol (SMTP) Virtual Server.

The ServerState property presents the current state of the server instance. The states, and the corresponding state codes, are as follows: 1 (starting), 2 (started), 3 (stopping), 4 (stopped), 5 (pausing), 6 (paused), or 7 (continuing).

If the Exchange Analyzer determines that the value for the ServerState property for an SMTP Virtual Server instance is not equal to 2 (started) the Exchange Analyzer then queries the Win32_NTLogEvent Microsoft Windows Management Instrumentation (WMI) class to determine whether an Event 429 error has been logged for the SMTP Service (SMTPSVC) within the last 24 hours.

If the Exchange Analyzer finds that the SMTP Virtual Server Instance (VSI) is not started and there is at least one Event 429 error logged for the SMTPSVC within the past 24 hours, the Exchange Analyzer displays a warning.

This warning indicates that there may be issues with the designated directories for the SMTP Virtual Server Instance.

SMTP is the native mail protocol for mail submission and mail transport for Exchange Server. This means that clients use SMTP to send messages and Exchange servers use SMTP to deliver messages and message data.

When messages arrive at the Exchange computer through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are stored in the <drive>:\Program Files\Exchsrvr\Mailroot folder on the same partition that Exchange is installed on.

This problem can be caused by one of the following:

  • The <drive>:\Program Files\Exchsrvr\Mailroot directory path or folders under that directory path have been moved, are missing, or have become corrupt

  • The permissions to the <drive>:\Program Files\Exchsrvr\Mailroot or folders under that directory path are not set appropriately.

  • Antivirus application scanning of the <drive>:\Program Files\Exchsrvr\Mailroot directory path or folders under that directory path.

To address this warning, do one or more of the following:

  • Verify the location and integrity of the <drive>:\Program Files\Exchsrvr\Mailroot directory path and folders under that directory path.

  • Verify the permissions on the <drive>:\Program Files\Exchsrvr\Mailroot directory path and folders under that directory path.

  • Make sure that Antivirus applications are not scanning the folders in the <drive>:\Program Files\Exchsrvr\Mailroot directory path.

To verify the Mailroot directory path on Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server), and then click Stop.

  4. Right-click the SMTP virtual server again, and then click Properties.

  5. Click the Messages tab.

  6. In the Queue directory field, verify the full path of the appropriate Mailroot folder. You can click Browse to browse the local computer for the path.

  7. Click OK to save the changes.

  8. Right-click the SMTP virtual server, and then click Start.
To verify the Mailroot directory path on Exchange 2000 Server

  1. Stop all the Exchange Server and IIS services on the Exchange 2000 Server computer whose SMTP virtual server Mailroot folder you want to verify.

  2. Verify that the affected SMTP virtual server's value for msExchSmtpQueueDirectory is configured for the appropriate path.

  3. Wait for Active Directory to replicate this change to the global catalog servers used by this Exchange server.

  4. Start the Microsoft Exchange System Attendant service.

  5. On the Exchange Server computer, check for the presence of three instances of Event ID 1005 in the Application event log that have an Event Source of MSExchangeMU and a Category of General.

  6. Restart the Exchange Server computer for any changes to take effect.
To verify the default permissions to the Mailroot directory path on Exchange 2000 Server and Exchange Server 2003

  1. Start Windows Explorer, and then navigate to and expand the Exchsvr folder.

  2. Right-click the Mailroot folder, and then click Properties

  3. Click the Security tab, and then verify the following default permissions:

Account | Permissions
Administrators | Full Control
Authenticated Users | Read and Execute, List Folder Contents, Read
Creator Owner | None
Server Operators | Modify, Read and Execute, List Folder Contents, Read, Write
System | Full Control
  1. Verify these default permissions for all folders for each Virtual Server Instance are present.

For more information about the procedures that are described, see the following Microsoft Knowledge Base articles:

  • 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822933)

  • 318230, "XCON: How to Change the Exchange 2000 SMTP Mailroot Directory Location" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=318230)

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

For more information about configuring antivirus scanning applications for use with Exchange, see Anti-Virus folder exclusions have not been configured.

For detailed information about how to configure exclusions on RealTime scanning in Symantec AntiVirus Corporate Edition, see the Symantec antivirus Web site (http://www.symantec.com).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites that are mentioned here.

For more information about fortifying an Exchange Server environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange Server computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see "Exchange Server 2007 Partners: Antivirus, Antispam" (http://go.microsoft.com/fwlink/?linkid=16226).


SMTP instance fully-qualified domain name does not match server name
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the value of the ncacn_ip_tcp: string of the networkAddress attribute for the server object matches the Fully Qualified Domain Name (FQDN) in the msExchSmtpFullyQualifiedDomainName attribute from the Simple Mail Transfer Protocol (SMTP) virtual server object.

If the Exchange Server Analyzer determines that the values of these attributes do not match, the Exchange Server Analyzer displays a warning.

This warning indicates that the values of these attributes may have been manually changed and could be contribute to mail flow problems on this server.

The value of the msExchSmtpFullyQualifiedDomainName attribute specifies the FQDN for the SMTP virtual server and must be resolvable by the Domain Name System (DNS) networking protocol.

A valid DNS HOST (A) record must exist for the value of this attribute so that messaging servers that try to resolve the FQDN of the SMTP virtual server can retrieve the correct IP address and route mail appropriately.

For more information about the reverse DNS lookup feature in Exchange, see "Add a resource record to a DNS zone" (http://go.microsoft.com/fwlink/?LinkId=63002).

For more information about SMTP virtual server settings, see the following Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686).

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163).

For more information about SMTP Service Design, see "SMTP Service Design" in the Technical Reference Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=58876).


SMTP Local Queue length beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-20

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Local Queue Length performance counter of the SMTP Server performance object to analyze performance data.

If the Exchange Server Analyzer determines that the Local Queue Length counter has exceeded the peak value of 1000 during the sample time slice, the Exchange Server Analyzer displays an error.

The SMTP Server\Local Queue Length counter indicates the number of messages in the Simple Mail Transfer Protocol (SMTP) queue for local delivery to the Microsoft Exchange Information Store service. SMTP local queue data (Mailroot directory) is temporarily held in the storage device while it is being processed by Exchange Server. This design prevents the data from being lost if the server fails. For example, when a destination server is unreachable, the messages that should be routed to that server will be stored on the local server queue directory until they can be delivered.

This error indicates a performance issue or outages on the server, because the server can no longer deliver the incoming mail in a timely manner. The following conditions can cause this delay:

  • The Active Directory® directory service is not being consulted promptly.

  • Messages are not being handed off promptly for local delivery or SMTP.

  • Databases (mailbox stores and public folder stores) have been dismounted.

  • To resolve this issue, take the following steps:

  • Make sure all databases (mailbox stores and public folder stores) are mounted.

  • Identify the source of the performance bottleneck. A performance bottleneck may be CPU, disk, network, or memory related and can be caused by an increase in load to the server or insufficient server resources. Use the Performance Monitor (Perfmon.msc) tool to determine whether the bottleneck is caused by an increased load on the server or whether the server is undersized. If the server load has increased, identify the source of the load and reduce it. If the server has insufficient resources, increase the necessary resources or move users off the server.

  • Monitor external dependencies, such as the Active Directory directory service, for performance issues and troubleshoot and correct as necessary.

For More Information

  • For more information about SMTP transport tuning, see "SMTP Transport Tuning" in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting mail flow issues, see Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • For more information about troubleshooting transport issues, see Microsoft Knowledge Base article 257265, "General troubleshooting for transport issues in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265).

  • For more information about processor bottlenecks, see Processor Bottleneck.

  • For more information about disk Bottlenecks, see Disk Bottleneck Detected.

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about how to move user mailboxes to reduce server load, see Move User Mailboxes to Another Server.


SMTP Server performance monitor object is not available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Local Queue Length performance counter of the SMTP Server performance object to analyze performance data. If valid data is not returned from the counter, the Exchange Server Analyzer displays a baseline message.

If valid data is not returned by the performance data collection engine, any combination of the following conditions may be true:

  • The SMTP Server performance object is disabled.

  • The SMTP Server performance monitor object is missing or corrupted.

  • The Exchange Server Analyzer does not have appropriate permissions to access the performance objects.

The first two conditions may occur if certain extensible counters corrupt the registry, or if programs based on Microsoft Windows® Management Instrumentation (WMI) modify the registry. The following procedure explains how to fix the first two conditions. Before you perform the procedure, verify that the Exchange Server Analyzer has appropriate permissions. For more information about the permissions that are required to run the Exchange Server Analyzer, see the Help documentation that is included with the Exchange Server Analyzer. For Help, open the Exchange Server Analyzer, and press the F1 key.

To correct this error

  1. Verify that the SMTP Server performance object is enabled.

    1. Download and install the Extensible Performance Counter List tool (Exctrlst.exe). You can download Exctrlst.exe at the "Exctrlst.exe: Extensible Performance Counter List" Web site (http://go.microsoft.com/fwlink/?LinkId=34436).

    2. Open Exctrlst.exe, click Sort Order, and then click Service.

    3. Locate the service for which the performance object reports and verify that the Performance Counters Enabled check box is selected.

      If the Performance Counters Enabled check box is not selected, select the check box, and then restart the service that is associated with the performance counters to verify that performance counters are operational. If the performance counters are not operational, or if the Performance Counters Enabled check box was already selected, continue to step 2.

  2. Rebuild the missing or corrupted performance counters as specified in the Microsoft Knowledge Base article 300956, "How to manually rebuild Performance Counter Library values" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956).

  3. If following this Knowledge Base article does not solve the issue, you will have to reinstall the Windows operating system in the Repair mode, and then apply the latest Windows service packs.


SQL Server is running Virtual Server 2005 with Exchange Server installed as a Guest
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine whether the value for the Model key is set to Virtual Machine.

The Exchange Server Analyzer also checks for the presence of the following registry value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

Additionally, the Exchange Server Analyzer queries the Win32_Services WMI class to determine whether the Microsoft SQL Server™ service (MSSQLSERVER) is running on the physical computer that is running Microsoft Virtual Server 2005.

If the Exchange Server Analyzer finds that the Model key contains the string Virtual Machine, that the above registry branch exists, and MSSQLSERVER is running, an error is displayed.

A value of Virtual Machine for the Model key indicates that the Exchange Server computer is running as a guest virtual machine on either Virtual Server 2005 or Microsoft Virtual PC 2004. Because the above registry branch is only created by Virtual Server 2005, its existence means that the Exchange Server computer is running as a guest virtual machine in Virtual Server 2005.

Microsoft does not support running any version of Microsoft Exchange on a virtual machine or on an emulator. This is true for Exchange Server running on Microsoft Virtual Server 2005, Microsoft Virtual PC 2004, or any third-party virtual machine program. Microsoft Exchange Server platforms are designed and tested to run only on physical hardware, particularly those hardware platforms that are listed in the Windows Server Catalog (http://go.microsoft.com/fwlink/?linkid=17219).

Further, running Exchange as a virtual server guest on a computer that is running SQL Server is not a best practice because it does not allow for adequate redundancy across services.

To correct this error

  1. Move the mailboxes from the Exchange Server that is running under Virtual Server 2005 to a non-virtual Exchange Server computer.

  2. Re-home any public folders and transfer any roles held by the virtual Exchange server as necessary.

  3. Uninstall Exchange from the virtual machine to decommission and remove it from your Exchange infrastructure and from the Active Directory® directory service.

For more information about moving mailboxes, see the following Microsoft Knowledge Base articles:

  • 822892, "Move Mailbox improvements in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 224975, "XADM: Differences Between Move Mailbox Methods" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

For more information about support for Exchange Server computers running in virtual environments, see the Knowledge Base article, 320220, "Support Boundaries for Exchange Server on a Virtual Machine or an Emulation Machine" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220).

For more information about Microsoft Virtual Server 2005, see the Microsoft Virtual Server 2005 Web site (http://go.microsoft.com/fwlink/?linkid=34938).

For more information about Microsoft Virtual PC 2004, see the Microsoft Virtual PC 2004 Web site (http://go.microsoft.com/fwlink/?linkid=34663).


SRS port is below 5000
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the TCP/IP setting for the Microsoft Exchange Site Replication Service:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

If the Exchange Server Analyzer finds that TCP/IP is set to a value below 5,000 (decimal), a warning is displayed.

In the case where you must set TCP/IP to a static value, it is recommended that you set it to a value that is just over 5,000. Assigning static port numbers under 5,000 may cause a port conflict with another process and lead to failure of the Microsoft Exchange Site Replication Service process.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the TCP/IP registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters

  3. Double-click the TCP/IP key, and set the Value data field to an integer just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the Microsoft Exchange Site Replication Service for this change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about port limitations, see Knowledge Base article 194952, "XADM: Statically Mapped Port Limitations for Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=194952).


SRS port has been manually overridden
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the port value for the Microsoft Exchange Site Replication Service has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

If the Exchange Server Analyzer finds that TCP/IP is present and configured, a non-default configuration message is displayed.

The most common reason that this value is configured is to enable MAPI clients to connect to an Exchange server that is on the other side of a firewall. This scenario involves opening multiple ports on a firewall to enable Microsoft Office Outlook® 2003 clients to connect using MAPI to an Exchange server, typically over the Internet. This is a supported configuration. For more information about configuring MAPI clients to connect to Exchange through a firewall, see the Microsoft Knowledge Base article 270836, "Exchange 2000 and Exchange 2003 Static Port Mappings" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836). If you are not using this scenario, you should remove the registry key.

The recommended deployment for using Outlook in MAPI Mode to connect to an Exchange server over the Internet is to use the RPC over HTTP features found in Microsoft Windows Server™ 2003, Exchange Server 2003, Outlook 2003, and Microsoft Windows® XP Professional. MAPI Mode was formerly referred to as "Corporate" or "Workgroup" mode.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To remove the TCP/IP registry entry

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters

  3. Delete the registry value called TCP/IP.

  4. Exit the registry editor, and restart the Microsoft Exchange Site Replication Service.

To deploy RPC over HTTP

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  3. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  4. Review the Microsoft Support WebCast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


The start-up account configured for System Attendant is not supported
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Services Microsoft Windows® Management Instrumentation (WMI) class to determine whether the startup account that is specified in the StartName property of the Microsoft Exchange System Attendant service (MSExchangeSA) is using the LocalSystem account. If the Exchange Server Analyzer finds the value for the StartName property on an Exchange 2000 Server or Exchange Server 2003 computer to be any account other than the LocalSystem account, the Exchange Server Analyzer displays an error. The LocalSystem account is also referred to as the SYSTEM account.

You must start MSExchangeSA in Exchange 2000 Server and Exchange Server 2003 under the LocalSystem security context. You must not start MSExchangeSA by associating a specific user account. When an Exchange service that is running as LocalSystem accesses a remote server, the Exchange service is authenticated by using the credentials of the computer account.

The standard mechanism for changing passwords changes the password on the computer account every seven days. By changing the password every seven days, you enhance the security of the computer account. The computer account is more secure than a typical user account for the following reasons:

  • The password on a typical user account is changed less frequently.

  • The password on a typical user account is less random than a computer account password that is randomly generated.

In Exchange Server 5.5, user accounts are used for services. Some administrators who have experience with Exchange Server 5.5 change the startup account on Exchange 2000 Server services and Exchange Server 2003 services from the default LocalSystem account to a user account.

In Exchange 2000 Server and Exchange Server 2003, Microsoft does not support running MSExchangeSA on any account except the default LocalSystem account.

To correct this error

  1. Click Start, point to Programs, point to Administrative Tools, and then click Services.

  2. In the list of services, right-click Microsoft Exchange System Attendant, and then click Properties.

  3. On the Log on tab, under Log on as, click Local System account, and then click OK.

  4. Right-click Microsoft Exchange System Attendant, and then click Restart.

For more information about Exchange services, see the Microsoft Knowledge Base article 239762, "Exchange Services Run Under LocalSystem" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762).


STORE.EXE file is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to check for the presence of several core Exchange binary files:

  • Exres.dll

  • Gapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapi32.dll (checked in the System32 folder and the \Exchsrvr\bin folder)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

If the Exchange Server Analyzer finds that one or more of the above files are missing, an error is displayed. To remedy this error, install the latest service pack or rollup for your version of Exchange. If this error persists, run Exchange 2000 Server or Exchange Server 2003 Setup and select Re-install. Running Setup in Re-install mode installs only binary files. It does not remove or reset any user data or configuration data. If you reinstall Exchange Server, you must also reinstall any Exchange service packs or hotfixes that were installed.

To reinstall Exchange 2000 Server or Exchange Server 2003

  1. Log on to the server on which you want to reinstall Exchange. Insert the Exchange 2000 Server or Exchange Server 2003 CD into your CD-ROM drive.

  2. On the Start menu, click Run, and then type <drive>:\setup\i386\setup, where <drive> is your CD-ROM drive.

  3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification page, type your 25-digit product key, and then click Next.

  6. On the Component Selection page, in the Action column, use the drop-down arrow next to the Microsoft Exchange node, and select Re-install, and then click Next.

For more information about the latest Exchange Server 2003 service packs, update rollups, and add-ins, see the "Downloads for Exchange Server 2003" Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about the latest Exchange 2000 Server service packs, update rollups, and add-ins, see the "Downloads for Exchange 2000 Server" Web site (http://go.microsoft.com/fwlink/?LinkId=33457).


Store HTTP port is below 5000
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the Rpc/HTTP Port setting for the Microsoft Exchange Information Store service:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

If the Exchange Server Analyzer finds that the value for Rpc/HTTP Port is set to a value below 5000 (decimal), a warning is displayed.

The Rpc/HTTP Port registry key is set to 6001 by Exchange Server 2003 and Exchange Server 2007 Setup. The Rpc/HTTP Port registry key is used to support RPC over HTTP functionality for Microsoft Office Outlook® 2003 and Microsoft Office Outlook 2007.

Unless you have customized your RPC over HTTP deployment with the aid of Microsoft Consulting Services or by recommendation from Microsoft Product Support Services, it is recommended that you deploy RPC over HTTP with the default port values.

If you must set Rpc/HTTP Port to a value other than 6001, it is recommended that you set it to a value that is just over 5000. Assigning static port numbers under 5000 may cause a port conflict with another process and lead to failure of the Microsoft Exchange Information Store service process.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the Rpc/HTTP Port registry to its default value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

  3. Double-click the Rpc/HTTP Port key, and set the Value data field to 6001 (decimal) or to an integer just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about configuring RPC over HTTP, see the following Knowledge Base articles:

  • 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


Store: HTTP port is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether HTTP Port is set to the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

If the Exchange Server Analyzer finds that the value for Rpc/HTTP Port is not 6001 (decimal), a non-default configuration message is displayed.

The Rpc/HTTP Port registry key is set to 6001 by Exchange Server 2003 and Exchange Server 2007 Setup. The Rpc/HTTP Port registry key is used to support RPC over HTTP functionality for Microsoft Office Outlook® 2003 and Microsoft Office Outlook 2007.

Unless you have customized your RPC over HTTP deployment with the aid of Microsoft Consulting Services or by recommendation from Microsoft Product Support Services, it is recommended that you deploy RPC over HTTP with the default port values.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the Rpc/HTTP Port registry key to its default value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Double-click the Rpc/HTTP Port key, and set the Value data field to 6001 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about configuring RPC over HTTP, see the following Knowledge Base articles:

  • 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


Sub-optimal Memory Settings
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-15

The Microsoft Exchange Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows Management Instrumentation (WMI) class to determine whether an Event 9665 error has been logged for MSExchangeIS within the last 24 hours.

Microsoft Exchange Server 2003 performs an optimal memory configuration check when the store process starts. If the memory settings are not optimal, you will see event 9665 in Event Viewer.

If the Exchange Analyzer finds that an Event 9665 has been logged in the past 24 hours, the Exchange Analyzer then reads the data field of the event to determine which of the possible flags from the table below is present in the event.

Event Data Field Flag | Exchange Server Analyzer Warning Displayed | Exchange Server 2003 Issue
0x00000001 | The /3GB switch is not set | The server is running Microsoft Windows 2000 Advanced Server or Microsoft Windows 2000 Datacenter Server, has 1 GB or more of physical memory, but does not have the /3GB switch set in the boot.ini file.
0x00000002 | The /Userva switch is not set properly | The server is running Microsoft Windows Server 2003 Standard Edition, Microsoft Windows Server 2003 Enterprise Edition or Microsoft Windows Server 2003 Datacenter Edition, has 1 GB or more of physical memory and the /3GB switch is set, but the /USERVA setting is not present in the boot.ini file.
0x00000004 | The 'SystemPages' setting needs to be set. | The server is running any edition of Microsoft Windows 2000 Server and the SystemPages value in the registry is set outside the range of 24000 to 31000.
0x00000008 | The 'SystemPages' setting needs to be reset | The server is running Microsoft Windows Server 2003 Standard, Microsoft Windows Server 2003 Enterprise, or Microsoft Windows Server 2003 Datacenter Edition, and the SystemPages value in the registry is set to something other than 0.
0x00000010 | The HeapDecommitFreeBlockThreshold setting is not properly set | The server is running any edition of Microsoft Windows 2000 Server or Microsoft Windows Server 2003, and the HeapDeCommitFreeBlockThreshold value in the registry is set to something other than 0x00040000

Depending on the flag that is present in the Event 9665 data field, the Exchange Analyzer displays the corresponding warning from the above table.

These warnings indicate that the Exchange Server memory is set to a sub-optimal state.

To address these warnings, follow the guidance of the issue-specific Exchange Analyzer articles listed below:

  • This Exchange mailbox server has 1 GB or more of memory but does not have /3GB set in the Boot.ini file

  • USERVA is set incorrectly

  • SystemPages set too high

  • This server is running Windows Server 2003 and the SystemPages value is not equal to 0

  • This server has 1 GB or more of physical memory and HeapDeCommitFreeBlockThreshold has not been set to 262144

For More Information

For more information about these issues, see Microsoft Knowledge Base article 325044, "How to troubleshoot virtual memory fragmentation in Exchange Server 2003 and Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044).

For more information about MSExchangeIS Event 9665, see the "Events and Errors Message Center: Event Details."

  • For Mailbox Store event 9665 see, (http://go.microsoft.com/fwlink/?LinkId=83210)

  • For Public Store event 9665 see, (http://go.microsoft.com/fwlink/?LinkId=83213).


Suspect Desktop Search Installed on Clients
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-09-05

The Microsoft® Exchange Server Analyzer Tool has determined that you have many users who are using a desktop search engine. Desktop search engines may create many remote procedure calls (RPCs) against a user's mounted mailboxes, as well as substantial traffic against the public folders as these search engines crawl the file structure of the public folder store. Many search engines only crawl the public folders if they are in the user's public folder Favorites list. Therefore, you may or may not see load on the public folder servers from desktop search.

Actions that you can take to mitigate this issue include the following:

  • Have your users turn off the scanner's Microsoft Office Outlook® features, or limit the scan to just their personal mailbox.

  • Run Outlook in Cached Exchange Mode so that the scans only affect the local workstation and not the server.

  • Follow the guidance of Microsoft Knowledge Base article 889086, "You may experience unexpected behavior in a Windows XP-based computer when you try to access public folders on Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=889086) to obtain the hofix and set the MaxObjsPerMapiSession registry key on computers that are running Exchange Server that are accessed by desktop search users.

To verify if the desktop search application is the cause of high load for a particular user, use Microsoft Exchange Server User Monitor (ExMon) to monitor the RPC operations the search engine's actions, make sure you gather data for an adequate time period (at least five minutes). Then, remove the search engine and run the ExMon tool again. If there is a significant decrease in the RPC rate, you have confirmed that desktop search engine is causing the increase in load. If you observe that the average RPC latency decreases, you have confirmed that the high load resulted in higher RPC latencies.

Note:
RPC latency rates vary considerably throughout the day. Therefore, a five-minute test may be inadequate. You may need to measure for a longer period of time.

To download ExMon, see the Microsoft Download Center (http://go.microsoft.com/fwlink/?linkid=54983).

For More Information

  • For more information about desktop search software, see:

    • Microsoft Knowledge Base article 905184, "Exchange 2000 Server and Exchange Server 2003 performance may be affected when desktop search engine software is running on Outlook or other MAPI client computers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905184).

    • Microsoft Exchange Team blog, "Are your clients using desktop search engines that index Exchange mailboxes or public folders?" (http://go.microsoft.com/fwlink/?LinkId=54475).

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


SystemPages set too high
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-03-13

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for SystemPages:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages

If the Exchange Server Analyzer finds the value for SystemPages to be larger than 50000, the Exchange Server Analyzer displays a warning.

Microsoft Windows Server™ 2003 and Microsoft Windows® 2000 Server can directly address up to 4 gigabytes (GB) of memory address space, regardless of how much physical RAM is installed. From the process perspective, each element of virtual address conceptually refers to a byte of physical memory. It is the responsibility of the Virtual Memory Manager (VMM) in conjunction with processor memory manager unit (MMU) to translate or map each virtual address into a corresponding physical address. The VMM performs the mapping by dividing the RAM into fixed-size page frames, creating system page table entries (PTEs) to store information about these page frames, and mapping them. System PTEs are small kernel-mode buffers of memory that are used to communicate with the disk I/O subsystem and the network. Each PTE represents a page frame and contains information necessary for the VMM to locate a page.

On an x86-based system that uses a 4 KB page size, the maximum number of PTEs required to map 2 GB of address space is 524,288 (2 GB/4 KB). On a similar system using the /3GB switch, the number of PTEs requires to map 3 GB of address space is 786,432 (3 GB/4 KB). On a typical system, this space is used as follows:

  • A maximum of 50,000 PTEs (approximately 195 MB address space) are reserved for general use.

  • The rest is used in mapping system cache, hyperspace, paged pool, non-paged pool, crash dump area, and so on.

This PTE pool size is automatically determined at system startup based on the amount of physical memory in the system. This pool is squeezed in between paged pool and non-paged pool, which also grows with the amount of physical memory in the system.

The system PTE pool can become heavily used and heavily fragmented. This could lead to situations where a driver may not load, and so on. Also, if the system PTE pool is depleted entirely, other parts of the system will degrade, even resulting in threads not being created, system stalls, and potential system crashes.

To prevent the system PTE pool from becoming heavily fragmented, you should always configure the SystemPages registry value appropriately for your Exchange Server computer's operating system. When you are running Exchange Server on Windows Server 2003, it is recommended that you set the SystemPages registry key to 0. This recommendation contrasts with the recommendation for Windows 2000 Server, which is to set SystemPages to a value between 24000 and 31000.

After performing the procedure described below, you should monitor the number of free system PTEs. You can do this by monitoring the Memory | Free System Page Table Entries performance counter with the Windows Performance Monitor (also known as System Monitor). If, after making the registry change described below, the number of free system PTEs remains low, you should check the following to ensure your Exchange Server computer is optimally configured:

  • Drivers A malfunctioning driver is one of the most common causes of low system PTEs. In addition, certain versions of the S3 Savage 4 video card drivers are known to set SystemPages to 208896. This driver is often found on IBM E-Series servers. Check with your hardware manufacturer to ensure you are using the latest drivers for all of your hardware. There may be opportunities to downgrade to a more basic driver, as well. For example, computers that run server-based applications such as Exchange Server generally do not need the most advanced video drivers with all of the features. Instead, a more basic driver is often sufficient. Switching from an advanced video driver to a basic video driver should increase the number of free system PTEs.

  • System configuration If your Windows Server 2003 system has 1 GB or more of physical memory installed, you should check to ensure that its Boot.ini file is correctly configured with the /3GB and /USERVA=3030 switches as described in the following Microsoft Knowledge Base articles:

    • 823440, "You Must Use the /3GB Switch When You Install Exchange Server 2003 on a Windows Server 2003-Based System" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440)

    • 810371, "XADM: Using the /Userva Switch on Windows Server 2003-Based Exchange Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371).

  • Event Logs Check the application event log on the Exchange Server for errors and warnings, especially MSExchangeIS events 9582 (errors and warnings), 9665 (warning) and 12880 (error). The presence of event 9665 could also indicate that SystemPages is not configured for optimal performance. For more information about these events, see the 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).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning on Windows 2000 Server by changing the value for SystemPages

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. In the right pane, double-click SystemPages.

  4. In the Value data field, type a value between 24000 and 31000 (decimal), and then click OK. If you are unsure what value to use, we recommend using 31000 (decimal).

  5. Close the registry editor and restart the computer for the change to take effect.

To correct this warning on Windows Server 2003 by changing the value for SystemPages

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. In the right pane, double-click SystemPages.

  4. In the Value data field, type 0, and then click OK.

  5. Close the registry editor and restart the computer for the change to take effect.

To correct this warning by updating or downgrading the video driver

  • Do one of the following:

    • Contact your hardware manufacturer to obtain an updated video driver that does not configure the SystemPages setting.

    • Downgrade the video driver to a standard VGA driver, and correct the SystemPages value as described above.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about optimizing memory for Exchange Server, see the following Knowledge Base articles:

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 311901, "The effects of 4GT tuning on System Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


System Attendant HTTP port is below 5000
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the HTTP Port setting for the Microsoft Exchange System Attendant:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

If the Exchange Server Analyzer finds that the value for HTTP Port is set to a value below 5000 (decimal), a warning is displayed.

The HTTP Port registry key is set to 6002 by Exchange Server 2003 and Exchange Server 2007 Setup. The HTTP Port registry key is used to support RPC over HTTP functionality for Microsoft Office Outlook® 2003 and Microsoft Office Outlook 2007.

Unless you have customized your RPC over HTTP deployment with the aid of Microsoft Consulting Services or by recommendation from Microsoft Product Support Services, it is recommended that you deploy RPC over HTTP with the default port values.

If you must set HTTP Port to a value other than 6002, it is recommended that you set it to a value that is just over 5000. Assigning static port numbers under 5000 may cause a port conflict with another process and lead to failure of the Microsoft Exchange System Attendant process.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the HTTP Port registry key to its default value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the HTTP Port key, and set the Value data field to 6002 (decimal) or to an integer just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about configuring RPC over HTTP, see the following Knowledge Base articles:

  • 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


System Attendant HTTP NSPI port is below 5000
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the Rpc/HTTP NSPI Port setting for the Microsoft Exchange System Attendant:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

If the Exchange Server Analyzer finds that the value for Rpc/HTTP NSPI Port is set to a value below 5000 (decimal), a warning is displayed.

The Rpc/HTTP NSPI Port registry key is set to 6004 by Exchange Server 2003 and Exchange Server 2007 Setup. The Rpc/HTTP NSPI Port registry key is used to support RPC over HTTP functionality for Microsoft Office Outlook® 2003 and Microsoft Office Outlook 2007.

Unless you have customized your RPC over HTTP deployment with the aid of Microsoft Consulting Services or by recommendation from Microsoft Product Support Services, we recommend that you deploy RPC over HTTP with the default port values.

If you must set Rpc/HTTP NSPI Port to a value other than 6004, it is recommended that you set it to a value that is just over 5000. Assigning static port numbers under 5000 may cause a port conflict with another process and lead to failure of the Microsoft Exchange System Attendant process.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the Rpc/HTTP NSPI Port registry key to its default value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the Rpc/HTTP NSPI Port key, and set the Value data field to 6004 (decimal), or an integer just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about configuring RPC over HTTP, see the following Knowledge Base articles:

  • 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


System Attendant: HTTP NSPI port is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether HTTP Port is set to the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

If the Exchange Server Analyzer finds that the value for Rpc/HTTP NSPI Port is not 6004 (decimal), a non-default configuration message is displayed.

The Rpc/HTTP NSPI Port registry key is set to 6004 by Exchange Server 2003 Setup. The Rpc/HTTP NSPI Port registry key is used to support RPC over HTTP functionality for Microsoft Office Outlook® 2003.

Unless you have customized your RPC over HTTP deployment with the aid of Microsoft Consulting Services or by recommendation from Microsoft Product Support Services, it is recommended that you deploy RPC over HTTP with the default port values.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the Rpc/HTTP NSPI Port registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the Rpc/HTTP NSPI Port key, and set the Value data field to 6004 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about configuring RPC over HTTP, see the following Knowledge Base articles:

  • 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


System Attendant: HTTP port value is non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether HTTP Port is set to the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

If the Exchange Server Analyzer finds that the value for HTTP Port is not 6002 (decimal), a non-default configuration message is displayed.

The HTTP Port registry key is set to 6002 by Exchange Server 2003 and Exchange Server 2007 Setup. The HTTP Port registry key is used to support RPC over HTTP functionality for Microsoft Office Outlook® 2003 and Microsoft Office Outlook 2007.

Unless you have customized your RPC over HTTP deployment with the aid of Microsoft Consulting Services or by recommendation from Microsoft Product Support Services, it is recommended that you deploy RPC over HTTP with the default port values.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the HTTP port registry key to its default value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Double-click the HTTP Port key, and set the Value data field to 6002 (decimal).

  4. Close the registry editor.

  5. Restart the computer for this setting to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about configuring RPC over HTTP, see the following Knowledge Base articles:

  • 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


System Attendant legacyExchangeDN value is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the legacyExchangeDN attribute for the System Attendant object for each Exchange Server computer. If the Exchange Server Analyzer does not find a value for the legacyExchangeDN attribute of any System Attendant object, the Exchange Server Analyzer displays an error message.

A missing legacyExchangeDN can result when an administrator modifies Active Directory to recover a database in a failure recovery situation. To resolve this error, you must modify the legacyExchangeDN attribute using an Active Directory editor, such as the LDP (ldp.exe) tool or Active Directory Service Interfaces (ADSI) Edit.

To make sure that the legacyExchangeDN attribute is correct you should also examine other System Attendant objects for this server or another Exchange server that does not generate this error, because they should have a similar value for the legacyExchangeDN attribute.

In a situation where the legacyExchangeDN attribute is missing on a database, probably the attribute is also missing on several other system objects. Therefore, if you use LDP or ADSI Edit to add a new legacyExchangeDN value, you will have to add a new legacyExchangeDN value on all the other system objects also.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.
To correct this error

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Expand Configuration [DomainName], expand, CN=Configuration, DC=DomainName, DC=DomainSuffix.

  3. Expand CN=Services, and then expand CN=Microsoft Exchange.

  4. Expand CN=OrganizationName, expand CN=Administrative Groups, and then expand CN=AdminGroupName.

  5. Expand CN=Servers, expand CN=ServerName.

  6. Right-click CN=Microsoft System Attendant and select Properties.

  7. Scroll down to locate legacyExchangeDN, select it, and click Edit.

  8. In the Value field, enter the correct legacyExchangeDN.

  9. Close the Active Directory editor and restart the Exchange Server computer for the change to take effect.

For more information about using ADSI Edit to create a new legacyExchangeDN attribute, see the Microsoft Knowledge Base article 273863, "How to Change the LegacyExchangeDN Attribute in Native Mode with ADSI Edit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=273863).


System Attendant NSPI port has been manually overridden
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether the Name Service Provider Interface target server (NSPI target server) service has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

If the Exchange Server Analyzer finds TCP/IP NSPI Port to be present and configured, a non-default configuration message is displayed.

The most common reason this value is configured is to enable MAPI clients to connect to an Exchange server that is on the other side of a firewall. This scenario involves opening multiple ports on a firewall to enable Microsoft Office Outlook® 2003 clients to connect using MAPI to an Exchange server, typically over the Internet.

The recommended deployment for using Outlook in Corporate or Workgroup Mode to connect to an Exchange server over the Internet, is to use the remote procedure call (RPC) over HTTP features found in Microsoft Windows Server™ 2003, Exchange Server 2003, Outlook 2003 and Windows® XP Professional.

RPC over HTTP eliminates the need to use a virtual private network (VPN) connection or to open multiple ports on your firewall to allow MAPI access from Outlook 2003 to Exchange Server 2003. A user who runs Outlook 2003 can connect to an Exchange server over the Internet. The RPC client establishes the Internet connection by tunneling the RPC traffic through the HTTP protocol. If the RPC client can make an HTTP/HTTPS connection to a remote computer that is running Internet Information Services (IIS), that RPC client can connect to any server on the remote network. The server on the remote network must be configured to be accessible over the Internet by using RPC over HTTP. Additionally, the RPC client and the RPC server programs can connect across the Internet, even if both programs are behind firewalls that are on different networks.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To remove the TCP/IP NSPI Port registry entry

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Delete the registry value called TCP/IP NSPI Port.

  4. Exit the registry editor and restart Exchange System Attendant Service.

To deploy RPC over HTTP

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review the Microsoft Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  3. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  4. Review the Microsoft Support Web Cast, "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the use of the TCP/IP NSPI Port registry value in a firewall environment, see the Knowledge Base article 270836, "Exchange 2000 and Exchange 2003 Static Port Mappings" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836).


System Attendant service is configured to interact with desktop
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the DesktopInteract property for the Microsoft Exchange System Attendant (MSExchangeSA) service. If the Exchange Server Analyzer finds that the Exchange System Attendant service is configured to interact with the desktop, the Exchange Server Analyzer displays an error.

This configuration should only be used under the guidance of Microsoft Product Support Services. Unless Microsoft Product Support Services has instructed you to run the System Attendant service in this configuration, it is recommended that you reconfigure the System Attendant service properties so that it does not interact with the desktop.

To configure the Exchange System Attendant service account

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. Locate and stop the Microsoft Exchange System Attendant service. Note that stopping the System Attendant service will also stop all services that depend on the System Attendant service. This includes the Microsoft Exchange Information Store service.

  3. Double-click the Microsoft Exchange System Attendant service.

  4. On the Log On tab of the Microsoft Exchange System Attendant Properties page, select Local System account under Log on as.

  5. Clear the Allow service to interact with desktop check box, and then click Apply.

  6. Under Service status, click Start, and then click OK.

  7. Close the Services snap-in.

For more information about the correct Exchange service configuration, see the Microsoft Knowledge Base article 239762, "Exchange Services Run Under LocalSystem" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762).


System Attendant service is not running as LocalSystem
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-01-09

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the StartName property for the Microsoft Exchange System Attendant (MSExchangeSA) service. The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value for the serialNumber attribute on the Exchange Server object in the directory. The serialNumber attribute on the Exchange Server object identifies the version of Exchange Server running on the computer that is represented by the object. If the Exchange Server Analyzer finds that the Exchange System Attendant service is running under any account other than the LocalSystem (SYSTEM) account on an Exchange server running Exchange 2000 Server, Exchange Server 2003, or Exchange Server 2007, the Exchange Server Analyzer displays an error.

This error indicates that the System Attendant service is not running in a supported configuration. If you run the System Attendant service under any other account, you will cause permission and access errors.

To resolve this error, you must configure the Exchange System Attendant service to start up under the LocalSystem (SYSTEM) account.

Note:
This error does not apply to Exchange Server version 5.5. Only Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007 require that the Exchange System Attendant service to run under the LocalSystem account.
To configure the Exchange System Attendant service account

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. Locate and stop the Microsoft Exchange System Attendant service. Note that stopping the System Attendant service will also stop all services that depend on the System Attendant service. This includes the Microsoft Exchange Information Store service.

  3. Double-click Microsoft Exchange System Attendant service.

  4. On the Log On tab of the Microsoft Exchange System Attendant Properties page, select Local System account under Log on as, and then click Apply.

  5. Under Service status, click Start, and then click OK.

  6. Close the Services snap-in.

For more information about running Exchange services under the LocalSystem account, see the Microsoft Knowledge Base article 239762, "Exchange Services Run Under LocalSystem" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762).


TcpTimedWaitDelay Key is Missing or Non-default
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-03-13

The Microsoft Exchange Analyzer tool queries the Active Directory directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 5.5", the computer is running Exchange Server 5.5. If the string value includes "Version 6.0", the computer is running Exchange 2000 Server. If the string value includes "Version 6.5", the computer is running Exchange Server 2003. If the string value includes "Version 8.0", the computer is running Exchange Server 2007.

The Exchange Analyzer tool then reads the following registry branch for each Exchange Server 2007 server found to determine if the value for the TcpTimedWaitDelay key is set to the default value of 60.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

The TcpTimedWaitDelay key determines the time that must elapse before TCP can release a closed connection and reuse its resources. This interval between closure and release is known as the TIME_WAIT state or 2MSL state. During this time, the connection can be reopened at much less cost to the client and server than establishing a new connection.

Reducing the value of this entry allows TCP to release closed connections faster, providing more resources for new connections. However, if the value is too low, TCP might release connection resources before the connection is complete, requiring the server to use additional resources to reestablish the connection.

If the Exchange Analyzer determines that the value for the TcpTimedWaitDelay key is missing or not equal to the default value of 60, the Exchange Analyzer displays a warning.

For optimal performance, we recommended that you set the TcpTimedWaitDelay key to its default value of 60 on Exchange Server 2007 servers.

Important:
This topic contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To set the TcpTimedWaitDelay registry key to its default value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

  3. Double-click the TcpTimedWaitDelay, and set the Value data field to 60 (decimal).

  4. Close the registry editor and restart the computer.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

This issue is related to the MaxUserPort Key is Missing or Non-default Analyzer issue.

For more information about the effect of the MaxUserPort and TcpTimedWaitDelay registry keys, see the "Transmission Control Protocol" topic in the Windows 2000 Resource Kit (http://go.microsoft.com/fwlink/?LinkId=85654).


The TEMP/TMP variable appears to point to an invalid or inappropriate folder
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

On a non-clustered Exchange Server computer, the Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine the value for the TEMP and TMP environment variables:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\TEMP

HKLM\System\CurrentControlSet\Control\Session Manager\Environment\TMP

The Microsoft Exchange Information Store service uses the TEMP and TMP folders as temporary storage during various operations, such as message conversion and mailbox move operations. On a non-clustered Exchange server, the Microsoft Exchange Information Store service uses the SYSTEM (for example, Local System), which uses a default environment variable setting of %Systemroot%\Temp for both TEMP and TMP. If either one or both of the Exchange Server's TEMP or TMP environment variables begin with %SYSTEMROOT, a warning is displayed.

The TEMP and TMP environment variables are used to designate which folders in the file system (which path) should be used by applications that require a temporary workspace. TEMP is typically used by applications, such as Microsoft Exchange and TMP is typically used by development tools, such as Microsoft Visual C++®. The path for each variable is usually relative to the security context of the application or tool.

When the Exchange Server Analyzer is run against an Exchange Virtual Server in a Microsoft Windows Server™ 2003 cluster, it does not read the HKLM registry tree. Instead, it reads the following registry entries:

HKEY_USERS\<Cluster service account SID>\Environment\TEMP

HKEY_USERS\<Cluster service account SID>\Environment\TMP

Exchange Virtual Servers running in a Windows Server 2003 cluster use the environment variable settings for the Cluster Service account, which runs under the context of a specific user security principle. For user accounts, the default environment variable for TEMP and TMP is set to %Userprofile%\temp. If either one or both of the Exchange Virtual Server's TEMP or TMP environment variables begin with %SYSTEMROOT, a warning is displayed.

For optimal performance, it is recommended that you do not use the disk containing the operating system for the TEMP and TMP folders used by Exchange. In addition, you should ensure that these environment variables are set to paths on a fast disk or disk subsystem, such as a RAID 0+1 spindle set. It is also recommended that you do not use the disk containing the operating system for the TEMP and TMP folders used by Exchange or Exchange Virtual Servers.

To correct this warning

  1. Log on to the Exchange server computer with an account that has administrative rights.

  2. Right-click My Computer and select Properties.

  3. Select the Advanced tab.

  4. Click the Environment Variables button.

  5. In the System variables area, select TEMP and click the Edit button.

  6. In the Variable value field, enter the new path for the TEMP environment variable and click OK.

  7. In the System variables area, select TMP and click the Edit button.

  8. In the Variable value field, enter the new path for the TMP environment variable and click OK.

  9. Click OK to close the Environment Variables dialog box and OK once more to close the System Properties dialog box.

  10. Reboot the node to apply the change.

For more information about changing the TEMP/TMP environment variables on a clustered Exchange server, see Cluster TEMP/TMP path is on the same drive as the system partition.


This server has 1 GB or more of physical memory and HeapDeCommitFreeBlockThreshold has not been set to 262144
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-08-14

Error Message

Introduction

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if Exchange has been optimally tuned based on the amount of physical memory in the system:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\HeapDeCommitFreeBlockThreshold

If the Exchange Server Analyzer finds the value for HeapDeCommitFreeBlockThreshold has not been set on an Exchange Server computer with 1 gigabyte (GB) or more of physical memory installed, a warning is displayed.

When memory is freed at a given address, the operating system heap manager checks how many contiguous bytes are free around that address. After that check is complete, the heap manager can do one of two things:

  • Keep the contiguous memory block committed.

  • De-commit the contiguous memory block and mark it as reserved only.

The HeapDeCommitFreeBlockThreshold registry key specifies the number of contiguous bytes above which the memory is de-committed. By default, the heap manager does not necessarily combine all free blocks or make new allocations; therefore, blocks may be de-committed and become useless holes in the virtual address space. This can lead to virtual memory fragmentation, poor performance, and ultimately system instability.

On systems with 1 GB or more of physical memory installed, performance is optimized by controlling the size of the chunks of de-committed memory. The HeapDeCommitFreeBlockThreshold registry key provides control of how the memory is handled as it is freed. When adding this value to the registry, you must configure it with a hexadecimal value of 0x00040000 (262144 in decimal).

Microsoft does not support any other value for the HeapDeCommitFreeBlockThreshold registry key than a hexadecimal value of 0x00040000 (262144 in decimal).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Control\Session Manager

  3. Create a DWORD value called HeapDeCommitFreeBlockThreshold.

  4. Double-click the HeapDeCommitFreeBlockThreshold value and enter a hexadecimal value of 0x00040000 (262144 in decimal).

  5. Close the registry editor and restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the HeapDeCommitFreeBlockThreshold registry key, see the following Knowledge Base articles:

  • 315407, "XADM: The "HeapDeCommitFreeBlockThreshold" Registry Key" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=315407)

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)


This server is running Windows Server 2003 and the SystemPages value is not equal to 0
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the setting for the SystemPages value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages

The Exchange Server Analyzer also queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the OSProductSuite key. The value of this key corresponds to a specific version of a Microsoft Windows operating system.

If the Exchange Server Analyzer finds the value for SystemPages is not set to 0 on an Exchange Server computer that is running Microsoft Windows Server™ 2003 that is not part of a Microsoft Windows Small Business Server 2003 installation, a warning is displayed.

When you are running Exchange Server 2003 Service Pack 1 (SP1) on Microsoft Windows Server 2003 with 1 GB or more of RAM, it is recommended that you set the SystemPages registry key to 0. This recommendation contrasts with the recommendation for Microsoft Windows 2000 Server, which is to set SystemPages to a value between 24000 and 31000.

On a Windows Server 2003 computer that is not part of a Microsoft Windows Small Business Server 2003 installation, you should never set the SystemPages registry value to anything other than 0. Changing it prevents the system from calculating an optimal value for your system and adjusting the value when your system changes.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
Caution:
The ramification for setting the SystemPages registry value on computers running Windows Server 2003 is that the maximum size of the paged pool will be lower. This can lead to paged pool exhaustion and server instability.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. In the right pane, double-click SystemPages.

  4. In the Value data field, type 0, and then click OK.

  5. Exit the registry editor and restart the computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about optimizing memory for Exchange Server, see the following Knowledge Base articles:

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 311901, "The effects of 4GT tuning on System Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


This Exchange server has the /PAE startup switch set in the Boot.ini file
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Windows® Management Instrumentation (WMI) class to determine which options are set in the SystemStartupOptions property. The Exchange Server Analyzer also queries the Active Directory® directory service to determine the count for the homeMDBBL attribute of the mailbox store object (msExchPrivateMDB). The resulting count is the number of mailboxes found on the Exchange Server computer.

If the Exchange Server Analyzer finds that the /PAE startup switch has been set in the boot.ini file on an Exchange server that has fewer than 500 mailboxes, and is running on a Windows 2000 Server, a warning is displayed.

Physical Addressing Extensions (PAE) enable a computer to access more than 4 GB of physical memory (RAM). Exchange Server does not support PAE. PAE enables Windows to access more than 4 gigabytes (GB) of physical memory. Exchange Server cannot use more than 4 GB of physical memory, and there is no benefit to installing more than 4 GB of RAM on a computer that is dedicated to running Exchange Server. PAE is enabled when the /PAE startup switch is present in the Boot.ini file.

To correct this warning for Windows 2000 only, it is recommended that you remove the /PAE switch from the Boot.ini file.

To correct this warning

  1. In Windows Explorer, navigate to the System partition. This is the partition that holds the hardware specific files such as Boot.ini and NTLDR.

  2. If you cannot see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in the Explorer window, click Tools, click Folder Options, and then click View. Click Show hidden files and folders. Clear the Hide protected operating system files (Recommended) check box. When prompted, click Yes.

  3. When the Boot.ini file is visible in Windows Explorer, right-click the file, click Open With, and then click Notepad to open the file.

  4. In the [Operating Systems] section, remove the /PAE switch.

  5. Save and close the file, and restart the Exchange Server computer for the change to take effect.

For more information about the /PAE switch in Boot.ini, see the following Microsoft Knowledge Base articles:

  • 268363: "Intel Physical Addressing Extensions (PAE) in Windows 2000"

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268363)

  • 328882: "Exchange Memory Use and the /3GB Switch"

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328882)


This Exchange server is running with Physical Address Extensions enabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-05-08

The Microsoft® Exchange Server Analyzer Tool queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the values for the following keys:

  • PAEEnabled The value of this key indicates whether Physical Address Extension (PAE) is enabled. A value of True indicates that PAE is enabled and a value of False indicates that PAE is not enabled.

  • Version The value of this key indicates the version of the Microsoft Windows operating system that is running on the computer. A value of 5.0.2195 indicates that a Microsoft Windows 2000 Server operating system is running and a value of 5.2.3790 indicates that a Microsoft Windows Server™ 2003 operating system is running.

  • ServicePackMajorVersion The value of this key indicates the major version number of the installed Windows service pack.

The Exchange Server Analyzer also queries the CIM_Datafile WMI class for the minor version of ntoskrnl.exe running on the system to determine if security update MS04-032 is installed on the computer. If the minor version of ntoskrnl.exe is 174 or less, it indicates that MS04-032 is not installed. If the minor version of ntoskrnl.exe is greater than 174, it indicates that MS04-032 is installed.

If the Exchange Server Analyzer finds the value for PAEEnabled set to True for an Exchange Server running on Windows Server 2003 that does not have security update MS04-032 installed, an error is displayed. This error indicates that the computer is susceptible to a known issue that can cause the Microsoft Exchange Information Store service (Store.exe) to crash.

Exchange Server does not make use of PAE. PAE enables Windows to access more than 4 gigabytes (GB) of physical memory. Exchange Server cannot use more than 4 GB of physical memory, and there is no benefit to installing more than 4 GB of RAM on a computer that is dedicated to running Exchange Server. PAE is enabled when the /PAE startup switch is present in the Boot.ini file on startup or when the Windows Server 2003 operating system detects hot-add memory devices. Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition automatically enable PAE only if the server is using hot-add memory devices.

To correct this error by installing the MS04-032 update

  1. To obtain the MS04-032 update, see the Microsoft Knowledge Base article 840987, "MS04-032: Security update for Microsoft Windows" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=840987).

  2. Completely back up the system.

  3. Apply the update, and then restart the computer for the update to take effect.

For more information about PAE, see the following Knowledge Base articles:

  • 268363: "Intel Physical Addressing Extensions (PAE) in Windows 2000"

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268363)

  • 328882: "Exchange Memory Use and the /3GB Switch"

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328882)

For more information about the /NOPAE switch in Boot.ini, see the MSDN article, "/nopae" (http://go.microsoft.com/fwlink/?LinkId=51490).


This Exchange server is running with Physical Address Extensions enabled and the /3GB Startup Switch
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the PAEEnabled key. The value of this key indicates whether Physical Address Extension (PAE) is enabled. A value of True indicates that PAE is enabled, and a value of False indicates that PAE is not enabled. The Exchange Server Analyzer also queries the Win32_OperatingSystem WMI class to determine the value for the MaxProcessMemorySize key.

If the Exchange Server Analyzer finds the value of PAEEnabled equal to True and the value for MaxProcessMemorySize to be greater than 2097024, a warning is displayed. This warning indicates that these values are not the default values. The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about PAE, see the following Microsoft Knowledge Base articles:

  • 268363: "Intel Physical Addressing Extensions (PAE) in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268363)

  • 328882: "Exchange Memory Use and the /3GB Switch" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328882)


This Exchange server is running with the /PAE and /3GB Startup Switches
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine which options are set in the SystemStartupOptions key. The Exchange Server Analyzer also queries the Win32_OperatingSystem WMI class to determine the value for the MaxProcessMemorySize key.

If the Exchange Server Analyzer finds that the value for the SystemStartupOptions key includes /PAE, the Win32_OperatingSystem value indicates Microsoft Windows 2000 Server, and the value for MaxProcessMemorySize is greater than 2097024, an error is displayed.

This error indicates that the /PAE and /3GB startup switches have both been set in the Boot.ini file. Physical Address Extension (PAE) enables a computer to access more than 4 gigabytes (GB) of physical memory (RAM). Exchange Server does not support PAE. Exchange Server cannot use more than 4 GB of physical memory, and there is no benefit to installing more than 4 GB of RAM on a computer that is dedicated to running Exchange Server. PAE is enabled when the /PAE startup switch is present in the Boot.ini file on startup.

To correct this error for Windows 2000 Server only, it is recommended that you remove the /PAE switch from the Boot.ini file.

To correct this error

  1. In Windows Explorer, navigate to the System Partition. This is the partition that holds the hardware specific files such as Boot.ini and NTLDR.

  2. If you cannot see the Boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in the Windows Explorer window, click Tools, click Folder Options, and then click View. Click Show hidden files and folders. Clear the Hide protected operating system files (Recommended) check box. When prompted, click Yes.

  3. When the Boot.ini file is visible in Windows Explorer, right-click the file, click Open With, and then click Notepad to open the file.

  4. In the [Operating Systems] section, remove the /PAE switch.

  5. Save and close the file, and then restart the Exchange Server computer for the change to take effect.

For more information about the /PAE switch in Boot.ini, see the following Microsoft Knowledge Base articles:

  • 268363, "Intel Physical Addressing Extensions (PAE) in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268363)

  • 328882, "Exchange Memory Use and the /3GB Switch" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328882)


This front-end server is configured with the recipient update service
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchAddressListServiceLink attribute for each Recipient Update Service object in the directory. The msExchAddressListServiceLink attribute is a link from the address list service to an Exchange Server computer that is running the Recipient Update Service (RUS). The Exchange Server Analyzer displays an error if the following conditions are true:

  • The Exchange Server is configured as a front-end server.

  • The Exchange Server computer is running the Recipient Update Service.

The Recipient Update Service is a component in the Exchange System Attendant service. The Recipient Update Service creates and maintains Exchange-specific attribute values in Active Directory. If you create a mailbox for a user, the Recipient Update Service is responsible for the automatic generation of their Simple Mail Transfer Protocol (SMTP) address and any other proxy addresses that you have defined in your recipient policies.

When an Exchange Server that is configured to use the Recipient Update Service is also configured as a front-end server, newly created user objects are not processed by the Recipient Update Service. The result is that user objects may not receive e-mail addresses and the recipients are not displayed in the address list). Also, updates to the offline address book are not processed.

If you receive this message, the Recipient Update Service is running on an Exchange Server configured as a front-end server.

To correct this error

  1. Open Exchange System Manager.

  2. Under Recipients, click Recipient Update Services. In the right pane, right-click the appropriate instance of the Recipient Update Service, and then click Properties.

  3. On the General tab, under Exchange Server, click Browse, and then specify a new server to run this RUS instance.

  4. Click OK, and then click OK again for the change to take effect.

For more information about Recipient Update Service, see the following topic and Microsoft Knowledge Base articles:

  • 328738, "How the Recipient Update Service applies recipient policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738).

  • 253828, "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828).

  • 246127, " How to check the progress of the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127).

  • 253770, "XADM: Tasks Performed by the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770).


There is a discrepancy with the Exchange server name between the registry and Active Directory
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-12-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value stored in Active Directory for the name of the Exchange server (CN=<ExchangeServerName>). After retrieving this name, the Exchange Server Analyzer counts the number of characters in the name.

The Exchange Server Analyzer also reads the following registry entry to determine the value stored in the Exchange Server computer's registry for the host name of the Exchange server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Hostname

Additionally, the Exchange Server Analyzer also queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for ClusSvc, the Cluster service.

If the Exchange Server Analyzer determines that the following criteria are all true, an error is displayed:

  • The value for CN=<ExchangeServerName> does not match the value for Hostname.

  • The Exchange server name is 15 characters or less.

  • The Exchange server is not running in a Windows cluster.

The most common cause of this error is that the name of the Exchange server has been changed. Changing the name this way changes the name in the computer registry, and it changes the name for the computer account in Active Directory, but it does not change the many references to the Exchange server name that are found throughout Exchange attributes and objects in Active Directory.

Note:
Some third-party software will also change the computer name to provide clustering functionality. If you are using such software, you may have to ignore this issue.

Renaming an Exchange Server computer is not supported and is known to cause problems, such as a failure to start the Microsoft Exchange System Attendant service after the computer name has been changed. If the renamed Exchange Server computer does not appear to be functioning correctly in all respects, you can manually remove Exchange Server from the computer using the manual removal process outlined in this article. If the renamed Exchange Server computer does appear to be functioning correctly in all respects, you should rebuild the Exchange server using the rebuild procedure below because this is an unsupported configuration and may cause problems in the future.

To correct this error by performing a manual removal of Exchange Server

  1. Stop all Exchange Server services and completely back up the computer.

  2. Depending on which version of Exchange Server you are running, see the following Microsoft Knowledge Base article:

    • If you are running Exchange Server 2007, follow the procedure outlined in the Exchange Server 2007 documentation, "How to Completely Remove Exchange 2007 from a Server" (http://go.microsoft.com/fwlink/?LinkId=79246).

    • If you are running Exchange Server 2003, follow the procedure outlined in the Knowledge Base article 833396, "How to remove Exchange Server 2003 from your computer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833396).

    • If you are running Exchange 2000 Server, follow the procedure outlined in the Knowledge Base article 260378, "How to manually remove an Exchange 2000 installation" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260378).

  3. If you are running Exchange 2000 Server or Exchange Server 2003 and this is the only Exchange server in your organization, follow the procedure outlined in the Knowledge Base article 273478, "How to completely remove Exchange 2000 or Exchange 2003 from Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=273478).

To correct this error by rebuilding the Exchange Server computer

  1. Move mailboxes, public folders, connectors, and roles to another Exchange Server computer in the organization.

  2. Uninstall Exchange Server from the computer.

  3. To clean up the registry on a computer running Exchange Server 2003 or Exchange Server 2000, follow the registry cleaning sections of the procedures outlined in the following Microsoft Knowledge Base articles:

    • 833396, "How to remove Exchange Server 2003 from your computer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833396)

    • 260378, "How to manually remove an Exchange 2000 installation" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260378)

    Alternatively, you can rebuild the operating system.

  4. Install Exchange Server on the computer.

  5. Move mailboxes, public folders, connectors, and roles to the newly built Exchange Server computer.

For more information about how to deploy Exchange Server 2003 on clusters, see the Microsoft Knowledge Base article 810986, "Microsoft support policy for Exchange Server installations that are running with a third-party Cluster service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810986).


There is a discrepancy with the Exchange server name in Active Directory
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-12-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the Name attribute and the cn attribute of a server (object of class msExchExchangeServer) match. If the Exchange Server Analyzer finds that these attributes differ, an error message is displayed.

Exchange uses the cn value of the server object to identify the server internally. It uses the Name value to identify the server in the Microsoft Exchange System Manager user interface.

This error can occur if an administrator changed the Name value using a tool such as Active Directory Service Interfaces (ADSI) Edit or the LDP (ldp.exe) tool. While this action does change the server name in the user interface, it creates a discrepancy that generates store and system attendant events. You must correct the value using a tool such as the ADSI Edit snap-in, the LDP tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007 or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Using ADSI Edit or a similar tool, locate the server object in Active Directory.

    The CN and Name attribute can be found at:

    Copy Code
    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group,CN=Servers,CN=Server

  2. For the Name attribute, type a new string value that matches the value of the CN attribute.

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in the Windows Server Help.


There is more than one network between the Active Directory server and this Exchange server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the WIN32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class in the root\cimv2 namespace to determine the value for the RouteRecord key. The RouteRecord key contains a record of intermediate hops (for example, the number of routers) between the Exchange server and the domain controller. The Exchange Server Analyzer takes a count of the number of routers listed in the RouteRecord key. If the Exchange Server Analyzer finds more than one router is listed, an error is displayed.

An optimal Active Directory® directory service is one that the design ensures that the Exchange Server computer can communicate with a domain controller or global catalog server on its subnet. This error indicates that the Exchange Server computer is communicating with domain controllers on networks that are more than one hop away.

To correct this error

  1. Check your network topology and re-evaluate the placement of Active Directory servers.

  2. Monitor the event logs on the Exchange Server and the domain controller to see if any network-related events have been logged that indicate potential problems.

  3. Investigate the Active Directory site design. If your network is not partitioned according to this specification, consider partitioning the network into more Active Directory sites.

For more details about the Win32_PingStatus WMI class, see the MSDN article, "Win32_PingStatus" (http://go.microsoft.com/fwlink/?linkid=33549).

For more information about Active Directory site design, see "Designing the Site Topology" (http://go.microsoft.com/fwlink/?linkid=33551).


Too many hops
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-07-06

The Microsoft® Exchange Server Analyzer Tool sends a test message from the Exchange server to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain and then scans the message tracking logs of the server to determine whether there were issues with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer queries the MessageID property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace for each server the message travels to.

A message can be routed through many different SMTP servers before the message reaches its final destination. Each server on this route is referred to as a hop.

If the number of Exchange_MessageTrackingEntry instances for the specific MessageID grows to 30, the Exchange Server Analyzer displays an error.

This error indicates that the test message may be traveling in a loop. Therefore, the Exchange Server Analyzer has stopped querying additional Exchange_MessageTrackingEntry instances as a safety precaution against a possible infinite loop situation.

Additional analysis of the Message Tracking Log section of the Exchange Server Analyzer output may help you determine whether a loop condition exists.


Unsupported virtual machine configuration - clustered Exchange Server detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine whether the value for the Model key is set to "Virtual Machine".

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine the value of the Started key for ClusSvc, the Windows Cluster service. A value of True for the Started key indicates the Cluster service is started, and a value of False indicates the Cluster service is not started.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The value for the Model key is set to "Virtual Machine".

  • The value of the Started key for the Cluster service is set to True.

This error indicates that the Exchange server is a clustered Exchange server that is running in a virtual machine environment. This configuration is not supported.

To correct this error

  1. Build a physical cluster and move the mailboxes to the physical cluster from the clustered Exchange server that is running in the virtual environment.

  2. If you cannot build a physical cluster, you can correct this error as follows:

    1. Move the mailboxes from the Exchange Server that is running in the virtual environment to a non-virtual, stand-alone Exchange Server computer.

    2. Re-home any public folders and transfer any roles performed by the clustered Exchange server as required.

    3. Uninstall Exchange Server from the virtual machine to decommission and remove it from the Exchange Server infrastructure and from Active Directory.

For more information about Microsoft support policy for running Exchange Server 2003 in virtual environments, see Microsoft Knowledge Base article 320220, "Support policy for Exchange Server 2003 running on hardware virtualization software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220).


Unsupported virtual machine configuration - Exchange Server 2003 Service Pack 2 or later not detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine whether the value for the Model key is set to "Virtual Machine."

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 5.5", the computer is running Exchange Server 5.5. If the string value includes "Version 6.0", the computer is running Exchange 2000 Server. If the string value includes "Version 6.5", the computer is running Exchange Server 2003. If the string value includes "Version 6.5" and "Service Pack 2", the computer is running Exchange Server 2003 with Service Pack 2 (SP2).

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The Model key is set to "Virtual Machine".

  • The computer is not running Exchange Server 2003 with SP2 or a later version.

This error indicates that the Exchange server is a virtual machine but Exchange Server 2003 SP2 or a later version is not installed. This configuration is not supported.

To correct this error

  1. Install Service Pack 2 or a later version for Exchange Server 2003.

  2. Review Microsoft Knowledge Base article 320220, "Support policy for Exchange Server 2003 running on hardware virtualization software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220).

  3. If you cannot apply Service Pack 2 or a later version, you can correct this error as follows:

    1. Move the mailboxes from the Exchange Server That Is Running under Virtual Server 2005 to a non-virtual Exchange Server computer.

    2. Re-home any public folders and transfer any roles performed by the virtual Exchange server as required.

    3. Uninstall Exchange Server from the virtual machine to decommission and remove it from the Exchange Server infrastructure and from Active Directory.


Unsupported virtual machine configuration - virtual machine additions not detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine whether the value for the Model key is set to "Virtual Machine".

The Exchange Server Analyzer also reads the following registry entry to determine whether virtual machine additions have been installed:

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

The presence of this registry path indicates that virtual machine additions have been installed. If this registry path is not present it indicates that virtual machine additions have not been installed.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The value for the Model key is set to "Virtual Machine".

  • This registry path is not present.

This error indicates that the Exchange server is a virtual machine but that the virtual machine additions are not installed. This configuration is not supported.

To install virtual machine additions

  1. Back up the Exchange Server that is running in the virtual environment.

  2. Install the Virtual Machine Additions using the Virtual Server 2005 administrative console or Web site.

For more information about how to run Exchange Server 2003 in a virtual environment, see Microsoft Knowledge Base article 320220, "Support policy for Exchange Server 2003 running on hardware virtualization software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220).


Update for Daylight Saving Time Available
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-07-30

The Microsoft Exchange Analyzer Tool queries the Active Directory directory service to determine the value of the versionNumber attribute for each Exchange Server object. The versionNumber attribute represents the version of Exchange Server that is running on the computer.

The Exchange Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the Store.exe process.

  • A value of 7638 for the Version key indicates Exchange Server 2003 Service Pack 2

  • A value of 7226 for the Version key indicates Exchange Server 2003 Service Pack 1

  • A value of 6944 for the Version key indicates the original release of Exchange Server 2003

  • A value in between the versions above indicates that the server is running a hotfix update version of the Store.exe process.

If the Exchange Analyzer determines that the Version key for Store.exe on a server running Exchange Server 2003 SP2 has a value less than 7561, or a server running Exchange Server 2003 SP1 has a value less than 7234, a warning is displayed.

This warning indicates that the Exchange Server computer is running Exchange Server 2003 Service Pack 1 or Exchange Server 2003 SP2 without the update for daylight saving time changes in 2007.

Without this update, calendar items in CDO-based programs and in Outlook Web Access will operate as if standard time is in effect during the extra weeks of daylight saving time.

To correct this for Exchange Server 2003 SP2

  1. Follow the guidance in Microsoft Knowledge Base article 926666, "Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=926666).
To correct this for Exchange Server 2003 SP1

  1. Follow the guidance in Microsoft Knowledge Base article 931978, "Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=931978)


Update Rollup for Windows 2000 SP4 not installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the ServicePackMajorVersion key. The Exchange Server Analyzer also examines the following registry entry to determine the version of Windows that is running on the destination computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

If the Exchange Server Analyzer determines that the target system is running a Windows 2000 Server operating system but is not running the Update Rollup for Windows 2000 Server Service Pack 4, a warning is displayed.

As a best practice, it is recommended that you install the latest service packs and rollups for all software in the Exchange deployment.

To correct this warning

  1. Update all domain controllers and global catalog servers that are running Windows 2000 Server to the Update Rollup for Service Pack 4, plus the latest hotfixes and updates from Windows Update.

  2. Update all Exchange Server computers to the latest rollup and update rollup.

For more information about the Update Rollup for Windows 2000 SP4, see the Microsoft Knowledge Base article 891861, "Update Rollup 1 for Windows 2000 SP4" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=891861).

For more information about how to obtain and install Exchange Server service packs and rollups, see the Exchange Server Web site (http://go.microsoft.com/fwlink/?LinkId=21573).


URLScan is installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-20

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine whether the following file exists in the following location on the Exchange server:

%WINDOWSPATH%\\SYSTEM32\\INETSRV\URLSCAN\URLSCAN.DLL

The presence of Urlscan.dll indicates that the URLScan tool is installed on the Exchange server. If the Exchange Server Analyzer finds that the URLScan tool is installed on an Exchange server, a best practice recommendation is displayed.

URLScan is an Internet Server Application Programming Interface (ISAPI) filter that allows Web site administrators to restrict the kind of HTTP requests that the server processes. By blocking specific HTTP requests, the URLScan filter prevents potentially harmful requests from reaching the server and causing damage.

When you run URLScan on an Exchange server, you should ensure that Urlscan.ini is tuned for an Exchange server's role. To help enhance the security of the Exchange server, you must edit the Urlscan.ini configuration file to remove any extraneous functionality. To customize the Urlscan.ini file for your particular Exchange Server 2003 computer role, you must remove verbs in the [AllowVerbs] section of the Urlscan.ini file. However, make sure that the recommended verbs for your computer's role are included to obtain appropriate functionality. If multiple Web-based features are required on a single computer, you must merge the appropriate [AllowVerbs] section requirements.

You can modify the Urlscan.ini file based on the Exchange Server 2003 computer's role by using the information from the Exchange Server 2003 Urlscan template that is included in the Microsoft Knowledge Base article 823175, "Fine-tuning and known issues when you use the Urlscan utility in an Exchange 2003 environment" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823175).

For more information about URLScan, see "UrlScan Security Tool" (http://go.microsoft.com/fwlink/?LinkId=24490).

For more information about using URLScan in an Exchange Server environment, see the following Microsoft Knowledge Base articles:

  • 309677, "XADM: Known Issues and Fine Tuning When You Use the IIS Lockdown Wizard in an Exchange 2000 Environment" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=309677)

  • 309508, "IIS lockdown and URLscan configurations in an Exchange environment" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=309508)

  • 325965, "The URLScan tool may cause problems in Outlook Web Access" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325965)

  • 326444, "How to configure the URLScan Tool" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=326444)


USERVA is set incorrectly
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-09-19

The Microsoft® Exchange Server Analyzer Tool queries three Microsoft Windows® Management Instrumentation (WMI) classes to determine the amount of physical memory in the Exchange Server computer and the amount of virtual address space allocated to user mode processes running on the Exchange Server computer. The table below describes the classes and keys being evaluated by the Exchange Server Analyzer.

Class Queried | Keys Queried | Description
Win32_OperatingSystem | MaxProcessMemorySize | Maximum number of kilobytes of memory that can be allocated to a process.
Win32_ComputerSystem | TotalPhysicalMemory | Number of bytes of random access memory (RAM) installed on the computer.
Win32_Service | Started | State of the service. A value of True indicates the service is running and a value of False indicates the service is not running.

The Exchange Server Analyzer also reads the following registry entry to determine the version of Microsoft Windows running on the Exchange Server computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the Exchange Server computer is running on Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the Exchange Server computer is running Windows 2000 Server and a value of 5.2 indicates the Exchange Server computer is running Windows Server™ 2003.

Finally, the Exchange Server Analyzer queries the Active Directory® directory service to determine the count for the homeMDBBL attribute of the mailbox store object (msExchPrivateMDB). The resulting count is the number of mailboxes found on the Exchange Server computer.

If the Exchange Server Analyzer determines that all of the following criteria are true, a warning is displayed:

  • The Exchange Server computer is running on Windows Server 2003.

  • The value for TotalPhysicalMemory is greater than 1073741824.

  • The value for MaxProcessMemorySize is equal to 3145600.

  • The Cluster service (ClusSvc) has a Win32_Service\Started value of True or the Exchange Server computer contains more than 20 mailboxes.

This warning indicates that the Exchange Server computer is not optimally configured for virtual memory usage. Specifically, the /USERVA=3030 startup switch is not present in the Boot.ini file of the Exchange Server computer. Adding this switch may provide greater scalability and better performance.

Windows Server 2003 includes support for two Boot.ini startup switches—/3GB and /USERVA—that enable you to tune the allocation and use of memory and memory address space. Regardless of the amount of physical memory in your system, Windows uses a virtual address space of 4 gigabytes (GB), with 2 GB allocated to user-mode processes (for example, applications) and 2 GB allocated to kernel-mode processes (for example, the operating system and kernel-mode drivers). On systems that have 1 GB or more of physical memory, these startup switches can be used to allocate more memory to applications (3 GB) and less memory to the operating system (1 GB). On an Exchange Server computer, this extra virtual address space helps to reduce the amount of memory fragmentation in the information store process virtual address space. The /3GB switch is used to affect this allocation change. The switch is entered into the system's Boot.ini file and takes effect after a reboot. This switch should only be used on Exchange Servers with 1 GB or more of memory that are running any of the following operating systems:

  • Microsoft Windows Server 2003, Standard Edition

  • Microsoft Windows Server 2003, Enterprise Edition

  • Microsoft Windows Server 2003, Datacenter Edition

Important:
The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the above operating systems when 1 GB or more of physical memory is installed. In addition, the /3GB switch should not be used on Active Directory servers (domain controllers and global catalog servers) running on Windows Server 2003, Standard Edition.

The /USERVA switch is new to Windows Server 2003. Its purpose is to provide a finer level of control over the division of virtual address space between user-mode processes and kernel-mode processes. This switch should be used only for applications that support it, such as Exchange Server 2003, and with the specific values supported by those applications. When used on Exchange Server 2003 systems, /USERVA should always equal 3030 (that is, /USERVA=3030). This value causes an additional 40 MB to be allocated to the operating system, and enables you to add more users without consuming all available system resources.

To correct this warning on Windows Server 2003

  1. Right-click My Computer and select Properties. The System Properties dialog box will appear.

  2. Click the Advanced tab.

  3. In the Startup and Recovery area, click Settings. The Startup and Recovery dialog box will appear.

  4. In the System startup area, click Edit. This will open the Windows Boot.ini file in Notepad.

  5. In the [Operating Systems] section, add the following switches to the startup line: /3GB /USERVA=3030

  6. Save the changes and close Notepad.

  7. Click OK twice to close the open dialog boxes, and then reboot the Exchange Server computer for the change to take effect.

For more information about the use of the /3GB and /USERVA startup switches, see the following Microsoft Knowledge Base articles:

  • 297812, "How to Use the 4GT RAM Tuning Feature" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812).

  • 311901, "The effects of 4GT tuning on system Page Table Entries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901).

  • 316739, "How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739).

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044).

  • 815372, "How to Optimize Memory Usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372).


The version of the Tcpip.sys file installed on this computer may require a hotfix
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value that is set for the Version key of the Tcpip.sys file. If the Exchange Server Analyzer finds that the value for the Version key corresponds to a specific version of the Tcpip.sys file, the Exchange Server Analyzer displays a warning.

For more information about this warning, follow the recommendations in the Microsoft Knowledge Base article 898060, "Installing security update MS05-019 or Windows Server 2003 Service Pack 1 may cause network connectivity between clients and servers to fail" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=898060).


Virtual machine configuration detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine whether the value for the Model key is set to "Virtual Machine".

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine the value of the Started key for ClusSvc, the Windows Cluster service. A value of True for the Started key indicates that the Cluster service is started. A value of False indicates that the Cluster service is not started.

The Exchange Server Analyzer queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 6.5" and "Service Pack 2", the computer is running Exchange Server 2003 with Service Pack 2 (SP2).

Finally, the Exchange Server Analyzer reads the following registry entry to determine whether virtual machine additions have been installed:

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

The presence of this registry path indicates that virtual machine additions have been installed. The absence of this registry path indicates that virtual machine additions have not been installed.

The Exchange Server Analyzer displays a best practice message if the following conditions are true:

  • The Exchange server is running as a guest under Microsoft Virtual Server 2005.

  • The Exchange server is running Exchange Server 2003 with Service Pack 2 or a later version.

  • The Exchange server is not clustered.

  • The Virtual Machine Additions for Virtual Server 2005 have been installed on the Exchange server.

There are some requirements for running in this configuration that the Exchange Server Analyzer cannot detect. Therefore, we recommend that you review the following article for the latest information about supportability and performance tuning for this configuration before you run Exchange Server 2003 in a Virtual Server 2005 environment:

Microsoft Knowledge Base article 320220, "Support policy for Exchange Server 2003 running on hardware virtualization software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220).


Virtual memory is fragmented
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2007-02-15

The Microsoft Exchange Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows Management Instrumentation (WMI) class to determine whether an Event 9582 error has been logged for MSExchangeIS within the last 24 hours.

If the Exchange Analyzer finds that an Event 9582 has been logged in the past 24 hours, the Exchange Analyzer displays an error.

This error indicates that the virtual memory that is required to run the Exchange server is fragmented.

In 32-bit Microsoft Windows systems, there are two kinds of memory:

  • Physical memory Amount of actual memory installed in the system

  • Virtual memory address space A virtualized 4-GB memory space

Regardless of how much physical memory is installed on the system, the total size of the virtual address space is always the same: 4 GB. Although it is not the case for all 32-bit applications, for Exchange Server, virtual address space equals virtual memory. The terms are used interchangeably.

During the normal course of its operations, the Exchange store will repeatedly allocate, use, and deallocate virtual memory. When virtual memory is allocated, used, and deallocated frequently, virtual memory fragmentation can result. Virtual memory fragmentation is similar to file system fragmentation that can occur over time. After a while, allocated segments of virtual memory are no longer contiguous, and performance begins to suffer. In the file system, you can run an application that performs defragmentation of the file system. In most cases, defragmentation of the file system can be done while the system is online and being accessed. With virtual memory fragmentation, there is no defragmentation tool. Instead, to correct the problem, you must stop and start the Microsoft Exchange Information Store service or restart the system.

To address this issue:

  • Virtual memory fragmentation can be caused by third-party software running in the store/inetinfo processes. Make sure that you have the latest drivers for any third-party applications.

  • Use the Performance Logs and Alerts tool to monitor the VM Total Large Free Block Bytes counter for the MSExchangeIS performance object. Use the data collect from this counter to determine the best window, within the next 36 to 72 hours, to shut down and then restart the server.

Note:
If this is a clustered server, stop and restart the passive node before you move cluster resources to it to make sure that the target virtual memory address space is clean.
  • If the problem is reproduced after restarting, consider disabling third-party software.

  • Consider moving user mailboxes to another server to reduce server load and see whether the problem stops. For more information, see Move User Mailboxes to Another Server.

For More Information

  • For more information about MSExchangeIS Event 9852, see the "Events and Errors Message Center: Event Details" (http://go.microsoft.com/fwlink/?LinkId=83209).

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about how to troubleshoot Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about how to troubleshoot virtual memory fragmentation in Microsoft Exchange Server 2003 and Exchange 2000 Server, see Microsoft Knowledge Base article 325044, "How to troubleshoot virtual memory fragmentation in Exchange Server 2003 and Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044).

  • For more information about how to optimize virtual memory usage, see Microsoft Knowledge Base article 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372).

  • For more information about how to move user mailboxes to reduce server load, see Move User Mailboxes to Another Server.


Virtual Server 2005 R2 or later not detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for Vssrvc.exe, the process represented by the Virtual Server service included with Microsoft Virtual Server 2005. If the Exchange Server Analyzer finds the value of the Version key for Vssrvc.exe equal to 1.1.465.0, the Exchange Server Analyzer displays an error.

This error indicates that this Exchange server is running as a guest in a Microsoft Virtual Server 2005 environment that is not running Virtual Server 2005 R2 or a later version. This configuration is not supported. Exchange Server 2003 with Service Pack 2 or a later version is only supported as a guest in a virtual environment when it runs under Microsoft Virtual Server 2005 R2 or a later version.

To correct this error

  1. Review Microsoft Knowledge Base article 320220, "Support policy for Exchange Server 2003 running on hardware virtualization software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220).

  2. Install Microsoft Virtual Server 2005 R2 or a later version. For information about Microsoft Virtual Server 2005 R2, see the Microsoft Virtual Server 2005 R2 Web site (http://go.microsoft.com/fwlink/?LinkId=34938).

  3. If you cannot install Virtual Server 2005 R2 or a later version, you can correct this error as follows:

    1. Move the mailboxes from the Exchange Server that is running under Virtual Server 2005 to a non-virtual Exchange Server computer or to a virtual Exchange Server computer that is running under Virtual Server 2005 R2.

    2. Re-home any public folders and transfer any roles performed by the unsupported virtual Exchange server as required.

    3. Uninstall Exchange Server from the unsupported virtual machine to decommission and remove it from the Exchange Server infrastructure and from Active Directory.


Virus Scan queue length beyond threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-27

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Virus Scan Queue Length performance counter of the MSExchangeIS performance object to analyze performance data.

If the Exchange Server Analyzer determines that the 90th percentile value for the Virus Scan Queue Length counter is greater than 10 during the sample time slice, the Exchange Server Analyzer displays an error.

The Virus Scan Queue Length performance counter indicates the current number of outstanding requests that are queued for virus scanning.

This error can indicate performance issues related to the following:

  • Decreased server performance, usually caused by a CPU bottleneck.

  • Larger than usual server load.

  • An out-of-date virus scanning engine.

  • An incorrectly configured virus scanning engine.

To resolve this error, take the following steps:

  • Look for updates for your virus engine.

  • Consider re-installing the virus scanning software.

  • Examine the configuration of your virus scanning engine for the correct thread configuration, file level exclusions, etc. See Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&k b id=823166).

  • Use the Performance Monitor (Perfmon.msc) tool to determine whether the bottleneck is caused by an increased load on the server or whether the server is undersized. If the server load has increased, identify the source of the load and reduce it. If the server has insufficient resources, increase the necessary resources or, move users off the server.

Removing Processor Bottlenecks

There are many ways to remove processor bottlenecks from your Exchange server.

  • First, review the applications or tasks that are causing load on the server. Determine whether the application should be using the processor time that it is or whether there might be an issue with the process.

  • If a non-Exchange application is not important to that server, run that application on another server. If you can run that application on another server, move server roles to other computers also. For example, if the Inetinfo process is using lots of CPU utilization, consider adding front-end servers to assume responsibility for the protocol work that Inetinfo performs. You can also move public folder access to a dedicated public folder server. Finally, if a server performs lots of distribution list expansions, you can reduce CPU utilization by moving distribution list expansion to a dedicated distribution-list expansion server.

  • Add more or faster processors to the server if you can. Also, enable hyper-threading if it is supported by the processors. You can enable hyper-threading by configuring the system BIOS. For more information, see the computer manufacturer's Help documentation.

  • If increasing the processing power is not a workable option, you must reduce the load on the processors. To reduce the overall effect on the server, make sure that I/O-intensive, CPU-intensive, or memory-using tasks occur outside ordinary operation hours.

  • Make sure that CPU-intensive tasks, such as backup and maintenance, occur during off-peak hours. Also, make sure and that these tasks are performed in a staged manner. Staging a task means setting different start times and, preferably, end times for each task. Staging the maintenance and backup of databases or storage groups also lessens the effect of these resource-intensive tasks.

For More Information

  • For an overview of Exchange Server and virus scanning, see Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • For more information about virus scanning and Exchange Server, see Microsoft Knowledge Base article 285667, "XADM: Understanding Virus Scanning API 2.0 in Exchange 2000 Server SP1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=285667).

  • For more information about processor bottlenecks, see Processor Bottleneck.

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about how to move user mailboxes to reduce server load, see Move User Mailboxes to Another Server.


Virus Scan queue length beyond warning threshold
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-04-20

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Virus Scan Queue Length performance counter of the MSExchangeIS performance object to analyze performance data.

If the Exchange Server Analyzer determines that the 90th percentile value for the Virus Scan Queue Length counter is greater than 5 during the sample time slice, the Exchange Server Analyzer displays a warning.

The Virus Scan Queue Length performance counter indicates the current number of outstanding requests that are queued for virus scanning.

This warning indicates that performance may become an issue for this server. The performance issues could be related to the following:

  • Decreased server performance, usually caused by an emerging CPU bottleneck.

  • Higher than usual server load.

  • An out-of-date virus scanning engine.

  • An incorrectly configured virus scanning engine.

To address this warning, take the following steps:

  • Look for updates to your virus engine.

  • Consider re-installing the virus scanning software.

  • Examine the configuration of your virus scanning engine for the correct thread configuration, file level exclusions, etc. See Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • Use the Performance Monitor (Perfmon.msc) tool to identify if the emerging bottleneck is caused by an increase load on the server or whether the server is undersized. If the server load has increased, identify the source of the load and reduce it. If the server has insufficient resources, increase the necessary resources or move users off the server.

Removing Processor Bottlenecks

There are many ways to address processor bottlenecks on your Exchange server:

  • First, review the applications or tasks that are causing load on the server. Determine if the application should be using the processor time that it is or if there might be an issue with the process.

  • If a non-Exchange application is not important to that server, run that application on another server. If you can, move server roles to other computers also. For example, if the Inetinfo process is using lots of CPU utilization, consider adding front-end servers to assume responsibility of the protocol work that Inetinfo performs. You can also move public folder access to a dedicated public folder server. Finally, if a server performs lots of distribution list expansions, you can reduce CPU utilization by moving distribution list expansion to a dedicated distribution-list expansion server.

  • Add more or faster processors to the server if you can. Also, enable hyper-threading if it is supported by the processors. You can enable hyper-threading by configuring the system BIOS. For more information, see the computer manufacturer's Help documentation.

  • If increasing the processing power is not a workable option, you must reduce the load on the processors. To reduce the overall effect on the server, make sure that I/O-intensive, CPU-intensive, or memory-consuming tasks occur outside ordinary operation hours.

  • Make sure that CPU-intensive tasks, such as backup and maintenance, occur during off-peak hours. Also make sure and that these tasks are performed in a staged manner. Staging a task means setting different start times, and preferably end times, for each task. Staging the maintenance and backup of databases or storage groups also lessens the effect of these resource-intensive tasks.

For More Information

  • For an overview of Exchange Server and virus scanning, see Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • For more information about virus scanning and Exchange Server, see Microsoft Knowledge Base article 285667, "XADM: Understanding Virus Scanning API 2.0 in Exchange 2000 Server SP1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=285667).

  • For more information about processor bottlenecks, see Processor Bottleneck.

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about how to move user mailboxes to reduce server load, see Move User Mailboxes to Another Server.


Volume Mount Point Failure: Windows Server 2003 SP1 not Installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Windows® Management Instrumentation (WMI).to verify that the Mountmgr.sys driver exists.

The Exchange Server Analyzer then reads the following registry value to determine which version of the Microsoft Windows® operating system is running on the Exchange server: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

If the CurrentVersion value equals 5.0, the Exchange server is running on Microsoft Windows 2000 Server. If the CurrentVersion value is 5.2, the Exchange server is running on Microsoft Windows Server™ 2003.

The Exchange Server Analyzer also queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Cluster service (ClusSvc). A value of TRUE indicates the Cluster service is started, and a value of FALSE indicates the Cluster service is not running.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • The Exchange Server computer is running on Windows Server 2003.

  • Windows Server 2003 SP1 is not installed.

  • The Exchange Server runs in a clustered environment.

  • Volume mount points exist.

The warning indicates that if the Exchange cluster node environment is upgraded to Windows Server 2003 SP1, you will require the update referenced in the following section. Without this update you may experience volume mount point failures after the upgrade.

To correct this warning

  • Apply the update referred to in Microsoft Knowledge Base article 898790, "Volume mount points on disks in a server cluster may intermittently become unavailable after you install Windows Server 2003 Service Pack 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=898790).


Windows Firewall Service is Enabled on Exchange Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Windows Firewall service (SharedAccess). A value of True indicates that Windows Firewall service is enabled on this Exchange server.

If the Exchange Server Analyzer determines that the Windows Firewall service is enabled on an Exchange Server computer, a warning is displayed. When the Windows Firewall service is enabled, the following problems may occur:

  • Some components of Exchange Server, such as the Message Tracking Service or remote procedure call (RPC) communication, may stop responding.

  • You may receive an error message that states low available memory.

By default, the Windows Firewall service is stopped when Microsoft Windows Server™ 2003 Service Pack 1 (SP1) is applied. However, the service is automatically set to run if either of the following conditions are true:

  • An administrator manually enables the Windows Firewall service.

  • You enable the Windows Firewall service after you run the Security Configuration Wizard.

To correct this warning

  • Check program exclusions.

  • Check port exclusions.

  • Check firewall exceptions if clients cannot connect to the Exchange server.

  • Manually open ports in the firewall so that Exchange System Manager and Microsoft Exchange Administrator can be run. When you open ports in Windows Firewall service, you increase the chance that other programs may gain access to your computer through those ports. Carefully consider your network security requirements before opening ports in Windows Firewall service.

  • Stop the Windows Firewall service.


Windows Management Instrumentation service is not running as LocalSystem
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value data for the ObjectName value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winmgmt

The ObjectName value in this registry branch indicates the service account settings for the Microsoft Windows® Management Instrumentation (WMI) service, known as the Winmgmt service. If the Exchange Server Analyzer finds the value data for ObjectName is not equal to LocalSystem, the Exchange Server Analyzer displays an error.

This error indicates that the WMI service is not running in a supported configuration. If you run the WMI service under any account other than the LocalSystem account, you can cause permission errors and access errors.

To resolve this error, you must configure the WMI service to start under the LocalSystem (SYSTEM) account.

To configure the WMI service account

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. Locate and stop the Windows Management Instrumentation service.

  3. Double-click Windows Management Instrumentation service.

  4. On the Log On tab of the Windows Management Instrumentation Properties page, select Local System account under Log on as, and then click Apply.

  5. Under Service status, click Start, and then click OK.

  6. Close the Services snap-in.


Windows Server 2003 SP1: Outlook Web Access hotfix is required
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries various Microsoft Windows® Management Instrumentation (WMI) classes to collect the following information:

  • Which version of the Microsoft Windows Server operating system is Exchange Server installed on?

  • Is the Exchange Server running on a cluster?

If the Exchange Server Analyzer determines that the following conditions are true, the Exchange Server Analyzer displays an error:

  • Exchange Server 2003 Service Pack 1 (SP1) is installed.

  • Microsoft Windows Server™ 2003 Service Pack 1 (SP1) is installed.

  • Cluster service is running.

  • The Version value of Davex.dll is less than 6.5.7232.

If you are running this configuration, you must download and install an Exchange Server hotfix before you install Windows Server 2003 SP1. If you do not install the Exchange Server hotfix, Microsoft Office Outlook® Web Access for Exchange Server 2003 users will not be able to log on to their mailboxes. Users who have mailboxes that are hosted on the clusters will receive the following error message when they try to connect by using Outlook Web Access:

  • "500 - Internal Server Errors"

This error is caused by some of the security enhancements that are included with Windows Server 2003 SP1.

When a user tries to log on to a mailbox by using Outlook Web Access, HTTP submits requests to the clustering API by impersonating the logged-on user. However, there have been security changes in Windows Server 2003 SP1. The security restrictions for the APIs that perform remote registry access have changed. Therefore, the logon attempt is not successful.

To fix this error, you must download and install the Exchange Server hotfix that is described in the Microsoft Knowledge Base article 841561, "'500 - Internal server error' error message when a user tries to access a clustered Exchange Server 2003 back-end server by using Outlook Web Access" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=841561).


Windows Server 2003 SP1 Security Configuration Wizard was detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine which version of the Microsoft Windows® operating system is running on the Exchange server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

If the CurrentVersion value equals 5.0, the Exchange server is running on Microsoft Windows 2000 Server. If the CurrentVersion value is 5.2, the Exchange server is running on Microsoft Windows Server™ 2003.

Additionally, the Exchange Server Analyzer reads the following registry value to determine the path for the Windows Program Files directory:

HKLM\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir

The Exchange Server Analyzer then examines the Windows Program Files directory to determine whether the Windows Program Files directory contains the \Exchsrvr folder for Exchange Server.

Finally, the Exchange Server Analyzer queries the Win32_OperatingSystem Windows Management Instrumentation (WMI) class to determine the value for the ServicePackMajorVersion key. The value for the ServicePackMajorVersion key indicates which Windows service pack is installed on the computer.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • The Exchange Server Analyzer determines that the Exchange Server computer is running on Windows Server 2003 Service Pack 1.

  • The Exchange Server Analyzer determines that Exchange Server 2003 is not installed in the default path of \Program Files\Exchsrvr.

This warning indicates that Exchange Server 2003 is not installed in the default Program Files folder on the server and that the Security Configuration Wizard is installed on the Exchange server. The Security Configuration Wizard is a tool that is included as an optional component of Windows Server 2003 Service Pack 1. If the Security Configuration Wizard is installed on an Exchange server, manual configuration of the Network Security section is needed.

Note:
To install the Security Configuration Wizard, you must first install Windows Server 2003 Service Pack 1. After Service Pack 1 is installed, open Add/Remove Programs in Control Panel to install the Security Configuration Wizard.

The Security Configuration Wizard helps reduce the attack surface of Windows servers by asking the user a series of questions that are designed to determine the functional requirements of a server. Specifically, the Security Configuration Wizard helps you perform the following tasks:

  • It automatically disables unnecessary services.

  • It automatically blocks unused ports.

  • It helps you apply additional address restrictions or security restrictions for ports that are left open.

  • It prevents unnecessary Internet Information Services (IIS) Web extensions, if applicable.

  • It reduces protocol exposure to server message block (SMB), LanMan, and Lightweight Directory Access Protocol (LDAP).

  • It defines a high signal-to-noise audit policy.

The Security Configuration Wizard guides you through the process of creating, editing, applying, or rolling back a security policy that is based on the selected roles of the server. The security policies that are created by using the Security Configuration Wizard are XML files that configure services, network security, specific registry values, and audit policy when they are applied. If applicable, Internet Information Services (IIS) can also be configured.

The Security Configuration Wizard includes a Network Security feature that configures and adds exceptions to Windows Firewall, in addition to performing other functions. Windows Firewall is the new version of the stateful packet filter in Windows Server 2003 Service Pack 1. Windows Firewall was first introduced in Windows XP Service Pack 2. It was called Internet Connection Firewall in Windows XP Service Pack 2.

There is a known issue that occurs when the Network Security feature in the Security Configuration Wizard runs on an Exchange server on which Exchange Server is not installed in the default path. In this configuration, the application of the resultant policy may cause Exchange Server to be inaccessible by clients. When the Network Security feature is used on an Exchange server on which Exchange Server is not installed to the default path, the Security Configuration Wizard can configure Windows Firewall to block TCP/IP port access by Exchange Server processes, such as the System Attendant (Mad.exe), the Microsoft Exchange Information Store (Store.exe), or the message transfer agent (Emsmta.exe). In this configuration, the Security Configuration Wizard displays Not Found! next to each process. If the Security Configuration Wizard is run until it is completed with a process that has Not Found! next to it, the Security Configuration Wizard applies security policy to the Windows Firewall that blocks network access by that process.

If the blocked processes include one or more Exchange Server processes, Exchange Server may become inaccessible by clients and other servers. If this condition exists, you should perform one of the following procedures to correct the problem.

To correct the problem

  • Perform one of the following procedures to correct the problem:

    • Use the rollback feature of the Security Configuration Wizard to roll back a security policy after it has been applied. For more information about how to do this, see the Security Configuration Wizard Help file that is included with Windows Server 2003 Service Pack 1. For more information about Windows Server 2003 Service Pack 1 and Security Configuration Wizard, see the Windows Server 2003 TechCenter (http://go.microsoft.com/fwlink/?LinkId=45315).

    • In the Security Configuration Wizard, manually fill in the Application path field to specify the location of the Exchange Server executable process files. To do this, select the process that has Not Found! next to it, and click Edit. It is recommended that you run the Security Configuration Wizard on the Exchange server to make sure that the path of each Exchange Server process executable is correct. After each process executable has been approved, the Security Configuration Wizard security policy can be applied, and Exchange Server should have the network access that it requires to function.

For more information about Windows Server 2003 Service Pack 1 and the Security Configuration Wizard, see the Windows Server 2003 TechCenter (http://go.microsoft.com/fwlink/?LinkId=45315).


XESE.DLL file is present
Microsoft Exchange Server Analyzer - Articles > Exchange Server >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for a file called Xese.dll.

If the Exchange Server Analyzer is able to obtain a Version value for this file, it indicates that the file exists, and an error is displayed.

Some ESE-based antivirus programs use an unsupported interface between the Exchange information store and the Extensible Storage Engine (ESE). When you use this type of software, you run the risk of database damage and data loss if there are errors in the implementation of the software.

During installation, the ESE-based scanner changes the Microsoft Exchange Information Store service so that it is dependent on the ESE-based antivirus program's service. This makes sure that the ESE-based antivirus program's service starts before the Microsoft Exchange Information Store service starts. When the ESE-based antivirus program starts, the version of Ese.dll included with Exchange Server is temporarily renamed as Xese.dll, and the ESE-based antivirus program's version of Ese.dll replaces the original file. After the ESE-based antivirus program's version of Ese.dll is loaded, the version included with Exchange Server is renamed back to Ese.dll, and the Microsoft Exchange Information Store service completes the startup process.

To resolve this warning

  1. It is strongly recommended that you do not use non-Microsoft implementations of the ESE on Exchange Server computers. Customers who contact Microsoft Product Support Services may be asked to disable the ESE-based antivirus program to help identify issues, but customers are free to enable the software again after the root cause of the issue is correctly diagnosed.

  2. The most widely used ESE-based antivirus program is Antigen for Microsoft Exchange from Sybari Software. Microsoft and Sybari agree that disabling Sybari Antigen is a valid troubleshooting step to determine the cause of issues. To contact Sybari Software, see the Sybari Software Web site (http://www.sybari.com).

    Note:
    The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.

  3. It is recommended that you use antivirus programs that support the Virus Scanning Application Programming Interface (VSAPI), also known as the AntiVirus API (AVAPI).

For more information about running antivirus software on Exchange Server, see the following Microsoft Knowledge Base articles:

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).


Hardware
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2005-11-18

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating with regard to hardware. Additionally, these articles describe actions that you can take to resolve hardware-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


BIOS is outdated
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_BIOS Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the SMBIOSBIOSVersion and ReleaseDate keys. The value returned represents the version number and release date of the BIOS installed on the computer, respectively. The Exchange Server Analyzer also examines the Win32_ComputerSystem WMI class to determine the value of the Model key.

If the Exchange Server Analyzer finds that the value for the ReleaseDate indicates it is more than a year out-of-date, and that the Model key contains any of the following strings, a warning is displayed:

  • ProLiant DL320

  • ProLiant DL320 G2

  • ProLiant DL320 G3

  • ProLiant DL360

  • ProLiant DL360 G2

  • ProLiant DL360 G3

  • ProLiant DL360 G4

  • ProLiant DL380

  • ProLiant DL380 G2

  • ProLiant DL380 G3

  • ProLiant DL380 G4

  • ProLiant DL560

  • ProLiant DL570 G3

  • ProLiant DL580

  • ProLiant DL580 G2

  • ProLiant DL580 G3

  • ProLiant DL585 G1

  • ProLiant ML350

  • ProLiant ML350 G2

  • ProLiant ML350 G3

  • ProLiant ML350 G4

  • ProLiant ML370

  • ProLiant ML370 G2

  • ProLiant ML370 G3

  • ProLiant ML370 G4

  • ProLiant ML530

  • ProLiant ML530 G2

  • ProLiant ML570

  • ProLiant ML570 G2

  • ProLiant ML750

To correct this warning, and for more information about obtaining and updating a newer BIOS version, see the Hewlett-Packard Web site "ROM-BIOS/Firmware Updates" (http://h18023.www1.hp.com/support/files/server/us/romtabl.html).

For more information about Hewlett-Packard ProLiant servers, see the Hewlett-Packard Web site (http://www.hp.com).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


BIOS is outdated on the Dell PowerEdge server
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_BIOS Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the SMBIOSBIOSVersion key. The value returned represents the version number of the BIOS installed on the computer. The Exchange Server Analyzer also examines the Win32_ComputerSystem WMI class to determine the value of the Model key.

If the Exchange Server Analyzer finds that the Model key contains any of the following strings, and the SMBIOSBIOSVersion is not the latest version for the model, a warning is displayed:

  • PowerEdge 2400

  • PowerEdge 2450

  • PowerEdge 2500

  • PowerEdge 2550

  • PowerEdge 2600

  • PowerEdge 2650

  • PowerEdge 2800

  • PowerEdge 2850

  • PowerEdge 3250

  • PowerEdge 4300

  • PowerEdge 4350

  • PowerEdge 4400

  • PowerEdge 4600

  • PowerEdge 6300

  • PowerEdge 6350

  • PowerEdge 6400

  • PowerEdge 6450

  • PowerEdge 6600

  • PowerEdge 6650

  • PowerEdge 6800

  • PowerEdge 6850

  • PowerEdge 7150

  • PowerEdge 7250

  • PowerEdge 8450

To correct this warning, and for more information about obtaining and updating a newer BIOS version, see the Dell Web site "Downloads" (http://support.dell.com/support/downloads).

For more information about Dell PowerEdge servers, see the Dell Web site (http://www.dell.com).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


BIOS update is available
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_BIOS Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the SMBIOSBIOSVersion key. The value returned represents the version number and release date of the BIOS that is installed on the computer. The Exchange Server Analyzer also examines the Win32_ComputerSystem WMI class to determine the value of the Model key. If the Exchange Server Analyzer determines that the computer is an IBM X445 system with a BIOS version that is older than REJT48A, the Exchange Server Analyzer displays an error.

To correct this error, and for more information about obtaining and updating to a newer BIOS version, see the IBM Web site "Flash BIOS update (DOS update package) with RSA I and RSA II EXA support - IBM eServer xSeries 445" (http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-54089).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Cluster network interface card is DHCP-enabled
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the DHCPEnabled key for all network interfaces in the cluster. If the Exchange Server Analyzer finds the value for DHCPEnabled set to True for any private network interface in the cluster, an error is displayed.

A value of True for the DHCPEnabled WMI key indicates that a network interface is configured to use the Dynamic Host Configuration Protocol (DHCP). Microsoft does not support using DHCP for nodes on the private network in a Windows server cluster. Additionally, it is recommended that you use static IP addresses for nodes on the public networks in a Windows server cluster. Using dynamic configuration of public networks through DHCP is not recommended, as the failure to renew a DHCP lease could disrupt cluster operations. Additionally, using dynamic configuration of private networks through DHCP is not supported, and should never be performed.

To resolve this problem, you must reconfigure the network interfaces for the private networks to use a static IP address. It is recommended that addresses be selected within the following ranges:

  • 10.0.0.0 - 10.255.255.255 (Class A network)

  • 172.16.0.0 - 172.31.255.255 (Class B network)

  • 192.168.0.0 - 192.168.255.255 (Class C network)

To correct this error

  1. In Network Connections, right-click the network connection for your private network adapter, and then click Properties.

  2. Click Internet Protocol (TCP/IP), and then click Properties.

  3. On the General tab, enter a static IP address that is not on the same subnet or network as another one of the public network adapters. An example of good IP addresses to use for the private adapters is 10.10.10.10 on node 1 and 10.10.10.11 on node 2 with a subnet mask of 255.0.0.0. If your public network uses the 10.x.x.x network and 255.0.0.0 subnet mask, use an alternate private network IP and subnet.

  4. Make sure that there is no value set in the Default Gateway box.

  5. Verify that there are no values defined in the Use the following DNS server addresses box.

  6. Click Advanced.

  7. On the DNS tab, verify that there are no values defined. Make sure that the Register this connection's addresses in DNS and Use this connection's DNS suffix in DNS registration check boxes are cleared.

  8. On the WINS tab, verify that there are no values defined. Click Disable NetBIOS over TCP/IP.

  9. When you close the dialog box, you may receive the following prompt. If you receive this prompt, click Yes: This connection has an empty primary WINS address. Do you want to continue?

  10. Click OK to save your changes.

  11. Complete the previous steps on all other nodes in the cluster.

For more information about the optimal network configuration for Windows server clusters, see "Server Clusters: Network Configuration Best Practices for Windows 2000 and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=34304).

For more information about the correct cluster heartbeat configuration, see the Microsoft Knowledge Base article 258750, "Recommended Private 'Heartbeat' Configuration on a Cluster Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750).


The computer's primary DNS suffix does not match the FQDN of the domain where it resides
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2006-05-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine the primary Domain Name System (DNS) suffix for this Exchange Server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\NV Domain

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Domain

If the Exchange Server Analyzer finds that the values for NV Domain and Domain do not match, a warning is displayed.

The NV Domain registry value contains the computer's primary DNS suffix. The Domain registry value contains the computer's primary DNS domain. By default, the primary DNS suffix portion of a computer's fully qualified domain name (FQDN) must be the same as the name of the Active Directory® directory service domain where the computer is located. Mismatched names can prevent DNS registration from occurring correctly. If the DNS domain name for the computer does not match the Active Directory domain name, you will see errors in the computer's System event log every 22 minutes. Such a condition is known as a disjoint namespace. To allow different primary DNS suffixes, you can create a restricted list of allowed suffixes by creating an Active Directory attribute called msDS-AllowedDNSSuffixes in the domain object container.

The procedure for ensuring you have a correctly configured disjoint namespace depends on the operating system used for your Active Directory domain controllers.

  • If you are running a Microsoft Windows® 2000 Server operating system on your Active Directory domain controllers, you can use the procedure outlined in the Microsoft Knowledge Base article 258503, "DNS Registration Errors 5788 and 5789 When DNS Domain and Active Directory Domain Name Differ" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258503) to correctly configure your namespace. This article includes procedures for correcting an unintended disjoint namespace, and for correctly configuring a disjoint namespace if one is intended.

  • If you are running Microsoft Windows Server™ 2003 on your Active Directory domain controllers and the disjoint namespace is unintended, you can use the first procedure below to correct the unintended disjoint namespace and resolve this warning. If you are running Windows Server 2003 on your Active Directory domain controllers and the disjoint namespace is intended, you can use the second procedure below to correctly configure it.

To perform the second procedure below, you will need to use an Active Directory editor such as Active Directory Service Interfaces (ADSI) Edit or LDP (Ldp.exe) tool. For more information about modifying Active Directory with the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260745).

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Windows Server 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

If the disjoint namespace is unintended

  1. Right-click My Computer, and then click Properties. The System Properties dialog box will appear.

  2. Click the Computer Name tab.

  3. Click Change. The Computer Name Changes dialog box will appear.

  4. Click More. The DNS Suffix and NetBIOS Computer Name dialog box will appear.

  5. Select the Change primary DNS suffix when domain membership changes check box.

  6. Click OK to save the changes, and then click OK to exit the Computer Name Changes dialog box.

  7. Click OK to close the System Properties dialog box, and then restart the computer for the change to take effect.

If the disjoint namespace is intended

  1. Use the procedure above to ensure that the Change primary DNS suffix when domain membership changes check box is clear.

  2. Modify the msDS-AllowedDNSSuffixes Active Directory attribute on the domain object container. You can do this with ADSI Edit, by performing the following steps:

    1. Double-click the domain directory partition for the domain you want to modify.

    2. Right-click the domain container object, and then click Properties.

    3. On the Attribute Editor tab, in the Attributes box, double-click the attribute msDS-AllowedDNSSuffixes.

    4. In the Multi-valued String Editor dialog box, in the Value to add box, type a DNS suffix, and then click Add.

    5. When you have added all the DNS suffixes for the domain, click OK.

    6. Click OK to close the Properties dialog box for that domain.

    7. Repeat these steps if you have multiple domains you want to similarly configure.

For more information about the msDS-AllowedDNSSuffixes attribute, see the Windows Server 2003 Help and Support Center. For additional information about the procedure used to edit this attribute, see "Step-by-Step Guide to Implementing Domain Rename" (http://go.microsoft.com/fwlink/?LinkId=41359).


Critical BIOS update is available
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2006-04-20

The Microsoft® Exchange Server Analyzer Tool queries the Win32_BIOS Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the SMBIOSBIOSVersion key. The SMBIOSBIOSVersion key value represents the version of the BIOS installed on the server. The Exchange Server Analyzer also queries the Win32_ComputerSystem WMI class to determine the value for the Model key. The Model key value represents the hardware model information as provided by the hardware manufacturer.

If the Exchange Server Analyzer finds that value for the Version key is 42B on a server whose Model key begins with eserver xSeries 445, an error is displayed. This error indicates that this IBM xSeries 445 server's BIOS has to be updated.

There is a known issue with the 42B version of the BIOS firmware that may cause data corruption. The problem is limited to X445 systems that have BIOS 42B (version 1.15) installed. The problem is corrected with BIOS 45A. You should update the BIOS on this server to 45A or later as soon as possible.

To correct this error

  1. For more information about this issue, see the IBM Web site, "Flash BIOS Update (DOS update package) - IBM eServer xSeries 445" (http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-54089#BIOSVersion).

  2. For information, see the Readme file for the BIOS update (ftp://ftp.software.ibm.com/pc/pccbbs/pc_servers/39y4888.txt).

  3. Download the BIOS update from the IBM Web site (http://www-307.ibm.com/pc/support/site.wss/license.do?filename=pc_servers/26r0663.exe).

  4. Update the BIOS on the server.

For more information about applying this critical BIOS update, see the IBM Web site (http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=DSHY-3TEPF6).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Current Processor speed is less than the maximum possible speed
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Processor Microsoft Windows® Management Instrumentation (WMI) class to determine the current values for MaxClockSpeed and CurrentClockSpeed. If the Exchange Server Analyzer finds that the value for CurrentClockSpeed is less than the value for MaxClockSpeed, a warning is displayed.

The CurrentClockSpeed value is the current speed of each processor in megahertz (MHz). The MaxClockSpeed is the maximum speed of each processor in megahertz. If this warning message is displayed, it indicates that one or more processors on your Exchange server are not operating at full speed. There are a few known causes for this:

  1. Exchange Server is installed on a computer running Microsoft Windows® 2000 Server or Windows 2000 Advanced Server that does not have a minimum of Windows 2000 Server Service Pack 3 installed. Windows 2000 Server Service Pack 3 corrected a problem where WMI was not returning the correct values for MaxClockSpeed or CurrentClockSpeed.

  2. An incorrect power-saving setting in the Exchange server's BIOS may be forcing the processor to run at a reduced speed in a power-saving mode.

To correct this warning

  1. If Exchange Server is installed on a computer running Windows 2000 Server or Windows 2000 Advanced Server that does not have a minimum of Windows 2000 Server Service Pack 3 installed, you should install the latest service pack. For more information about the latest Windows 2000 service packs, see the Microsoft Windows 2000 Web site (http://go.microsoft.com/fwlink/?LinkId=18353).

  2. If Exchange Server is installed on a computer running Windows 2000 Server or Windows 2000 Advanced Server that does have Windows 2000 Server Service Pack 3 or a later version installed, check your Exchange server's BIOS settings. You should also check power management settings in the BIOS and in Control Panel or Device Manager.

Refer to your hardware manufacturer for information about how to view and configure system BIOS, processor, and power management settings.

For more information about the power management features of Windows 2000 Server, see the Microsoft Knowledge Base article 244806, "Overview of Power Management in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=244806).

For more information about the power management features in Microsoft Windows Server™ 2003, search on "Power Management" and "Power Options" in the Windows Server 2003 Help and Support Center, which can be run from the Start menu on a computer running Windows Server 2003.

For more information about the power management features in Windows 2000 Server, see the "Power Management" and "Power Options" topics in the Windows 2000 Server Help, which can be run from the Start menu on a computer running Windows 2000 Server.


DisableDHCPMediaSense is not set correctly on Windows Server 2003
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2006-10-02

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Media Sense Detection is configured correctly:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\DisableDHCPMediaSense

The Exchange Server Analyzer also examines the following registry entry to determine the version of Windows that is running on the destination computer:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the computer is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the computer is running a Windows® 2000 Server operating system, and a value of 5.2 indicates the computer is running a Windows Server™ 2003 operating system.

Additionally, the Exchange Server Analyzer queries the Win32_Service Microsoft Windows Management Instrumentation (WMI) class to determine the value of the Started key for ClusSvc, the Microsoft Windows Cluster service. A value of True indicates the Windows Cluster service is running, and a value of False indicates it is not running.

If the Exchange Server Analyzer finds that the Windows Cluster service is running on Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition and the value for the DisableDHCPMediaSense registry key is set to 1, a warning is displayed.

When you use the Windows Server 2003 Cluster service, if network connectivity is lost, the TCP/IP stack does not get unloaded by default, as it did in Windows 2000 Server. As a result, you are no longer required to set the DisableDHCPMediaSense registry key. In Windows 2000 Server, if network connectivity is lost, the TCP/IP stack was unloaded, which meant that all cluster resources, including resources in an Exchange Virtual Server, that depended on IP addresses were taken offline. When the networks came back online, their network role reverted to the default setting (that is, client and private). By disabling Media Sense by default, it means the network role is preserved, as well as keeping all IP address-dependant resources online.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

  3. In the right pane, right-click to modify (set to 0 to disable) or delete the DisableDHCPMediaSense registry value.

  4. Close the registry editor.

  5. Move all cluster resources to another node, or take them offline. Then, restart the cluster node for the change to take effect.

  6. Repeat this process on all other nodes in the cluster that generated this warning.

For more information about the Microsoft Windows registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information about Media Sense Detection and Windows clusters, see the following Knowledge Base articles:

  • 254651, "Cluster network role changes automatically" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=254651)

  • 239924, "How to disable Media Sense for TCP/IP in Windows" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=239924)

  • 242430, "Network Adapter Not Available During Cluster Configuration with a Crossover Cable" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=242430)

  • 278007, "Available Features in Windows Server 2003 Clusters" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=278007)


DisableDHCPMediaSense is not set correctly on Windows 2000 Server
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if Media Sense Detection is configured correctly:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\DisableDHCPMediaSense

The Exchange Server Analyzer also examines the following registry entry to determine the version of Windows that is running on the target computer:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates that the computer is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the computer is running a Microsoft Windows® 2000 Server operating system, and a value of 5.2 indicates the computer is running a Microsoft Windows Server™ 2003 operating system.

Additionally, the Exchange Server Analyzer queries the Win32_Service Microsoft Windows Management Instrumentation (WMI) class to determine the value of the Started key for ClusSvc, the Microsoft Windows Cluster service. A value of True indicates the Windows Cluster service is running, and a value of False indicates it is not running.

If the Exchange Server Analyzer finds that the Windows Cluster service is running on Windows 2000 Advanced Server or Windows 2000 Datacenter Server and if the DisableDHCPMediaSense registry key is present and the value is not set to 1, a warning is displayed.

When using the Windows 2000 Server Cluster service, if network connectivity is lost, the TCP/IP stack is unloaded. This means that all cluster resources, including resources in an Exchange Virtual Server, that depended on IP addresses were taken offline. When the networks came back online, their network role reverted to the default setting (client and private). To prevent this from happening, it is recommended that you disable Media Sense Detection on all Windows 2000 Server-based clusters. Media Sense Detection is automatically disabled on Windows Server 2003-based clusters.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

  3. Right-click Parameters, and then click New | DWORD value. Type DisableDHCPMediaSense for the name and press Enter.

  4. In the right pane, double-click DisableDHCPMediaSense and enter a Value data of 1.

  5. Close the registry editor.

  6. Move all cluster resources to another node, or take them offline. Then, restart the cluster node for the change to take effect.

  7. Repeat this process on all nodes in the cluster that generated this warning.

For more information about the Microsoft Windows registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information about Media Sense Detection and Windows clusters, see the following Knowledge Base articles:

  • 254651, "Cluster network role changes automatically" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=254651)

  • 239924, "How to disable Media Sense for TCP/IP in Windows" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=239924)

  • 242430, "Network Adapter Not Available During Cluster Configuration with a Crossover Cable" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=242430)

  • 278007, "Available Features in Windows Server 2003 Clusters" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=278007)


Disk timeout is not set at default
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the disk time-out value has been changed from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue

If the Exchange Server Analyzer finds the TimeOutValue present and configured with any value other than 10, and the server is non-clustered, a non-default configuration message is displayed. If the Exchange Server Analyzer finds the TimeOutValue present and configured with any value other than 20, and the server is clustered, a non-default configuration message is displayed.

Disk time-out is a registry setting that defines the time that Microsoft Windows® will wait for a hard disk to respond to a command. On a non-clustered system, this key is not present and a default value of 10 seconds is used for all disks. On a Windows cluster, this key is present and uses a default value of 20 seconds. If the time-out time is more than the value in this registry setting, Windows will show an error and will stop disk access. Sometimes, this may be set to a greater value if you are running multipath disk-access software. Multipath software lets you connect multiple physical paths (such as fiber) to a single disk drive for redundancy. Multipath software manages the multiple physical connections so that Windows handles only a single handle to the disk.

Installing host bus adapters (HBA) or other storage controllers can cause this key to be created and configured. When you install or reinstall these drivers, the TimeOutValue registry value is overwritten with the value that is required by those drivers. You may have to contact the hardware vendor to determine the correct TimeOutValue registry value for your configuration.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue

  3. In the right pane, delete the TimeOutValue entry. Alternatively, double-click the TimeOutValue entry and set it to one of the following values:

    • On a non-clustered server, set the value to 10.

    • On a clustered server, set the value to 20.

    • If your hardware manufacturer recommends a different value for either a clustered or non-clustered system, use the value from your hardware manufacturer instead.

  4. Close the registry editor, and then restart the computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the TimeOutValue entry on clustered systems, see the Knowledge Base article 818877, "Cluster Servers May Experience Connection Timeouts to Drives After You Install or Upgrade to the Windows Clustering Feature in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=818877).


The DNS search order is blank
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the DNSServerSearchOrder. If the value for this key on an Exchange server is blank, a warning is displayed.

This warning indicates that one or more of the network adapters on this computer do not have DNS IP addresses associated with them. Therefore, when this computer tries to connect to another computer, it is broadcasting across the local network for IP addresses. Therefore, name resolution will be slow, which may slow Exchange.

It is recommended that an IP address of at least one valid DNS server be entered. If you have more than one adapter on the computer, verify that all adapters have at least one valid DNS server IP address.

To set the DNS IP address on a network adapter

  1. In Network Connections, right-click the appropriate Local Area Network adapter, and then click Properties.

  2. On the General tab, double-click Internet Protocol (TCP/IP).

  3. On the General tab of the Internet Protocol (TCP/IP) page, enter at least one IP address of a valid DNS server, and then click OK.

For more information about configuring DNS to work with Exchange, see the Microsoft Knowledge Base article 322856, "How to configure DNS for use with Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322856).


Heartbeat connection has default gateway
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapter Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the NetConnectionID key. If the value for the NetConnectionID key contains the string Internal, or HEART, it indicates that the interface is the cluster private (heartbeat) network.

The Exchange Server Analyzer also queries the Win32_NetworkAdapterConfiguration WMI class to determine whether a value is set for the DefaultIPGateway key. If a value is set, it indicates that a default gateway has been configured for this network interface.

If the Exchange Server Analyzer finds a value set for the DefaultIPGateway key on the network interface used for the cluster heartbeat network, a warning is displayed.

Because private cluster networks are used for internal cluster communications, it is not necessary to configure a default gateway. To eliminate possible communication issues, it is recommended that you remove all unnecessary network traffic from the network adapter that is used as the cluster private network adapter.

To correct this warning

  1. Open the Network Connections window. Either right-click My Network Places, and then click Properties, or if My Network Places is not displayed on the desktop, click Start, click Programs, click Accessories, click Communications, and then click Network Connections.

  2. In the Network Connections window, right-click the network adapter being used for the private network, and then click Properties.

  3. Select Internet Protocol (TCP/IP), and then click Properties.

  4. In the Use the following IP address area, delete the default gateway IP address.

  5. Click OK twice to save the changes.

  6. Repeat steps 1-5 for each node in the cluster.

For more information about the recommended settings for the private network in a Windows server cluster, see the Microsoft Knowledge Base article 258750, "Recommended Private 'Heartbeat' Configuration on a Cluster Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750).


Heartbeat connection has DNS search address
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapter Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the NetConnectionID key. If the value for the NetConnectionID key contains the string Internal, or HEART, it indicates that the interface is the cluster private (heartbeat) network.

The Exchange Server Analyzer also queries the Win32_NetworkAdapterConfiguration WMI class to determine whether a value is set for the DNSServerSearchOrder key. If a value is set, it indicates that a Domain Name System (DNS) search address has been configured for this network interface.

If the Exchange Server Analyzer finds a value set for the DNSServerSearchOrder key on the network interface used for the cluster heartbeat network, a warning is displayed.

Because private cluster networks are used for internal cluster communications, it is not necessary to configure any DNS servers. To eliminate possible communication issues, it is recommended that you remove all unnecessary network traffic from the network adapter that is used as the cluster private network adapter.

To correct this warning

  1. Open the Network Connections window. Either right-click My Network Places, and then click Properties, or if My Network Places is not displayed on the desktop, click Start, click Programs, click Accessories, click Communications, and then click Network Connections.

  2. In the Network Connections window, right-click the network adapter being used for the private network, and then click Properties.

  3. Select Internet Protocol (TCP/IP), and then click Properties.

  4. Click Advanced.

  5. On the DNS tab, select a DNS server address, and then click Remove. Repeat this step for each DNS server address listed.

  6. Clear the Register this connection's addresses in DNS and Use this connection's DNS suffix in DNS registration check boxes.

  7. Click OK three times to save the changes.

  8. Repeat steps 1 through 7 for each node in the cluster.

For more information about the recommended settings for the private network in a Windows server cluster, see the Microsoft Knowledge Base article 258750, "Recommended Private 'Heartbeat' Configuration on a Cluster Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750).


Heartbeat connection has WINS address
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapter Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the NetConnectionID key. If the value for the NetConnectionID key contains the string Internal, or HEART, it indicates that the interface is the cluster private (heartbeat) network.

The Exchange Server Analyzer also queries the Win32_NetworkAdapterConfiguration WMI class to determine whether a value is set for the WINSPrimaryServer key. If a value is set, it indicates that a primary Windows Internet Name Service (WINS) address has been configured for this network interface.

If the Exchange Server Analyzer finds a value set for the WINSPrimaryServer key on the network interface used for the cluster heartbeat network, a warning is displayed.

Because private cluster networks are used for internal cluster communications, you do not have to configure any WINS servers, or use NetBIOS. To eliminate possible communication issues, it is recommended that you remove all unnecessary network traffic from the network adapter that is used as the cluster private network adapter.

To correct this warning

  1. Open the Network Connections window. Either right-click My Network Places, and then click Properties, or if My Network Places is not displayed on the desktop, click Start, click Programs, click Accessories, click Communications, and then click Network Connections.

  2. In the Network Connections window, right-click the network adapter being used for the private network, and then click Properties.

  3. Select Internet Protocol (TCP/IP), and then click Properties.

  4. Click Advanced.

  5. On the WINS tab, select a WINS address, and then click Remove. Repeat this step for each listed WINS address.

  6. In the NetBIOS setting area, select Disable NetBIOS over TCP/IP.

  7. Click OK three times to save the changes. After clicking OK the first time, you may receive the following prompt. If you receive this prompt, click Yes: "This connection has an empty primary WINS address. Do you want to continue?"

  8. Repeat steps 1 through 7 for each node in the cluster.

For more information about the recommended settings for the private network in a Windows server cluster, see the Microsoft Knowledge Base article 258750, "Recommended Private 'Heartbeat' Configuration on a Cluster Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750).


The heartbeat connection is first in the TCP/IP binding order and not the public connection
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries two Microsoft Windows® Management Instrumentation (WMI) classes to do the following:

  • The Win32_NetworkConfiguration WMI class is queried to determine the value of the SettingID key for all network interfaces in the cluster. The value for the SettingsID key is a GUID that represents a unique network adapter.

  • The Win32_NetworkAdapter WMI class is queried to determine which network adapters are being used for private network communications in an Exchange cluster. The private network is used for internal cluster communications, including the cluster heartbeat.

  • The Exchange Server Analyzer also examines the following registry value to determine the network adapters binding order:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Linkage\Bind

The Bind registry value is a multi-string value that contains a list of network adapters in binding order. The first entry in the list is the first bound network adapter; the second entry is the second network adapter in the binding order; and so forth.

If the Exchange Server Analyzer determines that the cluster heartbeat network adapter is first in the binding order, a warning is displayed.

To resolve this problem, make sure that the public network adapter is the first binding at the top of the binding list. If you have multiple public network adapters, make sure that the private heartbeat network adapter is listed last. If the heartbeat network adapter is listed first, it can prevent the correct installation of service packs and upgrades.

To correct this warning

  1. In the Network Connections window, click Advanced, and then click Advanced Settings.

  2. Click the Adapters and Bindings tab.

  3. In the Connections field, select the private network adapter and use the down arrow to move the private network adapter to the bottom of the list.

  4. Repeat these steps for each node in the cluster.

For more information about the optimal network configuration for Windows server clusters, see "Server Clusters: Network Configuration Best Practices for Windows 2000 and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=34304)

For more information about the correct cluster heartbeat configuration, see the Microsoft Knowledge Base article 258750, "Recommended Private 'Heartbeat' Configuration on a Cluster Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750).


Heartbeat network speed set to auto sense/auto detect
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapter Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the NetConnectionID key. If the value for the NetConnectionID key contains the string Internal, or HEART, it indicates that the interface is the cluster private (heartbeat) network.

The Exchange Server Analyzer also reads the following registry value to determine the link speed and duplex settings for the network interface card being used for the cluster heartbeat network:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\ <NetworkCardDeviceID> \SpeedDuplex

Additionally, the Exchange Server Analyzer also reads the following registry value to determine whether automatic network speed detection is enabled:

HKLM\System\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\%NICDEVICEID%\Ndi\Params\SpeedDuplex\enum\0

If the value for the 0 key contains the string AUTO, it indicates that automatic network speed detection is enabled.

If the Exchange Server Analyzer determines that both SpeedDuplex is set to 0 and automatic network speed detection is enabled for the cluster heartbeat network, a warning is displayed.

Communication between server cluster nodes is critical for smooth cluster operations. If you use a multiple speed Ethernet network adapter for cluster communications and configure the adapter to automatically detect the network speed, the adapter may cause problems within the cluster. During the detection process, packets cannot be handled by the adapter and must be queued. Some adapters may unintentionally trigger the automatic detection process to reoccur occasionally. Therefore, communications are queued and communication delayed. Delays of this kind may cause cluster nodes not to receive critical packets promptly and may cause premature failover of cluster resources. It is recommended that the heartbeat network in a cluster be manually set to 10 megabits and half-duplex. This configuration will provide sufficient bandwidth and reliable communication.

To correct this warning

  • Configure the heartbeat network interface card for a link speed of 10 megabits and a duplex setting of half-duplex. Because the configuration steps for each network card are different, follow the instructions from your hardware provider to correctly configure the heartbeat network. Configuring these options may require an updated driver.

For more information about the recommended settings for the private network in a Windows server cluster, see the Microsoft Knowledge Base article 258750, "Recommended Private 'Heartbeat' Configuration on a Cluster Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750).


Host Bus Adapter queue depth is set to 32
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2006-10-11

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the queue depth of the host bus adapters (HBAs) installed in the Exchange Server computer:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\elxstor\Parameters\Device\DriverParameter

If the Exchange Server Analyzer finds the value for DriverParameter to be set to 32, a warning is displayed.

An HBA is a disk controller for storage area networks (SANs). The HBA queue depth defines the maximum number of outstanding queue requests. Generally, the recommended value for DriverParameter is 128. However, this may not be the optimal value for the HBA queue depth for every HBA in every Exchange Server computer. Therefore, you should consult with the HBA manufacturer to obtain the optimal value for your specific hardware.

To correct this warning

  1. Contact your hardware manufacturer to determine the optimal setting for your HBAs.

  2. Monitor disk performance using the Microsoft Windows® System Monitor utility.

  3. Update your HBA hardware to the latest firmware and drivers.

For more information about Exchange Server storage design and optimization, see the "Optimizing Storage for Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=49324).


Hot-add memory configuration
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2006-02-22

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Computer System Microsoft Windows® Management Instrumentation (WMI) class to determine whether the server supports hot-add memory capabilities. The Exchange Server Analyzer also queries the Win32_OperatingSystem WMI class to determine the following:

  • Is the /3GB option set in the Boot.ini file.

  • Is the physical address extensions (PAE) kernel loaded.

  • What edition of the operating system is running on the server.

Finally, the Exchange Server Analyzer queries the following registry entry to determine whether the DynamicMemory configuration parameter exists and is set correctly:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

If the Exchange Server Analyzer determines that all of the following criteria are true, Exchange Server Analyzer displays an error message:

  • The computer supports hot-add memory and, by default, the facility is enabled.

  • The computer is running Microsoft Windows Server™ 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition.

  • The PAE kernel is loaded.

  • The /3GB option is set in the Boot.ini.

  • The DynamicMemory registry configuration parameter is not set, is set to a value of 0, or is set to a value larger than 3.

Note:
If the computer supports hot-add memory, but the hardware manufacturer disables the facility by default, the Exchange Server Analyzer displays a warning message instead of an error message.

The hot-add memory facility was introduced in Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition to let system administrators add more physical memory to a computer without restarting it. This feature is useful on servers that support memory-intensive relational database applications such as Microsoft SQL Server. However, because Exchange Server cannot use more than 4 GB of physical memory, this feature is not useful to Exchange Server.

Not all computers support hot-add memory. For the computers that do, some hardware manufacturers enable the facility by default, and others provide controls within the Basic Input Output System (BIOS). If, during the boot process, hot-add memory is enabled, the operating system kernel must pre-allocate space to handle any future memory that may be added to the computer. Therefore, kernel resources are allocated based on the capabilities of the computer instead of what is actually installed. Kernel memory is a precious resource on computers that run Microsoft Exchange Server. Because the kernel may allocate significant amounts of resource to memory that may never be installed, and due to the nature of physical memory used by Exchange Server, additional performance and scalability may be achieved by disabling the hot-add memory facility. Leaving the feature enabled may cause the maximum size of the paged pool to be much lower than expected. This may cause a severe decrease in performance, system lock-ups, and, ultimately, a service outage.

Examples of expected maximum paged pool sizes (more is better):

  • 240 MB A computer that has 4 GB of physical memory without hot-add memory support or support is disabled

  • 210 MB A computer that has 4 GB of physical memory, but can support up to 32 GB of hot-add memory

  • 160 MB A computer that has 4 GB of physical memory, but can support up to 64 GB of hot-add memory

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this problem on computers that run Windows Server 2003 Service Pack 1 (SP1) or later

  1. Set the following registry parameter to disable the hot-add memory feature:

    Path

    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

    Value

    DynamicMemory

    Type

    REG_DWORD

    Data

    0x1
    Note:
    The value for this configuration parameter is expressed as the number, in gigabytes, of maximum addressable physical memory, including hot-add memory, if the physical memory installed at boot time is not greater. By setting the value to 1, the kernel reserves space for a total of 1 GB of system memory, or the total amount of physical memory installed at boot time, whichever is greater..

  2. Restart the computer
To correct this problem on computers that run Windows Server 2003 without SP1 installed

  • Contact your hardware vendor to determine whether the hot-add memory facility can be disabled in the BIOS.

  • If hot-add memory cannot be controlled through hardware, the recommended approach is to upgrade to Windows Server 2003 SP1 and follow the resolution steps here to implement the DynamicMemory parameter. If you cannot upgrade to SP1, the alternative is to set the /NOPAE option in the Boot.ini file. Setting this option will force the computer not to recognize any memory greater than the 4 GB boundary. Use this option on computers that run Windows Server 2003 before SP1, but you should not use it on computers that run SP1 as it may unintentionally disable new features including Data Execution Prevention (DEP) support.

For More Information

For more information about hot-add memory support in Windows Server 2003, see Hot-Add Memory Support in Windows Server 2003 (http://go.microsoft.com/fwlink/?linkid=57183).


Internet SCSI Initiator software is outdated
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2006-04-03

The Microsoft® Exchange Server Analyzer Tool queries the Win32_SCSIController Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the DriverName key for the iScsciPrt driver. The Exchange Server Analyzer also queries the CIM_Datafile WMI class to determine the value of the Version key listed in the iScsciPrt driver file. If the Exchange Server Analyzer finds a substring value in the iScsciPrt driver Version key that is less than 1748, a warning is displayed

Internet small computer system interface (iSCSI) is an Internet Protocol-based (IP-based) method that is designed to send small computer system interface (SCSI) commands that are encapsulated in IP packets over TCP/IP networks. Because iSCSI is IP-based, data can be transmitted over local area networks (LANs), over wide area networks (WANs), and over the Internet to remote storage locations. Microsoft Windows operating systems display iSCSI hard disks to programs such as Exchange Server 2003 or Exchange 2000 Server as hard disks that are connected directly to the Exchange Server computer.

Microsoft encourages you to use caution when you deploy Exchange Server 2003 with iSCSI or Exchange 2000 Server with iSCSI. Because iSCSI uses the SCSI transport protocol to transmit block data over TCP/IP networks, the involvement of a network can introduce components that are not traditionally thought of as high-speed input/output paths. To maximize throughput, you must configure Exchange Server to maximize caching activities, and you must test to verify that the latency that is involved with iSCSI traffic is minimized. Unless your storage vendor indicates otherwise, it is also strongly recommended that you use the latest available build of the Microsoft iSCSI Software Initiator.

To correct this warning

  1. Download the latest version of the Microsoft iSCSI Software Initiator from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=33817).

  2. Review the release notes at the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=40951).

  3. Review the User Guide at the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=40963).

  4. Take a complete backup of the computer.

  5. Apply the latest version update.

For more information about iSCSI support in Exchange 2000 Server and Exchange Server 2003, see the Microsoft Knowledge Base article 839686, "Support for iSCSI technology components in Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=839686).

For more information about iSCSI technology and Microsoft support of iSCSI, see the Microsoft Web site, "Microsoft Storage Technologies - iSCSI" (http://go.microsoft.com/fwlink/?LinkId=27514).


Logical and Physical disk performance counters are disabled
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the logical and physical disk performance counters are disabled:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Perfdisk\Performance\Disable Performance Counters

If the Exchange Server Analyzer finds the value for Disable Performance Counters present and configured with a value of 1, a warning is displayed.

There are two types of disk-related performance counters that are published on a server computer running a Microsoft Windows® operating system:

  • Those used by the Microsoft Win32® performance subsystem and Windows Management Instrumentation (WMI).

  • Those used by legacy applications that call the IOCTL_DISK_PERFORMANCE API to retrieve raw counter information.

  • The performance counters used by Win32 and WMI are enabled by default on Microsoft Windows Server™ 2003 and Windows 2000 Server. The raw counters are disabled by default on both operating systems. If the Disable Performance Counters registry value, which is not present by default on either operating system, is added and configured with a value of 1, the Win32/WMI performance counters are disabled, and performance data collection of those counters cannot be accomplished.

The most common way to disable Win32/WMI counters is by using the Extensible Counter List tool (ExCtrLst.exe). This graphical tool, which is available with both the Windows 2000 Server and Windows Server 2003 Resource Kits, enables an administrator to selectively enable or disable the publishing of performance objects. When ExCtrLst.exe is used to disable a performance object, it adds the Disable Performance Counters entry to the registry and configures it with a value of 1. If ExCtrLst.exe is then used to re-enable a disabled counter, it changes the value for Disable Performance Counters to 0. (Note that it does not delete the Disable Performance Counters entry.)

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\Perfdisk\Performance

  3. In the right pane, double-click Disable Performance Counters and set it to a value of 0. Alternatively, you can delete the Disable Performance Counters entry to re-enable the counters.

  4. Exit the registry editor and restart any application that collects performance data for the change to take effect.

For more information about ExCtrLst.exe, see "Exctrlst.exe: Extensible Performance Counter List" (http://go.microsoft.com/fwlink/?linkid=34436).


Multiple default gateways detected
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows® Management Instrumentation (WMI) class to determine the count of instances of the DefaultIPGateway key. Each network adapter publishes its configured default gateway address to WMI through this key. If the Exchange Server Analyzer determines that there is more than one configured instance of the DefaultIPGateway key, a warning is displayed.

This warning indicates that multiple network adapters were found, and that more than one of those adapters has a configured default gateway. When multiple adapters are used and configured with separate default gateways, connectivity to computers on remote networks may be lost. Additionally, using multiple default gateways that link to different network subnets is known to cause problems with Domain Name System (DNS) resolution, Simple Message Transfer Protocol (SMTP) message delivery, Lightweight Directory Access Protocol (LDAP) queries, and new mail notification to Microsoft Office Outlook® 2003 clients. Many of these problems can prevent Exchange Server from starting, or from sending and receiving messages.

It is recommended that you remove all except one default gateway from one of the network interface adapters in the Exchange Server computer. Exchange Server computers are often multihomed when Microsoft Internet Security and Acceleration (ISA) Server has been installed on the same computer. Even when you run Exchange Server and ISA Server on the same computer, using multiple default gateways is not recommended. If Exchange Server and ISA Server are not installed on the same computer, it is recommended that you do not multihome an Exchange Server computer.

To correct this warning

  1. Open the Network Connections window. Either right-click My Network Places, and then click Properties, or if My Network Places is not displayed on the desktop, click Start, click Programs, click Accessories, click Communications, and then click Network Connections.

  2. In the Network Connections window, right-click the network connection containing the default gateway entry you want to remove, and then click Properties.

  3. Select Internet Protocol (TCP/IP), and then click Properties.

  4. Delete the IP address from the Default gateway field.

  5. Click OK twice to save the changes.

  6. Repeat this process for all other network connections that contain a default gateway entry, except for the one entry you want to keep.

For more information about problems encountered on computers that use multiple default gateways, see the Microsoft Knowledge Base article 159168, "Multiple Default Gateways Can Cause Connectivity Problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=159168).

For more information about configuring default gateways on multihomed computers, see the Knowledge Base article 157025, "Default Gateway Configuration for Multihomed Computers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=157025).


PageFile Size Larger Than Total Physical Memory
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2007-07-30

The Microsoft Exchange Analyzer Tool queries the Win32_PageFile Windows® Management Instrumentation (WMI) class to determine the value for the MaximumSize key. This key represents the current configured maximum page file size.

The Exchange Analyzer also queries the Win32_ComputerSystem WMI class to determine the value set for the TotalPhysicalMemory key. This value represents the amount of RAM installed on the computer.

If the Exchange Analyzer determines that the value for the Win32_PageFile MaximumSize key is larger than 1.5 times the value of the Win32_ComputerSystem TotalPhysicalMemory key, an error is displayed.

The page file (pagefile.sys) is a hidden file on the hard disk that is used by Windows to retain temporary data when the system is running low on RAM. The page file is also known as paging file or swap file. Virtual memory consists of page file and RAM.

The recommended page file size is equivalent to 1.05 times the RAM up to a maximum of 4,095 MB. This means that the largest paging file size per volume that you can set is 4,095 MB.

Note:
To prevent page file fragmentation, we recommend that you set the paging file size initial and maximum values to be the same value. If you reduce the size of either the initial or maximum page file settings, you must restart your computer to see the effects of those changes. Increases typically do not require a restart.
To change the page file settings

  1. Click Start, Control Panel, and then click System.

  2. On the Advanced tab, under Performance, click Settings.

  3. In the Performance Options dialog box, on the Advanced tab, under Virtual Memory, click Change.

  4. Under Drive [Volume Label], click the drive that contains the paging file that you want to change.

  5. Under Paging file size for selected drive, click Custom size, and enter the recommended page file size in megabytes in the Initial size (MB) and Maximum size (MB) fields, and then click Set.

For more information about page files, see the following Microsoft Knowledge Base articles:

  • 197379, "Configuring paging files for optimization and recovery in Windows Server 2003, in Windows 2000, and in Windows NT" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379)

  • 307973, "How to configure system failure and recovery options in Windows" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307973)

  • 254649, "Overview of memory dump file options for Windows Server 2003, Windows XP, and Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=254649)

  • 241046, "Cannot Create a Memory.dmp File on Computers with over 4 GB RAM" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=241046)


The Secondary WINS server address is blank
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the WINSSecondaryServer key. If the value for this key on an Exchange server is blank, a warning is displayed.

Exchange Server 2003 and Exchange 2000 Server have several NetBIOS dependencies. Additionally, clients running Microsoft Outlook® versions prior to Microsoft Office Outlook 2003 also require NetBIOS name resolution. For example, the following Exchange functionality depends on NetBIOS name resolution:

  • The Exchange Server 2003 and Exchange 2000 Server Setup programs, especially on clustered servers.

  • Exchange Mailbox Merge Wizard (ExMerge) on an Exchange Server 2003 or Exchange 2000 Server computer.

  • Changing a password for an Exchange Server 2003 or Exchange 2000 Server mailbox through Outlook Web Access.

  • Exchange System Manager on an Exchange Server 2003 or Exchange 2000 Server computer.

Depending on your organization's network topology, you may be able to safely ignore this warning. On networks that are made up of a single subnet NetBIOS, broadcasts are typically able to handle the NetBIOS name resolution requirements of an Exchange deployment.

In large organizations, NetBIOS name resolution through broadcasts may not function correctly. Because NetBIOS broadcasts typically do not cross subnets, routed networks require an alternate method for resolving NetBIOS names. The preferred method to do this is Windows Internet Name Service (WINS). WINS provides a distributed database for registering and querying dynamic mappings of NetBIOS names for computers and groups used on your network. WINS maps NetBIOS names to IP addresses and was designed to solve the problems occurring because of NetBIOS name resolution in routed environments. WINS is the best choice for NetBIOS name resolution in routed networks that use NetBIOS over TCP/IP.

Exchange Server 2003 and Exchange 2000 Server operations and functions in a large or sub-netted organization without WINS have not been fully tested. Microsoft requires companies running Exchange on routed or segmented networks to use WINS for NetBIOS name resolution. Running Exchange in a routed or segmented environment without WINS is not supported.

It is recommended that you deploy a fault-tolerant WINS environment that includes at least two WINS servers. WINS servers can act as either a primary WINS server or a secondary WINS server to a client. The difference between primary and secondary WINS servers is the priority in which clients contact them. A primary WINS server is the first server a client contacts to perform its NetBIOS name service operations. A client contacts a secondary WINS server only when a primary WINS server cannot fulfill the request, for example, if it is unavailable when the client makes the request or you cannot resolve a name for the client.

If a primary WINS server does not fulfill a request, the client makes the same request of its secondary WINS server. If more than two WINS servers are configured for the client, the client tries the additional secondary WINS servers until the list is exhausted or one of the WINS servers successfully responds to the request. After a client uses a secondary WINS server, it periodically tries to switch back to its primary WINS server for future name service requests.

It is a best practice to configure at least one secondary WINS server on Exchange server computers on a routed or segmented network.

To correct this warning

  1. Open Network Connections.

  2. Right-click the network connection you want to configure, and then click Properties.

  3. On the General tab (for a local area connection) or the Networking tab (for all other connections), click Internet Protocol (TCP/IP), and then click Properties.

  4. Click Advanced, click the WINS tab, and then click Add.

  5. In TCP/IP WINS server, type the IP address of a secondary WINS server, and then click Add.

  6. Repeat steps 4 and 5 for each additional WINS server IP address you want to add, and then click OK. You can change the order of preference for WINS servers by using the arrow keys.

  7. Make sure Enable NetBIOS over TCP/IP is selected.

  8. Click OK to save your changes.

For more information about the NetBIOS name resolution requirements for Exchange, see the Microsoft Knowledge Base article 837391, "Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=837391).


Server is a Virtual PC
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2007-03-28

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Model key for the Exchange Server computer. If the value for this key contains the string "Virtual Machine," an error is displayed.

The presence of the string "Virtual Machine" indicates that the Exchange Server computer is running inside a Microsoft Virtual PC 200x virtual computer. Virtual PC 200x is a software virtualization solution that enables you to run multiple PC-based operating systems simultaneously on one workstation. Microsoft does not support running any version of Microsoft Exchange Server on a virtual machine or on an emulator. This is true for Exchange Server running on Microsoft Virtual Server 200x, Microsoft Virtual PC 200x, or any third-party virtual machine program. Microsoft Exchange Server platforms are designed and tested to run only on physical hardware, particularly those hardware platforms that are listed in the Windows Server Catalog (http://go.microsoft.com/fwlink/?linkid=17219).

To correct this error

  1. Move the mailboxes from the Exchange Server running under Virtual PC 200x to a non-virtual Exchange Server computer.

  2. Re-home any public folders and transfer any roles held by the virtual Exchange server as necessary.

  3. Uninstall Exchange from the virtual machine to decommission and remove from your Exchange infrastructure and from the Active Directory® directory service.

For more information about support for Exchange Server computers running in virtual environments, see the Microsoft Knowledge Base article 320220, "Support policy for Exchange Server 2003 running on hardware virtualization software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=320220).

For more information about Microsoft Virtual PC, see the Microsoft Virtual PC home page (http://go.microsoft.com/fwlink/?linkid=34663).


This disk is reporting an error
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_DiskDrive Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the Status key for each disk. If the Exchange Server Analyzer determines that the value of the Status key for any disk does not equal OK, an error is displayed.

The Status key provides the current status of the disk object. Various operational and non-operational statuses can be defined. Operational statuses include:

  • OK

  • Degraded

  • Pred Fail (an element, such as a SMART-enabled hard drive, may be functioning correctly but predicting a failure in the near future).

  • Non-operational statuses include:

  • Error

  • Starting

  • Stopping

  • Service (this can apply during mirror-resilvering of a disk, reload of a user permissions list, or other administrative work).

The Status key is inherited from the CIM_ManagedSystemElement WMI class, which includes the following values:

  • OK

  • Error

  • Degraded

  • Unknown

  • Pred Fail

  • Starting

  • Stopping

  • Service

  • Stressed

  • NonRecover

  • No Contact

  • Lost Comm

Generally, Microsoft does not provide documentation about troubleshooting disk failures for specific hardware vendors.

To correct this error

  1. Verify all disk and cable connections, wait 10 minutes, and then check the value for Status.

  2. If the value returned is not a maintenance mode value (for example, the value does not equal Service, you should follow the disk troubleshooting steps recommended by your hard disk manufacturer. In some cases, your hard disk manufacturer may have troubleshooting software that you can install to analyze the problem.

For generic storage information related to Exchange, see "Storage Solutions for Microsoft Exchange 2000 Server" in the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=1715).

For generic storage information related to Microsoft Windows Server™ 2003, see "Windows Server 2003 Storage Services" in the Microsoft Windows Server 2003 TechCenter (http://go.microsoft.com/fwlink/?LinkId=33811).

For generic storage information related to Windows 2000 Server, see "Windows 2000 Storage Services" in the Windows 2000 Web site (http://go.microsoft.com/fwlink/?LinkId=33812).


This Exchange server has more than 8 processors
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the current value for NumberOfProcessors. If the Exchange Server Analyzer finds that the value for NumberOfProcessors is larger than 8, a warning is displayed. However, if this server is configured to use Intel Hyper-Threading Technology, this warning can be safely ignored. Hyper-Threading Technology enables multi-threaded software applications to run threads in parallel. Hyper-Threading Technology requires a computer system with an Intel Pentium 4 processor supporting Hyper-Threading Technology and an HT Technology-enabled chipset, BIOS, and operating system.

Exchange 2000 Server and Exchange Server 2003 can effectively use only eight processors on a computer. Specifically, the Microsoft Exchange Information Store service is optimized for a maximum on eight processors.

On computers that have more than eight processors, it is recommended that you use hardware partitioning to partition the computer into multiple eight-processor computers or into multiple four-processor computers. Alternatively, you can configure CPU affinity for the Microsoft Exchange Information Store process (Store.exe) to only eight processors.

As soon as the Microsoft Exchange Information Store process has been limited to eight processors either through CPU affinity or through hardware partitioning, it is recommended that you upgrade to the latest available service pack and Exchange update rollups. This is especially important if you are running Exchange Server 2003.

Previously, Exchange server performance has shown marginal improvements when the number of processors in back-end servers increases to more than four. With more than eight processors, the performance increase is marginal at best, and sometimes performance can decrease. The falloff in performance gain with additional processors has become more pronounced with the types of processors used on more recent computers. With Exchange Server 2003 Service Pack 1, scalability with additional processors is much improved. When hyper-threading is enabled, eight-processor servers now provide a 50 percent increase in performance over four-processor servers. Using eight-processor computers for back-end servers is now appropriate in many scenarios. Dual-processor servers are still recommended for front-end servers.

As stated, if this Exchange Server computer is using Hyper-Threading Technology, this warning can be safely ignored.

To correct this warning on systems that do not use Hyper-Threading Technology

  1. Apply the latest service pack and update rollups for Exchange, which you can download from the Downloads for Exchange Server 2003 Web site (http://go.microsoft.com/fwlink/?linkid=25097).

  2. Set the CPU affinity for the Microsoft Exchange Information Store service (Store.exe) to eight CPUs, or use hardware partitioning to create an eight-processor Exchange server. Contact your hardware manufacturer for details about how to do this.

For more information about Exchange Server resource scalability, see the Microsoft Knowledge Base article 827281, "CPU and Memory Scalability for Exchange 2000 and Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827281).

For more information, see also the Knowledge Base article 271088, "XGEN: Optimizing Windows 2000 Active Directory Servers with Six or Eight Processors to Run with Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=271088).

For more information about Hyper-Threading Technology, see the Intel Web site (http://www.intel.com/info/hyperthreading).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


This Exchange server has more than 4 GB of memory
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2006-06-20

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the TotalPhysicalMemory key for each Exchange Server computer.

If the Exchange Server Analyzer finds the value for TotalPhysicalMemory greater than 4294967296 but less than 6442450944, a warning is displayed.

If the Exchange Server Analyzer finds that the value for TotalPhysicalMemory is greater than 6442450944, an error is displayed.

A value for TotalPhysicalMemory greater than 4294967296 indicates that the Exchange Server computer has more than 4 gigabytes (GB) of memory installed while a value for TotalPhysicalMemory greater than 6442450944 indicates that the Exchange Server computer has more than 6 GB of memory installed. On a computer with 4 GB or more of physical memory, Exchange Server will not use any more than 3 GB. Therefore, if the computer is dedicated to running Exchange Server only, there is no benefit to installing more than 4 GB of memory.

More importantly, the more physical RAM that is present, the more operating system kernel address entries are needed to perform the necessary virtual to physical mapping. This reduces both the free system page table entries (PTEs) and the paged pool memory available to the system which could cause instability.

As an example, a computer with 8 GB of physical RAM will have 3,000 fewer free system page table entries (PTEs) and a 30 MB reduction in the maximum paged pool size than a computer with only 4 GB of physical RAM.

It is recommended that you follow one of these two solutions:

  • Reduce the amount of memory in the system to 4 GB

  • Set the BurnMemory parameter in the Boot.ini file to reduce the physical memory to 4 GB, as described later in this article.

Additionally, if you are running multiple applications that require the extra memory, you can run a Windows hotfix that will help prevent Exchange information store failures that could occur when there is more than 4 GB of RAM available. Note that the recommended best practice is to dedicate a computer to run Exchange Server only. For details about the hotfix, see the Microsoft Knowledge Base article 834628, "Data is corrupted when PAE is enabled on a Windows Server 2003-based computer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834628).

To correct this warning

  1. In Windows Explorer, navigate to the system partition.

  2. If you are unable to see the boot.ini file, it could be because the Folder Options are set to Hide protected operating system files. If this is the case, in Windows Explorer, click Tools, Folder Options, and then click the View tab. Clear the Hide protected operating system files (Recommended) check box. When prompted with the warning box, click Yes.

  3. Once the boot.ini file is visible in Explorer, right-click the file, click Open With, and choose Notepad to open the file.

  4. In the [Operating Systems] section, add the following switch to the startup line: /BURNMEMORY=<Value in MB>

    For example:

    If there is 6GB of physical memory installed, use /BURNMEMORY=2048 to reduce the available memory to 4GB. If there is 8GB of physical memory installed, use /BURNMEMORY=4096.

  5. Save the changes and close Notepad.

  6. Reboot the Exchange Server computer for the change to take effect.

For more information about the parameters that can be used in the Boot.ini file, see the following Microsoft Knowledge Base articles:

  • 833721: "Available switch options for the Windows XP and Windows Server 2003 Boot.ini files" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833721)

  • 102873: "BOOT.INI and ARC Path Naming Conventions and Usage" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=102873)


This logical disk has less than 3 GB of available space
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2007-03-14

The Microsoft® Exchange Server Analyzer Tool queries the Win32_LogicalDisk Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the FreeSpace key for disks that have the Win32_LogicalDisk DriveType key set to 3 (which indicates a local disk). If the value for the FreeSpace key for a local disk in an Exchange Server computer is less than 3 GB, a warning is displayed. It is recommended that all disks in Exchange Server computers that contain mailboxes have at least 50 percent capacity free at all times.

Having sufficient disk capacity is critical. When a database disk runs out of space, the database will go offline. When a transaction log disk runs out of space, it will cause all of the databases in that storage group to go offline. Provisioning additional space is often hard to do quickly, and performing offline compaction to reclaim space can take a long time. In most cases, running out of disk space results in an interruption of availability of one or more databases for a period of time that typically exceeds most recovery time objectives (RTO).

To correct this warning

  1. Delete unnecessary files from this disk to free up disk space.

  2. If the disk that has less than 50 percent space free contains data that can be safely moved to another disk (such as mailboxes, or the Windows pagefile), perform the steps that are required to move the data.

  3. Add disk capacity to the Exchange Server computer.

For more information about moving mailboxes with Exchange Server 2003, see the Microsoft Knowledge Base article 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829).

For more information about moving mailboxes between Exchange 2000 Server and Exchange Server 5.5, see the Knowledge Base article 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810).

For more information about setting mailbox limits with system policy on Exchange Server 2003, see the Knowledge Base article 822938, "HOW TO: Use System Policies to Configure Mailbox Storage Limits in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822938).

For more information about setting mailbox limits with system policy on Exchange 2000 Server, see the Knowledge Base article 319130, "HOW TO: Use System Policies to Configure Mailbox Storage Limits in Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319130).

For more information about


This mountpoint has less than 3 GB of available space
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Volume Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FreeSpace key for volume mount points used by the Exchange Server computer. If the value for FreeSpace, when divided by 1,000,000,000 and rounded up to the nearest whole number, is less than 4, a warning is displayed.

This warning indicates that less than 3 gigabytes (GB) of storage space is available for a volume mount point. In Exchange Server 2003, volume mount points (also known as NTFS file system junction points) are supported as a location for data storage in a clustered configuration when Exchange Server 2003 is installed on a computer running Microsoft Windows Server™ 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition. With the NTFS Volume Mount Points feature, you can surpass the 26-drive-letter limitation. By using volume mount points, you can graft, or mount a target partition into a folder on another physical disk. Volume mount points are transparent to programs such as Exchange Server 2003.

Mount points are not supported in the following scenarios:

  • When they are used as a storage location for the Exchange Server 2003 binaries.

  • When they are used with Exchange clusters that are running Microsoft Exchange 2000 Server or earlier.

  • When they are used with Windows clusters that are running Microsoft Windows 2000 Server or earlier.

Regardless of whether a volume used by Exchange Server is a local physical disk, a logical volume, or a volume mount point, best practices for Exchange Server implementations are to have at least 50 percent free disk space available on all drives. As a general rule of thumb, Microsoft recommends a minimum of 25 to 30 percent of free disk space for Exchange maintenance such as tasks performed using database utilities such as Eseutil and Isinteg. In addition, for some maintenance operations, such as offline defragmentation, Microsoft recommends that you have 100 percent more free space than the amount you are defragmenting. For example, if you are defragmenting a 1 GB database, you should have at least 1 GB of free disk space available.

Having plenty of free disk space is also beneficial from a both a security and an availability perspective. A denial of service attack, a message loop, or a virus outbreak that is widespread can cause excessive consumption of disk space due to increased message traffic, transaction log activity, and so forth.

To correct this warning

  1. Investigate areas to reclaim disk space and increase available space.

  2. If disk space is extremely low, you should consider moving data to another Exchange Server computer or Exchange Virtual Server that is not space constrained. If not already done, setting mailbox limits can also be useful in managing disk utilization.

For more information about using volume mount points in an Exchange Server 2003 cluster, see the Microsoft Knowledge Base article 318458, "Volume Mount Point Support for an Exchange Server 2003 Cluster on a Windows Server 2003-based System" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=318458).

For more information about using volume mount points in a Windows Server 2003 cluster, see the Knowledge Base article 280297, "How to configure Volume Mount Points on a clustered server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=280297).


This network card is DHCP-enabled
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the DHCPEnabled property. If the value for this property on an Exchange server is one (1), an error is displayed.

Running Exchange on a DHCP-enabled network card is a supported configuration. However, this configuration is not recommended. Running Exchange on DHCP-enabled computers is not a best practice because if the DHCP service fails or is interrupted, Exchange may stop delivering mail or may otherwise fail.

It is recommended that you configure all computers running Exchange to use static IP addresses.

For more information about designing Windows TCP/IP networks, see the Microsoft TechNet Networking Web site (http://go.microsoft.com/fwlink/?LinkId=33819).


The primary WINS server address is blank
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the WINSPrimaryServer key. If the Exchange Server Analyzer finds the value for this key on an Exchange server to be blank, a warning is displayed.

Exchange Server 2003 and Exchange 2000 Server have several NetBIOS dependencies. Additionally, clients running versions of Microsoft Outlook® that are earlier than Microsoft Office Outlook 2003 also require NetBIOS name resolution. For example, the following Exchange functionality depends on NetBIOS name resolution:

  • The Exchange Server 2003 and Exchange 2000 Server Setup programs, especially on clustered servers.

  • Exchange Mailbox Merge Wizard (ExMerge) on an Exchange Server 2003 or Exchange 2000 Server computer.

  • Changing a password for an Exchange Server 2003 or Exchange 2000 Server mailbox through Outlook Web Access.

  • Exchange System Manager on an Exchange Server 2003 or Exchange 2000 Server computer.

Depending on your organization's network topology, you may be able to safely ignore this warning. On networks that are made up of a single subnet, NetBIOS broadcasts typically can handle the NetBIOS name resolution requirements of an Exchange deployment.

In large organizations, NetBIOS name resolution through broadcasts may not function correctly. Because NetBIOS broadcasts typically do not cross subnets, routed networks require an alternate method for resolving NetBIOS names. The preferred method to do this is Windows Internet Name Service (WINS). WINS provides a distributed database for registering and querying dynamic mappings of NetBIOS names for computers and groups used on your network. WINS maps NetBIOS names to IP addresses and was designed to solve the problems arising from NetBIOS name resolution in routed environments. WINS is the best choice for NetBIOS name resolution in routed networks that use NetBIOS over TCP/IP.

Exchange Server 2003 and Exchange 2000 Server operations and functions in a large or sub-netted organization without WINS have not been fully tested. Microsoft requires companies running Exchange on routed or segmented networks to use WINS for NetBIOS name resolution. Running Exchange in a routed or segmented environment without WINS is not supported.

It is recommended that a fault-tolerant WINS environment that includes at least two WINS servers be deployed. WINS servers can act as either a primary WINS server or a secondary WINS server to a client. The difference between primary and secondary WINS servers is just the priority in which clients contact them. A primary WINS server is the first server a client contacts to perform its NetBIOS name service operations. A client contacts a secondary WINS server only when a primary WINS server cannot fulfill the request, for example, if it is unavailable when the client makes the request or you cannot resolve a name for the client.

If a primary WINS server does not fulfill a request, the client makes the same request of its secondary WINS server. If more than two WINS servers are configured for the client, the client tries the additional secondary WINS servers until the list is exhausted or one of the WINS servers successfully responds to the request. After a client uses a secondary WINS server, it periodically tries to switch back to its primary WINS server for future name service requests.

It is a best practice to configure at least one secondary WINS server on Exchange server computers on a routed or segmented network.

To correct this warning

  1. Open Network Connections.

  2. Right-click the network connection you want to configure, and then click Properties.

  3. On the General tab (for a local area connection) or the Networking tab (for all other connections), click Internet Protocol (TCP/IP), and then click Properties.

  4. Click Advanced, click the WINS tab, and then click Add.

  5. In TCP/IP WINS server, type the IP address of the WINS server, and then click Add.

  6. Repeat steps 4 and 5 for each additional WINS server IP address you want to add, and then click OK. You can change the order of preference for WINS servers by using the arrow keys.

  7. Make sure Enable NetBIOS over TCP/IP is selected.

  8. Click OK to save your changes.

For more information about the NetBIOS name resolution requirements for Exchange, see the Knowledge Base article 837391 "Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=837391).


Virtual Server detected
Microsoft Exchange Server Analyzer - Articles > Hardware >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine whether the value for the Model key is set to Virtual Machine.

The Exchange Server Analyzer also checks for the presence of the following registry value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

If the Exchange Server Analyzer finds that the Model key contains the string Virtual Machine, and the above registry branch exists, an error is displayed.

A value of Virtual Machine for the Model key indicates that the Exchange Server computer is running as a guest virtual machine on either Microsoft Virtual Server 2005 or Microsoft Virtual PC 2004. Because the above registry branch is only created by Virtual Server 2005, its existence means that the Exchange Server computer is running as a guest virtual machine in Virtual Server 2005.

Microsoft does not support running any version of Microsoft Exchange Server on a virtual machine or on an emulator. This is true for Exchange Server running on Microsoft Virtual Server 2005, Microsoft Virtual PC 2004, or any third-party virtual machine program. Microsoft Exchange Server platforms are designed and tested to run only on physical hardware, particularly those hardware platforms that are listed in the Microsoft Windows Server Catalog (http://go.microsoft.com/fwlink/?linkid=17219).

To correct this error

  1. Move the mailboxes from the Exchange Server running under Virtual Server 2005 to a non-virtual Exchange Server computer.

  2. Re-home any public folders and transfer any roles held by the virtual Exchange server as necessary.

  3. Uninstall Exchange from the virtual machine to decommission and remove from your Exchange infrastructure and from the Active Directory® directory service.

For more information about moving mailboxes, see the following Microsoft Knowledge Base articles:

  • 822892, "Move Mailbox improvements in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 224975, "XADM: Differences Between Move Mailbox Methods" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

For more information about Microsoft Virtual Server 2005, see the Microsoft Virtual Server 2005 Web site (http://go.microsoft.com/fwlink/?LinkId=34938).

For more information about Microsoft Virtual PC 2004, see the Microsoft Virtual PC 2004 Web site (http://go.microsoft.com/fwlink/?linkid=34663).


Network
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2005-11-18

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating with regard to the network. Additionally, these articles describe actions that you can take to resolve network-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


DNS 'Host' Record Appears to Be Missing
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2006-04-13

The Microsoft® Exchange Server Analyzer Tool performs a Domain Name System (DNS) lookup on the DNS server to retrieve the Host (A) record of the Exchange server. If the DNS lookup operation does not return an IP address, the Exchange Server Analyzer displays a warning that the Host (A) record appears to be missing.

The DNS lookup of the Host (A) record from the Exchange Server 2003 computer could fail for the following reasons:

  • The DNS server maybe down or not responding because of a network failure or other reasons.

  • The Host (A) record for Exchange Server 2003 could be missing on the DNS server because the record may not be available, may be incorrect, or the DNS server may not be configured to allow dynamic host record updates.

When the DNS server is down, there can be mail routing delays and other service failures.

Note:
Exchange Server 2003 relies on host name resolution for both local and external SMTP-based messaging systems in the network. Host name resolution is based primarily on DNS, and DNS is a critical network service. The failure of a DNS server can prevent users from locating your messaging system. Active Directory and the Exchange Server 2003 organization cannot function without DNS. Messaging clients will query DNS to locate internal resources, such as domain controllers and mailbox servers. Exchange Server 2003, on the other hand, relies on DNS to retrieve Internet Protocol (IP) addresses of domain controllers for directory lookups and external Simple Mail Transfer Protocol (SMTP) hosts when Exchange Server 2003sends messages to the Internet.

To fix the issue, verify that the DNS server is running and that the Host (A) record is registered.

To verify that the DNS server is online and that the Host record is present

  1. Verify that the DNS server is running by performing one or more of the following steps:

    • Examine the DNS server status by using the DNS Administration program on the DNS server.

    • Restart the DNS server. For more information, see "Start, stop, pause, or restart a DNS server" (http://go.microsoft.com/fwlink/?LinkId=62999).

    • Examine the DNS server responsiveness by using nslookup. For more information, see "Verify DNS server responsiveness using the nslookup command" (http://go.microsoft.com/fwlink/?LinkId=63000).

  2. Use nslookup to verify that the Host (A) record exists on the DNS server. For more information, see "To verify A resource records exist in DNS" (http://go.microsoft.com/fwlink/?LinkId=63001).

  3. If the Host (A) resource record does not exist, manually add or modify the A resource record or configure the DNS server to allow dynamic record updates

    • Manually add an A resource record. For more information, see "Add a resource record to a DNS zone" (http://go.microsoft.com/fwlink/?LinkId=63002).

    • Manually modify an A resource record. For more information, see "Modify an existing resource record" (http://go.microsoft.com/fwlink/?LinkId=63014).

    • Enable DNS server to allow dynamic host record updates. For more information, see Microsoft Knowledge Base article 816592, "How to configure DNS dynamic updates in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592).
  • For information about how Exchange Server 2003 uses DNS to resolve external IP addresses, see "Transport Dependencies for Exchange Server 2003" in the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • For information about DNS name resolution, see Microsoft Knowledge Base article 322856, "How to configure DNS to use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856).

  • For information about how to troubleshoot DNS, see "Troubleshooting DNS" (http://go.microsoft.com/fwlink/?LinkId=63003).

For information about Exchange Server 2003 system monitoring, see "System Monitoring with Exchange Server 2003 Management Pack" in the Exchange Server 2003 Management Pack Guide for MOM 2000 SP1 (http://go.microsoft.com/fwlink/?LinkId=47573).

  • For information about Host (A) resource records, see "Managing resource records" (http://go.microsoft.com/fwlink/?LinkId=63004).


DNS responses are different between UDP and TCP
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2007-03-16

The Microsoft Exchange Analyzer tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows Management Instrumentation (WMI) class to obtain the DNSServerSearchOrder attribute. This attribute is an array of server IP addresses to be used in querying for Domain Name System (DNS) servers.

After retrieving the address of the primary DNS server, the Exchange Analyzer attempts a DNS query against the configured DNS servers for each Active Directory directory service server. This connection is made by using a custom object processor that performs both a (TCP) Transmission Control Protocol and a User Datagram Protocol (UDP) name resolution request.

If both the TCP and UDP name resolution requests are successful, the Exchange Analyzer compares the returned responses of the successful requests. If the returned responses of the TCP and UDP queries are not the same, the Exchange Analyzer displays a warning.

This warning indicates that there may be DNS server configuration issues that are affecting mail flow performance.

Simple Mail Transfer Protocol (SMTP) is the native mail protocol for mail submission and mail transport for Exchange Server. This means that clients use SMTP to send messages and Exchange servers use SMTP to deliver messages and message data.

For Exchange Server to deliver an outbound internet message via the SMTP service, DNS is employed by the following method:

  1. An internal user sends a message to a recipient in a remote domain.

  2. To determine whether the recipient is local or remote, the SMTP virtual server on the sender's Exchange server uses internal transport functions to query the global catalog server for the recipient address. If the recipient address on the message is not in a recipient policy, it is not stored in Active Directory. Therefore, Exchange determines that the message is destined for a remote domain.

  3. If it is necessary, the Exchange server delivers the message to the appropriate SMTP virtual server.

  4. The SMTP virtual server uses its IIS metabase information to determine the method for delivering a message to a remote domain.

  5. The SMTP virtual server on the Exchange server then performs one of two actions:

    • Uses DNS to look up the IP address for the target domain, and then tries to deliver the message.

    • Forwards the message to a smart host that assumes responsibility for the DNS resolution and delivery of the message.

To address this warning, consider the guidance in Microsoft Knowledge Base article 820284, "Mail may not be delivered to certain domains if Server OS is Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=820284).

For more information about DNS and Exchange Server, see the following Microsoft Knowledge Base articles and WebCast:

  • 322856, "How to configure DNS for use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 263237, "XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 324759, "Support WebCast: Microsoft Exchange 2000 Server: DNS Troubleshooting in Transports" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324759)


DNS server is running Virtual Server 2005 with Exchange Server installed as a Guest
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine if the value for the Model key is set to Virtual Machine.

The Exchange Server Analyzer also checks for the presence of the following registry value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

Additionally, the Exchange Server Analyzer queries the Win32_Services WMI class to determine if the Domain Name System service (DNS) is running on the physical computer that is running Microsoft Virtual Server 2005.

If the Exchange Server Analyzer finds that the Model key contains the string Virtual Machine, and that the above registry branch exists, and DNS is running, an error is displayed.

A value of Virtual Machine for the Model key indicates that the Exchange Server computer is running as a guest virtual machine on either Virtual Server 2005 or Microsoft Virtual PC 2004. Because the above registry branch is only created by Virtual Server 2005, its existence means that the Exchange Server computer is running as a guest virtual machine in Virtual Server 2005.

Microsoft does not support running any version of Microsoft Exchange Server on a virtual machine or on an emulator. This is true for Exchange Server running on Virtual Server 2005, Virtual PC 2004, or any third-party virtual machine program. Microsoft Exchange Server platforms are designed and tested to run only on physical hardware, particularly those hardware platforms that are listed in the Windows Server Catalog (http://go.microsoft.com/fwlink/?linkid=17219).

Further, running Exchange as a Virtual Server 2005 guest on a computer running Domain Name System is not a best practice in that it does not allow for adequate redundancy across services.

To correct this error

  1. Move the mailboxes from the Exchange Server running under Virtual Server 2005 to a non-virtual Exchange Server computer.

  2. Re-home any public folders and transfer any roles held by the virtual Exchange server as necessary.

  3. Uninstall Exchange from the virtual machine to decommission and remove from your Exchange infrastructure and from the Active Directory® directory service.

For more information about moving mailboxes, see the following Microsoft Knowledge Base articles:

  • 822892, "Move Mailbox improvements in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 224975, "XADM: Differences Between Move Mailbox Methods" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

For more information about support for Exchange Server computers running in virtual environments, see the Knowledge Base article, 320220, "Support Boundaries for Exchange Server on a Virtual Machine or an Emulation Machine" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220).

For more information about Microsoft Virtual Server 2005, see the Microsoft Virtual Server 2005 Web site (http://go.microsoft.com/fwlink/?linkid=34938).

For more information about Microsoft Virtual PC 2004, see the Microsoft Virtual PC 2004 Web site (http://go.microsoft.com/fwlink/?linkid=34663).


External DNS Server Responses are Different Between UDP and TCP
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2007-03-16

The Microsoft Exchange Analyzer tool queries the Active Directory directory service to determine the value for the msExchSmtpExternalDNSServers attribute in the protocolCfgSMTPServer class for each Exchange Server object. The value of the msExchSmtpExternalDNSServers attribute, if set, specifies the address of the external Domain Name System (DNS) server that the Simple Mail Transfer Protocol (SMTP) Virtual Server Instance uses.

After retrieving the address of the primary external DNS server, the Exchange Analyzer attempts a DNS query against the configured DNS servers for each Active Directory directory service server. This connection is made by using a custom object processor that performs both a Transmission Control Protocol (TCP) and a User Datagram Protocol (UDP) name resolution request.

If both the TCP and UDP name resolution requests are successful, the Exchange Analyzer compares the returned responses of the successful requests. If the returned responses of the TCP and UDP queries are not the same, the Exchange Analyzer displays a warning.

This warning indicates that there may be external DNS server configuration issues that are affecting mail flow performance.

SMTP is the native mail protocol for mail submission and mail transport for Exchange Server. This means that clients use SMTP to send messages and Exchange servers use SMTP to deliver messages and message data.

For Exchange Server to deliver an outbound internet message via the SMTP service, DNS is employed by the following method:

  1. An internal user sends a message to a recipient in a remote domain.

  2. To determine if the recipient is local or remote, the SMTP virtual server on the sender's Exchange server uses internal transport functions to query the global catalog server for the recipient address. If the recipient address on the message is not in a recipient policy, it is not stored in Active Directory. Therefore, Exchange determines that the message is destined for a remote domain.

  3. If necessary, the Exchange server delivers the message to the appropriate SMTP virtual server.

  4. The SMTP virtual server uses its IIS metabase information to determine the method for delivering a message to a remote domain.

  5. The SMTP virtual server on the Exchange server then performs one of two actions:

    • Uses DNS to look up the IP address for the target domain, and then attempts to deliver the message.

    • Forwards the message to a smart host that assumes responsibility for the DNS resolution and delivery of the message.

To address this warning, see Microsoft Knowledge Base article 820284, "Mail may not be delivered to certain domains if Server OS is Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=820284).

For more information about DNS and Exchange Server, see the following Microsoft Knowledge Base articles and WebCast:

  • 322856, "How to configure DNS for use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 263237, "XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 324759, "Support WebCast: Microsoft Exchange 2000 Server: DNS Troubleshooting in Transports" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324759)


Network Bytes Total per second beyond threshold
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Bytes Total/sec performance counter of the Network Interface performance object to analyze performance data.

The Bytes Total/sec performance counter shows the rate at which the network adapter is processing data bytes. This counter includes all application and file data, in addition to protocol information, such as packet headers. The Bytes Total/sec performance counter is the sum of the Network Interface\Bytes Received/sec and Network Interface/Bytes Sent/sec.

The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. For a 100 megabits per second (Mbps) network adapter, the value of the Bytes Total/sec performance counter should be under 7 megabytes/second. For a 1000 Mbps network adapter, the value of the Bytes Total/sec performance counter should be under 70 megabytes/second. If Bytes Total/sec exceeds 7 percent of the bandwidth of the network, the Exchange Server Analyzer displays an error.

This error usually indicates that the server is experiencing periods of unresponsiveness, causing mail flow to slow down or stop. Additionally, Microsoft Outlook® clients who connect to this server may receive the RPC cancel Request dialog box.

The following are some of the possible causes of this error:

  • A network interface card (NIC) on the computer cannot support the maximum bandwidth supported by your network infrastructure.

  • There is too much load on the server.

  • Viruses or SPAM are causing sudden elevated network usage patterns.

To resolve this error,

  • If a NIC is does not support the maximum bandwidth of your network, upgrade the NIC to support a faster bandwidth.

  • Reduce the load on the server. You can do this by moving mailboxes to a server that has fewer mailboxes. If it is required, add an additional Exchange server to your environment.

  • If you suspect that the unusually high load is not caused by too many mailboxes on a server, try to identify the source of the unusually high load and stop it.

  • Consider the best practices in the following articles:

    • For information about network bandwidth considerations, see Network Performance in "Understanding Exchange Performance" in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

    • For information about troubleshooting network problems, see "Ruling Out Network-Bound Problems" in Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Network interface card (NIC) teaming is enabled
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2006-10-16

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapter Microsoft Windows® Management Instrumentation (WMI) class for all network interface cards (NIC) that are bound to the TCP/IP protocol.

The Exchange Server Analyzer then queries the following registry branch to determine whether the TeamAdapters key exists for those adapters:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\%NICDEVICEID%\

If the Exchange Server Analyzer determines that the TeamAdapters key exists for one or more NIC on the server that is being analyzed, the Exchange Server Analyzer displays a warning.

This warning indicates that NIC teaming is enabled on the Exchange server that is being analyzed. Although NIC teaming is generally not a mail flow issue, care should be taken to make sure that teaming is configured correctly with the most recent NIC drivers available.

To address this issue:

  • If mail flow issues occur on the server that has NIC Teaming enabled, temporarily disable Teaming to see whether the mail flow issue is resolved.

  • Update the NIC drivers to the latest available from the NIC manufacturer.

  • Strictly follow the Teaming configuration recommendations of the NIC manufacturer.

For more information about NIC teaming, see the following Microsoft Knowledge Base articles:

  • 278431, "Using teaming adapters with network load balancing may cause network problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=278431).

  • 814607, "Microsoft support for server clusters with third-party system components" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=814607).


Network Outbound Packets beyond threshold
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects. The performance data collection engine collects data from the Packet Outbound errors performance counter of the Network Interface performance object to analyze performance data.

The Packet Outbound errors performance counter indicates the number of outgoing packets that could not be transmitted because of error. The value of the Packet Outbound errors performance counter should be zero. If the Exchange Server Analyzer determines that the Packet Outbound errors performance counter has a value greater then zero, the Exchange Server Analyzer displays an error.

This error usually indicates that the server is experiencing periods of unresponsiveness, causing mail flow to slow down or stop. Additionally, Microsoft Outlook® clients who connect to this server may receive the RPC cancel Request dialog box.

This error is most likely caused by a faulty or damaged network interface card (NIC).

To resolve this error, you must determine the cause of the outgoing packet errors, and then correct the problem. If the outgoing packet errors are caused by a faulty NIC, replace the card immediately.

Consider the best practices in the following articles:

  • For information about network bandwidth considerations, see Network Performance in "Understanding Exchange Performance" in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For information about troubleshooting network problems, see "Ruling Out Network-Bound Problems" in Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Network Output Queue length beyond threshold
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2007-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Output Queue Length performance counter of the Network Interface performance object to analyze performance data.

The Output Queue Length performance counter shows the length of the output packet queue, in packets. The Exchange Server Analyzer reports the maximum value for the performance counter during the collection interval. If the average value exceeds 10, the Exchange Server Analyzer displays an error.

This error usually indicates that the server is experiencing periods of unresponsiveness, causing mail flow to slow down or stop. Additionally, Outlook clients who connect to this server may receive the RPC cancel Request dialog box.

The following are some of the possible causes of this error:

Note:
In certain circumstances, on a machine running the Microsoft Windows 2000 Server operating system, the Output Queue Length performance counter may consistently show a random value that is greater than zero. For more information about the circumstances in which the Output Queue Length performance might display the random value, and how to correct this, see Microsoft Knowledge Base article 834940, "System Monitor may display high values for the Output Queue Length performance counter in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834940).
  • A network interface card (NIC) on the computer cannot support the maximum bandwidth supported by your network infrastructure.

  • There is too much load on the server.

  • Viruses or SPAM are causing sudden elevated network usage patterns.

Take the following steps to resolve this error:

  • If NIC is does not support the maximum bandwidth of your network, upgrade the NIC to support a faster bandwidth.

  • Reduce the load on the server. You can do this by moving mailboxes to a server that has fewer mailboxes. If it is required, add an additional Exchange server to your environment.

  • If you suspect that the unusually high load is not caused by too many mailboxes on a server, try to identify the source of the unusually high load and stop it.

Consider the best practices in the following articles:

  • For information about network bandwidth considerations, see Network Performance in "Understanding Exchange Performance" in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For information about troubleshooting network problems, see "Ruling Out Network-Bound Problems" in Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Primary DNS failed to respond to a UDP connection
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2007-03-16

The Microsoft Exchange Analyzer tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows Management Instrumentation (WMI) class to obtain the DNSServerSearchOrder attribute. This attribute is an array of server IP addresses to be used in querying for DNS servers.

After retrieving the address of the primary Domain Name System (DNS) server, the Exchange Analyzer attempts a DNS query against the configured DNS servers for each Active Directory directory service server. This connection is made by using a custom object processor that performs a User Datagram Protocol (UDP) name resolution request and analyzes the results.

If the UDP name resolution request fails, the Exchange Analyzer displays a warning.

This warning indicates that the primary DNS server may be configured to accept only TCP queries.

Simple Mail Transfer Protocol (SMTP) is the native mail protocol for mail submission and mail transport for Exchange Server. This means that clients use SMTP to send messages and Exchange servers use SMTP to deliver messages and message data.

For Exchange Server to deliver an outbound internet message via the SMTP service, DNS is employed by the following method:

  1. An internal user sends a message to a recipient in a remote domain.

  2. To determine whether the recipient is local or remote, the SMTP virtual server on the sender's Exchange server uses internal transport functions to query the global catalog server for the recipient address. If the recipient address on the message is not in a recipient policy, it is not stored in Active Directory. Therefore, Exchange determines that the message is destined for a remote domain.

  3. If it is necessary, the Exchange server delivers the message to the appropriate SMTP virtual server.

  4. The SMTP virtual server uses its IIS metabase information to determine the method for delivering a message to a remote domain.

  5. The SMTP virtual server on the Exchange server then performs one of two actions:

    • Uses DNS to look up the IP address for the target domain, and then tries to deliver the message.

    • Forwards the message to a smart host that assumes responsibility for the DNS resolution and delivery of the message.

By default, DNS servers listen on UDP socket 53 for communications such as name resolution queries.

If the SMTP services on the Exchange Server are configured to only send UDP queries and the Primary DNS server is configured to only accept TCP queries, mail routing failures can occur that may adversely affect mail flow performance.

To address this warning, do the following:

  1. Make sure that the DNS server has been started and that it is connected to the network.

  2. Verify that a network firewall or packet filter is not intentionally blocking well-known DNS ports such as UDP port 53.

  3. Verify that the primary DNS server is configured to support UDP name resolution queries.

For more information about DNS and Exchange Server, see the following Microsoft Knowledge Base articles and WebCast:

  • 322856, "How to configure DNS for use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 263237, "XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 324759, "Support WebCast: Microsoft Exchange 2000 Server: DNS Troubleshooting in Transports" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324759)


Primary DNS server is unreachable
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows® Management Instrumentation (WMI) class to obtain the DNSServerSearchOrder attribute. This attribute is an array of server IP addresses to be used in querying for DNS servers. After retrieving the address of the primary DNS server, the Exchange Server Analyzer opens a TCP socket connection to port 53 on the server. This connection is made by using a custom object processor that returns a specific string if the connection is successful. If the Exchange Server Analyzer does not receive 53 Available as part of the returned string, a warning is displayed.

This warning indicates that the server did not respond to a connection attempt on TCP port 53. By default, DNS servers listen on TCP socket 53 for communications such as name resolution queries.

If the primary DNS server is unreachable and you are running Exchange 2000 Server, mail delivery will be slow. A supported hotfix is available from Microsoft to correct the problem of message delivery to external recipients being slower than expected when the primary DNS server is not available. Contact Microsoft Product Support Services to obtain this hotfix.

Additionally, you will want to troubleshoot why the primary DNS server is not available, or change the DNS settings on the Exchange server to use a different DNS server for name resolution.

To correct this warning

  1. Make sure that the DNS server has been started, and that it is connected to the network.

  2. Use the PING command to determine whether the DNS server is reachable.

For more information about slow mail delivery when the primary DNS server is not available, as well as how to obtain a hotfix for this issue, see the Microsoft Knowledge Base article 829722, "Mail delivery is slow in Exchange 2000 when the primary DNS server is not available" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829722).

For more information about DNS and Exchange Server, see the following Knowledge Base articles and WebCast:

  • 322856, "How to configure DNS for use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 263237, "XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 324759, "Support WebCast: Microsoft Exchange 2000 Server: DNS Troubleshooting in Transports" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324759)


Primary External DNS Server Failed to Respond to a TCP Connection
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2007-03-16

The Microsoft Exchange Analyzer tool queries the Active Directory directory service to determine the value for the msExchSmtpExternalDNSServers attribute in the protocolCfgSMTPServer class for each Exchange Server object. The value of the msExchSmtpExternalDNSServers attribute, if set, specifies the address of the external Domain Name System (DNS) server that the Simple Mail Transfer Protocol (SMTP) Virtual Server Instance uses.

After retrieving the address of the primary external DNS server, the Exchange Server Analyzer opens a TCP socket connection to port 53 on the server. This connection is made by using a custom object processor that returns a specific string if the connection is successful. If the Exchange Server Analyzer does not receive 53 Available as part of the returned string, a warning is displayed.

This warning indicates that the server did not respond to a connection attempt on TCP port 53. By default, DNS servers listen on TCP socket 53 for communications such as name resolution queries.

SMTP is the native mail protocol for mail submission and mail transport for Exchange Server. This means that clients use SMTP to send messages and Exchange servers use SMTP to deliver messages and message data.

For Exchange Server to deliver an outbound internet message via the SMTP service, DNS is employed by the following method:

  1. An internal user sends a message to a recipient in a remote domain.

  2. To determine if the recipient is local or remote, the SMTP virtual server on the sender's Exchange server uses internal transport functions to query the global catalog server for the recipient address. If the recipient address on the message is not in a recipient policy, it is not stored in Active Directory. Therefore, Exchange determines that the message is destined for a remote domain.

  3. If necessary, the Exchange server delivers the message to the appropriate SMTP virtual server.

  4. The SMTP virtual server uses its IIS metabase information to determine the method for delivering a message to a remote domain.

  5. The SMTP virtual server on the Exchange server then performs one of two actions:

    • Uses DNS to look up the IP address for the target domain, and then attempts to deliver the message.

    • Forwards the message to a smart host that assumes responsibility for the DNS resolution and delivery of the message.

If the primary external DNS server is unreachable and you are running Exchange 2000 Server, mail delivery will be slow. A supported hotfix is available from Microsoft to correct the problem of message delivery to external recipients being slower than expected when the primary external DNS server is not available. Contact Microsoft Product Support Services to obtain this hotfix.

Additionally, you will want to troubleshoot why the primary external DNS server is not available, or change the DNS settings on the Exchange server to use a different DNS server for name resolution.

To correct this warning, do the following:

  1. Make sure that the external DNS server has been started, and that there is connectivity to it from the Exchange network.

  2. Use the PING command to determine whether the external DNS server is reachable.

For more information about slow mail delivery when the primary DNS server is not available, as well as how to obtain a hotfix for this issue, see the Microsoft Knowledge Base article 829722, "Mail delivery is slow in Exchange 2000 when the primary DNS server is not available" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829722).

For more information about DNS and Exchange Server, see the following Knowledge Base articles and WebCast:

  • 322856, "How to configure DNS for use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 263237, "XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 324759, "Support WebCast: Microsoft Exchange 2000 Server: DNS Troubleshooting in Transports" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324759)


Primary External DNS Failed to Respond to a UDP Connection
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2007-03-16

The Microsoft Exchange Analyzer tool queries the Active Directory directory service to determine the value for the msExchSmtpExternalDNSServers attribute in the protocolCfgSMTPServer class for each Exchange Server object. The value of the msExchSmtpExternalDNSServers attribute, if set, specifies the address of the external Domain Name System (DNS) server that the Simple Mail Transfer Protocol (SMTP) Virtual Server Instance uses.

After retrieving the address of the primary external DNS server, the Exchange Analyzer attempts a DNS query against the configured external DNS servers for each Active Directory directory service server. This connection is made by using a custom object processor that performs a User Datagram Protocol (UDP) name resolution request and analyzes the results.

If the UDP name resolution request fails, the Exchange Analyzer displays a warning.

This warning indicates that the primary external DNS server may be configured to accept only TCP queries.

SMTP is the native mail protocol for mail submission and mail transport for Exchange Server. This means that clients use SMTP to send messages and Exchange servers use SMTP to deliver messages and message data.

For Exchange Server to deliver an outbound internet message via the SMTP service, DNS is employed by the following method:

  1. An internal user sends a message to a recipient in a remote domain.

  2. To determine whether the recipient is local or remote, the SMTP virtual server on the sender's Exchange server uses internal transport functions to query the global catalog server for the recipient address. If the recipient address on the message is not in a recipient policy, it is not stored in Active Directory. Therefore, Exchange determines that the message is destined for a remote domain.

  3. If it is necessary, the Exchange server delivers the message to the appropriate SMTP virtual server.

  4. The SMTP virtual server uses its IIS metabase information to determine the method for delivering a message to a remote domain.

  5. The SMTP virtual server on the Exchange server then performs one of two actions:

    • Uses DNS to look up the IP address for the target domain, and then tries to deliver the message.

    • Forwards the message to a smart host that assumes responsibility for the DNS resolution and delivery of the message.

By default, DNS servers listen on UDP socket 53 for communications such as name resolution queries.

If the SMTP services on the Exchange server are configured to only send UDP queries and the primary external DNS server is configured to only accept TCP queries, mail routing failures can occur that may adversely affect mail flow performance.

To address this warning, do the following:

  1. Make sure that the external DNS server has been started, and that there is connectivity to it from the network.

  2. Verify that a network firewall or packet filter is not intentionally blocking well-known DNS ports such as UDP port 53.

  3. Verify that the primary external DNS server is configured to support UDP name resolution queries.

For more information about DNS and Exchange Server, see the following Microsoft Knowledge Base articles and WebCast:

  • 322856, "How to configure DNS for use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 263237, "XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 324759, "Support WebCast: Microsoft Exchange 2000 Server: DNS Troubleshooting in Transports" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324759)


Primary WINS server failed to respond
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NetworkAdapterConfiguration Microsoft Windows® Management Instrumentation (WMI) class to obtain the WINSPrimaryServer attribute. This attribute is the IP address of the primary Windows Internet Name Service (WINS) server for the Exchange Server computer. After the Exchange Server Analyzer retrieves the address of the primary WINS server, the Exchange Server Analyzer opens a TCP socket connection to port 137 on the server. This connection is made by using a custom object processor that returns a specific string if the connection is successful. If the Exchange Server Analyzer does not receive 137 Available as part of the returned string, the Exchange Server Analyzer displays a warning.

This warning indicates that the server did not respond to a connection attempt on TCP port 137. By default, WINS servers listen on TCP socket 137 for communications such as name resolution queries.

If the primary WINS server is unreachable and you are running Exchange Server, mail delivery will be slow, especially in larger organizations. You should troubleshoot why the primary WINS server is not available, or change the WINS settings on the Exchange server to use a different WINS server for name resolution.

To correct this warning

  1. Make sure that the WINS server has been started and is connected to the network.

  2. Use the PING command to determine whether the WINS server is reachable.

For information about why WINS is required for Exchange 2000 Server and Exchange Server 2003, see the Microsoft Knowledge Base article 837391, "Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=837391).


Port 389 failed to respond
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the dNSHostName attribute for all domain controllers in Active Directory. After retrieving the names of the domain controllers, the Exchange Server Analyzer opens a TCP socket connection to port 389 on each domain controller. This connection is made by using a custom object processor that returns a specific string if the connection is successful. If the Exchange Server Analyzer does not receive 389 Available as part of the returned string, a warning is displayed.

This warning indicates that the domain controller did not respond to a connection attempt on TCP port 389. TCP port 389 is the default port for Lightweight Directory Access Protocol (LDAP) communications.

If you are receiving this warning, it could be because of connectivity issues between the Exchange Server Analyzer and the domain controller. There are many reasons why LDAP requests may not be properly serviced by a domain controller when the Exchange Server Analyzer queries it.

To correct this warning

  1. Verify that the account running the tool is authorized to query the domain controller. You will need User level permissions in the domain where the domain controller is running. More information about permissions required to run the Exchange Server Analyzer can be found in the Help file included with the tool. Open the Help file by opening the Exchange Server Analyzer, clicking Help, and then clicking Microsoft Exchange Server Analyzer Tool Help.

  2. Verify that there are no firewalls or port restrictions between the computer running the Exchange Server Analyzer and the domain controller that failed to respond.

  3. Verify that the domain controller is connected to the network and functioning properly.

For more information about troubleshooting Active Directory connectivity issues, see the Microsoft Knowledge Base article 816103, "HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816103).

For more information about configuring Microsoft Windows® Time on domain controllers, see the Knowledge Base article 816042, " How to configure an authoritative time server in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816042).


Port 636 failed to respond
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the dNSHostName attribute of all domain controllers in Active Directory. After retrieving the names of the domain controllers, the Exchange Server Analyzer opens a TCP socket connection to port 636 on each domain controller. This connection is made by using a custom object processor that returns a specific string if the connection is successful. If the Exchange Server Analyzer does not receive 636 Available as part of the returned string, a warning is displayed.

This warning indicates that the domain controller did not respond to a connection attempt on TCP port 636. TCP port 636 is the default port for Secure Lightweight Directory Access Protocol (LDAP over SSL) communications.

With the introduction of Exchange 2000 Server Service Pack 3, Exchange Server will connect with LDAP over SSL if a valid certificate exists in the local certificate store on the Exchange Server computer. If such a certificate does not exist, or if a certificate-related error is returned (for example, the domain controller does not trust the Exchange certificate, or the certificate being used requires strong-key protection), Exchange Server will automatically fall back to LDAP without SSL. If you are receiving this warning, it could be because of connectivity issues between the Exchange Server Analyzer and the domain controller. Public Key Infrastructure (PKI) or other certificate issues will not be exposed by this warning.

There are many reasons why LDAP over SSL requests may not be properly serviced by a domain controller when the Exchange Server Analyzer queries it.

To correct this warning

  1. Verify that the account running the tool is authorized to query the domain controller. You will need User level permissions in the domain where the domain controller is running. More information about permissions required to run the Exchange Server Analyzer can be found in the Help file included with the tool. Open the Help file by opening the Exchange Server Analyzer, clicking Help, and then clicking Microsoft Exchange Server Analyzer Tool Help.

  2. Verify that there are no firewalls or port restrictions between the computer running the Exchange Server Analyzer and the domain controller that failed to respond.

  3. Verify that the domain controller is connected to the network and functioning properly.

  4. Verify that the time on the computer running the Exchange Server Analyzer and the domain controller that failed to respond is synchronized. If the Microsoft Windows® Time Service on the domain controller is stopped or disabled, the domain controller local time may be out of synchronization. In this case, the domain controller will not respond to LDAP over SSL requests until its clock is synchronized.

For more information about using LDAP over SSL, see the Microsoft Knowledge Base article 321051, "How to enable LDAP over SSL with a third-party Certification Authority" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=321051).

For more information about troubleshooting Active Directory connectivity issues, see the Knowledge Base article 816103, "HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816103).

For more information about the Windows Time Service, see the Knowledge Base article, 816042, "How to configure the Windows Time service on a Windows Server 2003-based forest root PDC master computer" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816042).


SMTP server does not support X-LINK2STATE verb
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool initiates an SMTP session with the Exchange server to validate that the proper Exchange SMTP verbs are listed. If the X-LINK2STATE verb is not listed, a warning is displayed.

The X-LINK2STATE verb is used by Exchange to update the link state tables on the routing masters. The link state tables record up-to-date information about the status of the SMTP links throughout the Exchange organization. Exchange uses this information to pick the lowest cost and most reliable routes when routing messages. This functionality is also referred to as "Intelligent Routing."

The X-LINK2STATE verb is required by Exchange for efficient routing, and is not used by other SMTP providers. As such, the functionality is provided in a file (xlsasink.dll) that is installed and registered by Exchange Setup.

There are two known reasons why this warning may be returned. First, some administrators may have disabled xlsasink.dll as a way to work around the intelligent routing functionality it provides. This is not a recommended best practice and will likely lead to performance and reliability problems. In this case, it is recommended that you reinstall Exchange on the affected computer to install and register xlsasink.dll.

Secondly, this warning may be returned if you are running an antivirus product that installs and uses its own SMTP protocol stack to scan messages. In this case, the antivirus software may run its own SMTP stack that intercepts and scans messages before they reach the Exchange SMTP stack. In this case, the antivirus SMTP stack is not using X-LINK2STATE verb. It is recommended that you run the antivirus software in a mode that does not require it to install its own SMTP stack on the Exchange server.

For more information about X-LINK2STATE and other proprietary verbs used by Exchange, see the Microsoft Knowledge Base article 812455, "Definitions of Verbs That Are Used Between 2 Exchange Servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=812455).

For more information about how to view Exchange command verbs and reinstall Exchange 2000 Server, see the Knowledge Base article 319885, "XCON: Messages Sent in the Exchange 2000 Server Organization Are Not Delivered" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319885).

For more information about how to view Exchange command verbs and reinstall Exchange Server 2003, see the Knowledge Base article 822939, "Messages That Are Sent in the Exchange Server 2003 Organization Are Not Delivered" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822939).


SMTP server failed mail acceptance test
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool tries to send a message to the Postmaster account for the Simple Mail Transfer Protocol (SMTP) domain by performing the following tasks:

  • Opening a socket connection to the SMTP server. If the Exchange Server Analyzer receives a response code of 220, this step is considered to have completed successfully.

  • Transmitting the EHLO SMTP command verb. If the Exchange Server Analyzer receives a series of response codes of 250, including a response that includes 250-X-LINK2STATE and 250-XEXCH50, this step is considered to have completed successfully.

  • Transmitting the MAIL FROM: ExBPA-MailAcceptTest@Fabrikam.com SMTP command verb. If the Exchange Server Analyzer receives a response code of 250, this step is considered to have completed successfully.

  • Transmitting the RCPT TO: Postmaster@<domainname>.com SMTP command verb. If the Exchange Server Analyzer receives a response code of 250, this step is considered to have completed successfully.

If the Exchange Server Analyzer cannot successfully complete all steps, an error is displayed. The error indicates that there may be a general mail flow issue. The following links are listed in the order in which you should troubleshoot, starting at the server level and working out to the network level.

To correct this error

  1. See "Troubleshooting Routing" in the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?linkid=47579).

  2. See Microsoft Knowledge Base article 324867, "Support WebCast: Microsoft Exchange 2000 Server: Troubleshooting Mail Flow Problems (Revisited)" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324867).

  3. See Microsoft Knowledge Base article 823489, "How to Use Queue Viewer to Troubleshoot Mail Flow Issues" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823489).

  4. See Microsoft Knowledge Base article 324759, "Support WebCast: Microsoft Exchange 2000 Server: DNS Troubleshooting in Transports" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759).

For more information about the Postmaster account in Exchange Server, see the following Microsoft Knowledge Base articles:

  • 223860, "XCON: SMTP Postmaster Mailbox Must Be Set Manually" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=223860)

  • 313832, "HOW TO: Set an SMTP Postmaster Account in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=313832)


SMTP server failed open relay test
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2007-03-14

The Microsoft® Exchange Server Analyzer Tool tries to relay a message through a Simple Mail Transfer Protocol (SMTP) server by performing the following tasks:

  • Opening a socket connection to the SMTP server. If the Exchange Server Analyzer receives a response code of 220, this step is considered to have completed successfully.

  • Transmitting the EHLO SMTP command verb. If the Exchange Server Analyzer receives a series of response codes of 250, including a response that includes 250-X-LINK2STATE and 250-XEXCH50, this step is considered to have completed successfully.

  • Transmitting the MAIL FROM: ExBPA-OpenRelayTest@Fabrikam.com SMTP command verb. If the Exchange Server Analyzer receives a response code of 250, this step is considered to have completed successfully.

  • Transmitting the RCPT TO: ExBPA-OpenRelayTest@Fabrikam.com SMTP command verb. If the Exchange Server Analyzer receives a response code of 250, this step is considered to have completed successfully.

The Exchange Server Analyzer also queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the OSProductSuite key. The value of this key corresponds to a specific version of a Windows Server operating system.

If the Exchange Server Analyzer can successfully complete all steps on an Exchange Server computer that is part of a Microsoft Small Business Server 2000 or Microsoft Windows Small Business Server 2003 installation, an error is displayed.

The error indicates that this server is configured as an open relay.

It is not a recommended best practice to allow open relay.

Open relay occurs when an e-mail server permits e-mail messages to be relayed through the system without exercising any restrictions or any control over the relayed e-mail.

Note:
If for some reason your Exchange organization uses an SMTP domain named Fabrikam.com, you may encounter this error. In this event, you may be able to safely ignore this error. The Fabrikam.com domain is owned by Microsoft Corporation and is used for training, documentation, and similar purposes.

Relay is not inherently bad, because SMTP was designed for this purpose (for more information, see the RFC 2821 document, sections 2.1 and 3.7 (http://ietf.org)). However, if relay is not controlled (an uncontrolled host is known as an open relay host), a malicious user might potentially use relay to send bulk, unsolicited commercial e-mail messages (spam or UCE). By bouncing these unsolicited e-mail messages off an intermediate host, the malicious user tries to obfuscate their identity. This also ties up resources on the relay host and may keep the relay host from sending valid e-mail messages. In particular, most users who send such unsolicited e-mail messages can send a single message to an extraordinary number of recipients without using their own bandwidth to do this.

Make sure that you do not allow anonymous relaying on your Internet-facing SMTP virtual servers. In its default configuration, Exchange allows only authenticated users to relay mail. Only authenticated users can use Exchange to send mail to an external domain. If you modify the default relay settings to allow unauthenticated users to relay, or if you allow open relaying to a domain through a connector, unauthorized users or malicious worms can use your Exchange server to send spam. Your server may be block-listed and be prevented from sending mail to legitimate remote servers. To prevent unauthorized users from using your Exchange server to relay mail, at a minimum, use the default relay restrictions.

If you have legitimate reasons for relaying, follow the guidelines for making sure that security is preserved in your implementation. This is mainly done by leaving the deny all defaults and adding only the IP addresses from which you will accept relayed mail, and disabling access for authenticated users.

Review how built-in accounts (local Administrator) and other users are used on your gateway servers. It is unlikely that you are using the built-in accounts for any kind of relaying. If you are relaying, the relaying is probably by a known set of users or computers. Restricting relay rights to explicit users and computers or to an IP address is recommended.

Configuring explicit permission to relay will additionally help fortify your server. Malicious users may use a brute-force attack to try to obtain the passwords for built-in accounts or for user accounts found on the Internet so that they can use your server as a spam proxy. Therefore, the default setting that allows any authenticated computer to relay is not recommended for computers that are accessible from the Internet. Disabling this setting is recommended.

The following procedures explain how to disable anonymous relaying based on whether the SMTP virtual server is Internet-facing. As mentioned earlier in this article, enabling any form of anonymous relay should be done only in cases where the security risk is understood and acceptable to your organization. The references at the end of this article provide more information about how to use relaying.

If an SMTP virtual server is not accessible from the Internet, it is recommended that you reset the relay configurations to the default values. This will result in SMTP virtual servers that allow only internal relaying from authenticated computers.

For SMTP virtual servers that are accessible from the Internet, it is recommended that you additionally secure the default relay configurations, so that only users and computers with explicit permission are allowed to relay.

If you have verified that Exchange is configured to block relaying and you are still receiving this error in the Exchange Server Analyzer, you should verify that any proxy server or process, such as firewall, antivirus, or anti-spam software is not allowing anonymous relaying.

To reset anonymous relay configurations to the default settings on internal SMTP virtual servers

  1. Open Exchange System Manager.

  2. In the console tree, expand Servers, expand the server that you want, expand Protocols, and then expand SMTP.

  3. Right-click the SMTP virtual server on which you want to apply relay restrictions, and then click Properties.

  4. In <SMTP Virtual Server> Properties, click the Access tab, and then click Relay.

  5. In Relay Restrictions, under Select which computer may relay through this virtual server, select Only the list below, select the Allow all computers which successfully authenticate to relay, regardless of the list below check box, and then click OK.

To configure explicit relay permission on Internet-facing SMTP Virtual Servers in Exchange Server 2003

  1. Open Exchange System Manager.

  2. In the console tree, expand Servers, expand the server that you want, expand Protocols, and then expand SMTP.

  3. Right-click the SMTP virtual server on which you want to apply relay restrictions, and then click Properties.

  4. In <SMTP Virtual Server> Properties, click the Access tab, and then click Relay.

  5. In Relay Restrictions, clear the Allow all computers which successfully authenticate to relay, regardless of the list below check box, and then click Users to specify a subset of users that you want to grant relay permissions on this SMTP virtual server.

  6. In Permissions for Submit and Relay, to remove a user or group, select the group or user, and then click Remove.

  7. To add a group or user, click Add, and then select the users or group for which you want to specify permissions. Select from one of the following options:

    • On Microsoft Windows Server™ 2003, in Select Users, Computers or Groups, under Enter the object name to select, type the name of the user or the group. If you want to search for the user or group, click Advanced, search for the user or group name, and then click Check Names to validate your entry.

      Tip:
      Click the examples link to view the acceptable formats for your entries.
    • On Windows 2000 Server, in Select Users, Computers or Groups, select the group or user that you want to grant submit permissions, and then click Add.

  8. Click OK to return to the Permissions for Submit and Relay dialog box.

  9. Under Group or user names list, select the group you just added.

  10. Under Permissions for <selected group>, next to Submit Permission, if necessary, select the check box under Allow to allow the selected user or group to submit mail through this SMTP virtual server.

  11. Next to Relay Permissions, select the check box under Allow to permit the selected object to relay through this SMTP virtual server, or select the check box under Deny to prevent the selected object from relaying through this virtual server.

    Note:
    You must allow Submit Permissions if you want to allow Relay Permissions.

  12. Click OK.

To configure relay permissions on Internet-facing SMTP Virtual Servers in Exchange 2000 Server

  1. Open Exchange System Manager.

  2. In the console tree, expand Servers, expand the server you want to configure, expand Protocols, and then expand SMTP.

  3. Right-click the SMTP virtual server on which you want to apply relay restrictions, and then click Properties.

  4. In <SMTP Virtual Server> Properties, click the Access tab, and then click Relay.

  5. In Relay Restrictions, under Select which computer may relay through this virtual server, select Only the list below.

  6. Click Add to add a single computer, group of computers or an SMTP domain name, and then click OK. Repeat this step for each additional entry you want to add.

  7. Select Allow all computers which successfully authenticate to relay, regardless of the list above check box, and then click OK twice.

For more information about message relaying and security see the following guides from the Exchange Server 2003 Technical Library:

  • Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?linkid=47579).

  • Slowing and Stopping E-mail Transmitted Viruses in an Exchange 2003 Environment (http://go.microsoft.com/fwlink/?linkid=47587)

For more information about testing and securing open relay behavior in your Exchange and Microsoft Windows environment, see the Microsoft Knowledge Base article 304897, "SMTP relay behavior in Windows 2000, Windows XP, and Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=304897).


The version of SMTP running does not support the XEXCH50 verb
Microsoft Exchange Server Analyzer - Articles > Network >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool initiates an SMTP session with the Exchange server to validate that the proper Exchange SMTP verbs are listed. If the XEXCH50 verb is not listed, a warning is displayed.

Among other things, the XEXCH50 verb is used by Exchange for public folder replication. Running a version of SMTP on an Exchange server that does not support the XEXCH50 verb will break public folder replication.

The XEXCH50 verb is not used by other SMTP providers; therefore, the functionality is provided in a file (peexch50.dll) that is installed and registered by Exchange Setup.

The Exchange Server Analyzer may return this warning if you are running an antivirus product that installs and uses its own SMTP protocol stack to scan messages. In this case, the antivirus software uses its own SMTP stack to intercept and scan messages before they reach the Exchange SMTP stack. In this case, the SMTP stack in the antivirus software is not using the XEXCH50 verb.

It is recommended that you run the antivirus software in a mode that does not require it to install its own SMTP stack on the Exchange server or run such software at the incoming perimeter of your SMTP network. If you have disabled the SMTP stack for the antivirus software, and you still get this warning, reinstall Exchange to install and register peexch50.dll properly.

For more information about XEXCH50 and other proprietary verbs used by Exchange, see the Microsoft Knowledge Base article 812455, "Definitions of Verbs That Are Used Between 2 Exchange Servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=812455).

For more information about how to view Exchange command verbs and reinstall Exchange 2000 Server, see the Knowledge Base article 319885, "XCON: Messages Sent in the Exchange 2000 Server Organization Are Not Delivered" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319885).

For more information about how to view Exchange command verbs and reinstall Exchange Server 2003, see the Knowledge Base article 822939, "Messages That Are Sent in the Exchange Server 2003 Organization Are Not Delivered" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822939).


Protocols
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2005-11-18

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating with regard to Internet protocols. Additionally, these articles describe actions that you can take to resolve Internet protocol-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


Active Directory round-trip response error
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class to determine the value (StatusCode key) that is returned from the Active Directory® directory service server. Win32_PingStatus returns an object with 24 properties that supply extensive details about the ping packets that the class sends.

If the Exchange Server Analyzer finds that the value for this key matches one of the values in the following table, an error is displayed.

The Exchange Server Analyzer displays the Active Directory server name and the corresponding StatusCode value that is returned with this error.

StatusCode value Meaning Description

11001

Buffer Too Small

This error is unlikely to be returned because the Exchange Server Analyzer is generating a standard request.

11002

Destination Net Unreachable

Request failed because the network that contains the destination computer is not reachable; no valid route exists to the destination computer.

For information, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11003

Destination Host Unreachable

Request failed because the destination computer is not reachable.

For information, see Active Directory server down or unreachable.

Alternatively, this error may be caused by a firewall between where the Exchange Server Analyzer is being run and the target domain controller, or even a DNS error.

For information, see the Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11004

Destination Protocol Unreachable

Request failed because the destination computer does not respond to the packet's protocol.

This error may be caused by a firewall between where the Exchange Server Analyzer is being run and the target domain controller.

11005

Destination Port Unreachable

Request failed because the port on the destination computer is not available.

For information, see the Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11006

No Resources

Request failed because of insufficient network resources.

For information, see the Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11007

Bad Option

Request failed because it contains an invalid option.

This error is unlikely to be returned because the Exchange Server Analyzer is generating a standard request.

11008

Hardware Error

Request failed because of a hardware error.

Validate that the domain controller is suitably operational by running your computer manufacturer's hardware health check tool.

11009

Packet Too Big

Request failed because the packet that contains the request is larger than the maximum transmission unit (MTU) of a node (router or gateway) located between the source and destination. The MTU defines the maximum size of a transmittable packet.

The request sent by the Exchange Server Analyzer is not bigger than 10 KB in size. Confirm that the routers and gateways in your organization are appropriately configured.

For information, see the Knowledge Base article 159211, "Diagnoses and Treatment of Black Hole Routers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211).

11010

Request Timed Out

Reply was not received within the allocated time. The default time allowed for replies is five seconds.

For information, see the Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11011

Bad Request

Request failed because it was encoded incorrectly.

This is unlikely to be returned because the Exchange Server Analyzer is generating a standard request.

11012

Bad Route

Request failed because there is no valid route between the source and destination computers.

For information, see the Knowledge Base article 325487,"How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11013

TimeToLive Expired Transit

Request failed because its Time to Live (TTL) value reached zero, which causes the forwarding node (router or gateway) to discard the packet.

For information, see the Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11014

TimeToLive Expired Reassembly

Request failed because the packet was divided into fragments for transmission and all fragments were not received within the time allocated for reassembly. RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) specifies 60 seconds as the time limit within which all packet fragments must be received.

For information, see the Knowledge Base article 325487,"How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11015

Parameter Problem

Request failed because a node (router or gateway) encountered problems while processing the packet header. This status occurs if, for example, the header contains invalid field data or an unrecognized option.

This is unlikely to be returned because the Exchange Server Analyzer is generating a standard request.

11016

Source Quench

Request failed because the packet was discarded. This occurs when the source computer's output queue has insufficient storage space, or when packets arrive at the destination too quickly to be processed.

This is unlikely to be returned because the Exchange Server Analyzer is generating a standard request.

11017

Option Too Big

Request failed because it contains an invalid option.

This is unlikely to be returned because the Exchange Server Analyzer is generating a standard request.

11018

Bad Destination

Request failed because the destination IP address cannot receive PING requests or should never appear in the destination address field of any IP datagram.

This may be caused by a firewall between where the Exchange Server Analyzer is being run and the target domain controller.

11032

Negotiating IPSEC

Request failed because an IPsec connection could be not negotiated.

11050

General Failure

Request failed for an unknown reason.

For information, see the Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).


Active Directory to Exchange Server round-trip response error
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-15

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class to determine the StatusCode key value that is returned from the Active Directory® directory service server. Win32_PingStatus returns an object that has 24 properties that supply extensive details about the ping packets that the class sends.

If the Exchange Server Analyzer finds that the value for this key matches one of the values in the following table, the Exchange Server Analyzer displays an error.

The Exchange Server Analyzer displays the Active Directory server name, the Exchange Server name, and the corresponding StatusCode value that is returned with this error.

StatusCode value Meaning Description

11001

Buffer Too Small

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11002

Destination Net Unreachable

Request failed because the network that contains the destination computer is not reachable. No valid route exists to the destination computer.

For more information, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11003

Destination Host Unreachable

Request failed because the destination computer is not reachable.

For more information, see Active Directory server down or unreachable.

Alternatively, this error may be caused by one of the following conditions:

  • A firewall between where the Exchange Server Analyzer is being run and the target domain controller.

  • A DNS error.

For more information, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11004

Destination Protocol Unreachable

Request failed because the destination computer does not respond to the packet's protocol.

This error may be caused by a firewall between where the Exchange Server Analyzer is being run and the target domain controller.

11005

Destination Port Unreachable

Request failed because the port on the destination computer is unavailable.

For more information, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11006

No Resources

Request failed because of insufficient network resources.

For more information, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11007

Bad Option

Request failed because it contains an invalid option.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11008

Hardware Error

Request failed because of a hardware error.

Validate that the domain controller is suitably operational by running the hardware health check tool supplied by the manufacturer of your computer.

11009

Packet Too Big

Request failed because the packet that contains the request is larger than the maximum transmission unit (MTU) of a router or gateway node that is located between the source and the destination. The MTU defines the maximum size of a transmittable packet.

The request sent by the Exchange Server Analyzer is not bigger than 10 KB. Confirm that the routers and gateways in your organization are appropriately configured.

For more information, see Microsoft Knowledge Base article 159211, "Diagnoses and Treatment of Black Hole Routers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211).

11010

Request Timed Out

Reply was not received in the allocated time. The default time allowed for replies is five seconds.

For more information, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11011

Bad Request

Request failed because it was encoded incorrectly.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11012

Bad Route

Request failed because there is no valid route between the source and destination computers.

For more information, see Microsoft Knowledge Base article 325487,"How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11013

TimeToLive Expired Transit

Request failed because the Time to Live (TTL) value reached zero. This causes the forwarding router or gateway node to discard the packet.

For more information, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11014

TimeToLive Expired Reassembly

Request failed because the packet was divided into fragments for transmission and all fragments were not received in the time allocated for reassembly. RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) specifies 60 seconds as the time limit within which all packet fragments must be received.

For more information, see Microsoft Knowledge Base article 325487,"How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11015

Parameter Problem

Request failed because a router or gateway node experienced problems when it processed the packet header. This can occur if the header contains invalid field data or an unrecognized option.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11016

Source Quench

Request failed because the packet was discarded. This occurs when the output queue of the source computer has insufficient storage space. Alternatively, it can occur when packets arrive at the destination too quickly to be processed.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11017

Option Too Big

Request failed because it contains an invalid option.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11018

Bad Destination

Request failed for one of the following reasons:

  • The destination IP address cannot receive PING requests.

  • The destination IP address should never appear in the destination address field of any IP datagram.

This may be caused by a firewall between where the Exchange Server Analyzer is being run and the target domain controller.

11032

Negotiating IPSEC

Request failed because an IPsec connection could not be negotiated.

11050

General Failure

Request failed for an unknown reason.

For more information, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).


Anonymous access is allowed on internal SMTP virtual servers and dedicated SMTP virtual servers for IMAP and POP clients
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchAuthenticationFlags attribute in the protocolCfgSMTPServer class for the Exchange Server object. The protocolCfgSMTPServer class contains the settings for an SMTP virtual server. The msExchAuthenticationFlags attribute represents the type of authentication that is allowed on the SMTP server. The Exchange Server Analyzer displays a warning message if the following conditions exist:

  • Authentication on the msExchAuthenticationFlags attribute has been configured to allow anonymous access to the SMTP server.

  • The server is not running Microsoft Small Business Server 2000 or Microsoft Windows® Small Business Server 2003.

  • The Exchange Server hosts more than 20 mailboxes.

For increased security, disable anonymous access on your internal SMTP virtual servers that do not accept incoming Internet mail. For increased security, you can also disable anonymous access on dedicated SMTP virtual servers for remote IMAP and POP users.

Important:
Do not disable anonymous access on your Internet bridgehead SMTP virtual servers. SMTP virtual servers that accept mail from the Internet must allow anonymous access.

When you send internal mail, Exchange servers in your organization authenticate with each other to send mail. Therefore, you do not have to enable anonymous access on your internal SMTP virtual servers. By preventing anonymous access on your internal servers, mail flow is not disrupted, and an additional layer of security is provided on your internal SMTP virtual server.

Similarly, IMAP and POP clients authenticate with your SMTP virtual servers before sending mail to SMTP virtual servers. Therefore, if you use dedicated SMTP virtual servers for your IMAP and POP clients, you can configure these servers to allow only authenticated access. If you disable anonymous access on these servers, you can help prevent unauthorized users from accessing them.

If you cannot disable authenticated access on your SMTP virtual server for business reasons, such as authentication by a partner company, follow these steps to help enhance security on your gateway server:

  • Enforce a strong password policy for all user accounts, particularly the administrator account.

  • Disable the guest account. For more information about disabling the guest account, see the Microsoft Knowledge Base article 320053, "How to rename the administrator and guest account in Windows 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=320053). Although this article applies to Windows 2000 Server, similar principles apply to Windows Server 2003.

To disable anonymous access authentication for an SMTP Virtual Server

  1. In Exchange System Manager, expand Servers, expand <your inbound Exchange server>, expand Protocols, and then expand SMTP.

  2. Right-click your inbound SMTP virtual server, and then click Properties.

  3. Click the Access tab, and then click Authentication.

  4. In Authentication, clear the Anonymous Access check box.

For more information about configuring your Exchange Server 2003 organization to send and receive Internet mail more securely, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Background antivirus scanning has been enabled
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if background antivirus scanning is enabled:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

If the Exchange Server Analyzer finds the value for the BackgroundScanning entry is set to 1, a warning is displayed.

When the BackgroundScanning registry entry is present and set to 1, all messages are rescanned in the background every time the antivirus program's signature file is updated. This behavior substantially impacts performance whenever an antivirus signature file is updated, and is therefore not recommended by Microsoft.

When you use a Virus Scanning Application Programming Interface (VSAPI) 2.0-based antivirus program and a client tries to open a message, a comparison is made to make sure that the message body and attachment have been scanned by the current virus signature file. If the current signature pattern file was not used to scan the content, the corresponding message is submitted to the antivirus program before that message is available to the client.

If the installed antivirus program does not include a user interface that allows you to disable background scanning, you can use the procedure below to control this behavior by modifying the registry on the Exchange Server computer.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

  3. In the right-hand pane, double-click the BackgroundScanning value.

  4. In the Value Data field, change the value to 0.

  5. Close the registry editor, and restart the Microsoft Exchange Information Store service, and your antivirus software services for the change to take effect.
  • Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

  • For more information on the different types of antivirus scanning programs used by Exchange, see the Knowledge Base article 328841, "Exchange and Antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).


CheckPop3Tail value has been changed
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the following registry value exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\CheckPop3Tail

If the Exchange Server Analyzer finds the CheckPop3Tail value present and configured with a value 1, a non-default configuration message is displayed.

Internet Engineering Task Force (IETF) Request for Comments (RFC) 1939 (http://www.ietf.org/rfc/rfc1939.txt) specifies a termination sequence of CRLF for POP3 messages. In Exchange parlance, the CRLF sequence is referred to as a POP3Tail. If a POP3 client, such as Microsoft Office Outlook® 2003 or Microsoft Outlook Express, encounters a malformed message with an incorrect POP3Tail (for example, a missing CRLF), it can stop responding and fail to download all the messages that are in the Inbox. The CheckPop3Tail registry value represents a configuration opportunity for administrators to instruct the Microsoft Exchange POP3 service to check the POP3Tail of each POP3 message, and add the correct termination sequence if it is missing.

Note:
This setting will correct malformed messages and enable the POP3 client to download all the messages in the user's Inbox; however, it will also cause slight performance degradation as each message will be checked for a proper POP3Tail.

If you want, you can use the procedure below to remove the CheckPop3Tail registry value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To delete the CheckPop3Tail registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. Delete the value called CheckPop3Tail.

  4. Close the registry editor and restart the Microsoft Exchange POP3 service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the use of the CheckPop3Tail registry value, see the Knowledge Base article 816896, "XCCC: POP3 Client Stops Responding (Hangs) or Times Out When You Try to Download Messages" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=816896).


Defense Message System is enabled
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the heuristics attribute has been configured to enable the Defense Message System. By default, the heuristics attribute is not configured. If the Exchange Server Analyzer finds that the heuristics attribute is set to 256, the Exchange Server Analyzer displays a non-default configuration message.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

The Defense Message System (DMS) Program was established by the Under Secretary of Defense (Acquisition) to facilitate and coordinate development of an integrated common-user message system that satisfies writer-to-reader requirements, reduces cost and staffing levels, and improves functionality, security, survivability, and availability.

For more information about the Defense Message System, see the Lockheed Martin Web site (http://www.lockheedmartin.com).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Disable MAPI clients warning
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2007-05-01

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether MAPI client blocking has been set:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Disable MAPI Clients

If the Exchange Server Analyzer finds that the value for Disabled MAPI Clients is set with a value that blocks all MAPI clients in the ranges of 6 through 9, the Exchange Server Analyzer displays a warning.

By default, the Disable MAPI Clients key is not enabled. By enabling this key an administrator can block specific versions of Microsoft Office Outlook® from connecting to a computer that is running Exchange 2000 Server, Exchange Server 2003, or Exchange Server 2007.

When the Disabled MAPI Clients key is set with a value that blocks MAPI clients in the range of 6 through 9, entire ranges of MAPI versions are blocked. These ranges correspond to the Outlook 2000, Outlook 2003, and Outlook 2007 versions and to Exchange System Attendant in Exchange Server 2003. Blocking the Exchange System Attendant service will likely cause Exchange Server to malfunction.

To fix this warning, follow the recommendations and procedure in All versions of Outlook are allowed to access the server.

For more information about blocking specific MAPI clients from connecting to a computer that is running Exchange 2000 Server or Exchange Server 2003, see the following Microsoft Knowledge Base articles:

  • 328240, "How to put server-side restrictions on clients that are used to access Exchange 2000 mailboxes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328240)

  • 288894, "How to disable MAPI client access to an Exchange Server 2003 computer or to an Exchange 2000 Server computer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=288894).

For more information about blocking specific MAPI clients from connecting to a computer that is running Exchange Server 2007, see the Exchange Management Shell "Set-CasMailbox" cmdlet in the Exchange Server 2007 product documentation (http://go.microsoft.com/fwlink/?LinkId=80698).

For more information about how to download security updates for older versions of Outlook and blocking other versions of Outlook, see Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment (http://go.microsoft.com/fwlink/?LinkId=30732).


DisableSMTPMailboxAddressing value is set
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-08-11

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the value is set to disable Simple Mail Transfer Protocol (SMTP) mailbox addressing:

HKeyLocalMachine\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\DisableSMTPMailboxAddressing

A value of 1 for the DisableSMTPMailboxAddressing key indicates that SMTP Mailbox Addressing is disabled (true) whereas a value of 0 indicates that SMTP mailbox addressing is not disabled (false).

If the Exchange Server Analyzer determines that the value of the DisableSMTPMailboxAddressing key is set to disable SMTP mailbox addressing with a value of 1, the Exchange Server Analyzer displays a warning.

This error indicates that SMTP mailbox addressing is disabled. This can cause synchronization errors for Microsoft Exchange ActiveSync clients that connect to this server.

To address this warning, set the value of the DisableSMTPMailboxAddressing key to 0.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To modify the value for the DisableSMTPMailboxAddressing key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

HKeyLocalMachine\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA

  1. In the right pane, locate and double-click DisableSMTPMailboxAddressing

  2. Change the value from 1 to 0.

  3. Close the registry editor, and restart the Server service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the synchronization error associated with this warning, see Microsoft Knowledge Base article 886346, "You receive an HTTP_500 error message when you synchronize your mobile device with Microsoft Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=886346).


Distribution of User Load
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool has determined that your server has a high RPC operations-per-second count.

If your server has a high RPC operations-per-second count, you can use the Exchange Server User Monitor (ExMon) to identify how the load is distributed. It is important to determine if the load is caused by one of the following circumstances:

  • There is a relatively small number of active users.

  • The load is distributed across many users.

If a single user is identified as causing a high percentage of the load, the Exchange Server Analyzer displays a warning stating that high usage can be traced back to a single user. If this is not the case, the Exchange Server Analyzer displays a message stating that the load is distributed across many users.

Note:
RPC traffic changes over time. Therefore, to capture statistically relevant data about how users use Exchange, you may need to collect data multiple times.

Additionally, it is typical that some common user operations will expend large amounts of CPU utilization for a short period of time. Do not be concerned about this activity unless the same user is expending large amounts of CPU utilization frequently or over long periods of time.

Note:
You can safely disregard this warning if the source of the high load is a known service or process that is expected to have high load and which processes requests for many users and generates a higher load than individual users. Some services that sync mobile devices, server processes that manage free busy, services related to voice mail or unified messaging, and server processes that move users are examples of services or processes that can cause higher load than individual users.
To correct this problem

  • If the RPC rate is high (for a single user or for everyone), find out if users have desktop search engines, third-party client plug-ins, or mobile devices that synchronize e-mail with the user's mailbox. For more information about troubleshooting third-party applications, see Turn Off Third-Party Add-ins on Client.

  • Users should have fewer than 5,000 items in the default and heavily used folders.

  • As a best practice, mailboxes should be 1 GB or less in size. For users who are causing the high load, it is recommended that they archive their mailbox items to a .pst file. Then you can run the Exchange Performance (Perfmon) tool again to see if the user is continually causing high load.

  • Contact the user to identify client applications that may be accessing the client e-mail program. Remove these applications and then reinstall them one at a time to observe their impact on the server.

  • False-positives are common when troubleshooting user load. Therefore, it is recommended that you run ExMon again during a time of high load to see if the analysis is consistent.

For More Information

  • To download the Exchange Server User Monitor (ExMon), see the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=54983).

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about troubleshooting Outlook client performance issues, see the Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803).

  • For more information about desktop search software, see the Microsoft Knowledge Base article 905184, "Exchange 2000 Server and Exchange Server 2003 performance may be affected when desktop search engine software is running on Outlook or other MAPI client computers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905184).


Exchange Virtual Directory for OMA and EAS has been overridden
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the SMTP proxy address for Exchange ActiveSync® has been overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MasSync\Parameters\ExchangeVDir

If the Exchange Server Analyzer finds the ExchangeVDir registry entry present and configured, a non-default configuration message is displayed.

The ExchangeVDir registry entry is used by Microsoft Outlook® Mobile Access and by Exchange ActiveSync. It specifies the virtual directory that Outlook Mobile Access and Exchange ActiveSync use to access Microsoft Office Outlook Web Access for Exchange Server 2003 templates and WebDAV on the Exchange Server 2003 back-end servers where user mailboxes are located.

If the ExchangeVDir entry does not exist, or if a value is not set for it, the default value of /Exchange is used. Otherwise, it contains the name of the virtual directory (including the forward slash character "/"). You can configure this value when you want to specify a virtual directory for Outlook Mobile Access or Exchange ActiveSync.

There is a known issue in Exchange Server 2003 where Exchange mobile services do not work when using forms-based authentication on a single Exchange Server 2003 computer topology. When the /Exchange virtual directory on an Exchange Server 2003 back-end server is configured to require Secure Sockets Layer (SSL), or when forms-based authentication is enabled, Outlook Mobile Access cannot access this virtual directory. This issue does not occur when you enable these settings in the /Exchange virtual directory on a front-end server.

A configuration opportunity exists to resolve this issue that involves the creation of the ExchangeVDir registry value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MasSync\Parameters

  3. Examine, and if desired, change the ExchangeVDir value.

  4. Close the registry editor. If a change is made, restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about resolving this issue, see the Knowledge Base article 817317, "Mapping Multiple Proxy Addresses to Multiple Back-End Virtual Root Directories on the Same Server Is Not Supported" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=817317).


An Exchange Virus Scanning API compatible product was detected, but it is not currently enabled
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Virus Scanning Application Programming Interface (VSAPI)-compliant software is enabled on the Exchange Server computer:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for Ese.dll, the Exchange Database Storage Engine, also known as the Extensible Storage Engine (ESE).

Finally, the Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects with an object class of msExchExchangeServer. If the string value includes "Version 5.5," the computer is running Microsoft Exchange Server 5.5. If the string value includes "Version 6.0," the computer is running Microsoft Exchange 2000 Server. If the string value includes "Version 6.5," the computer is running Microsoft Exchange Server 2003.

If the Exchange Server Analyzer finds the value for Version does not contain a substring of 6 as part of its version information, but the value for serialNumber indicates that Exchange 2000 Server or Exchange Server 2003 is installed, a non-Exchange version of the ESE is running on the Exchange Server.

If the Exchange Server Analyzer determines that a non-Exchange version of the ESE is not running, and the value for VirusScan \Enabled registry key is equal to 0, a warning is displayed. If the Exchange Server Analyzer determines that a non-Exchange version of the ESE is running on the Exchange Server, a separate warning is displayed.

It is generally recommended that you deploy antivirus software designed for messaging systems at the Simple Mail Transfer Protocol (SMTP) gateway or on the Exchange Server computers that host mailboxes. For the most protection, run antivirus software at the gateway that scans the inbound MIME messages and a scanner on the Exchange Server computer that uses VSAPI 2.0 (Exchange 2000 Server) or VSAPI 2.5 (Exchange Server 2003).

In addition, you should run antivirus software on the client computers. If you run 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 the client computers is sufficient.

To correct this warning

  1. In the antivirus software program user interface, enable VSAPI scanning.

  2. If the problem persists after enabling VSAPI scanning, contact your antivirus software vendor for assistance.

For more information about virus-scanning programs that are typically used with Microsoft Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

For more information about virus-scanning programs that are typically used with Microsoft Exchange 2000 Server, see the Knowledge Base article 328841, "Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

For more information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).


Exchange Virus Scanning API compatible product was detected, but it is not correctly installed
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Virus Scanning Application Programming Interface (VSAPI)-compliant software is running on the computer and has a valid library referenced:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

If the Exchange Server Analyzer finds the value for Library does not contain a valid path to a VSAPI antivirus library file (DLL), a warning is displayed.

It is generally recommended that you deploy antivirus software designed for messaging systems at the Simple Mail Transfer Protocol (SMTP) gateway or on the Exchange Server computers that host mailboxes. For the most protection, run antivirus software at the gateway that scans the inbound MIME messages and a scanner on the Exchange Server computer that uses VSAPI 2.0 (Exchange 2000 Server) or VSAPI 2.5 (Exchange Server 2003).

In addition, you should run antivirus software on the client computers. If you run 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 the client computers is sufficient.

To correct this warning

  1. Uninstall and then reinstall the antivirus software.

  2. If the problem persists after you reinstall the software, contact your antivirus software vendor for assistance.

For more information about virus-scanning programs that are typically used with Microsoft Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

For more information about virus-scanning programs that are typically used with Microsoft Exchange 2000 Server, see the Knowledge Base article 328841, "Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

For more information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).


Exchange Virus Scanning API has low thread count
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for ScanningThreads:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

The ScanningThreads registry value represents the maximum number of Virus Scanning API (VSAPI) threads that are allocated for scanning.

The Exchange Server Analyzer also reads the following registry entry to determine whether VSAPI message scanning is enabled:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

A value of 1 for Enabled indicates that VSAPI scanning is enabled. A value of 0 indicates VSAPI scanning is not enabled.

Additionally, the Exchange Server Analyzer queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value set for the NumberOfProcessors key. This value represents the number of processors installed on the computer, and it includes both physical processors and logical processors. Using Hyper-Threading technology from Intel, a physical processor can be split into two logical processors.

If the Exchange Server Analyzer finds that the value for ScanningThreads is less than (2 × NumberOfProcessors) + 1 on an Exchange Server computer that has VSAPI scanning enabled, a warning is displayed. The optimal value for ScanningThreads is equal to (2 × NumberOfProcessors) + 1. For example, on an Exchange Server computer with two processors, the optimal value for ScanningThreads is 5.

Note:
If Hyper-Threading is enabled, the value for NumberOfProcessors will be double the number of physical processors. It is recommended that you check with your antivirus software manufacturer to determine if physical or logical processors should be used in the above formula.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

  3. In the right pane, double-click ScanningThreads.

  4. Enter the value returned from the above formula.

  5. Close the registry editor, and then restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about Hyper-Threading technology, see the Intel Web site (http://www.intel.com/technology/hyperthread).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


External DNS server is used for SMTP
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchSMTPExternalDNSServers attribute in the protocolCfgSMTPServer class for the Exchange Server object. The protocolCfgSMTPServer class contains the settings for an SMTP virtual server. If the msExchSMTPExternalDNSServers attribute is set, the SMTP virtual server uses an external DNS server. If the Exchange Server Analyzer determines that the msExchSMTPExternalDNSServers attribute is set, a warning is displayed.

If you configure your SMTP virtual server to use an external DNS server, you may experience performance problems. Therefore, this configuration is not recommended.

To change the external DNS setting on an SMTP virtual server

  1. In Exchange System Manager, expand Servers, expand <your inbound Exchange server>, expand Protocols, and then expand SMTP.

  2. Right-click your SMTP virtual server, and then click Properties.

  3. Click the Delivery tab, and then click Advanced.

  4. Click Configure to configure external DNS servers.

  5. To add an external DNS server, click Add, type the IP address of the external DNS server in the Add dialog box, and then click OK.

  6. To remove an external DNS server, select an IP address, and then click Remove.

  7. Click OK.

For more information about configuring DNS in your Exchange Server 2003 organization, see "Configuring DNS" in the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about configuring SMTP connectors to link to Internet domains in Exchange, see the Microsoft Knowledge Base article 319426 "How To Configure the SMTP Connector to Link to Internet Domains in Exchange" (http://go.microsoft.com/fwlink/?Linkid=3052&kbid=319426).


Front-end server is using basic authentication
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether basic authentication is configured between a front-end server and a back-end server:

HKEY_LOCAL_MACHINE\CurrentControlSet\Services\MSExchangeWeb\DAV\UseBasicAuthToBE

If the Exchange Server Analyzer finds that the UseBasicAuthToBE key has been set, a non-default configuration message is displayed.

By default, Exchange Server 2003 front-end servers will use Kerberos authentication to help protect user credentials between the front-end and back-end servers. If Kerberos authentication fails, a Warning event will be logged and the front-end server will try NTLM instead. If NTLM fails, an error will be logged. Kerberos is tried again in 30 minutes. When Exchange 2000 Server or Exchange Server 2003 front-end computers authenticate with Exchange 2000 Server back-end computers, NTLM is used.

Setting the UseBasicAuthToBE registry key overrides this default logic and forces the Exchange front-end servers to use basic authentication for all communications with back-end servers. If you have more than 1,000 mailbox stores in your Exchange organization, you must set this registry key. A known issue exists where users who are accessing mailboxes from Microsoft Office Outlook® Web Access for Exchange Server 2003 through front-end servers in organizations with more than 1,000 mailbox stores cannot access their mailboxes.

If you do not have more than 1,000 mailbox stores, and you do not have a reason for forcing basic authentication, consider deleting the UseBasicAuthToBE registry key.

Basic authentication sends credentials in clear text. If you are running an Exchange front-end server with the UseBasicAuthToBE registry key set, it is highly recommended that you use IPSec encryption.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you that understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To delete the UseBasicAuthToBE registry key

  1. On the Exchange front-end server, open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Service\MSExchangeWeb\Dav\ UseBasicAuthToBE.

  3. Right-click UseBasicAuthToBE, click Delete, and then click Yes.

  4. Open the Services MMC snap-in, right-click IIS Admin Service, and then click Restart.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Gateway Server PING Unsuccessful
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class to determine the StatusCode key value that is returned from a non-Exchange gateway server. Win32_PingStatus returns an object that has 24 properties that supply extensive details about the ping packets that the class sends.

If the Exchange Server Analyzer finds that the value for this key matches one of the values in the following table, the Exchange Server Analyzer displays an error.

The Exchange Server Analyzer displays the gateway server name, the Exchange Server name, and the corresponding StatusCode value that is returned with this error.

StatusCode value Meaning Description

11001

Buffer Too Small

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11002

Destination Net Unreachable

Request failed because the network that contains the destination computer is not reachable. No valid route exists to the destination computer.

For information, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11003

Destination Host Unreachable

Request failed because the destination computer is not reachable.

For information, see Active Directory server down or unreachable.

Alternatively, this error may be caused by one of the following conditions:

  • A firewall between where the Exchange Server Analyzer is being run and the target domain controller.

  • A DNS error.

For information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11004

Destination Protocol Unreachable

Request failed because the destination computer does not respond to the packet's protocol.

This error may be caused by a firewall between where the Exchange Server Analyzer is being run and the target domain controller.

11005

Destination Port Unreachable

Request failed because the port on the destination computer is unavailable.

For information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11006

No Resources

Request failed because of insufficient network resources.

For information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11007

Bad Option

Request failed because it contains an invalid option.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11008

Hardware Error

Request failed because of a hardware error.

Validate that the domain controller is suitably operational by running the hardware health check tool supplied by the manufacturer of your computer.

11009

Packet Too Big

Request failed because the packet that contains the request is larger than the maximum transmission unit (MTU) of a router or gateway node that is located between the source and the destination. The MTU defines the maximum size of a transmittable packet.

The request sent by the Exchange Server Analyzer is not bigger than 10 KB. Confirm that the routers and gateways in your organization are appropriately configured.

For information, see Knowledge Base article 159211, "Diagnoses and Treatment of Black Hole Routers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211).

11010

Request Timed Out

Reply was not received in the allocated time. The default time allowed for replies is 5 seconds.

For information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11011

Bad Request

Request failed because it was encoded incorrectly.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11012

Bad Route

Request failed because there is no valid route between the source and destination computers.

For information, see Knowledge Base article 325487,"How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11013

TimeToLive Expired Transit

Request failed because its Time to Live (TTL) value reached zero. This causes the forwarding router or gateway node to discard the packet.

For information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11014

TimeToLive Expired Reassembly

Request failed because the packet was divided into fragments for transmission and all fragments were not received in the time allocated for reassembly. RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) specifies 60 seconds as the time limit within which all packet fragments must be received.

For information, see Knowledge Base article 325487,"How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11015

Parameter Problem

Request failed because a router or gateway node experienced problems when it processed the packet header. This can occur if the header contains invalid field data or an unrecognized option.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11016

Source Quench

Request failed because the packet was discarded. This occurs when the output queue of the source computer has insufficient storage space. Alternatively, it can occur when packets arrive at the destination too quickly to be processed.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11017

Option Too Big

Request failed because it contains an invalid option.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11018

Bad Destination

Request failed because of one of the following reasons:

  • The destination IP address cannot receive PING requests.

  • The destination IP address should never appear in the destination address field of any IP datagram.

This may be caused by a firewall between where the Exchange Server Analyzer is being run and the target domain controller.

11032

Negotiating IPSEC

Request failed because an IPsec connection could be not negotiated.

11050

General Failure

Request failed for an unknown reason.

For information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).


IIS 6.0 MaxFieldLength parameter not set correctly
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the maximum field length for HTTP requests has been hard-coded in the registry.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxFieldLength

The Exchange Server Analyzer also examines the following registry entry to determine the version of the Microsoft Windows® operating system that is running on the destination computer.

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the computer is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the computer is running a Microsoft Windows 2000 Server operating system, and a value of 5.2 indicates the computer is running a Microsoft Windows Server™ 2003 operating system.

Finally, the Exchange Server Analyzer examines the Exchange_Server Windows Management Instrumentation (WMI) class in the root\MicrosoftExchangeV2 namespace to determine the value for the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is a front-end server.

The Exchange Server Analyzer displays a warning if the Exchange Server Analyzer finds that the value for MaxFieldLength is not set to 32768 on an Exchange back-end server on which the following conditions are true:

  • The Exchange back-end server is running Windows Server 2003.

  • The Exchange back-end server is not configured as a front-end server.

  • The Exchange back-end server has more than 500 mailboxes.

The MaxFieldLength IIS registry parameter, which is not present by default, specifies the maximum size of any individual HTTP client request. This value is typically set in tandem with a companion value, MaxRequestBytes. In larger environments, if these values are not set to 32768, Microsoft Office Outlook® Web Access for Exchange Server users can experience logon failures. Specifically, the absence of these values can cause HTTP 400 - Bad Request errors. When configuring the MaxFieldLength registry value, you must also set the MaxRequestBytes parameter to 32768 to enable users who are members of more than 75 groups to log on to Outlook Web Access. The MaxRequestBytes registry value determines the upper limit for the total size of the Request line and the headers. If its value is lower than MaxFieldLength, the MaxFieldLength value is adjusted.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the MaxRequestBytes and MaxFieldLength parameters

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\HTTP\Parameters

  3. Right-click Parameters, click New | DWORD value, and name the value MaxFieldLength.

  4. Right-click Parameters, click New | DWORD value, and name the value MaxRequestBytes.

  5. In the right pane, double-click MaxFieldLength and set its value to 32768 (decimal).

  6. In the right pane, double-click MaxRequestBytes and set its value to 32768 (decimal).

  7. Close the registry editor and restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the HTTP registry settings for Internet Information Service (IIS), see the Knowledge Base article 820129, INF: Http.sys Registry Settings for IIS" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=820129).


IIS 6.0 MaxRequestBytes parameter not set correctly
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the maximum size for HTTP requests has been hard-coded in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes

The Exchange Server Analyzer also examines the following registry entry to determine the version of the Microsoft Windows® operating system that is running on the destination computer:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

A CurrentVersion value of 4.0 indicates the computer is running Microsoft Windows NT® Server 4.0. A value of 5.0 indicates the computer is running a Microsoft Windows 2000 Server operating system, and a value of 5.2 indicates the computer is running a Microsoft Windows Server™ 2003 operating system.

Finally, the Exchange Server Analyzer examines the Exchange_Server Windows Management Instrumentation (WMI) class in the root\MicrosoftExchangeV2 namespace to determine the value for the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is a front-end server.

The Exchange Server Analyzer displays a warning if the Exchange Server Analyzer finds that the value for MaxRequestBytes is set to 32768 on an Exchange back-end server on which the following conditions are true:

  • The Exchange back-end server is running Windows Server 2003.

  • The Exchange back-end server is not configured as a front-end server.

  • The Exchange back-end server has more than 500 mailboxes.

The MaxRequestBytes registry value, which is not present by default, determines the upper limit for the total size of the Request line and the headers. This value is typically set in tandem with a companion value, MaxFieldLength. The MaxFieldLength IIS registry parameter specifies the maximum size of any individual HTTP client request. In larger environments, if these values are not set to 32768, Microsoft Office Outlook® Web Access for Exchange Server users can experience logon failures. Specifically, the absence of these values can cause HTTP 400 - Bad Request errors. When configuring the MaxFieldLength registry value, you must also set the MaxRequestBytes parameter to 32768 to enable users who are members of more than 75 groups to log on to Outlook Web Access. If its value is lower than MaxFieldLength, the MaxFieldLength value is adjusted.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the MaxRequestBytes and MaxFieldLength parameters

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\HTTP\Parameters

  3. Right-click Parameters, select New | DWORD value, and then name the value MaxFieldLength.

  4. Right-click Parameters, select New | DWORD value, and then name the value MaxRequestBytes.

  5. In the right pane, double-click MaxFieldLength, and then set its value to 32768 (decimal).

  6. In the right pane, double-click MaxRequestBytes, and then set its value to 32768 (decimal).

  7. Close the registry editor and restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the HTTP registry settings for Internet Information Services (IIS), see the Knowledge Base article 820129, "INF: Http.sys Registry Settings for IIS" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=820129).


The IMAP4 Compatibility flag has been set in the registry
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the following registry value exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4Svc\Parameters\Compatibility

If the Exchange Server Analyzer finds the Compatibility value present and configured with a value of 0xfffffffe (in hexadecimal), a non-default configuration message is displayed.

Exchange Server Internet Protocol (IP) client computers that are using IMAP4 and Post Office Protocol version 3 (POP3) fully use the streaming store (.stm) file to read and write data. When an IP client requests a download of messages over POP3 or IMAP4, the Exchange information store that contains the user's mailbox will calculate the exact size of the messages in the Inbox to send to the client before transmitting the messages. In large environments, especially hosted Exchange environments, this can take a lot of time to calculate. The Compatibility value represents a configuration opportunity for administrators to instruct the Exchange store to use an approximate message size instead of exact calculations for message sizes.

The Compatibility registry value is available for the Exchange IMAP4 service, as described in this article, and for the Exchange POP3 service, as described in The POP3 Compatibility flag has been set in the registry.

The Compatibility registry value is also useful during a move of many mailboxes, or mailboxes with several MIME messages. When moving data, the data is promoted from the streaming store into the MAPI store (.edb file). Clients that use POP3 and IMAP4 to access their mailboxes may experience performance issues after you move their mailboxes between databases or servers. After the user logs on, message sizes must be calculated and MAPI-to-MIME conversion occurs in memory and on the disk of the server. In extreme cases, very large temporary files may be created on the Exchange Server computer when this behavior occurs.

Not all POP3 and IMAP4 mail clients may work correctly with the Compatibility registry value set. Changing this setting causes some older mail clients such as Fetchmail to break. Setting this registry key also breaks RFC-compliance for the IMAP4 protocol. If you are experiencing problems downloading messages with POP3 and IMAP4 and you are using the Compatibility registry value, you can delete it using the following procedure as a troubleshooting step for the message download problems.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To delete the Compatibility registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\IMAP4Svc\Parameters

  3. Delete the value called Compatibility.

  4. Exit the registry editor and restart the Microsoft Exchange Information Store service and the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the use of the Compatibility registry value, see the following Knowledge Base articles:

  • 317722, "XADM: Client Latencies Occur When Exchange 2000 Converts Mail from MAPI to MIME Format" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=317722)

  • 329067, "XADM: Move Mailbox Functionality Promotes Contents of .stm Files" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329067)


IMAP4 MaxBufferSize value has been changed
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2007-08-07

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the following registry value exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4Svc\Parameters\MaxBufferSize

If the Exchange Server Analyzer finds the MaxBufferSize value present and configured with any numeric value greater than 0, a non-default configuration message is displayed.

The MaxBufferSize registry value is used in an Exchange front-end/back-end topology. It defines the TCP/IP buffer size between front-end servers and back-end servers. The default buffer size is 1 kilobyte (KB). On networks with high latency, adjusting the MaxBufferSize value can improve performance for IMAP4 clients.

When setting the TCP/IP buffer size with the MaxBufferSize registry value, you should always set the buffer size in multiples of 1,024. It is recommended that you test your front-end/back-end server configuration performance with the following buffer sizes to determine the optimal value for your organization:

  • 8,192 bytes

  • 16,384 bytes

  • 32,768 bytes

It is recommended that you do not set the MaxBufferSize registry entry to a value greater than 32,768. However, you may notice increased performance with a buffer size value of 65,536, depending on your network conditions. A larger buffer size uses more memory on the Exchange Server computer and may decrease the number of users who can access the front-end server. While there is no limit to the maximum value that you can use for the MaxBufferSize registry value, you may experience unstable performance and memory issues if you assign too great a value to this registry entry.

Note:
To use the MaxBufferSize registry value, you must be running Exchange 2000 Server Service Pack 2 or later.

If the MaxBufferSize registry value is set too low, performance will not improve and the Exchange Server Analyzer will display an error message, as described in IMAP4 MaxBufferSize value is too low If the MaxBufferSize registry value is set too high, system instability could result and the Exchange Server Analyzer will display an error message, as described in IMAP4 MaxBufferSize value is too high

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the MaxBufferSize value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\IMAP4Svc\Parameters

  3. Create a new DWORD value called MaxBufferSize.

  4. Double-click the MaxBufferSize value and set it to the new buffer size (in bytes). For example, you can enter 8192 to set it to 8,192 bytes.

  5. Close the registry editor, and then restart the Microsoft Exchange IMAP4 service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about when and how to use the MaxBufferSize registry value, see the Knowledge Base article 823857, "XADM: IMAP4 and POP3 Performance Is Slow Between Front-End and Back-End Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857).


IMAP4 MaxBufferSize value is too high
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2007-08-07

The Microsoft® Exchange Server Analyzer Tool reads the registry on the Exchange Server computer to determine whether the following registry value exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4Svc\Parameters\MaxBufferSize

If the Exchange Server Analyzer finds the MaxBufferSize value present and configured with any numeric value more than 32768, a warning is displayed.

The MaxBufferSize registry value is used in an Exchange front-end/back-end topology. It defines the TCP/IP buffer size between front-end servers and back-end servers. The default buffer size is 1 kilobyte (KB). On networks with high latency, adjusting the MaxBufferSize value can improve performance for IMAP4 clients.

When setting the TCP/IP buffer size with the MaxBufferSize registry value, you should always set the buffer size in multiples of 1,024. It is recommended that you test your front-end/back-end server configuration performance with the following buffer sizes:

  • 8,192 bytes

  • 16,384 bytes

  • 32,768 bytes

When using this registry entry, it must be set to at least 1,024. It is recommended that you do not set the MaxBufferSize registry entry to a value greater than 32,768. However, you may notice increased performance with a buffer size value of 65536, depending on your network conditions. A larger buffer size uses more memory on the Exchange Server computer and may decrease the number of users who can access the front-end server. While there is no limit to the maximum value that you can use for the MaxBufferSize registry value, you may experience unstable performance and memory issues if you assign too great a value to this registry entry.

Note:
To use the MaxBufferSize registry value, you must be running Exchange 2000 Server Service Pack 2 or later.

If the MaxBufferSize registry value is set too low, performance will not improve and the Exchange Server Analyzer will display an error message, as described in IMAP4 MaxBufferSize value is too low. If the MaxBufferSize registry value is set too high, system instability could result and the Exchange Server Analyzer will display a message, as described in this article.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\IMAP4Svc\Parameters

  3. Create a new DWORD value called MaxBufferSize.

  4. Double-click the MaxBufferSize value and set it to the new buffer size (in bytes). For example, you can enter 8192 to set it to 8,192 bytes.

  5. Close the registry editor and restart the Microsoft Exchange IMAP4 service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about when and how to use the MaxBufferSize registry value, see the Knowledge Base article 823857, "XADM: IMAP4 and POP3 Performance Is Slow Between Front-End and Back-End Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857).


IMAP4 MaxBufferSize value is too low
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2007-08-07

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the following registry value exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4Svc\Parameters\MaxBufferSize

If the Exchange Server Analyzer finds the MaxBufferSize value present and configured with any numeric value greater than 0 but less than 1024, an error is displayed.

The MaxBufferSize registry value is used in an Exchange front-end/back-end topology. It defines the TCP/IP buffer size between front-end servers and back-end servers. The default buffer size is 1 kilobyte (KB). On networks with high latency, adjusting the MaxBufferSize value can improve performance for IMAP4 clients.

When setting the TCP/IP buffer size with the MaxBufferSize registry value, you should always set the buffer size in multiples of 1,024. It is recommended that you test your front-end/back-end server configuration performance with the following buffer sizes to determine the optimal value for your organization:

  • 8,192 bytes

  • 16,384 bytes

  • 32,768 bytes

When using this registry entry, it must be set to at least 1,024. It is recommended that you do not set the MaxBufferSize registry entry to a value greater than 32,768. However, you may notice increased performance with a buffer size value of 65,536, depending on your network conditions. A larger buffer size uses more memory on the Exchange Server computer and may decrease the number of users who can access the front-end server. While there is no limit to the maximum value that you can use for the MaxBufferSize registry value, you may experience unstable performance and memory issues if you assign too great a value to this registry entry.

Note:
To use the MaxBufferSize registry value, you must be running Exchange 2000 Server Service Pack 2 or later.

If the MaxBufferSize registry value is set too low, performance will not improve and the Exchange Server Analyzer will display an error message, as described in this article. If the MaxBufferSize registry value is set too high, system instability could result and the Exchange Server Analyzer will display a message, as described in IMAP4 MaxBufferSize value is too high.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\IMAP4Svc\Parameters

  3. Create a new DWORD value called MaxBufferSize.

  4. Double-click the MaxBufferSize value and set it to the new buffer size (in bytes). For example, you can enter 8192 to set it to 8,192 bytes.

  5. Close the registry editor, and then restart the Microsoft Exchange IMAP4 service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about when and how to use the MaxBufferSize registry value, see the Knowledge Base article 823857, "XADM: IMAP4 and POP3 Performance Is Slow Between Front-End and Back-End Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857).


MAPI Operation Failures
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that the server has many reported MAPI failures. Some MAPI operations are expected to return errors occasionally. However, sometimes a client application may not respond to the error correctly. As a result, the application may reissue the RPC request that caused the error, thereby increasing the load on the server.

An example of a frequent client error is when a MAPI client requests a list of items in batches and continues to request the items after the request has been returned by Exchange. For example, a client computer may request all items in a given folder that contain an attachment. The client may further request that the items are returned in batches of 30 items each. In some cases, after the Exchange server has returned the last item in the request, the client will continue to request a new batch of 30 items. In these cases, Exchange returns a "Not Found" error. If the client computer continues to request items even after the "Not Found" error is returned, the client computer is not responding to the error correctly. In this scenario, Exchange Server User Monitor (ExMon) would report multiple MAPI failures. In this case, although the ratio of failures to number of operations is high, the high failure rate is expected. MAPI operations with expected high failure rates include, GetPerUserGuid, ImportMsgMove, and Logon.

To correct this error

  1. Use ExMon to determine which user or group of users is causing the high number of MAPI failures.

  2. Determine what application on the client computer is causing this problem.

  3. Fix or remove the application that is causing the problem.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


MaxClientRequestBuffer is set to a non-default value
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether the key is present:

HKEY_LOCAL_MACHINE System\CurrentControlSet\w3svc\Parameters\MaxClientRequestBuffer

If the Exchange Server Analyzer finds that the MaxClientRequestBuffer key has been set, the Exchange Server Analyzer displays a non-default message.

By default, this registry value does not exist.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about the MaxClientRequestBuffer registry key, see Microsoft Knowledge Base article 260694, "Description of the MaxClientRequestBuffer Registry Value" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260694)


MaxClientRequestBuffer is set too low
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine the value data for the MaxClientRequestBuffer value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\W3SVC\Parameters\MaxClientRequestBuffer

If the Exchange Server Analyzer finds that the value data for MaxClientRequestBuffer value is lower than 16,384, the Exchange Server Analyzer displays a warning.

If the value for MaxClientRequestBuffer is too low, it could cause errors for Microsoft Office Outlook® Web Access users. Specifically, it could cause HTTP 400 - Bad Request to be returned to the browser. To correct this warning, it is recommended that you either increase the value to a number greater than 16,384 or remove the registry value to revert to the default settings. The MaxClientRequestBuffers value is not present by default.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning by increasing the value for the value data

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\W3SVC\Parameters\MaxClientRequestBuffer

  3. Double-click the MaxClientRequestBuffer value and edit the value data. Set the value data to a decimal number that is equal to or greater than 16,384.

  4. Close the registry editor and then restart the Exchange server.
To correct this warning by removing the value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\W3SVC\Parameters\MaxClientRequestBuffer

  3. Right-click the MaxClientRequestBuffer value, and then click Delete.

  4. Close the registry editor and restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the MaxClientRequestBuffer registry value, see Microsoft Knowledge Base article 260694, "Description of the MaxClientRequestBuffer Registry Value" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260694).


Multiple SMTP port bindings configured
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchServerBindings attribute has been configured with multiple port bindings. By default, the msExchServerBindings attribute is configured for TCP port 25. If the Exchange Server Analyzer finds that the msExchServerBindings attribute has been configured with multiple port bindings, the Exchange Server Analyzer displays a non-default configuration message.

The msExchServerBindings attribute represents the TCP port on which the Simple Mail Transfer Protocol (SMTP) server listens for incoming connections. You can configure SMTP virtual servers to listen on one or more TCP ports. By default, all SMTP virtual servers are configured to listen on TCP port 25. You can change the SMTP listening port if you modify the rest of your internal messaging infrastructure accordingly. However, for SMTP virtual servers that accept messages directly from the Internet, you generally should use port 25 because SMTP servers on the Internet send messages through port 25.

Note that the Exchange Server Analyzer examines the value for the Exchange SMTP protocol virtual server. The Exchange SMTP protocol virtual server may or may not be the SMTP server that receives messages directly from the Internet. Some antivirus products and anti-spam products are designed to receive SMTP messages from the Internet on port 25 and to redirect to an Exchange SMTP virtual server on another port.

To view or modify the SMTP virtual server listening port

  1. In Exchange System Manager, expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  2. Right-click an SMTP virtual server, such as Default SMTP Virtual Server, and then click Properties.

  3. Select the General tab, and then click Advanced.

  4. A list of IP addresses and ports is displayed.

    • To change the existing port, select the IP address, and then click Edit.

    • To remove an existing port, select the IP address, and then click Remove.

  5. To save your changes, click OK, and then click OK to exit the Advanced dialog box.

  6. Click OK to close the Properties dialog box for the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


PING Reply is a Different Size
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class using specific BufferSize setting values and compares them against the returned BufferSize values to determine whether they are the same.

If the returned BufferSize value differs from the value that was sent, the Exchange Server Analyzer displays a warning.

This warning indicates that the packet was truncated somewhere in transit. This may indicate a general network failure or the presence of a black hole router in the environment.

On a TCP/IP wide area network (WAN), communication over some routes may fail if intermediate network segments have packet sizes smaller than the communicating hosts and if routers do not send appropriate ICMP responses to this condition. Alternatively, the firewall on the path may drop such responses. A router that causes this condition is sometimes known as a black hole router.

The presence of a black hole router can cause a variety of errors that do not occur if a program connects to a computer on a local subnet. The behavior may seem intermittent, but when you examine the circumstances more closely you may find that the behavior can be reproduced, for example, by having a client read a large file that is sent from a remote host.

For more information, follow the guidance in Microsoft Knowledge Base article 314825, "How to Troubleshoot Black Hole Router Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=314825).

For More Information

For more information about detecting and treating possible black hole routers, see the following resources:

  • Microsoft Knowledge Base article 159211, "Diagnoses and treatment of black hole routers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211).

  • "Path Maximum Transmission Unit (PMTU) Black Hole Routers" (http://go.microsoft.com/fwlink/?LinkId=66963).


Ping test not performed
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-08-09

The Microsoft® Exchange Server Analyzer Tool tries to query the Win32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class to analyze the response object for various mail-flow-specific configuration settings.

Win32_PingStatus typically returns an object that has 24 properties that supply extensive details about the ping packets that the class sends.

If the Exchange Server Analyzer does not receive the expected object in response to its query after six consecutive attempts, the Exchange Server Analyzer displays a warning.

This warning indicates that the Win32_PingStatus could not be performed.

The most likely cause of this failure is that the computer that tries to execute the Win32_PingStatus command is running on the Microsoft Windows® 2000 Server operating system. Windows 2000 Server does not support the Win32_PingStatus WMI class.

If the computer that tries to execute the Win32_PingStatus command is not running on the Windows 2000 Server operating system, the issue could be the result of general networking issues or a permissions problem.

To correct this error

  1. Make sure that the Exchange Server computer has been started and is connected to the network.

  2. Use the PING command from the computer that is running the Exchange Server Analyzer to see whether the target Exchange Server computer is reachable.

  3. Use the PING command from a server that is on the same subnet with the target Exchange server to see whether the target Exchange Server computer is reachable.

  4. If there is a firewall, check to see whether remote procedure call (RPC) ports are blocked.

  5. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange server that it scans.

For more information about network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about Exchange Server Best Practices Analyzer connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).

For more information about the Win32_PingStatus WMI class, see the MSDN® article, "Win32_PingStatus" (http://go.microsoft.com/fwlink/?linkid=33549).


Plain text antivirus scanning has been disabled
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for the Rich Text Format (RTF) message antivirus scanning:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

If the Exchange Server Analyzer finds the value for ScanPlainText is set to 0, a warning is displayed.

The ScanPlainText registry key is set by third-party antivirus vendors that use the Exchange Virus Scanning API (VSAPI). It is recommended that you scan all message types for viruses, including plain text messages. You should enable virus scanning of all messages flowing through an Exchange Server computer.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  • In your Exchange-aware antivirus application, enable scanning of all messages.

    -or-

  • Manually modify the entry in the registry by performing the following procedure:

    1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

    2. Navigate to:

      HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

    3. Double-click the ScanPlainText registry entry and set its Value Data to 1.

    4. Exit the registry editor and restart the Microsoft Exchange Information Store service and the services representing your Exchange-aware antivirus software for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about fighting viruses, see the Web site "Slowing and Stopping E-mail Transmitted Viruses in an Exchange 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).


The POP3 Compatibility flag has been set in the registry
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the following registry value exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\Compatibility

If the Exchange Server Analyzer finds the Compatibility value present and configured with a value of 0xfffffffe (in hexadecimal), a non-default configuration message is displayed.

Exchange Server Internet Protocol (IP) client computers that are using IMAP4 and Post Office Protocol version 3 (POP3) fully use the streaming store (.stm) file to read and write data. When an IP client requests a download of messages using POP3 or IMAP4, the Exchange store that contains the user's mailbox will calculate the exact size of the messages in the Inbox to send to the client before transmitting the messages. In large environments, especially hosted Exchange environments, this can take a considerable amount of time to calculate. The Compatibility value represents a configuration opportunity for administrators to instruct the Exchange store to use an approximate message size instead of exact calculations for message sizes.

The Compatibility registry value is available for the Exchange POP3 service, as described in this article, and for the Exchange IMAP4 service, as described in The IMAP4 Compatibility flag has been set in the registry.

The Compatibility registry value is also useful during a move of a large number of mailboxes, or mailboxes with a large number of Multipurpose Internet Mail Extensions (MIME) messages. When moving data, the data is promoted from the streaming store into the MAPI store (.edb file). Clients that use POP3 and IMAP4 to access their mailboxes may experience performance issues after you move their mailboxes between databases or servers. After the user logs on, message sizes must be calculated and MAPI-to-MIME conversion occurs in memory and on the disk of the server. In extreme cases, very large temporary files may be created on the Exchange Server computer when this behavior occurs.

Not all POP3 and IMAP4 mail clients may work correctly with the Compatibility registry value set. Changing this setting causes some older mail clients (such as Fetchmail) to break. Setting this registry key also breaks RFC-compliance for the POP3 protocol. If you are experiencing problems downloading messages with POP3 and IMAP4 and you are using the Compatibility registry value, you can delete it using the procedure below as a troubleshooting step for the message download problems.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To delete the Compatibility registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. Delete the value called Compatibility.

  4. Exit the registry editor and restart the Microsoft Exchange Information Store service and the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the use of the Compatibility registry value, see the following Knowledge Base articles:

  • 317722, "XADM: Client Latencies Occur When Exchange 2000 Converts Mail from MAPI to MIME Format" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=317722)

  • 329067, "XADM: Move Mailbox Functionality Promotes Contents of .stm Files" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329067)


POP3 MaxBufferSize value has been changed
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the following registry value exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\MaxBufferSize

If the Exchange Server Analyzer finds the MaxBufferSize value present and configured with any numeric value more than 0, a non-default configuration message is displayed.

The MaxBufferSize registry value is used in an Exchange front-end/back-end topology. It defines the TCP/IP buffer size between front-end servers and back-end servers. The default buffer size is 1 kilobyte (KB). On networks with high latency, adjusting the MaxBufferSize value can improve performance for POP3 clients.

When setting the TCP/IP buffer size with the MaxBufferSize registry value, you should always set the buffer size in multiples of 1,024. It is recommended that you test your front-end/back-end server configuration performance with the following buffer sizes:

  • 8,192 bytes

  • 16,384 bytes

  • 32,768 bytes

When you use this registry entry, it must be set to at least 1,024. It is recommended that you do not set the MaxBufferSize registry entry to a value more than 32,768. However, you may notice increased performance with a buffer size value of 65,536, depending on your network conditions. A larger buffer size uses more memory on the Exchange Server computer and may decrease the number of users who can access the front-end server. While there is no limit to the maximum value that you can use for the MaxBufferSize registry value, you may experience unstable performance and memory issues if you assign too great a value to this registry entry.

Note:
To use the MaxBufferSize registry value, you must be running Exchange 2000 Server Service Pack 2 or a later version.

If the MaxBufferSize registry value is set too low, performance will not improve and the Exchange Server Analyzer will display an error message, as described in POP3 MaxBufferSize value is too low. If the MaxBufferSize registry value is set too high, system instability could result and the Exchange Server Analyzer will display an error message, as described in POP3 MaxBufferSize value is too high.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. Create a new DWORD value called MaxBufferSize.

  4. Double-click the MaxBufferSize value and set it to the new buffer size (in bytes). For example, you can enter 8192 to set it to 8,192 bytes.

  5. Exit the registry editor and restart the Microsoft Exchange POP3 service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about when and how to use the MaxBufferSize registry value, see the Knowledge Base article 823857, "XADM: IMAP4 and POP3 Performance Is Slow Between Front-End and Back-End Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857).


POP3 MaxBufferSize value is too high
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the following registry value exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\MaxBufferSize

If the Exchange Server Analyzer finds the MaxBufferSize value present and configured with any numeric value greater than 32768, a warning is displayed.

The MaxBufferSize registry value is used in an Exchange front-end/back-end topology. It defines the TCP/IP buffer size between front-end servers and back-end servers. The default buffer size is 1 kilobyte (KB). On networks with high latency, adjusting the MaxBufferSize value can improve performance for POP3 clients.

When setting the TCP/IP buffer size with the MaxBufferSize registry value, you should always set the buffer size in multiples of 1,024. It is recommended that you test your front-end/back-end server configuration performance with the following buffer sizes:

  • 8,192 bytes

  • 16,384 bytes

  • 32,768 bytes

When using this registry entry, it must be set to at least 1,024. It is recommended that you do not set the MaxBufferSize registry entry to a value greater than 32,768. However, you may notice increased performance with a buffer size value of 65,535, depending on your network conditions. A larger buffer size uses more memory on the Exchange Server computer and may decrease the number of users who can access the front-end server. While there is no limit to the maximum value that you can use for the MaxBufferSize registry value, you may experience unstable performance and memory issues if you assign too great a value to this registry entry.

Note:
To use the MaxBufferSize registry value, you must be running Exchange 2000 Server Service Pack 2 or later.

If the MaxBufferSize registry value is set too low, performance will not improve and the Exchange Server Analyzer will display an error message, as described in POP3 MaxBufferSize value is too low. If the MaxBufferSize registry value is set too high, system instability could result and the Exchange Server Analyzer will display a message, as described in this article.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. Create a new DWORD value called MaxBufferSize.

  4. Double-click the MaxBufferSize value and set it to the new buffer size (in bytes). For example, you can enter 8192 to set it to 8,192 bytes.

  5. Exit the registry editor and restart the Microsoft Exchange POP3 service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about when and how to use the MaxBufferSize registry value, see the Knowledge Base article 823857, "XADM: IMAP4 and POP3 Performance Is Slow Between Front-End and Back-End Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857).


POP3 MaxBufferSize value is too low
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the following registry value exists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\MaxBufferSize

If the Exchange Server Analyzer finds the MaxBufferSize value present and configured with any numeric value greater than 0 but less than 1024, an error is displayed.

The MaxBufferSize registry value is used in an Exchange front-end/back-end topology. It defines the TCP/IP buffer size between front-end servers and back-end servers. The default buffer size is 1 kilobyte (KB). On networks with high latency, adjusting the MaxBufferSize value can improve performance for POP3 clients.

When setting the TCP/IP buffer size with the MaxBufferSize registry value, you should always set the buffer size in multiples of 1,024. It is recommended that you test your front-end/back-end server configuration performance with the following buffer sizes to determine the optimal value for your organization:

  • 8,192 bytes

  • 16,384 bytes

  • 32,768 bytes

When using this registry entry, it must be set to at least 1,024. It is recommended that you do not set the MaxBufferSize registry entry to a value greater than 32,768. However, you may notice increased performance with a buffer size value of 65,535, depending on your network conditions. A larger buffer size uses more memory on the Exchange Server computer and may decrease the number of users who can access the front-end server. While there is no limit to the maximum value that you can use for the MaxBufferSize registry value, you may experience unstable performance and memory issues if you assign too great a value to this registry entry.

Note:
To use the MaxBufferSize registry value, you must be running Exchange 2000 Server Service Pack 2 or later.

If the MaxBufferSize registry value is set too low, performance will not improve and the Exchange Server Analyzer will display an error message, as described in this article. If the MaxBufferSize registry value is set too high, system instability could result and the Exchange Server Analyzer will display a message, as described in POP3 MaxBufferSize value is too high.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. Create a new DWORD value called MaxBufferSize.

  4. Double-click the MaxBufferSize value and set it to the new buffer size (in bytes). For example, you can enter 8192 to set it to 8,192 bytes.

  5. Close the registry editor, and then restart the Microsoft Exchange POP3 service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about when and how to use the MaxBufferSize registry value, see the Knowledge Base article 823857, "XADM: IMAP4 and POP3 Performance Is Slow Between Front-End and Back-End Servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857).


Port did not respond
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-16

The Microsoft® Exchange Server Analyzer Tool queries the user-defined server and tries to open a socket connection to the specified server on the default configuration of TCP port 25 or a user-defined port. If the Exchange Server Analyzer does not receive an expected custom response of xx Available, where xx is the default port of 25 or the alternative port number defined by the user, the Exchange Server Analyzer displays an error.

This error indicates that the server cannot be accessed on the desired TCP port and that failures may occur. To correct this error, you can troubleshoot the connectivity problem with the server.

To troubleshoot the connectivity problem with the server

  1. Can you telnet to the desired port from the designated server itself? If not, the problem is not with the network.

  2. Is everything plugged in? Is all your hardware functioning correctly?

  3. Is DNS working and configured correctly?

  4. Is your router functioning correctly?

  5. Are there any firewalls preventing you from connecting?

For more information about how to troubleshoot server connectivity issues, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).


Potential Black Hole Routers
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class using various, specific BufferSize and NoFragmentation setting values to determine whether black hole routers might be present in the WAN environment.

BufferSize Setting | NoFragmentation Setting
548 | True
1472 | True
1472 | False
4096 | True
4096 | False

The Exchange Server Analyzer displays an error, if the following conditions are true:

  • PING with a smaller BufferSize and NoFragmentation = True is successful

  • PING with a larger BufferSize and NoFragmentation = True times out

  • PING with a larger BufferSize and NoFragmentation = False is successful but the reply BufferSize size differs from the sent BufferSize.

This error indicates the possible presence of one or more black hole routers on the wide area network (WAN).

On a TCP/IP WAN, communication over some routes may fail if the following conditions are true:

  • Intermediate network segments have packet sizes smaller than the communicating hosts

  • Routers do not send appropriate ICMP responses to this condition.

Alternatively, the firewall on the path may drop such responses. A router that causes this condition is sometimes known as a black hole router.

The presence of a black hole router can cause a variety of errors that do not occur if a program connects to a computer on a local subnet. The behavior may seem intermittent, but you will find that the behavior can be reproduced, for example, by having a client read a large file that is sent from a remote host.

For more information, follow the guidance in Microsoft Knowledge Base article 314825, "How to Troubleshoot Black Hole Router Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=314825).

For More Information

For more information about detecting and treating possible black hole routers, see the following resources:

  • Microsoft Knowledge Base article 159211, "Diagnoses and treatment of black hole routers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211).

  • "Path Maximum Transmission Unit (PMTU) Black Hole Routers" in The Cable Guy - July 2004 column (http://go.microsoft.com/fwlink/?LinkId=66963).


Remote Host PING Unsuccessful
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-03

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PingStatus Microsoft Windows® Management Instrumentation (WMI) class by using various BufferSize and NoFragmentation settings to determine the size of the Maximum Transmission Unit (MTU) for the network and locate possible black hole routers. The Exchange Server Analyzer determines this by examining the StatusCode key value that is returned from a remote host for each settings combination.

BufferSize Setting | NoFragmentation Setting
548 | True
1472 | True
1472 | False
4096 | True
4096 | False

Win32_PingStatus returns an object that has 24 properties that supply extensive details about the ping packets that the class sends.

If the Exchange Server Analyzer finds that the value for this key matches one of the values in the following table, the Exchange Server Analyzer displays an error.

The Exchange Server Analyzer displays the remote host name, the Exchange Server name, and the corresponding StatusCode value that is returned with this error.

StatusCode value Meaning Description

11001

Buffer Too Small

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11002

Destination Net Unreachable

Request failed because the network that contains the destination computer is not reachable. No valid route exists to the destination computer.

For more information, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11003

Destination Host Unreachable

Request failed because the destination computer is not reachable.

For more information, see Active Directory server down or unreachable.

Alternatively, this error may be caused by one of the following conditions:

  • A firewall between where the Exchange Server Analyzer is being run and the target domain controller.

  • A DNS error.

For more information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11004

Destination Protocol Unreachable

Request failed because the destination computer does not respond to the packet's protocol.

This error may be caused by a firewall between where the Exchange Server Analyzer is being run and the target domain controller.

11005

Destination Port Unreachable

Request failed because the port on the destination computer is unavailable.

For more information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11006

No Resources

Request failed because of insufficient network resources.

For more information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11007

Bad Option

Request failed because it contains an invalid option.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11008

Hardware Error

Request failed because of a hardware error.

Validate that the domain controller is suitably operational by running the hardware health check tool supplied by the manufacturer of your computer.

11009

Packet Too Big

Request failed because the packet that contains the request is larger than the maximum transmission unit (MTU) of a router or gateway node that is located between the source and the destination. The MTU defines the maximum size of a transmittable packet.

The request sent by the Exchange Server Analyzer is not bigger than 10 KB. Confirm that the routers and gateways in your organization are appropriately configured.

For more information, see Knowledge Base article 159211, "Diagnoses and Treatment of Black Hole Routers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211).

11010

Request Timed Out

Reply was not received in the allocated time. The default time allowed for replies is 5 seconds.

For more information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11011

Bad Request

Request failed because it was encoded incorrectly.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11012

Bad Route

Request failed because there is no valid route between the source and destination computers.

For more information, see Knowledge Base article 325487,"How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11013

TimeToLive Expired Transit

Request failed because its Time to Live (TTL) value reached zero. This causes the forwarding router or gateway node to discard the packet.

For more information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11014

TimeToLive Expired Reassembly

Request failed because the packet was divided into fragments for transmission and all fragments were not received in the time allocated for reassembly. RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) specifies 60 seconds as the time limit within which all packet fragments must be received.

For more information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

11015

Parameter Problem

Request failed because a router or gateway node experienced problems when it processed the packet header. This can occur if the header contains invalid field data or an unrecognized option.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11016

Source Quench

Request failed because the packet was discarded. This occurs when the output queue of the source computer has insufficient storage space. Alternatively, it can occur when packets arrive at the destination too quickly to be processed.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11017

Option Too Big

Request failed because it contains an invalid option.

This error is unlikely because the Exchange Server Analyzer generates a standard request.

11018

Bad Destination

Request failed because of one of the following reasons:

  • The destination IP address cannot receive PING requests.

  • The destination IP address should never appear in the destination address field of any IP datagram.

This may be caused by a firewall between where the Exchange Server Analyzer is being run and the target domain controller.

11032

Negotiating IPSEC

Request failed because an IPsec connection could not be negotiated.

11050

General Failure

Request failed for an unknown reason.

For more information, see Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about these tests, see Microsoft Knowledge Base article 314825, "How to Troubleshoot Black Hole Router Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=314825).


Routing Engine is stopped
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether the Microsoft Exchange Routing Engine service (RESvc) and the Simple Mail Transfer Protocol (SMTP) service (SMTPSVC) are running. The Exchange Server Analyzer displays an error if the Exchange Server Analyzer finds that either of the following conditions is true:

  • SMTPSVC is running.

  • RESvc is not running.

If RESvc is not running on all Exchange servers that relay messages, routing problems may occur. An Exchange Server configuration that relays messages without RESvc running is not a supported configuration.

Like Exchange 2000 Server, Exchange Server 2003 uses a link state routing algorithm and a routing protocol to propagate link state information in the form of a link state table. The link state table is stored in memory on all Exchange 2000 Server and Exchange Server 2003 servers in the organization.

A link state algorithm provides the following advantages:

  • Each Exchange server can select the optimum message route at the source instead of sending messages along a route where a link is unavailable.

  • Messages no longer bounce back and forth between servers because each Exchange server has current information about whether alternative routes or redundant routes are available.

  • Message looping no longer occurs. Message looping was sometimes a problem in earlier versions of Exchange Server.

Exchange Server collects the following information from the link state table:

  • The link state table documents the routing topology of the whole Exchange organization.

  • The link state table documents the availability of each connector in the topology. An available topology is "up." An unavailable topology is "down."

  • The link state table documents the costs and the address spaces that are associated with each available connector.

Exchange Server uses this information to determine the route with the lowest cost for the destination address. If a connector along the route with the lowest cost is unavailable, Exchange Server determines the best alternative route on the basis of costs and connector availability. RESvc is required for link state routing.

To correct this error, you must configure RESvc to start automatically. You also must make sure that RESvc is running during production hours.

To correct this error

  1. Click Start, point to Programs, point to Administrative Tools, and then click Services.

  2. In the list of services, right-click Microsoft Exchange Routing Engine, and then click Properties.

  3. On the General tab, on the Startup type menu, select Automatic, and then click OK.

  4. Right-click Microsoft Exchange Routing Engine, and then click Start.

For more information about routing messages in Exchange Server 2003, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


RPC Performance Counters Indicate Poor Server Performance
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-08-24

The Microsoft® Exchange Server Analyzer Tool has determined that your server is not operating at optimal performance. The Exchange Server Analyzer evaluates many remote procedure call (RPC) performance counters. If the reported data in the RPC performance counters do not compare favorably to the levels in the table below, a warning is displayed.

Number of Users on the Exchange Server | RPC Averaged Latency Threshold
Less than 500 | Average greater than 15
Greater than or equal to 500 but less than 3000 | Average greater than 30
Greater than 3000 | Average greater than 50

The following performance counters are discussed in this article and are managed by the MSExchangeIS performance object:

  • RPC Averaged Latency

  • RPC Requests

RPC Averaged Latency

The RPC Averaged Latency performance counter records the average time, in milliseconds (ms), that it takes for the last 1024 packets to be processed. The latency represents how long it takes from the time the Store.exe process received the packet to the time it returned the packet. The RPC Averaged Latency performance counter does not include any network latency or any latency that is introduced by anything other than the Store.exe process. Although the RPC Averaged Latency performance counter data does not include network transit time, it does provide data about the shortest time period that client computers have waited for a response from the server. If the RPC Averaged Latency performance counter data is lower than 50 ms, the server can process the requests in a reasonable amount of time. If the counter stays greater than 50 ms for more than several seconds, this indicates that the server is having difficulty keeping up with the load. As a result, users may experience delays when accessing their e-mail. If average latency is greater than 100 ms, users will receive the following pop-up window from their Microsoft Office Outlook® client computers: "Retrieving data from Exchange Server."

Interpreting the RPC Averaged Latency Performance Counter

The RPC Averaged Latency counter can be misleading in the following two situations:

  • First, some MAPI operations are expected to take a long time. For example, if the client computer searches a folder that contains thousands of items in an attempt locate all items that match complex criteria, it is ordinary for such an operation to take several seconds. If there are few users on the server, this ongoing operation may cause a spike in the RPC Average Latency. If the RPC load on the server is low, observe the average for this value over a longer period of time (at least several minutes), instead of acting upon the short-term, more volatile behavior.

  • The second situation that may occur is when the RPC load on the server is very low. Sometimes, depending on the activity of the busiest user, the latency can change dramatically. Because the server load is particularly stressed, the result of heavy operation by a single user may unintentionally skew the RPC average latency data.

RPC Requests

The RPC Requests performance counter records the number of client computer requests that are currently being processed by Exchange. The counter has a maximum value of 100. After the Exchange store has 100 RPC operations being processed, it regularly refuses any new connections. On a healthy server, the number of outstanding requests should be lower than 50. If the number is greater than 50 for a long time, this indicates that RPCs are backed up and waiting to be processed and client computers are probably experiencing delays.

Interpreting RPC Requests

The threshold of 50 requests is not a strict threshold. A lightly loaded server may start to have performance problems before the counter reaches 30; however, a heavily loaded server may function correctly at 50 requests. Ideally, for each server, a baseline value for this counter should be measured. The Exchange Server Performance Troubleshooting Analyzer uses the threshold of 50, which is appropriate for most large servers.

Compared to a heavily loaded server, a lightly loaded server has a reduced value for RPC requests. This is because a lightly loaded server requires fewer threads to keep pace with the load. To avoid falling behind and to obtain a greater RPC request value, a busier server must perform more concurrent work. Therefore, on a heavily loaded server, the greater RPC request value does not, on its own, imply a performance problem. To assess the "slowness" of the server, you must also consider the RPC Average Latency performance counter.

Causes of Latency

An increase in latency may be caused by the following:

  • An increase in RPC load

  • A bottleneck in one or more server resources

Furthermore, a bottleneck may be caused by the following:

  • High RPC load (or any other load on the server)

  • Hardware malfunction or configuration error

To correct this error

  • Follow the recommendations and best practices that are provided in the following Exchange Server 2003 guides:

    • Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576)

    • Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588)


RPC port range set on a non-clustered server
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine the value data for the ports:

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet\Ports

If the Exchange Server Analyzer finds that the following conditions are true, the Exchange Server Analyzer displays an error:

  • The HKLM\Software\Microsoft\Rpc\Internet\Ports key is present.

  • The server is not a clustered Exchange server.

  • The server is having other errors.

When the registry key is present, Exchange Server is limited to a specific range of ports for RPC calls. If the Exchange server is under load and needs more ports than are currently available, errors may occur.

To correct this problem you should add an additional 100 ports to the HKLM\Software\Microsoft\Rpc\Internet\Ports key until the problems go away.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open the registry editor Regedt32.exe.

    Note:
    To edit a REG_MULTI_SZ value, you must use Regedt32.exe instead of Regedit.exe.

  2. Navigate to: HKLM\Software\Microsoft\Rpc\Internet.

  3. In the right pane, double-click the Ports key. In the value box, increase the Port Range.

  4. Close the registry editor and restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the HKLM\Software\Microsoft\Rpc\Internet registry keys, see Microsoft Knowledge Base article 154596, "How to configure RPC dynamic port allocation to work with firewalls" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=154596).


RPC port range set on a clustered server
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine the value data for the ports: HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet\Ports

If the Exchange Server Analyzer finds that the following conditions are true, the Exchange Server Analyzer displays an error:

  • The HKLM\Software\Microsoft\Rpc\Internet\Ports key is present.

  • The server is a clustered Exchange server.

  • The server is having other errors.

When the registry key is present, Exchange Server is limited to a specific range of ports for RPC calls. If the Exchange server is under load and needs more ports than are currently available, errors may occur.

To correct this problem, you should add an additional 100 ports to the HKLM\Software\Microsoft\Rpc\Internet\Ports key until the problems go away.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open the registry editor Regedt32.exe.

    Note:
    To edit a REG_MULTI_SZ value, you must use Regedt32.exe instead of Regedit.exe.

  2. Navigate to: HKLM\Software\Microsoft\Rpc\Internet.

  3. In the right pane, double-click the Ports key. In the value box, increase the Port Range.

  4. Close the registry editor and restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the HKLM\Software\Microsoft\Rpc\Internet registry keys, see the Microsoft Knowledge Base article 154596, "How to configure RPC dynamic port allocation to work with firewalls" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=154596).


RPC User Activity From Performance Counters
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2007-02-14

The Microsoft® Exchange Server Analyzer Tool has determined that your server is currently experiencing a high remote procedure call (RPC) load.

The RPC operations-per-second rate is an indication of how much RPC load is present on the server. Sometimes, an unexpected increase in RPC operational load can result in poor server performance. If your server is experiencing a performance problem, you should first identify if the load on the server is higher than expected. There are several performance counters that provide information about RPC activity on the server. The following performance counters that are discussed in this article are all under the MSExchangeIS, MSExchangeIS Public or MSExchangeIS Mailbox performance objects:

  • RPC Operations/sec

  • Active User Count

  • Active Client Logons (MSExchangeIS Public)

  • Active Client Logons (MSExchangeIS Mailbox)

Identifying Client RPC Load

There are two counters you can use to identify the current activity rate of the client computers.

  • RPC Operations/sec This counter provides the number of RPC operations per second that client computers are currently requesting from the server. You can count users in the following ways:

    • You can count the total mailboxes on the server.

    • You can count the total number of logons (from the sum of Active Client Logons for MSExchangeIS Public, and Active Client Logons for MSExchangeIS Mailbox).

    • You can count the total number of logons from the Active User Count.

    The Exchange Server Analyzer uses the last method. To calculate the rate per-active-user, divide the average RPC Operations/sec by the Active User Count.

  • RPC Operations/sec per user This counter provides an indication of how active the users are on the server. Typically, knowledge workers who use Microsoft Office Outlook® have a rate of approximately 0.1 operations per second, per user on a mailbox server. If the users on the server are running additional applications, the number may increase.

If the Exchange Server Analyzer determines that the RPC operations per second per user is greater than 0.15 but lower than 0.25, the users are considered moderately active and the Exchange Server Analyzer displays a warning.

If the Exchange Server Analyzer determines that the RPC operations per second per user is greater than 0.25, the users are considered to be unusually active and the Exchange Server Analyzer displays an error.

What to Do if the RPC Load Is High

If the operations per second are higher than expected, you should first attempt to identify the cause of high load and then reduce it. You can use the Exchange Server User Monitor (ExMon) tool to identify if a particular user is issuing a high rate of RPC operations.

If you are unable to reduce the load on the server, you must identify the performance bottlenecks and increase the capacity of the server.

Identifying a High Number of Logons

It is required that the server maintain some information about logons in memory (both in user and kernel memory). There is a limited amount of memory set aside. If this memory is used, the server can encounter a memory bottleneck. For this reason, if you encounter a performance problem on an Exchange server, you should make sure that the total number of logons per user is not excessive.

A typical knowledge worker will have two to three logons. If users are running other applications, the number of logons may increase. The Exchange Server Analyzer calculates the number of logons per user by dividing the total number of logons to the server by the number of mailboxes on the server. You can determine the total number of logons to the server by adding together the Active Client Logons performance counters on the MSExchangeIS Mailbox and MSExchangeIS Public performance objects. For mailbox or mixed mailbox and public folder servers, the Exchange Server Analyzer looks only at this ratio.

Note:
If a large number of users are viewing other users' shared folders (such as shared calendars), the number of logons can also be higher.

If the average number of logons per user is more than five and the server is experiencing a memory bottleneck, this may indicate that users are running applications that are creating a large number of logons. If users are running applications that are not required for business use, request that they do not run the applications that are causing excessive logons to the Exchange server.

If you cannot reduce the number of applications that users are running, you must reduce the number of users per server by moving users to another server. To determine whether the logons are caused by many users or if a single user has a disproportionately high number of logons, you can use Exchange System Manager to view the active logons for each user.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


RTF antivirus scanning has been disabled
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for the Rich Text Format (RTF) message antivirus scanning:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

If the Exchange Server Analyzer finds the value for ScanRTF is set to 0, a warning is displayed.

The ScanRTF registry key is set by third-party antivirus vendors that use the Exchange Virus Scanning API (VSAPI). RTF messages allow you to use colors, fonts, and formatting, but RTF is readable only by Microsoft Office Outlook® 2003. Exchange Server RTF format is different from reading a file in RTF format in a word processor such as Microsoft Office Word 2003.

It is recommended that you scan all message types for viruses, including RTF messages. You should enable virus scanning of all messages flowing through an Exchange Server computer.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. In your Exchange-aware antivirus application, enable scanning of all messages.

    or

  2. Manually modify the entry in the registry by performing the following procedure:

    • Open a registry editor, such as Regedit.exe or Regedt32.exe.

    • Navigate to:

      HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

    • Double-click the ScanRTF registry entry and set its Value Data to 1.

    • Exit the registry editor and restart the Microsoft Exchange Information Store service and the services representing your Exchange-aware antivirus software for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about fighting viruses, see the Web site "Slowing and Stopping E-mail Transmitted Viruses in an Exchange 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=30732).


SMTP Banner Has Been Customized
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool tries to send a message to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain. The Exchange Server Analyzer displays a warning if it receives a response from that account different from the following default response:

"220 Computer Name . Domain Name .com Microsoft ESMTP MAIL Service, Version: Version Number ready at Date Time +0000"

This warning indicates that the default response that appears when the program connects to an Exchange SMTP virtual server has been customized.

A customized SMTP banner may not be an issue if the Exchange Server administrator has intentionally changed the banner as described in Microsoft Knowledge Base article 281224, "XCON: How to Modify the SMTP Banner" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=281224).

If the default SMTP banner has not been intentionally customized by the Exchange Server administrator, this warning may indicate that the Exchange Server is behind a Firewall or SMTP Proxy that is filtering the Exchange Server Extended SMPT (ESMTP) commands.

If Exchange Server ESMTP commands are filtered, this can have a significant effect on Exchange performance and may produce the behavior described in Microsoft Knowledge Base article 320027, "Cannot send or receive e-mail messages behind a Cisco PIX firewall" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320027).

For more information about customized SMTP banners see the following Microsoft Knowledge Base articles:

  • "XCON: How to Modify the SMTP Banner" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=281224).

  • "Cannot send or receive e-mail messages behind a Cisco PIX firewall" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320027).


SMTP Instance Paused
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-16

The Microsoft® Exchange Server Analyzer Tool queries the IIS metabase to determine the value of the ServerState property for each instance of a Simple Mail Transfer Protocol (SMTP) Virtual Server.

The ServerState property presents the current state of the server instance. The states, and the corresponding state codes, are as follows: 1 (starting), 2 (started), 3 (stopping), 4 (stopped), 5 (pausing), 6 (paused), or 7 (continuing).

If the Exchange Server Analyzer determines that the value for the ServerState property for a SMTP Virtual Server instance is equal to 6 (paused), the Exchange Server Analyzer displays an error.

SMTP is the native mail protocol for mail submission and mail transport for Exchange Server. This means that clients use SMTP to send messages and Exchange servers use SMTP to deliver messages and message data.

Virtual servers run under a server process that you can start, stop, and pause—much like other server processes. For example, if you are changing the configuration of a virtual server or performing other maintenance tasks, you may have to stop the virtual server, make the changes, and then restart it. When you stop a virtual server, it does not accept connections from users and you cannot use it to deliver or retrieve mail.

An alternative to stopping a virtual server is to pause it. When you pause a virtual server, this prevents new client connections but does not disconnect current connections. When you pause an SMTP virtual server, active clients can continue to submit messages and the virtual server can deliver existing messages that are queued for delivery. However, no new connections are accepted.

For ordinary messaging operations, Exchange Server SMTP virtual server instances should be started.

To resolve this error, follow these steps to start the SMTP virtual server instance.

To start the SMTP virtual server instance

  1. In Exchange System Manager, right-click the virtual server instance that you want to start.

  2. On the Action menu, click Start.

For more information about how to start, stop, or pause SMTP virtual servers, see the following Microsoft Knowledge Base articles:

  • "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686).

  • "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163).

  • "XIMS: How to Flush the SMTP Mail Queue in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=251087).

  • "XGEN: Disabling Protocols in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=291330).


SMTP Instance Stopped
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-16

The Microsoft® Exchange Server Analyzer Tool queries the IIS metabase to determine the value of the ServerState property for each instance of a Simple Mail Transfer Protocol (SMTP) Virtual Server.

The ServerState property presents the current state of the server instance. The states, and the corresponding state codes, are as follows: 1 (starting), 2 (started), 3 (stopping), 4 (stopped), 5 (pausing), 6 (paused), or 7 (continuing).

If the Exchange Server Analyzer Tool determines that the value for the ServerState property for a SMTP Virtual Server instance is equal to 4 (stopped), the Exchange Server Analyzer displays an error.

SMTP is the native mail protocol for mail submission and mail transport for Exchange Server. This means that clients use SMTP to send messages and Exchange servers use SMTP to deliver messages and message data.

Virtual servers run under a server process that you can start, stop, and pause—much like other server processes. For example, if you are changing the configuration of a virtual server or performing other maintenance tasks, you may have to stop the virtual server, make the changes, and then restart it. When you stop a virtual server, it does not accept connections from users and you cannot use it to deliver or retrieve mail.

For ordinary messaging operations, Exchange Server SMTP virtual server instances should be started.

To resolve this error, follow these steps to start the SMTP virtual server instance.

To start the SMTP virtual server instance

  1. In Exchange System Manager, right-click the virtual server instance that you want to start.

  2. On the Action menu, click Start.

For more information about how to start, stop, or pause SMTP virtual servers, see the following Microsoft Knowledge Base articles:

  • "XCON: How to Configure an SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686).

  • "XCON: How to Configure an SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163).

  • "XIMS: How to Flush the SMTP Mail Queue in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=251087).

  • "XGEN: Disabling Protocols in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=291330).


SMTP maximum recipients may be set too low
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpMaxRecipients attribute is less than 250. By default, the msExchSmtpMaxRecipients attribute is configured for 64,000 recipients. If the Exchange Server Analyzer finds that the msExchSmtpMaxRecipients attribute is configured with a value of less than 250, the Exchange Server Analyzer displays a warning.

From a security perspective, it is a best practice to limit the maximum number of recipients for each message. It is recommended that you leave the msExchSmtpMaxRecipients attribute set at its default value of 64000.

Each organization should determine its acceptable maximum number of recipients on the basis of its own business requirements. However, it is recommended that you not set the maximum number of recipients to a value under 250. Messages that are addressed to multiple distribution lists are likely to have more than 250 recipients. If you set a maximum number of recipients to a value under 250, Exchange must process the remaining recipients by using additional copies of the message. These additional copies cause increased network traffic.

To view and configure the maximum number of recipients

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server, such as Default SMTP Virtual Server, and then select Properties.

  4. Select the Messages tab.

  5. To revert to the default setting of 64000, make sure that the Limit number of recipients per message check box is selected and enter a value of 64000. Alternatively, you can configure this field with any value that you want, or clear the check box to allow an unlimited number of recipients.

  6. Click OK to save the changes and to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


SMTP Proxy Address for EAS has been overridden
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

Error Message

Introduction

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the SMTP proxy address for Exchange ActiveSync® has been overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MasSync\Parameters\SMTPProxy

If the Exchange Server Analyzer finds the SMTPProxy registry entry present and configured, a non-default configuration message is displayed.

SMTP addresses are used to identify the path of a mailbox in Exchange Server, and they must be unique. Each address has a left-hand side (LHS) portion and a right-hand side (RHS) portion that are separated by an @ symbol. For example, the format for an SMTP address is as follows:

Username@domain.com = left-hand-side@right-hand-side (or LHS@RHS)

Exchange ActiveSync uses a WebDAV request to access the mailbox information from the Exchange server. Exchange ActiveSync selects an associated RHS value, with the LHS@RHS representing an SMTP proxy address, to use in the WebDAV request. In environments that have a default RHS address that is different from a user's primary SMTP address, the SMTPProxy registry value provides a configuration opportunity to allow Exchange ActiveSync to use an alternate SMTP proxy address.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To view or modify the SMTPProxy registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MasSync\Parameters

  3. Examine, and if desired, change the SMTPProxy value.

  4. If a change is made, close the registry editor, and then restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about Exchange ActiveSync, see "Exchange Server 2003 ActiveSync Architecture" (http://go.microsoft.com/fwlink/?linkid=34203).

For more information about mobile access and Exchange Server 2003, see "Mobile Access Using Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=20098).


SMTP server accepts basic authentication
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchAuthenticationFlags attribute in the protocolCfgSMTPServer class for the Exchange Server object. The protocolCfgSMTPServer class contains the settings for an SMTP virtual server. The msExchAuthenticationFlags attribute represents the type of authentication that is allowed on the SMTP server. If the Exchange Server Analyzer determines that basic authentication has been configured on the SMTP server and the server is not Microsoft Small Business Server 2000 or Microsoft Windows® Small Business Server 2003, the Exchange Server Analyzer displays a warning message.

If basic authentication is configured on the SMTP server, the risk of a security breach increases. Basic authentication allows user names and passwords to be sent across the network in clear text. Without encryption, user names and passwords can be easily intercepted on the Internet.

If you use basic authentication, it is strongly recommended that you also use Transport Layer Security (TLS) encryption for more security. TLS encrypts user names, passwords, and message data. You can require that clients who are connecting to the SMTP virtual server use TLS encryption. TLS is designed to help protect outgoing messages, but TLS does not help protect traffic that travels from clients to the server.

TLS is supported by Microsoft Outlook Express. To use TLS encryption for the SMTP virtual server, you must create key pairs and configure key certificates. Clients can then use TLS to encrypt the session with the SMTP service. Therefore, all messages are sent. The SMTP service can also use TLS to encrypt sessions with remote servers.

Note:
Clients that do not support TLS cannot relay e-mail messages through the virtual server.

If you cannot disable authenticated access on your SMTP virtual server for business reasons, such as authentication by a partner company, follow these steps to help enhance security on your gateway server:

  • Enforce a strong password policy for all user accounts, particularly the administrator account.

  • Disable the guest account. For more information about disabling the guest account, see the Microsoft Knowledge Base article 320053, "How to rename the administrator and guest account in Windows 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=320053). Although this article applies to Microsoft Windows 2000 Server, similar principles apply for Windows Server™ 2003.

To disable basic authentication

  1. In Exchange System Manager, expand Servers, expand <your inbound Exchange server>, expand Protocols, and then expand SMTP.

  2. Right-click your inbound SMTP virtual server, and then click Properties.

  3. Click the Access tab, and then click Authentication.

    Authentication dialog box

  4. In Authentication, clear the Basic Authentication check box.

    Important:
    If you use basic authentication, consider implementing TLS for more security. Use the Requires TLS encryption check box if you have a digital certificate. Digital certificates are common in a high-security environment. If you select this check box, in the corresponding Default domain box, you must type the Windows 2000 Server domain name or Windows Server 2003 domain name that the user should authenticate against if the user does not specify a domain. For more information about TLS encryption, see the Exchange online documentation.

For more information about how to configure your Exchange Server 2003 organization to send and receive Internet mail more securely, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=26041).


SMTP Service Disabled
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-16

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value set for the Simple Mail Transfer Protocol (SMTP) service StartMode key. A value of Disabled indicates that the Simple Mail Transfer Protocol (SMTP) service has been disabled and cannot be started until the StartMode value is changed to either Manual or Automatic.

The Exchange Server Analyzer queries the Win32_Service WMI class to determine the value of the Started key for the SMTP service. A value of False indicates that the service is not running. A value of True indicates that the service is running.

If the Exchange Server Analyzer finds the value for the StartMode key is set to Disabled on an Exchange Server computer that has the SMTP service started, the Exchange Server Analyzer displays an error.

The Windows SMTP service is a component of Internet Information Services (IIS) and runs as part of Inetinfo.exe. Exchange Server relies on the SMTP service as its native transport protocol. Therefore, Exchange uses SMTP to route all internal and external messages.

All Exchange Server computers should have the SMTP service set to Automatic.

To resolve this error, you must configure the SMTP service to start automatically on servers that route mail.

To configure the Simple Mail Transfer Protocol (SMTP) service for automatic startup

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. Double-click Simple Mail Transfer Protocol (SMTP) service.

  3. On the General tab of the Simple Mail Transfer Protocol (SMTP) Properties page, select Automatic from the Startup type drop-down dialog box, and then click Apply.

  4. Under Server status, click Start, and then click OK.

  5. Close the Services snap-in.

For more information about the SMTP service and Exchange Servers, see "SMTP Transport Architecture" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to configure SMTP service for Exchange, see "Configuring SMTP in Microsoft Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=24866).


SMTP Service Not Started
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2007-03-13

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Simple Mail Transfer Protocol (SMTP) service. A value of False indicates that the SMTP service is not running. A value of True indicates that the SMTP service is running.

If the Exchange Server Analyzer finds the value for the Started key is set to False, the Exchange Server Analyzer displays an error.

The Windows SMTP service is a component of Internet Information Services (IIS) and runs as part of Inetinfo.exe. Exchange Server relies on the SMTP service as its native transport protocol. Therefore, Exchange uses SMTP to route all internal and external messages.

The SMTP service should always be running on Exchange servers.

To correct this error

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. In the right pane, scroll down to the Simple Mail Transfer Protocol (SMTP) service and double-click it. This will display the Simple Mail Transfer Protocol (SMTP) Properties dialog box.

  3. Set the value in the Startup type drop-down menu to Automatic.

  4. Click Start to start the SMTP service.

  5. Click OK to save the changes and close the Simple Mail Transfer Protocol (SMTP) Properties dialog box.

  6. Close the Services snap-in.

For more information about the Simple Mail Transfer Protocol (SMTP) service and Exchange Servers, see "SMTP Transport Architecture" in the Technical Reference Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47891).

For more information about how to configure SMTP service for Exchange, see "Configuring SMTP in Microsoft Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=24866).


SMTP Service Set to Manual
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-05-16

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value set for the Simple Mail Transfer Protocol (SMTP) service StartMode key. A value of Manual indicates that the Simple Mail Transfer Protocol (SMTP) service has been set to require a manual start and will not start automatically.

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine the value of the Started key for the SMTP service. A value of False indicates that the service is not running. A value of True indicates that the service is running.

If the Exchange Server Analyzer finds the value for the StartMode key is set to Manual on an Exchange Server computer that has the SMTP service started, the Exchange Server Analyzer displays a warning.

The Windows SMTP service is a component of Internet Information Services (IIS) and runs as part of Inetinfo.exe. Exchange Server relies on the SMTP service as its native transport protocol. Therefore, Exchange uses SMTP to route all internal and external messages.

If the SMTP service does not start automatically at startup, it may be overlooked. This could lead to serious mail flow issues.

All Exchange Server computers should have the SMTP service set to Automatic.

To resolve this error, you must configure the SMTP service to start automatically on servers that route mail.

To configure the Simple Mail Transfer Protocol (SMTP) service for automatic startup

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. Double-click Simple Mail Transfer Protocol (SMTP) service.

  3. On the General tab of the Simple Mail Transfer Protocol (SMTP) Properties page, select Automatic from the Startup type drop-down dialog box, and then click Apply.

  4. Under Server status, click Start, and then click OK.

  5. Close the Services snap-in.

For more information about the SMTP service and Exchange Servers, see "SMTP Transport Architecture" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to configure SMTP service for Exchange, see "Configuring SMTP in Microsoft Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=24866).


SMTP service status unknown
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Simple Mail Transfer Protocol (SMTP) service. A value of False indicates that the SMTP service is not running. A value of True indicates that the SMTP service is running.

If the Exchange Server Analyzer cannot determine the value for the Started key, the Exchange Server Analyzer displays an error.

This error indicates that the WMI query was unable to retrieve the data requested.

The likely causes of this error are as follows:

  • The account that runs the Exchange Server Analyzer does not have sufficient permissions to query WMI classes.

  • A network issue prevents the Exchange Server Analyzer from contacting the computer.

  • A transient condition of unknown origin has caused a time-out for the query.

To correct this error

  1. Make sure that the server that is running Exchange Server has been started and is connected to the network.

  2. Use the PING command to see whether the Exchange server is reachable.

  3. If there is a firewall, check to see whether remote procedure call (RPC) ports are blocked.

  4. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange server that it scans.

    Alternatively, you can grant specific WMI permission to the account under which the Exchange Server Analyzer is running:

    1. On the Exchange server, open the Computer Management Microsoft Management Console (MMC) tree.

    2. Under Services and Applications, right-click WMI Control, and then click Properties.

    3. On the WMI Controls Property dialog box, click the Security tab, and then expand Root.

    4. Select the CIMV2 folder, and then click Security.

    5. On the Security for ROOT\CIMV2 page, add the account under which the Exchange Server Analyzer runs.

  5. Select the account that you added in step 5. In Permissions for Selected_Account, under the Allow column, select both Remote Enable and Read Security, and then click OK.

For more information about SMTP service and Exchange Servers, see "SMTP Transport Architecture" in the Technical Reference Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47891).

For more information about how to configure SMTP service for Exchange, see "Configuring SMTP in Microsoft Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=24866).

For more information about how to troubleshoot network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about how to troubleshoot connectivity problems for the Exchange Server Analyzer, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).


UseAltRegionalCharset and UseRegionalCharset registry values are both enabled
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine the language settings that are used by Microsoft Outlook® Web Access clients:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseRegionalCharset

    A setting of 1 causes UTF-8 message bodies to persist in the store in the regional character set or codepage instead of in UTF-8 format. This is the default setting for the Exchange Server 2003 UseRegionalCharset registry value.

  • HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseAltRegionalCharset

The level of the browser determines message encoding if the following conditions are true:

  • The UseAltRegionalCharset key is not set or is set to 0.

  • The related UseRegionalCharset is similarly not set or is set to 0.

An uplevel browser, Internet Explorer 5 or a later version, sends messages in UTF-8. An earlier browser, or one other than Internet Explorer 5, sends messages in the appropriate encoding for that browser's acceptance language.

The UseAltRegionalCharset key only changes the behavior for browsers configured for the languages in the following list:

  • Korean : KS_C_5601-1987

  • Japanese: shift_jis

  • Western Europe: windows-1252

  • Russian: windows-1251

  • Central Europe: windows-1250

If the UseAltRegionalCharset key is set to 1, both uplevel and earlier browsers send messages in the following encodings:

  • Korean : euc_kr

  • Japanese: iso-2022-jp (JIS)

  • Western Europe: iso-8859-1

  • Russian: koi8-r

  • Central Europe: iso-8859-2

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer.

  • If the string value includes "Version 6.0", the computer is running Exchange 2000 Server.

  • If the string value includes "Version 6.5", the computer is running Exchange Server 2003.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • The UseAltRegionalCharset and the UseRegionalCharset are both present

  • The UseAltRegionalCharset and the UseRegionalCharset are both configured to use a value of 1 on an Exchange 2000 server or an Exchange 2003 server.

For Exchange 2000 Server and Exchange Server 2003, the alternative character sets take precedence when the following conditions are true:

  • The use of regional characters is turned on - the UseRegionalCharset registry key REG_DWORD value is set to -1.

  • The use of alternative character sets is turned on - the UseAltRegionalCharset registry key REG_DWORD value is set to 0x1.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this issue

  1. On the Exchange computer, open a registry editor such as Regedit.exe or RegEdt32.exe.

  2. Determine which Outlook Web Access language settings are appropriate for the Exchange Server environment and remove the key that is not appropriate.

    1. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

    2. Select the key to be removed, right-click the key, and then select Delete from the drop down list.

  3. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about Outlook Web Access language settings, see the following Exchange Server resources:

The "Exchange Server Client Access Guide" (http://go.microsoft.com/fwlink/?LinkId=47568).

Microsoft Knowledge Base article 311342, "XCCC: Exchange 2000 Server SP2 Server-Side OWA Registry Keys" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311342).


UseAltRegionalCharset registry value is enabled on Exchange 2000 Server
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the UseAltRegionalCharset is being used for the client language setting for Microsoft Outlook® Web Access:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseAltRegionalCharset

The level of the browser determines message encoding if the following conditions are true:

  • The UseAltRegionalCharset key is not set or is set to 0.

  • The related UseRegionalCharset is similarly not set or is set to 0.

The UseAltRegionalCharset key only changes the behavior for browsers configured for the languages in the following list:

  • Korean : KS_C_5601-1987

  • Japanese: shift_jis

  • Western Europe: windows-1252

  • Russian: windows-1251

  • Central Europe: windows-1250

If the UseAltRegionalCharset key is set to 1, both uplevel and earlier browsers send messages in the following encodings:

  • Korean : euc_kr

  • Japanese: iso-2022-jp (JIS)

  • Western Europe: iso-8859-1

  • Russian: koi8-r

  • Central Europe: iso-8859-2

The Exchange Server Analyzer queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 6.0", the computer is running Exchange 2000 Server.

If the Exchange Server Analyzer finds that the UseAltRegionalCharset is configured to use a value of anything larger than 0 on a computer that is running Exchange 2000 Server, the Exchange Server Analyzer displays a non-default configuration message.

This message indicates that the UseAltRegionalCharset registry parameter on this Exchange 2000 server is enabled. If you expect Outlook Web Access users in your organization to send mail frequently to recipients who use a variety of character sets, you can modify the registry settings so that users who are running Internet Explorer 5 or later versions can use UTF-8 encoded UNICODE characters to send mail. If you do not need multiple character sets, you can use the following procedure to restore the default configuration.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default language setting for Outlook Web Access

  1. On the Exchange computer, open a registry editor such as Regedit.exe or RegEdt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. In the right pane, delete the UseAltRegionalCharSet registry value.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about Outlook Web Access language settings, see Microsoft Knowledge Base article 311342, "XCCC: Exchange 2000 Server SP2 Server-Side OWA Registry Keys" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311342).


UseAltRegionalCharset registry value is enabled on Exchange Server 2003
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to look for the presence of the UseAltRegionalCharset registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\

The UseAltRegionalCharset registry value enables Microsoft Outlook® Web Access users to encode e-mail using an alternative character set.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 6.5", the computer is running Exchange Server 2003.

If the Exchange Server Analyzer finds the UseAltRegionalCharset registry value is set to anything larger than 0 on an Exchange 2003 server, the Exchange Server Analyzer displays a non-default configuration message.

This message indicates that UseAltRegionalCharset has been configured on this Exchange 2003 server. This setting may cause unintended character set encoding for Outlook Web Access messages, where some messages may be unreadable by some clients. We recommend that you verify that the client language settings are correct.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default language setting for Outlook Web Access on Exchange Server 2003

  1. On the Exchange computer, open a registry editor such as Regedit.exe or RegEdt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. In the right pane, delete the UseAltRegionalCharSet registry value.

  4. If the UseRegionalCharset registry value does not exist, follow these steps to create it:

    1. On the Edit menu, click New, and then click DWORD Value.

    2. Type UseRegionalCharset for the name of the DWORD, and then press Enter.

  5. If UseRegionalCharset exists, double-click it to modify it.

  6. In the Value data box, type 1, and then click OK.

  7. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the UseAltRegionalCharSet and UseRegionalCharset registry values, see Microsoft Knowledge Base article 283214, "XCCC: Outlook Web Access May Send a Japanese-Language Message in SJIS" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=283214).


UseRegionalCharset registry value is enabled on Exchange 2000 Server
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the language settings that are used by Microsoft Outlook® Web Access clients:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseRegionalCharset

The UseRegionalCharset registry value causes UTF-8 message bodies to persist in the store in the regional character set or codepage instead of in UTF-8 format.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 6.0", the computer is running Exchange 2000 Server.

If the Exchange Server Analyzer finds that UseRegionalCharset is configured to use a value of 1 or larger on a computer that is running Exchange 2000 Server, the Exchange Server Analyzer displays a non-default configuration message.

This message indicates that the UseRegionalCharset registry parameter on this Exchange 2000 server is enabled. If you expect Outlook Web Access users in your organization to send mail frequently to recipients who use a variety of character sets, you can modify registry settings so that users who are running Internet Explorer 5 or later versions can use UTF-8 encoded UNICODE characters to send mail. If you do not need multiple character sets, you can use the following procedure to restore the default configuration.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default language setting for Outlook Web Access

  1. On the Exchange computer, open a registry editor such as Regedit.exe or RegEdt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. In the right pane, delete the UseRegionalCharSet registry value.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


UseRegionalCharset registry value is disabled
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the language settings that are used by Microsoft Outlook® Web Access clients:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseRegionalCharset

The UseRegionalCharset registry value causes UTF-8 message bodies to persist in the store in the regional character set or codepage instead of in UTF-8 format.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 6.5", the computer is running Exchange Server 2003.

If the Exchange Server Analyzer finds that the UseRegionalCharset is configured to use a value of 0 on a computer that is running Exchange Server 2003, the Exchange Server Analyzer displays a non-default configuration message.

This message indicates that the UseRegionalCharset registry parameter on this Exchange 2003 server is disabled. This setting may cause unintended character set encoding for Outlook Web Access messages, where some messages may be unreadable by some clients.

When you use Microsoft Internet Explorer 5 or later versions to access Outlook Web Access, Exchange Server 2003 uses the browser's language settings to determine which character set to use to encode information such as e-mail messages and meeting requests.

If you expect Outlook Web Access users in your organization to send mail frequently to recipients who use a variety of character sets, you can modify the registry settings so that users who are running Internet Explorer 5 or later versions can use UTF-8 encoded UNICODE characters to send mail.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default language setting for Outlook Web Access

  1. On the Exchange computer, open a registry editor such as Regedit.exe or RegEdt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. If UseRegionalCharset does not exist, follow these steps to create it:

    1. On the Edit menu, click New, and then click DWORD Value.

    2. Type UseRegionalCharset for the name of the DWORD, and then press Enter.

  4. If UseRegionalCharset exists, double-click it to modify it.

  5. In the Value data box, type 1, and then click OK.

  6. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about Outlook Web Access language settings, see the "Exchange Server Client Access Guide" (http://go.microsoft.com/fwlink/?LinkId=47568).


UseRegionalCharset registry value is disabled or missing on Exchange Server 2003
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the language settings that are used by Microsoft Outlook® Web Access clients:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseRegionalCharset

The UseRegionalCharset registry value causes UTF-8 message bodies to persist in the store in the regional character set or codepage instead of in UTF-8 format.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 6.5", the computer is running Exchange Server 2003.

The Exchange Server Analyzer displays a warning message if either of the following conditions is true:

  • The UseRegionalCharset entry for an Exchange 2003 server is not present.

  • The UseRegionalCharset entry has a value of anything other than 1.

This message indicates that the UseRegionalCharset registry parameter on this Exchange 2003 server is disabled or missing. This setting may cause unintended character set encoding for Outlook Web Access messages, where some messages may be unreadable by some clients.

When you use Microsoft Internet Explorer 5 or later versions to access Outlook Web Access, Exchange Server 2003 uses the browser's language settings to determine which character set to use to encode information such as e-mail messages and meeting requests.

If you expect Outlook Web Access users in your organization to send mail frequently to recipients who use a variety of character sets, you can modify registry settings so that users who are running Internet Explorer 5 or later versions can use UTF-8 encoded UNICODE characters to send mail.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default language setting for Outlook Web Access

  1. On the Exchange computer, open a registry editor such as Regedit.exe or RegEdt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. If UseRegionalCharset does not exist, follow these steps to create it:

    1. On the Edit menu, click New, and then click DWORD Value.

    2. Type UseRegionalCharset for the name of the DWORD, and then press Enter.

  4. If UseRegionalCharset exists, double-click it to modify it.

  5. In the Value data box, type 1, and then click OK.

  6. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about Outlook Web Access language settings, see the "Exchange Server Client Access Guide" (http://go.microsoft.com/fwlink/?LinkId=47568).


User Load and MAPI Operations
Microsoft Exchange Server Analyzer - Articles > Protocols >

Topic Last Modified: 2006-10-17

The Microsoft® Exchange Server Analyzer Tool has determined that a few MAPI operations on the server are contributing to a significant percentage of the server user load. This determination is made by querying for operations that are consuming greater than 4 percent of the CPU time relative to total CPU time used in processing all RPC requests.

Common Causes of High CPU Percentage MAPI Operations

An administrator investigating poor Exchange Server performance should review whether the average mailbox size is high on any servers exhibiting poor performance. It should be determined if individual folders are excessively large (more than 5,000 items in a user's Inbox, Sent Items, Deleted Items, or Calendar folder). Large folders and mailbox growth can lead to increased CPU and I/O load. An increase in the number of views for each folder can also add overhead to many MAPI operations.

Views

Many of the common, long-running MAPI operations are related to views. A couple of the prominent ones are Restrict and FindRow. These operations do not always take a long time, and if their performance is a problem, you should understand why. Also note that, in addition to the following reasons, anytime there is a bottleneck for resources (generally a disk or CPU bottleneck), the latencies of operations will increase.

Note:
Sometimes there may be a high cost in TaskQ User Known in conjunction with Restrict or FindRow operations; this is because some of the work for these operations is performed in a TaskQ and the cost is attributed to TaskQ User Known.

Restrictions

The MAPI Restrict operation is used to select items that match particular criteria. The server creates a view that is, effectively, a table with associated criteria called a restriction. If the view that has a matching restriction already exists, the server uses the existing view to satisfy the user request. Using this view is relatively inexpensive; however, creating a new view is relatively expensive. By default, the store caches only 11 views for each folder. If the server is asked to create a twelfth view, it deletes the oldest cached view and create a new view. Views add overhead to all actions on items that match the views restriction.

Findrow

Client applications use the MAPI operations SeekRow or FindRow to move the cursor between rows in a view. SeekRow specifies how many rows to move the cursor, and is very low-cost in terms of CPU time. FindRow is quite expensive because it moves the cursor to the first item in a non-materialized (won't be cached) view that matches the restriction criteria, and then discards the view after the client application is finished with the action. The ultimate CPU cost of FindRow depends on the complexity of the restriction, and how many rows the store has to review before finding the first item that matches the criteria and so is loosely correlated with the number of items in the folder.

The high cost that can occur with Restrict and FindRow makes these good candidates for running cached mode which would get the cost off the server. Be aware that, sometimes, the high CPU percentage consumed by these may just be caused by shared calendars, in which case cached mode won't help. High consumption of percentage of CPU time by these operations could indicate a lot of view creation, expensive views, or large folder item counts.

For More Information

For more information, see the following Exchange Server resources:

  • Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)

  • Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkId=56460)


Storage
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2005-11-18

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating regarding storage. Additionally, these articles describe actions you can take to resolve storage-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


Aging Clean Interval for a mailbox store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the interval for removing unused database indexes has been modified from the default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>\Aging Clean Interval

If the Exchange Server Analyzer finds that the Aging Clean Interval key is present and configured, a non-default configuration message is displayed.

One of the functions of the Extensible Storage Engine is to dynamically create indexes when information is resorted or requested in a different sort order. As a result, the Exchange store database could have thousands of indexes on a table. The Exchange store handles this situation by assigning indexes an expiry time. Information about the index is added to an internal table referred to as the index aging table. During online maintenance, the index aging table is reviewed, and each entry's delete time value is compared to the current time. If the index has expired, the index is removed. By default, this process runs every 24 hours during the Exchange store maintenance cycle and removes entries older than 8 days for Exchange Server 5.5 and older than 40 days for Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007. The Aging Clean Interval key is the interval in milliseconds at which the Exchange store tries to remove unused indexes. The registry key can be used to override this default and perform this function at a custom interval.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Delete the Aging Clean Interval key.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Aging Clean Interval key, see the following Knowledge Base articles:

  • 159197, "XADM: Controlling Folder Index Aging" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=159197)

  • 216076, "Accessing information store folders may become slow in Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=216076)


Aging Clean Interval for a public folder store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the interval for removing unused database indexes has been modified from the default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>\Aging Clean Interval

If the Exchange Server Analyzer finds that the Aging Clean Interval key is present and configured, a non-default configuration message is displayed.

One of the functions of the Extensible Storage Engine is to dynamically create indexes when information is resorted or requested in a different sort order. As a result, the Exchange store database could have thousands of indexes on a table. The Exchange store handles this situation by assigning indexes an expiry time. Information about the index is added to an internal table referred to as the index aging table. During online maintenance, the index aging table is reviewed, and each entry's delete time value is compared to the current time. If the index has expired, the index is removed. By default, this process runs every 24 hours during the Exchange store maintenance cycle and removes entries older than 8 days for Exchange Server 5.5 and 40 days for Exchange 2000 Server and Exchange Server 2003. The Aging Clean Interval key is the interval in milliseconds at which the Exchange store tries to remove indexes. The registry key can be used to override this default and perform this function at a custom interval.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>

  3. Delete the Aging Clean Interval key.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Aging Clean Interval key, see the following Knowledge Base articles:

  • 159197, "XADM: Controlling Folder Index Aging" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=159197)

  • 216076, "Accessing information store folders may become slow in Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=216076)


All versions of Outlook are allowed to access the server
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether any versions of Microsoft Office Outlook® are blocked from connecting to Exchange Server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds that the Disable MAPI Clients key does not exist, a warning is displayed.

The Disable MAPI Clients key, which is not enabled by default, lets an administrator block specific versions of Outlook from connecting to a computer that is running Exchange 2000 Server, Exchange Server 2003, or Exchange Server 2007.

Recent releases and service packs to Outlook include many security and virus-fighting enhancements. Beginning with Outlook 2002, attachment blocking and Object Model Guard are included and enabled by default. These features are a critical component in the overall fight against viruses. The oldest version of Outlook that is supported by Microsoft Product Support Services is Outlook 2000 Service Pack 3 (SP3). If you are running earlier versions of Outlook in your organization, upgrade to Outlook 2003 or, at a minimum, update the Outlook client with the latest security releases.

After you update Outlook, you can lock out access to Exchange from earlier versions of Outlook that have not been updated. Locking out earlier versions of Outlook that do not support attachment blocking and Object Model Guard helps provide a known level of client security for MAPI client connections.

To help protect against all earlier versions of Outlook (Outlook 97, Outlook 98, Outlook 2000 before SP3, and earlier versions), it is strongly recommended that you disallow all versions of Outlook with build numbers equal to or earlier than 5.3164.0.0 from connecting to Exchange Server.

The client itself dictates the client's version string. This string is similar to the version number reported in the About dialog box for the client. However, do not rely on this version number. Instead, use Exchange System Manager to view the Client Version property on the Mailbox Store Logons page.

Important:
Before making any changes, note that hotfixes and service pack releases may affect the client version string. Be careful when you restrict client access, because server-side Exchange components also have to use MAPI to log on. Some components report their client version as the component name, such as SMTP or OLEDB, although others report the Exchange build number, such as 6.0.4712.0. For this reason, avoid restricting clients that have version numbers that start with 6.<x.x>. For example, to prevent MAPI access completely, instead of specifying 0.0.0-65535.65535.65535", instead specify two ranges, so that the server components can log on, as follows: 0.0.0-5.9.9; 7.0.0-65535.65535.65535.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Create a new String Value entry named Disable MAPI Clients.

  4. Double-click the Disable MAPI Clients registry entry and set the value data to the level that you want. The list of values in the Value Data string represents the different ways that you can disable ranges of MAPI client versions. The versions (vX) are typically in the following formats:

    • For Microsoft Outlook 2003 and Outlook 2007: Maj.Min.Build

    • For Microsoft Outlook 2000: Maj.Build.Dot

    • For earlier versions of Microsoft Outlook: Maj.Min.Build

    You can indicate all the specific versions or ranges of versions that you want to disable in this string. Use Exchange System Manager to determine the version of MAPI clients that connect to the mailbox store for Exchange Server 2003. In Exchange System Manager, locate the Logons container of the mailbox store. The Client Version column displays the version of the MAPI clients that are connected to the mailbox store.

    In Exchange Server 2007, use the Exchange Management Shell Get-LogonStatistics cmdlet to retreive the client version of MAPI clients that are connected to the mailbox database.
Important:
The MAPI client version is listed in Exchange System Manager and the Exchange Management Shell as X.0.Y.Z. This version must be entered as X.Y.Z in the registry value. For example, if Exchange System Manager lists the MAPI client version as 5.0.2819.0, enter 5.2819.0 in the Disable MAPI Clients registry value.
  1. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for more information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information about blocking specific MAPI clients from connecting to an Exchange 2000 Server or Exchange Server 2003 computer, see the following Microsoft Knowledge Base articles:

  • 328240, "How to put server-side restrictions on clients that are used to access Exchange 2000 mailboxes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328240)

  • 288894, "XADM: Feature to Disable MAPI Client Access" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=288894)

For more information about downloading security updates for older versions of Outlook and blocking other versions of Outlook, see "Slowing and Stopping E-mail Transmitted Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about the Get-LogonStatistics cmdlet, see "Get-LogonStatistics" (http://go.microsoft.com/fwlink/?LinkId=80699) in the Exchange Server 2007 product documentation.


AssertOnEvent is set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether debugging has been enabled on the Microsoft Exchange Information Store:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\AssertOnEvent

If the Exchange Server Analyzer finds that a value has been set for AssertOnEvent, the Exchange Server Analyzer displays a warning.

The AssertOnEvent registry value holds decimal values that specify which store events should trigger the debug mode of the Microsoft Exchange Information Store. The AssertOnEvent registry fires only when the debug version of store.exe is running. The Microsoft Exchange Information Store uses many resources when it runs in debug mode. It is not a best practice to debug the store in a production environment.

Unless you are actively troubleshooting an Exchange Information Store issue with the aid of Microsoft Product Support Services, you should delete the AssertOnEvent registry value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To delete the AssertOnEvent registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, locate and delete the AssertOnEvent value.

  4. Close the registry editor, and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


At least one corrupted message has been identified
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the count of the number of entries in the PoisonIDs value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS \<ExchangeServerName> \Private- <PrivateInformationStoreGUID>

If the Exchange Server Analyzer determines that the number of entries in the PoisonIDs value is greater than 0, a warning is displayed.

Versions of Exchange Server later than Exchange Server 2003 Service Pack 1 implement behavior that helps prevent corrupted or bad messages from causing the Microsoft Exchange Information Store service to stop unexpectedly or from preventing the Exchange Information Store service to start successfully.

In Exchange Server 2003 Service Pack 1 or later versions, messages that cause the Exchange Information Store service to stop unexpectedly during conversion from MAPI format to MIME format are tracked. The message ID of the corrupted message is stored in the registry when the crash occurs. If a corrupted message causes the store to stop unexpectedly three times, this information is used to prevent the message from being processed again when the Exchange Information Store service is restarted the fourth time.

When the Exchange Information Store service stops unexpectedly because of a corrupted message, the PoisonIDs registry value is created at:

HKLM\System\CurrentControlSet\Services\MSExchangeIS \<ExchangeServerName> \Private- <PrivateInformationStoreGUID>

Additionally, an administrator can create the PoisonThreshold registry entry. The PoisonThreshold key controls the maximum number of times a message can pass through the Exchange information store before it is added to the PoisonIDs registry key. By default, this threshold value is 2. To trigger the behavior, the threshold must be exceeded. Therefore, the Exchange Information Store service can stop 3 times because of a corrupted message before that message is blocked. For example, if a message is involved in 3 crashes, the message is blocked because three is more than the threshold value of 2.

When a corrupted message event is written to the registry, error event messages (Event IDs 9680 and 9681) will appear in the Application event log. After the Exchange Information Store service is successfully started, Exchange then blocks the message and tries to send a non-delivery report for it. In some cases, Exchange may be unable to send a non-delivery report. In these cases, the blocked message may remain in the queue until it expires. The PoisonIDs registry key contains up to ten message ID values. When the limit of ten is exceeded, a new corrupted message event is added. The corrupted message event that contains the oldest crash date is removed.

To correct this warning

  1. If you have a mailbox store that has problems with a corrupted message, you must further investigate the issue. For information about how Microsoft IT recovers from damaged Exchange databases, see http://go.microsoft.com/fwlink/?LinkId=56372.

  2. If you are experiencing problems with Exchange Server 2003 shutdowns because of corrupted messages, it may help to enable automatic error reporting on the Exchange Server computer. Error report data is used to find and to fix problems in the software that you use. For more information about how to enable Exchange Error Reporting, see Exchange Error Reporting is disabled.

For more information about Exchange Server 2003 Service Pack 1, see "Service Pack 1 for Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=29090).


Background Cleanup for a mailbox store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the current value data for the Background Cleanup registry value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>\Background Cleanup

If the Exchange Server Analyzer finds that the value data for Background Cleanup is set to any value other than 60,000 (decimal) or 0xEA60 (hexadecimal), a non-default configuration message is displayed. We recommend that Background Cleanup be set to the default value.

If the Background Cleanup value is set too high, the background cleanup process may not run frequently enough and many issues may be encountered. This includes the following:

  • Move mailbox may fail and an event 1205 with error code 0x4e3 may be logged.

  • Folder sizes and item counts shown in Exchange System Manager or Exchange Management Console may differ greatly from those shown by Microsoft Outlook®. In addition, database space occupied by these items may not be reclaimed.

  • Unread receipts for items that were deleted without being read may not be generated under certain circumstances.

  • Cleanup of old entries in the DeliveredTo table will not occur. The DeliveredTo table is used by the Exchange store to prevent the delivery of duplicate messages.

If the Background Cleanup value is set too low, the background cleanup process may cause unnecessary load on the server.

Caution:
Following the procedure in this topic to revert to the default configuration from a value that is too high can result in an increased load on the server until background cleanup has completed for all items that would have ordinarily been cleaned up at the default interval. Therefore, we recommend that you make these changes at a time during which users will be minimally affected. Additionally, if messages for which read receipts were requested have been deleted without being read and have not been cleaned up because of this issue, unread receipts will be generated for each of those messages after you correct this warning.
Important:
This article contains information about how to edit the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Change the value of Background Cleanup to 60,000 (decimal) or 0xEA60 (hexadecimal).

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Background Cleanup interval for a mailbox store is missing
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Background Cleanup registry value is present:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>\Background Cleanup

If the Exchange Server Analyzer finds that the Background Cleanup value is missing, a warning is displayed.

If the Background Cleanup value is missing, the background cleanup process does not run and numerous issues may be encountered, including:

  • Move mailbox may fail and an event 1205 with error code 0x4e3 may be logged.

  • Mailbox sizes and item counts shown in Exchange System Manager or Exchange Management Console may differ greatly from those shown by Microsoft Outlook®. In addition, database space occupied by these items may not be reclaimed.

  • Unread receipts for items that were deleted without being read may not be generated under certain circumstances.

  • Cleanup of the DeliveredTo table will not occur. The DeliveredTo table is used by the Exchange store to prevent the delivery of duplicate messages. The Track Duplicates value controls the time range for which entries in the DeliveredTo table are kept. If the Background Cleanup value is present but the Track Duplicates value is missing, entries over 24 hours old will be purged by background cleanup. The suggested value for Track Duplicates is 1 (decimal or hexadecimal).

It is recommended that Background Cleanup be set to the default value of 60,000 (decimal) or 0xEA60 (hexadecimal).

Caution:
Following the procedure below to correct this warning can result in an increased load on your server until background cleanup has completed for all items that would have normally been cleaned up on a regular basis. Therefore, it is recommended that you make these changes at a time during which users will be minimally impacted. Additionally, if messages for which read receipts were requested have been deleted without being read and have not been cleaned up due to this issue, unread receipts will be generated for each of those messages after you correct this warning.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Create a DWORD value called Background Cleanup with value data of 60000 (decimal) or 0xEA60 (hexadecimal).

  4. Close the registry editor. To make the changes take effect, do one of the following:

    • Dismount and mount the affected information stores.

    • Restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Background Cleanup interval for a public folder store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the current value data for the Background Cleanup registry value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<PublicStoreGUID>\Background Cleanup

If the Exchange Server Analyzer finds that the value data for Background Cleanup is set to any value other than 60,000 (decimal) or 0xEA60 (hexadecimal), a non-default configuration message is displayed. It is recommended that Background Cleanup be set to the default value.

If the Background Cleanup value is set too high, the background cleanup process may not run often enough and numerous issues may be encountered, including:

  • Folder sizes and item counts shown in Exchange System Manager may differ greatly from those shown by Microsoft Outlook®. In addition, database space occupied by these items may not be reclaimed.

  • Unread receipts for items that were deleted without being read may not be generated under certain circumstances.

  • Cleanup of old entries in the DeliveredTo table will not occur. The DeliveredTo table is used by the Exchange store to prevent the delivery of duplicate messages.

If the Background Cleanup value is set too low, the background cleanup process may cause unnecessary load on the server.

Caution:
Following the procedure below to revert to the default configuration from a value that is too high can result in an increased load on your server until background cleanup has completed for all items that would have normally been cleaned up at the default interval. Therefore, it is recommended that you make these changes at a time during which users will be minimally impacted. Additionally, if messages for which read receipts were requested have been deleted without being read and have not been cleaned up due to this issue, unread receipts will be generated for each of those messages after you correct this warning.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<PublicStoreGUID>

  3. Change the value data of Background Cleanup to 60,000 (decimal) or 0xEA60 (hexadecimal).

  4. Close the registry editor, and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Background Cleanup interval for a public folder store is missing
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Background Cleanup registry value is present:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicStoreGUID>\Background Cleanup

If the Exchange Server Analyzer finds that the Background Cleanup value is missing, a warning is displayed.

If the Background Cleanup value is missing, the background cleanup process does not occur and numerous issues may be encountered, including:

  • Folder sizes and item counts shown in Exchange System Manager or Exchange Management Console may differ greatly from those shown by Microsoft Outlook®. In addition, database space occupied by these items may not be reclaimed.

  • Unread receipts for items that were deleted without being read may not be generated under certain circumstances.

  • Cleanup of the DeliveredTo table will not occur. The DeliveredTo table is used by the Exchange store to prevent the delivery of duplicate messages. The Track Duplicates value controls time range for which entries in the DeliveredTo table are kept. If the Background Cleanup value is present but the Track Duplicates value is missing, entries over 24 hours old will be purged by background cleanup. The suggested value for Track Duplicates is 1 (decimal or hexadecimal).

It is recommended that Background Cleanup is set to the default value of 60,000 (decimal) or 0xEA60 (hexadecimal).

Caution:
Following the procedure below to correct this warning can result in an increased load on your server until background cleanup has completed for all items that would have normally been cleaned up on a regular basis. Therefore, it is recommended that you make these changes at a time during which users will be minimally impacted. Additionally, if messages for which read receipts were requested have been deleted without being read and have not been cleaned up due to this issue, unread receipts will be generated for each of those messages after you correct this warning.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicStoreGUID>

  3. Create a DWORD value called Background Cleanup with value data of 60000 (decimal) or 0xEA60 (hexadecimal).

  4. Close the registry editor. To make the changes take effect, do one of the following:

    • Dismount and mount the affected information stores.

    • Restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


BreakOnEvent is set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether debugging has been enabled on the Microsoft Exchange Information Store:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\BreakOnEvent

If the Exchange Server Analyzer finds that a value has been set for the BreakOnEvent registry value, the Exchange Server Analyzer displays a warning.

The BreakOnEvent registry value holds decimal values that specify which store events trigger the debug mode of the Microsoft Exchange Information Store. The Microsoft Exchange Information Store uses many resources when it runs in debug mode. It is not a best practice to debug the store in a production environment.

Unless you are actively troubleshooting an Exchange Information Store issue with the aid of Microsoft Product Support Services, you should delete the BreakOnEvent registry value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To delete the BreakOnEvent registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, locate and delete the BreakOnEvent value.

  4. Close the registry editor, and restart the Microsoft Exchange Information Store service to make the change take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Call tracing is disabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Call Trace logging is enabled:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Disable Call Tracing

If the Exchange Server Analyzer finds that the registry value for Disable Call Tracing is present and configured to use a value of 1, and the computer is running Exchange Server 2003, the Exchange Server Analyzer displays a non-default configuration message.

When Call Trace logging is enabled, function call data for the Store.exe processes is logged. By default, call tracing is enabled on computers that are running Exchange Server 2003. Note that this function is disabled by default on Exchange 2000 Server. However, if you are running Exchange Server 2003, you should enable call tracing unless you have been instructed otherwise under the guidance of Microsoft Product Support Services. If call tracing is enabled, it collects important information that you can use for troubleshooting any issues that occur with the store process.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open Registry Editor (Regedit.exe or Regedt32.exe).

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Set the Disable Call Tracing registry value to 0.

  4. Close Registry Editor, and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Call tracing is Enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Call Trace logging is enabled:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Disable Call Tracing

If the Exchange Server Analyzer finds that the registry value for Disable Call Tracing is present and configured with a value of 0, the Exchange Server Analyzer displays a non-default configuration message.

When Call Trace logging is enabled, function call data for the Store.exe processes is logged. Call Trace logging can cause a performance decrease of up to 4 percent. You should enable it only when you need it to troubleshoot slow or unresponsive Store.exe processes.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Set the Disable Call Tracing registry value to 1. The Flush Call Traces key, RPC Requests Threshold key, and Call Tracing Logging Interval keys are not used when Call Tracing is disabled.

  4. Close the registry editor, and restart the Exchange server for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Checkpoint depth is not set correctly on this cluster
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchESEParamCheckpointDepthMax attribute on each storage group. If the Exchange Server Analyzer finds that the msExchESEParamCheckpointDepthMax does not equal 5242880 on an Exchange 2000 Server cluster, a warning is displayed.

The msExchESEParamCheckpointDepthMax attribute is set in bytes and governs the maximum checkpoint depth. The checkpoint depth is the amount of data that is waiting to be committed to the Exchange store. The maximum checkpoint depth is the maximum amount of data that can be outstanding at any time. Therefore, if the maximum checkpoint depth is set to 20 MB, this is the maximum amount of data that can be outstanding (not committed to the Exchange store) at any time. In a clustered environment, a smaller value for this parameter causes faster failover times. Testing in Exchange Server 2003 showed that a value of 5 MB (5242880 bytes) for this parameter (instead of 20 MB, which was the default in Exchange 2000 Server) causes much faster failover times, without seriously affecting I/O performance on the server.

On Exchange 2000 Server clusters, this value should always be set to 5242880.

Caution:
If you incorrectly modify the attributes of Active Directory® directory service objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To set the msExchESEParamCheckpointDepthMax attribute using ADSI Edit

  1. Run Active Directory Service Interfaces (ADSI) Edit. ADSI Edit is provided with the Microsoft Windows® 2000 Server and Microsoft Windows Server™ 2003 Server Support Tools.

  2. In the console tree, right-click ADSIEdit, click Connect To, and then connect to the Configuration Naming Context.

  3. Expand the Configuration Container, CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=<OrganizationName>, CN=Administrative Groups, CN=<AdminGroupName>, CN=Servers, CN=<ServerName>, CN=Information Store.

  4. Right-click CN=<StorageGroupName>, and then click Properties.

  5. In the properties list, select msExchESEParamCheckpointDepthMax.

  6. Click Edit and type the size you want to set in 5 MB increments. The value must to be entered in bytes. For example, a 5 MB checkpoint depth is 5242880 bytes, and a 10 MB checkpoint depth is 10485760 bytes. The minimum size you can enter is 5 MB. If you enter a value over 20 MB, there will be an increase in the Microsoft Exchange Information Store service resource failover times.

  7. Close ADSIEdit, and then restart the Microsoft Exchange Information Store service.

For more information about deploying Exchange 2000 Server clusters, see "Deploying Microsoft Exchange 2000 Server Clusters" (http://go.microsoft.com/fwlink/?LinkID=14578).


Checkpoint file placement
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the checkpoint file path (msExchESEParamSystemPath) for each storage group on an Exchange server matches the transaction log path (msExchESEParamLogFilePath) for that storage group. If the Exchange Server Analyzer finds that the checkpoint file path does not match the transaction log path for the storage group, the Exchange Server Analyzer displays a best practice message.

If the location of the checkpoint file does not match the location of the transaction log files, you may experience extended downtime when disk failures occur.

To change the location of an Exchange storage group checkpoint file for Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, right-click the storage group, and then click Properties.

  2. On the General tab, in System path location, click Browse, and then choose a location for the checkpoint file.
To change the location of Exchange storage group transaction log files for Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, right-click the storage group, and then click Properties.

  2. On the General tab, in Transaction log location, click Browse, and then choose a location for the transaction log files.
To change the location of Exchange storage group transaction log files for Exchange Server 2007

  1. Follow the guidance in the core Exchange Server 2007 documentation, "How to Set or Change the Location of Storage Group Log Files" (http://go.microsoft.com/fwlink/?LinkId=80702).

For more information about location of the transaction log files, see "Managing Mailbox Stores and Public Folder Stores" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).

For more information about the checkpoint file, see "Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003" in Using Exchange Server 2003 Recovery Storage Groups (http://go.microsoft.com/fwlink/?LinkId=47589).


Circular Logging is disabled on this front-end server
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-03-27

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value configured for the circular logging (msExchESEParamCircularLog) attribute. If the Exchange Server Analyzer finds that this attribute is configured with a value of 0, a warning is displayed.

A value of 1 for the msExchESEParamCircularLog attribute indicates that circular logging is enabled. A value of 0 for the msExchESEParamCircularLog attribute indicates that circular logging is disabled.

In the standard transaction logging used by Exchange Server, each database transaction in a storage group is written to a log file and then to the database. When a log file reaches a certain size, it is renamed and a new log file is created. Over time, this results in a set of a log files. If there is a crash, you can recover the transactions by replaying the data from these log files into the database.

Circular logging overwrites and reuses the first log file after the data it contains has been written to the database. In Exchange Server, circular logging is disabled by default. By enabling it, you reduce drive storage space requirements, but without complete transaction log files, you cannot recover anything more recent than the last full backup. Therefore, on production servers that contain mailbox or public folder data, circular logging is not recommended. However, on front-end Exchange servers that do not have mailboxes or public folders, the only messages that are committed are non-delivery reports (NDRs); therefore, there is no need to keep the transaction files for these servers, nor is there much reason to back up these servers. Enabling circular logging on front-end servers allows the transaction log files to be overwritten and to never exceed 20 MB of data.

To enable circular logging

  1. In Exchange System Manager, expand Servers, and then expand an Exchange server.

  2. Right-click the storage group on which you want to enable circular logging, and select Properties. The storage group properties dialog box will appear.

  3. Select the Enable circular logging check box, and then click OK to save the changes.

  4. Exit Exchange System Manager and restart the Microsoft Exchange Information Store for the change to take effect.

For more information about circular logging, see the following Microsoft Knowledge Base articles:

  • 258470, "XADM: How to Modify the Circular Logging Setting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=258470)

  • 147524, "XADM: How Circular Logging Affects the Use of Transaction Logs" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=147524)

  • 296788, "Offline Backup and Restoration Procedures for Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=296788)

  • 314605, "HOW TO: Turn On or Turn Off Circular Logging in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=314605)


Circular logging is enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchESEParamCircularLog attribute of each storage group on the Exchange server. A value of 1 indicates that circular logging is enabled for the storage group. A value of 2 indicates that circular logging is not enabled for the storage group. In addition, the Exchange Server Analyzer also queries Active Directory to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

The Exchange Server Analyzer also queries the Exchange_Server Microsoft Windows® Management Instrumentation (WMI) class in the root\MicrosoftExchangeV2 namespace to determine the value for the IsFrontEndServer key. A value of True indicates the Exchange Server computer is a front-end server. A value of False indicates that the Exchange Server computer is not a front-end server.

If the Exchange Server Analyzer finds the value for the msExchESEParamCircularLog attribute set to 1, the value for the IsFrontEndServer key set to False, and the value of the homeMDBBL attribute to be greater than 20, a warning is displayed.

This combination of values indicates that circular logging is enabled on a mailbox server that contains more than 20 mailboxes. In the standard transaction logging used by Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007, each database transaction in a storage group is written to a log file and then to the database. When a log file reaches a certain size, it is renamed and a new log file is created. Over time, this results in a set of a log files. If there is a crash, you can recover the transactions by replaying the data from these log files into the database.

Circular logging overwrites and reuses the first log file after the data it contains has been written to the database. In Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007, circular logging is disabled by default. By enabling it, you reduce drive storage space requirements, but without complete transaction log files, you cannot recover anything more recent than the last full backup. Therefore, in a normal production environment, circular logging is not recommended.

To correct this warning for Exchange 2000 Server and Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, and then expand the server you want to modify.

  3. Right-click the storage group that you want to change, and then click Properties.

  4. In the Properties dialog box, clear the Enable circular logging check box.

  5. Click OK to save the setting.

  6. Close Exchange System Manager and restart the Microsoft Exchange Information Store service for the change to take effect.

To correct this warning for Exchange Server 2007 using Exchange Management Console

  1. Open Exchange Management Console.

  2. Expand Server Configuration, and then expand the server you want to modify.

  3. Right-click the storage group that you want to change, and then click Properties.

  4. In the Properties dialog box, clear the Enable circular logging check box.

  5. Click OK to save the setting.

  6. Close Exchange Management Console and restart the Microsoft Exchange Information Store service for the change to take effect.

To correct this warning for Exchange Server 2007 using Exchange Management Shell

  1. The following code is an example of the Set-StorageGroup command that disables circular logging for the 'MyStorageGroup' storage group.
Copy Code
Set-StorageGroup -Identity MyStorageGroup -CircularLoggingEnabled $false
  • For more information about circular logging, see the following Microsoft Knowledge Base articles:

  • 147524, "How Circular Logging affects the Use of Transaction Logs" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=147524)

  • 240145, "How to Tell Which Transaction Log Files Can Be Safely Removed" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=240145)


Circular logging is disabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-03-23

The Microsoft Exchange Analyzer tool queries the Active Directory directory service to determine the value configured for the msExchESEParamCircularLog attribute.

A value of 1 for the msExchESEParamCircularLog attribute indicates that circular logging is enabled. A value of 0 for the msExchESEParamCircularLog attribute indicates that circular logging is disabled.

The Exchange Analyzer also determines whether the following conditions are present:

  • Exchange Server is configured as a front-end server.

  • The SMTP service is running and determines how many mailboxes are configured.

If the Exchange Analyzer finds the following conditions are present, the Exchange Analyzer displays a warning:

  • The msExchESEParamCircularLog attribute is configured with a value of 0.

  • The server is not configured as a front-end server.

  • Fewer than 20 mailboxes are configured.

In the standard transaction logging that is used by Exchange Server, each database transaction in a storage group is written to a log file, and then each database transaction is written to the database. When a log file reaches a certain size, it is renamed, and a new log file is created. Over time, this standard transaction logging creates a set of log files. If the system fails, you can recover the transactions by replaying the data from these log files into the database.

Circular logging overwrites and reuses the first log file after the data that it contains has been written to the database. In Exchange Server, circular logging is disabled by default.

Important:
By enabling circular logging, you reduce drive storage space requirements. However, if you do not have complete transaction log files, you cannot recover anything more recent than the last full backup. Therefore, circular logging on production servers that contain mailbox data or public folder data is not recommended.

On front-end Exchange servers, message routing servers (also called infrastructure servers), and bridgehead servers that do not have user mailboxes or public folders, the only messages that are committed are non-delivery reports (NDRs). Therefore, you do not have to keep the transaction files for these servers. Additionally, you do not have to back up these servers. If you enable circular logging on servers that do not host user mailboxes, you can overwrite the transaction log files, and your transaction log files will never exceed 20 MB of data.

To enable circular logging for Exchange 2000 Server and Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, and then expand an Exchange server.

  3. Right-click the storage group on which you want to enable circular logging, and select Properties. The storage group properties dialog box will appear.

  4. Select the Enable circular logging check box, and then click OK to save the changes.

  5. Close Exchange System Manager and restart the Microsoft Exchange Information Store service for the change to take effect.
To enable circular logging for Exchange Server 2007 using Exchange Management Console

  1. Open Exchange Management Console.

  2. Expand Server Configuration, and then expand the server you want to modify.

  3. Right-click the storage group that you want to change, and then click Properties.

  4. In the Properties dialog box, select the Enable circular logging check box.

  5. Click OK to save the setting.

  6. Close Exchange Management Console and restart the Microsoft Exchange Information Store service for the change to take effect.
To enable circular logging for Exchange Server 2007 using Exchange Management Shell

  1. The following code is an example of the Set-StorageGroup command that enables circular logging for the MyStorageGroup storage group.
Copy Code
Set-StorageGroup -Identity MyStorageGroup -CircularLoggingEnabled $true

For more information about circular logging, see the following Microsoft Knowledge Base articles:

  • 258470, "XADM: How to Modify the Circular Logging Setting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=258470)

  • 147524, "XADM: How Circular Logging Affects the Use of Transaction Logs" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=147524)

  • 296788, "Offline Backup and Restoration Procedures for Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=296788)

  • 314605, "How to turn on or turn off circular logging in Exchange 2000 Server and Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=314605)


Client/Server RPC compression is disabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether remote procedure call (RPC) compression is enabled:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ Rpc Compression Enabled

If the Exchange Server Analyzer finds that the value for Rpc Compression Minimum Size is present and configured with a value of 0, a non-default configuration message is displayed.

By default, all RPC data that moves between Microsoft Office Outlook® 2003 or Outlook 2007 and Exchange Server 2003 or Exchange Server 2007 is compressed, regardless of its size. In some scenarios, you may want to control RPC compression. For example, if you are trying to troubleshoot connectivity problems by viewing the packets that are being sent over the network, RPC compression may make analysis difficult because you see only the compressed data in the trace.

To configure RPC compression settings, you can add three registry key values to the system settings:

  • Rpc Compression Minimum Size

  • Rpc Compression Enabled

  • Rpc Packing Enabled

The Rpc Compression Enabled registry value determines whether the RPC compression algorithms are used. If this key is not present, RPC compression is enabled and used.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the Rpc Compression Enabled key. If the Rpc Compression Minimum Size and Rpc Packing Enabled keys are present, delete those also.

  4. Close the registry editor, and restart the Exchange server for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about controlling RPC compression, see Knowledge Base article 825371, "Modify Remote Procedure Call Compression in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=825371).


ClientMonitoringReportLevel parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine how Exchange Server 2003 monitors network performance data for Microsoft Office Outlook® 2003:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds that the value for the ClientMonitoringReportLevel registry key is not 1, the Exchange Server Analyzer displays a non-default configuration message.

Exchange Server uses the value of the ClientMonitoringReportLevel registry key to identify network errors and latency problems with Outlook 2003 clients. The value of the ClientMonitoringReportLevel registry key has three possible settings.

Value | Function
0 | Do not collect any performance data from any Outlook 2003 client.
1 | Collect performance data from Outlook 2003 clients that have high-speed network connectivity only.
2 | Collect performance data from all Outlook 2003.

When you enable the ClientMonitoringReportLevel registry key with a value of 1 or 2, Outlook 2003 clients send data to the server. The data that is sent to the server indicates the status and state of the network connection. The data that is sent to the server includes information about failed remote procedure call (RPC) requests and error conditions. The server aggregates the information and exposes the information in event log entries.

Exchange Setup does not create the ClientMonitoringReportLevel registry key. However, the default behavior in Exchange Server 2003 is to collect performance data only from Outlook 2003 clients that have high-speed network connectivity. This default behavior of Exchange Server 2003 is functionally the same as the functionality when the value of the ClientMonitoringReportLevel registry key is set to 1.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required. However, you can edit the value of the ClientMonitoringReportLevel registry key if you want to restore the default value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, see the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Double-click ClientMonitoringReportLevel.

  4. In the Value data field, type 1, and then click OK.

  5. Close the registry editor.

The Microsoft Exchange Information Store service detects the changes in minutes. You do not have to restart the computer.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Consider implementing storage quotas
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether mailbox quotas have been set on each private message database (MDB) object. If the Exchange Server Analyzer finds that a particular private MDB contains more than 20 mailboxes and that quotas are not set on the MDB, the Exchange Server Analyzer displays a Best Practice configuration message.

It is a best practice to apply quotas to all databases on computers Exchange Server that host user mailboxes. There are three limits you should set at the database level. The limits are set on the Limits tab of the mailbox store properties page. Each limit is expressed in kilobytes (KB)

  • Warning The Issue warning limit defines the mailbox size that triggers a warning e-mail to the user. The warning e-mail tells the user that the mailbox size is approaching the Prohibit send limit.

  • Prohibit send The Prohibit send limit defines the mailbox size that prevents a user from sending e-mail. The user will receive an e-mail from the Exchange server explaining that the mailbox size limit has been exceeded.

  • Prohibit send and receive the Prohibit send and receive limit defines the mailbox size that prevents a user from both sending and receiving e-mail. All mail sent to the user is returned to the sender with a non-delivery report (NDR).

As you set these rules, make sure that you provide a wide enough delta between the Prohibit send limit and the Prohibit send and receive limit. If the delta between the two limits is too small, the mailbox may reject messages before the user has had an opportunity to clean-up their mailbox. Therefore, the best practice is to provide a buffer of at least 20 percent between the Prohibit send limit and the Prohibit send and receive limit. For example, if users are prohibited from sending new messages when their mailbox hits 100 MB, the Prohibit send and receive limit should be at least 120 MB.

To set mailbox limits on Exchange 2000 Server and Exchange Server 2003

  1. Open the Exchange System Manager.

  2. Locate the mailbox store displayed in the Exchange Server Analyzer regarding this issue.

  3. Right-click MailboxStore_Name and select Properties.

  4. Select the Limits tab.

  5. Modify the Issue warning at (KB), Prohibit send at (KB) limit and the Prohibit send and receive at (KB) limit.

  6. Click Apply, and then click OK.
To set mailbox limits on Exchange Server 2007 using the Exchange Management Console

  1. Open the Exchange Management Console

  2. Locate the mailbox store displayed in the Exchange Server Analyzer regarding this issue.

  3. Right-click MailboxStore_Name and select Properties.

  4. Select the Limits tab.

  5. Modify the Issue warning at (KB), Prohibit send at (KB) limit and the Prohibit send and receive at (KB) limit.

  6. Click Apply, and then click OK
To set mailbox limits on Exchange Server 2007 using the Exchange Management Shell

  1. The following example shows how to set the mailbox size at which a warning message is sent to the user. This attribute applies to all mailboxes in this mailbox database that do not have their own warning quota attribute set. You must specify either an integer or "unlimited." The default value is 1.9 gigabytes (GB).

    Copy Code
    Set-MailboxDatabase "Mailbox Database Name" -IssueWarningQuota 1991680

  2. The following example shows how to set the mailbox size at which users associated with mailboxes in this mailbox database can no longer send messages. This attribute applies to all mailboxes in this mailbox database that do not have their own prohibit send quota attributes set.. The limit value set must be either an integer or "unlimited."

    Copy Code
    Set-MailboxDatabase "Mailbox Database Name" -ProhibitSendQuota 2097152

  3. The following example shows how to set the mailbox size at which the user associated with this mailbox can no longer send or receive messages. This attribute applies to all mailboxes in this mailbox database that do not have their own prohibit send receive quota attributes set. You must specify either an integer or "unlimited."

    Copy Code
    Set-MailboxDatabase "Mailbox Database Name" -ProhibitSendReceiveQuota 2411520

For more information about how to manage Exchange mailboxes in Exchange Server 2003, see Working with Exchange Server 2003 Stores (http://go.microsoft.com/fwlink/?LinkId=47595).

For more information about how to manage Exchange mailbox limits in Exchange Server 2007, see "How to Configure Database Limits and Properties" (http://go.microsoft.com/fwlink/?LinkId=80746)


Content Indexing has been enabled on this mailbox store
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the Content Indexing Rebuild Schedule (msExchCIRebuildSchedule) attribute has been set to any non-null value and if the Content Indexing Rebuild Style (msExchCIRebuildStyle) attribute has been set. These are attributes of each private mailbox database. If the Exchange Server Analyzer finds that both these attributes are configured for indexing, a warning is displayed.

Running content indexing, also referred to as "full-text indexing," on a mailbox store is not recommended because full-text indexing is resource intensive, and mailbox data changes frequently. Therefore, keeping an up-to-date index of a given database is a very resource-intensive process. Full-text indexing is better suited for public folders.

If you want to run full-text indexing on a mailbox store, it is recommended that you set the indexing schedule to frequently update and monitor the computer's performance to ensure that the computer is not overwhelmed and remains able to deliver mail and respond to client requests while indexing the content.

Otherwise, it is recommended that you disable full-text indexing by deleting the full-text index on the mailbox store.

To disable full-text indexing on a given mailbox store

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, expand your server, expand your storage group, right-click Mailbox Store, and then click Delete Full-Text Index.

For more information about configuring and troubleshooting full-text indexing in Exchange, see the Microsoft Knowledge Base article, "HOW TO: Configure Full-Text Indexing on Mailbox Stores in Exchange 2003" (http://go.microsoft.com/fwlink/?LinkID=3052&kbid=822932).


Content Indexing has been enabled on this Public Folder store
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine if the Content Indexing Rebuild Schedule (msExchCIRebuildSchedule) attribute and the Content Indexing Rebuild Style (msExchCIRebuildStyle) attribute are present and set to anything other than 0. These are attributes of each public information store database.

If the Exchange Server Analyzer finds that both of these attributes are present and set to anything other than 0, a non-default configuration message is displayed.

When these two attributes are both set to 1, it indicates that full-text indexing has been enabled for the information store database. Full-text indexing enables powerful and fast searches by indexing every word in a specified database. When you deploy full-text indexing, you select an individual public folder or mailbox store to be indexed. Users can then conduct full-text searches on the messages and attachments contained in the public folder or mailbox store.

By default, the index contains the subject and body of a message, along with names of the sender and recipient and any names that appear in the Cc and Bcc fields. The index also includes text from the following types of attachments: .doc, .xls, .ppt, .html, .htm, .asp, .txt, and .eml (embedded Multipurpose Internet Mail Extensions (MIME) messages) files. Binary attachments, such as pictures and sounds, are not indexed.

Search results are only as accurate as the last time the index was updated. As the content of public folders or mailbox stores changes, the index must be updated to reflect the new content. Index updates can be performed manually or automatically on a schedule.

There are four major categories of full-text indexing files. You can optimize the performance of full-text indexing by arranging the disk location of these files as follows:

  • Catalogs Catalogs are the main indexes. There can be one catalog for each Exchange store. Place your catalog on a RAID-0+1 array. You can specify the catalog location in Exchange System Manager when you create the catalog.

  • Property store This is the database containing various properties of items indexed in the catalog. There is only one property store per server. Place the full-text property store on the RAID array. By default, the files are installed on the same drive as Exchange Server.

  • Temporary files These files contain temporary information used by the Microsoft Search service. Place the full-text index temporary directory on the RAID array. By default, these files are installed on the system drive, which typically does not have the I/O throughput of the RAID array.

  • Gatherer logs These files contain log information for the indexing service. One set of logs exists for each catalog. The gatherer logs can remain in their default location, or you can move them if you choose.

To enable or disable full-text indexing

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, and then expand the storage group containing the public folder store you are working with.

  3. Right-click the public folder store and select Properties.

  4. Select the Full-Text Indexing tab.

  5. Edit the Update interval field as desired.

  6. Click OK to save the changes and exit the public folder store Properties.

For more information about full-text indexing public folders, see the Microsoft Knowledge Base article 319433, "HOW TO: Configure Full-Text Indexing on Public Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319433).

For more information about configuring and troubleshooting full-text indexing on mailbox stores, see the following Knowledge Base articles:

  • 822932, "HOW TO: Configure Full-Text Indexing on Mailbox Stores in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822932)

  • 319436, "HOW TO: Configure Full-Text Indexing on Mailbox Stores in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319436)

For information about full-text indexing in a multi-language environment, see the Knowledge Base article 325624, "XGEN: Full-Text Indexing with Multiple Languages" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325624).

For more information about full-text indexing best practices, see the Knowledge Base article 326186, "XADM: White Paper - The Best Practices for Deploying Full-Text Indexing" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=326186).


DSNs are currently being rendered as messages
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if delivery status notifications (DSNs) on the Exchange Server computer are being rendered as standard messages:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent\RenderDSNsAsMessages

If the Exchange Server Analyzer finds the RenderDSNsAsMessages registry entry present and configured with a value greater than 0, a non-default configuration message is displayed.

As its name implies, the RenderDSNsAsMessages registry entry represents a configuration opportunity that enables administrators to control how DSNs are rendered on Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007 computers:

  • If the value data for RenderDSNsAsMessages is set to 0, DSNs (which include delivery reports and non-delivery reports) are rendered as standard MAPI messages.

  • If the value data for RenderDSNsAsMessages is set to any value greater than 0, DSNs are rendered as multipart/mixed MIME messages.

This registry value is not present by default and must be added manually to be used. In addition, for the entry to have the appropriate effect on Exchange 2000 Server, the computer must be running a minimum of the September 2003 Exchange 2000 Server Post-Service Pack 3 Rollup.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

  3. Delete the RenderDSNsAsMessages registry entry.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.
  • Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

  • For more information about delivery status notification format issues, see the Knowledge base article 812806, "Exchange user unexpectedly receives a standard NDR instead of a custom NDR" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=812806).

  • For more information about the Exchange 2000 Server Post-Service Pack 3 Rollup, see the Knowledge Base article 824282, "September 2003 Exchange 2000 Server Post-Service Pack 3 Rollup" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=824282).


Database Aging Keep Time interval has been modified from default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the default aging value for Exchange client view database indexes has been overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<Server name>\Private-<Private Information Store GUID>\Aging Keep Time

If the Exchange Server Analyzer finds the Aging Keep Time registry entry present and configured, a non-default configuration message is displayed.

Indexes used for views that are created in Exchange database tables by an Exchange client that have not been used for a given time are cleaned up at this time. The following registry entries are used to control index aging:

  • Aging Keep Time The minimum index age before it is deleted. The default is 8 days for Exchange Server 5.5 and 40 days for Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007.

  • Aging Clean Interval The minimum time interval (milliseconds) between index age task runs. The default is 24 hours.

  • Reset Views If this setting exists, and it is non-zero, this forces all cached indexes to be deleted during the next index aging task run. When the index aging is complete, the Reset Views value sets to 0.

It is recommended that you not add the Aging Keep Time registry value unless directed to by Microsoft Product Support Services.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To view or modify the Aging Keep Time registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\<Server name>\Private-<Private Information Store GUID>

  3. Examine and, if desired, change the Aging Keep Time value.

  4. Close the registry editor. If a change is made, restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Database and log files stored on same disk volume
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the database files for this mailbox store reside on the same physical disk as the transaction log files for this storage group. Specifically, the Exchange Server Analyzer queries Active Directory to determine the following:

  • Whether the mailbox store has more than 100 mailboxes, determined by counting the values of the homeMDBBL attribute of the mailbox store object (class msExchPrivateMDB). If the mailbox store has fewer than 100 mailboxes, the performance impacts of the file location will be limited.

  • The path of the database files for the mailbox store, determined by reading the value of the msExchEDBFile of the mailbox store object.

  • The path of the transaction log files for the storage group, determined by reading the value of the msExchESEParamLogFilePath of the storage group object (class msExchStorageGroup).

  • Whether that path in msExchESEParamLogFilePath is on the same disk as the path in msExchEDBFile.

Additionally, the Exchange Server Analyzer determines the following:

  • Whether the Exchange Server extensions for Windows-powered NAS are running on the server, determined by querying the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class for the value of the Started attribute for the Exchange Server NAS extensions (wssexchmap). If the Exchange Server extensions for Windows-powered NAS are running, it means that the files under consideration may not be on a local drive and performance considerations may not apply.

  • Whether the files are on a disk volume that has a name longer than three characters, determined by querying the Win32_Volume WMI class. Again, this may mean that the files may not be on a local drive and performance considerations may not apply.

To provide fault tolerance in case a hard disk fails, keep your Exchange transaction log files and database files on separate physical hard disks. When you keep these log files and database files on separate hard disks, you can significantly increase hard disk I/O performance.

Note:
To provide fault tolerance in case a database must be restored, each storage group has its own set of transaction log files. Transaction log files maintain a record of every change to every database in that storage group. Transaction log files are not deleted until a full backup is made of all the databases in a storage group.

The following examples illustrate how to recover data even in extreme circumstances (such as the loss of a hard disk that contains either your database files or your transaction log files) if you have a backup and your transaction log files are on a separate disk.

  • If the hard disk that contains your database files fails, you can replace the failed hard disk, restore the most recent backup of the database files, and then use the current log files that were stored on a separate hard disk to restore the data on your Exchange server and bring it up to date to the time at which the hard disk failed.

  • If the hard disk that contains your transaction logs fails, but the hard disk that contains your database files is functional, and the database store file is gracefully closed, you may be able to repair the failed transaction log disk and remount the database store. If the database store file does not close gracefully, it will remain in an inconsistent state and may only mount after a hard-repair using the eseutil.exe, which may result in some lost data. The other option is to restore the database store file from backup, which will not include new mailbox data created after the time of the backup.

Important:
If you keep your Exchange databases and transaction log files on the same physical hard disk, and that hard disk fails, you lose the data that was created after your last backup.

Additionally, putting database files and transaction log files on separate physical disks increases overall performance. Exchange writes each transaction to the transaction log file first, then to the database file. Additionally, the transaction log files are shared by all the mailbox stores in the storage group. When these files are on the same physical disk, the drive head must move back and forth between the location of the current transaction log file and the locations of the database files to complete the write operations. When the files are on separate disks, one drive head stays in position to write to the transaction log file, so transactions can be completed more quickly than when the files are on a single disk. The difference in performance for a single transaction is small, but it can become noticeable when the system load is high.

To correct your configuration, you can either move the transaction log files or the database files.

To move the transaction log files to a new drive in Exchange 2000 Server or Exchange Server 2003

  1. In Exchange System Manager, expand the appropriate Exchange server object, right-click the storage group you want, and then click Properties.

  2. On the General tab, specify a new location for the files.

    For example, if the E:\ drive will contain only log files for this storage group, in Transaction log location, click Browse, and then choose the E:\ drive.

To change the location of Exchange storage group transaction log files for Exchange Server 2007

  1. Follow the guidance in the core Exchange Server 2007 documentation, "How to Set or Change the Location of Storage Group Log Files" (http://go.microsoft.com/fwlink/?LinkId=80702).

To move the database files to a new drive in Exchange 2000 Server or Exchange Server 2003

  1. In Exchange System Manager, expand the Exchange server object on which the store resides, expand the appropriate storage group container, right-click the mailbox store object you want, and then click Properties.

  2. Specify new file locations on the Database tab of the Properties dialog box.
Caution:
To move a database file, the database must be temporarily dismounted and then remounted. This is done automatically by the wizard, but the database is inaccessible to all users during the process.

To move the database files to a new drive in Exchange Server 2007 using the Move Database Path wizard

  1. Start the Exchange Management Console on the server on which the storage group is located.

  2. In the console tree, expand Server Configuration, and then click Mailbox.

  3. In the results pane, expand the appropriate storage group container, right-click the mailbox database object you want, and then click Move Database Path. The Move Database Path wizard appears.

  4. On the Introduction page, the Database files path box displays the location where your database files are currently stored. Click Browse to specify a location to which to move these files.

  5. Click Move.

  6. On the Completion page, confirm whether the database file path was changed successfully. A status of Completed indicates that the wizard completed the task successfully. A status of Failed indicates that the task was not completed. If the task fails, review the summary for an explanation, and then click Back to make any configuration changes. Click Finish to complete the Move Database Path wizard.
Note:
You can also use the Exchange Management Shell to move database files in Exchange Server 2007. For more information, see Move- DatabasePath.

For more information about Exchange Server database files, see the following topics:

  • "Managing Mailbox Stores and Public Folder Stores" in Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617)

  • "Understanding the Exchange Server 2003 Store" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595)

For more information about managing Exchange Server database files, see the Microsoft Knowledge Base article 328794, "How to Protect Exchange Data from Hard Disk Failure" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328794)

For more information about hard repairing Exchange database stores, see the Knowledge Base article 296788, "Offline Backup and Restoration Procedures for Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=296788).

For more information about performing a hard repair on an Exchange database store file, see the Knowledge Base article 810190, "XADM: 'the information store terminated abnormally' error message and event ID 447 is logged" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810190).


Database Has All Log Files Present
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that all log files that are required to recover this database exist and are in the correct location for recovery. Therefore, the recovery failure is not caused by a missing or mismatched transaction log file.

It is possible that the databases or transaction log files are damaged or that other files are interfering with the recovery process.

To correct this error

  • Use Exchange System Manager to mount one of the databases in the storage group and then view the Application log for errors that may indicate the cause of the failure.

  • Recover the database in isolation. After analysis of the database, the Exchange Server Analyzer will display the instructions for recovering the database in isolation.

  • Run Eseutil.exe /ML to verify the integrity of the required log files. For more information about how to use Eseutil, see Microsoft Knowledge Base article 248122, "How to use Eseutil to test transaction log files for damage in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=248122).


Database Is in a Clean Shutdown State
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that your Exchange Database is in a Clean Shutdown state.

A database that is in a Clean Shutdown state has been shut down correctly and detached from the log file stream. As a result, if you want to mount the database again, you may do so with out performing any recovery operations.

If you cannot mount a database that is in a Clean Shutdown state, the reason is not because the database requires additional transaction log file replay. However, it is possible that transaction log replay required for other databases in the same storage group may prevent a Clean Shutdown database from mounting. Before any database in an Exchange storage group can be mounted, all databases in that storage group must be recovered and brought to a mountable state.

A database that is in a Clean Shutdown state can be mounted with its previous transaction logs or with a different set of transaction logs. If you mount a database that is in a Clean Shutdown state and no transaction logs exist, a new set of transaction logs will be generated.

Note:
Generally, you should not delete existing transaction log files, even if all databases in a storage group are in Clean Shutdown state. If you delete existing transaction log files, you will not be able to roll forward from previous backups. However, deleting transaction log files when all databases in a storage group are in a Clean Shutdown state does not affect the current databases. As a best practice, if you delete all transaction log files for a storage group, you should immediately create a full backup of all databases in the storage group.


Database Is in a Dirty Shutdown State and No Logs are Required
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-08-10

The Microsoft® Exchange Server Analyzer Tool has determined that your database in is a Dirty Shutdown state.

By definition, a database in a Dirty Shutdown state requires replay of at least one transaction log file. Dirty Shutdown is not a mountable state for the database and should not occur during general operation.

To correct this error

  • For advanced analysis of the database and log files, contact Microsoft Help and Support (http://go.microsoft.com/fwlink/?linkid=3052&kbid=31845).


Database Is in an Unknown State
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has found your database to be in unknown state. Ordinarily, your databases should be either in a Clean Shutdown or Dirty Shutdown state. (In Exchange 2000 Server and earlier, these states are called Consistent or Inconsistent respectively.)

To correct this error

  • For advanced analysis of the database state, contact Microsoft Help and Support (http://go.microsoft.com/fwlink/?LinkId=31845).


Database is Missing Optional and Required Log Files
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that log files that are required to recover this database are not found in the log file folder. If a required log file is missing, a database cannot be recovered until the log file is found.

If an Exchange database has not been shut down correctly, there are always log files that must be replayed into the database before it can be mounted again. At a minimum, there may be only a single log file that must be replayed. Typically, however, there are several log files.

In addition to the required log files, there may be additional log files that can be played into the database. Although it is not required that these optional log files are replayed before the database can be mounted, you can use these log files to recover additional data. If you do not replay these optional log files, all data that was contained within them will be lost.

To correct this error

  • Locate the missing transaction log files and add them to the appropriate folder.

  • If you cannot locate all the optional log files, you can recover the database in isolation with only the required log files. To recover the database without the optional log files, follow the instructions in the Exchange Server Analyzer. Remember, if you recover the database without the optional log files, you will lose the data that was in those optional files.

    However, depending on which log file is missing, you may be able to replay some of optional log files into the database. For example, consider the following scenario. You have log files numbered one through ten. The tenth log file is required (the remaining files are optional) the sixth log file is missing. In this case, you would be able to replay the log files numbered seven through ten because the sequential order up to the required file is constant.

  • Repair the current database.

    Note:
    Although repairing the database is likely to result in success, it is not guaranteed. Even a successful repair may result in minor or major data loss. For more information about repairing an Exchange database, see Microsoft Knowledge Base article 812357, "How to maintain your Exchange database after you repair by using the Eseutil /p tool in Exchange Server 5.5, in Exchange 2000 Server, and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812357).

  • Implement a hybrid strategy that includes repairing and restoring the database. Sometimes, you may be able to restore a database even though it cannot be rolled forward with additional log files. In these cases, you may be able to restore a previous copy of the database while simultaneously repairing the current copy that is not mountable. You can then merge the contents of the databases to maximize data salvage. This is an advanced strategy, and you may want to contact Microsoft Help and Support (http://go.microsoft.com/fwlink/?LinkId=31845) before implementation. For more information about this strategy, see Using Recovery Storage Groups in Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47589).


Database Is Missing Optional Log Files but not Required Log Files
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that one of your databases has not been shut down correctly.

If an Exchange database has not been shut down correctly, there are always log files that must be replayed into the database before it can be mounted again. At a minimum, there may be only a single log file that must be replayed. Typically, however, there are several log files.

In addition to the required log files, there may be additional log files that can be played into the database. Although it is not necessary that these optional log files are replayed before the database can be mounted, you can use these log files to recover additional data. If you do not replay these optional log files, all data that was contained within them will be lost.

To correct this error

  • Locate the missing optional log files and copy them to the transaction log folder.

  • If you cannot locate all the optional log files, you can recover the database in isolation with only the required log files. To recover the database without the optional log files, follow the instructions in the Exchange Server Analyzer. Remember, if you recover the database without the optional log files, you will lose the data that was in those optional files.

    However, depending on which log file is missing, you may be able to replay some of optional log files into the database. For example, consider the following scenario. You have log files numbered one through ten. The tenth log file is required (the remaining files are optional) the sixth log file is missing. In this case, you would be able to replay the log files numbered seven through ten because the sequential order up to the required file is constant.


Database is Missing Required Log Files
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that log files that are required to recovering this database are not found in the log file folder. If a required log file is missing, a database cannot be recovered until the log file is found.

To correct this error

  • Locate the missing transaction log files and add them to the appropriate folder.

  • Restore the database from backup. Then roll the database forward by playing the remaining transaction log files into the database.

    Important:
    Data in the missing log file and subsequent log files will be lost. Before you restore a database from backup, you should save a copy of the current database. If the restoration is unsuccessful, you may be able to repair the current database.

  • Repair the current database.

    Note:
    Although repairing the database is likely to result in success, it is not guaranteed. Even a successful repair may result in minor or major data loss. For more information about how to repair an Exchange database, see Microsoft Knowledge Base article 812357, "How to maintain your Exchange database after you repair by using the Eseutil /p tool in Exchange Server 5.5, in Exchange 2000 Server, and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812357).

  • Implement a hybrid strategy that includes repairing and restoring the database. Sometimes, you may be able to restore a database even though it cannot be rolled forward with additional log files. In these cases, you may be able to restore a previous copy of the database while simultaneously repairing the current copy that is not mountable. You can then merge the contents of the databases to maximize data salvage. This is an advanced strategy, and you may want to contact Microsoft Help and Support (http://go.microsoft.com/fwlink/?LinkId=31845) before implementation. For more information about this strategy, see Using Recovery Storage Groups in Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47589).


Databases in this storage group are set to zero pages during backup
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchESEParamZeroDatabaseDuringBackup attribute of each storage group on the server. If the Exchange Server Analyzer finds the msExchESEParamZeroDatabaseDuringBackup attribute is set to 1, the Exchange Server Analyzer Tool displays a non-default configuration message.

The msExchESEParamZeroDatabaseDuringBackup attribute represents a configuration setting that enables the overwriting of deleted records/long values with zeros during backup. This is a process known as zeroing out. You can control the zeroing out of database pages at the storage group level. Each storage group can have a different policy for zeroing out deleted database pages.

By default, zeroing out is disabled and the value for the msExchESEParamZeroDatabaseDuringBackup attribute is set to 0. When the attribute is set to 1, deleted database pages are overwritten with other characters at the end of online backups of any of the databases in that storage group.

Enabling and disabling zeroing out for Exchange 2000 Server and Exchange Server 2003 can be performed using Exchange System Manager, as described in this article. Enabling and disabling zeroing out for Exchange Server 2007 can be performed using Exchange Management Shell, also described in this article. While this option provides greater security, it does affect server performance.

Note If you enable zeroing out on an Exchange 2000 Server computer, it is recommended that you install Exchange 2000 Server Service Pack 3 or a later version. Service Pack 3 corrects a known issue that can cause the Exchange information store to stop responding. For more information about this issue, see the Microsoft Knowledge Base article 320883, "XADM: The Information Store Stops Responding During an Online Backup If Database Zeroing Is Turned On" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320883).

To enable or disable zeroing out for Exchange 2000 Server and Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, and then expand the server you want to modify.

  3. Right-click the storage group that you want to change, and then click Properties.

  4. In the Properties dialog box, select or clear the Zero Out Deleted Database Pages check box as needed. Selecting the check box enables zeroing out and clearing the check box disables zeroing out.

  5. Click OK to save the setting.

  6. Close Exchange System Manager, and then restart the Microsoft Exchange Information Store service for the change to take effect.

To enable or disable zeroing out of deleted pages for Exchange Server 2007

  1. The following code is an example of the Set-StorageGroup command that enables or disables zeroing out for the databases in the 'MyStorageGroup' storage group.
Copy Code
Set-StorageGroup -Identity MyStorageGroup -ZeroDatabasePages
 $false
Set-StorageGroup -Identity MyStorageGroup -ZeroDatabasePages
 $true

For more information about the affect on performance of overwriting deleted database pages, see the Knowledge Base article 815068, "XADM: Online Backup Performance Decreases Over Time" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815068).


Debug Break At Startup is set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether debugging has been enabled on the Microsoft Exchange Information Store:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Debug Break At Startup

If the Exchange Server Analyzer finds that a value has been set for Debug Break At Startup, the Exchange Server Analyzer displays a warning.

The Debug Break At Startup registry value turns on the debug mode the next time that the Microsoft Exchange Information Store service is started. The Microsoft Exchange Information Store uses many resources when it runs in debug mode. It is not a best practice to debug the store in a production environment.

Unless you are actively troubleshooting a store issue with the aid of Microsoft Product Support Services, you should delete the Debug Break At Startup registry value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To delete the Debug Break At Startup registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, locate and delete the Debug Break At Startup value.

  4. Close the registry editor, and restart the Microsoft Exchange Information Store service to make the change take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Default ESE log buffers have been changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool searches the Active Directory® directory service for the value for the msExchESEParamLogBuffers attribute of each storage group on the Exchange Server computer. If the Exchange Server Analyzer finds the value for msExchESEParamLogBuffers equal to 512, a non-default configuration message is displayed.

The msExchESEParamLogBuffers storage group attribute governs the number of Extensible Storage Engine (ESE) log buffers that are used by the Exchange information store. ESE uses a set of log buffers to hold information in RAM before it writes to the transaction logs. Using these buffers improves transaction logging performance. For large servers, the default value of 84 is too low. This can cause excessive disk I/O operations to the transaction log drive and, therefore, significant performance degradation if the server is under load or if users are sending large messages. Increasing the number of ESE log buffers improves performance, although it also causes more virtual memory usage.

To correctly set this value, use the following information:

  • For Exchange 2000 Server, Exchange 2000 Server Service Pack 1 (SP1), or Exchange 2000 Server Service Pack 2 (SP2), set this value to 9000.

  • For Exchange 2000 Server Service Pack 3 (SP3), set this value to 512.

  • For Exchange Server 2003, a default value of 500 is used, and you should change the value for the msExchESEParamLogBuffers attribute to 9000.

Note:
If you previously tuned log buffers to 9000, make sure that you manually reduce this setting after you apply Exchange 2000 Server SP3. This change is not made automatically when you install Exchange 2000 Server SP3.

If you have log stalls, this may be caused by too low a buffer, and you can raise this value up to 9000. The Database\Log Record Stalls/sec performance counter can be monitored to determine whether log stalls are occurring. Do not use a value greater than 9000, as that can corrupt transaction log files.

Note:
Log Record Stalls/sec is the number of log records that cannot be added to the log buffers per second because they are full. If this counter is non-zero most of the time, the log buffer size may be a bottleneck.

You must correct the value using a tool such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To revert to the default configuration

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=<ExchangeOrganizationName>.

  3. Expand CN=Administrative Groups, expand CN=<AdministrativeGroupName>, and then expand CN=Servers.

  4. Expand CN=<ServerName>, expand CN=InformationStore, right-click CN=<StorageGroupName>, and then click Properties.

  5. In the Attribute Editor, click the msExchESEParamLogBuffers attribute, and then click Edit.

  6. In the Edit Attribute box, set the value to 512 for Exchange 2000 Server or 9000 for Exchange Server 2003.

  7. Click Apply, and then click OK.

  8. Close ADSI Edit, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about ESE log buffers, see the Microsoft Knowledge Base article 328466, "XADM: ESE Log Buffers That Are Set Too Low Can Cause the Store to Stop Responding" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328466).

For more information about using the LDP tool, see the Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in the Windows Server Help.


Default public folder store is remote
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchHomePublicMDB attribute for each mailbox store contains the local Exchange Server. By default, the public folder store for a mailbox store is on the local Exchange Server. If the msExchHomePublicMDB attribute does not contain the local Exchange Server, the mailbox store has a remote default public folder store. If the Exchange Server Analyzer finds that a mailbox store has a remote default public folder store, the Exchange Server Analyzer displays a non-default configuration message.

To change the default public folder store

  1. In Exchange System Manager, expand Servers, expand <your Exchange server>, expand <storage group>, right-click the mailbox store, and then select Properties.

  2. On the General tab, under Default public store, click Browse to select a public folder store.

For more information about mailbox stores and public folder stores, see "Managing Mailbox Stores and Public Folder Stores" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


Deletion Thread Period for a mailbox store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the interval for removing deleted items has been modified from the default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>\Deletion Thread Period

If the Exchange Server Analyzer finds that the Deletion Thread Period key is present and configured, a non-default configuration message is displayed.

When you delete a message, Exchange marks the message for deletion. Exchange also marks the message as hidden until it is permanently deleted from the Exchange store. When the Exchange store receives a request to delete a message in a particular folder referenced by the Message ID, the Exchange store determines if the message should be soft deleted or hard deleted. The message is permanently deleted after its deleted item retention period has elapsed. Soft deletion is also referred to as logical deletion. Hard deletion is also referred to as physical deletion.

By default, a dumpster cleanup process runs every 24 hours runs that determines whether it is time to hard delete an item. The dumpster cleanup process is part of the Exchange store online maintenance process. If the deleted item retention period has elapsed, the item will be hard deleted. The Deletion Thread Period registry value is used to override the default 24-hour interval and specify a custom interval for the dumpster cleanup process.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Delete the Deletion Thread Period key.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about deleted item retention and recovery, see the following Knowledge Base articles:

  • 249680, "XADM: Understanding Deleted Item Retention and Message Deletion Process" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=249680)

  • 287544, "XADM: Public Information Store Grows Significantly When the Deleted Item Retention Functionality Is Enabled" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=287544)

  • 822938, "HOW TO: Use System Policies to Configure Mailbox Storage Limits in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822938)


Deletion Thread Period for a public folder store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the interval for removing deleted items has been modified from the default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>\Deletion Thread Period

If the Exchange Server Analyzer finds that the Deletion Thread Period key is present and configured, a non-default configuration message is displayed.

When you delete a message, Exchange marks the message for deletion. Exchange also marks the message as hidden until it is permanently deleted from the Exchange store. When the information store receives a request to delete a message in a particular folder referenced by the Message ID, the Exchange store determines whether the message should be soft deleted or hard deleted. Soft deletion is also referred to as logical deletion, and hard deletion is also referred to as physical deletion. The message is permanently deleted after its deleted item retention period has elapsed.

By default, a dumpster cleanup process runs every 24 hours that determines whether it is time to hard delete an item. The dumpster cleanup process is part of the Exchange store online maintenance process. If the deleted item retention period has elapsed, the item will be hard deleted. The Deletion Thread Period registry value is used to override the default 24-hour interval and specify a custom interval for the dumpster cleanup process.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>

  3. Delete the Deletion Thread Period key.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about deleted item retention and recovery, see the following Knowledge Base articles:

  • 249680, "XADM: Understanding Deleted Item Retention and Message Deletion Process" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=249680)

  • 287544, "XADM: Public Information Store Grows Significantly When the Deleted Item Retention Functionality Is Enabled" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=287544)

  • 319098, "HOW TO: Use System Policies to Configure Public Folder Storage Limits in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319098)


Disk Bottleneck Detected
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-11-14

The Microsoft® Exchange Server Analyzer Tool has determined that your disk system is currently running within 20 percent of the expected maximum available throughput. This determination is made by one of the following calculations:

  • Measuring disk latencies. The performance counters that indicate latency are LogicalDisk\Avg. Disk sec/Read and LogicalDisk\Avg. Disk sec/Write.

  • Comparing the maximum possible disk I/O per second (IOPS) of your current disk configuration and spindle count against the current IOPS value, as recorded by Performance Monitor (Perfmon).

Acceptable Latencies

Depending on the type of data that is being accessed, the Exchange server has different tolerance for delays. Because of this, the maximum acceptable average latency threshold is given based on the type of resource that is on the disk. For all cases, except where indicated in the following list, the maximum acceptable value for the read or write latencies is 50 milliseconds (ms).

  • Transaction log drives The drive that hosts the transaction log should have average write latencies below 10 ms. Spikes in write latencies should be under 50ms. Writes to the transaction log are synchronous. This means that, before a thread in the Store.exe process can perform another task, the thread must wait for the write to complete. Having low write latencies for the transaction logs is important to server performance. The average Read latency to the transaction log drives should be below 20 ms. Spikes in read latency should be under 50ms. Database Log Record Stalls per second should be less than 10. Database Log Threads Waiting should be less than 10.

    Ordinarily, Exchange servers do not read from the transaction logs. Therefore, the read latencies to that drive do not matter. However, because the transaction log write latencies are so important to Exchange performance, it is recommended that, on large servers, you do not use the drives that host transaction logs for any other purpose. In this case, the rate of reads (as measured by LogicalDisk\Disk Reads/sec) should be minimal compared to the rate of writes (LogicalDisk\Disk Writes/sec). The Exchange Server Analyzer will detect if the ratio of reads to writes on the transaction log drive is greater than 0.10 (more than one read for every ten writes).

    If there are more than 0.10 reads for every write, you should identify which application is reading from the transaction log drive, and then prevent this action from occurring.

  • Database drives The acceptable latency for the drives that contain Exchange database files ( *edb, and *stm files) are as below (higher values indicate a disk bottleneck):

    • The maximum value for Logical Disk\Avg. Disk sec/Read on a database drive should be less than 50 ms. (0.050 seconds)

    • The average value for Logical Disk\Avg. Disk sec/Read on a database drive should be less than 20 ms. (0.020 seconds)

  • TEMP and TMP drives The latency for the drives that contain the TEMP and TMP directories should have read and write latencies below 10 ms. The maximum value for the read or write latency should be below 50 ms.

  • Page and system drive The latency for the drives that contain page files and the Windows system files should have read and write latencies below 10 ms.

  • SMTP drive The latency for the drives that contain SMTP server files should have read and write latencies below 10 ms.

Causes of Latency

Disks that are accessed at a rate higher than the disk subsystem can support is one of the most common causes of disk latency. In this case, the disk is said to be a bottleneck. This also means that the disk subsystem is at or beyond its throughput capacity.

If the rate of disk IOPS (LogicalDisk\Disk Transfers/sec) is close to or greater than the estimated capacity, then the disk is referred to as "beyond throughput capacity" or "beyond capacity." In these cases, to improve server performance, you must either reduce the load on the disk subsystem (move users to another server) or increase the capacity of the drive (by adding more or faster spindles).

In cases where your hardware is not performing as expected, you may see latencies even when the I/O rate is significantly below the estimated capacity.

Reducing Disk Latency

To reduce the load on the disk subsystem, you can reduce some of the tasks that are performed by the server. Specifically, you should remove any optional applications that are contributing to disk load. The Store.exe process is the only application that should be accessing the database and transaction log drives.

Depending on your current disk system configuration, you can take several actions to reduce the effect of this issue.

To reduce disk latency

  • If a database or transaction log drive is bottlenecked, you can reduce load on that drive by moving users to a database or storage group that is hosted on a drive that is not near maximum capacity. If all the databases or transaction log drives are nearing capacity, you may have to move users to another server. For more information, see Move User Mailboxes to Another Server

  • Occasionally the duration of a high I/O rate is brief because it is caused by an expensive MAPI operation. In that case, to determine which user or action is causing high I/O rates, you can use the Exchange Server User Monitor (ExMon) tool in conjunction with the logical disk performance counters. If you can isolate the user, you may be able to identify which client application is generating the greater load. You can download ExMon from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=54983).

  • If you are running a RAID-5 disk array, you may want to change to a RAID-10 disk array to improve the available supported IOPS of the disk subsystem.

  • To improve the available supported IOPS, consider adding additional disks to your disk system.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about best practices for designing storage architectures, see Best Practices Common to Multiple Architectures (http://go.microsoft.com/fwlink/?LinkId=72988).

  • For more information on moving user mailboxes to reduce server load, see Move User Mailboxes to Another Server.

  • For more information about disk sizing, latency, and I/O rates, see the following blogs on the Microsoft Exchange Team Blog Web site:

    • "A few basic concepts in disk sizing" (http://go.microsoft.com/fwlink/?linkid=39538)

    • "Some more thoughts on disk IO and calculations…." (http://go.microsoft.com/fwlink/?linkid=39539)

    • How to Calculate Your Disk I/O Requirements (http://go.microsoft.com/fwlink/?linkid=69747)


Disk bottleneck found on disk containing the transaction log files
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that the disk system that holds the Exchange Server log files is over tasked and causing a performance bottleneck. This determination is made by checking one or more of the following performance counters:

  • The average Database\Log Record Stalls/sec are more than 10.

  • The maximum Database\Log Record Stalls/sec is more than 100.

  • The average Database\Log Threads Waiting are more than 10.

  • The maximum Database\Log Threads Waiting is more than 20.

If any one of these thresholds is met, an error is displayed stating that your log drive is a disk bottle neck. Log files require a low-write latency. Any backup or stalling in writing to a log file can cause server performance issues. Log stalls may be caused by a low log buffer setting, msExchESEParamLogBuffers, or by too many users connecting to the server.

To reduce log disk latency

  • You can raise the ESE buffers parameter, msExchESEParamLogBuffers, to 9,000. Do not use a value larger than 9,000, as that can corrupt transaction log files. For more information, see Default ESE log buffers have been changed.

  • If a database or transaction log drive is bottlenecked, you can reduce the load on that drive by moving users to a database or storage group that is hosted on a drive that is not near maximum capacity. If all the databases or transaction log drives are nearing capacity, you may have to move users to another server. For more information, see Move User Mailboxes to Another Server.


EnableChangeNotification is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether file change notification for the Exchange Installable File System (ExIFS) has been enabled:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EXIFS\Parameters\ EnableChangeNotification

If the Exchange Server Analyzer finds that the EnableChangeNotification key is present and configured with a value greater than 0, a non-default configuration message is displayed.

By default, file change notification is disabled for ExIFS. When ExIFS sends change notifications for a file or a directory, it does not clear the cached version of the file or directory. As a result, when an application such as Exchange Server or Microsoft SharePoint® Portal Server receives a change notification and reloads the file or directory, the application gets the cached version and not the newly modified file or directory.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\EXIFS\Parameters

  3. Delete the EnableChangeNotification key.

  4. Close the registry editor, and restart the Exchange server for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986 "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Exchange Installable File System, see the following:

  • Chapter 26 "Exchange 2000 Architecture," Exchange 2000 Server Resource Kit (http://go.microsoft.com/fwlink/?LinkId=51224)

  • Exchange Server 2003 Technical Reference Guide (http://go.microsoft.com/fwlink/?linkid=47891)


Error Accessing Log Directory
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that the path defined on the Exchange server for this storage group's transaction logs is inaccessible.

To correct this error

  • Verify that the path actually exists on the server.

  • Verify that you have the permissions that are required to read files that are stored in the transaction log path.


Error Accessing Streaming Database File
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined the Exchange streaming database (.stm) file is inaccessible.

Each database in Exchange 2000 Server and Exchange Server 2003 is made up of two files: the .edb Exchange database file and the .stm streaming database file. These files must be accessed and processed together.

To correct this error:

  • Locate the path for the .stm file. In Exchange System Manager, this path is defined on the database properties page for each database object.

  • Verify that the .stm file for this database exists.

  • Verify that you have permissions to access the folder where the .stm file is located.

  • Verify that the file has not been exclusively locked by another process. One way to verify this is to try to rename the file. If you can successfully rename the file, this indicates the file is not exclusively locked. (Remember to rename the file back to its original name.)


Error Checking Log Files
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool was unable to read the transaction log files.

To correct this error

  • Verify that you have the permissions that are required to access the transaction log file folder.

  • Verify that the file has not been exclusively locked by another process. One way to verify this is to try to rename the file. If you can successfully rename the file, this indicates the file is not exclusively locked. (Remember to rename the file back to its original name.)


ESE log buffers are at maximum on this storage group
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchESEParamLogBuffers attribute for each storage group. If the Exchange Server Analyzer finds the value for the msExchESEParamLogBuffers attribute equal to 9,000, a non-default configuration message is displayed.

Extensible Storage Engine (ESE) uses a set of log buffers to hold information in RAM before it writes to the transaction logs. Using these buffers improves transaction logging performance. For large servers, the default value of 84 is too low. This can cause excessive disk I/O operations to the transaction log drive and, therefore, significant performance degradation if the server is under load or if users are sending large messages. Increasing the number of ESE log buffers improves performance, although it also causes more virtual memory usage.

To correctly set this value, use the following information:

  • For Exchange 2000 Server, Exchange 2000 Server Service Pack 1 (SP1), or Exchange 2000 Server Service Pack 2 (SP2), set this value to 9000.

  • For Exchange 2000 Server Service Pack 3 (SP3), set this value to 512.

  • For Exchange Server 2003, a default value of 500 is used, and you should change the value for the msExchESEParamLogBuffers attribute to9000.

Note:
If you previously tuned log buffers to 9000, make sure that you manually reduce this setting after you apply Exchange 2000 Server SP3. This change is not made automatically when you install Exchange 2000 Server SP3.

If you have log stalls, this may be caused by too low a buffer, and you can raise this value up to 9000. The Database\Log Record Stalls/sec performance counter can be monitored to determine whether log stalls are occurring. Do not use a value greater than 9000, as that can corrupt transaction log files.

Note:
Log Record Stalls/sec is the number of log records that cannot be added to the log buffers per second because they are full. If this counter is non-zero most of the time, the log buffer size may be a bottleneck.

You must correct the value using a tool such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To revert to the default configuration

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=<ExchangeOrganizationName>.

  3. Expand CN=Administrative Groups, expand CN=<AdministrativeGroupName>, and then expand CN=Servers.

  4. Expand CN=<ServerName>, expand CN=InformationStore, right-click CN=<StorageGroupName>, and then click Properties.

  5. In the Attribute Editor, click the msExchESEParamLogBuffers attribute, and then click Edit.

  6. In the Edit Attribute box, set the value to 512 for Exchange 2000 Server or 9000 for Exchange Server 2003.

  7. Click Apply, and then click OK.

  8. Close ADSI Edit, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about setting ESE log buffers, see the Microsoft Knowledge Base article 328466, "XADM: ESE Log Buffers That Are Set Too Low Can Cause the Store to Stop Responding" (http://go.microsoft.com/fwlink/?LinkID=3052&kbid=328466).


ESE log buffers are set too low on this storage group
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the msExchESEParamLogBuffers value of each storage group object (class msExchStorageGroup) in the InformationStore container. If the Exchange Server Analyzer finds that the value for this attribute less than 500, a warning is displayed.

Extensible Storage Engine (ESE) uses a set of log buffers to hold information in RAM before it writes to the transaction logs. Using these buffers improves transaction logging performance. For large servers, the default value of 84 is too low. This can cause excessive disk I/O operations to the transaction log drive and, therefore, significant performance degradation if the server is under load or if users are sending large messages. Increasing the number of ESE log buffers improves performance, although it also causes more virtual memory usage.

To correctly set this value, use the following information:

  • For Exchange 2000 Server, Exchange 2000 Server Service Pack 1 (SP1), or Exchange 2000 Server Service Pack 2 (SP2), set this value to 9000.

  • For Exchange 2000 Server Service Pack 3 (SP3), set this value to 512.

  • For Exchange Server 2003, a default value of 500 is used, and you should change the value for the msExchESEParamLogBuffers attribute to 9000.

Note:
If you previously tuned log buffers to 9000, make sure that you manually reduce this setting after you apply Exchange 2000 Server SP3. This change is not made automatically when you install Exchange 2000 Server SP3.

If you have log stalls, this may be caused by too low a buffer, and you can raise this value up to 9000. The Database\Log Record Stalls/sec performance counter can be monitored to determine whether log stalls are occurring. Do not use a value greater than 9000, as that can corrupt transaction log files.

Note:
Log Record Stalls/sec is the number of log records that cannot be added to the log buffers per second because they are full. If this counter is non-zero most of the time, the log buffer size may be a bottleneck.

You must correct the value using a tool such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this warning

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=<ExchangeOrganizationName>.

  3. Expand CN=Administrative Groups, expand CN=<AdministrativeGroupName>, and then expand CN=Servers.

  4. Expand CN=<ServerName>, expand CN=InformationStore, right-click CN=<StorageGroupName>, and then click Properties.

  5. In the Attribute Editor, click the msExchESEParamLogBuffers attribute, and then click Edit.

  6. In the Edit Attribute box, set the value to 512 for Exchange 2000 Server or 9000 for Exchange Server 2003.

  7. Click Apply, and then click OK.

  8. Close ADSI Edit, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about ESE log buffers, see the Microsoft Knowledge Base article 328466, "XADM: ESE Log Buffers That Are Set Too Low Can Cause the Store to Stop Responding" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328466).

For more information about using the LDP tool, see the Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about setting ESE log buffers, see the Knowledge Base article 328466, "XADM: ESE Log Buffers That Are Set Too Low Can Cause the Store to Stop Responding" (http://go.microsoft.com/fwlink/?LinkID=3052&kbid=328466).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in the Windows Server Help.


ESE log buffers are set too high on this storage group
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchESEParamLogBuffers attribute of each storage group. If the Exchange Server Analyzer determines that the value of the msExchESEParamLogBuffers attribute for any storage group is greater than 9,000, an error is displayed.

Extensible Storage Engine (ESE) uses a set of log buffers to hold information in RAM before it writes to the transaction logs. Using these buffers improves transaction logging performance. For large servers, the default value of 84 is too low. This can cause excessive disk I/O operations to the transaction log drive and, therefore, significant performance degradation if the server is under load or if users are sending large messages. Increasing the number of ESE log buffers improves performance, although it also causes more virtual memory usage.

To correctly set this value, use the following information:

  • For Exchange 2000 Server, Exchange 2000 Server Service Pack 1 (SP1), or Exchange 2000 Server Service Pack 2 (SP2), set this value to 9000.

  • For Exchange 2000 Server Service Pack 3 (SP3), set this value to 512.

  • For Exchange Server 2003, a default value of 500 is used, and you should change the value for the msExchESEParamLogBuffers attribute to 9000.

Note:
If you previously tuned log buffers to 9000, make sure that you manually reduce this setting after you apply Exchange 2000 Server SP3. This change is not made automatically when you install Exchange 2000 Server SP3.

If you have log stalls, this may be caused by too low a buffer, and you can raise this value up to 9000. The Database\Log Record Stalls/sec performance counter can be monitored to determine whether log stalls are occurring. Do not use a value greater than 9000, as that can corrupt transaction log files.

Note:
Log Record Stalls/sec is the number of log records that cannot be added to the log buffers per second because they are full. If this counter is non-zero most of the time, the log buffer size may be a bottleneck.

You must correct the value using a tool such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=<ExchangeOrganizationName>.

  3. Expand CN=Administrative Groups, expand CN=<AdministrativeGroupName>, and then expand CN=Servers.

  4. Expand CN=<ServerName>, expand CN=InformationStore, right-click CN=<StorageGroupName>, and then click Properties.

  5. In the Attribute Editor, click the msExchESEParamLogBuffers attribute, and then click Edit.

  6. In the Edit Attribute box, set the value to 512 for Exchange 2000 Server or 9000 for Exchange Server 2003.

  7. Click Apply, and then click OK.

  8. Close ADSI Edit, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about setting ESE log buffers, see the Knowledge Base article 328466, "XADM: ESE Log Buffers That Are Set Too Low Can Cause the Store to Stop Responding" (http://go.microsoft.com/fwlink/?LinkID=3052&kbid=328466).


ESE Log file size has been manually changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchESEParamLogFileSize attribute of the InformationStore container. If the Exchange Server Analyzer finds that the value for the msExchESEParamLogFileSize attribute does not equal 5120, an error is displayed.

This value applies to all storage groups on the server. This particular error arises if the value of this attribute has been changed from its default (5120 KB or 5 MB). This is the only value supported, and should never be changed.

You must correct the value by using a utility such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Open an Active Directory editor, such as ADSI Edit, and locate the InformationStore object for this Exchange Server computer in Active Directory.

    The msExchESEParamLogFileSize attribute can be found at:

    CN=Configuration, DC=Domain, CN=Services, CN=Microsoft Exchange, CN= OrganizationName , CN=Administrative Groups, CN= AdministrativeGroupName , CN=Servers, CN= ServerName , CN=InformationStore

  2. Double-click the msExchESEParamLogFileSize attribute and set its value to 5120.

  3. Close the Active Directory editor and restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about using LDP.exe to edit Active Directory attributes, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in the Windows Server Help.


ESE Maximum open tables has been hard-coded
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine if the msExchESEParamMaxOpenTables attribute is present for any of the storage group objects under the InformationStore object of the Exchange Server object. If the Exchange Server Analyzer finds that the msExchESEParamMaxOpenTables attribute is present and configured, a non-default configuration message is displayed.

By default, for Exchange 2000 Server and Exchange Server 2003, this attribute is present but not set with any value. Exchange Server caches data about folders that are not currently being accessed. In some cases, this may contribute to virtual memory fragmentation. One way to mitigate this is to reduce the maximum number of database tables that can be open concurrently. The actual suggested value for this varies depending on the version of Exchange Server and the Exchange service pack that is installed. For Exchange 2000 Server Service Pack 2, the default setting for 8-processor servers is 85,000 tables per storage group. This is reduced to 27,600 in Exchange 2000 Server Service Pack 3 for 8-processor servers. For 4-processor servers, the value is 13,800. This value can be lowered to reduce virtual memory fragmentation issues. However, lowering this value could also cause situations where operations may fail because of too many open tables. The error occurs because the maximum number of tables that could be concurrently open is being lowered, which means the maximum is reached sooner.

Exchange Server 2003 uses a different method for caching data about folders that are not currently being accessed. Therefore, reducing the maximum number of open tables is neither necessary nor effective for reducing virtual memory fragmentation issues. This attribute should not be set on an Exchange Server 2003 server.

Unless you have been instructed by Microsoft Product Support Services to enter a value here, use the Active Directory Service Interfaces (ADSI) Edit tool to clear the value set on this attribute.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To clear the msExchESEParamMaxOpenTables attribute value

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=ExchangeOrganizationName.

  3. Expand CN=Administrative Groups, expand CN=AdministrativeGroupName, and then expand CN=Servers.

  4. Expand CN=ExchangeServerName, expand CN=InformationStore, right-click CN=StorageGroupName, and then click Properties.

  5. In the Select a property to view box, click msExchESEParamMaxOpenTables.

  6. In the Edit Attribute box, click Clear to change the value to <not set>.

  7. Click OK, and then click OK again.

  8. Close the Active Directory editor and restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about this attribute, see the 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).

For more information about using the LDP tool, see the Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).


The Exchange Database exceeds 100 GB in size
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool queries the CIM_DataFile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FileSize key for each Exchange information store database. If the combined size of an information store's .edb file and .stm file exceeds 100 gigabytes (GB), a warning is displayed.

Microsoft recommends that information store databases grow no larger than 50 GB. Assuming proper maintenance, there are no operational issues with running mailbox stores larger than 50 GB; however, backup and restore times may make larger mailbox stores unsuitable for some service level agreements (SLAs).

If you run mailbox stores larger than 50 GB, verify that your hardware is matched appropriately with the service level agreement such that restoration of large databases is within your SLA. Otherwise, it is recommended that you distribute mailboxes across multiple mailbox stores so that no single mailbox store is over 50 GB in size.

To correct this warning

  1. Consider moving some of the mailboxes from the large information store to a new information store on this or another Exchange Server computer.

  2. If you have recently moved mailboxes from this information store to another store, or if you have recently deleted mailboxes from this information store, performing an offline defragmentation may decrease the size of the files.

  3. Consider setting mailbox or message size limits to prevent unlimited growth of the information store database.

For more information about .stm and .edb files, see the Microsoft Knowledge Base article 232323, "Native Content Storage in Microsoft Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323).

For more information about moving mailboxes in Exchange Server 2003, see the Knowledge Base article 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829).

For more information about moving mailboxes in Exchange 2000 Server, see the Knowledge Base article 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810).

For more information about performing an offline defragmentation of an Exchange Server database, see the Knowledge Base article 328804, "How to Defragment Exchange Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804).

For more information about setting message size limits, see the Knowledge Base article 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679).


Exchange database files are being written to a compressed folder
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Compressed key for the folder containing the Exchange information store database files. If the value for Compressed is set to True for this folder, an error is displayed.

On an Exchange 2000 Server or an Exchange Server 2003 computer, the information store databases are written to the following default location:

<drive> :\Program Files\Exchsrvr\mdbdata

On an Exchange Server 2007 computer, the database files are written to the following default location:

<drive> :\Program Files\Microsoft\Exchange Server\Mailbox\<Storage Group Name>

Microsoft does not support the storage of Exchange data files on an NTFS compressed volume. When you store your Exchange data files on a compressed volume, the additional overhead significantly impacts the performance of Exchange. In addition, after an information store database reaches a certain size (approximately 4 GB), it may fail to mount or it may become corrupt.

The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

Files that are managed by the Extensible Storage Engine (ESE) are not designed to be stored on a compressed drive. The ESE depends on sector independence for log-based recovery, and compression of files invalidates sector independence. Compression should not be turned on for volumes hosting ESE databases, or any database that uses write-ahead logging.

Before Exchange 2000 Server Service Pack 3, compressed information store databases were allowed to mount. However, corruption can result in any Exchange 2000 Server information store databases or information store logs that have been compressed by using NTFS compression.

With Exchange 2000 Server Service Pack 3, compressed information store database files of 128 MB or fewer are automatically decompressed. When database files grow to larger than 128 MB, the database does not mount and the error messages are generated in the application log. Exchange 2000 Server Service Pack 3 prevents compressed databases larger than 128 MB from mounting.

To turn off file compression on a given folder

  1. Right-click the folder for which you want to turn off file compression, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Compress contents to save disk space check box, and then click OK.

To move the database files on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, expand your server, expand your storage group, right-click Mailbox Store, and then click Properties.

  3. On the Database tab, under Exchange database, or Exchange streaming database, click Browse, type the path location to a folder where compression is not enabled, and then click OK.

  4. Click OK or Apply to apply your changes, and then click Yes on the warning message.

    After you click Yes, the stores (databases) are dismounted, moved, and remounted. When these procedures are successfully completed, you receive the following informational message:

    The database files have been moved successfully

To move the location of Exchange storage group database files on Exchange Server 2007

  1. Follow the guidance in the core Exchange Server 2007 documentation, "How to Move a Storage Group Path" (http://go.microsoft.com/fwlink/?LinkID=80747).

For more information about .stm and .edb files, see the Microsoft Knowledge Base article 232323, "Native Content Storage in Microsoft Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323).


Exchange database files are being written to a non-NTFS partition
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FSName key for the Exchange database file path. If the Exchange Server Analyzer determines that the value for the FSName key does not equal NTFS File System, an error is displayed.

Microsoft does not support the storage of Exchange data files on non-NTFS volumes. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .chk files

  • .eml files

If you see this error, you must move the database files to a folder on an NTFS drive. Alternatively, if the drive on which the database files are stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS.

To move the Exchange database files on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, expand your server, expand your storage group, right-click Mailbox Store, and then click Properties.

  3. On the Database tab, under Exchange database, or Exchange streaming database, click Browse, type the path location to a folder on an NTFS volume, and then click OK.

  4. Click OK or Apply to apply your changes, or click Cancel if you do not want to apply your changes.

  5. If you clicked OK or Apply, you receive the following warning message:

    Note You are about to perform the following operation(s)

    • change the Exchange database location

    • change the Exchange streaming database location

    To perform the requested operation(s), the store must be dismounted which will make it inaccessible to any users.

    Do you want to continue?

    Note:
    Only the operations that you have chosen are listed in the warning message. The warning message contains a Yes and a No button.

  6. Click Yes if you are ready to proceed, otherwise click No.

  7. If you clicked Yes, the stores (databases) are dismounted, moved, and remounted. When these procedures are successfully completed, you receive the following informational message:

    The database files have been moved successfully

To move the location of an Exchange storage group database files on Exchange Server 2007

  1. Follow the guidance in the core Exchange Server 2007 documentation, "How to Move a Storage Group Path" (http://go.microsoft.com/fwlink/?LinkID=80747)

As an alternative to the above procedure, if the drive on which the files are stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS. For information about using the convert.exe command-line tool to convert a FAT partition to an NTFS partition, see the Microsoft Knowledge Base article 214579, "How to Use Convert.exe to Convert a Partition to the NTFS File System" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579).


Exchange database files are being written to an encrypted folder
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Encrypted key for the folder that contains the Microsoft Exchange Information Store database files. If the Exchange Server Analyzer finds the value for Encrypted set to True, an error is displayed.

On an Exchange 2000 Server or an Exchange Server 2003 computer, the database files are written to the following default location:

<drive> :\Program Files\Exchsrvr\mdbdata

On an Exchange Server 2007 computer, the database files are written to the following default location:

<drive> :\Program Files\Microsoft\Exchange Server\Mailbox\<Storage Group Name>

Microsoft does not support the storage of Exchange data files on an Encrypting File System (EFS) encrypted volume. When you store your Exchange data files on an encrypted volume, the additional overhead significantly affects Exchange performance. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To help secure your Exchange data files, it is recommended that you prevent unauthorized access to the Exchange computer and that you use the S/MIME message format to encrypt message data.

To resolve this error, you must either turn off file encryption on the folder where the database files are being written, or move the database files to a folder where encryption is not enabled.

To turn off file encryption on a given folder

  1. Right-click the folder where you want to turn off file encryption, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Encrypt contents to secure data check box, and then click OK.

To move the database files on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, expand your server, expand your storage group, right-click Mailbox Store, and then click Properties.

  3. On the Database tab, under Exchange database, or Exchange streaming database, click Browse, type the path location to a folder where encryption is not enabled, and then click OK.

  4. Click OK or Apply to apply your changes, and then click Yes on the warning message.

  5. After clicking Yes, the stores (databases) are dismounted, moved, and remounted. When these procedures are successfully completed, you receive the following informational message:

    The database files have been moved successfully

To move the location of Exchange storage group database files on Exchange Server 2007

  1. Follow the guidance in the core Exchange Server 2007 documentation, "How to Move a Storage Group Path" (http://go.microsoft.com/fwlink/?LinkId=80747)

For more information about moving database files, see the Microsoft Knowledge Base article 821915, "How to Move Exchange Databases and Logs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821915).

For more information about Exchange Server data files and EFS, see the Knowledge Base article 834638, "Information about the storage of data files on an encrypted volume in Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638).

For information about how to secure messages in Exchange Server 2003, see the Exchange Server 2003 Message Security Guide" (http://go.microsoft.com/fwlink/?linkid=47574).


Exchange Database Is in a Dirty Shutdown State
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-10-30

The Microsoft® Exchange Server Analyzer Tool has determined that one of your databases was not shut down correctly. Therefore, the database files are still attached to the log files.

A Dirty Shutdown state does not indicate the database is corrupted or damaged. A Dirty Shutdown state indicates only that the database files were not detached from the log stream correctly. Therefore, before you can start the database again, you must first recover the database files.

The next time that the database is mounted, this recovery is run automatically. If automatic recovery fails, you can use the Microsoft Exchange Server Disaster Recovery Analyzer Tool to analyze the reasons for failure. After analysis, the Exchange Server Disaster Recovery Analyzer will provide recommendations for manually recovering the database files.

To correct this error

  • Bring the database to a Clean Shutdown state by replaying required transaction log files into the database. To replay the log files, mount the database. If this fails, use the Exchange Server Disaster Recovery Analyzer Tool to help isolate the reason for the failure.

For more information about the Exchange Server Disaster Recovery Analyzer Tool see Microsoft Knowledge Base article 922247, "Description of the Microsoft Exchange Server Disaster Recovery Analyzer tool for Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=922247).


Exchange database online maintenance schedule is set to Never
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the activationSchedule attribute on the mailbox stores and public stores. If the Exchange Server Analyzer finds that the value for activationSchedule resolves to Never, a warning is displayed.

The activationSchedule attribute represents the setting for the online database maintenance schedule. Online database maintenance in Exchange Server is very important. During this interval, tasks like dumpster cleanup (the deletion of messages that have passed their deleted item retention date), public folder expiry (messages in public folders that are older than a certain date are expired), deleted mailbox cleanup, and online defragmentation (database objects that are no longer being used are detected and removed, thereby making additional database space available) are performed. These processes keep the Exchange Server computer healthy and the performance stable. Online maintenance should be set to run at least four hours a day; failing to do so will cause performance degradation over time.

It is recommended that you configure online database maintenance to run on each database (mailbox store or public folder store) for four hours each day. Stagger the online maintenance intervals with the backup schedules. For example, if backup runs from midnight to 2:00 A.M., run online maintenance from 3:00 A.M. to 7:00 A.M.

This is important because online maintenance will not start if the backup session is still running. If an overlap occurs, backup takes precedence over maintenance. In this case, Exchange checks every 15 minutes to see if backup has completed. After backup completes, maintenance will start.

There are 18 tasks that the store goes through to run maintenance. When a task is started, it finishes the task regardless of the maintenance timing window. However, maintenance will not begin a new task if the timing window has expired. Thus, in some instances, not all tasks are completed in a given maintenance interval. If maintenance is cut short, it will pick up where it left off during the next maintenance cycle.

To enable online database maintenance for Exchange 2000 Server and Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, and then expand the server that you want to work with.

  3. Expand the storage group that you want to work with.

  4. In the list of available data stores in the details pane, right-click the store that you want to work with, and then click Properties.

  5. In the Store Properties dialog box, click the Database tab.

  6. Do one of the following:

    • In the Maintenance interval list, select an interval.

    • Click Customize to access the Schedule dialog box, and then create a custom interval.

  7. Click OK.

To correct this warning for Exchange Server 2007

  1. Open Exchange Management Console

  2. Expand Server Configuration and then select the server that you want to work with.

  3. Expand the storage group that you want to work with.

  4. Right-click the store that you want to work with, and then click Properties.

  5. On the General tab, click the Maintenance schedule drop down and select an interval, or click Customize to create a custom schedule.

For more information about online maintenance database tasks, see the Microsoft Knowledge Base article 159196 "XADM: Tasks Controlled by the IS Maintenance Schedule" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=159196).


The Exchange Information Store service is not configured to run as LocalSystem
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-02-27

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Services Microsoft Windows® Management Instrumentation (WMI) class to determine whether the startup account specified on StartName property of the Microsoft Exchange Information Store service (MSExchangeIS) is using the LocalSystem account. If the Exchange Server Analyzer finds the value for this property on an Exchange 2000 Server, Exchange Server 2003, or Exchange Server 2007 computer to be any account other than LocalSystem (also known as the SYSTEM account), a warning is displayed. This warning is not triggered for Exchange Server 5.5 computers, where the Microsoft Exchange Information Store service is expected and required to run under a user account.

Exchange 2000 Server, Exchange Server 2003 and Exchange Server 2007 must be started under the LocalSystem security context instead of associating a specific user account (and password) to start these services. This assures that password changes or user account deletions will not prevent Exchange from functioning correctly. When an Exchange service that is running as LocalSystem accesses a remote server, Microsoft Windows 2000 Server or Windows Server™ 2003 authenticates it by using the credentials of the computer account.

The password on the computer account is changed every seven days by using the standard change-password mechanism. This helps make the computer account more secure than a typical user account where the password is not only changed less frequently, but is also likely to be less random than a randomly generated computer account password.

Some administrators who have experience with Exchange Server 5.5, where a user account is used for services, change the startup account on Exchange 2000 Server, Exchange Server 2003 and Exchange Server 2007 services from using the default LocalSystem account to a user account.

On Exchange 2000 Server, Exchange Server 2003 and Exchange Server 2007, Microsoft does not support running the Microsoft Exchange Information Store service under any account other than LocalSystem.

To correct this error

  1. Click Start, point to Programs, point to Administrative Tools, and then click Services.

  2. In the list of services, right-click Microsoft Exchange Information Store, and then click Properties.

  3. On the Log on tab, under Log on as, click Local System account, and then click OK.

  4. Right-click Microsoft Exchange Information Store, and then click Restart.

For more information about Exchange services, see the Microsoft Knowledge Base article 239762, "Exchange Services Run Under LocalSystem" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762).


The Exchange Information Store service is not running
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether the value set for the Started key in the Microsoft Exchange Information Store service is set to True or False.

A value of False indicates that the Microsoft Exchange Information Store service is not running on this Exchange Server computer. A value of True indicates that the Microsoft Exchange Information Store service is running.

The Exchange Server Analyzer also examines the Exchange_Server WMI class in the root\MicrosoftExchangeV2 namespace to determine the value for the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is an Exchange Server 2003 or Exchange 2000 Server front-end server.

If the values for both evaluated keys are False on Exchange 2000 Server and Exchange Server 2003 systems, a warning is displayed.

If a value of False is returned for the Win32_Service Started key and the Exchange Server computer is running Exchange Server 2007, a warning is displayed.

If attempts to start the Microsoft Exchange Information Store service fail, it could indicate a more serious problem on this Exchange Server computer. In this case, you should examine the event logs for details about the failure. You should also ensure that you are running the most recent service pack for your version of Exchange Server.

You can obtain the latest service pack for Exchange Server 2003 at "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=25097).

For more information about known causes for the Microsoft Exchange Information Store service failure, see the following Microsoft Knowledge Base articles:

  • 827915, "The Information Store service may stop unexpectedly while converting a message that does not contain the PR_MESSAGE_CLASS property in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827915)

  • 830602, "Exchange Server 2003 Information Store service stops responding" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=830602)

  • 839115, "The Information Store service does not start after you upgrade to Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839115)

  • 330197, "The Information Store service stops unexpectedly when a message with a null Internet message ID is delivered locally" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=330197)

  • 831130, "The Folders pane does not appear or the Information Store service quits unexpectedly when you use OWA to access your mailbox on your Exchange Server 2003 computer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=831130)

  • 823163, "'Setup Cannot Locate a Qualifying Global Catalog Server' Error Message When You Try to Start the Information Store Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823163)

  • 822579, "Event ID 7024 After You Install Exchange Server 2003, and Exchange Information Store Service Does Not Start" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822579)

  • 833841, "The Microsoft Exchange Information Store service unexpectedly stops responding" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833841)

For more information about using Exchange Server 2003 and Exchange 2000 Server front-end servers, see the following Web sites:

  • Using Microsoft Exchange 2000 Front-End Servers (http://go.microsoft.com/fwlink/?linkid=12055)

  • Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Topology (http://go.microsoft.com/fwlink/?linkid=47567)


The Exchange Information Store service is not running on this front-end server
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the values set for the Started key of the Microsoft Exchange Information Store and the Simple Message Transfer Protocol (SMTP) services. A value of False indicates that the service is not running. A value of True indicates that the service is running.

The Exchange Server Analyzer also examines the Exchange_Server WMI class in the root\MicrosoftExchangeV2 namespace to determine the value of the IsFrontEndServer key. A value of False indicates that the Exchange Server computer is not a front-end server. A value of True indicates that the Exchange Server computer is a front-end server.

If the Exchange Server Analyzer finds the value of Started for the SMTP service is true, the value of Started for the Microsoft Exchange Information Store service is False, and the value for IsFrontEndServer to be True, a warning is displayed.

Exchange 2000 Server and Exchange Server 2003 use front-end servers to proxy POP3, IMAP4, and Microsoft Office Outlook® Web Access client requests. Additionally, they can be used as Internet-facing SMTP servers. If this front-end server accepts and routes SMTP messages, supports IMAP clients (which use SMTP for submitting messages), or if this front-end server is running Virus Scan API (VSAPI)-compliant software, the Microsoft Exchange Information Store service must be running. Otherwise, the front-end server will not be able to process SMTP messages, or scan messages using VSAPI.

Unless SMTP or VSAPI-compliant antivirus software is being used on a front-end server, the recommended configuration is to disconnect and delete all public folder stores on the front-end server, stop the Microsoft Exchange Information Store service, and then set the Microsoft Exchange Information Store service to disabled. In addition, the SMTP service should be stopped if it is not being used. On Exchange Server computers that use SMTP or VSAPI-compliant software, the Microsoft Exchange Information Store service must be running to deliver messages and service messaging clients.

To correct this warning

  1. Open the Services MMC snap-in.

  2. Right-click Microsoft Exchange Information Store service, and then click Properties.

  3. On the General tab of the Microsoft Exchange Information Store property page, make sure that the Start-up type is set to Automatic. If it is not, set it to Automatic, click Apply, and then click OK.

  4. Right-click Microsoft Exchange Information Store service, and then click Start.

  5. Close the Services snap-in.

If attempts to start the Microsoft Exchange Information Store service fail, it could indicate a more serious problem on this Exchange Server computer. In this case, you should examine the event logs for details about the failure. You should also ensure that you are running the most recent service pack for your version of Exchange Server. You can obtain the latest service pack for Exchange Server at the Web site, "Microsoft Exchange Server home page" (http://go.microsoft.com/fwlink/?LinkId=21573).

For more information about known causes for Microsoft Exchange Information Store service failure, see the following Microsoft Knowledge Base articles:

  • 827915, "The Information Store service may stop unexpectedly while converting a message that does not contain the PR_MESSAGE_CLASS property in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827915)

  • 830602, "Exchange Server 2003 Information Store service stops responding" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=830602)

  • 839115, "The Information Store service does not start after you upgrade to Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839115)

  • 330197, "The Information Store service stops unexpectedly when a message with a null Internet message ID is delivered locally" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=330197)

  • 831130, "The Folders pane does not appear or the Information Store service quits unexpectedly when you use OWA to access your mailbox on your Exchange Server 2003 computer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=831130)

  • 823163, "'Setup Cannot Locate a Qualifying Global Catalog Server' Error Message When You Try to Start the Information Store Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823163)

  • 822579, "Event ID 7024 After You Install Exchange Server 2003, and Exchange Information Store Service Does Not Start" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822579)

  • 833841, "The Microsoft Exchange Information Store service unexpectedly stops responding" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833841)

For more information about using front-end servers, see the Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Topology Guide (http://go.microsoft.com/fwlink/?linkid=47567).


Exchange Installable File System drive is enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-02-28

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Exchange Installable File System (ExIFS or IFS) drive letter mapping is enabled:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EXIFS\Parameters\DriveLetter

If the Exchange Server Analyzer finds the DriveLetter registry value configured with a drive letter (such as M), an error is displayed.

Exchange 2000 Server introduced a feature named IFS. IFS is a kernel-level driver that surfaces some of the data in the Exchange information stores to the Microsoft Windows® file system. On new Exchange 2000 Server installations and on upgrades to Exchange 2000 Server from Exchange Server 5.5, IFS is automatically installed and a drive letter (by default, drive M) was assigned and mapped to the information store. This was performed using the \\.\BackOfficeStorage\ namespace.

Exchange Server 2003 supports IFS, but has the drive letter mapping disabled by default. The DriveLetter registry value is not present in new installations of Exchange Server 2003, and in an upgrade from Exchange 2000 Server to Exchange Server 2003, the registry value data, and therefore the drive letter mapping, is removed.

As a best practice, it is recommended that you do not enable the IFS drive letter mapping in Exchange Server 2003 and that you remove it in Exchange 2000 Server. There are known problems that can occur if the driver letter mapped to the IFS is accessed or scanned by anti-virus or file system-based applications. As a result, it is recommended that the drive letter mapping be removed if the IFS feature is not being used.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\EXIFS\Parameters

  3. In the right pane, double-click the DriveLetter value.

  4. In the Value data field, delete the listed letter so that the Value data field is blank.

  5. Close the registry editor and restart the Microsoft Exchange System Attendant service and the World Wide Web Publishing service for the change to take effect. When then System Attendant service is restarted, all services that depend on the System Attendant service, including the Microsoft Exchange MTA Stacks and the Microsoft Exchange Information Store services, will also be restarted.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about removing the drive M mapping in Exchange 2000 Server, see the Knowledge Base article 305145, "How to remove the IFS mapping for Drive M in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=305145).

For more information about adding the drive M mapping in Exchange Server 2003, see the Knowledge Base article 821836, "Drive M Mapping to IFS Is Not Present by Default in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821836).


Exchange Server Configuration and Performance
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool has determined that your Exchange server is not configured for optimal performance.

During regular operation, Exchange servers access various files. The location of the files may contribute to a performance bottleneck. Groups of interdependent files, such as transaction log drives, are also called resources.

If the distribution of these resources contributes to a disk bottleneck, the Exchange Server Analyzer may display a warning or error about the location of the resources on the Exchange server. To make sure that specific resources are isolated from other load demands, put the resources on a dedicated storage device. The following list describes of how each resource is used, including recommendations for how you can configure the resource.

  • Transaction log drives The transaction log files maintain the state and integrity of your .edb and .stm files. This means that the log files, in effect, represent the data. There is a transaction log file set for each storage group. Because transaction logs are a critical backup component for the data in the Exchange server database files, the Exchange server must commit all data to the log file before it can finish many of its transactions on data. Any delays in writing to the transaction log drive can severely affect the server's performance. Therefore, it is important that you isolate the transaction log drives so that the drives have their own disk subsystem that is not shared by any other server, application, or resource. For best performance, make sure that each transaction log has a dedicated drive.

  • Location of the TEMP drive When first installed, the operating system sets the temporary file location on the same drive that is used by the operating system. This means that any I/O for the TEMP drive competes with I/O for programs and page file operations that are run from that drive. This competition for I/O affects performance. The TEMP drive is used for mail delivery and for the content conversion of large messages. If the TEMP drive becomes bottlenecked, it will affect mail flow and some client applications. To avoid having the operating system compete for I/O with the TEMP drive, and to reduce the risk of performance issues on the Exchange server, it is recommended that you:

    • Change the global environment setting of TEMP to point to another disk.

    • Move the TEMP drive to its own disk.

  • Location of the .edb and .stm files An Exchange database consists of two files:

    • An .edb file (MAPI content) This file stores all MAPI messages and tables that are used by the Store.exe process to locate all messages and checksums of both the .edb and .stm files and MAPI messages.

    • An .stm file (non-MAPI content) This file contains messages that are transmitted with their native Internet content.

    Because access to either type of these files is generally random, both file types can be included on the same disk volume. However, it is important not to put .edb and .stm files on the same drive as the transaction logs. Also, because it is important to avoid a performance bottleneck on the drives that contain database files, it is recommended that you put these files on dedicated drives according to each storage group.

  • Location of the SMTP Directory The SMTP queue stores SMTP messages until Exchange writes them to a database (the mailbox store or the public folder store) or sends the messages to another server or connector. Generally, SMTP queues experience random, small I/Os. The Exchange Server Analyzer displays a warning if the SMTP directory is on a drive that is shared by any of the following:

    • Any other Exchange data file

    • The TEMP or TMP directories

    • The page file

    • The system drive

    If there is no disk bottleneck to the SMTP directory, you can safely ignore this warning. However, if the traffic to this drive is high, and the drive exhibits a performance bottleneck, consider moving the SMTP directory to its own drive or increase the capacity of the drive that hosts the SMTP directory.

  • Location of the page file The page file serves as an extension of the physical memory. Specifically, the page file is where the system stores unused pages or pages that the system will need later. The page file is always used, even by servers that have an adequate amount of free memory. This constant use is because the operating system tries to store only necessary pages and sufficient free space for operations. For example, a printing tool that is used only at startup may have some of its memory paged to disk and never brought back if it is never used.

    In servers where the physical memory is being used heavily, make sure that all access to the page file is as fast as possible. It is recommended that you create a second page file on a drive that is dedicated to the page file.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about best practices for designing storage architectures, see Best Practices Common to Multiple Architectures (http://go.microsoft.com/fwlink/?LinkId=72988).

  • For more information about disk sizing, latency, and I/O rates, see How to Calculate Your Disk I/O Requirements (http://go.microsoft.com/fwlink/?linkid=69747).


The Exchange Store TCP/IP port has been manually overridden
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-03-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the port value for the Exchange store interface has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

If the Exchange Server Analyzer finds that TCP/IP Port is present and configured, a non-default configuration message is displayed.

The most common reason that this value is configured is to enable MAPI clients to connect to an Exchange server that is on the other side of a firewall. This scenario involves opening multiple ports on a firewall to enable Microsoft Office Outlook® 2003 or Outlook 2007 clients to connect using MAPI to an Exchange server, typically over the Internet. This is a supported configuration. For more information about configuring MAPI clients to connect to Exchange through a firewall, see the Microsoft Knowledge Base article 270836, "Exchange 2000 and Exchange 2003 Static Port Mappings" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836). However, if you are not using this scenario, you should remove the registry key.

The recommended deployment for using Outlook in MAPI Mode to connect to an Exchange server over the Internet is to use the RPC over HTTP features found in Microsoft Windows Server™ 2003, Exchange Server 2003, Outlook 2003, Exchange Server 2007, Outlook 2007 and Microsoft Windows® XP Professional. MAPI Mode was formerly referred to as "Corporate" or "Workgroup" mode.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To remove the TCP/IP port registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the registry value called TCP/IP Port.

  4. Close the registry editor, and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

To deploy RPC over HTTPS

  1. Review "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://go.microsoft.com/fwlink/?linkid=47577).

  2. Review the Knowledge Base article 833401, "How to configure RPC over HTTP on a single server in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401).

  3. Review the Knowledge Base article 827330, "How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330).

  4. Review the Microsoft Support WebCast "Using Microsoft Exchange over the Internet (RPC/HTTP) with Microsoft Office Outlook 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134).


The Exchange Store TCP/IP port is below 5000
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-01-11

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the TCP/IP Port setting for the Exchange store:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

If the Exchange Server Analyzer finds that the value for TCP/IP Port is set to a value below 5000 (decimal), a warning is displayed.

If you must set the TCP/IP Port setting to a static value, it is recommended that you set it to a value that is equal to or greater than 5000. If a value lower than 5000 is set, it may cause the Exchange server to stop listening on that port. The Exchange server will remain in this state until a service is restarted (the service to be restarted depends on the component of Exchange that has been hard coded).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set the TCP/IP port registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Double-click the TCP/IP Port key, and set the Value data field to an integer just above 5000 (decimal).

  4. Close the registry editor.

  5. Restart the Microsoft Exchange Information Store service for this change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about port settings, see the Knowledge Base article 270836, "Exchange Server static port mappings" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836).


Exchange transaction logs are being written to a non-NTFS partition
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-02-27

Error Message

Introduction

The Microsoft Exchange Analyzer Tool queries the Win32_Directory Microsoft Windows Management Instrumentation (WMI) class to determine the value of the FSName key for the Exchange transaction log file path. If the Exchange Server Analyzer determines that the value for the FSName key does not equal NTFS, an error is displayed.

Microsoft does not support the storage of Exchange data files on non-NTFS volumes. The Exchange data files include all of the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

If you encounter this error, you must move the transaction logs to a folder on an NTFS drive. Alternatively, if the drive on which the transaction log directory is stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS.

To move the transaction logs on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, right-click your storage group, and then click Properties.

  3. On the General tab, under Transaction log location, click Browse.

  4. Enter the path to the new location for the log files, and then click OK.

  5. Click OK.

To move the location of an Exchange storage group's transaction log files for Exchange Server 2007

  1. Follow the guidance in the core Exchange Server 2007 documentation, "How to Set or Change the Location of Storage Group Log Files" (http://go.microsoft.com/fwlink/?LinkID=80702).

As an alternative to the above procedure, if the drive on which the files are stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS. For information about using the convert.exe command-line tool to convert a FAT partition to an NTFS partition, see the Microsoft Knowledge Base article 214579, "How to Use Convert.exe to Convert a Partition to the NTFS File System" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=214579).


Exchange transaction logs are written to a compressed folder
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Compressed key for the folder containing the Exchange information store transaction logs. If the value for Compressed is set to True for this folder, an error is displayed.

When a message is delivered to Exchange, it is first written to the transaction logs before it is committed to the store and delivered. On an Exchange 2000 Server or an Exchange Server 2003 computer, the transaction logs are written to the following default location:

<drive> :\Program Files\Exchsrvr\mdbdata

On an Exchange Server 2007 computer, the transaction logs are written to the following default location:

<drive> :\Program Files\Microsoft\Exchange Server\Mailbox\<Storage Group Name>

Microsoft does not support the storage of Exchange data files on an NTFS compressed volume. When you store your Exchange data files on a compressed volume, the additional overhead significantly impacts the performance of Exchange. In addition, after an information store database reaches a certain size (approximately 4 GB), it may fail to mount or it may become corrupt.

The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

Files that are managed by Extensible Storage Engine (ESE) are not designed to be stored on a compressed drive. The ESE depends on sector independence for log-based recovery, and compression of files invalidates sector independence. Compression should not be turned on for volumes hosting ESE databases, or any database that uses write-ahead logging.

Before Exchange 2000 Server Service Pack 3, compressed information store databases were allowed to mount. However, corruption can result in any Exchange 2000 Server information store databases or information store logs that have been compressed by using NTFS compression.

With Exchange 2000 Server Service Pack 3, compressed information store database files of 128 MB or smaller are automatically decompressed. When database files grow to larger than 128 MB, the database does not mount and the error messages are generated in the application log. Exchange 2000 Server Service Pack 3 prevents compressed databases larger than 128 MB from mounting.

To turn off compression for a given folder

  1. Right-click the folder where you want to turn off file compression, and click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Compress contents to save disk space check box, and then click OK.

To move the transaction logs on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, right-click your storage group, and then click Properties.

  3. On the General tab, under Transaction log location, click Browse.

  4. Enter the path to the new location for the log files, and then click OK.

  5. Click OK.

To move the location of an Exchange storage group transaction log files for Exchange Server 2007

  1. Follow the guidance in the core Exchange Server 2007 documentation, "How to Set or Change the Location of Storage Group Log Files" (http://go.microsoft.com/fwlink/?LinkId=80702).

For more information about moving log files on Exchange Server 2003, see the Microsoft Knowledge Base article 821915, "How to Move Exchange Databases and Logs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821915).

For more information about moving log files on Exchange 2000 Server, see the Knowledge Base article 239944, "How to Move the Transaction or System Logs to Another Location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239944).


Exchange transaction logs are written to an encrypted folder
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-02-27

The Microsoft Exchange Analyzer Tool queries the Win32_Directory Microsoft Windows Management Instrumentation (WMI) class to determine the value of the Encrypted key for the folder that contains the information store transaction logs. If the Exchange Analyzer finds the value for Encrypted set to True, an error is displayed.

When a message is delivered to Exchange, it is first written to the transaction logs before it is committed to the store and delivered. On an Exchange 2000 Server or an Exchange Server 2003 computer, the transaction logs are written to the following default location:

<drive> :\Program Files\Exchsrvr\mdbdata

On an Exchange Server 2007 computer, the transaction logs are written to the following default location:

<drive> :\Program Files\Microsoft\Exchange Server\Mailbox\<Storage Group Name>

Microsoft does not support the storage of Exchange data files on an Encrypting File System (EFS) encrypted volume. When you store your Exchange data files on an encrypted volume, the additional overhead significantly affects Exchange Server performance. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To help secure your Exchange data files, it is recommended that you prevent unauthorized access to the Exchange computer and that you use the S/MIME message format to encrypt message data.

To resolve this error, you must either turn off file encryption on the folder where the transaction logs are being written, or move the transaction logs to a folder where encryption is not enabled.

To turn off file encryption on a specified folder

  1. Right-click the folder where you want to turn off file encryption, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Encrypt contents to secure data check box, and then click OK.

To move the transaction logs on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand your administrative group, expand Servers, right-click your storage group, and then click Properties.

  3. On the General tab, under Transaction log location, click Browse.

  4. Enter the path to the new location for the log files, and then click OK.

  5. Click OK.

To move the location of an Exchange storage group's transaction log files for Exchange Server 2007

  1. Follow the guidance in the core Exchange Server 2007 documentation, "How to Set or Change the Location of Storage Group Log Files" (http://go.microsoft.com/fwlink/?LinkID=80702).

For more information about moving log files, see the Microsoft Knowledge Base article 821915, "How to Move Exchange Databases and Logs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821915).

For more information about Exchange Server data files and EFS, see Microsoft Knowledge Base article 834638, "Information about the storage of data files on an encrypted volume in Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638).

For information about how to secure messages in Microsoft Exchange Server 2003, see the Exchange Server 2003 Message Security Guide (http://go.microsoft.com/fwlink/?linkid=47574).


Extended ESE performance counters are enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether the Exchange server includes the Extensible Storage Engine (ESE) extended counters in its library of performance counters:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ESE\Performance\Show Advanced Counters

If the Exchange Server Analyzer finds that the data value of the Show Advanced Counters registry key is 1, the Exchange Server Analyzer displays a non-default configuration message.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To disable the extended ESE performance counters

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Delete the Show Advanced Counters value under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESE\Performance key in the registry.

  3. Close the registry editor.

  4. Restart Performance Monitor to apply the change.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Extended store performance counters are enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether Mdbperfx.dll exists in the Exchange server library of performance counters:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Performance

If the Exchange Server Analyzer finds that the Library value includes the string "mdbperfx.dll," the Exchange Server Analyzer displays a non-default configuration message.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

The DLL Mdbperf.dll contains the default set of store performance counters. The DLL Mdbperfx.dll contains the same default set of store performance counters and also contains the extended set of store performance counters.

By default, the Library value data includes the DLL Mdbperf.dll. By default, the Library value data does not contain the DLL Mdbperfx.dll. The following table lists the extended store performance counters that the DLL Mdbperfx.dll contains.

Counter | Target
FXGetBufferRopsCalled | The total number of FXGetBuffer remote procedure call (RPC) operations
FXGetBufferRopsCalledPerSec | The number of FXGetBuffer RPC operations per second
FXGetBufferRopsAcceptedPerSec | The number of FXGetBuffer RPC operations that are accepted per second
FXGetBufferRopsDenied | The total number of FXGetBuffer RPC operations that are denied
FXGetBufferRopsDeniedPerSec | The number of FXGetBuffer RPC operations that are denied per second
FXGetBufferCurrentCallerCount | The number of simultaneous FXGetBuffer RPC operations
FXGetBufferCurrentUsersExecuting | The number of simultaneous FXGetBuffer RPC operations that are being run
Messages Scanned as MIME | The total number of top-level messages that are processed as MIME by the virus scanner
Messages Scanned as MIME/sec | The rate that top-level messages are processed as MIME by the virus scanner
Messages Scanned as MAPI | The total number of top-level messages that are processed as MAPI by the virus scanner
Messages Scanned as MAPI/sec | The rate that top-level messages are processed as MAPI by the virus scanner
Bytes Read | The total number of bytes that are read by the virus scanner
Bytes Written | The total number of bytes that are written by the virus scanner
Queue Length (Low Priority) | The current number of outstanding low-priority requests that are queued for virus scanning
Threads | The current number of threads in a thread pool that are used for virus scanning. This count does not include the number of threads that are used for background scanning.
Checks Satisfied by MFT Stamp | The number of times that virus scan checks were satisfied by stamp in the Message Folder table
Checks Satisfied by MFT Stamp/sec | The rate that virus scan checks are satisfied by stamp in the Message Folder table
Checks Satisfied by Instance Stamp | The number of times that virus scan checks were satisfied by instance stamp
Checks Satisfied by Instance Stamp/sec | The number of times that virus scan checks were satisfied by master instance stamp
Checks Satisfied by Master Instance Stamp/sec | The rate that virus scan checks are satisfied by master instance stamp
Checks Not Satisfied | The number of times that virus scan checks were not satisfied by any stamp
Checks Not Satisfied/sec | The rate that virus scan checks are not satisfied by any stamp
Checks Blocked | The number of times that processing was blocked waiting for the virus scan to complete
Checks Blocked/sec | The rate that processing is blocked waiting for the virus scan to complete
Check Timeouts | The number of times that operations that are waiting for virus scan to complete were timed out
Check Timeouts/sec | The rate that operations that are waiting for virus scan to complete are timed out
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To enable only the default store performance counters

  1. Start a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Locate the Library value under the following registry key:

    HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\Performance

  3. On the Edit menu, click Modify.

  4. In the Value data box, change the value from c:\Program Files\Exchsrvr\bin\mdbperfx.dll to c:\Program Files\exchsrvr\bin\mdbperf.dll.

  5. Click OK, and close the registry editor.

  6. Restart Performance Monitor to apply the change.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about collecting performance data about the Exchange store, see the Knowledge Base article 821912, "How to Collect Diagnostic Data to Help Troubleshoot Information Store Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821912).


FXGetBuffer Backoff Constant parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether the FXGetBuffer Backoff Constant value has been created:

HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds that the FXGetBuffer Backoff Constant value has been created under the ParametersSystem registry key, the Exchange Server Analyzer displays a non-default configuration message.

You can use the FXGetBuffer Backoff Constant value to control the number of Microsoft Office Outlook® 2003 clients that synchronize with an Exchange Server 2003 server at one time. You set the FXGetBuffer Backoff Constant value to configure the amount of time that an Outlook client waits before the Outlook client attempts to synchronize again. The default value of the FXGetBuffer Backoff Constant value is 500 milliseconds.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required. However, you can delete the FXGetBuffer Backoff Constant registry key if you want to restore the default configuration.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, see the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the FXGetBuffer Backoff Constant value.

  4. Close the registry editor.

The Microsoft Exchange Information Store service detects the changes in minutes. You do not need to restart the computer.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting registry keys to control the number of Outlook clients that can synchronize with Exchange Server 2003, see the Knowledge Base article 818484, "Registry Values and Counters That You Can Use to Configure and Monitor Outlook Client Synchronization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=818484).


FXGetBuffer Retry Count parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether the FXGetBuffer Retry Count value has been created:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds that the FXGetBuffer Retry Count value has been created under the ParametersSystem registry key, the Exchange Server Analyzer displays a non-default configuration message.

You can use the FXGetBuffer Retry Count value to control the number of Microsoft Office Outlook® 2003 clients that synchronize with an Exchange Server 2003 server at one time. You set the FXGetBuffer Retry Count value to configure the number of times that an Outlook client can attempt to synchronize before the client is granted access. The default value is 10.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required. However, you can delete the FXGetBuffer Retry Count registry key if you want to restore the default configuration.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, see the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the FXGetBuffer Retry Count value.

  4. Close the registry editor.

The Microsoft Exchange Information Store service detects the changes in minutes. You do not need to restart the computer.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting registry keys to control the number of Outlook clients that can synchronize with Exchange Server 2003, see the Knowledge Base article 818484, "Registry Values and Counters That You Can Use to Configure and Monitor Outlook Client Synchronization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=818484).


Ignore Bad Oof Rule registry parameter has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the registry of the Exchange Server computer to check for the presence of the Ignore Bad Oof Rule registry entry. This registry value is present at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

If the Exchange Server Analyzer finds the Ignore Bad Oof Rule registry entry present and configured with a value of 1 or greater, a non-default configuration message is displayed.

The Ignore Bad Oof Rule registry entry is a configuration setting for Exchange 2000 Server Exchange Server 2003, and Exchange Server 2007 designed specifically to work with the hotfix described in the Microsoft Knowledge Base article 828875, "You cannot move an Exchange mailbox after you use the Exmerge.exe utility" (http://go.microsoft.com/fwlink/?LinkID=3052&kbid=828875).

When the Microsoft Exchange Mailbox Merge program (Exmerge.exe) is used to move messages and other items from a mailbox on one mailbox store to a mailbox on a different mailbox store, a subsequent attempt to move the second mailbox may fail. This can occur because of a bad out-of-office (OOF) rule on that mailbox. If you want, you can revert to the default configuration by using the procedure outlined here.

Important:
This article contains information about how to edit the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

  3. In the right pane, locate and delete the Ignore Bad Oof Rule value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Ignore Zombie Users registry parameter has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool checks the registry of the Exchange Server computer for the presence of the Ignore Zombie users registry entry. This registry value is present at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds the Ignore Zombie users registry entry present and configured with a value of 1 or greater, a non-default configuration message is displayed.

In a mixed-mode Exchange Server organization that contains Exchange Server 5.5 and Exchange 2000 Server or in an environment that was previously mixed, problems may occur if the following conditions exist:

  • You upgrade the access control list (ACL) of mailboxes and public folders from Exchange Server 5.5 to Exchange 2000 Server.

  • The ACL contains user accounts that are not represented in the Active Directory® directory service.

These unused access control entries (ACEs) are also known as zombie users. As of the March 2003, post-Service Pack 3 Roll-up for Exchange 2000 Server, the default behavior for processing zombie users has changed. You can control this behavior by using the Ignore Zombie users registry key.

The Ignore Zombie users registry value can be used on servers that have Exchange 2000 Server Service Pack 3 or later installed. You should use this registry entry carefully and only when you are sure that the zombie users are not a result of Active Directory Connector (ADC) replication issues, such as latency. This registry value causes Exchange Server to ignore the zombie users and remove them from the ACL of the mailboxes or public folders. If the user is valid but is not in Active Directory at the time that the ACL was upgraded, the user is removed, and you have to manually add the user to each ACL later.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, locate and delete the Ignore Zombie users value.

  4. Close the registry editor, and then restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about using the Ignore Zombie Users registry key, see the following Knowledge Base articles:

  • 812963, "Using the Ignore Zombie Users Registry Key" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812963)

  • 324323, "XADM: Skipping User Accounts That Are Not Represented in Active Directory During Access Control List Conversion" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324323)


IMAIL exception handling has been manually disabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool examines the following registry entry to determine the setting for the ExceptionHandling registry value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

If the Exchange Server Analyzer finds the ExceptionHandling registry value configured with a value of 0, a warning is displayed.

In Exchange Server, IMAIL exception handling is turned on by default, and it cannot be turned off through the user interface. However, IMAIL exception handling can be turned off by using the registry.

Microsoft recommends that IMAIL exception handling remain enabled unless you are actively troubleshooting a problem. For example, you might turn off IMAIL exception handling if you have custom applications that trigger events based on bad Multipurpose Internet Mail Extensions (MIME) or MAPI content. Microsoft recommends that IMAIL exception handling be turned off only on the advice and direction of Microsoft Product Support Services support professionals.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent.

  3. Double-click ExceptionHandling:

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the ExceptionHandling registry value, see the Knowledge Base article 832174, "There is no option to turn off IMAIL exception handling in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832174).


Information Store service is configured to interact with desktop
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the DesktopInteract property for the Microsoft Exchange Information Store (MSExchangeIS) service. If the Exchange Server Analyzer finds that the Microsoft Exchange Information Store service is configured to interact with the desktop, the Exchange Server Analyzer displays an error.

This configuration should only be used under the guidance of Microsoft Product Support Services. Unless Microsoft Product Support Services has instructed you to run the Microsoft Exchange Information Store service in this configuration, it is recommended that you reconfigure the Microsoft Exchange Information Store service properties so that it does not interact with the desktop.

To configure the Exchange Information Store service account

  1. Open the Services MMC snap-in.

  2. Locate and stop the Microsoft Exchange Information Store service.

  3. Double-click Microsoft Exchange Information Store service.

  4. On the Log On tab of the Microsoft Exchange Information Store Properties page, select Local System account under Log on as.

  5. Clear the Allow service to interact with desktop check box, and then click Apply.

  6. Under Service status, click Start, and then click OK.

  7. Close the Services snap-in.

For more information about the correct Exchange service configuration, see the Microsoft Knowledge Base article 239762, "Exchange Services Run Under LocalSystem" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762).


Increase maximum database size for mailbox store
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the CIM_DataFile Microsoft Windows® Management Instrumentation (WMI) class to determine the following information:

  • The full path for the Exchange database files.

  • The current size of the mailbox store.

The Exchange Server Analyzer also queries the Win32_OperatingSystem WMI class to determine additional information:

  • The version of the Windows operating system that is running on the Exchange server.

  • The version of Exchange Server that is installed.

  • The edition of Exchange Server that is installed.

  • The service pack level version for Exchange Server.

Finally, the Exchange Server Analyzer also reads the following registry entry to determine whether the Database Size in Gb value has been set:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

The Exchange Server Best Practices Analyzer displays an error if the following conditions are true:

  • The server is running Exchange Server 2003.

  • The service has Service Pack 2 for Exchange Server 2003 installed.

  • The Exchange Server database size is larger than 16 gigabytes (GB).

  • The Database Size in Gb registry value has not been set.

This error indicates that the identified Exchange database is close to its size limit. Service Pack 2 for Exchange Server 2003 raises the database storage limits from 16 GB to 75 GB. However, to use the new limits you must manually add the Database Size in Gb registry value on the Exchange Server.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this error by adding the Database Size in Gb registry value

  1. On the computer that is running Exchange Server, open a registry editor such as Regedit.exe or RegEdt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Right-click MailboxStoreGUID, point to New, and then click DWORD Value.

  4. For the new value name, type Database Size Limit in Gb.

  5. Double-click Database Size Limit in Gb. In Value data, type an appropriate value for maximum database size in GB. Click OK.

  6. Right-click MailboxStoreGUID, point to New, and then click DWORD Value.

  7. For the new value name, type Database Size Buffer in Percentage.

  8. Double-click Database Size Buffer in Percentage. In Value data, type a value between 1 and 100 to specify when you want events to be logged to warn you that you are nearing the maximum size for a database. Click OK.

    Note:
    The default value of 10 will cause warning events to be logged when you have 10 percent capacity left before you reach the maximum size for that database.

  9. Right-click MailboxStoreGUID, point to New, and then click DWORD Value.

  10. For the new name, type Database Size Check Start Time in Hours From Midnight.

  11. Double-click Database Size Check Start Time in Hours From Midnight. In Value data, type a value between 0 and 23 to specify when you want Exchange to look at the database size. Click OK.

    Note:
    The default value of 5 causes Exchange Server to look at the database size at 5 hours after midnight (05:00).

  12. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about how to configure and manage Exchange Server database size limits, see "Database Size Limit Configuration and Management" (http://go.microsoft.com/fwlink/?LinkId=57029).

For information about maximum database size for Exchange Server 2003 Standard Edition and Exchange 2000 Server Standard Edition, see the Knowledge Base article 828070, "Exchange Server Mailbox Store does not mount when the Mailbox Store database reaches the 16-GB limit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site, "Why Try Service Pack 2 for Exchange Server 2003?" (http://go.microsoft.com/fwlink/?LinkId=52073).


Increase maximum database size for public folder store
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the CIM_DataFile Microsoft Windows® Management Instrumentation (WMI) class to determine the following information:

  • The full path for the Exchange Server database files.

  • The current size of the public folder store.

The Exchange Server Analyzer also queries the Win32_OperatingSystem WMI class to determine additional information:

  • The version of the Windows operating system that is running on the Exchange server.

  • The version of Exchange Server that is installed.

  • The edition of Exchange Server that is installed.

  • The service pack level version for Exchange Server.

Finally, the Exchange Server Analyzer also reads the following registry entry to determine whether the Database Size in Gb value has been set:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicStoreGUID>

The Exchange Server Best Practices Analyzer displays an error if the following conditions are true:

  • The server is running Exchange Server 2003.

  • The service has Service Pack 2 for Exchange Server 2003 installed.

  • The Exchange database size is larger than 16 gigabytes (GB).

  • The Database Size in Gb registry value has not been set.

This error indicates that the identified Exchange Server database is close to its size limit. Service Pack 2 for Exchange Server 2003 raises the database storage limits from 16 GB to 75 GB. However, to use the new limits you must manually add the Database Size in Gb registry value on the Exchange Server.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this error by adding the Database Size in Gb registry value

  1. On the computer that is running Exchange Server, open a registry editor such as Regedit.exe or RegEdt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicStoreGUID>

  3. Right-click PublicStoreGUID, point to New, and then click DWORD Value.

  4. For the new value name, type Database Size Limit in Gb.

  5. Double-click Database Size Limit in Gb. In Value data, type an appropriate value for maximum database size in GB. Click OK.

  6. Right-click PublicStoreGUID, point to New, and then click DWORD Value.

  7. For the new value name, type Database Size Buffer in Percentage.

  8. Double-click Database Size Buffer in Percentage. In Value data, type a value between 1 and 100 to specify when you want events to be logged to warn you that you are nearing the maximum size for a database. Click OK.

    Note:
    The default value of 10 will cause warning events to be logged when you have 10 percent capacity left before you reach the maximum size for that database.

  9. Right-click PublicStoreGUID, point to New, and then click DWORD Value.

  10. For the new name, type Database Size Check Start Time in Hours From Midnight.

  11. Double-click Database Size Check Start Time in Hours From Midnight. In Value data, type a value between 0 and 23 to specify when you want Exchange to look at the database size. Click OK.

    Note:
    The default value of 5 causes Exchange Server to look at the database size at 5 hours after midnight (05:00).

  12. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about how to configure and manage Exchange database size limits, see "Database Size Limit Configuration and Management" (http://go.microsoft.com/fwlink/?LinkId=57029).

For information about maximum database size for Exchange Server 2003 Standard Edition and Exchange 2000 Server Standard Edition, see the Knowledge Base article 828070, "Exchange Server Mailbox Store does not mount when the Mailbox Store database reaches the 16-GB limit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site, "Why Try Service Pack 2 for Exchange Server 2003?" (http://go.microsoft.com/fwlink/?LinkId=52073).


Increase Transaction Log Log Buffers Setting
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that the number of log buffers on your server is too low. The tool has detected that the Database (Information Store Instance)\Log Record Stalls/sec value for your server is greater than 10 stalls per second. A value greater than 10 indicates that there is a backup writing to the transaction log. This situation can occur because the transaction log drive is beyond its throughput capacity, or because the log buffers are set too low.

Log write I/O's are sequential and single threaded, so the latency on log I/O is often a bottleneck to the system. Log I/O's are written to the log buffers first, and then the buffer is cleared by either a non-lazy commit or a capacity commit. A non-lazy commit means that the log buffer is written to the disk immediately. A capacity commit means that the log buffer is written to the disk when the buffer becomes full.

Increasing the log buffer size reduces the frequency of capacity flushes, increases the log write size, and subsequently reduces the overall log write latency. Reducing the log I/O write latency is a significant way to improve the performance/scalability of the Exchange deployment.

The general recommendation is to increase the buffer size to the maximum of 9,000 for Exchange Server 2003 and to 512 for Exchange 2000 Server.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this warning

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=ExchangeOrganizationName.

  3. Expand CN=Administrative Groups, expand CN=AdministrativeGroupName, and then expand CN=Servers.

  4. Expand CN=ExchangeServerName, expand CN=InformationStore, right-click CN=Storage Group Name, and then click Properties.

  5. In the Select a property to view box, click msExchESEParamLogBuffers.

  6. In the Edit Attribute box, type the appropriate value for your version of Exchange for msExchESEParamLogBuffers, and then click Set.

    Note:
    For computers that are running Exchange 2000 Server, Exchange 2000 Server Service Pack 1 (SP1), Exchange 2000 Server SP2, or Exchange 2000 SP3, set the value to 512. For computers that are running the original release version of Exchange Server 2003 or Exchange Server 2003 SP1, set the value to 9,000.

  7. Click Apply, and then click OK.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about working with log buffering, see Microsoft Knowledge Base article "ESE log buffers that are set too low can cause the Microsoft Exchange Information Store service to stop responding" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328466).


Initial memory percentage has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Initial Memory Percentage value has been set:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds the value for Initial Memory Percentage present and configured with any value more than 0, a non-default configuration message is displayed.

The Initial Memory Percentage registry setting was introduced as a mechanism for fine tuning the initial amount of memory allocated to the Exchange information store to 10 percent of the total physical memory in the Exchange server. By starting out with this initial allocation and then growing from there, virtual memory fragmentation does not occur as frequently. This registry value should not be set arbitrarily, and should only be used on the advice and direction of Microsoft Product Support Services.

Versions of Exchange Server at Exchange Server 2003 or later include support for special startup switches in Microsoft Windows® 2000 Advanced Server and Windows Server™ 2003 that help reduce virtual memory fragmentation, and additional changes were made to help prevent virtual memory fragmentation in Exchange Server clusters. Therefore, the Initial Memory Percentage registry value is no longer needed on versions of Exchange Server at Exchange Server 2003 or later.

The Initial Memory Percentage registry value works only on computers that are running Exchange 2000 Server. Exchange Server 2003 and Exchange Server 2007 will ignore this value if present, and the value will have no effect. Therefore, you should remove this registry entry before upgrading this Exchange server from Exchange 2000 Server to Exchange Server 2003.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To remove the Initial Memory Percentage registry setting

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, delete the Initial Memory Percentage value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.
  • For more information about a known issue when you use this registry value, see the Microsoft Knowledge Base article 810883, "'Initial Memory Percentage' Registry Value Has No Effect" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810883).

  • Before you edit the registry, and for information about how to edit the registry, see the Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).


Initial Reserve Size KB registry entry has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-04-27

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the Initial Reserve Size KB registry entry is present:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSexchangeIS\ParametersSystem

If the Exchange Server Analyzer finds the Initial Reserve Size KB registry value present and configured with a value greater than 0, a non-default configuration message is displayed.

The Initial Reserve Size KB registry value is used to set aside additional memory for heap space. The value specified is in kilobytes. The default value on most Exchange servers is 655360 kilobytes (KB), which equals 640 megabytes (MB). You can reduce this value to increase the amount of available free memory and reduce virtual memory fragmentation. This value should only be set on the advice and direction of Microsoft Product Support Services support professionals. This message is an informational message and no corrective action needs to be taken if this registry value was added on the advice of Microsoft Product Support Services support professionals.

If you believe this entry was incorrectly set, you can remove it and revert to the default configuration.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration settings

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSexchangeIS\ParametersSystem

  3. Delete the value called Initial Reserve Size KB.

  4. Close the registry editor, and then restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

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


The legacyExchangeDN for this Exchange database does not correspond to the Exchange server
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the legacyExchangeDN attribute for all mailbox store databases on an Exchange Server computer. If the Exchange Server Analyzer finds that the value for the legacyExchangeDN attribute on any mailbox store does not correspond with the Exchange Server computer that contains the mailbox store, an error is displayed.

A mismatched legacyExchangeDN could be the result of an administrator modifying Active Directory to recover a database in a disaster recovery situation. To resolve this error, you must modify the legacyExchangeDN attribute using an Active Directory editor, such as the LDP (ldp.exe) tool or Active Directory Service Interfaces (ADSI) Edit.

To ensure that the legacyExchangeDN attribute is correct, examine the legacyExchangeDN attribute of the server where this database resides because, being a child object of that server, this database will have the same legacyExchangeDN.

You should also examine other databases on this Exchange server that did not generate this error, because they should have the same legacyExchangeDN. Be aware that there are several other system objects that also have this attribute. In a situation where the legacyExchangeDN attribute is mismatched on a database, it is probable that the attribute is also mismatched on several other system objects. Therefore, if you use LDP or ADSI Edit to correct a legacyExchangeDN value, you will have to do this on all the other system objects as well.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Expand Configuration [DomainName], and then expand, CN=Configuration,DC=DomainName,DC=DomainSuffix.

  3. Expand CN=Services, and then expand CN=Microsoft Exchange.

  4. Expand CN=OrganizationName, expand CN=Administrative Groups, and then expand CN=AdminGroupName.

  5. Expand CN=Servers, expand CN=ServerName, and then expand CN=InformationStore.

  6. Select CN=StorageGroupName, and in the right-hand pane, right-click the mailbox store whose legacyExchangeDN attribute is mismatched and click Properties.

  7. Scroll down to legacyExchangeDN, select it, and click Edit.

  8. In the Value field, enter the correct legacyExchangeDN.

  9. Close the Active Directory editor and restart the Exchange Server computer for the change to take effect.

For more information about using ADSI Edit to create a new legacyExchangeDN attribute, see the Microsoft Knowledge Base article 273863, "How to Change the LegacyExchangeDN Attribute in Native Mode with ADSI Edit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=273863).


The legacyExchangeDN value is missing from this Exchange database
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the legacyExchangeDN attribute for all mailbox store databases on an Exchange Server computer. If the Exchange Server Analyzer does not find a value for the legacyExchangeDN attribute on any mailbox store, an error is displayed.

A missing legacyExchangeDN could be the result of an administrator modifying Active Directory to recover a database in a disaster recovery situation. To resolve this error, you must modify the legacyExchangeDN attribute using an Active Directory editor, such as the LDP (ldp.exe) tool or Active Directory Service Interfaces (ADSI) Edit.

To ensure that the legacyExchangeDN attribute is correct, examine the legacyExchangeDN attribute of the server where this database resides because, being a child object of that server, this database will have the same legacyExchangeDN.

You should also examine other databases on this Exchange server that did not generate this error, because they should have the same legacyExchangeDN. Know that there are several other system objects that also have this attribute. In a situation where the legacyExchangeDN attribute is missing on a database, it is probable that the attribute is also missing on several other system objects. Therefore, if you use LDP or ADSI Edit to add a new legacyExchangeDN value, you will have to do this on all the other system objects also.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Expand Configuration [DomainName], expand, CN=Configuration,DC=DomainName,DC=DomainSuffix.

  3. Expand CN=Services, and then expand CN=Microsoft Exchange.

  4. Expand CN=OrganizationName, expand CN=Administrative Groups, and then expand CN=AdminGroupName.

  5. Expand CN=Servers, expand CN=ServerName, and then expand CN=InformationStore.

  6. Select CN=StorageGroupName, and in the right pane, right-click the mailbox store whose legacyExchangeDN attribute is missing and click Properties.

  7. Scroll down to locate legacyExchangeDN, select it, and click Edit.

  8. In the Value field, enter the correct legacyExchangeDN.

  9. Close the Active Directory editor and restart the Exchange Server computer for the change to take effect.

For more information about using ADSI Edit to create a new legacyExchangeDN attribute, see the Microsoft Knowledge Base article 273863, "How to Change the LegacyExchangeDN Attribute in Native Mode with ADSI Edit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=273863).


LimitBodyParts parameter has been manually set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the default limit for attachments in a message has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent\LimitBodyParts

If the Exchange Server Analyzer finds the LimitBodyParts registry entry present and configured, a non-default configuration message is displayed.

By design and for security reasons, Exchange Server limits the number of attachments (referred to as body parts) to 250. If a message contains more than 250 attachments, a MAPI_E_TOO_BIG error is generated. In addition, the Microsoft Exchange Information Store service may consume excessive memory and CPU resources while processing messages with a large number of attachments.

A configuration opportunity exists that allows administrators to add the LimitBodyParts registry value and configure it to use a value higher than 250. In the absence of this entry, the default value of 250 is used.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To view or change the LimitBodyParts registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

  3. Examine and, if desired, change the LimitBodyParts value. An acceptable value for this registry value is any whole number between 250 and 4294967295.

  4. If a change is made, restart the Exchange Server computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


LimitEmbeddingDepth parameter has been manually set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-30

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the default MIME header limits in Exchange have been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

If the Exchange Server Analyzer finds that any value for LimitEmbeddingDepth has been set, a non-default configuration message is displayed.

Exchange 2000 Server Service Pack 3, Exchange Server 2003 and Exchange Server 2007 include updated functionality in the information store process (store.exe) that defines how large or irregularly formed MIME is handled. This functionality was added to further secure Exchange Server against denial of service attacks by both malicious and unintentionally large and complex MIME messages. Some examples of the limits imposed on MIME messages submitted to the store include limiting the number of recipients, limiting the number of embedded messages, and limiting the size of the individual MIME headers.

The default values for these various MIME header limits are set within the store process. However, if a registry key has been set to define any one of these limits, the registry key will override the default store.exe value. When any one of the various limits is exceeded in a MIME message, a non-delivery report (NDR) is sent to the sender.

Limiting the embedding depth of MIME refers to the number of MIME messages that can be embedded into each other. For example, assume that you receive a message (m1) with an attached message (m2). When you open the attached message (m2), you find that there is a message (m3) attached to that message (m2) as well. Thus, the original message (m1) has messages embedded to a depth of 3 levels. By default, Exchange will allow messages with an embedded depth level of 100. Messages with embedded messages exceeding 100 levels of depth may consume all memory on an Exchange server for the time it takes the server to "un-wrap" the message, parse it, and convert it to MAPI. It is highly unlikely that any e-mail client or server will generate a message with such depth of embedded messages. Rather, such a message is more likely the result of malicious users attempting a denial of service attack on your messaging system.

To revert to the default configuration

  • There is no action that needs to be taken. This registry entry will be present only when the hotfix from the Microsoft Knowledge Base article 833607, "The Microsoft Exchange Information Store service uses 100 percent of the CPU resources on an Exchange 2000 Server or an Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=833607), has been installed. This hotfix creates the LimitEmbeddingDepth registry entry and sets it to a value of 10.

For more information about Exchange Server service packs and hotfixes, see the Knowledge Base article 328839, "How to apply Exchange service packs and hotfixes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839).


LimitNestingLevels parameter has been manually set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the default Multipurpose Internet Mail Extensions (MIME) header limits in Exchange have been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

If the Exchange Server Analyzer finds that any value for LimitNestingLevels has been set, a non-default configuration message is displayed.

MIME bodyparts within a message item can be nested. If the nesting level is high, the conversion process requires more and more resources to decode the entire message. A single message with a MIME bodypart nested to 700 levels can take up to 10 minutes to process. When you receive messages from the Internet with nested MIME bodyparts, the conversion process for the MIME bodyparts may cause the slow delivery of these messages. As the messages are delivered, the server will require a large amount of system resources, especially memory. If a large number of these messages are received at the same time, the system may report it is running low on virtual memory.

Limiting the nesting levels of MIME refers to the number of MIME content types (such as multipart/mixed, or multipart/alternative) that can be nested within each other. Messages that are generated by most e-mail clients (including Microsoft Outlook® and Outlook Express) and e-mail servers contain very few nested MIME content types. For example, a typical message (even with multiple replies) will only be represented in a MIME message as a single content-type. Multiple nesting levels are usually the result of an automated process that builds MIME messages for specific uses (such as a workflow application), or of a malicious message constructed with the specific purpose of consuming resources on the mail server.

In addition to enforcing nesting levels according to content-type, Exchange Server will use the LimitNestingLevels value (whether defined as a registry value or as a default value in the store process) to enforce a limit on embedded messages. If the LimitNestingLevels registry value is not defined, the default value of 30 nesting levels is enforced. The embedded messages limit is defined by multiplying the LimitNestingLevels value by 16. Therefore, the default value for the number of embedded messages is 480. For example, if LimitNestingLevels is configured with a value of 5, a maximum of 80 attachments are accepted.

To revert to the default configuration

  • There is no action that needs to be taken. The Exchange Server Analyzer is displaying the non-default configuration for your information.

For more information about an Exchange 2000 Server hotfix related to the LimitNestingLevels registry value, see the Microsoft Knowledge Base article 289775, "XADM: Exchange 2000 Server Experiences Memory Leaks Because of Many Embedded Messages" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=289775).


LimitRecipients parameter has been manually set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the default MIME header limits in Exchange have been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

If the Exchange Server Analyzer finds that any value for LimitRecipients has been set, a non-default configuration alert is displayed.

Exchange 2000 Server Service Pack 2 (SP2), and later versions of Exchange Server include updated functionality in the store process (store.exe) that defines how large or irregularly formed MIME is handled. This functionality was added to further secure Exchange as a target against denial of service attacks by both malicious and exceptional (unintentionally large and complex) MIME messages. Some examples of the limits imposed on MIME messages submitted to the store include limiting the number of recipients, limiting the number of embedded messages, and limiting the size of the individual MIME headers. In previous versions of Exchange, where unbounded MIME headers are allowed to enter the Exchange store for processing, excessively large or complex MIME messages may consume nearly all resources (mainly CPU) as a result of parsing, indexing, and processing the MIME.

The default values for these various MIME header limits are set within the store process. However, if a registry key has been set to define any one of these limits, the registry key will override the default store.exe value. When any one of the various limits is exceeded in a MIME message, a non-delivery report (NDR) is sent to the sender.

If the LimitRecipients registry key has been set, it is likely the result of advice from Microsoft Product Support Services, as this key has not been published. As such, Microsoft does not recommend changing this setting.

The default value for LimitRecipients (if no registry key exists) in the store process is 65,535 recipients per MIME message.


Log buffers are not optimized for servers with replicated disk storage that are running Exchange Server 2003
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine if the following conditions are true:

  • The computer is running Exchange Server 2003.

  • The value of msExchESEParamLogBuffers is between 0 and 8,960.

The Exchange Server Analyzer queries the Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft Windows® Management Instrumentation (WMI) class to determine if the following condition is true:

  • The value for VMLargestBlockSize is greater than 150,000,000.

The Exchange Server Analyzer determines if either of the following services are running:

  • GeoSpanService

  • SRDFService

If all of the conditions above are true, an error is displayed.

The Extensible Storage Engine (ESE) uses log buffers to hold transactions in memory before committing them to the transaction logs. If there are not sufficient log buffers you may encounter excessive disk I/Os on the transaction log drive which will decrease performance.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To correct this error

  1. In Active Directory Service Interfaces (ADSI) Edit, double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=ExchangeOrganizationName.

  2. Expand CN=Administrative Groups, expand CN=AdministrativeGroupName, and then expand CN=Servers.

  3. Expand CN=ExchangeServerName, expand CN=InformationStore, right-click CN=Storage Group Name, and then click Properties.

  4. In the Select a property to view box, click msExchESEParamLogBuffers.

  5. In the Edit Attribute box, type 9000 for msExchESEParamLogBuffers, and then click Set.

  6. Click Apply, and then click OK.

  7. For the change to go into effect, you must restart the Microsoft Exchange Information Store service.

For more information, see Microsoft Knowledge Base article 328466, "ESE log buffers that are set too low can cause the Microsoft Exchange Information Store service to stop responding" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328466).


Log buffers may not be sufficient for servers with large numbers of mailboxes that are running Exchange Server 2003
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-03-27

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the following conditions are true:

  • The computer is running Exchange Server 2003.

  • The value of msExchESEParamLogBuffers is between 0 and 8,960.

  • The number of mailboxes in the storage group is more than 500.

The Exchange Server Analyzer queries the Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft Windows® Management Instrumentation (WMI) class to determine whether the following condition is true:

  • The value for VMLargestBlockSize is more than 150 million.

If all these conditions are true a warning is displayed.

Extensible Storage Engine (ESE) uses log buffers to hold transactions in memory before committing them to the transaction logs. If there are not sufficient log buffers, you may see excessive disk I/Os on the transaction log drive which will decrease performance.

To correct this warning

  1. In Active Directory Service Interfaces (ADSI) Edit, double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=ExchangeOrganizationName.

  2. Expand CN=Administrative Groups, expand CN=AdministrativeGroupName, and then expand CN=Servers.

  3. Expand CN=ExchangeServerName, expand CN=InformationStore, right-click CN=Storage Group Name, and then click Properties.

  4. In the Select a property to view box, click msExchESEParamLogBuffers.

  5. In the Edit Attribute box, type 9000 for msExchESEParamLogBuffers, and then click Set.

  6. Click Apply, and then click OK.

  7. For the change to go into effect you must restart the Microsoft Exchange Information Store service.
Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

For more information, see Microsoft Knowledge Base article 328466, "ESE log buffers that are set too low can cause the Microsoft Exchange Information Store service to stop responding" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328466).


Log files stored on network drive
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchESEParamLogFilePath attribute of each storage group object. This attribute specifies the location of the transaction log files used by databases in the storage group.

The Exchange Server Analyzer also queries Active Directory to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer finds that the msExchESEParamLogFilePath attribute starts with \\ on an Exchange Server with more than 50 mailboxes, an error is displayed.

This error indicates that the transaction log files for a storage group are being stored on a network share. If the msExchESEParamLogFilePath attribute starts with \\, it indicates that the log file path uses a Universal Naming Convention (UNC) path. This is not a recommended practice because interruptions in network connectivity could cause transaction log and database errors, resulting in lost data or corrupt databases. It is recommended that you correct this problem as soon as possible.

To correct this error

  • Move the transaction logs from the network share to a local disk. For optimum performance, place all transaction logs on separate drives.

For information about how to move the transaction logs to another location, see the Microsoft Knowledge Base article 239944, "XADM: How to Move the Transaction or System Logs to Another Location" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=239944).


Log Generation Discrepancy
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that you have a log file generation discrepancy. This error indicates that a transaction log file has been renamed with an inappropriate sequence number.

Exchange transaction log files are named according to the following format: EnnXXXXX.log

  • XXXXX = A five digit hexadecimal sequence number. When a new set of transaction log files is generated, the first log in the sequence will be 000001, and the next log will be 00002, and so on. Because each transaction log records its own sequence number in its header, you can determine whether the log filename has been changed.

  • Enn = The log prefix, which is a three character sequence shared by every transaction log for this storage group. Typically, the prefix will be E00, E01, E02, E03 or R00 (for a recovery storage group).

The current log being written to is named only with the log prefix. This log does not acquire a sequence number until it has been closed and a new current log is generated. Therefore, the current log file may be named E00.log. When this log file is full, it may be renamed E0012345.log. A new E00.log would be generated with an internal sequence number of 12346.

To correct this error

  • Rename the log file to the appropriate sequence number.
To view the internal sequence number

  • Run the following command:

    C:\Program Files\Exchsrvr\Bin\Eseutil.exe /ML [log filename]

    The lGeneration value in the output of this command lists the actual sequence number of the log file.


Log Pairs Are Inconsistent
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that some of your required log files are inconsistent. This error indicates that log files may have been tampered with, manually moved, copied, renamed, or deleted.

To correct this error

  • For advanced analysis of the log files, contact Microsoft Help and Support (http://go.microsoft.com/fwlink/?LinkId=31845).


Log Signature Discrepancy
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that the log signature in one or more of your log files does not match other log files in the same folder.

This problem does not occur unless log files have been manually moved, deleted or disarranged.

Note:
This is an advanced recovery scenario, and you may want to contact Microsoft Help and Support (http://go.microsoft.com/fwlink/?LinkId=31845) before implementation.

Each Exchange transaction log file is stamped with a signature called a Log Signature. This signature identifies individual log files that belong to the same series of logs. Each Exchange database records the Log Signature of the transaction log series to which the database was last attached.

Exchange databases also have a signature called a DB Signature. The DB Signature is generated when a database is first created. If you use Eseutil to defragment or repair a database, this signature will change because the repair and defragmentation processes make changes to the database files without logging those changes to the transaction logs. For logging purposes, the database that results from a repair or defragmentation operation is a new or different database.

Unlike DB Signatures, Log Signatures never change during the lifetime of a series of log files.

Log files record the DB Signatures of all databases attached as the log is created. Databases record the Log Signature of the most recent log series to which the database has been attached. Therefore, DB and Log Signatures are useful to match databases with transaction log files.

You can detach an Exchange database from one set of logs and attach it to another. You can do this by moving the database to a different storage group or by removing all the transaction logs for a storage group and starting a new series of logs.

If a database is in a Dirty Shutdown state, only transaction log files that have signatures matching the Log Signature in the database header can be replayed into the database successfully. In a Dirty Shutdown state, a database is still attached to a particular log stream and can only perform recovery with that log stream.

If a database is in a Clean Shutdown state, you may be able to play transaction log files that do not have signatures matching the current Log Signature in the database header. This will succeed only in the following circumstance:

  1. The database was shut down correctly at the end of a previous sequence of log files.

  2. The database was then attached to a new sequence of transaction log files and you have access to the transaction log in which the database was first attached to the new set of logs.

To correct this error

  • You must know the history of the database and under what circumstances the transaction logs were generated with regard to the database.

  • In this situation, before you attempt recovery, always make a copy of both the transaction logs and the database files. A mistaken recovery attempt may change transaction log or database files in such a way that another recovery attempt may be unachievable.

  • Replay only one set of transaction logs at a time with the database. Move other transaction logs out of the recovery folder.

  • If the database is in Dirty Shutdown state, you must first successfully replay the transaction logs to which the database is attached and bring the database to a Clean Shutdown state. Then you may be able to play the second set of log files with the database.

  • If the database is in a Clean Shutdown state, you cannot examine the logs or the database to conclusively verify which set of transaction logs is the right one to replay first.


Logon has been restricted to certain users
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry on the Exchange Server computer to determine if the list of users who are allowed to log on to the Exchange information store has been limited:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Logon Only As

If the Exchange Server Analyzer finds the Logon Only As registry value present, a warning is displayed.

The Logon Only As registry value is a multi-string value (REG_MULTI_SZ) that contains the list of legacyExchangeDN attributes for the accounts that are authorized to log on to the Exchange information store. This registry value, which is not present by default, is typically added during periods of troubleshooting, maintenance, and mailbox move operations.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right-hand pane, delete the Logon Only As registry value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for more information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information about the Logon Only As registry value, see the Knowledge Base article 146764, "Limiting Logons to the Information Store" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=146764).

For information about how to limit logons during mailbox move operations, see the Knowledge Base article 218920, "XADM: How to Prevent Logons During Move Mailbox" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=218920).


Lookup SID Cache Expire registry value has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether the Lookup Sid Cache Expire registry entry is present:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

The Exchange Server Analyzer displays a non-default configuration message if the following conditions exist:

  • The Lookup Sid Cache Expire registry entry is present.

  • The Lookup Sid Cache Expire registry entry has any value other than 3,600.

On Exchange servers that are running Exchange 2000 Server Service Pack 3 or later, the information store creates a cache that contains Security Identifiers (SIDs) and indicates whether the SID is a user object or group object. This cache is created and populated when a public folder is first touched. After the cache is populated, all calls to look up account SIDs are first directed to the information store cache. If the SID is not in the information store cache, the call is made to the domain controller, and then the information for that SID is added to the cache.

By default, the cache is maintained for one hour. If the cache exceeds the default 8 kilobytes (KB) of entries, older cache entries are removed to make room for the new entries. You can use two registry keys to adjust both the default cache time (Lookup Sid Cache Expire) and the default cache size (Lookup Sid Cache Size). It is recommended that you do not change these default settings unless you have evidence that making this change will increase performance.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

  3. In the right pane, locate and delete the Lookup Sid Cache Expire value. If the Lookup SID Cache Size value is also set, delete it, too.

  4. Exit the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Lookup Sid Cache Expire registry value, see Microsoft Knowledge Base article 328907, "XADM: Access Control List Upgrades Cause Slow Public Folder Performance; Fix Requires Exchange 2000 SP2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328907).


Lookup SID Cache Size registry value has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether the Lookup Sid Cache Size registry entry is present:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

The Exchange Server Analyzer displays a non-default configuration message if the following conditions exist:

  • The Lookup Sid Cache Size registry entry is present.

  • The Lookup Sid Cache Size registry entry has any value other than 1,024.

On Exchange servers that are running Exchange 2000 Server Service Pack 3 or later, the information store creates a cache that contains Security Identifiers (SIDs) and indicates whether the SID is a user object or group object. This cache is created and populated when a public folder is first touched. After the cache is populated, all calls to look up account SIDs are first directed to the information store cache. If the SID is not in the information store cache, the call is made to the domain controller, and then the information for that SID is added to the cache.

By default, the cache is maintained for one hour. If the cache exceeds the default 8 kilobytes (KB) of entries, older cache entries are removed to make room for the new entries. You can use two registry keys to adjust both the default cache time (Lookup Sid Cache Expire) and the default cache size (Lookup Sid Cache Size). It is recommended that you do not change these default settings unless you have evidence that making this change will increase performance.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

  3. In the right pane, locate and delete the Lookup Sid Cache Size value. If the Lookup SID Cache Expire value is also set, delete it, too.

  4. Exit the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Lookup Sid Cache Size registry value, see Microsoft Knowledge Base article 328907, "XADM: Access Control List Upgrades Cause Slow Public Folder Performance; Fix Requires Exchange 2000 SP2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328907).


Low virtual memory error event has been overridden
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the threshold for logging an event regarding virtual memory fragmentation has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\VM Error Level

If the Exchange Server Analyzer finds the VM Error Level registry value present and configured, a non-default configuration message is displayed.

In 32-bit Microsoft Windows® systems, there are two kinds of memory: physical memory (the amount of actual memory installed in the system) and virtual memory address space (a virtualized 4-gigabyte memory space). Regardless of how much physical memory is installed on the system, the total size of the virtual address space is always the same: 4 GB. Although it is not the case for all 32-bit applications, in the case of Exchange Server, virtual address space equals virtual memory; in other words, the terms are used interchangeably.

During the normal course of its operations, the Exchange information store will repeatedly allocate, use, and de-allocate virtual memory. When virtual memory is allocated, used, and de-allocated frequently, it can cause virtual memory fragmentation. Virtual memory fragmentation is analogous to file system fragmentation that can occur over time. After a while, allocated segments of virtual memory are no longer contiguous, and performance begins to suffer. In the case of the file system, you can run an application that performs defragmentation of the file system, and in most cases this can be done while the system is online and being accessed. In the case of virtual memory fragmentation, there is no defragmentation tool; instead, to correct the problem you must stop and start the Microsoft Exchange Information Store service or reboot the system.

When an Exchange Server computer has less than 16 MB of free contiguous virtual address space, the following error message is logged to the application event log:

Source: | MSExchangeIS
Category: | Performance
ID: | 9582
Type: | Error
Description: | The virtual memory necessary 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.

The VM Error Level registry value represents a configuration opportunity that allows an administrator to override the default 16 MB level warning and set an alternate value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, delete the value for VM Error Level.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about troubleshooting virtual memory fragmentation in Exchange Server 2003 and Exchange 2000 Server, see the 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).


Low virtual memory warning event has been overridden
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the threshold for logging an event regarding virtual memory fragmentation has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\VM Warning Level

If the Exchange Server Analyzer finds the VM Warning Level registry value present and configured, a non-default configuration message is displayed.

In 32-bit Microsoft Windows® systems, there are two kinds of memory: physical memory (the amount of actual memory installed in the system) and virtual memory address space (a virtualized 4 gigabyte memory space). Regardless of how much physical memory is installed on the system, the total size of the virtual address space is always the same: 4 GB. Although it is not the case for all 32-bit applications, for Exchange Server, virtual address space equals virtual memory; in other words, the terms are used interchangeably.

During the regular course of its operations, the Exchange information store will repeatedly allocate, use, and de-allocate virtual memory. When virtual memory is allocated, used, and de-allocated frequently, it can cause virtual memory fragmentation. Virtual memory fragmentation is analogous to file system fragmentation that can occur over time. After a while, allocated segments of virtual memory are no longer contiguous, and performance begins to suffer. For the file system, you can run an application that performs defragmentation of the file. Generally, you can do this while the system is online and being accessed. For virtual memory fragmentation, there is no defragmentation tool; instead, to correct the problem you must stop and start the Microsoft Exchange Information Stores service or restart the system.

By default, when an Exchange Server computer has less than 32 MB of free contiguous virtual address space, the following warning message is logged to the application event log:

Source: | MSExchangeIS
Category: | Performance
ID: | 9582
Type: | Warning
Description: | The virtual memory necessary to run your Exchange server is fragmented in such a way that performance may be affected. It is highly recommended that you restart all Exchange services to correct this issue.

The VM Warning Level registry value represents a configuration opportunity that lets an administrator override the default 32 MB level warning and set an alternate value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right-hand pane, delete the value for VM Warning Level.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about troubleshooting virtual memory fragmentation in Exchange Server 2003 and Exchange 2000 Server, see the 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).


Mailbox Cache Age Limit has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-15

The Microsoft® Exchange Server Analyzer Tool checks the registry of the Exchange Server computer for the presence of the Mailbox Cache Age Limit registry entry. This registry value is present at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds the Mailbox Cache Age Limit registry entry present and configured with a value of 1 or greater, a non-default configuration message is displayed.

Exchange Server allows size limits (quotas) to be set on mailboxes. Quota settings are stored in the Active Directory® directory service and Exchange Server periodically reads the information in Active Directory to determine whether any changes were made to these limits. By default, Exchange Server caches this information for a period of two hours (120 minutes), after which it re-reads the information in Active Directory.

The Mailbox Cache Age Limit registry value, which is represented in minutes, is used to override the default time period. It is especially useful in a situation where a user cannot access their mailbox because the mailbox limit has been reached. If the default cache age limit is in effect, the user will not be able to access their mailbox for up to two hours. The recommended value is 20 minutes. Do not set this value too low because this can cause performance issues.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

  3. In the right pane, locate and delete the Mailbox Cache Age Limit value.

  4. Exit the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Mailbox Cache Age Limit registry value, see the Knowledge Base article 327378, "XADM: Exchange 2000 and Exchange Server 2003 Mailbox Size Limits Are Not Enforced in a Reasonable Period of Time; Fix Requires Exchange 2000 SP3" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327378).


Mailbox Cache Idle Limit has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Mailbox Cache Idle Limit is present:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds the Mailbox Cache Idle Limit registry entry present, a non-default configuration message is displayed.

Exchange Server allows size limits (quotas) to be set on mailboxes. Quota settings are stored in the Active Directory® directory service, and the Exchange server periodically reads the information in Active Directory to determine whether any changes were made to these limits. Exchange Server caches this information for a period of time, after which it re-reads the information in Active Directory.

The Mailbox Cache Age Limit setting and the Mailbox Cache Idle Limit setting control how long the entries in the mailbox information cache survive. An item will be removed from the cache if it has been in the cache longer than the time (in seconds) in the Mailbox Cache Age Limit setting. An item will be removed from the cache if it is not used for the time (in seconds) in the Mailbox Cache Idle Limit. The default values for these settings are 7,200 seconds (120 minutes) for the Mailbox Cache Age Limit setting and 900 seconds (15 minutes) for the Mailbox Cache Idle Limit setting. The value of the Mailbox Cache Idle Limit setting should not be more than the value of the Mailbox Cache Age Limit setting.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem.

  3. In the right pane, locate and delete the Mailbox Cache Idle Limit value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Mailbox Cache Age Limit registry value, see the Knowledge Base article 327378, "XADM: Exchange 2000 Mailbox Size Limits Are Not Enforced in a Reasonable Period of Time; Fix Requires Exchange 2000 SP3" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327378).


Mailbox Cache Size has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Mailbox Cache Size is present:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds the Mailbox Cache Size registry entry present, a non-default configuration message is displayed.

The Mailbox Cache Size value controls the size of this mailbox cache. The default value is 256 MB. Exchange Server allows size limits (quotas) to be set on mailboxes. Quota settings are stored in the Active Directory® directory service and Exchange Server periodically reads the information in Active Directory to determine whether any changes were made to these limits. By default, Exchange Server caches this information for a period of two hours (7,200 seconds), after which it re-reads the information in Active Directory.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, locate and delete the Mailbox Cache Size value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Mailbox Cache Age Limit registry value, see the Knowledge Base article 327378, "XADM: Exchange 2000 Mailbox Size Limits Are Not Enforced in a Reasonable Period of Time; Fix Requires Exchange 2000 SP3" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327378).


Mailbox Cache Size set to zero
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine the setting for the Mailbox Cache Size value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds the Mailbox Cache Size registry value set to 0, an error is displayed.

Exchange Server allows size limits (quotas) to be set on mailboxes. Quota settings are stored in the Active Directory® directory service and Exchange Server periodically reads the information in Active Directory to determine whether any changes were made to these limits. The Mailbox Cache Size value controls the size of this mailbox cache. The default value is 256 MB. When set to 0, mailbox cache is turned off. Setting this value to 0 is not recommended because it causes the Directory Service Access (DSAccess) component to perform more Active Directory lookups. Additionally, setting this value to 0 can cause the Exchange store to fail, and can cause failures when moving mailboxes.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, locate and delete the Mailbox Cache Size value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Mailbox Cache Age Limit registry value, see the Knowledge Base article 327378, "XADM: Exchange 2000 Mailbox Size Limits Are Not Enforced in a Reasonable Period of Time; Fix Requires Exchange 2000 SP3" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327378).


Mailbox Store Controlled by Policy
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-06-06

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchPolicyList attribute of each mailbox store object. The msExchPolicyList attribute determines whether an Exchange Server mailbox policy has been created and assigned to a mailbox store. If the Exchange Server Analyzer finds that the msExchPolicyList attribute has been set, the Exchange Server Analyzer displays a non-default configuration message.

By default, when mailbox stores are created, they do not have a mailbox policy assigned. However most of the time, administrators create mailbox policies and then assign them to multiple mailbox stores. These policies apply administrative settings such as storage limits, indexing updates, maintenance intervals, mappings to public stores and offline address lists. If a mailbox policy has been created and assigned to a mailbox store, the Exchange Server Analyzer displays a message stating that the mailbox store is currently controlled by a mailbox policy. No additional actions are required.

To remove a mailbox policy from a mailbox store

  1. Open Exchange System Manager and expand Administrative Groups in the console tree.

  2. Expand the First Administrative Group and then select System Policies.

  3. In the results pane, right-click the mailbox store and select Remove from policy.

  4. In the Exchange System Manager window, click Yes to confirm the removal of the mailbox store.
Note:
If the System Policies node is not visible in the console tree in Exchange System Manager, configure Exchange System Manager to display Administrative Groups.

For more information about mailbox store policies, see the following Microsoft Knowledge Base articles:

  • 822938, "How To: Use System Policies to Configure Mailbox Storage Limits in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822938).

  • 256141, "How to Create System Policies in Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256141).

For more information about Exchange Server database files, see the following Exchange Server 2003 topics:

  • "Managing Mailbox Stores and Public Folder Stores" in the Administration Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47617).

  • "Understanding the Exchange Server 2003 Store" in Working with Exchange Server 2003 Stores (http://go.microsoft.com/fwlink/?LinkId=47595).


Mailbox store database file stored on network drive
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchEDBFile attribute of each mailbox store object. This attribute specifies the location of the database files used by this mailbox store.

The Exchange Server Analyzer also queries Active Directory to determine the count of the values listed in the homeMDBBL attribute of each mailbox store on this server. The count of this attribute represents the number of mailboxes in the mailbox store. The Exchange Server Analyzer can then calculate the total number of mailboxes managed by the server.

If the Exchange Server Analyzer finds that the msExchEDBFile attribute starts with \\ on an Exchange server with more than 50 mailboxes, an error is displayed.

This error indicates that the database files for a mailbox store are being stored on a network share. If the msExchEDBFile attribute starts with \\, it indicates that the log file path uses a Universal Naming Convention (UNC) path. This is not a recommended practice because interruptions in network connectivity could cause database errors, resulting in lost data or corrupted databases. It is recommended that you correct this problem as soon as possible.

To move the database files to a new drive

  1. In Exchange System Manager, expand the Exchange server object on which the store resides, expand the appropriate storage group container, right-click the mailbox store object that you want, and then click Properties.

  2. Specify new file locations on the Database tab of the Properties dialog box.

For more information about Exchange Server database files, see the following topics:

  • "Managing Mailbox Stores and Public Folder Stores" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617)

  • "Understanding the Exchange Server 2003 Store" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595)

For more information about using Exchange Server with network drives, see the following Microsoft Knowledge Base articles:

  • 328879, "Using Exchange Server with Storage Attached Network and network-attached storage devices" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328879)

  • 839687, "Microsoft support policy on the use of network-attached storage devices with Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=839687)

  • 317173, "Exchange Server and network-attached storage" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317173)

  • 317172, "Exchange Server 5.5 and network-attached storage" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317172)


Mailbox Store Database size limit has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Database Size Limit in Gb registry value is present and configured for mailbox store databases:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

If the Exchange Server Analyzer finds that the Database Size Limit in Gb value is present and configured, the Exchange Server Analyzer displays a non-default configuration message.

When Exchange Server 2003 Service Pack 2 (SP2) is applied to Exchange Server 2003 Standard Edition, the hard-coded licensing database size limit is increased from 16 gigabytes (GB) to 75 GB. You can set a protective database size limit to prevent unintentional database size growth. The default size limit value in SP2 is 18 GB, and this default value can be overwritten by creating the Database Size Limit in Gb registry value.

The Exchange Server 2007 Standard Edition hard coded licensing database size limit of 50 GB can also be increased by creating the Database Size Limit in Gb registry value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Delete the Database Size Limit in Gb value.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site (http://go.microsoft.com/fwlink/?LinkId=52073).


Mailbox store does not have a default public folder store associated
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchPrivateMDB attribute has a default public folder store that is assigned to the mailbox store.

The msExchPrivateMDB attribute is a private database configuration for a mailbox store object. By default, the msExchHomePublicMDB attribute is associated with a mailbox store. The msExchPrivateMDB attribute is the home public message database (MDB).

If the Exchange Server Analyzer finds that the msExchHomePublicMDB attribute is deleted or configured incorrectly, the Exchange Server Analyzer displays an error.

Each mailbox store must be associated with a default public folder store, either on the local server or another server. For each mailbox-enabled user who is supported by a particular mailbox store, the associated public folder store is the user's home public folder store. If you can, use the default public folder store on the same server as the mailbox store.

Note:
By using the default public folder store on the same server as the mailbox store, you may improve performance when users access public folders and simplify troubleshooting of public folder access problems.
To assign a default public folder store to mailbox store

  1. In Exchange System Manager, right-click the storage group where the Mailbox Store resides.

  2. Right-click the mailbox store, and then click Properties.

  3. On the General tab, in Default Public folder store, click Browse and select the public folder store that you want to associate with this mailbox store.

    Note:
    If you are creating a new mailbox store, Exchange Server automatically selects a default public store, which is associated with the Public Folders tree, and an offline address book, which users will download for offline use.

For more information about managing mailbox stores and public folder stores, see the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?linkid=47617).


Mailbox store exceeds 12 GB
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-02-28

The Microsoft® Exchange Server Analyzer Tool queries the CIM_DataFile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FileSize key for each Exchange mailbox store database file (.edb file) and streaming file (.stm file). The Exchange Server Analyzer also reads the following registry branch to determine the version of Exchange Server that is installed:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Exchange Product GUID>

If the Exchange Server Analyzer finds that the combined size of a pair of mailbox store database and streaming files exceeds 12 GB on a computer that is running Microsoft Exchange Server 2003 Standard Edition or Microsoft Exchange 2000 Server Standard Edition, a warning is displayed.

Exchange store databases on Exchange Server 2003 Standard Edition and Exchange 2000 Server Standard Edition cannot grow larger than 16 GB. After that limit is reached, the mailbox store will no longer mount and Exchange will be inaccessible. Exchange store databases in Exchange Server 2003 Enterprise Edition and Exchange 2000 Server Enterprise Edition are not limited to 16 GB; they are limited only by available hardware, with a theoretical maximum size of 16 terabytes.

To correct this warning

  1. Consider moving some of the mailboxes from the large mailbox store to a new mailbox store on this or another Exchange Server computer.

  2. If you have recently moved mailboxes from this information store to another store, or if you have recently deleted mailboxes from this mailbox store, performing an offline defragmentation may decrease the size of the files.

  3. Consider setting mailbox and message size limits to prevent unlimited growth of the mailbox store.
Note:
With the release of Exchange Server 2003 Service Pack 2 (SP2), in Exchange Server 2003 Standard Edition, the hard-coded licensing database size limit has been increased from 16 GB to 75 GB. The administrator can set a protective database size limit (prevent unintentional database size growth). The default value is 18 GB in SP2 for Standard Edition and the default of 18 GB can be overwritten by editing the Database Size Limit in Gb registry key.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the database size limit for a database with Exchange Server 2003 SP2

  1. On the computer running Exchange Server, start Regedit.exe.

  2. Open the following registry key: HKLM\System\CurrentControlSet\Services\MSExchangeIS\Server name\Private-Mailbox Store GUID

  3. Right-click Private Store GUID, point to New, and then click DWORD Value.

  4. For the new value name, type Database Size Limit in Gb.

  5. Double-click Database Size Limit in Gb. In Value data, type an appropriate value for maximum database size in GB. For Exchange Server 2003 Standard Edition, type a decimal value between 1 and 75 (the default is 18 GB). For Exchange Server 2003 Enterprise Edition, type a decimal value between 1 and 8000 (the default is 8000 GB). Click OK.

  6. Right-click Private Store GUID, point to New, and then click DWORD Value.

  7. For the new value name, type Database Size Buffer in Percentage.

  8. Double-click Database Size Buffer in Percentage. In Value data, type a decimal value between 1 and 100 to specify when you want events to be logged to warn you that you are nearing the maximum size for a database. The default value of 10 will result in warning events to be logged when you have 10 percent capacity left before you reach the maximum size for that database. Click OK.

  9. Right-click Private Store GUID, point to New, and then click DWORD Value.

  10. For the new name, type Database Size Check Start Time in Hours From Midnight.

  11. Double-click Database Size Check Start Time in Hours From Midnight. In Value data, type a value between 0 and 23 to specify when you want Exchange to check the database size. The default value of 5 results in Exchange Server checking the database size 5 hours after midnight (5:00 AM). Click OK.

  12. Close Registry Editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about .stm and .edb files, see the Microsoft Knowledge Base article 232323, "Native Content Storage in Microsoft Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323).

For more information about moving mailboxes in Exchange Server 2003, see the Knowledge Base article 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829).

For more information about moving mailboxes in Exchange 2000 Server, see the Knowledge Base article 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810).

For more information about performing an offline defragmentation of an Exchange Server database, see the Knowledge Base article, 328804, "How to Defragment Exchange Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804).

For more information about setting message size limits, see the Knowledge Base article 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679).

For information about Exchange Server 2003 Standard Edition or Microsoft Exchange 2000 Server Standard Edition reaching the maximum database size, see the Knowledge Base article, 828070, "Exchange Server Mailbox Store Does Not Mount When the Mailbox Store Database Reaches the 16-GB Limit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site (http://go.microsoft.com/fwlink/?LinkId=52073).


Mailbox store exceeds 15 GB
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-02-28

The Microsoft® Exchange Server Analyzer Tool queries the CIM_DataFile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FileSize key for each Exchange mailbox store database file (.edb file) and streaming file (.stm file). The Exchange Server Analyzer also reads the following registry branch to determine the version of Exchange Server that is installed:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Exchange Product GUID>

If the Exchange Server Analyzer finds that the combined size of a pair of mailbox store database and streaming files exceeds 15 GB on a computer that is running Microsoft Exchange Server 2003 Standard Edition or Microsoft Exchange 2000 Server Standard Edition, an error is displayed.

Exchange store databases on Exchange Server 2003 Standard Edition and Exchange 2000 Server Standard Edition cannot grow larger than 16 GB. After that limit is reached, the mailbox store will no longer mount and Exchange will be inaccessible. Exchange store databases in Exchange Server 2003 Enterprise Edition and Exchange 2000 Server Enterprise Edition are not limited to 16 GB; they are limited only by available hardware, with a theoretical maximum size of 16 terabytes.

To correct this error

  1. Consider moving some of the mailboxes from the large mailbox store to a new mailbox store on this or another Exchange Server computer.

  2. If you have recently moved mailboxes from this information store to another store, or if you have recently deleted mailboxes from this mailbox store, performing an offline defragmentation may decrease the size of the files.

  3. Consider setting mailbox and message size limits to prevent unlimited growth of the mailbox store.
Note:
With the release of Exchange Server 2003 Service Pack 2 (SP2), in Exchange Server 2003 Standard Edition, the hard-coded licensing database size limit has been increased from 16 GB to 75 GB. The administrator can set a protective database size limit (prevent unintentional database size growth). The default value is 18 GB in SP2 for Standard Edition and the default of 18 GB can be overwritten by editing the Database Size Limit in GB registry key.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the database size limit for a database with Exchange Server 2003 SP2

  1. On the computer running Exchange Server, start Regedit.exe.

  2. Open the following registry key: HKLM\System\CurrentControlSet\Services\MSExchangeIS\Server name\Private-Mailbox Store GUID

  3. Right-click Private Store GUID, point to New, and then click DWORD Value.

  4. For the new value name, type Database Size Limit in Gb.

  5. Double-click Database Size Limit in Gb. In Value data, type an appropriate value for maximum database size in GB. For Exchange Server 2003 Standard Edition, type a decimal value between 1 and 75 (the default is 18 GB). For Exchange Server 2003 Enterprise Edition, type a decimal value between 1 and 8000 (the default is 8000 GB). Click OK.

  6. Right-click Private Store GUID, point to New, and then click DWORD Value.

  7. For the new value name, type Database Size Buffer in Percentage.

  8. Double-click Database Size Buffer in Percentage. In Value data, type a decimal value between 1 and 100 to specify when you want events to be logged to warn you that you are nearing the maximum size for a database. The default value of 10 will result in warning events to be logged when you have 10 percent capacity left before you reach the maximum size for that database. Click OK.

  9. Right-click Private Store GUID, point to New, and then click DWORD Value.

  10. For the new name, type Database Size Check Start Time in Hours From Midnight.

  11. Double-click Database Size Check Start Time in Hours From Midnight. In Value data, type a value between 0 and 23 to specify when you want Exchange to check the database size. The default value of 5 results in Exchange Server checking the database size 5 hours after midnight (5:00 AM). Click OK.

  12. Close Registry Editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about .stm and .edb files, see the Microsoft Knowledge Base article 232323, "Native Content Storage in Microsoft Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323).

For more information about moving mailboxes in Exchange Server 2003, see the Knowledge Base article 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829).

For more information about moving mailboxes in Exchange 2000 Server, see the Knowledge Base article 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810).

For more information about performing an offline defragmentation of an Exchange Server database, see the Knowledge Base article 328804, "How to Defragment Exchange Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804).

For more information about setting message size limits, see the Knowledge Base article 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679).

For information about Exchange Server 2003 Standard Edition and Exchange 2000 Server Standard Edition reaching the maximum database size, see the Knowledge Base article 828070, "Exchange Server Mailbox Store Does Not Mount When the Mailbox Store Database Reaches the 16-GB Limit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site (http://go.microsoft.com/fwlink/?LinkId=52073).


Mailbox store has not had a full backup in more than 8 days
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries each mailbox store to determine the date and time of the last full backup. The Exchange Server Analyzer also queries the Active Directory® directory service to determine the number of users with mailboxes in each mailbox store. The Exchange Server Analyzer displays a warning if both of the following conditions exist:

  • The number of days since the last full backup for a mailbox store is greater than eight.

  • More than ten mailboxes exist in the mailbox store.

The mailbox store is a database for storing mailboxes in Microsoft Exchange Server 2003 and Exchange Server 2007. A mailbox store is made up of a rich-text (.edb) file and a streaming native Internet content (.stm) file. Although there are two files, the .edb and .stm files, they represent two halves of a single database, instead of two distinct databases.

The mailbox store and public folder store data in your Exchange Server databases and transaction log files are the most important data to back up in your Exchange Server organization. You can use an Exchange Server database backup to restore a damaged mailbox to a functioning server that is running Exchange Server. You can also use Exchange Server database backups to restore your Exchange Server databases to a different server.

As a best practice, 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 Server databases are deleted from the server. A full backup provides the advantage of speed in a recovery scenario, because you need only one tape set to restore all data.

Note:
It is a best practice to keep transaction log files on a dedicated disk separate from the database files. This provides fault tolerance in case the database disk is destroyed, and in some cases, improves database performance.
Important:
You must have the required permissions or rights assigned to the user account that you are logged into when you try to back up or restore files and folders. To create Exchange Server backups, you must have domain level backup operator rights. To create backups of your Microsoft Windows Server™ 2003 operating system, you must have, at a minimum, local backup operator rights.

The backup strategy that you choose for your Exchange Server data depends on the size of the stores, the speed of backup software and hardware, hardware capacity, and time requirements.

For more information about backup strategies and disaster recovery operations, see:

  • Exchange Server 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?LinkId=47570).

  • Database Backup and Restore (http://go.microsoft.com/fwlink/?LinkId=80766).


Mailbox store has not had a full backup in more than 60 days
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries each mailbox store to determine the date and time of the last full backup. The Exchange Server Analyzer also queries the Active Directory® directory service to determine the number of users with mailboxes in each mailbox store. The Exchange Server Analyzer displays an error if both of the following conditions exist:

  • The number of days since the last full backup for a mailbox store is greater than 60 days.

  • More than 10 mailboxes exist in the mailbox store.

The mailbox store is a database for storing mailboxes in Microsoft Exchange Server 2003 and Microsoft Exchange Server 2007. A mailbox store is made up of a rich-text (.edb) file and a streaming native Internet content (.stm) file. Although there are two files, the .edb and .stm files, they represent two halves of a single database, instead of two distinct databases.

The mailbox store and public folder store data in your Exchange Server databases and transaction log files are the most important data to back up in your Exchange Server organization. You can use an Exchange Server database backup to restore a damaged mailbox to a functioning server that is running Exchange Server. You can also use Exchange Server database backups to restore your Exchange Server databases to a different server.

As a best practice, you should perform a full backup of your database files and transaction logs every day. After you complete a full backup of a storage group, the committed transaction log files on the Exchange Server databases are deleted from the server. A full backup provides the advantage of speed in a recovery scenario, because you need only one tape set to restore all data.

Note:
It is a best practice to keep transaction log files on a dedicated disk separate from the database files. This provides fault tolerance in case the database disk is destroyed, and in some cases, improves database performance.
Important:
You must have the required permissions or rights assigned to the user account that you are logged into when you try to back up or restore files and folders. To create Exchange Server backups, you must have domain level backup operator rights. To create backups of your Microsoft Windows Server™ 2003 operating system, you must have at least local backup operator rights.

The backup strategy that you choose for your Exchange Server data depends on the size of the stores, the speed of backup software and hardware, hardware capacity, and time requirements.

For more information about backup strategies and disaster recovery operations, see:

  • Exchange Server 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?LinkId=47570).

  • Database Backup and Restore (http://go.microsoft.com/fwlink/?LinkID=80766).


Mailbox store online maintenance schedules overlap
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether all the mailbox stores in the storage group have the same maintenance schedule. If the storage group container (class msExchStorageGroup) has two or more mailbox store objects (class msExchPrivMDB), the Exchange Server Analyzer checks the activationSchedule attribute of each mailbox store object. If the Exchange Server Analyzer finds that these values (stored as octet strings) are the same for each mailbox store, or that they overlap, a warning is displayed.

By default, the mailbox store maintenance processes run nightly from 1:00 A.M. to 5:00 A.M. Because of the server resources required for the maintenance processes, it is recommended that you modify the maintenance schedules so that the mailbox stores have schedules that differ by at least 15 minutes.

To correct this warning for Exchange 2000 Server and Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, and then expand the server that you want to work with.

  3. Expand the storage group that you want to work with.

  4. Right-click the store that you want to work with, and then click Properties.

  5. On the Database tab, click Maintenance interval and click a new interval, or click Customize to create a custom schedule.

To correct this warning for Exchange Server 2007

  1. Open Exchange Management Console

  2. Expand Server Configuration and then select the server that you want to work with.

  3. Expand the storage group that you want to work with.

  4. Right-click the store that you want to work with, and then click Properties.

  5. On the General tab, click the Maintenance schedule drop down and select a new interval, or click Customize to create a custom schedule.

For more information about Exchange Server 2003 store maintenance, see "Configuring Store Maintenance and Backup Options" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


Mailbox store prohibit send and receive limits are too similar
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the mailbox size limits set on a mailbox. If the Exchange Server Analyzer finds that the difference between the Prohibit send and Prohibit send and receive mailbox limits is less than 20 percent, the Exchange Server Analyzer displays a Best Practice configuration message.

It is a best practice to separate the Prohibit send and Prohibit send and receive limits by at least 20 percent. If the difference between the limits is less than 20 percent, the mailbox user may not have enough time to clean-up their mailbox before the mailbox starts to reject messages. For example, if users are prohibited from sending new messages when their mailbox hits 100 MB, the Prohibit send and receive limit should be at least 120MB.

Note:
It is also important to set a warning limit on the mailboxes. When the mailbox reaches the warning limit, an e-mail message will be sent to the user warning him or her that the mailbox is approaching the limit defined in the Prohibit send limit.

To correct this problem, you should increase the difference between the Prohibit send and Prohibit send and receive mailbox limits to more than 20 percent.

To set mailbox limits

  1. Open the Exchange System Manager.

  2. Locate the mailbox store displayed in the Exchange Server Analyzer message.

  3. Right-click MailboxStore_Name and select Properties.

  4. Select the Limits tab.

  5. Modify the Prohibit send at (KB) limit or the Prohibit send and receive at (KB) limit, or both limits.

  6. Click Apply, and then click OK.
To set mailbox limits on Exchange Server 2007 using the Exchange Management Console

  1. Open the Exchange Management Console

  2. Locate the mailbox store displayed in the Exchange Server Analyzer regarding this issue.

  3. Right-click MailboxStore_Name and select Properties.

  4. Select the Limits tab.

  5. Modify the Issue warning at (KB), Prohibit send at (KB) limit and the Prohibit send and receive at (KB) limit.

  6. Click Apply, and then click OK
To set mailbox limits on Exchange Server 2007 using the Exchange Management Shell

  1. The following example shows how to set the mailbox size at which a warning message is sent to the user This attribute applies to all mailboxes in this mailbox database that do not have their own warning quota attribute set. You must specify either an integer or "unlimited." The default value is 1.9 gigabytes (GB).
Copy Code
Set-MailboxDatabase "Mailbox Database Name" -IssueWarningQuota 1991680
  1. The following example shows how to set the mailbox size at which users associated with mailboxes in this mailbox database can no longer send messages. This attribute applies to all mailboxes in this mailbox database that do not have their own prohibit send quota attributes set.. The limit value set must be either an integer or "unlimited."

Copy Code
Set-MailboxDatabase "Mailbox Database Name" -ProhibitSendQuota 2097152
  1. The following example shows how to set the mailbox size at which the user associated with this mailbox can no longer send or receive messages. This attribute applies to all mailboxes in this mailbox database that do not have their own prohibit send receive quota attributes set. You must specify either an integer or "unlimited."

Copy Code
Set-MailboxDatabase "Mailbox Database Name" -ProhibitSendReceiveQuota 2411520

For more information about managing Exchange mailboxes, see Working with Exchange Server 2003 Stores (http://go.microsoft.com/fwlink/?LinkId=47595).

For more information about managing Exchange mailbox limits in Exchange Server 2007, see "How to Configure Database Limits and Properties" (http://go.microsoft.com/fwlink/?LinkID=80746)


Mailbox store will not mount on startup
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchEDBOffline attribute of all objects with a class of msExchPrivateMDB. Objects with this class are mailbox stores.

A value of True for the msExchEDBOffline attribute indicates that the mailbox store will not be mounted automatically when the Microsoft Exchange Information Store service starts. A value of False indicates that the mailbox store will be mounted at startup. If the Exchange Server Analyzer finds the value for this attribute to be True, a warning is displayed.

This warning indicates that the Do not mount this store at start-up check box is selected. This check box is on the Database tab of the mailbox store Properties dialog box. When the check box is selected, the mailbox store will not be mounted automatically when the Microsoft Exchange Information Store service starts. The next time the Microsoft Exchange Information Store service is started, for example after a restart of the server, a mailbox store with this attribute set to True will not mount. We recommend that mailbox stores mount automatically when the Microsoft Exchange Information Store service is started.

To correct this warning for Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, and then expand the server that contains the mailbox store you want to modify.

  3. Expand the storage group that contains the mailbox store you want to modify.

  4. Right-click the mailbox store, and then click Properties.

  5. On the Database tab, clear the Do not mount this store at start-up check box.

  6. Click OK to save the setting.

  7. Close Exchange System Manager.

To correct this warning for Exchange Server 2007

  1. Open Exchange Management Console

  2. Expand Server Configuration and then select the server that you want to work with.

  3. Expand the storage group that you want to work with.

  4. Right-click the database that you want to work with, and then click Properties.

  5. On the General tab, clear the Do not mount this database at start-up check box.

  6. Click OK to save the setting.

  7. Close Exchange Management Console

For more information about this option, see the following Microsoft Knowledge Base articles:

  • 314218, "HOW TO: Turn Off or Turn On Automatic Mounting of Data Stores at Startup in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=314218)

  • 285169, "XADM: Information Stores Do Not Mount After You Use the "/disasterrecovery" Switch" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=285169)


Max FXGetBuffer Users parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Max FXGetBuffer Users registry key has been created:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds that the Max FXGetBuffer Users registry key has been created under ParametersSystem, the Exchange Server Analyzer displays a non-default configuration message.

You can use the Max FXGetBuffer Users registry key to control the number of Microsoft Office Outlook® 2003 clients that synchronize with an Exchange Server 2003 server at the same time. You set the value for the Max FXGetBuffer Users registry key to override the limit on simultaneous remote procedure call (RPC) connections that are made by Outlook clients. These connections are sometimes referred to as ropFXSrcGetBuffers. You calculate the default value for the Max FXGetBuffer Users registry key by taking the number of processors that are on the server, multiplying that number by 2, and then adding 3. For example, on an Exchange Server 2003 server that has two processors, the default value is 7 ([2*2] + 3=7).

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the Max FXGetBuffer Users value.

  4. Close the registry editor.

The Microsoft Exchange Information Store service detects the changes in minutes. You do not have to restart the computer.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting registry keys to control the number of Outlook clients that can synchronize with Exchange Server 2003, see the Knowledge Base article, 818484, "Registry Values and Counters That You Can Use to Configure and Monitor Outlook Client Synchronization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=818484).


Maximum attachment per message submission has been changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the default maximum number of attachments per message submission has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession\objtAttachment

If the Exchange Server Analyzer finds the objtAttachment registry value present and configured with any value other than is displayed in the table below, a non-default configuration message is displayed.

Entry | Exchange Server 2003 RTM Default Value | Exchange Server 2003 SP1 and Later Default value | Exchange Server 2007 Default Value
objtAttachment | 100 | 500 | 500

When manually added and configured, the objtAttachment registry value determines the maximum number of attachments per message submission per MAPI client. When a MAPI client attempts to send a message with more than the allowed number of attachments, the following event is logged in the application event log on the Exchange Server computer that contains the client's mailbox:

Event Type: | Error
Event ID: | 9646
Event Source: | MSExchangeIS
Event Category: | General
Description: | Closing Mapi session "/o=OrganizationName/ou=AdministrativeGroupName/cn=Recipients/cn=UserName" because it exceeded the maximum of xxx objects of type "objtAttachment".

The objtAttachment registry value represents a configuration opportunity that provides the administrator with a greater level of control over the Exchange Server resources used by MAPI clients.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession.

  3. Delete the objtAttachment registry value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Alternatively, if you wish to make use of the objtAttachment registry value, instead of deleting it, keep it set to its existing value or adjust it as needed.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information, see the Knowledge Base article 830829, "Your Exchange Server 2003 computer may stop responding after a MAPI client opens more than the default value of certain server objects" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830829).


Maximum cached views has been modified
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the maximum number of cached views per database has been modified. If the Exchange Server Analyzer finds that the msExchMaxCachedViews attribute has been changed from its default of 11, the Exchange Server Analyzer displays a non-default configuration message. The number of cached views that you have configured per database is included with the Exchange Server Analyzer output. It is a best practice to have between 5 and 20 cached views.

The msExchMaxCachedViews is an attribute of the msExchangePrivateMDB object class. Therefore, each mailbox database store object in Active Directory has an msExchMaxCachedViews attribute value. The msExchMaxCachedViews attribute value specifies the maximum number of views that are cached for a specific folder in a mailbox. In this context, "view" refers to the folders that are displayed when a user accesses another user's Microsoft Office Outlook® 2003 mailbox. When users share access to an Outlook folder with other users, Exchange Server generates a view that hides private items.

When an Outlook user first views someone else's calendar, contact folder, or other data, the user may experience delays. After the user has viewed the folder, the user may experience quicker views on subsequent attempts, but after a period of time, the user may experience delays when the user tries to access the folder again. This delay is generally most noticeable when the folder contains a large number of items. A large number is 5,000 items or more.

The act of applying a view to a folder creates search folders in the Exchange store for each unique user who accesses the Outlook folder. When a search folder is created, it is cached for later use. Before Exchange Server creates a new search folder, it determines whether that search folder already exists. If the search folder exists, Exchange Server uses the cached search folder to accelerate subsequent viewings.

The msExchMaxCachedViews attribute defines how many search folders are cached in a specific folder. For example, the msExchMaxCachedViews attribute can define how many search folders are cached in the Calendar folder.

If you have many users who share Outlook folders, you must decide how to balance server resourcing and acceptable client performance. When a search folder is cached, a search folder is kept up-to-date as the data in the search folder changes. Such updates use CPU and disk resources. If multiple caches of the search folder are being maintained, CPU performance and disk performance are further impacted.

On the other hand, when Exchange Server creates a search folder for the first time, the user who accesses the Outlook folder may experience a delay as the search folder is built.

For example, consider an Exchange Server that is configured with 11 search folders. Eleven is the default number of search folders. UserA shares her Calendar folder with 15 other users. UserB accesses the folder and experiences a delay while his search folder is built. After the search folder for UserB is created, access to UserA's Calendar folder is quick. Assume UserB does not access the folder for the rest of the day. In the meantime, if 11 other users access the folder, unique search folders are created for them. Because only 11 search folders are cached, the next time UserB accesses UserA's Calendar, UserB again experiences a delay while a new search folder is built for him.

The best practice is to limit the maximum number of search folder caches to 20 or less. When you exceed this number, especially for folders that have more than 5,000 items in them, you may overload the server as the server attempts to maintain the cached folders.

Additionally, it is a best practice to have no less than five caches. If users are sharing Outlook folders with multiple users, caching only four search folders negatively affects client experience and causes the server to use more resources on creating new caches more often.

The msExchMaxCachedViews attribute also can be set on public folder databases. Search folders also are built for public folders. By default, public folders are shared resources that many users may access. If public folders receive many posts, you should minimize search folders because the Exchange Server may experience heavy CPU and disk use as it updates the search folders. Additionally, it is not a best practice to try to optimize the client experience by providing many search folder caches if many different users access a public folder. It is likely that these caches will be discarded as new search folders are created for new users.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To modify the msExchMaxCachedViews attribute

  1. Start the ADSI Edit tool from Microsoft Windows® 2000 Support Tools or from Windows Server 2003 Support Tools.

  2. Expand the following nodes:

    • Configuration Container

    • Configuration

    • Services

    • Microsoft Exchange

    • Organization_Name

    • Administrative Groups

    • Administrative_Group_Name

    • Servers

    • InformationStore

    • Storage_Group_Name

  3. In the details pane, right-click Database_Name, and then click Properties.

  4. In the Attributes box, double-click msExchMaxCachedViews.

  5. In the Integer Attribute Editor dialog box, enter an integer between 5 and 20 in the Value field, and then click OK.

  6. Click Apply, and then close ADSI Edit.

  7. Wait at least 15 minutes for replication, and then restart the Microsoft Exchange Information Store service on the Exchange Server where you made the modification.


Maximum cached views is set too high
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the maximum number of cached views per database has been modified. If the Exchange Server Analyzer finds that the msExchMaxCachedViews attribute is set to a value greater than 20, the Exchange Server Analyzer displays a warning. The number of cached views that you have configured per database is included with the Exchange Server Analyzer output. It is a best practice to have between 5 and 20 cached views.

The msExchMaxCachedViews is an attribute of the msExchangePrivateMDB object class. Therefore, each mailbox database store object in Active Directory has an msExchMaxCachedViews attribute value. The msExchMaxCachedViews attribute value specifies the maximum number of views that are cached for a specific folder in a mailbox. In this context, "view" refers to the folders that are displayed when a user accesses another user's Microsoft Office Outlook® 2003 mailbox. When users share access to an Outlook folder with other users, Exchange Server generates a view that hides private items.

When an Outlook user first views someone else's calendar, contact folder, or other data, the user may experience delays. After the user has viewed the folder, the user may experience quicker views on subsequent attempts, but after a period of time, the user may experience delays when the user tries to access the folder again. This delay is generally most noticeable when the folder contains a large number of items. A large number is 5,000 items or more.

The act of applying a view to a folder creates search folders in the Exchange store for each unique user who accesses the Outlook folder. When a search folder is created, it is cached for later use. Before Exchange Server creates a new search folder, it determines whether that search folder already exists. If the search folder exists, Exchange Server uses the cached search folder to accelerate subsequent viewings.

The msExchMaxCachedViews attribute defines how many search folders are cached in a specific folder. For example, the msExchMaxCachedViews attribute can define how many search folders are cached in the Calendar folder.

If you have many users who share Outlook folders, you must decide how to balance server resourcing and acceptable client performance. When a search folder is cached, a search folder is kept up-to-date as the data in the search folder changes. Such updates use CPU and disk resources. If multiple caches of the search folder are being maintained, CPU performance and disk performance are further impacted.

On the other hand, when Exchange Server creates a search folder for the first time, the user who accesses the Outlook folder may experience a delay as the search folder is built.

For example, consider an Exchange Server that is configured with 11 search folders. Eleven is the default number of search folders. UserA shares her Calendar folder with 15 other users. UserB accesses the folder and experiences a delay while his search folder is built. After the search folder for UserB is created, access to UserA's Calendar folder is quick. Assume UserB does not access the folder for the rest of the day. In the meantime, if 11 other users access the folder, unique search folders are created for them. Because only 11 search folders are cached, the next time UserB accesses UserA's Calendar, UserB again experiences a delay while a new search folder is built for him.

The best practice is to limit the maximum number of search folder caches to 20 or less. When you exceed this number, especially for folders that have more than 5,000 items in them, you may overload the server as the server attempts to maintain the cached folders.

Additionally, it is a best practice to have no less than five caches. If users are sharing Outlook folders with multiple users, caching only four search folders negatively affects client experience and causes the server to use more resources on creating new caches more often.

The msExchMaxCachedViews attribute also can be set on public folder databases. Search folders also are built for public folders. By default, public folders are shared resources that many users may access. If public folders receive many posts, you should minimize search folders because the Exchange Server may experience heavy CPU and disk use as it updates the search folders. Additionally, it is not a best practice to try to optimize the client experience by providing many search folder caches if many different users access a public folder. It is likely that these caches will be discarded as new search folders are created for new users.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To modify the msExchMaxCachedViews attribute

  1. Start the ADSI Edit tool from Microsoft Windows® 2000 Support Tools or from Windows Server 2003 Support Tools.

  2. Expand the following nodes:

    • Configuration Container

    • Configuration

    • Services

    • Microsoft Exchange

    • Organization_Name

    • Administrative Groups

    • Administrative_Group_Name

    • Servers

    • InformationStore

    • Storage_Group_Name

  3. In the details pane, right-click Database_Name, and then click Properties.

  4. In the Attributes box, double-click msExchMaxCachedViews.

  5. In the Integer Attribute Editor dialog box, enter an integer between 5 and 20 in the Value field, and then click OK.

  6. Click Apply, and then close ADSI Edit.

  7. Wait at least 15 minutes for replication, and then restart the Microsoft Exchange Information Store service on the Exchange Server where you made the modification.


Maximum cached views is set too low
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the maximum number of cached views per database has been modified. If the Exchange Server Analyzer finds that the msExchMaxCachedViews attribute is set to a value less than 5, the Exchange Server Analyzer displays a warning. The number of cached views you have configured per database is included with the Exchange Server Analyzer output. It is a best practice to have between 5 and 20 cached views.

The msExchMaxCachedViews is an attribute of the msExchangePrivateMDB object class. Therefore, each mailbox database store object in Active Directory has an msExchMaxCachedViews attribute value. The msExchMaxCachedViews attribute value specifies the maximum number of views that are cached for a specific folder within a mailbox.

In this context, "view" refers to the folders that are displayed when a user accesses another user's Microsoft Office Outlook® 2003 mailbox. When users share access to an Outlook folder with other users, Exchange Server generates a view that hides private items.

When an Outlook user first views someone else's calendar, contact folder, or other data, the user may experience delays. After the user has viewed the folder, the user may experience quicker views on subsequent attempts, but after a period of time, the user may experience delays when the user tries to access the folder again. This delay is generally most noticeable when the folder contains a large number of items. A large number is 5,000 items or more.

The act of applying a view to a folder creates search folders in the Exchange store for each unique user who accesses the Outlook folder. When a search folder is created, it is cached for later use. Before Exchange Server creates a new search folder, it determines whether that search folder already exists. If the search folder exists, Exchange Server uses the cached search folder to accelerate subsequent viewings.

The msExchMaxCachedViews attribute defines how many search folders are cached in a specific folder. For example, the msExchMaxCachedViews attribute can define how many search folders are cached in the Calendar folder.

If you have many users who share Outlook folders, you must decide how to balance server resourcing and acceptable client performance. When a search folder is cached, a search folder is kept up-to-date as the data in the search folder changes. Such updates use CPU and disk resources. If multiple caches of the search folder are being maintained, CPU performance and disk performance are further impacted.

On the other hand, when Exchange Server creates a search folder for the first time, the user who accesses the Outlook folder may experience a delay as the search folder is built.

For example, consider an Exchange Server that is configured with 11 search folders. Eleven is the default number of search folders. UserA shares her Calendar folder with 15 other users. UserB accesses the folder and experiences a delay while his search folder is built. After the search folder for UserB is created, access to UserA's Calendar folder is quick. Assume UserB does not access the folder for the rest of the day. In the meantime, if 11 other users access the folder, unique search folders are created for them. Because only 11 search folders are cached, the next time UserB accesses UserA's Calendar, UserB again experiences a delay while a new search folder is built for him.

The best practice is to limit the maximum number of search folder caches to 20 or less. When you exceed this number, especially for folders that have more than 5,000 items in them, you may overload the server as the server attempts to maintain the cached folders.

Additionally, it is a best practice to have no less than five caches. If users are sharing Outlook folders with multiple users, caching only four search folders negatively affects client experience and causes the server to use more resources on creating new caches more often.

The msExchMaxCachedViews attribute also can be set on public folder databases. Search folders also are built for public folders. By default, public folders are shared resources that many users may access. If public folders receive many posts, you should minimize search folders because the Exchange Server may experience heavy CPU and disk use as it updates the search folders. Additionally, it is not a best practice to try to optimize the client experience by providing many search folder caches if many different users access a public folder. It is likely that these caches will be discarded as new search folders are created for new users.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To modify the msExchMaxCachedViews attribute

  1. Start the ADSI Edit tool from Microsoft Windows® 2000 Support Tools or from Windows Server 2003 Support Tools.

  2. Expand the following nodes:

    • Configuration Container

    • Configuration

    • Services

    • Microsoft Exchange

    • Organization_Name

    • Administrative Groups

    • Administrative_Group_Name

    • Servers

    • InformationStore

    • Storage_Group_Name

  3. In the details pane, right-click Database_Name, and then click Properties.

  4. In the Attributes box, double-click msExchMaxCachedViews.

  5. In the Integer Attribute Editor dialog box, enter an integer between 5 and 20 in the Value field, and then click OK.

  6. Click Apply, and then close ADSI Edit.

  7. Wait at least 15 minutes for replication, and then restart the Microsoft Exchange Information Store service on the Exchange server where you made the modification.


Maximum ESE cache has been manually changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-02-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchESEParamCacheSizeMax attribute for all mailbox store objects. If the Exchange Server Analyzer finds the value of the msExchESEParamCacheSizeMax attribute for any mailbox store to be more than 0 but less than 219727, a non-default configuration message is displayed.

In Exchange 2000 Server, a large area of the virtual memory used by STORE.EXE is allocated for the ESE buffer. Exchange 2000 Server uses a hard-coded default of 858 megabytes (MB) for this buffer. In Exchange Server 2003, ESE buffer allocation is based on the presence of the /3GB switch in the Boot.ini file. If the /3GB switch is present, the ESE buffer is tuned to 896 MB. If /3GB is not present, the ESE buffer is tuned to 576 MB. While auto-tuning is useful in every case, you may want to override the auto-tuning and manually set a value more appropriate for your environment. While you can tune this value to any multiple of 8192, it is recommended that you only use a value from the following table.

Recommended Value | Memory Allocated | Comments
147456 | 576 MB | This is the recommended minimum. Do not set the value any lower. This value is useful on virtual memory-constrained servers, and on Exchange Server 2003 computers that run on Microsoft Windows® 2000 Server, which does not support the /3GB switch. This is also the default value on systems that do not use the /3GB switch.
196608 | 768 MB | This value is recommended on servers with large amounts of virtual memory that log event 9582 frequently.
219726 | 858 MB | This is the default value in Exchange 2000 Server, and it is a good value to use on systems you are upgrading in-place that have large amounts of virtual memory.
229376 | 896 MB | This is the default value in Exchange Server 2003, and a good value to use on new systems unless your Application event log indicates otherwise with the presence of 9582 events.
311296 | 1.2 GB | This is the maximum value that you can set. This value should only be used on systems with 2 GB or more of physical memory.

Before you reconfigure this value, you should monitor the amount of virtual memory consumed by the STORE.EXE process. You can do this by monitoring the Process performance object in Windows. On systems with the /3GB switch, the Virtual Bytes counter for the STORE.EXE instance of the Process object should be less than 2.8 GB. On systems without the /3GB switch, it should be less than 1.8 GB. If the values are greater than these amounts, you may need to decrease the value for msExchESEParamCacheSizeMax. If the values are lower than this, you may need to increase the value for msExchESEParamCacheSizeMax.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To tune the msExchESEParamCacheSizeMax attribute

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Double-click the Configuration container.

  3. Expand CN=Services.

  4. Expand CN=Microsoft Exchange.

  5. Expand CN=<Exchange Organization Name>.

  6. Expand CN=Administrative Groups.

  7. Expand CN=<Administrative Group Name>.

  8. Expand CN=Servers.

  9. Expand CN=<Exchange Server Name>.

  10. Right-click CN=InformationStore, and then click Properties.

  11. In the attributes field, scroll to and then double-click msExchESEParamCacheSizeMax.

  12. In the Value field, type the value that you want to set. Use the table in this article to determine the optimal value for your system. Note that the value that you use must be a multiple of 8192.

  13. Click OK, and then click OK again.

  14. Close the Active Directory editor, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about optimizing memory usage, see the Microsoft Knowledge Base article 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372).

For more information about the msExchESEParamCacheSizeMax attribute, see the Knowledge Base article 266768, "XSTR: How to modify the Store Database maximum cache size" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768).


Maximum ESE Cache is set too high
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-02-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchESEParamCacheSizeMax attribute for all mailbox store objects. The Exchange Server Analyzer also queries the Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the VMLargestBlockSize key. The VMLargestBlockSize key represents the size (in bytes) of the largest available block of virtual memory.

Additionally, the Exchange Server Analyzer queries Active Directory to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer finds the value msExchESEParamCacheSizeMax to be more than 219726, and the value for VMLargestBlockSize to be more than 50000000 but less than 150000000 on an Exchange Server computer with more than 20 mailboxes, an error is displayed. This error indicates that the msExchESEParamCacheSizeMax attribute is set too high on this Exchange Server computer.

In Exchange 2000 Server, a large area of the virtual memory used by STORE.EXE is allocated for the ESE Buffer. Exchange 2000 Server uses a hard-coded default of 858 megabytes (MB) for this buffer. In Exchange Server 2003, the ESE buffer allocation is based on the presence of the /3GB switch in the Boot.ini file. If the /3GB switch is present, the ESE buffer is tuned to 896 MB. If /3GB is not present, the ESE buffer is tuned to 576 MB. While auto-tuning is good across the board, you may want to override the auto-tuning and manually set a value more appropriate for your environment. While you can tune this value to any multiple of 8192, it is recommended that you use only a value from the following table.

Recommended Value | Memory Allocated | Comments
147456 | 576 MB | This is the recommended minimum. Do not set the value any lower. This value is useful on virtual memory-constrained servers, and on Exchange Server 2003 computers that run on Microsoft Windows 2000 Server, which does not support the /3GB switch. This is also the default value on systems that do not use the /3GB switch.
196608 | 768 MB | This value is recommended on servers with large amounts of virtual memory that log event 9582 frequently.
219726 | 858 MB | This is the default value in Exchange 2000 Server, and it is a good value to use on systems you are upgrading in-place that have large amounts of virtual memory.
229376 | 896 MB | This is the default value in Exchange Server 2003, and a good value to use on new systems unless your Application event log indicates otherwise with the presence of 9582 events.
311296 | 1.2 GB | This is the maximum value that you can set. This value should only be used on systems with 2 GB or more of physical memory.

Before you reconfigure this value, you should monitor the amount of virtual memory consumed by the STORE.EXE process. You can do this by monitoring the Process performance object in Windows. On systems with the /3GB switch, the Virtual Bytes counter for the STORE.EXE instance of the Process object should be less than 2.8 GB. On systems without the /3GB switch, it should be less than 1.8 GB. If the values are more than these amounts, you may need to decrease the value for msExchESEParamCacheSizeMax. If the values are lower than this, you may want to increase the value for msExchESEParamCacheSizeMax.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To tune the msExchESEParamCacheSizeMax attribute

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Double-click the Configuration container.

  3. Expand CN=Services.

  4. Expand CN=Microsoft Exchange.

  5. Expand CN=<Exchange Organization Name>.

  6. Expand CN=Administrative Groups.

  7. Expand CN=<Administrative Group Name>.

  8. Expand CN=Servers.

  9. Expand CN=<Exchange Server Name>.

  10. Right-click CN=InformationStore, and then click Properties.

  11. In the attributes field, scroll to and then double-click msExchESEParamCacheSizeMax.

  12. In the Value field, type the value that you want to set. Use the table to determine the optimal value for your system. Note that the value you use must be a multiple of 8192.

  13. Click OK, and then click OK again.

  14. Close the Active Directory editor, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about optimizing memory usage, see the Microsoft Knowledge Base article 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372).

For more information about the msExchESEParamCacheSizeMax attribute, see the Knowledge Base article 266768, "XSTR: How to modify the Store Database maximum cache size" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768).


Maximum ESE cache size increased
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-02-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchESEParamCacheSizeMax attribute for all mailbox store objects.

The Exchange Server Analyzer also queries the Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the VMLargestBlockSize key. The VMLargestBlockSize key represents the size (in bytes) of the largest available block of virtual memory.

Additionally, the Exchange Server Analyzer queries Active Directory to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer finds the value msExchESEParamCacheSizeMax to be more than 219726, and the value for VMLargestBlockSize is not within the following values on Exchange Server computer with more than 20 mailboxes, a warning is displayed:

  • Greater than 50000000 and less than 150000000

  • Greater than 0 and less than 50000001

This warning indicates that the msExchESEParamCacheSizeMax attribute has been increased on this Exchange Server computer, and may cause low virtual memory conditions.

In Exchange 2000 Server, a large area of the virtual memory used by STORE.EXE is allocated for the ESE buffer. Exchange 2000 Server uses a hard-coded default of 858 megabytes (MB) for this buffer. In Exchange Server 2003, ESE buffer allocation is based on the presence of the /3GB switch in the Boot.ini file. If the /3GB switch is present, the ESE buffer is tuned to 896 MB. If /3GB is not present, the ESE buffer is tuned to 576 MB. While auto-tuning is useful in every case, you may want to override the auto-tuning and manually set a value more appropriate for your environment. While you can tune this value to any multiple of 8192, it is recommended that you only use a value from the following table:

Recommended Value | Memory Allocated | Comments
147456 | 576 MB | This is the recommended minimum. Do not set the value any lower. This value is useful on virtual memory-constrained servers, and on Exchange Server 2003 computers that run on Microsoft Windows 2000 Server, which does not support the /3GB switch. This is also the default value on systems that do not use the /3GB switch.
196608 | 768 MB | This value is recommended on servers with large amounts of virtual memory that log event 9582 frequently.
219726 | 858 MB | This is the default value in Exchange 2000 Server, and it is a good value to use on systems you are upgrading in-place that have large amounts of virtual memory.
229376 | 896 MB | This is the default value in Exchange Server 2003, and a good value to use on new systems unless your Application event log indicates otherwise with the presence of 9582 events.
311296 | 1.2 GB | This is the maximum value that you can set. This value should only be used on systems with 2 GB or more of physical memory.

Before you reconfigure this value, you should monitor the amount of virtual memory consumed by the STORE.EXE process. You can do this by monitoring the Process performance object in Windows. On systems with the /3GB switch, the Virtual Bytes counter for the STORE.EXE instance of the Process object should be less than 2.8 GB. On systems without the /3GB switch, it should be less than 1.8 GB. If the values are greater than these amounts, you may need to decrease the value for msExchESEParamCacheSizeMax. If the values are lower than this, you may need to increase the value for msExchESEParamCacheSizeMax.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To tune the msExchESEParamCacheSizeMax attribute

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Double-click the Configuration container.

  3. Expand CN=Services.

  4. Expand CN=Microsoft Exchange.

  5. Expand CN=<Exchange Organization Name>.

  6. Expand CN=Administrative Groups.

  7. Expand CN=<Administrative Group Name>.

  8. Expand CN=Servers.

  9. Expand CN=<Exchange Server Name>.

  10. Right-click CN=InformationStore, and then click Properties.

  11. In the attributes field, scroll to and then double-click msExchESEParamCacheSizeMax.

  12. In the Value field, type the value that you want to set. Use the table in this article to determine the optimal value for your system. Note that the value that you use must be a multiple of 8192.

  13. Click OK, and then click OK again.

  14. Close the Active Directory editor, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about optimizing memory usage, see the Microsoft Knowledge Base article 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372).

For more information about the msExchESEParamCacheSizeMax attribute, see the Knowledge Base article 266768, "XSTR: How to modify the Store Database maximum cache size" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768).


MaxOpenMessagesPerLogon has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-05-14

The Microsoft Exchange Analyzer Tool reads the following registry entry to determine whether the MaxOpenMessagesPerLogon registry value is present and configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Analyzer finds the MaxOpenMessagesPerLogon registry value present and configured to have a value more than 0, a nondefault configuration message is displayed.

Every time that a MAPI client or application opens a message on an Exchange Server computer, it causes the Microsoft Exchange Information Store service (store.exe) to consume a small amount of physical memory. When the message is closed by the Microsoft Office Outlook 2003 or Outlook 2007 clients, the memory is released. To prevent one or more MAPI clients from causing the Exchange store service to continuously allocate memory, a new configuration feature was introduced in Exchange 2000 Server Service Pack 1 (SP1) that lets an administrator limit the number of messages each MAPI client logon session can open simultaneously. Setting such a limit may be useful in your environment if certain client applications unintentionally open many messages, thereby affecting overall server performance.

This feature is implemented by using the MaxOpenMessagesPerLogon registry value on the Exchange Server computer. We recommend that a limit no more than 1000 be set. A value of 1,000 allows each client to use approximately 4 to 6 megabytes (MBs) of memory. For some environments, a smaller value of 500 may be more appropriate.

Important:
This article contains information about how to edit the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure a maximum number of simultaneously opened messages

  1. Open a registry editor, such a Regedit.exe or Regedt32.exe.

  2. Open:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Right-click ParametersSystem, select New | DWORD Value, and give the new value a name of MaxOpenMessagesPerLogon.

  4. In the right pane, double-click the MaxOpenMessagesPerLogon value, and then enter the maximum number of simultaneously open messages, in decimal.

  5. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the MaxOpenMessagesPerLogon registry value, see Microsoft Knowledge Base article 289109, "XADM: How to Limit the Number of Messages Opened for Each MAPI Logon" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=289109).


The maximum number of databases per storage group has been manually changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchMaxStoresPerGroup attribute of each storage group. If the Exchange Server Analyzer finds that the value of the msExchMaxStoresPerGroup attribute for any storage group does not equal 5, an error is displayed.

This value applies to all storage groups on the server. This particular error arises if the value of this attribute has been changed from its default of 5. This is the only value supported, and should never be changed. Exchange Server does not function correctly if this value is increased.

You must correct the value using a tool such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=<ExchangeOrganizationName>.

  3. Expand CN=Administrative Groups, expand CN=<AdministrativeGroupName>, and then expand CN=Servers.

  4. Expand CN=<ServerName>, right-click CN=InformationStore, and then click Properties.

  5. In the Attribute Editor, click the msExchMaxStoresPerGroup attribute, and then click Edit.

  6. In the Edit Attribute box, set the value to 5.

  7. Click Apply, and then click OK.

  8. Close ADSI Edit, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about the allowed maximum number of storage groups, see the Knowledge Base article 251123, "XADM: Maximum Number of Storage Groups in Exchange 2000 for Database Capacity Planning" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=251123).

For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in the Windows Server Help.


The maximum number of storage groups has been manually changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchMaxStorageGroups attribute of each InformationStore container. If the Exchange Server Analyzer determines that the value for any msExchMaxStorageGroups attribute does not equal 4, an error is displayed.

The only value supported for the msExchMaxStorageGroups attribute is 4, and this value should never be changed. Exchange does not function correctly if this value is modified.

You must correct the value using an Active Directory editor, such as the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP (ldp.exe) tool, or any other Lightweight Directory Access Protocol (LDAP) version 3 client.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Using ADSI Edit or a similar tool, locate the InformationStore object for this server in Active Directory.

    The msExchMaxStorageGroups attribute can be found at:

    CN=Configuration,DC=Domain,CN=com, CN=Services, CN=Microsoft Exchange, CN= OrganizationName , CN=Administrative Groups, CN= AdminGroupName , CN=Servers, CN= ServerName , CN=InformationStore

  2. Edit the msExchMaxStorageGroups attribute by entering 4 as the new value.

  3. Close the Active Directory editor, and then restart the Exchange Server computer for the change to take effect.

For more information about using the LDP tool, see the Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).


Maximum open folder objects per logon has been changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the default maximum number of folders that can be opened per MAPI session has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession\objtFolder

If the Exchange Server Analyzer finds the objtFolder registry value present and configured with any value other than 500, a non-default configuration message is displayed.

When manually added and configured, the objtFolder registry value determines the maximum number of folders that can be opened per MAPI client. By default, Exchange Server 2003 and Exchange Server 2007 limit the number of open folders to 500. When a MAPI client attempts to open more than 500 folders, the following event is logged in the application event log on the Exchange Server computer containing the client's mailbox:

Event Type: | Error
Event ID: | 9646
Event Source: | MSExchangeIS
Event Category: | General
Description: | Closing Mapi session "/o=OrganizationName/ou=AdministrativeGroupName/cn=Recipients/cn=UserName" because it exceeded the maximum of 500 objects of type "objtFolder".

The objtFolder registry value represents a configuration opportunity that provides the administrator with a greater level of control over the Exchange Server resources used by MAPI clients.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession.

  3. Delete the objtFolder registry value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

  5. Alternatively, if you wish to make use of the objtFolder registry value, instead of deleting it, keep it set to its existing value or adjust it as needed.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information, see the Knowledge Base article 830829, "Your Exchange Server 2003 computer may stop responding after a MAPI client opens more than the default value of certain server objects" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830829).


Maximum open folder views per logon has been changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default maximum number of folder views that can be opened per MAPI session has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession\objtFolderView

If the Exchange Server Analyzer finds the objtFolderView registry value present and configured with any value other than 500, a non-default configuration message is displayed.

When manually added and configured, the objtFolderView registry value determines the maximum number of folder views that can be opened per MAPI client. By default, Exchange Server 2003 and Exchange Server 2007 limit the number of open folder views to 500. When a MAPI client tries to open more than 500 folder views, the following event is logged in the application event log on the Exchange Server computer that contains the client's mailbox:

Event Type: Error

Event Source: MSExchangeIS

Event Category: General

Description: Closing Mapi session "/o= OrganizationName /ou= AdministrativeGroupName /cn=Recipients/cn= UserName " because it were greater than the maximum of 500 objects of type "objtFolderView".

The objtFolderView registry value represents a configuration opportunity that provides an administrator with a greater level of control over the Exchange Server resources used by MAPI clients.

Important:
This article contains information about how to edit the registry. Before you edit the registry, make sure that you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession.

  3. Delete the objtFolderView registry value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

  5. Alternatively, if you want to use the objtFolderView registry value, instead of deleting it, keep it set to its existing value, or adjust it as needed.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information, see Microsoft Knowledge Base article 830829, "Your Exchange Server 2003 computer may stop responding after a MAPI client opens more than the default value of certain server objects" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830829).


Maximum open message objects per logon has been changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default maximum number of open messages per MAPI session has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession\objtMessage

If the Exchange Server Analyzer finds the objtMessage registry value present and configured with any value other than 250, a non-default configuration message is displayed.

When manually added and configured, the objtMessage registry value determines the maximum number of open messages per MAPI client. By default, Exchange Server 2003 and Exchange Server 2007 limit the number of open messages to 250. When a MAPI client attempts open more than 250 messages, the following event is logged in the application event log on the Exchange Server computer that contains the client's mailbox:

Event Type: Error

Event ID: 9646

Event Source: MSExchangeIS

Event Category: General

Description: Closing Mapi session "/o= OrganizationName /ou= AdministrativeGroupName /cn=Recipients/cn= UserName " because it exceeded the maximum of 250 objects of type "objtMessage".

The objtMessage registry value represents a configuration opportunity that provides an administrator with a greater level of control over the Exchange Server resources used by MAPI clients.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession.

  3. Delete the objtMessage registry value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

  5. Alternatively, if you want to use the objtMessage registry value, instead of deleting it, keep it set to its existing value, or adjust it as needed.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information, see the Knowledge Base article 830829, "Your Exchange Server 2003 computer may stop responding after a MAPI client opens more than the default value of certain server objects" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830829).


Maximum Polling Frequency is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether the polling interval for Microsoft Office Outlook® 2003 and Outlook 2007 clients that access Exchange Server 2003 or Exchange Server 2007 using RPC over HTTP has been modified from its default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ Maximum Polling Frequency

If the Exchange Server Analyzer finds that the Maximum Polling Frequency key is present and configured with a value more than 0, a non-default configuration message is displayed.

When it makes its initial connection to an Exchange server, Outlook registers itself for new message notifications. Whenever a new message is received in an Outlook user's mailbox, Exchange sends a notification to Outlook using User Datagram Protocol (UDP). When Outlook receives this notification, it retrieves the message from the Exchange server and displays it in the appropriate folder. If Outlook does not receive new mail notifications, it reverts to polling the Exchange server. Although polling is initiated by Outlook, polling frequency is dictated by the Exchange server.

By default, Outlook 2003 polls every 60 seconds. You can change the frequency by adding the Maximum Polling Frequency registry entry to the Exchange server that contains the user's mailbox. The value you enter is the minimum number of milliseconds between polling intervals. If Maximum Polling Frequency is not present, a default value of 60 seconds (60,000 milliseconds) is used. This default value does not mean that polling occurs every 60 seconds. Rather, the value means that polling will occur any time between the polling frequency interval and two times that interval. For example, assume that Maximum Polling Frequency is set to 90 seconds. In that example, polling occurs between 90 and 180 seconds after the last poll.

You should not reduce the value below the default value of 60 seconds because doing this will degrade performance for Exchange, Outlook, and the network. You may not need to adjust this value because many user actions will check for new messages as part of internal operations. For example, if a user switches between folders or opens a message, new items on the server will be displayed. This outcome occurs because when Outlook sends necessary RPC requests to Exchange to effect the user action, the new message flag is checked and, if present, the new message notification is included in the RPC response sent back to Outlook.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the Maximum Polling Frequency registry value.

  4. Restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about RPC over HTTP, see the Exchange Server 2003 RPC over HTTP Deployment Scenarios guide (http://go.microsoft.com/fwlink/?LinkId=47577).


Minimum ESE cache has been manually changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-01-16

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchESEParamCacheSizeMin attribute for all mailbox store objects. If the Exchange Server Analyzer finds the value of the msExchESEParamCacheSizeMin attribute for any mailbox store to be more than 0, a non-default configuration message is displayed.

The Microsoft Exchange Information Store service uses the Extensible Storage Engine (ESE) cache as a buffer when writing store data to disk. Exchange 2000 Server uses a maximum cache size of 858 MB. Exchange Server 2003 dynamically determines the default value for the msExchESEParamCacheSizeMin property, based on the amount of physical random access memory (RAM) that is installed in the server.

For example, the maximum cache size for an Exchange Server 2003 computer that has the /3GB switch set in its boot.ini file is 896 MB. If the computer does not have the /3GB switch set, the maximum cache size is 576 MB.

You can use the following information to restore the msExchESEParamCacheSizeMin property to its original value:

  • If Exchange Server 2003 is running on Microsoft Windows Server™ 2003 and the server has 2 GB or more of RAM, msExchESEParamCacheSizeMin will be 131072 (512 MB).

  • If Exchange Server 2003 is running on Windows Server 2003 and the server has 768 MB or more but less than 2 GB of RAM, msExchESEParamCacheSizeMin will equal "RAM/4*(4*1024)".

  • If Exchange Server 2003 is running on Windows Server 2003 and the server has less than 768 MB of RAM, msExchESEParamCacheSizeMin will equal "RAM/8*(4*1024)".

For example:

  • Windows Server 2003 with 512 MB of RAM will have a default value for msExchESEParamCacheSizeMin of 16384 (4 KB pages).

  • Windows Server 2003 with 1 GB of RAM will have a default value for msExchESEParamCacheSizeMin of 65536 (4 KB pages).

  • Windows Server 2003 with 4 GB of RAM will have a default value for msExchESEParamCacheSizeMin of 131072 (4 KB pages).

  • If Exchange Server 2003 is running on Microsoft Windows® 2000 Server, no default value is set for msExchESEParamCacheSizeMin.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Windows Server 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this warning

  1. Open an Active Directory editor, such as ADSI Edit.

  2. Double-click the Configuration container.

  3. Expand CN=Services.

  4. Expand CN=Microsoft Exchange.

  5. Expand CN=<Exchange Organization Name>.

  6. Expand CN=Administrative Groups.

  7. Expand CN=<Administrative Group Name>.

  8. Expand CN=Servers.

  9. Expand CN=<Exchange Server Name>.

  10. Right-click CN=InformationStore, and then click Properties.

  11. In the attributes field, scroll to and then double-click msExchESEParamCacheSizeMin.

  12. In the Value field, type the value that you want to set. You can use the default formula and edit it for your situation. The value that you use must be a multiple of 32 MB.

  13. Click OK, and then click OK again.

  14. Close the Active Directory editor, and then restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about tuning the msExchESEParamCacheSizeMin attribute, see the Microsoft Knowledge Base article 822894, "Jet Database Does Not Work Correctly During a Backup or During a Content Indexing Operation" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822894).


The number of threads for the store process is high
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Process Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the ThreadCount for the Exchange information store process. This value represents the number of active store threads on the server. If there are more than 400 active store threads, a warning message is displayed.

The most common cause of this problem is incompatible antivirus software running on the same computer.

To correct this warning

  1. Check with your vendor to be sure that you are running up-to-date and Exchange-compatible antivirus software.

  2. Update your antivirus software.

For more information about antivirus software and Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).


OAB Bandwidth Threshold (KBps) registry parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether the OAB Bandwidth Threshold (KBps) registry key has been created:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

If the Exchange Server Analyzer finds that the OAB Bandwidth Threshold (KBps) registry key has been created under ParametersSystem, the Exchange Server Analyzer displays a non-default configuration message.

In Microsoft Exchange Server 2003 Service Pack 1 (SP1), the administrator can set and configure the OAB Bandwidth Threshold (KBps) registry key to override the default functionality and to limit the bandwidth that is used for full downloads of an offline address book from a particular public store.

By default, every client request for a full download of an offline address book is served immediately. Also, the public store does not limit the number of concurrent full downloads of offline address books. The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required. However, you can delete the OAB Bandwidth Threshold (KBps) registry key if you want to restore the default configuration.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the OAB Bandwidth Threshold (KBps) value.

  4. Close the registry editor.

The Microsoft Exchange Information Store service detects the changes in minutes. You do not have to restart the computer.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about throttling the bandwidth consumed during offline address book downloads, see the Knowledge Base article 867623, "Throttling full offline Address Book downloads to limit the effect on a LAN in Exchange Server 2003," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=867623).


Offline address book is not associated with a particular mailbox store
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchUseOAB attribute in the msExchPrivateMDB class has been configured to use a specific offline address book for a particular mailbox store on a database. The msExchPrivateMDB class determines the configuration on a private database. The msExchUseOAB attribute determines the specific offline address book that a particular mailbox store uses. If the Exchange Server Analyzer finds that the offline address book for the mailbox store on the database is missing, the Exchange Server Analyzer displays an error message.

In Exchange 2000 Server and later versions, an offline address list is associated with all the users who are contained in an information store. You cannot automatically associate an offline address list with a particular mailbox or override the global offline address list settings for the information store or storage group.

To associate an offline address list with a particular mailbox, you must first create an offline address list that contains a filtered copy of the global address list. Then you must associate the offline address list with a particular mailbox by using Active Directory Service Interfaces (ADSI) Edit or another Lightweight Directory Access Protocol (LDAP) version 3 client to set the msExchUseOAB attribute to the full distinguished name of the offline address list.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another LDAP version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.

For detailed instructions about how to associate an offline address book with a particular mailbox, see the Microsoft Knowledge Base article 275203, "Offline Address Book Cannot Be Associated with a Particular Mailbox" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=275203).

To learn more about offline address books, see the Offline Address Book Best Practices Guide (http://go.microsoft.com/fwlink/?LinkId=47583).


OLD Completion Time for a public folder store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the start delay for online defragmentation has been changed from its default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>\OLD Completion Time

If the Exchange Server Analyzer finds that the OLD Completion Time key is present, a non-default configuration message is displayed. The OLD Completion Time key specifies the period of time in seconds that online defragmentation runs after the information store maintenance window. The default value is 1 hour (3600 seconds).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>

  3. Delete the OLD Completion Time key.

  4. Close the registry editor, and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


OLD Minimum RunTime for a public folder store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the minimum run time for online defragmentation has been modified from its default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>\OLD Minimum RunTime

If the Exchange Server Analyzer finds that the OLD Minimum RunTime key is present, a non-default configuration message is displayed. The OLD Minimum RunTime key specifies the minimum period of time in seconds that online defragmentation runs.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>

  3. Delete the OLD Minimum RunTime key.

  4. Close the registry editor, and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Online defragmentation has been disabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchESEParamEnableOnlineDefrag attribute on each storage group object. A value of True indicates that online database maintenance will occur according to the configured schedule. A value of False indicates that online maintenance will not occur. If the Exchange Server Analyzer finds the value for the msExchESEParamEnableOnlineDefrag attribute set to False, an error is displayed.

Online database maintenance, including defragmentation, in Exchange Server is very important. During this interval, tasks like dumpster cleanup (deletion of messages that have passed their deleted item retention date), public folder expiry (messages in public folders that are older than a certain date are expired), deleted mailbox cleanup, online defragmentation (database objects that are no longer being used are detected and removed, thereby making additional database space available) and so on, are performed. These processes help keep the Exchange server healthy and performance stable. Online database maintenance should not be set to Never Run because this can cause performance to degrade over time.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.

To correct this error

  1. Click Start, Run, type MMC, and then click OK.

  2. In the Microsoft Management Console (MMC), click File, and then click Add/Remove Snap-in.

  3. In the list of Available Standalone Snap-ins, select ADSI Edit and click Add, and then click Close. Click OK in the Add/Remove Snap-in box.

  4. Right click ADSI Edit, and then click Connect to. In the Select a well known Naming Context list dialog box, select Configuration, and then click OK.

  5. Expand the Configuration Container, CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=<OrganizationName>, CN=Administrative Groups, CN=<AdminGroupName>, CN=Servers, CN=<ServerName>, CN=Information Store.

  6. Right-click CN=<StorageGroupName>, and then click Properties.

  7. In the Storage Group Properties dialog box, select msExchESEParamEnableOnlineDefrag from the list of attributes and click Edit, and change the value to True.

  8. Close ADSI Edit and restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about online database maintenance, see the following Exchange resources:

  • Microsoft Knowledge Base article 314214, "How to set maintenance intervals in data stores in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=314214).

  • Exchange Server 2007 Insider Article "Exchange Store Maintenance" (http://go.microsoft.com/fwlink/?LinkId=80787).


Preferred backfill source enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether the Preferred Backfill Source key has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>\Preferred Backfill Source

By default, Preferred Backfill Source does not exist. If the Exchange Server Analyzer finds Preferred Backfill Source to be present, a non-default configuration message is displayed.

Backfilling occurs when a public folder store determines that it has not received all the updates for a replicated folder (or for the hierarchy) and must retrieve the missing updates from another store.

To streamline the backfill process, Exchange Server stores information about missing updates in the backfill array.

The backfill array stores this information for a specified length of time (called the backfill time-out). If the missing updates arrive in subsequent replication messages during this time, they are removed from the backfill array. The table lists the default backfill time-out values, which depend on where the missing updates exist and whether they have been requested before.

Type of request | Content exists on a store in the local site | Content exists on a store in a remote site
Initial backfill | 6 hours | 12 hours
First backfill retry | 12 hours | 24 hours
Subsequent backfill retries | 24 hours | 48 hours

If the backfill time-out expires and the updates are still missing, Exchange Server 2003 creates one or more backfill requests and determines which servers to use as backfill sources.

To select a server (or servers) to use as a backfill source, Exchange Server 2003 first creates a list of all of the servers that have replicas of the folder, and then sorts the list according to the following sequence of criteria:

  • Sort according to server status. Servers that are down or unavailable drop to the end of the list.

  • Sort according to preferred backfill server. (if any; this feature is available only in Exchange Server 2003 and later). Exchange Server 2003 checks the public folder store object in the Active Directory® directory service for a preferred backfill server. This setting is seldom used. In most circumstances, the backfill process operates most efficiently if Exchange Server 2003 selects a backfill server automatically. Most deployments of Exchange Server 2003 do not need a preferred backfill server. Microsoft Product Support Services can provide a script that sets a preferred backfill server if your deployment requires it.

  • Sort according to transport cost (lowest to highest). Servers in the same site have priority over servers in remote sites. The transport cost of a server is calculated by the Exchange Server 2003 routing engine, and is normally used to calculate the most efficient way to deliver a message. Note that in versions of Exchange prior to Exchange Server 2003, transport cost has lower priority and is only considered after Exchange version and number of available changes.

  • Sort according to Exchange version (newest to oldest).

  • Sort according to the number of necessary changes that are available on the server (largest to smallest). Servers that do not have any of the missing changes are dropped from the list.

If one server does not have all the needed changes, Exchange Server 2003 selects the next server in the sorted list and sends a backfill request to that server also. This process is repeated until all the changes have been requested. This feature is only available in Exchange Server 2003 and later; versions of Exchange send backfill requests to one server at a time if no single server holds all of the missing updates for a specific folder. After each request, previous versions of Exchange wait for the retry time-out (from 24 through 48 hours) to elapse before sending the next request.

If the selected server does not respond to the backfill request, the store marks that server as down and repeats the selection process. Servers marked down drop to the end of the list.

Most of the time, your topology will operate efficiently if you allow Exchange Server to automatically select backfill servers. For troubleshooting purposes, Microsoft Product Support Services may recommend setting Preferred Backfill Source. However, you should only use it when necessary to resolve a specific problem.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To reset the Preferred Backfill Source registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>

  3. Examine or edit the value for Preferred Backfill Source.

    The value for this registry entry is in kilobytes (KB). To return to the default value, you should delete Preferred Backfill Source and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Preferred Public Folder backfill source has been enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Exchange has been configured with a preferred backfill source for the public folder hierarchy:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<Server name>\Public-<Public Information Store GUID>\Preferred Backfill Source

If the Exchange Server Analyzer finds the Preferred Backfill Source registry entry present and configured, a non-default configuration message is displayed.

Exchange Server 2003 introduces a new Active Directory® directory service attribute named msexchPreferredBackfillSource that can be used to designate which Exchange Server should receive backfill request messages.

When a public folder has to replicate content, it sends out a query to the Exchange organization for a backfill request. The first public folder server to respond is used to backfill the data. This logic assumes that the first public folder server to respond is the closest; however, this may not always be the case. A configuration opportunity was introduced in Exchange Server 2003 that lets an administrator specify a preferred server for backfill.

In Exchange Server 2003, you can set the preferred server to use for backfilling public folder hierarchy and content using either an Active Directory attribute or the Preferred Backfill Source registry entry on the public folder server. The Active Directory parameter is checked first. If it is null, the registry parameter is checked. If that is also nonexistent, the default algorithm for public folder backfill is used.

To use the Active Directory attribute, set the Distinguished Name (DN) of the required backfill public folder store in the msExchPreferredBackfillSource attribute on the public folder store objects.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

If you choose to edit the msExchPreferredBackfillSource attribute in Active Directory, you will need to use an Active Directory editor such as Active Directory Service Interfaces (ADSI) Edit or the LDP (ldp.exe) tool.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To specify a preferred public folder backfill source in the registry

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<Server name>\Public-<Public Information Store GUID>

  3. Examine, and if desired, change the Preferred Backfill Source value. The value that should be entered is the Distinguished Name (DN) of the Exchange public folder store that you prefer to source from.

  4. If a change is made, dismount and remount the public information store for the change to take effect.

To specify a preferred public folder backfill source in Active Directory

  1. Modify the affected Public Folder Store object's value for msExchPreferredBackfillSource to point to the desired backfill source. The msExchPreferredBackfillSource attribute can be found at: CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=OrganizationName, CN=Administrative Groups, CN=AdministrativeGroupName, CN=Servers, CN=ServerName, CN=InformationStore, CN=StorageGroupName, CN=Public Folder Store

  2. The value that should be entered is the Distinguished Name (DN) of the Exchange public folder store that you prefer to source from.

  3. If a change is made, dismount and remount the public information store for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about modifying Active Directory with the LDP tool, see the Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260745).


Provide More Disk Space
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool has determined that disk space on the computer that is running Exchange Server is below acceptable levels. The Exchange Server Analyzer measures available disk space to verify that it is within an acceptable range. If the tool finds that disk space is below acceptable levels, it displays an error message. It is recommended that all disks in computers that are running Exchange Server contain mailboxes that have at least 10 percent of their capacity free at all times.

The Exchange Server Analyzer tests the following drives:

  • Database drive

  • Temp drive

  • MailRoot drive

  • STM drive

  • System drive

  • Log drive

    Note:
    The state table calls for the log drive size to be increased and the logs to be archived.
  • Page drive

To correct this error

  1. To free up disk space, delete unnecessary files from the disk.

  2. If the disk that has less than 10 percent space free contains data that can be safely moved to another disk (such as mailboxes or the Microsoft Windows® pagefile), perform the steps that are required to move the data.

  3. Add disk capacity to the computer that is running Exchange Server.

  4. Reduce the mailbox size or move users to another server.

For More Information

  • For more information about moving mailboxes with Exchange Server 2003, see Microsoft Knowledge Base article 821829 "Moving Mailboxes in Exchange Server 2003," (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829).

  • For more information about moving mailboxes between Exchange 2000 Server and Exchange 5.5 Server, see Microsoft Knowledge Base article 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810).

  • For more information about setting mailbox limits with system policies on Exchange Server 2003, see Microsoft Knowledge Base article 822938, "HOW TO: Use System Policies to Configure Mailbox Storage Limits in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822938).

  • For more information about setting mailbox limits with system policies on Exchange 2000 Server, see Microsoft Knowledge Base article 319130, "HOW TO: Use System Policies to Configure Mailbox Storage Limits in Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319130).

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about best practices for designing storage architectures, see Best Practices Common to Multiple Architectures (http://go.microsoft.com/fwlink/?LinkId=72988).

  • For more information about disk sizing, latency, and I/O rates, see How to Calculate Your Disk I/O Requirements (http://go.microsoft.com/fwlink/?linkid=69747).


Public folder store database file stored on network drive
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchEDBFile attribute of each public folder store object. This attribute specifies the location of the database files used by this public folder store.

The Exchange Server Analyzer also queries Active Directory to determine the count of the values listed in the homeMDBBL attribute of each mailbox store on this server. The count of this attribute represents the number of mailboxes on the mailbox store. The Exchange Server Analyzer can then calculate the total number of mailboxes managed by the server.

If the Exchange Server Analyzer finds that the msExchEDBFile attribute starts with \\ on an Exchange Server with more than 50 mailboxes, an error is displayed.

This error indicates that the database files for the public folder store are being stored on a network share. If the msExchEDBFile attribute starts with \\, it indicates that the log file path uses a Universal Naming Convention (UNC) path. This is not a recommended practice as interruptions in network connectivity could cause database errors, resulting in lost data or corrupted databases. It is recommended that you correct this problem as soon as possible.

To move the database files to a new drive

  1. In Exchange System Manager, expand the Exchange server object on which the store resides, expand the appropriate storage group container, right-click the public folder store object that you want, and then click Properties.

  2. Specify new file locations on the Database tab of the Properties dialog box.

For more information about Exchange Server database files, see the following topics:

  • "Managing Mailbox Stores and Public Folder Store" in Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617)

  • "Understanding the Exchange Server 2003 Store" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595)

For more information about using Exchange Server with network drives, see the following Microsoft Knowledge Base articles:

  • 328879, "Using Exchange Server with Storage Attached Network and network-attached storage devices" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328879)

  • 839687, "Microsoft support policy on the use of network-attached storage devices with Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=839687)

  • 317173, "Exchange Server and network-attached storage" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317173)

  • 317172, "Exchange Server 5.5 and network-attached storage" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317172)


Public Folder Store Database size limit has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Database Size Limit in Gb registry value is present and configured for the public folder store:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<Server_Name>\Public-<MailboxStoreGUID>

If the Exchange Server Analyzer finds that the Database Size Limit in Gb value is present and configured, the Exchange Server Analyzer displays a non-default configuration message.

When Exchange Server 2003 Service Pack 2 (SP2) is applied to Exchange Server 2003 Standard Edition, the hard-coded licensing database size limit is increased from 16 gigabytes (GB) to 75 GB. You can set a protective database size limit to prevent unintentional database size growth. The default size limit value in SP2 is 18 GB, and this default value can be overwritten by creating the Database Size Limit in Gb registry value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<MailboxStoreGUID>

  3. Delete the Database Size Limit in Gb value.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site (http://go.microsoft.com/fwlink/?LinkId=52073).


Public folder store has not had a full backup in more than 8 days
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the public folder store to determine the date and time of the last full backup. If the Exchange Server Analyzer finds that the number of days since the last full backup for a public folder store is greater than eight, the Exchange Server Analyzer displays a warning.

The public folder store holds information associated with a particular public folder tree, such as how the tree is structured and what folders the tree contains. It also holds public folder content. A public folder store is made up of a rich-text .edb file, and a streaming native Internet content .stm file.

The mailbox store and public folder store data in your Exchange Server databases and transaction log files are the most important data to back up in your Exchange Server organization. You can use an Exchange Server database backup to restore a damaged public folder store to a functioning server that is running Exchange Server. You can also use Exchange Server database backups to restore your Exchange Server databases to a different server.

As a best practice, you should perform a full backup of your database files and transaction logs every day. After you complete a full backup of a storage group, the committed transaction log files on the Exchange Server databases are deleted from the server. A full backup provides the advantage of speed in a recovery scenario, because you need only one tape set to restore all data.

Note:
It is a best practice to keep transaction log files on a dedicated disk separate from the database files. This provides fault tolerance in case the database disk is destroyed, and in some cases, improves database performance.
Important:
You must have the required permissions or rights assigned to the user account that you are logged into when you try to back up or restore files and folders. To create Exchange Server backups, you must have domain level backup operator rights. To create backups of your Microsoft Windows Server™ 2003 operating system, you must have at least local backup operator rights.

The backup strategy that you choose for your Exchange Server data will depend on the size of the stores, the speed of backup software and hardware, hardware capacity, and time requirements.

For more information about backup strategies as well as disaster recovery operations, see:

  • Exchange Server 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?linkid=47570).

  • Database Backup and Restore (http://go.microsoft.com/fwlink/?LinkID=80766).


Public folder store has not had a full backup in more than 60 days
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the public folder store to determine the date and time of the last full backup. If the Exchange Server Analyzer finds that the number of days since the last full backup for a public folder store is greater than 60, the Exchange Server Analyzer displays an error.

The public folder store holds information that is associated with a particular public folder tree, such as how the tree is structured and what folders the tree contains. The public folder store also holds public folder content. A public folder store is made up of a rich-text .edb file, and a streaming native Internet content .stm file.

The mailbox store data and public folder store data in your Exchange Server databases and transaction log files are the most important data to back up in your Exchange Server organization. You can use an Exchange Server database backup to restore a damaged public folder store to a functioning server that is running Exchange Server. You can also use Exchange Server database backups to restore your Exchange Server databases to a different server.

As a best practice, you should perform a full backup of your database files and transaction logs every day. After you complete a full backup of a storage group, the committed transaction log files on the Exchange Server databases are deleted from the server. A full backup provides the advantage of speed in a recovery scenario, because you need only one tape set to restore all data.

Note:
It is a best practice to keep transaction log files on a dedicated disk separate from the database files. Not only does this best practice improve database performance, but it also provides fault tolerance in case the database disk is destroyed.
Important:
You must have the required permissions or rights assigned to the user account that you are logged into when you try to back up or restore files and folders. To create Exchange Server backups, you must have domain level backup operator rights. To create backups of your Microsoft Windows Server™ 2003 operating system, you must have at least local backup operator rights.

The backup strategy that you choose for your Exchange Server data will depend on the size of the stores, the speed of backup software and hardware, hardware capacity, and time requirements.

For more information about backup strategies as well as disaster recovery operations, see:

  • the Exchange Server 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?linkid=47570).

  • Database Backup and Restore (http://go.microsoft.com/fwlink/?LinkId=80766).


Public folder store exceeds 12 GB
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_DataFile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FileSize key for each Exchange public folder store database file (.edb file) and streaming file (.stm file). The Exchange Server Analyzer also reads the following registry branch to determine the version of Exchange Server that is installed:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Exchange Product GUID>

If the Exchange Server Analyzer finds that the combined size of a pair of public folder store database and streaming files exceeds 12 GB on a computer that is running Microsoft Exchange Server 2003 Standard Edition or Exchange 2000 Server Standard Edition, a warning is displayed.

Exchange store databases on Exchange Server 2003 Standard Edition and Exchange 2000 Server Standard Edition cannot grow larger than 16 GB. After that limit is reached, the mailbox store will no longer mount and Exchange will be inaccessible. Exchange store databases in Exchange Server 2003 Enterprise Edition and Exchange 2000 Server Enterprise Edition are not limited to 16 GB; they are limited only by available hardware, with a theoretical maximum size of 16 terabytes.

To correct this warning

  1. Consider setting expiration policies on public folders to delete messages that are older than a certain age.

  2. Consider setting storage limits on both public folder stores and individual public folders to prevent unlimited growth of the public folder store.

  3. If you have recently deleted bulk messages or removed public folder replicas from this public folder store, performing an offline defragmentation may decrease the size of the files.
Note:
With the release of Exchange Server 2003 Service Pack 2 (SP2), in Exchange Server 2003 Standard Edition, the hard-coded licensing database size limit has been increased from 16 GB to 75 GB. The administrator can set a protective database size limit (prevent unintentional database size growth). The default value is 18 GB in SP2 for Standard Edition and the default of 18 GB can be overwritten by editing the Database Size Limit in Gb registry key.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the database size limit for a database with Exchange Server 2003 SP2

  1. On the computer running Exchange Server, start Regedit.exe.

  2. Open the following registry key: HKLM\System\CurrentControlSet\Services\MSExchangeIS\Server name\Public-Public Store GUID

  3. Right-click Public Store GUID, point to New, and then click DWORD Value.

  4. For the new value name, type Database Size Limit in Gb.

  5. Double-click Database Size Limit in Gb. In Value data, type an appropriate value for maximum database size in GB. For Exchange Server 2003 Standard Edition, type a value between 1 and 75 (the default is 18 GB). For Exchange Server 2003 Enterprise Edition, type a value between 1 and 8000 (the default is 8000 GB). Click OK.

  6. Right-click Public Store GUID, point to New, and then click DWORD Value.

  7. For the new value name, type Database Size Buffer in Percentage.

  8. Double-click Database Size Buffer in Percentage. In Value data, type a value between 1 and 100 to specify when you want events to be logged to warn you that you are nearing the maximum size for a database. The default value of 10 will result in warning events to be logged when you have 10 percent capacity left before you reach the maximum size for that database. Click OK.

  9. Right-click Public Store GUID, point to New, and then click DWORD Value.

  10. For the new name, type Database Size Check Start Time in Hours From Midnight.

  11. Double-click Database Size Check Start Time in Hours From Midnight. In Value data, type a value between 0 and 23 to specify when you want Exchange to check the database size. The default value of 5 results in Exchange Server checking the database size 5 hours after midnight (5:00 AM). Click OK.

  12. Close Registry Editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about .stm and .edb files, see the Microsoft Knowledge Base article 232323, "Native Content Storage in Microsoft Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323).

For more information about moving mailboxes in Exchange Server 2003, see the Knowledge Base article 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829).

For more information about moving mailboxes in Exchange 2000 Server, see the Knowledge Base article 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810).

For more information about performing an offline defragmentation of an Exchange Server database, see the Knowledge Base article 328804, "How to Defragment Exchange Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804).

For more information about setting storage limits on public folders, see the Knowledge Base article 823144, "HOW TO: Configure Storage Limits on Public Folders in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823144).

For information about Exchange Server 2003 Standard Edition and Exchange 2000 Server Standard Edition reaching the maximum database size, see Microsoft Knowledge Base article 828070, "Exchange Server Mailbox Store Does Not Mount When the Mailbox Store Database Reaches the 16-GB Limit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site (http://go.microsoft.com/fwlink/?LinkId=52073).


Public folder store exceeds 15 GB
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_DataFile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FileSize key for each Exchange public folder store database file (.edb file) and streaming file (.stm file). The Exchange Server Analyzer also reads the following registry branch to determine the version of Exchange Server that is installed:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Exchange Product GUID>

If the Exchange Server Analyzer finds that the combined size of a pair of public folder store database and streaming files exceeds 15 GB on a computer that is running Microsoft Exchange Server 2003 Standard Edition or Exchange 2000 Server Standard Edition, an error is displayed.

Exchange store databases on Exchange Server 2003 Standard Edition and Exchange 2000 Server Standard Edition cannot grow larger than 16 GB. After that limit is reached, the mailbox store will no longer mount and Exchange will be inaccessible. Exchange store databases in Exchange Server 2003 Enterprise Edition and Exchange 2000 Server Enterprise Edition are not limited to 16 GB; they are limited only by available hardware, with a theoretical maximum size of 16 terabytes.

To correct this error

  1. Consider setting expiration policies on public folders to delete messages that are older than a certain age.

  2. Consider setting storage limits on both public folder stores and individual public folders to prevent unlimited growth of the public folder store.

  3. If you have recently deleted bulk messages or removed public folder replicas from this public folder store, performing an offline defragmentation may decrease the size of the files.
Note:
With the release of Exchange Server 2003 Service Pack 2 (SP2) for the Exchange Server 2003 Standard Edition, the hard-coded licensing database size limit has been increased from 16 GB to 75 GB. The administrator can set a protective database size limit (prevent unintentional database size growth). The default value is 18 GB in SP2 for Standard Edition and the default of 18 GB can be overwritten by editing the Database Size Limit in Gb registry key.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the database size limit for a database with Exchange Server 2003 SP2

  1. On the computer running Exchange Server, start Regedit.exe.

  2. Open the following registry key: HKLM\System\CurrentControlSet\Services\MSExchangeIS\Server name\Public-Public Store GUID

  3. Right-click Public Store GUID, point to New, and then click DWORD Value.

  4. For the new value name, type Database Size Limit in Gb.

  5. Double-click Database Size Limit in Gb. In Value data, type an appropriate value for maximum database size in GB. For Exchange Server 2003 Standard Edition, type a value between 1 and 75 (the default is 18 GB). For Exchange Server 2003 Enterprise Edition, type a value between 1 and 8000 (the default is 8000 GB). Click OK.

  6. Right-click Public Store GUID, point to New, and then click DWORD Value.

  7. For the new value name, type Database Size Buffer in Percentage.

  8. Double-click Database Size Buffer in Percentage. In Value data, type a value between 1 and 100 to specify when you want events to be logged to warn you that you are nearing the maximum size for a database. The default value of 10 will result in warning events to be logged when you have 10 percent capacity left before you reach the maximum size for that database. Click OK.

  9. Right-click Ppublic Store GUID, point to New, and then click DWORD Value.

  10. For the new name, type Database Size Check Start Time in Hours From Midnight.

  11. Double-click Database Size Check Start Time in Hours From Midnight. In Value data, type a value between 0 and 23 to specify when you want Exchange to check the database size. The default value of 5 results in Exchange Server checking the database size 5 hours after midnight (5:00 AM). Click OK.

  12. Close Registry Editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about .stm and .edb files, see the Microsoft Knowledge Base article 232323, "Native Content Storage in Microsoft Exchange" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323).

For more information about moving mailboxes in Exchange Server 2003, see the Knowledge Base article 821829, "Moving Mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829).

For more information about moving mailboxes in Exchange 2000 Server, see the Knowledge Base article 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810).

For more information about performing an offline defragmentation of an Exchange Server database, see the Knowledge Base article 328804, "How to Defragment Exchange Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804).

For more information about setting storage limits on public folders, see the Knowledge Base article 823144, "HOW TO: Configure Storage Limits on Public Folders in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823144).

For information about Exchange Server 2003 Standard Edition and Exchange 2000 Server Standard Edition reaching the maximum database size, see the Knowledge Base article 828070, "Exchange Server Mailbox Store Does Not Mount When the Mailbox Store Database Reaches the 16-GB Limit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site (http://go.microsoft.com/fwlink/?LinkId=52073).


Public Folder store does not have an e-mail address
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-03-28

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the configured value for the mail attribute for each public folder store. If the Exchange Server Analyzer finds that the mail attribute is not configured for any public folder store, an error is displayed.

If a public folder store is not configured with a Simple Mail Transfer Protocol (SMTP) address, public folder hierarchy replication will not function correctly for the store.

Technically, a public folder store is a special type of Exchange mailbox. Like all mailbox-enabled objects, a public folder store must have the following attributes correctly configured to send and receive mail:

  • legacyExchangeDN This is the Exchange-style distinguished name for the object.

  • proxyAddresses This attribute holds all the e-mail addresses that may be used to send mail to this recipient.

  • textEncodedORAddress This attribute contains the primary X.400 address.

  • Mail This attribute contains the object's primary SMTP address, without an address prefix.

  • mailNickname This attribute is used to generate the URL to access the mailbox.

  • displayName This attribute contains the display name of the object as it appears in the global address list and any other address lists that the object is a member of.

If the mail attribute is not set for a public folder store, it often means that the Recipient Update Service is not configured or working correctly. There are two types of Recipient Update Services. One is responsible for processing Exchange system objects in the Configuration container (the Enterprise Recipient Update Service), and the other is responsible for processing recipients in each domain (a domain Recipient Update Service).

There is only one Enterprise Recipient Update Service in the entire Active Directory forest because there is only one Configuration container. It is this Recipient Update Service that is responsible for configuring, among other items, the mail attribute for public folder stores. If this Recipient Update Service is disabled, incorrectly configured, or if the Recipient Update Service encounters a problem, the attributes might not be configured correctly, and public folder replication will not operate correctly. You should resolve this issue by verifying the configuration of the Enterprise Recipient Update Service.

To correct this error

  1. Open Exchange System Manager.

  2. Expand Recipients, and then select the Recipient Update Services node.

  3. In the right pane, right-click the Recipient Update Service that has (Enterprise Configuration) as part of its name, and click Properties.

  4. Verify that the Domain field has the correct domain name listed.

  5. Verify that the computers listed in the Exchange server and Windows Domain Controller fields are operating normally and available on the network. If these systems are down, unavailable, or not the required systems for performing Recipient Update Service tasks, you can use the field's Browse button to specify an alternate machine.

  6. Verify that the Update interval is set to Always run.

  7. Click OK to save the changes.

  8. In the right pane, right-click the Recipient Update Service that has (Enterprise Configuration) as part of its name and select Rebuild. The following message will be displayed:

    "This operation will recalculate the Address List membership and the Recipient Policy settings of all recipients in 'contoso.com' upon the next scheduled update interval. Depending on the number of recipients in the domain, this could take several hours. Do you want to continue?"

  9. Click Yes to rebuild the Recipient Update Service.

  10. After 15 minutes, start monitoring the progress of Recipient Update Service by following the procedures outlined in the Microsoft Knowledge Base article 246127, "XADM: How to Check the Progress of the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127).

For more information about the Recipient Update Service, see the following Knowledge Base articles:

  • 296479, "XADM: Requirements for Disabling the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=296479)

  • 328738, "XADM: How the Recipient Update Service Applies Recipient Policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 253770, "XADM: Tasks Performed by the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 288807, "Troubleshooting the Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=288807)

  • 319065, "HOW TO: Work with the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319065)


Public folder store will not mount on start-up
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchEDBOffline attribute of all objects with a class of msExchPublicMDB. Objects with this class are public folder stores.

A value of True for the msExchEDBOffline attribute indicates that the public folder store will not be mounted automatically when the Microsoft Exchange Information Store service starts. A value of False indicates that the public folder store will be mounted at startup. If the Exchange Server Analyzer finds the value for this attribute set to True, a warning is displayed.

This warning indicates that the Do not mount this store at start-up check box is selected. This check box is on the Database tab of the public folder store Properties dialog box. When the check box is selected, the public folder store will not be mounted automatically when the Microsoft Exchange Information Store service starts. The next time the Microsoft Exchange Information Store service is started, for example after a reboot of the server, a public folder store with this attribute set to True will not mount. It is recommended that public folder stores mount automatically when the Microsoft Exchange Information Store service is started.

To correct this warning on Exchange 2000 Server and Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, and then expand the server that contains the public folder store you want to modify.

  3. Expand the storage group that contains the public folder store you want to modify.

  4. Right-click the public folder store, and then click Properties.

  5. On the Database tab, clear the Do not mount this store at start-up check box.

  6. Click OK to save the setting.

  7. Close Exchange System Manager.

To correct this warning for Exchange Server 2007

  1. Open Exchange Management Console

  2. Expand Server Configuration and then select the server that you want to work with.

  3. Expand the storage group that you want to work with.

  4. Right-click the public folder database that you want to work with, and then click Properties.

  5. On the General tab, clear the Do not mount this database at start-up check box.

  6. Click OK to save the setting.

  7. Close Exchange Management Console

For more information about this option, see the following Microsoft Knowledge Base articles:

  • 314218, "HOW TO: Turn Off or Turn On Automatic Mounting of Data Stores at Startup in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=314218)

  • 285169, "XADM: Information Stores Do Not Mount After You Use the "/disasterrecovery" Switch" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=285169)


Public folder tree database assignment
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchOwningPFTreeBL attribute for each msExchPFTree object class. The msExchOwningPFTreeBL attribute stores a list of distinguished names of public folder stores that contain a replica of the public folder tree. If the Exchange Server Analyzer finds that the msExchOwningPFTreeBL attribute on a public folder tree object is empty, a warning is displayed. This warning indicates that a public folder tree is not owned by any public folder store.

Each public folder tree (also called "public folder hierarchy") is linked back to a public folder store. You must create the tree first and then the store. If you have not yet linked the tree to a database, this warning is displayed. Each public folder tree can have only one store on a particular server. A tree can have multiple stores when each store exists on a separate server. In such a configuration, Exchange replicates information among the stores to keep the hierarchy consistent.

If Microsoft Office Outlook® Web Access clients try to connect to any public folder within a tree that has no associated public folder stores, a "service unavailable" (HTTP 503) error occurs.

To correct this warning, you must do one of the following:

  • Link the public folder tree with a public folder database. To link the public folder tree with a public folder database, you must first create a new public folder database, and then locate the public folder tree and link them.

  • Delete the public folder tree. If you have not yet linked the public folder tree to a public folder database, no user data will be lost when you delete the tree.

To link the public folder tree with a public folder database

  1. In Exchange System Manager, expand the server to which you want to add a public folder store.

  2. Right-click a specific storage group, point to New, and then click Public Store.

  3. In Name, type a name for the new database.

  4. To associate the public folder tree with the database, click Browse, and then select the public folder tree that is displayed in the Exchange Server Analyzer warning.

  5. To save your settings, click OK.

  6. To mount the new store, click Yes.

To delete the public folder tree

  1. In Exchange System Manager, expand the Folders node where the public folder tree exists.

  2. Right-click the public folder tree that you want to delete, click Delete, and then click Yes.

For more information about public folder administration, see "Managing Mailbox Stores and Public Folder Stores" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?linkid=47617).

For more information, see the Exchange Server 2003 Service Pack 1 (SP1) Online Help (http://go.microsoft.com/fwlink/?LinkId=29847).


Recovery storage group enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchESEParamBaseName attribute of all objects with a class of msExchStorageGroup. Objects with this class are storage group objects. A value of R00 for the msExchESEParamBaseName attribute indicates that the storage group object is a recovery storage group. If the Exchange Server Analyzer finds that the value for this attribute is R00, a warning is displayed.

This warning indicates that a recovery storage group exists. We recommend that you remove a recovery storage group after you complete the recovery process. If you do not remove a recovery storage group, an administrator who is unfamiliar with recovery storage groups may be confused when performing a standard recovery in the future.

To correct this warning for Exchange 2000 Server and Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, and then expand the server that contains the recovery storage group you want to delete.

  3. Right-click the recovery storage group, and then click Delete.

  4. Close Exchange System Manager.

To correct this warning for Exchange Server 2007

  1. Follow the guidance in the core Exchange Server 2007 documentation, How to Remove a Recovery Storage Group (http://go.microsoft.com/fwlink/?LinkId=80783).

For more information about recovery storage groups and Exchange Server 2003, see Using Exchange Server 2003 Recovery Storage Groups (http://go.microsoft.com/fwlink/?LinkId=23233) and Microsoft Knowledge Base article 824126, "How to use Recovery Storage Groups in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=824126).

For more information about recovery storage groups and Exchange Server 2007, see Understanding Recovery Storage Groups (http://go.microsoft.com/fwlink/?LinkId=80784).


Recovery storage group functionality disabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchMaxRestoreStorageGroups attribute has been modified. If the Exchange Server Analyzer finds that the msExchMaxRestoreStorageGroups attribute has been set to 0, the Exchange Server Analyzer displays an error.

The msExchMaxRestoreStorageGroups attribute is a binary attribute of the information store object for each Exchange computer. If the msExchMaxRestoreStorageGroups attribute is set to 0, recovery storage groups cannot be created for the given Exchange computer.

This error may occur if you have performed an in-place upgrade from Exchange 2000 Server SP3 to Exchange Server 2003 SP1 on a Windows cluster, where the Exchange virtual server was not upgraded with Exchange Server 2003. Note that sometimes this in-place upgrade scenario may also cause Outlook® Mobile Access to fail.

You must correct the recovery storage group error by setting the msExchMaxRestoreStorageGroups attribute to 1 for each Exchange computer's information store object. The affected information store objects are displayed in the Exchange Server Analyzer output. If you need help with the Outlook Mobile Access issue, contact Microsoft support.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP tool (ldp.exe), or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.
To correct the recovery storage group error

  1. Start ADSI Edit.

  2. Double-click the Configuration container, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=<ExchangeOrganizationName>.

  3. Expand CN=Administrative Groups, expand CN=<AdministrativeGroupName>, and then expand CN=Servers.

  4. In the details pane, right-click CN=InformationStore, and then click Properties.

  5. In the Attribute Editor, click the msExchMaxRestoreStorageGroups attribute, and then click Edit.

  6. In the Edit Attribute box, enter 1.

  7. Click Apply, and then click OK.

  8. Close ADSI Edit. Restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about how to use the LDP tool, see Microsoft Knowledge Base article 260745, "XADM: Using the LDP Utility to Modify Active Directory Object Attributes" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745).

For more information about Exchange recovery storage groups, see the following Exchange resources:

  • Using Exchange Server 2003 Recovery Storage Groups (http://go.microsoft.com/fwlink/?LinkId=47589).

  • Understanding Recovery Storage Groups (http://go.microsoft.com/fwlink/?LinkID=80784)


Replication expiry for a public folder server is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-05-25

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether the interval at which the Exchange store removes items that have exceeded the retention period has been modified from its default setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder GUID>\Replication Expiry

If the Exchange Server Analyzer finds that the Replication Expiry registry value is present and configured, a non-default configuration message is displayed.

Message expiration is the process of expiring messages in public folders that exceed a specified time value. The default interval for message expiration is 24 hours.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder GUID>

  3. Delete the Replication Expiry registry value.

  4. Restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595) and Knowledge Base article 273479, "Description of the public folder referral functionality in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=273479).


Replication Folder Conflict Age Limit for a public folder store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether folder conflict aging has been modified from its default setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder GUID>\Replication Folder Conflict Age Limit

If the Exchange Server Analyzer finds that the Replication Folder Conflict Age Limit registry value is present and configured, a non-default configuration message is displayed.

When two users have edited and modified the same message in a public folder, the resulting saved messages are defined as being in conflict. This situation can occur when a simultaneous save occurs on the same public folder server, or if the message is edited on two servers that contain replicas of the folder. If no action is taken by the owners of the public folder within the period established by the conflict age limit, the conflict is resolved by the public folder store after the age limit has elapsed. The Replication Folder Conflict Age Limit registry value controls this age limit. Its value is the number of days that items in conflict are allowed to exist.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder GUID>

  3. Delete the Replication Folder Conflict Age Limit registry value.

  4. Restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see the Knowledge Base article 273479, "Understanding Public Folder Replication and Referrals" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=273479).


Replication Folder Count Limit value changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the Replication Folder Count Limit key has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ <servername> \Public -<GUID of Public Store> \Replication Folder Count Limit

If the Exchange Server Analyzer finds Replication Folder Count Limit to be present, a non-default configuration message is displayed.

By default, Replication Folder Count Limit does not exist. The Replication Folder Count Limit value represents the maximum number of folders to pack in a hierarchy replication message (used to replicate the hierarchy of the public folder tree and the properties of public folders). The value must be between 1 and 1000; the default value is 20. This registry key is not valid in Exchange Server 2003 and later versions; it is used only in previous versions of Exchange Server.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To reset the Replication Folder Count Limit registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>

  3. Examine or edit the value for Replication Folder Count Limit.

    The value for this registry entry is in kilobytes (KB). To return to the default value, you should delete Replication Folder Count Limit and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Replication Folder Tree RMQ Timeout value changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Replication Folder Tree RMQ Timeout key has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ <servername> \Public -<GUID of Public Store> \Replication Folder Tree RMQ Timeout

If the Exchange Server Analyzer finds Replication Folder Tree RMQ Timeout to be present, a non-default configuration message is displayed.

By default, Replication Folder Tree RMQ Timeout does not exist. Exchange uses hierarchy messages to replicate the hierarchy of the public folder tree and the properties of public folders. After a public folder store receives replicated changes, it loads the changes into memory (replication message queues) to process. The Replication Folder Tree RMQ Timeout value represents the maximum length of time replicated hierarchy changes remain in memory. The value, in seconds, must be between 3600 (one hour) and 2592000 (30 days); the default value is 604800 (7 days). Changes that are processed successfully are promptly deleted from memory; otherwise, the changes are held in memory until either they can be processed or until the time-out elapses, at which time they are deleted.

For example, assume a change is replicated for a folder and another change is replicated for a subfolder of that folder. Depending on the topology and the elapsed time between changes, the changes may arrive at the destination public folder store in any order. If the subfolder change arrives first but cannot be processed correctly until the parent folder change has been applied, the public folder store will hold the subfolder change in memory until the parent folder change has arrived and been processed. If the time-out elapses before the parent folder change has been processed, the subfolder change will be deleted from memory. Later, after the parent folder change has been processed, the public folder store may receive another copy of the subfolder change, which it can then process successfully. If the store does not receive another copy of the subfolder change, when the public folder store checks its status against other public folder stores in the topology, it notes that its copy of the public folder tree is missing the subfolder change and begins the process of backfilling that change.

In most circumstances, changing the Replication Folder Tree RMQ Timeout from its default value is not recommended. If this value has been changed, it may have been temporarily increased during a period of heavy replication traffic (for example, after a new public folder store was added).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To reset the Replication Folder Tree RMQ Timeout registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>

  3. Examine or edit the value for Replication Folder Tree RMQ Timeout.

    The value for this registry entry is in seconds. To return to the default value, you should delete Replication Folder Tree RMQ Timeout and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication," in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Replication Folder Tombstone Age Limit for a public folder store is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the interval for removing public folder tombstone entries has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder Store GUID>\Replication Folder Tombstone Age Limit

If the Exchange Server Analyzer finds that Replication Folder Tombstone Age Limit is present in the registry, a non-default configuration message is displayed.

Folder tombstone information is used by public folder replication. The aging is required to prevent the folder tombstone list from growing unbounded. The default value of 180 days can be overridden with the Replication Folder Tombstone Age Limit registry value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder Store GUID>

  3. Delete the Replication Folder Tombstone Age Limit registry value.

  4. Restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Replication Folder Tombstone Age Limit registry value, see the Knowledge Base article 159196, "XADM: Tasks Controlled by the IS Maintenance Schedule" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=159196).


Replication Long Backfill Request Delay value changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the Replication Long Backfill Request Delay key has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS \<servername> \Public- <GUID of Public Store> \Replication Long Backfill Request Delay

If the Exchange Server Analyzer finds Replication Long Backfill Request Delay to be present, a non-default configuration message is displayed.

By default, Replication Long Backfill Request Delay does not exist. Backfilling occurs when a public folder store determines that it has not received all of the updates for a replicated folder (or for the hierarchy) and must retrieve the missing updates from another store.

To streamline the backfill process, Exchange Server stores information about missing updates in the backfill array. The backfill array stores this information for a specified length of time (called the backfill time-out). If the missing updates arrive in subsequent replication messages during this time, they are removed from the backfill array. The table below lists the default backfill time-out values, which depend on where the missing updates exist and whether they have been requested before.

Type of request | Content exists on a store in the local site | Content exists on a store in a remote site
Initial backfill | 6 hours | 12 hours
First backfill retry | 12 hours | 24 hours
Subsequent backfill retries | 24 hours | 48 hours

If the backfill time-out expires and the updates are still missing, Exchange Server 2003 creates one or more backfill requests and determines which servers to use as backfill sources.

To select a server (or servers) to use as a backfill source, Exchange Server 2003 first creates a list of all of the servers that have replicas of the folder, and then sorts the list according to the following sequence of criteria:

  • Sort according to server status Servers that are down or unavailable drop to the end of the list.

  • Sort according to preferred backfill server If any; this feature is only available in Exchange Server 2003 and later. Exchange Server 2003 checks the public folder store object in the Active Directory® directory service for a preferred backfill server. This setting is seldom used. In most circumstances, the backfill process operates most efficiently if Exchange Server 2003 selects a backfill server automatically. Most deployments of Exchange Server 2003 do not need a preferred backfill server. Microsoft Product Support Services can provide a script that sets a preferred backfill server if your deployment requires it.

  • Sort according to transport cost (lowest to highest) Servers in the same site have priority over servers in remote sites. The transport cost of a server is calculated by the Exchange Server 2003 routing engine, and is normally used to calculate the most efficient way to deliver a message. Note that in versions of Exchange prior to Exchange Server 2003, transport cost has lower priority and is only considered after the Exchange version and number of available changes.

  • Sort according to Exchange version (newest to oldest)

  • Sort according to the number of necessary changes that are available on the server (largest to smallest) Servers that do not have any of the missing changes are dropped from the list.

If one server does not have all of the needed changes, Exchange Server 2003 selects the next server in the sorted list and sends a backfill request to that server as well. This process is repeated until all of the changes have been requested. This feature is only available in Exchange Server 2003 and later; previous versions of Exchange send backfill requests to one server at a time if no single server holds all of the missing updates for a specific folder. After each request, previous versions of Exchange wait for the retry time-out (from 24 through 48 hours) to elapse before sending the next request.

If the selected server does not respond to the backfill request, the store marks that server as down and repeats the selection process. Servers marked down drop to the end of the list.

The Replication Long Backfill Request Delay value represents the length of time that a store delays before sending a backfill request for data that is not available in the same Exchange site. The value, in seconds, must be between 900 and 2592000 seconds (30 days); the default value is 43200 seconds (12 hours).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To reset the Replication Long Backfill Request Delay registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>

  3. Examine or edit the value for Replication Long Backfill Request Delay.

    The value for this registry entry is in seconds. To return to the default value, you should delete Replication Long Backfill Request Delay and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication," in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Replication Long Backfill Request Timeout value changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the Replication Long Backfill Request Timeout key has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS \<servername> \Public -<GUID of Public Store> \Replication Long Backfill Request Timeout

If the Exchange Server Analyzer finds Replication Long Backfill Request Timeout to be present, a non-default configuration message is displayed.

By default, Replication Long Backfill Request Timeout does not exist. Backfilling occurs when a public folder store determines that it has not received all of the updates for a replicated folder (or for the hierarchy) and must retrieve the missing updates from another store.

To streamline the backfill process, Exchange Server stores information about missing updates in the backfill array. The backfill array stores this information for a specified length of time (called the backfill time-out). If the missing updates arrive in subsequent replication messages during this time, they are removed from the backfill array. The table below lists the default backfill time-out values, which depend on where the missing updates exist and whether they have been requested before.

Type of request | Content exists on a store in the local site | Content exists on a store in a remote site
Initial backfill | 6 hours | 12 hours
First backfill retry | 12 hours | 24 hours
Subsequent backfill retries | 24 hours | 48 hours

If the backfill time-out expires and the updates are still missing, Exchange Server 2003 creates one or more backfill requests and determines which servers to use as backfill sources.

To select a server (or servers) to use as a backfill source, Exchange Server 2003 first creates a list of all of the servers that have replicas of the folder, and then sorts the list according to the following sequence of criteria:

  • Sort according to server status Servers that are down or unavailable drop to the end of the list.

  • Sort according to preferred backfill server If any; this feature is only available in Exchange Server 2003 and later. Exchange Server 2003 checks the public folder store object in the Active Directory® directory service for a preferred backfill server. This setting is seldom used. In most circumstances, the backfill process operates most efficiently if Exchange Server 2003 selects a backfill server automatically. Most deployments of Exchange Server 2003 do not need a preferred backfill server. Microsoft Product Support Services can provide a script that sets a preferred backfill server if your deployment requires it.

  • Sort according to transport cost (lowest to highest) Servers in the same site have priority over servers in remote sites. The transport cost of a server is calculated by the Exchange Server 2003 routing engine, and is normally used to calculate the most efficient way to deliver a message. Note that in versions of Exchange prior to Exchange Server 2003, transport cost has lower priority and is only considered after Exchange version and number of available changes.

  • Sort according to Exchange version (newest to oldest)

  • Sort according to the number of necessary changes that are available on the server (largest to smallest) Servers that do not have any of the missing changes are dropped from the list.

If one server does not have all of the needed changes, Exchange Server 2003 selects the next server in the sorted list and sends a backfill request to that server as well. This process is repeated until all of the changes have been requested. This feature is only available in Exchange Server 2003 and later; previous versions of Exchange send backfill requests to one server at a time if no single server holds all of the missing updates for a specific folder. After each request, previous versions of Exchange wait for the retry time-out (from 24 through 48 hours) to elapse before sending the next request.

If the selected server does not respond to the backfill request, the store marks that server as down and repeats the selection process. Servers marked down drop to the end of the list.

The Replication Long Backfill Request Timeout value represents the time-out value that the public folder store uses when trying to send a backfill request for data that is not available in the same Exchange site. The value, in seconds, must be between 900 and 2592000 seconds (30 days); the default value is 86400 seconds (24 hours).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To reset the Replication Long Backfill Request Timeout registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>

  3. Examine or edit the value for Replication Long Backfill Request Timeout.

    The value for this registry entry is in seconds. To return to the default value, you should delete Replication Long Backfill Request Timeout and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Replication Long Backfill Request Timeout Retry value changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the Replication Long Backfill Request Timeout Retry key has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS \<servername> \Public- <GUID of Public Store> \Replication Long Backfill Request Timeout Retry

If the Exchange Server Analyzer finds Replication Long Backfill Request Timeout Retry to be present, a non-default configuration message is displayed.

By default, Replication Long Backfill Request Timeout Retry does not exist. Backfilling occurs when a public folder store determines that it has not received all of the updates for a replicated folder (or for the hierarchy) and must retrieve the missing updates from another store.

To streamline the backfill process, Exchange Server stores information about missing updates in the backfill array. The backfill array stores this information for a specified length of time (called the backfill time-out). If the missing updates arrive in subsequent replication messages during this time, they are removed from the backfill array. The table lists the default backfill time-out values, which depend on where the missing updates exist and whether they have been requested before.

Type of request | Content exists on a store in the local site | Content exists on a store in a remote site
Initial backfill | 6 hours | 12 hours
First backfill retry | 12 hours | 24 hours
Subsequent backfill retries | 24 hours | 48 hours

If the backfill time-out expires and the updates are still missing, Exchange Server 2003 creates one or more backfill requests and determines which servers to use as backfill sources.

To select a server (or servers) to use as a backfill source, Exchange Server 2003 first creates a list of all of the servers that have replicas of the folder, and then sorts the list according to the following sequence of criteria:

  • Sort according to server status Servers that are down or unavailable drop to the end of the list.

  • Sort according to preferred backfill server If any; this feature is only available in Exchange Server 2003 and later. Exchange Server 2003 checks the public folder store object in the Active Directory® directory service for a preferred backfill server. This setting is seldom used. In most circumstances, the backfill process operates most efficiently if Exchange Server 2003 selects a backfill server automatically. Most deployments of Exchange Server 2003 do not need a preferred backfill server. Microsoft Product Support Services can provide a script that sets a preferred backfill server if your deployment requires it.

  • Sort according to transport cost (lowest to highest) Servers in the same site have priority over servers in remote sites. The transport cost of a server is calculated by the Exchange Server 2003 routing engine, and is normally used to calculate the most efficient way to deliver a message. Note that in versions of Exchange prior to Exchange Server 2003, transport cost has lower priority and is only considered after Exchange version and number of available changes.

  • Sort according to Exchange version (newest to oldest)

  • Sort according to the number of necessary changes that are available on the server (largest to smallest) Servers that do not have any of the missing changes are dropped from the list.

If one server does not have all of the required changes, Exchange Server 2003 selects the next server in the sorted list and sends a backfill request to that server as well. This process is repeated until all of the changes have been requested. This feature is only available in Exchange Server 2003 and later; previous versions of Exchange send backfill requests to one server at a time if no single server holds all of the missing updates for a specific folder. After each request, previous versions of Exchange wait for the retry time-out (from 24 through 48 hours) to elapse before sending the next request.

If the selected server does not respond to the backfill request, the store marks that server as down and repeats the selection process. Servers marked down drop to the end of the list.

The Replication Long Backfill Request Timeout Retry value represents the time-out value the public folder store uses when sending a backfill request for data that is not available in the same Exchange site, and when this request is a retry of a previous backfill request. The value, in seconds, must be between 900 and 2592000 seconds (30 days); the default value is 172800 seconds (48 hours).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To reset the Replication Long Backfill Request Timeout Retry registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>

  3. Examine or edit the value for Replication Long Backfill Request Timeout Retry.

    The value for this registry entry is in seconds. To return to the default value, you should delete Replication Long Backfill Request Timeout Retry and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Replication messages at startup has been Enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Exchange has been configured to generate status request messages for the public folder hierarchy:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<Server name>\Public-<Public Information Store GUID>\Enable Replication Messages At Startup

If the Exchange Server Analyzer finds the Enable Replication Messages At Startup registry entry present and configured, a non-default configuration message is displayed.

In Exchange Server 5.5, each computer that has a public folder store sends a nightly status request message to determine the state of the public folder hierarchy. Exchange 2000 Server and Exchange Server 2003 do not do this. Typically, in Exchange 2000 Server and Exchange Server 2003, the status request message is only sent out once during the lifetime of the public folder store; it is sent when the store is created.

However, in certain circumstances you may have to generate a status request message. For example, if the public folder hierarchy on the Exchange 2000 Server or Exchange Server 2003 computer does not seem to replicate, or the public folder hierarchy replicates very slowly, the generation of a status request message may permit the public folder hierarchy replication to continue. Issues with public folder hierarchy replication may occur if the original status request message that was sent when the public folder store was created was dropped and never acknowledged, or if the message was sent to a server with a significantly incomplete hierarchy.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To view or modify the Aging Keep Time registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<Server name>\Public-<Public Information Store GUID>

  3. Examine, or if desired, change the Enable Replication Messages At Startup value. This REG_DWORD value must be set to 1 to take effect. If you set the value to 0 (the default setting), no status request message is sent when the public information store starts.

  4. If a change is made, close the registry editor, and then dismount and remount the public information store for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication status messages and the Enable Replication Messages At Startup registry value, see the following Knowledge Base articles:

  • 321082, "XADM: How to Send Replication Status Request Messages in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=321082)

  • 842273, "How to troubleshoot public folder replication problems in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=842273)


Replication Short Backfill Request Delay value changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Replication Short Backfill Request Delay key has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS \<servername> \Public -<GUID of Public Store> \Replication Short Backfill Request Delay

If the Exchange Server Analyzer finds Replication Short Backfill Request Delay to be present, a non-default configuration message is displayed.

By default, Replication Short Backfill Request Delay does not exist. Backfilling occurs when a public folder store determines that it has not received all the updates for a replicated folder (or for the hierarchy) and must retrieve the missing updates from another store.

To streamline the backfill process, Exchange Server stores information about missing updates in the backfill array. The backfill array stores this information for a specified length of time (called the backfill time-out). If the missing updates arrive in subsequent replication messages during this time, they are removed from the backfill array. The table lists the default backfill time-out values, which depend on where the missing updates exist and whether they have been requested before.

Type of request | Content exists on a store in the local site | Content exists on a store in a remote site
Initial backfill | 6 hours | 12 hours
First backfill retry | 12 hours | 24 hours
Subsequent backfill retries | 24 hours | 48 hours

If the backfill time-out expires and the updates are still missing, Exchange Server 2003 creates one or more backfill requests and determines which servers to use as backfill sources.

To select a server (or servers) to use as a backfill source, Exchange Server 2003 first creates a list of all the servers that have replicas of the folder, and then sorts the list according to the following sequence of criteria:

  • Sort according to server status Servers that are down or unavailable drop to the end of the list.

  • Sort according to preferred backfill server If any; this feature is available only in Exchange Server 2003 and later. Exchange Server 2003 checks the public folder store object in the Active Directory® directory service for a preferred backfill server. This setting is seldom used. In most circumstances, the backfill process operates most efficiently if Exchange Server 2003 selects a backfill server automatically. Most deployments of Exchange Server 2003 do not need a preferred backfill server. Microsoft Product Support Services can provide a script that sets a preferred backfill server if your deployment requires it.

  • Sort according to transport cost (lowest to highest) Servers in the same site have priority over servers in remote sites. The transport cost of a server is calculated by the Exchange Server 2003 routing engine, and is normally used to calculate the most efficient way to deliver a message. Note that in versions of Exchange prior to Exchange Server 2003, transport cost has lower priority and is only considered after Exchange version and number of available changes.

  • Sort according to Exchange version (newest to oldest)

  • Sort according to the number of necessary changes that are available on the server (largest to smallest) Servers that do not have any of the missing changes are dropped from the list.

If one server does not have all of the needed changes, Exchange Server 2003 selects the next server in the sorted list and sends a backfill request to that server as well. This process is repeated until all of the changes have been requested. This feature is only available in Exchange Server 2003 and later; previous versions of Exchange send backfill requests to one server at a time if no single server holds all of the missing updates for a specific folder. After each request, previous versions of Exchange wait for the retry time-out (from 24 through 48 hours) to elapse before sending the next request.

If the selected server does not respond to the backfill request, the store marks that server as down and repeats the selection process. Servers marked as down drop to the end of the list.

The Replication Short Backfill Request Delay value represents the length of time that the public folder store delays before sending a backfill request for data that is available in the same Exchange site. The value, in seconds, must be between 900 and 2592000 seconds (30 days); the default value is 21600 seconds (6 hours).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To reset the Replication Short Backfill Request Delay registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>

  3. Examine or edit the value for Replication Short Backfill Request Delay.

    The value for this registry entry is in seconds. To return to the default value, you should delete Replication Short Backfill Request Delay and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Replication Short Backfill Request Timeout value changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the Replication Short Backfill Request Timeout key has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ <servername> \Public -<GUID of Public Store> \Replication Short Backfill Request Timeout

If the Exchange Server Analyzer finds Replication Short Backfill Request Timeout to be present, a non-default configuration message is displayed.

By default, Replication Short Backfill Request Timeout does not exist. Backfilling occurs when a public folder store determines that it has not received all of the updates for a replicated folder (or for the hierarchy) and must retrieve the missing updates from another store.

To streamline the backfill process, Exchange Server stores information about missing updates in the backfill array. The backfill array stores this information for a specified length of time (called the backfill time-out). If the missing updates arrive in subsequent replication messages during this time, they are removed from the backfill array. The table below lists the default backfill time-out values, which depend on where the missing updates exist and whether they have been requested before.

Type of request | Content exists on a store in the local site | Content exists on a store in a remote site
Initial backfill | 6 hours | 12 hours
First backfill retry | 12 hours | 24 hours
Subsequent backfill retries | 24 hours | 48 hours

If the backfill time-out expires and the updates are still missing, Exchange Server 2003 creates one or more backfill requests and determines which servers to use as backfill sources.

To select a server (or servers) to use as a backfill source, Exchange Server 2003 first creates a list of all of the servers that have replicas of the folder, and then sorts the list according to the following sequence of criteria:

  • Sort according to server status Servers that are down or unavailable drop to the end of the list.

  • Sort according to preferred backfill server If any; this feature is only available in Exchange Server 2003 and later. Exchange Server 2003 checks the public folder store object in the Active Directory® directory service for a preferred backfill server. This setting is seldom used. In most circumstances, the backfill process operates most efficiently if Exchange Server 2003 selects a backfill server automatically. Most deployments of Exchange Server 2003 do not need a preferred backfill server. Microsoft Product Support Services can provide a script that sets a preferred backfill server if your deployment requires it.

  • Sort according to transport cost (lowest to highest) Servers in the same site have priority over servers in remote sites. The transport cost of a server is calculated by the Exchange Server 2003 routing engine, and is normally used to calculate the most efficient way to deliver a message. Note that in versions of Exchange prior to Exchange Server 2003, transport cost has lower priority and is only considered after Exchange version and number of available changes.

  • Sort according to Exchange version (newest to oldest)

  • Sort according to the number of necessary changes that are available on the server (largest to smallest) Servers that do not have any of the missing changes are dropped from the list.

If one server does not have all of the needed changes, Exchange Server 2003 selects the next server in the sorted list and sends a backfill request to that server as well. This process is repeated until all of the changes have been requested. This feature is only available in Exchange Server 2003 and later; previous versions of Exchange send backfill requests to one server at a time if no single server holds all of the missing updates for a specific folder. After each request, previous versions of Exchange wait for the retry time-out (from 24 through 48 hours) to elapse before sending the next request.

If the selected server does not respond to the backfill request, the store marks that server as down and repeats the selection process. Servers marked down drop to the end of the list.

The Replication Short Backfill Request Timeout value represents the time-out value that a public folder store uses when trying to send a backfill request for data that is available in the same Exchange site. The value, in seconds, must be between 900 and 2592000 seconds (30 days); the default value is 43200 seconds (12 hours).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To reset the Replication Short Backfill Request Timeout registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>

  3. Examine or edit the value for Replication Short Backfill Request Timeout.

    The value for this registry entry is in seconds. To return to the default value, you should delete Replication Short Backfill Request Timeout and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Replication Short Backfill Request Timeout Retry value changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the Replication Short Backfill Request Timeout Retry key has been modified from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS \<servername> \Public -<GUID of Public Store> \Replication Short Backfill Request Timeout Retry

If the Exchange Server Analyzer finds Replication Short Backfill Request Timeout Retry to be present, a non-default configuration message is displayed.

By default, Replication Short Backfill Request Timeout Retry does not exist. Backfilling occurs when a public folder store determines that it has not received all of the updates for a replicated folder (or for the hierarchy) and must retrieve the missing updates from another store.

To streamline the backfill process, Exchange Server stores information about missing updates in the backfill array. The backfill array stores this information for a specified length of time (called the backfill time-out). If the missing updates arrive in subsequent replication messages during this time, they are removed from the backfill array. The table below lists the default backfill time-out values, which depend on where the missing updates exist and whether they have been requested before.

Type of request | Content exists on a store in the local site | Content exists on a store in a remote site
Initial backfill | 6 hours | 12 hours
First backfill retry | 12 hours | 24 hours
Subsequent backfill retries | 24 hours | 48 hours

If the backfill time-out expires and the updates are still missing, Exchange Server 2003 creates one or more backfill requests and determines which servers to use as backfill sources.

To select a server (or servers) to use as a backfill source, Exchange Server 2003 first creates a list of all of the servers that have replicas of the folder, and then sorts the list according to the following sequence of criteria:

  • Sort according to server status Servers that are down or unavailable drop to the end of the list.

  • Sort according to preferred backfill server If any; this feature is only available in Exchange Server 2003 and later. Exchange Server 2003 checks the public folder store object in the Active Directory® directory service for a preferred backfill server. This setting is seldom used. In most circumstances, the backfill process operates most efficiently if Exchange Server 2003 selects a backfill server automatically. Most deployments of Exchange Server 2003 do not need a preferred backfill server. Microsoft Product Support Services can provide a script that sets a preferred backfill server if your deployment requires it.

  • Sort according to transport cost (lowest to highest) Servers in the same site have priority over servers in remote sites. The transport cost of a server is calculated by the Exchange Server 2003 routing engine, and is normally used to calculate the most efficient way to deliver a message. Note that in versions of Exchange prior to Exchange Server 2003, transport cost has lower priority and is only considered after Exchange version and number of available changes.

  • Sort according to Exchange version (newest to oldest)

  • Sort according to the number of necessary changes that are available on the server (largest to smallest) Servers that do not have any of the missing changes are dropped from the list.

If one server does not have all of the required changes, Exchange Server 2003 selects the next server in the sorted list and sends a backfill request to that server as well. This process is repeated until all of the changes have been requested. This feature is only available in Exchange Server 2003 and later; previous versions of Exchange send backfill requests to one server at a time if no single server holds all of the missing updates for a specific folder. After each request, previous versions of Exchange wait for the retry time-out (from 24 through 48 hours) to elapse before sending the next request.

If the selected server does not respond to the backfill request, the store marks that server as down and repeats the selection process. Servers marked down drop to the end of the list.

The Replication Short Backfill Request Timeout Retry value represents the time-out value that the public folder store uses when sending a backfill request for data that is available in the same Exchange site, and when this request is a retry of a previous backfill request. The value, in seconds, must be between 900 and 2592000 seconds (30 days); the default value is 86400 seconds (24 hours).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To reset the Replication Short Backfill Request Timeout Retry registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-<GUID of Public Store>

  3. Examine or edit the value for Replication Short Backfill Request Timeout Retry.

    The value for this registry entry is in seconds. To return to the default value, you should delete Replication Short Backfill Request Timeout Retry and restart the Microsoft Exchange Information Store service.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about public folder replication, see "Controlling Exchange Server 2003 Public Folder Replication" in Working with the Exchange Server 2003 Store (http://go.microsoft.com/fwlink/?LinkId=47595).


Reserve increment size set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-30

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether a value for Reserve Increment KB has been set: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects that have an object class of msExchExchangeServer. If the string value includes "Version 5.5," the computer is running Microsoft Exchange Server 5.5. If the string value includes "Version 6.0," the computer is running Microsoft Exchange 2000 Server. If the string value includes "Version 6.5," the computer is running Microsoft Exchange Server 2003. If the string value includes "Version 8.0," the computer is running Microsoft Exchange Server 2007.

If the Exchange Server Analyzer finds that the Reserve Increment KB registry value exists on a computer that is running Exchange Server 2003, a non-default configuration message is displayed.

The Reserve Increment KB registry value overrides the native memory heap value in Microsoft Windows®. Windows includes a process-wide heap manager that handles memory operations for all processes. Every time that a process instantiates, a default heap (called a process heap) is created for that process. Programs or modules loaded in the process can also create additional heaps if needed. The Microsoft Exchange Information Store service, Store.exe, is an example of a process that creates additional heaps when needed. By default Store.exe sets the initial memory that is reserved for heap space to 20 percent of physical RAM. The Reserve Increment KB value changes the initial memory reservation for heap to 10 percent of physical memory.

The Reserve Increment KB registry value is useful only in limited cases. Additionally, this value should only be set on the advice and direction of Microsoft Product Support Services. An incorrect setting or incorrect use of this value could result in decreased performance and accelerate fragmentation of virtual memory. If this value was set without consulting Microsoft Product Support Services, consider removing it using the following procedure.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, delete the Reserve Increment KB value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about how to tune Exchange Server 2003, see the following Microsoft Knowledge Base articles:

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 815372, "How to optimize memory usage in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)


RPC buffer packing is disabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether remote procedure call (RPC) buffer packing has been disabled:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc Packing Enabled

If the Exchange Server Analyzer finds that the value data for the Rpc Packing Enabled registry key has been set to 0, the Exchange Server Analyzer displays a non-default configuration message. The Rpc Packing Enabled registry key is disabled when its value data is set to 0.

The value data for the Rpc Packing Enabled registry key is one of three registry entries that administrators can add to configure RPC compression between Microsoft Office Outlook® 2003 and Exchange Server 2003.

Outlook 2003 can request a data buffer of 96 KB. However, after Exchange Server 2003 has compressed the data, the data buffer may be significantly smaller than the amount that Outlook 2003 has requested.

Exchange Server 2003 supports buffer packing to support varying compression rates and to keep buffers full for efficiency.

When the Rpc Packing Enabled registry key is enabled, Exchange Server 2003 continues to add compressed data to the buffer until the buffer is full. For each data request, Outlook 2003 can download significantly more data than earlier versions of Outlook for the following reasons:

  • Outlook 2003 requests larger buffer sizes.

  • Exchange Server 2003 supports buffer packing.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required. However, you can delete the Rpc Packing Enabled registry key if you want to restore the default configuration. You can also set the data value of the Rpc Packing Enabled registry key to 1 to enable RPC buffer packing.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

    • To delete the entry, delete the Rpc Packing Enabled value.

    • To preserve the entry and enable RPC buffer packing, double-click Rpc Packing Enabled, set the value to 1, and then click OK.

  3. Close the registry editor.

The Microsoft Exchange Information Store service detects the changes in minutes. You do not have to restart the computer.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting registry keys to configure RPC compression between Outlook clients and Exchange Server 2003, see the Knowledge Base article 825371, "Modify Remote Procedure Call Compression in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=825371).


RPC Compression Minimum Size is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the minimum packet size for remote procedure call (RPC) compression:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc Compression Minimum Size

If the Exchange Server Analyzer finds that the value for Rpc Compression Minimum Size is greater than 0, a non-default configuration message is displayed.

By default, all RPC data that moves between Microsoft Office Outlook® 2003 or Outlook 2007 and Exchange Server 2003 or Exchange Server 2007 is compressed, regardless of its size. In some scenarios, you may want to control RPC compression. For example, if you are trying to troubleshoot connectivity problems by viewing the packets that are being sent over the network, RPC compression may make analysis difficult because you see only the compressed data in the trace.

To configure RPC compression settings, you can add three registry key values to the system settings:

  • Rpc Compression Minimum Size

  • Rpc Compression Enabled

  • Rpc Packing Enabled

The Rpc Compression Minimum Size registry value determines the minimum number of bytes required in the RPC packet before compression is activated. If this key is not present, a default value of 1,024 bytes is used.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the Rpc Compression Minimum Size key. If the Rpc Compression Enabled and Rpc Packing Enabled keys are present, delete those also.

  4. Close the registry editor, and restart the Exchange server for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about controlling RPC compression, see the Knowledge Base article 825371, "Modify Remote Procedure Call Compression in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=825371).


RpcEtwTracing parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine the value data:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\RpcEtwTracing

If the Exchange Server Analyzer finds that the value data for the RpcEtwTracing registry key is set to 1, the Exchange Server Analyzer displays a non-default configuration message.

You use the value data for the RpcEtwTracing registry key only to troubleshoot network problems between Microsoft Office Outlook® 2003 and Exchange Server. It is recommended that you disable the RpcEtwTracing registry key if you are not currently troubleshooting a problem.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required. However, you can delete the RpcEtwTracing registry key if you want to restore the default configuration.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To restore the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the RpcEtwTracing value.

  4. Close the registry editor.

The Microsoft Exchange Information Store service detects the changes in minutes. You do not have to restart the computer.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Server has less than four storage groups but more than four mailbox stores defined
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to count the number of StorageGroup objects and MailboxGroup objects on a server running Exchange Server 2003. If the Exchange Server Analyzer determines that the total number of StorageGroup objects is less than four and the total number of MailboxStore objects is more than four, an error is displayed.

If you are using Exchange Server 2003 Standard Edition, each Exchange Server computer can have one storage group, which supports one mailbox store and one public folder store. If you are using Exchange Server 2003 Enterprise Edition, each server can have as many as four storage groups, each of which supports as many as five databases (either mailbox stores or public folder stores).

The recommended best practice for configuring storage groups for computers that are running Exchange Server 2003 Enterprise Edition is to add an additional storage group for each new database until the maximum number of storage groups has been created. You can spread the load of mailboxes in your Exchange Server storage topology across as many storage groups as possible. Such a topology has the following advantages:

  • The reliability of the storage topology is increased.

  • The recoverability of the storage topology is increased.

  • Drive I/O can be better managed.

If you have less than four storage groups and more than four mailbox stores on a server running Exchange Server 2003 Enterprise Edition, take the following steps to spread your mailboxes across the most storage groups possible.

To resolve this error

  1. In Exchange System Manager, select the server that reported this error. Make a note of the number of storage groups and mailbox stores located on that server. Make a note of the storage groups that contain more than one mailbox store.

  2. Create any additional storage groups until you have four storage groups on the computer running Exchange Server 2003 Enterprise Edition. For information about how to create a new storage group, see "Adding a Storage Group" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).

  3. Create a new mailbox store in each new storage group you have created. For information about how to create a new mailbox store, see "Adding a Mailbox Store" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).

  4. Move mailboxes from one of the mailbox stores on the storage group that contains multiple mailbox stores to the mailbox store located in a newly-created storage group. Use the Move Mailbox Wizard to move mailboxes. For detailed information about how to use the Move Mailbox Wizard, see " Using Exchange Task Wizard to Move Mailboxes" in "Migrating from Exchange Server 5.5 to Exchange Server 2003" chapter of the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

For more information about how to configure storage groups in Exchange Server 2003, see the Microsoft Knowledge Base article 890699, "How to configure storage groups in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=890699).

For information about how to configure storage groups, see the storage group configuration section in "Planning a Reliable Back-End Storage Solution" in the Exchange Server 2003 High Availability Guide (http://go.microsoft.com/fwlink/?LinkId=47571).

For overall recommendations to help you maximize availability, fault tolerance, and performance, see Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=49324).


Signature Discrepancy Between Database and Streaming File
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that you have a signature discrepancy between your Exchange database (.edb) file and its corresponding Exchange streaming database (.stm) file.

Each database in Exchange 2000 Server and Exchange Server 2003 is made up of two files: the .edb MAPI database file and the .stm streaming database file. Matched pairs of these files share a common database signature. If the database signature does not match, the files are not matched.

You should treat the .edb and .stm files as if they are a single file. They should always be moved or copied together.

To correct this error

  • Investigate the history of the database files. It is likely that files have been manually copied, moved or deleted. You must correct this problem before the database can be recovered.

  • If you cannot locate matching .edb and .stm files, you may be able to use Eseutil.exe to repair only the .edb file and use Eseutil with the /createstm switch to discard the .stm file. This method results in the loss of all information in the streaming database.

    Note:
    If all database users connect to the database by using a MAPI client such as Microsoft Office Outlook®, the information stored in the streaming database is minimal. If users connect to the database by using POP3, IMAP or Outlook Web Access clients, then the streaming database contains some or all of the users' mailbox contents.

For more information about how to repair an Exchange database, see Microsoft Knowledge Base article 812357, "How to maintain your Exchange database after you repair by using the Eseutil /p tool in Exchange Server 5.5, in Exchange 2000 Server, and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812357).


SMTP address is not defined in default recipient policy
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-12-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the SMTP address is specified on the gatewayProxy attribute of the default recipient policy in your Exchange Server organization. If the Exchange Server Analyzer finds that the gatewayProxy attribute does not contain an SMTP address, the Exchange Server Analyzer displays an error.

This error is a critical error. You must add the SMTP address, such as SMTP:@contoso.com, to the gatewayProxy attribute of the default recipient policy in your Exchange Server organization. The default recipient policy must contain an SMTP address. If the default recipient policy does not contain an SMTP address, the Microsoft Exchange Information Store service will not initialize after restarting. This failure will occur across all Exchange servers in your Exchange Server organization the next time the Microsoft Exchange Information Store service is restarted.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003 or Exchange Server 2007, or both. Modify Active Directory object attributes at your own risk.
To add the SMTP address to the gatewayProxy attribute of the default recipient policy

  1. Start the ADSI Edit tool from Microsoft Windows® 2000 Support Tools or from Windows Server 2003 Support Tools.

  2. Expand the following nodes:

    • Configuration Container

    • Configuration

    • Services

    • Microsoft Exchange

    • Organization_Name

    • Recipient Policies

  3. In the details pane, right-click CN=Default Policy, and then click Properties.

  4. In the Attributes box, double-click gatewayProxy.

  5. In the Multi-valued String Editor dialog box, enter SMTP:@domain_name.com in the Value to add field, and then click Add.

    Note:
    The syntax that you enter is important. You must include SMTP:@ before you enter the domain name of the Exchange Server organization. There are no white spaces in this string.

  6. Click OK, then click Apply, and then close ADSI Edit.

  7. Wait at least 15 minutes for replication.


Store RPC prorate registry parameters are not set to their correct values
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads three registry keys to determine whether their values have been modified from their default values. All three keys are DWORD values that can be found at:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Image File Execution Options\STORE.EXE\RpcThreadPoolThrottle

The keys have the following names and default values:

DWORD value Default Decimal Value
  • ProrateStart

  • 40
  • ProrateMax

  • 10,000
  • ProrateFactor

  • 100

If the Exchange Server Analyzer finds that any of the above default values have been changed, a non-default configuration message is displayed.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default values

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Image File Execution Options\STORE.EXE\RpcThreadPoolThrottle

  3. In the right pane, double-click the entry whose value has been changed, and configure it for its default value.

  4. Repeat step 3 if more than one value was changed.

  5. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about store process threads, see the Knowledge Base article 267255, "Store.exe Threads Use Up Available Memory" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=267255).


Store working directory is missing or incorrect
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-30

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to verify the working directory for the Microsoft Exchange Information Store service.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Working Directory

The Exchange Server Analyzer displays a warning if the following conditions exist:

  • The directory that is specified as the Working Directory does not exist.

  • You are running Exchange 2000 Server, Exchange Server 2003, or Exchange Server 2007.

Exchange Server uses the working directory for temporary storage. For example, Exchange Server uses the working directory during the message conversion process. Exchange Server also uses the working directory to store a temporary database during defragmentation. If the working directory is not specified correctly, the following problems may occur:

  • Messages with attachments may build up in the SMTP local delivery queue.

  • Messages may be received without attachments.

  • Messages may not be delivered successfully.

By default, Exchange 2000 Server and Exchange Server 2003 sets the working directory to be the mdbdata directory under the directory where you installed Exchange Server. For example, if you install Exchange Server in the C:\Program Files\Exchsrvr directory, Exchange Server sets the working directory as C:\Program Files\Exchsrvr\mdbdata.

By default, Exchange Server 2007 sets the working directory to be the mailbox database directory under the directory where you installed Exchange Server. For example, if you install Exchange Server in the C:\Program Files\Exchange Server directory, Exchange Server 2007 sets the working directory as C:\ Program Files\Exchange Server\Mailbox\MDBTemp

To correct this warning, specify the working directory as a directory that exists on your Exchange server.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To specify the working directory using regedit

  1. Start Registry Editor (regedit).

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Update the Working Directory registry value with the correct working directory for the Microsoft Exchange Information Store service, such as C:\Program Files\Exchsrvr\mdbdata.

    Note:
    This change does not require that you restart the Microsoft Exchange Information Store service.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the Working Directory registry value, see the Knowledge Base article 298415, "Messages that have attachments are not delivered as expected, and Event ID 12003 and 327 messages are logged in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?Linkid=3052&kbid=298415).


Suppress out-of-office messages to distribution lists has been set
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-02-27

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether out-of-office messages are being suppressed for distribution lists:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\SuppressOOFsToDistributionLists

If the Exchange Server Analyzer finds the value for SuppressOOFsToDistributionLists to be greater than 0, a non-default configuration message is displayed.

When a message is sent to a mailbox that has the Out-of-Office Assistant enabled, the sender receives a message that does not have an address in the To or the Cc field, but it does have a distribution list in the Bcc field, an out-of-office message is sent to the distribution list that is in the Bcc field.

If a message is sent to a recipient, and the recipient is addressed only in the Bcc field, but not in a distribution list, and the recipient has turned on Out of Office Assistant, the recipient's mailbox store will still send an out-of-office message even though the SuppressOOFsToDistributionLists registry value is set. This limitation applies only if the recipient is addressed in the Bcc field, and the To and the Cc fields are blank. If there is at least one user in the To or Cc fields, the registry parameter on the Exchange Server computer will suppress the recipients listed in the Bcc field from generating an out-of-office message.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To modify out-of-office message generation behavior

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Right-click ParametersSystem, point to New, and then click DWORD Value.

  4. Name the new value SuppressOOFsToDistributionLists.

  5. Right-click SuppressOOFsToDistributionLists, and then click Modify.

  6. In the Value data box, type 1, and then click OK.

  7. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the SuppressOOFsToDistributionLists registry value, see the Knowledge Base article 825370, "Out-of-Office Messages Are Sent to Distribution Lists That Are in the BCC Field" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=825370).


The threshold value that controls how many times a corrupted message is allowed to pass through the store has been changed
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-08

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for the PoisonThreshold value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS \<ExchangeServerName> \Private- <PrivateInformationStoreGUID>

If the Exchange Server Analyzer determines that the value for PoisonThreshold does not equal 2, a non-default configuration message is displayed.

Versions of Exchange Server later than Exchange Server 2003 Service Pack 1 implement behavior that helps prevent corrupted or bad messages from causing the Microsoft Exchange Information Store service to stop unexpectedly or from preventing the Microsoft Exchange Information Store service to start successfully.

In Exchange Server 2003 Service Pack 1 or later, messages that cause the Microsoft Exchange Information Store service to stop unexpectedly during conversion from MAPI format to MIME format are tracked. The message ID of the corrupt message is stored in the registry when the crash occurs. If a corrupted message causes the store to stop unexpectedly three times, this information is used to prevent the message from being processed again when the Microsoft Exchange Information Store service is restarted the fourth time.

When the Microsoft Exchange Information Store service stops unexpectedly because of a corrupted message, the PoisonIDs registry value is created at:

HKLM\System\CurrentControlSet\Services\MSExchangeIS \<ExchangeServerName> \Private- <PrivateInformationStoreGUID>

Additionally, an administrator can create the PoisonThreshold registry entry. The PoisonThreshold key controls the maximum number of times a message is allowed to pass through the Exchange information store before it is added to the PoisonIDs registry key. By default, this threshold value is 2. To trigger the behavior, the threshold must be exceeded. Therefore, the Microsoft Exchange Information Store service can stop 3 times because of a corrupted message before that message is blocked. For example, if a message is involved in 3 crashes, the message is blocked because three is more than the threshold value of 2.

When a corrupted message event is written to the registry, error event messages (Event IDs 9680 and 9681) will appear in the Application event log. After the Microsoft Exchange Information Store service is successfully started, Exchange then blocks the message and attempts to send a non-delivery report for it. In some cases, Exchange may not be able to send a non-delivery report. In such cases, the blocked message may remain in the queue until it expires. The PoisonIDs registry key holds up to ten message ID values. When the limit of ten is exceeded, and a new corrupted message event is added. The corrupted message event that contains the oldest crash date is removed.

Note:
The steps to troubleshoot individual corrupted messages are beyond the scope of the Exchange Server Analyzer. In some cases, Microsoft Product Support Services may be able to help with troubleshooting individual corrupted messages. If you are experiencing problems with Exchange Server 2003 or later shutdowns because of corrupted messages, it may be helpful to enable automatic error reporting on the Exchange Server computer. Error report data is used to find and to fix problems in the software that you use. For more information about how to enable Exchange Error Reporting, see Exchange Error Reporting is disabled

It is recommended that the value for PoisonThreshold be changed backed to its default value of 2.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ExchangeServerName>\Private-<PrivateInformationStoreGUID>

  3. In the right pane, double-click PoisonThreshold.

  4. In the Value data, enter 2 (decimal) and click OK.

  5. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Tracing has been enabled on the Store process
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool checks the registry to see if the Enable Tracing registry entry exists along with the Trace User LegacyDN registry value. Both these registry values are present under the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSexchangeIS\ParametersSystem

If the Exchange Server Analyzer finds that both registry entries are present and configured, a warning is displayed.

The Enable Tracing DWORD registry value enables the Microsoft Exchange Information Store service for tracing. Tracing is used in troubleshooting Exchange store startup issues and can severely affect performance. Unless you are troubleshooting a problem, do not use this registry setting. Tracing can be enabled for specific users (filtered tracing) by adding the Trace User LegacyDN registry string value. If the Trace User LegacyDN value is not present, tracing is enabled for all users. If the Trace User LegacyDN value is present, tracing is being done for the specific users listed under that key.

If troubleshooting is not being performed on the Exchange Server computer, these registry values should not be present.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the Enable Tracing and Trace User LegacyDN registry values.

  4. Close the registry editor and restart the computer for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about per-user tracing on an Exchange server, see the Knowledge Base article 296624, "Per-User Tracing Feature Added to Exchange 2000 Server Service Pack 2 (SP2)" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=296624).


Tracing has been enabled on the Microsoft Exchange Information Store service for all users
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the registry to determine whether the Enable Tracing entry is present under:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSexchangeIS\ParametersSystem

If the Exchange Server Analyzer finds the Enable Tracing registry value present and configured, a warning is displayed.

The Enable Tracing DWORD registry value enables tracing for the Microsoft Exchange Information Store service. Tracing is used in troubleshooting store startup issues and can severely affect performance. Unless you are troubleshooting a problem, this registry setting should not be used. Tracing can be enabled for specific users by adding the Trace User LegacyDN registry string value. If this value is not present, it means that tracing is enabled for all users.

If troubleshooting is not being performed on the Exchange Server computer, this value should not be present.

Note:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, see the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Delete the Enable Tracing registry value.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for more information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about per-user tracing on an Exchange server, see the Knowledge Base article 296624, "Per-User Tracing Feature Added to Exchange 2000 Server Service Pack 2 (SP2)" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=296624).


Transaction log file names running out
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool verifies the health of the transaction log files for each storage group by checking the log files on the server disk. To find the location of the log files, the Exchange Server Analyzer queries the Active Directory® directory service. For each storage group object (class msExchStorageGroup), the file path to the log files is stored in the msExchESEParamLogFilePath attribute.

Transaction log file names include sequential hexadecimal numbers that identify the sequence of the log files. For example, the first log file for the default First Storage Group is named E0000001.log, the second is E0000002.log, and so on. The sequence can go as high as E00FFFFF.log. Exchange can create up to 1,030,000 unique log files. However, when Exchange reaches the end of the sequence, the stores in the affected storage group will no longer mount if they are dismounted after the limit is reached. If left mounted, the store will not dismount the databases even though no Jet operations can occur. Normally, Exchange can run for several years before reaching this limit.

You will see this message as a warning if the specified server has used more than 950,000 transaction log files.

You will see this message as an error if the specified server has used more than 1,020,000 transaction log files.

To allow the store to properly dismount the databases if this limit is reached, a fix has been included in Exchange Server 2003 Service Pack 1. A post-Service Pack 3 hotfix is available for Exchange 2000 Server, as described in the Microsoft Knowledge Base article 830408, "Exchange database stores remain mounted although all transaction logs that are available to a storage group have been used" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830408).

If Exchange has not yet reached the 1,030,000 transaction log limit, perform a full online backup of the server as soon as possible. For more information about performing a full online backup of the Exchange stores, see the Exchange 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?LinkId=47570).

If Exchange has reached this limit, you must move all existing transaction logs to another location. After you do this, a new sequence of log files that starts with 0x00001 will be generated. To ensure that the Exchange store will dismount the databases properly, you must also apply the appropriate fix for your version of Exchange.

Note:
Before you move the transaction logs, you must verify that all databases in the storage group are in a Clean Shutdown state.
Important:
After performing the procedure below, all previous backups will be invalidated. This does not mean that the backups cannot be restored. However, the backups can no longer be rolled forward with additional transaction logs. If you must restore a previous backup after you remove the transaction logs, you will be able to restore data only up to the time that the new log generation was created.

To resolve this problem

  1. For Exchange Server 2003, install Service Pack 1, available at the Exchange Server downloads Web site (http://go.microsoft.com/fwlink/?LinkId=29090).

    -or-

    For Exchange 2000 Server, obtain and install the hotfix referenced in the Microsoft Knowledge Base article 830408, "Exchange database stores remain mounted although all transaction logs that are available to a storage group have been used" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830408).

  2. In the storage group that has run out of transaction log files, dismount all databases. To do this, follow these steps:

    1. Open Exchange System Manager.

    2. Expand Administrative Groups, expand <AdministrativeGroupName>, expand Servers, expand <ServerName>, and then expand <StorageGroupName>.

    3. Right-click the first store in this storage group, and click Dismount Store. Repeat this step for each store in this storage group.

  3. Verify that each database in the storage group is in a Clean Shutdown state. To do this, follow these steps:

    1. In Exchange System Manager, right-click the first store in the storage group that has run out of transaction log files, and click Properties.

    2. Click the Database tab, and then note the paths and the file names of the database files in the Exchange database box and in the Exchange streaming database box. Each Exchange database is composed of a paired set of files that have the .edb file name extension and the .stm file name extension. Repeat this step for each store in the storage group.

    3. At a command prompt, change the directory to the Exchange Server bin folder. For example, change the directory to C:\Program Files\Exchsrvr\bin.

    4. Type Eseutil /mh DatabaseFileName, and then press Enter. Repeat this step for each database in the storage group. This command will display the database file header. The header will contain one of the following two lines: State: Clean Shutdown or State: Dirty Shutdown.

  4. If the header contains the line State: Dirty Shutdown, you must manually recover the database before you remove the log files. To do this, follow these steps:

    1. In Exchange System Manager, right-click the storage group that has run out of transaction log files, and click Properties.

    2. Click the General tab, and then note the paths of the transaction logs in the Transaction log location box.

    3. Note the path of the checkpoint file in the System path location box.

    4. At a command prompt, change the directory to the Exchange Server bin folder.

    5. Type the following command, and press Enter: Eseutil /r 3-CharacterLogfileBaseName /lDirectory:\LogfilePath /sDirectory:\CheckpointFilePath.

      Note:
      Do not type a space between the option switch and the directory paths. If you make a typographical error in the paths that are listed in the command, recovery may fail. To avoid this behavior, you can copy the checkpoint file to the transaction log file folder. At a command prompt that is defaulted to the log file directory, run the command Eseutil /r 3-CharacterLogfileBaseName. Because the /l switch and the /s switch default to the current directory, you do not have to provide the paths of the log files or the paths of the checkpoint files.
    6. After recovery has completed, verify that all database files are now in a Clean Shutdown state before you move the transaction log files and the checkpoint files. If you move the log files when a database is in a Dirty Shutdown state, you will not be able to restart the database. If you cannot recover all databases to the Clean Shutdown state, contact Microsoft Product Support Services for more information.

  5. In Exchange System Manager, right-click the storage group that has run out of transaction log files, and click Properties.

  6. Click the General tab, and then note the paths of the transaction logs in the Transaction log location box.

  7. Note the path of the checkpoint file in the System path location box.

  8. Move the transaction log files and the checkpoint file to another location. The log files have the .log file name extension and the checkpoint files have the .chk file name extension.

  9. In Exchange System Manager, right-click the first dismounted store in the storage group, and click Mount Store.

  10. Repeat this step for each store in the storage group. The log file sequence is now reset on the storage group.

  11. Perform a full backup of all the databases on the storage group.

For more information about service packs for Exchange Server, see the Exchange Server Web site (http://go.microsoft.com/fwlink/?LinkId=21573).


The VM Largest Block Size is low
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the VMLargestBlockSize key. The VMLargestBlockSize key represents the size (in bytes) of the largest available block of virtual memory.

Also, the Exchange Server Analyzer also queries the Active Directory® directory service to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer finds the value for VMLargestBlockSize more than 50000000 but less than 150000000 on an Exchange Server computer with more than 20 mailboxes, a warning is displayed.

Among other things, Exchange Server uses virtual memory to store messages when you convert them between MIME and MAPI formats, and as a buffer when committing messages from the transaction log and committing to the store. Frequently these operations require large contiguous chunks of virtual memory to complete quickly and efficiently. If this warning has been displayed, the virtual memory on the Exchange computer is depleted to less than 150 MB of contiguous space. This is known as virtual memory fragmentation.

If the virtual memory depletes too much, you may start to see error messages in the event log (Event ID 9582), which are virtual memory errors. If virtual memory is low enough, you will see Event ID 12800, which means messages are not being delivered because there is insufficient memory to process messages.

To resolve this warning, follow these recommendations in the order in which they are presented.

Look for error, "Maximum ESE cache size raised," in the Exchange Server Analyzer output.

If the error, Maximum ESE cache size raised, is returned on the same Exchange computer where this virtual memory fragmentation warning is returned, follow the recommendations in the article, Maximum ESE Cache is set too high.

The coupling of these two messages likely indicates that the virtual memory fragmentation issues are a result of the ESE cache being manually increased

Restart Exchange Information Store service

In the description of this error message, the Exchange Server Analyzer specifies the number of days that the Microsoft Exchange Information Store service has been running. If the number of days specified is more than 30, restart the service.

To restart the Microsoft Exchange Information Store service

  1. Open the Services MMC snap-in.

  2. Right-click Microsoft Exchange Information Store service, and then click Restart.

Evaluate message size limits

If you have many users sending large messages (more than 30 MB), virtual memory may become fragmented sooner than it otherwise might have if many users did not send large messages. As mentioned, virtual memory is used as a buffer when the store process moves data from log files and commits it to the store. If the data being moved is frequently large, then big, contiguous chunks of virtual memory are consumed quickly.

If large data is regularly sent using e-mail, and that data is sent internally, consider setting up shared directories on file servers where users can post large pieces of data.

It is recommended setting the maximum message size limit to no more than 30 MB. However, if you need a higher message size limit for messages with large attachments to be sent through your Exchange organization, you may want to increase the maximum outgoing message size limit above 30 MB. In addition to virtual memory fragmentation, increasing the message size limit over 30 MB can cause your system to be more vulnerable to malicious attacks. It is not recommended to allow more than a 30 MB message size limit.

To set message size limits

  1. In Exchange System Manager, expand Global Settings, right-click Message Delivery, and then click Properties.

  2. In the Message Delivery Properties dialog box, on the Defaults tab, select the Sending message size limit option and enter the size limit you want.

Verify that antivirus software is up-to-date

Sometimes, outdated antivirus software that is being run in Exchange Virus Scanning API (VSAPI) mode will cause virtual memory fragmentation. If you are running antivirus software in VSAPI mode, contact your antivirus vendor and verify that you are running the latest version of their software and drivers.

Move mailboxes to another Exchange server

If you have worked through all the procedures, and the Exchange Server Analyzer is still displaying this warning, you must move mailboxes off of the affected server to reduce its load. There are too many mailboxes on this server.

To move mailboxes on Exchange 2000 Server and Exchange Server 2003

  1. In Active Directory Users and Computers, select the user or users whose mailboxes you want to move.

  2. Right-click the user list you selected in the previous step, and then click Exchange Tasks.

  3. In the Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

  4. Carefully read and follow the remaining steps in the wizard.

To move mailboxes on Exchange Server 2003

  1. In Exchange System Manager, expand Servers, expand the server from which you want to move mailboxes, expand the Storage Group from which you want to move mailboxes, expand the Mailbox Store that contains the mailboxes that you want to move, and then click Mailboxes.

  2. In the details pane, right-click the user or users whose mailboxes you want to move, and then click Exchange Tasks.

  3. In the Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

  4. Carefully read and follow the remaining steps in the wizard.

For more information about resolving virtual memory fragmentation issues, see the following Microsoft Knowledge Base articles:

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 838233, "Your computer may slow or stop responding and repeatedly log event IDs 9582 and 1160 in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=838233)

For more details about setting message size limits, see the Knowledge Base article 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679)

For more information about moving mailboxes, see the following Knowledge Base articles:

  • 328810, "Moving mailboxes between servers" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328810)

  • 821829, "Moving mailboxes in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821829)


The VM Largest Block Size is reaching critical point
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the VMLargestBlockSize key. The VMLargestBlockSize key represents the size (in bytes) of the largest available block of virtual memory.

In addition, the Exchange Server Analyzer queries the Active Directory® directory service to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer finds the value for VMLargestBlockSize greater than 0 but less than 50000001 on an Exchange Server computer with more than 20 mailboxes, an error is displayed.

Among other things, Exchange server uses virtual memory to store messages when converting them between MIME and MAPI formats and as a buffer when committing messages from the transaction log and committing to the store. Often these operations require large contiguous chunks of virtual memory to complete quickly and efficiently. If this error has been displayed, the virtual memory on the Exchange computer is depleted to less than 50 MB of contiguous space. This is known as virtual memory fragmentation. An Exchange mailbox server running with less than 50 MB of contiguous virtual memory space is a critical error.

If the virtual memory depletes too much, you may begin to see error alerts in the event log (Event ID 9582), which are virtual memory errors. If virtual memory is low enough, you will see Event ID 12800, which means messages are not being delivered because there is not enough memory to process messages.

To remedy this error follow the recommendations below in the order they are presented.

Look for error, "Maximum ESE cache size raised," in the Exchange Server Analyzer output.

If the error, Maximum ESE cache size raised, is returned on the same Exchange computer where this virtual memory fragmentation warning is returned, follow the recommendations in the article, Maximum ESE Cache is set too high.

The coupling of these two alerts likely indicates that the virtual memory fragmentation issues are a result of the ESE cache being manually increased

Restart Exchange Information Store service

In the description of this alert, the Exchange Server Analyzer specifies the number of days that the Microsoft Exchange Information Store service has been running. If the number of days specified is more than 30, restart the service.

To restart the Exchange Information Store

  1. Open the Services MMC snap-in.

  2. Right-click Microsoft Exchange Information Store service, and then click Restart.

Evaluate message size limits

If you have many users sending large messages (in excess of 30 MB), virtual memory may become fragmented sooner than it otherwise might if many users did not send large messages. As mentioned above, virtual memory is used as a buffer when the store process moves data from log files and commits it to the store. If the data being moved is frequently large, big, contiguous chunks of virtual memory are consumed quickly.

If large data is routinely sent using e-mail, and that data is sent internally, consider setting up shared directories on file servers on which users can post large pieces of data.

It is recommended that you set the maximum message size limit to no more than 30 MB. However, if you need a higher message size limit for messages with large attachments to be sent through your Exchange organization, you may want to increase the maximum outgoing message size limit above 30 MB. In addition to virtual memory fragmentation, increasing the message size limit over 30 MB can cause your system to be more vulnerable to malicious attacks. Thus, allowing more than a 30 MB message size limit is not recommended.

To set message size limits

  1. In Exchange System Manager, expand Global Settings, right-click Message Delivery, and then click Properties.

  2. In the Message Delivery Properties dialog box, on the Defaults tab, select the Sending message size limit option and enter the size limit you want.

Verify that antivirus software is up-to-date

In some cases, outdated antivirus software that is being run in Exchange Virus Scanning API (VSAPI) mode will cause virtual memory fragmentation. If you are running antivirus software in VSAPI mode, contact your antivirus vendor and verify that you are running the latest version of their software and drivers.

Move mailboxes to another Exchange server

If you have worked through all of the above procedures, and the Exchange Server Analyzer is still displaying this error, or the warning version of this alert (where less than 150 MB of contiguous virtual memory space is left), you must move mailboxes off of the affected server to reduce its load. There are too many mailboxes on this server.

To move mailboxes on Exchange 2000 Server and Exchange Server 2003

  1. In Active Directory Users and Computers, select the user or users whose mailboxes you want to move.

  2. Right-click the user list you selected in the previous step, and then click Exchange Tasks.

  3. In the Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

  4. Carefully read and follow the remaining steps in the wizard.

To move mailboxes on Exchange Server 2003

  1. In Exchange System Manager, expand Servers, expand the server from which you want to move mailboxes, expand the Storage Group from which you want to move mailboxes, expand the Mailbox Store that contains the mailboxes that you want to move, and then click Mailboxes.

  2. In the details pane, right-click the user or users whose mailboxes you want to move, and then click Exchange Tasks.

  3. In the Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

  4. Carefully read and follow the remaining steps in the wizard.

For more information about resolving virtual memory fragmentation issues, see the following Microsoft Knowledge Base articles:

  • 325044, "HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 838233, "Your computer may slow or stop responding and repeatedly log event IDs 9582 and 1160 in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=838233)

For more information about setting message size limits, see the Knowledge Base article 322679, "Set Size Limits for Messages," (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679).

For more information about moving mailboxes, see the following Knowledge Base articles:

  • 328810, "Moving mailboxes between servers," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328810)

  • 821829, "Moving mailboxes in Exchange Server 2003," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821829)


VirtualReserveSize is non-default
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether the initial memory allocation for the Exchange Interprocess Communication (ExIPC) component has been changed from the default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EXIPC\Parameters\VirtualReserveSize

If the Exchange Server Analyzer finds that the VirtualReserveSize key is present and configured with a value greater than 0, a non-default configuration message is displayed.

ExIPC is a queuing component that permits Inetinfo.exe (Internet Information Services) and Store.exe (Microsoft Exchange Information Store service) to move data back and forth quickly. Generally, the default initial memory allocation for ExIPC is sufficient. By default, the VirtualReserveSize key is not present. It should be added and configured only at the direction of Microsoft Consulting Services or Microsoft Product Support Services.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\EXIPC\Parameters

  3. Delete the VirtualReserveSize key.

  4. Close the registry editor, and restart the Microsoft Exchange Information Store service and the IIS Admin Service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about ExIPC, see the following Knowledge Base articles:

  • 821879, "Definitions of key transport components in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821879)

  • 260995, "XCON: Definitions of Key Transport Components in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260995)


Virtual memory event interval has been overridden
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the threshold for logging an event regarding virtual memory fragmentation has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ VM Info Update Interval

If the Exchange Server Analyzer finds the VM Info Update Interval registry value present but not equal to 3600, a non-default configuration message is displayed.

In 32-bit Microsoft Windows® systems, there are two kinds of memory: physical memory (the amount of actual memory installed in the system) and virtual memory address space (a virtualized 4 gigabyte memory space). Regardless of how much physical memory is installed on the system, the total size of the virtual address space is always the same: 4 GB. Although it is not the case for all 32-bit applications, for Exchange Server, virtual address space equals virtual memory; in other words, the terms are used interchangeably.

During the regular course of its operations, the Microsoft Exchange Information Store service will repeatedly allocate, use, and de-allocate virtual memory. When virtual memory is allocated, used, and de-allocated frequently, it can cause virtual memory fragmentation. Virtual memory fragmentation is similar to file system fragmentation that can occur over time. After a while, allocated segments of virtual memory are no longer contiguous, and performance begins to suffer. For the file system, you can run an application that performs defragmentation of the file system, and most of the time you can do this while the system is online and being accessed. For virtual memory fragmentation, there is no defragmentation tool; instead, to correct the problem you must stop and start the Microsoft Exchange Information Store service or restart the system.

By default, the Microsoft Exchange Information Store service checks for free virtual memory once an hour (for example, every 3,600 seconds). The VM Info Update Interval registry value represents a configuration opportunity that lets an administrator override the default 3,600 seconds interval. If you do override the default level, it is recommended that you do not set the value lower than 5 minutes (300 seconds).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. In the right pane, delete the value for VM Info Update Interval.

  4. Close the registry editor and restart the Microsoft Exchange Information Store service for the change to take effect.

For more information about troubleshooting virtual memory fragmentation in Exchange Server 2003 and Exchange 2000 Server, see the 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).


Write-Back Cache Not Enabled
Microsoft Exchange Server Analyzer - Articles > Storage >

Topic Last Modified: 2006-08-18

The Microsoft® Exchange Server Analyzer Tool has determined that your disk array controller does not have the write-back cache set correctly for the drives that host the transaction logs.

It is recommended that you enable the write-back cache to 100 percent on your array controller for all drives that host transaction logs. Transaction logs are rarely read from. The more write speed that is available to a transaction log drive, the better a server that is running Exchange Server will perform.

To correct this warning

  • Enable write-back cache.

For more information about how to configure Exchange server hard disks, see Microsoft Knowledge Base article 188589, "Exchange DB and caching hard disks and controllers," (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=188589).


Third-Party Software
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2005-11-18

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating with regard to third-party software. Additionally, these articles describe actions that you can take to resolve third-party software-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


Anti-Virus folder exclusions have not been configured
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Symantec AntiVirus Corporate Edition (Symantec AV) is installed on the Exchange Server, and RealTime Protection (RTP) is enabled:

HKEY_LOCAL_MACHINE\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Storages\Filesystem\RealTimeScan

If the Exchange Server Analyzer finds that the HaveExceptionDirs registry value is set to 0, the Exchange Server Analyzer displays an error. A HaveExceptionDirs registry value of 0 indicates that folder exclusions are disabled.

Folder exclusions prevent specific folders from being scanned during real-time antivirus scanning. If you have not enabled folder exclusions on your Exchange Server, the following problems can occur:

  • Symantec AV RTP may provide false positive reports on certain clean files that are accessed during ordinary program activity.

  • Symantec AV RTP may incorrectly report infected files in software that your corporate security policy already permits to run on your Exchange Server.

  • Symantec AV RTP may scan the Exchange Server directory structure and cause inaccurate virus detections, unexpected behavior on the Exchange server, or damage to the Exchange Server databases.

Important:
You must never run file-based scanning software against Exchange Server databases, logs, temporary files, Internet Information Services (IIS) system files, or the installable file system (IFS) drive (drive M). Configure antivirus software to avoid scanning the folders that contain these files.

You can run file-based antivirus software against the operating system of the Exchange Server computer and against Exchange Server program files (the Exchsrvr\Bin folder). However, do not run file-based antivirus software against the following files and folders:

  • Exchange Server databases (.mdb and .stm files) and transaction log (.log) files (default location: \Exchsrvr\MDBData)

  • Exchange Server .mta files (default location: \Exchsrvr\Mtadata)

  • Exchange Server message tracking log files (default location: \Exchsrvr\Server_Name.log)

  • Virtual server folders (default location: \Exchsrvr\Mailroot)

  • Site Replication Service (SRS) files (default location: \Exchsrvr\Srsdata)

  • Internet Information Service (IIS) system files (default location: \%SystemRoot%\System32\Inetsrv)

  • Internet Mail Connector files (default location: \Exchsrvr\IMCData)

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this working folder is located at \Exchsrvr\MDBData

  • A temporary folder that is used together with offline maintenance utilities, such as Eseutil.exe. By default, this folder is the location that you run the .exe files from, but you can configure this when you run the utility.

You can run file-based scanning against the following folders:

  • Exchsrvr\Address

  • Exchsrvr\Bin

  • Exchsrvr\Exchweb

  • Exchsrvr\Res

  • Exchsrvr\Schema

For detailed information about how to configure exclusions on RealTime scanning in Symantec AntiVirus Corporate Edition, see the Symantec antivirus Web site (http://www.symantec.com).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites that are mentioned here.

For more information about fortifying an Exchange Server environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange Server computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Antigen Is Scanning Public Folder Replication Messages
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-03-13

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether a public folder store is present on each Exchange server. If the Exchange Server Analyzer finds that the InformationStore object is of the msExchPublicMDB object class, the server hosts a public folder store.

The Microsoft® Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for ANTIGENVSAPI.DLL. A Version key value of 1517 or greater for ANTIGENVSAPI.DLL indicates that Sybari Antigen for Microsoft Exchange version 8.0 SR3 or a later version is installed on the Exchange Server.

Finally, the Exchange Server Analyzer queries following registry branch to determine whether the DoNotScanIPMReplicationMessages key is present and does not have a value that is larger than 0:

HKEY_LOCAL_MACHINE\Software\Sybari Software\Antigen for Exchange\DoNotScanIPMReplicationMessages

The value of the DoNotScanIPMReplicationMessages key determines whether the installed Sybari Antigen will scan, and possibly remove, the Exchange Server public folder replication messages. A value of anything less than 1 for the DoNotScanIPMReplicationMessages key means that Antigen will scan the winmail.dat files for viruses. Exchange Server uses the Winmail.dat files for several purposes, including making public folder replication easier between servers. If Antigen modifies any one of these Winmail.dat files, the public folder replication process fails.

If the Exchange Server Analyzer determines that following conditions exist, the Exchange Server Analyzer displays an error:

  • The Exchange Server is hosting one ore more public folder stores

  • Sybari Antigen build 1517 or a later version is installed on the server

  • The DoNotScanIPMReplicationMessages key is not present or, is present but does not have a value larger than 0.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Sybari Software\Antigen for Exchange

  3. If the DoNotScanIPMReplicationMessages.subkey already exists in the right pane, double-click it and set the value to 1.

  4. If the DoNotScanIPMReplicationMessages.subkey does not yet exist, right-click in the right pane to create it as a new DWORD value.

  5. Configure the DoNotScanIPMReplicationMessages value with a setting of 1.

    Note:
    If a virus is replicated through public folder replication, even if you enable this new registry key, Antigen will still detect the virus on the Real-Time scan job

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841).

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105).

  • 245822, "Recommendations for troubleshooting an Exchange Server computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822).


CA eTrust: EML/LOG/EDB/STM/DAT files are not in the real-time file exclusion list
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to obtain the list of file extensions that have been excluded from the real-time file-level antivirus scanning in eTrust Antivirus from Computer Associates:

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\szExcludeExtList

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeExtList

If the Exchange Server Analyzer finds that the value for szExcludeExtList does not include file extensions that correspond to an Exchange data file type (.eml, .log, .edb, .stm, or .dat), a warning is displayed.

eTrust Antivirus is a file-level antivirus scanning program. To determine the version of eTrust Antivirus installed on your Exchange Server computer, do the following:

  1. Navigate to Start | Programs | eTrust Antivirus, and then click eTrust Antivirus to start the application.

  2. On the eTrust Antivirus application menu, click Help, and then click About eTrust Antivirus.

  3. Examine the Product Version field to determine the version of eTrust Antivirus.

The following issues can occur when you use file-level scanners on an Exchange Server computer:

  • File-level scanners scan a file when it is used or at a scheduled interval, and may lock or quarantine an Exchange log or database file while Exchange tries to use the file. This can cause a severe failure in Exchange Server, and can also generate database errors.

  • More problems can occur if you scan the drive represented by the Exchange Installable File System (IFS)—typically drive M—with file-level scanner software.

Regardless of which file-level antivirus program that you use, you should always exclude the following files and folders from file-level scanners:

  • .eml, .edb, .stm, .log, .dat and .chk files.

  • The Exchange Server drive represented by the IFS. By default, this is drive M.

  • Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.

  • Exchange MTA files in the Exchsrvr\Mtadata folder.

  • Additional log files such as the Exchsrvr\server_name.log file.

  • The Exchsrvr\Mailroot virtual server folder.

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.

  • The temporary folder that is used with offline maintenance tools such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure the location when you run the tool.

  • Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.

  • Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.

  • IIS working files in the %SystemRoot%\IIS Temporary Compressed Files folder.

To correct this warning

  1. Use the eTrust Antivirus user interface to exclude the above listed folders and files from file-level antivirus scanning.

  2. Visit the CA eTrust Antivirus Web site (http://www3.ca.com/Solutions/Product.asp?ID=156) for the latest information about using eTrust Antivirus on an Exchange Server computer.

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).

For more information about problems that can occur if you scan the IFS drive, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM: C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange data drive has not been excluded from manual job scanning
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to obtain the list of directories that have been excluded from manual file-level antivirus scanning in eTrust Antivirus from Computer Associates:

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Job\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Job\szExcludeDirs

The Exchange Server Analyzer also reads the value for the MsExchESEParamSystemPath attribute in the Active Directory® directory service, which is a storage group attribute that corresponds to the Exchange system data file location.

If the Exchange Server Analyzer finds that the value for szExcludeDirs does not include the path that corresponds to the Exchange system data file location, a warning is displayed.

eTrust Antivirus is a file-level antivirus scanning program. To determine the version of eTrust Antivirus installed on your Exchange Server computer:

  1. Navigate to Start | Programs | eTrust Antivirus, and then click eTrust Antivirus to start the application.

  2. On the eTrust Antivirus application menu, click Help, and then click About eTrust Antivirus.

  3. Examine the Product Version field to determine the version of eTrust Antivirus.

The following issues can occur when you use file-level scanners on an Exchange Server computer:

  • File-level scanners scan a file when it is used or at a scheduled interval, and may lock or quarantine an Exchange log or database file while Exchange tries to use the file. This can cause a severe failure in Exchange Server, and can also generate database errors.

  • More problems can occur if you scan the drive represented by the Exchange Installable File System (IFS)—typically drive M—with file-level scanner software.

Regardless of which file-level antivirus program that you use, you should always exclude the following files and folders from file-level scanners:

  • .eml, .edb, .stm, .log, .dat and .chk files.

  • The Exchange Server drive represented by the IFS. By default, this is the M drive.

  • Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.

  • Exchange MTA files in the Exchsrvr\Mtadata folder.

  • Additional log files such as the Exchsrvr\server_name.log file.

  • The Exchsrvr\Mailroot virtual server folder.

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.

  • The temporary folder that is used with offline maintenance tools such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure this location when you run the tool.

  • Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.

  • Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.

  • IIS working files in the %SystemRoot%\IIS Temporary Compressed Files folder.

To correct this warning

  1. Use the eTrust Antivirus user interface to exclude the above listed folders and files from file-level antivirus scanning.

  2. Visit the CA eTrust Antivirus Web site (http://www3.ca.com/Solutions/Product.asp?ID=156) for the latest information about using eTrust Antivirus on an Exchange Server computer.

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).

For more information about problems that can occur if you scan the IFS drive, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM: C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange data drive has not been excluded from real-time scanning
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to obtain the list of directories that have been excluded from the real-time file-level antivirus scanning in eTrust Antivirus from Computer Associates:

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeDirs

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value for the MsExchESEParamSystemPath attribute of each storage group. This attribute represents the path of the Exchange data files.

If the Exchange Server Analyzer finds that the value for szExcludeDirs does not include the path that corresponds to the Exchange system data file location, a warning is displayed.

eTrust Antivirus is a file-level antivirus scanning program. To determine the version of eTrust Antivirus installed on your Exchange Server computer:

  1. Navigate to Start | Programs | eTrust Antivirus, and then click eTrust Antivirus to start the application.

  2. On the eTrust Antivirus application menu, click Help, and then click About eTrust Antivirus.

  3. Examine the Product Version field to determine the version of eTrust Antivirus.

The following issues can occur when you use file-level scanners on an Exchange Server computer:

  • File-level scanners scan a file when it is used or at a scheduled interval, and may lock or quarantine an Exchange log or database file while Exchange tries to use the file. This can cause a severe failure in Exchange Server, and can also generate database errors.

  • More problems can occur if you scan the drive represented by the Exchange Installable File System (IFS)—typically drive M—with file-level scanner software.

Regardless of which file-level antivirus program you use, you should always exclude the following files and folders from file-level scanners:

  • .eml, .edb, .stm, .log, .dat and .chk files.

  • The Exchange Server drive represented by the IFS. By default, this is drive M.

  • Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.

  • Exchange MTA files in the Exchsrvr\Mtadata folder.

  • Additional log files such as the Exchsrvr\server_name.log file.

  • The Exchsrvr\Mailroot virtual server folder.

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.

  • The temporary folder that is used with offline maintenance tools such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure the location when you run the tool.

  • Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.

  • Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.

  • IIS working files in the %SystemRoot%\IIS Temporary Compressed Files folder.

To correct this warning

  1. Use the eTrust Antivirus user interface to exclude the above listed folders and files from file-level antivirus scanning.

  2. Visit the CA eTrust Antivirus Web site (http://www3.ca.com/Solutions/Product.asp?ID=156) for the latest information about using eTrust Antivirus on an Exchange Server computer.

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).

For more information about problems that can occur if you scan the IFS drive, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM:C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange IFS path has not been excluded from manual job scanning
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to obtain the list of directories that have been excluded from manual file-level antivirus scanning in eTrust Antivirus from Computer Associates:

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Job\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Job\szExcludeDirs

The Exchange Server Analyzer also reads the following registry entry to obtain the drive letter that represents the Exchange Installable File System (IFS) drive:

HKLM\System\CurrentControlSet\Services\EXIFS\Parameters\DriveLetter

On Exchange 2000 Server, the default drive letter is M. The IFS drive is turned off by default in Exchange Server 2003.

If the Exchange Server Analyzer finds that the value for szExcludeDirs does not include the path that corresponds to the IFS drive, a warning is displayed.

eTrust Antivirus is a file-level antivirus scanning program. To determine the version of eTrust Antivirus installed on your Exchange Server computer, do the following:

  1. Navigate to Start | Programs | eTrust Antivirus, and then click eTrust Antivirus to start the application.

  2. On the eTrust Antivirus application menu, click Help, and then click About eTrust Antivirus.

  3. Examine the Product Version field to determine the version of eTrust Antivirus.

The following issues can occur when you use file-level scanners on an Exchange Server computer:

  • File-level scanners scan a file when it is used or at a scheduled interval, and may lock or quarantine an Exchange log or database file while Exchange tries to use the file. This can cause a severe failure in Exchange Server, and can also generate database errors.

  • More problems can occur if you scan the drive represented by the IFS—typically drive M—with file-level scanner software.

Regardless of which file-level antivirus program that you use, you should always exclude the following files and folders from file-level scanners:

  • .eml, .edb, .stm, .log, .dat and .chk files.

  • The Exchange Server drive represented by the IFS. By default, this is drive M.

  • Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.

  • Exchange MTA files in the Exchsrvr\Mtadata folder.

  • Additional log files such as the Exchsrvr\server_name.log file.

  • The Exchsrvr\Mailroot virtual server folder.

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.

  • The temporary folder that is used with offline maintenance tools such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure the location when you run the tool.

  • Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.

  • Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.

  • IIS working files in the %SystemRoot%\IIS Temporary Compressed Files folder.

To correct this warning

  1. Use the eTrust Antivirus user interface to exclude the above listed folders and files from file-level antivirus scanning.

  2. Visit the Computer Associates eTrust Antivirus Web site (http://www3.ca.com/Solutions/Product.asp?ID=156) for the latest information about using eTrust Antivirus on an Exchange Server computer.

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).

For more information about problems that can occur if you scan the IFS drive, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM: C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange IFS path has not been excluded from real-time scanning
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to obtain the list of directories that have been excluded from real-time file-level antivirus scanning in eTrust Antivirus from Computer Associates:

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeDirs

The Exchange Server Analyzer also reads the following registry entry to obtain the drive letter that represents the Exchange Installable File System (IFS) drive:

HKLM\System\CurrentControlSet\Services\EXIFS\Parameters\DriveLetter

On Exchange 2000 Server the default drive letter is M. By default, the IFS drive is turned off in Exchange Server 2003.

If the Exchange Server Analyzer finds that the value for szExcludeDirs does not include the path that corresponds to the IFS drive, a warning is displayed.

eTrust Antivirus is a file-level antivirus scanning program. To determine the version of eTrust Antivirus installed on your Exchange Server computer, do the following:

  1. Navigate to Start | Programs | eTrust Antivirus, and then click eTrust Antivirus to start the application.

  2. On the eTrust Antivirus application menu, click Help, and then click About eTrust Antivirus.

  3. Examine the Product Version field to determine the version of eTrust Antivirus.

The following issues can occur when you use file-level scanners on an Exchange Server computer:

  • File-level scanners scan a file when it is used or at a scheduled interval, and may lock or quarantine an Exchange log or database file while Exchange tries to use the file. This can cause a severe failure in Exchange Server, and can also generate database errors.

  • More problems can occur if you scan the drive represented by the IFS—typically drive M—with file-level scanner software.

Regardless of which file-level antivirus program that you use, you should always exclude the following files and folders from file-level scanners:

  • .eml, .edb, .stm, .log, .dat and .chk files.

  • The Exchange Server drive represented by the IFS. By default, this is drive M.

  • Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.

  • Exchange MTA files in the Exchsrvr\Mtadata folder.

  • Additional log files such as the Exchsrvr\server_name.log file.

  • The Exchsrvr\Mailroot virtual server folder.

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.

  • The temporary folder that is used with offline maintenance tools such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure the location when you run the tool.

  • Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.

  • Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.

  • IIS working files in the %SystemRoot%\IIS Temporary Compressed Files folder.

To correct this warning

  1. Use the eTrust Antivirus user interface to exclude the above listed folders and files from file-level antivirus scanning.

  2. Visit the CA eTrust Antivirus Web site (http://www3.ca.com/Solutions/Product.asp?ID=156) for the latest information about using eTrust Antivirus on an Exchange Server computer.

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).

For more information about problems that can occur if you scan the IFS drive, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM: C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Real-time scanning is set to scan all files regardless of extension
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to obtain the list of file name extensions that have been excluded from the real-time file-level antivirus scanning in eTrust Antivirus from Computer Associates:

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\dwFileFilterType

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\dwFileFilterType

If the Exchange Server Analyzer determines that the value for dwFileFilterType is configured to scan all files regardless of the file name extension, a warning is displayed.

eTrust Antivirus is a file-level antivirus scanning program. To determine the version of eTrust Antivirus installed on your Exchange Server computer, do the following:

  1. Navigate to Start | Programs | eTrust Antivirus, and then click eTrust Antivirus to start the application.

  2. On the eTrust Antivirus application menu, click Help, and then click About eTrust Antivirus.

  3. Examine the Product Version field to determine the version of eTrust Antivirus.

The following issues may occur when you use file-level scanners on an Exchange Server computer:

  • File-level scanners scan a file when it is used or at a scheduled interval, and may lock or quarantine an Exchange log or database file while Exchange tries to use the file. This can cause a severe failure in Exchange Server, and can also generate database errors.

  • More problems can occur if you scan the drive represented by the Exchange Installable File System (IFS)—typically drive M—with file-level scanner software.

Regardless of which file-level antivirus program that you use, you should always exclude the following files and folders from file-level scanners:

  • .eml, .edb, .stm, .log, .dat and .chk files.

  • The Exchange Server drive represented by the IFS. By default, this is the M: drive.

  • Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.

  • Exchange MTA files in the Exchsrvr\Mtadata folder.

  • Additional log files such as the Exchsrvr\server_name.log file.

  • The Exchsrvr\Mailroot virtual server folder.

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.

  • The temporary folder that is used with offline maintenance tools such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure the location when you run the tool.

  • Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.

  • Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.

  • IIS working files in the %SystemRoot%\IIS Temporary Compressed Files folder.

To correct this warning

  1. Use the eTrust Antivirus user interface to exclude the listed folders and files from file-level antivirus scanning.

  2. Visit the CA eTrust Antivirus Web site (http://www3.ca.com/Solutions/Product.asp?ID=156) for the latest information about using eTrust Antivirus on an Exchange Server computer.

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).

For more information about problems that can occur if you scan the IFS drive, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM:C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Storage Group drive has not been excluded from manual job scanning
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to obtain the list of directories that have been excluded from manual file-level antivirus scanning in eTrust Antivirus from Computer Associates:

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Job\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Job\szExcludeDirs

The Exchange Server Analyzer also reads the value for the MsExchESEParamSystemPath attribute in the Active Directory® directory service, which is a storage group attribute that corresponds to the Exchange system log file location.

If the Exchange Server Analyzer finds that the value for szExcludeDirs does not include the path that corresponds to the Exchange system log file location, a warning is displayed.

eTrust Antivirus is a file-level, antivirus scanning program. To determine the version of eTrust Antivirus installed on your Exchange Server computer do the following:

  1. Navigate to Start | Programs | eTrust Antivirus, and then click eTrust Antivirus to start the application.

  2. On the eTrust Antivirus application menu, click Help, and then click About eTrust Antivirus.

  3. Examine the Product Version field to determine the version of eTrust Antivirus.

The following issues can occur when you use file-level scanners on an Exchange Server computer:

  • File-level scanners scan a file when it is used or at a scheduled interval, and may lock or quarantine an Exchange log or database file while Exchange tries to use the file. This can cause a severe failure in Exchange Server, and can also generate database errors.

  • More problems can occur if you scan the drive represented by the Exchange Installable File System (IFS)—typically drive M—with file-level scanner software.

Regardless of which file-level antivirus program that you use, you should always exclude the following files and folders from file-level scanners:

  • .eml, .edb, .stm, .log, .dat and .chk files.

  • The Exchange Server drive represented by the IFS. By default, this is drive M.

  • Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.

  • Exchange MTA files in the Exchsrvr\Mtadata folder.

  • Additional log files such as the Exchsrvr\server_name.log file.

  • The Exchsrvr\Mailroot virtual server folder.

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.

  • The temporary folder that is used with offline maintenance tools such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure the location when you run the tool.

  • Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.

  • Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.

  • IIS working files in the %SystemRoot%\IIS Temporary Compressed Files folder.

To correct this warning

  1. Use the eTrust Antivirus user interface to exclude the above listed folders and files from file-level antivirus scanning.

  2. Visit the Computer Associates eTrust Antivirus Web site (http://www3.ca.com/Solutions/Product.asp?ID=156) for the latest information about using eTrust Antivirus on an Exchange Server computer.

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

  • For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).

For more information about problems that can occur if you scan the IFS drive, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM: C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Storage Group drive has not been excluded from real-time scanning
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to obtain the list of directories that have been excluded from the real-time file-level antivirus scanning in eTrust Antivirus from Computer Associates:

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeDirs

The Exchange Server Analyzer also queries the value for the MsExchESEParamSystemPath attribute in the Active Directory® directory service, which is a storage group attribute that corresponds to the Exchange system data file location.

If the Exchange Server Analyzer finds that the value for szExcludeDirs does not include the path that corresponds to the Exchange system data file location, a warning is displayed.

eTrust Antivirus is a file-level antivirus scanning program. To determine the version of eTrust Antivirus installed on your Exchange Server computer:

  1. Navigate to Start | Programs | eTrust Antivirus, and then click eTrust Antivirus to start the application.

  2. On the eTrust Antivirus application menu, click Help, and then click About eTrust Antivirus.

  3. Examine the Product Version field to determine the version of eTrust Antivirus.

The following issues can occur when you use file-level scanners on an Exchange Server computer:

  • File-level scanners scan a file when it is used or at a scheduled interval, and may lock or quarantine an Exchange log or database file while Exchange tries to use the file. This can cause a severe failure in Exchange Server, and can also generate database errors.

  • More problems can occur if you scan the drive represented by the Exchange Installable File System (IFS)—typically drive M—with file-level scanner software.

Regardless of which file-level antivirus program that you use, you should always exclude the following files and folders from file-level scanners:

  • .eml, .edb, .stm, .log, .dat and .chk files.

  • The Exchange Server drive represented by the IFS. By default, this is drive M.

  • Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.

  • Exchange MTA files in the Exchsrvr\Mtadata folder.

  • Additional log files such as the Exchsrvr\server_name.log file.

  • The Exchsrvr\Mailroot virtual server folder.

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.

  • The temporary folder that is used with offline maintenance tools such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure the location when you run the tool.

  • Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.

  • Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.

  • IIS working files in the %SystemRoot%\IIS Temporary Compressed Files folder.

To correct this warning

  1. Use the eTrust Antivirus user interface to exclude the above listed folders and files from file-level antivirus scanning.

  2. Visit the CA eTrust Antivirus Web site (http://www3.ca.com/Solutions/Product.asp?ID=156) for the latest information about using eTrust Antivirus on an Exchange Server computer.

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).

For more information about problems that can occur if you scan the IFS drive, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM: C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange process has not been excluded from real-time scanning
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to obtain the list of processes that have been excluded from real-time file-level antivirus scanning in eTrust Antivirus from Computer Associates:

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\RealTime\szExcludeProcessNames

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeProcessNames

If the Exchange Server Analyzer finds that the value for szExcludeProcessNames does not include STORE.EXE, EMSMTA.EXE and MAD.EXE, a warning is displayed.

It is recommended that you do not scan the Microsoft Exchange Information Store process (Store.exe), the Exchange MTA process (Emsmta.exe) or the System Attendant process (Mad.exe) with a file-level based antivirus scanner while the these processes are running.

eTrust Antivirus is a file-level antivirus scanning program. To determine the version of eTrust Antivirus installed on your Exchange Server computer, do the following:

  1. Navigate to Start | Programs | eTrust Antivirus, and then click eTrust Antivirus to start the application.

  2. On the eTrust Antivirus application menu, click Help, and then click About eTrust Antivirus.

  3. Examine the Product Version field to determine the version of eTrust Antivirus.

The following issues can occur when you use file-level scanners on an Exchange Server computer:

  • File-level scanners scan a file when it is used or at a scheduled interval, and may lock or quarantine an Exchange log or database file while Exchange tries to use the file. This can cause a severe failure in Exchange Server, and can also generate database errors.

  • More problems can occur if you scan the drive represented by the IFS—typically drive M—with file-level scanner software.

Regardless of which file-level antivirus program that you use, you should always exclude the following files and folders from file-level scanners:

  • .eml, .edb, .stm, .log, .dat and .chk files.

  • The Exchange Server drive represented by the IFS. By default, this is drive M.

  • Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.

  • Exchange MTA files in the Exchsrvr\Mtadata folder.

  • Additional log files such as the Exchsrvr\server_name.log file.

  • The Exchsrvr\Mailroot virtual server folder.

  • The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.

  • The temporary folder that is used with offline maintenance tools such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure the location when you run the tool.

  • Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.

  • Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.

  • IIS working files in the %SystemRoot%\IIS Temporary Compressed Files folder.

To correct this warning

  1. Use the eTrust Antivirus user interface to exclude the above listed folders and files from file-level antivirus scanning.

  2. Visit the Computer Associates eTrust Antivirus Web site (http://www3.ca.com/Solutions/Product.asp?ID=156) for the latest information about using eTrust Antivirus on an Exchange Server computer.

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).

For more information about problems that can occur if you scan the IFS drive, see the following Knowledge Base articles:

  • 298924, "XADM: Do Not Back Up or Scan Exchange 2000 Drive M" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 300608, "XADM: C1041737 Err Msg Displayed When You Mount Databases" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 299046, "XADM: Calendar Items Disappear from User's Folders" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


Client Service Messaging Security for SMB v2.0 update available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry:

HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

A Version value of 6.2100 indicates that Trend Micro ScanMail Client Service Messaging Security for SMB v2.0 is installed.

The Microsoft® Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the version of Client Service Messaging Security for SMB version 2.0 that is installed. If the major build number is less than 1145, the Exchange Server Analyzer displays a warning.

This warning indicates that Client Server Messaging Security for SMB v2.0 is installed on the Exchange server and that a recommended software update is available. The recommended update is Client Server Messaging Security for SMB v2.0 Patch 2 for Messaging Component. This update is highly recommended and can improve the overall performance and reliability of the server.

To correct this warning

  1. Visit the Trend Micro Update Center for Client Server Messaging Security for SMB (http://www.trendmicro.com/download/product.asp?productid=39).

  2. Download and install Patch 2.
Note:
The third-party Web site information in this topic is provided to help you find the technical information that you need. The URLs are subject to change without notice.

For more information about other Trend Micro product updates, see the Trend Micro Update Center Web site (http://www.trendmicro.com/download/).

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, Exchange and antivirus software (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, Overview of Exchange Server 2003 and antivirus software (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, Recommendations for troubleshooting an Exchange Server computer with antivirus software installed (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see Exchange Server Partners: Antivirus (http://go.microsoft.com/fwlink/?linkid=16226).


Consider installing HP Command View EVAPerf
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-09

The Microsoft® Exchange Server Analyzer Tool queries the Win32_SCSIController Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the Name key. If the value for the Name key equals Compaq HSV110CCL, this indicates that at least one disk volume on the server is being presented by an HP EVA Storage Area Network (SAN).

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine the value of the Started key for the HP StorageWorks Command View EVAPerf (EVSPDCS) service. A value of False indicates that the service is not running. A value of True indicates that the service is running.

The Exchange Server Analyzer displays a best practice recommendation if both of the following conditions exist:

  • At least one disk volume on the server is being presented by an HP EVA SAN.

  • The HP StorageWorks Command View EVAPerf (EVSPDCS) service is not present or running.

HP provides a free-of-charge software management application that publishes additional performance counters for HP StorageWorks SANs. Administrators can use this software management application to monitor the performance of individual controllers and physical disks in the SAN.

To follow the recommended best practice

  1. Go to the HP StorageWorks Command View EVAPerf Software Web site to download the HP Command View EVAPerf application (http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?pnameOID=471498&locale=en_US&taskId=135&prodSeriesId=471497&prodTypeId=12169&swEnvOID=1005).

    Note:
    The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.

  2. Run the self-extracting executable file that you downloaded and follow the instructions to install the application.


EMC PowerPath Service is stopped
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the EMC PowerPath Service service. A value of True indicates the EMC PowerPath Service service is running, and a value of False indicates the EMC PowerPath Service service is not running. If the Exchange Server Analyzer finds that the value for the Started key is False, a warning is displayed.

EMC PowerPath is multipath I/O (MPIO) software. Multipathing provides for high availability data access by allowing a host to have up to 32 paths to access an external storage device, which facilitates failover and load balancing. Multipathing is not a feature of the operating system, but is supported through the MPIO Driver Development Kit (DDK), which provides a means for storage vendors to create interoperable multipathing solutions.

When MPIO software is run, Microsoft Windows® detects only a single drive while the MPIO software manages the multiple connections to various storage devices. If the MPIO software is stopped, Windows will detect all of the attached storage drives as independent drives. This will likely lead to storage errors and malfunction.

To start the EMC PowerPath Service service

  1. Open the Services MMC snap-in.

  2. Right-click the EMC PowerPath Service service, and then click Properties.

  3. On the General tab of the EMC PowerPath Service property page, make sure the Start-up type is set to Automatic. If it is not, click Apply, and then click OK.

  4. Right-click the EMC PowerPath Service service, and then click Start.

  5. Close the Services snap-in.

For general information about deploying different storage technologies with Windows, see "Planning to Use Windows Storage Features with SANs" (http://go.microsoft.com/fwlink/?LinkId=33626).


EMC PowerPath Version Mismatch Between Cluster Nodes
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2007-07-25

The Microsoft Exchange Analyzer Tool reads the following registry entry to determine the EMC PowerPath version installed on each node in the cluster:

HKEY_LOCAL_MACHINE\SOFTWARE\EMC\PowerPath\Version

If the Exchange Analyzer finds that the value of the second or subsequent node in the Exchange cluster differs for Version, from the value for Version on the first node in the Exchange cluster, an error is displayed.

This error indicates that the nodes in this Exchange cluster are not running the same level of EMC PowerPath driver. As a best practice, we recommend that all nodes in an Exchange cluster run the same level of EMC PowerPath driver.

EMC PowerPath is multipath I/O (MPIO) software. Multipathing provides for high availability data access by allowing a host to have up to 32 paths to access an external storage device, which facilitates failover and load balancing. Multipathing is not a feature of the operating system, but is supported through the MPIO Driver Development Kit (DDK), which provides a means for storage vendors to create inter-operable multipathing solutions.

When MPIO software is run, Microsoft Windows detects only a single drive while the MPIO software manages the multiple connections to various storage devices. If the MPIO driver is mismatched between different nodes of the cluster, it could lead to cluster failover problems.

To resolve this problem, you must upgrade all nodes to the same EMC PowerPath driver version.

For More Information

For more information about deploying different storage technologies with Windows, see "Planning to Use Windows Storage Features with SANs" (http://go.microsoft.com/fwlink/?LinkId=33626).


Emulex FC Port driver has not been updated in more than two years
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-04-19

The Microsoft® Exchange Server Analyzer Tool queries the Win32_SCSIController Microsoft® Windows® Management Instrumentation (WMI) class to determine whether a value is set for the DriverName key. The Exchange Server Analyzer Tool determines whether the following conditions exist:

  • The Emulex FC Port driver is installed on the Exchange server.

  • The current version of the Emulex FC Port driver is installed on the Exchange server.

  • The Emulex FC Port driver was updated in the last two years.

If the Exchange Server Analyzer finds that the value for the DriverName key has not been updated in more than two years, the Exchange Server Analyzer displays a warning.

The Emulex FC Port driver provides SCSI-only or concurrent SCSI and IP functionality within a single host bus adapter (HBA) or several HBAs. The FC Port driver supports Fibre Channel arbitrated loop (FC-AL) topologies, point-to-point topologies, and fabric topologies. The FC Port driver is designed for specialized applications that require host-based logical unit number (LUN) mapping or persistent binding.

To update Emulex FC Port driver, see Downloads and Manuals for Windows (http://www.emulex.com/ts/docfc/winframe.htm). If you need special OEM drivers, see the Emulex software and documentation Web site (http://www.emulex.com/ts/index.html).

Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.


Emulex SCSIport Miniport driver has not been updated in more than two years
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-06-14

The Microsoft® Exchange Server Analyzer Tool queries the Win32_SCSIController Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the DriverName key. The Exchange Server Analyzer Tool determines whether the following conditions exist:

  • The Emulex SCSIport Miniport driver is installed on the Exchange server.

  • The current version of the Emulex SCSIport Miniport driver is installed on the Exchange server.

  • The Emulex SCSIport Miniport driver was updated in the last two years.

If the Exchange Server Analyzer finds that the value for the DriverName key has not been updated in more than two years, the Exchange Server Analyzer displays a warning.

The SCSIport Miniport driver provides SCSI functionality over Fibre Channel arbitrated loop (FC-AL) topologies, point-to-point topologies, and fabric topologies.

To update the Emulex SCSIport Miniport driver, see Downloads and Manuals for Windows (http://www.emulex.com/ts/docfc/winframe.htm). If you need special OEM drivers, see OEM software and documentation (http://www.emulex.com/ts/index.html).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Emulex Storport Miniport driver has not been updated in more than two years
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-06-14

The Microsoft® Exchange Server Analyzer Tool queries the Win32_SCSIController Microsoft® Windows® Management Instrumentation (WMI) class to determine whether a value is set for the DriverName key. The Exchange Server Analyzer Tool determines whether the following conditions exist:

  • The Emulex Storport miniport driver is installed on the Exchange server.

  • The current version of the Emulex Storport miniport driver is installed on the Exchange server.

  • The Emulex Storport miniport driver was updated in the last two years.

If the Exchange Server Analyzer finds that the value for the DriverName key has not been updated in more than two years, the Exchange Server Analyzer displays a warning.

The Emulex Storport miniport driver optimizes the performance and manageability of Storage Area Networks (SANs) and hardware-based disk arrays. The Emulex Storport miniport driver supports Fibre Channel arbitrated loop (FC-AL) topologies, point-to-point topologies, and fabric topologies.

To update Emulex Storport miniport driver, see Downloads and Manuals for Windows (http://www.emulex.com/ts/docfc/winframe.htm). If you need special OEM drivers, see OEM software and documentation (http://www.emulex.com/ts/index.html).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


High CPU usage in non-Exchange process
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

  • The Microsoft® Exchange Server Analyzer Tool has a found a non-Exchange Server process that is currently using more than 20 percent of the server's available CPU. If a non-Exchange Server process is using more than 20 percent of the available CPU, an error is displayed.

  • It is recommended that your servers that run Exchange Server be dedicated to Exchange Server whenever possible and run as few applications or services as possible outside Exchange.

To correct this error

  • If another process causes most of the CPU use, try one of the following options:

    • Turn off the process and see whether the problem goes away.

    • Move that process to another server if you can.

    • Make sure that the process is configured correctly and look for any updates from Microsoft and the provider of the process that address this issue.

    • Uninstall the process if you do not need it.

  • If the process cannot be moved or fixed, the server should be rescaled to allow for the added load of the non-Exchange Server process. You should consider moving users to another Exchange server as part of this rescale.


HP/Compaq Secure Path Service is stopped
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether the HP/Compaq Secure Path service is running. If the Exchange Server Analyzer determines that the HP/Compaq Secure Path service is not running, a warning is displayed.

The HP/Compaq Secure Path service is a Multipath I/O (MPIO) software. Multipathing provides for high availability data access by allowing a host to have up to 32 paths to access an external storage device, which facilitates failover and load balancing. Multipathing is not a feature of the operating system, but is supported through the MPIO Driver Development Kit (DDK), which provides a means for storage vendors to create interoperable multipathing solutions.

When MPIO software is run, the Windows operating system detects only a single drive while the MPIO software manages the multiple connections to various storage devices. If the MPIO software is stopped, Windows will detect all of the attached storage drives as independent drives. This will likely lead to storage errors and malfunction.

To correct this warning

  1. Open the Services MMC snap-in.

  2. Right-click the HP/Compaq Secure Path service, and then click Properties.

  3. On the General tab of the HP/Compaq Secure Path service property page, make sure the Start-up type is set to Automatic. If it is not, click Apply, and then click OK.

  4. Right-click the HP/Compaq Secure Path service, and then click Start.

  5. Close the Services snap-in.

For general information about deploying different storage technologies with Windows, see "Planning to Use Windows Storage Features with SANs" (http://go.microsoft.com/fwlink/?linkid=33626).


Impact of Third-Party Software
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that you are running third-party software on your Exchange server. This third-party software may be the cause of your server's performance problem. Third-party software may include, but is not limited to, the following software:

  • File-level antivirus products

  • Exchange-aware e-mail antivirus products

  • Anti-spam products

  • Fax server software

  • Foreign mail or collaboration connector

  • File and print services

  • Mobile device connectors

To correct this error

  • If you suspect that the third-party software is degrading Exchange Server performance, uninstall or disable the third-party software and measure Exchange Server performance.

  • If you determine that the third-party software is causing a decrease in performance, and the third-party software is important to the server's functionality, consider dedicating another server to distribute the load across two servers.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


INO_FLPY.SYS version update available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the version of the Ino_flpy.sys Computer Associates antivirus filter driver.

The Exchange Server Analyzer queries the CIM_Datafile WMI class to determine the value of the Version key for Ino_flpy.sys, and based on the version build number, a software update may be required. If the value for the Version key indicates that the version number is less than 5.00.6100.109 for the Ino_flpy.sys file, a warning is displayed.

A version number of less than 5.00.6100.109 indicates that the most current version of the Ino_flpy.sys file is not installed on the Exchange Server computer and a more current version of the filter driver should be installed. An antivirus software update for the Ino_flpy.sys file can be found at the Computer Associates Web site. This antivirus software update is highly recommended and can improve the overall performance and reliability of the Exchange Server computer.

When Inoculan Computer Associates eTrust Antivirus version 6.x or 7.x and InoculateIT version 6.x antivirus software programs are installed on an Exchange 2000 Server or Exchange Server 2003 computer, the Setup program copies Ino_flpy.sys and Ino_fltr.sys antivirus filter driver files to the %systemroot%\system32\drivers folder. The antivirus driver files are Windows NT® Kernel mode drivers that are used to start the required antivirus services. Older versions of the filter drivers can cause unexpected results with the Exchange Server computer.

To correct this warning

  1. To obtain the latest antivirus software updates for the ino_flpy.sys file, visit the Computer Associates Web site (http://supportconnectw.ca.com/premium/antivirus/downloads/nt/4.5/ildrvupdate.asp).

  2. Download the appropriate updated version of eTrust or InoculateIT.

  3. Do a full backup of the Exchange Server computer including a backup of the Ino_flpy.sys file.

  4. Install the latest update to eTrust or InoculateIT.
Note:
Web addresses can change, so you might be unable to connect to the Web sites mentioned here.

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 240309, "How to Fully Disable Antivirus Software from Filtering Files" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240309)

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see the Exchange Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


INO_FLTR.SYS version update available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the version of the Ino_fltr.sys Computer Associates antivirus filter driver.

The Exchange Server Analyzer queries the CIM_Datafile WMI class to determine the value of the Version key for Ino_fltr.sys and, based on the version build number, a software update may be required. If the value for the Version key indicates that the version number is less than 5.00.6100.142 for the Ino_fltr.sys file, a warning is displayed.

A version number of less than 5.00.6100.142 indicates that the most current version of the Ino_fltr.sys file is not installed on the Exchange Server computer and a more current version of the filter driver should be installed. An antivirus software update for the Ino_fltr.sys file can be found at the Computer Associates Web site. This antivirus software update is highly recommended and can improve the overall performance and reliability of the Exchange Server computer.

When Inoculan Computer Associates eTrust Antivirus version 6.x or 7.x and InoculateIT version 6.x antivirus software programs are installed on an Exchange 2000 Server or Exchange Server 2003 computer, the Setup program copies Ino_flpy.sys and Ino_fltr.sys antivirus filter driver files to the %systemroot%\system32\drivers folder. The antivirus driver filter files are Windows NT® Kernel mode drivers that are used to start the required antivirus services. Older versions of the filter drivers can cause unexpected results with the Exchange Server computer.

To correct this warning

  1. To obtain the latest antivirus software updates for the Ino_fltr.sys file, visit the Computer Associates Web site: (http://supportconnectw.ca.com/premium/antivirus/downloads/nt/4.5/ildrvupdate.asp).

  2. Download the appropriate updated version of eTrust or InoculateIT.

  3. Do a full backup of the Exchange Server computer including a backup of the Ino_fltr.sys file.

  4. Install the latest update to eTrust or InoculateIT.
Note:
Web addresses can change, so you might be unable to connect to the Web sites mentioned here.

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 240309, "How to Fully Disable Antivirus Software from Filtering Files" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240309)

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


McAfee GroupShield 5.2 for Microsoft Exchange Update for Exchange available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-04-19

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether a Virus Scanning Application Programming Interface (VSAPI) library file is registered with the Microsoft Exchange Information Store service:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

When McAfee GroupShield 5.2 for Microsoft Exchange is installed on Exchange 2000 Server or Exchange Server 2003, the Library registry entry will have a value of GSEVS2.DLL. This library file performs several VSAPI-related functions in GroupShield 5.2 for Microsoft Exchange.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for GSEVS2.DLL. If the value for the Version key indicates that the build number is less than 682 for this file, a warning is displayed.

A version number of less than 682 for GSEVS2.DLL indicates that the latest version of GroupShield 5.2 for Microsoft Exchange is not installed. A software update is available for GroupShield 5.2 for Microsoft Exchange from the McAfee Web site. This update is highly recommended and can improve overall performance and reliability. Additionally, upgrading to GroupShield for Microsoft Exchange 5.2.682 guarantees that you are using the latest versions of important DLLs. The use of the latest version of gsevs2.dll has significantly improved performance and reliability in Exchange Server messaging deployments.

To correct this warning

  1. Determine the latest version of GroupShield 5.2 for Microsoft Exchange Server by visiting the Guided Knowledge Search page of the McAfee Web site (http://knowledgemap.nai.com/). Use the following McAfee Solutions KnowledgeBase articles and other McAfee Solutions KnowledgeBase articles that are located on that site to determine the latest version:

    • Solution ID KB40567, "Getting the latest version of GroupShield and/or SpamKiller"

    • Solution ID KB nai18117, "Product Version Information for GroupShield for Exchange 2000"

  2. Visit the McAfee Web site (https://secure.nai.com/us/forms/downloads/upgrades/login.asp).

  3. Download the latest update for your version of GroupShield 5.2 for Microsoft Exchange Server.

  4. Take a full backup of the Exchange Server computer.

  5. Install the latest update to GroupShield 5.2 for Microsoft Exchange Server.
Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange Server computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226)


McAfee GroupShield 6.0 for Microsoft Exchange Update for Exchange available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether a Virus Scanning Application Programming Interface (VSAPI) library file is registered with the Microsoft Exchange Information Store service:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

When McAfee GroupShield 6.0 for Microsoft Exchange is installed on Exchange 2000 Server or Exchange Server 2003, the Library registry entry will have a value of VSAPISCANSOURCE.DLL. This library file performs several VSAPI-related functions in GroupShield 6.0 for Microsoft Exchange.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for VSAPISCANSOURCE.DLL. If the value for the Version key indicates that the build number is less than 6.0.1148.0 for this file, a warning is displayed.

A version number of less than 6.0.1148.0 for VSAPISCANSOURCE.DLL indicates that the latest version of GroupShield 6.0 for Microsoft Exchange is not installed. A software update is available for GroupShield 6.0 for Microsoft Exchange from the McAfee Web site. This update is highly recommended and can improve overall performance and reliability.

To correct this warning

  1. Determine the latest version of GroupShield 6.0 for Microsoft Exchange by visiting the Guided Knowledge Search page of the McAfee Web site (http://knowledgemap.nai.com/). Use the following McAfee Solutions articles and other McAfee Solutions articles located on that site to determine the latest version:

    • Solution ID nai18117 "Product Version Information for GroupShield for Exchange 2000"

    • Solution ID KB37636, "Version numbers for McAfee GroupShield 6.x for Microsoft Exchange"

    • Solution ID KB40567, "Getting the latest version of GroupShield and/or SpamKiller"

  2. Visit the Product Downloads page of the McAfee Web site (https://secure.nai.com/us/forms/downloads/upgrades/login.asp).

  3. Download the latest update for your version of GroupShield 6.0 for Microsoft Exchange.

  4. Take a full backup of the Exchange Server computer.

  5. Install the latest update to GroupShield 6.0 for Microsoft Exchange.
Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange Server computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


McAfee GroupShield is installed on this Exchange server but the service is stopped
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether McAfee GroupShield for Microsoft Exchange is installed and if the McAfee GroupShield service is running on the Exchange computer.

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine whether the value set for the Started key in the Microsoft Exchange Information Store service is set to True or False.

A value of False indicates that the Information Store service is not running on this Exchange Server computer. A value of True indicates that the Microsoft Exchange Information Store service is running.

If the Exchange Server Analyzer finds that the Microsoft Exchange Information Store service is running, and that McAfee GroupShield is installed, but the McAfee GroupShield service is not started, a warning is displayed.

McAfee GroupShield provides antivirus protection for Exchange. Some reasons the McAfee GroupShield service may have been stopped, together with solutions are listed here.

  • The software you are running on your Exchange Server may be an evaluation or trial version that has expired. In this case, you may need to reinstall McAfee GroupShield. At a minimum, to continue using the software, you must activate it.

  • An administrator may have unintentionally stopped the McAfee GroupShield service. Verify that the service is set to start automatically, and then start the service.

  • A malicious worm, virus, or other program may have stopped the service. Verify that the service is set to start automatically, and start the service. If the service continues to stop unexpectedly without relevant error events, verify that the computer is not infected with a malicious worm and disinfect the system if needed.

Microsoft generally recommends deploying antivirus software designed for messaging systems at either the Simple Mail Transfer Protocol (SMTP) gateway or at the Exchange servers that host mailboxes. For the most protection, run antivirus software at the gateway that scans the incoming MIME messages, and a scanner on the Exchange Server that uses VSAPI 2.5.

To start the McAfee GroupShield service

  1. Open the Services MMC snap-in.

  2. Right-click McAfee GroupShield service, and then click Properties.

  3. On the General tab of the McAfee GroupShield property page, make sure the Start-up type is set to Automatic. If it is not, click Apply, and then click OK.

  4. Right-click McAfee GroupShield service, and then click Start.

  5. Close the Services snap-in.

Additionally, you should be running client antivirus software on the user desktop. If you are running antivirus software designed for messaging systems (it can parse and scan MIME) at the gateway or on the Exchange server, running a file-level scanner at the desktop is sufficient.

  • For more information about the different types of virus-scanning programs that are typically used with Microsoft Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

  • For more information about the different types of virus-scanning programs that are typically used with Microsoft Exchange 2000 Server, see the Knowledge Base article 328841, "Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

  • For information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see the Microsoft white paper, "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=30732).


Messageware Plus Pack is installed
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Messageware Plus Pack is installed on any Exchange Servers:

HKEY_LOCAL_MACHINE\Software\Messageware Incorporated\Core Services\PlusPack\Load

If the Exchange Server Analyzer finds the value data for Load equals 1, the Exchange Server Analyzer displays a non-default configuration message.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

Messageware Plus Pack is a Microsoft Office Outlook® Web Access for Exchange Server 2003 add-in that is produced by Messageware Incorporated. Messageware Plus Pack extends and enhances Outlook Web Access for both Outlook Web Access Basic users and Outlook Web Access Premium users.

For more information about Messageware Plus Pack, see the Web site, "Messageware OWA Suite" (http://www.messageware.com).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Microsoft Antigen Data Execution Prevention compatibility
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2007-02-19

The Microsoft Exchange Analyzer Tool queries the Win32_Service Microsoft Windows Management Instrumentation (WMI) class to determine the value of the Started key for the Microsoft Antigen service. A value of False indicates that the service is not running. A value of True indicates that the service is running.

The Exchange Analyzer also reads the following registry entry to determine whether the Kaspersky scan engine for Microsoft Antigen is installed on the Exchange Server. This registry entry will only be present if the Kaspersky scan engine is installed on the Exchange Server.

HKEY_LOCAL_MACHINE\Software\Sybari Software\Antigen for Exchange\Scan Engines\Kaspersky

Finally, if the Exchange Server is running on Microsoft Windows Server 2003 Service Pack 1 (SP1) or a later version, the Exchange Analyzer queries the Win32_ComputerSystem WMI class to determine whether the value for the SystemStartupOptions key contains the strings '/NOEXECUTE=OPTOUT' or '/NOEXECUTE=ALWAYSON'. This indicates that Data Execution Prevention (DEP) is enabled on the server. Data Execution Prevention is a set of hardware and software technologies that perform additional checks on memory to help prevent malicious code from running on a system.

If the Exchange Analyzer determines that the following conditions are true, the Exchange Analyzer displays a warning:

  • The Microsoft Antigen service is enabled on the server.

  • The Kaspersky scan engine for Antigen is installed.

  • The Exchange server is running on Microsoft Windows Server 2003 Service Pack 1 (SP1) or a later version.

  • Data Execution Prevention is enabled on the server.

This warning indicates that the current server configuration may cause messaging and virus scanning performance issues.

To address this warning, follow the guidance prescribed in Microsoft Knowledge Base article 905952, "Messaging performance is slower than expected in Antigen, and the Antigen client stops responding" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905952) to selectively disable DEP for individual programs.

For More Information

For more information about Data Execution Prevention, see Microsoft Knowledge Base article 875352 "A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=875352).


NSI Software Double-Take is installed
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Double-Take service. A value of True indicates that the Double-Take service is running on this Exchange Server. If the Double-Take service is detected on an Exchange Server, the Exchange Server Analyzer displays a non-default configuration message.

The Exchange Server Analyzer reports this non-default configuration for informational purposes only. No action is required.

Double-Take, from NSI Software, Inc., copies user-selected files or complete volumes from one or more source servers to one or more target servers over standard network connections. These copies allow businesses to resume quickly after a disaster or a system outage, with or without user intervention.

For more information about Double-Take, see the Web site, "Double-Take" (http://www.nsisoftware.com/pro/doubletake).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

Double-Take is data replication software. For detailed information regarding multi-site data replication for Exchange 2000 Server and Exchange Server 2003, see Microsoft Knowledge Base article 895847, "Multi-site data replication support for Exchange 2003 and Exchange 2000," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895847).


Non-Exchange Process Consuming Greater than 20% Processor Time
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the %Processor Time (_Total) counter of the Processor performance object to analyze performance data.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • There is a processor bottleneck.

  • One or more non-Exchange processes are using greater than 20 percent of the total average server CPU time.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • There is a processor bottleneck.

  • One or more non-Exchange processes are using greater than 10 percent of the total average server CPU time.

The % Processor Time (_Total) performance counter under the Process performance object provides overall utilization of the processors. The average CPU utilization should always be below 80 percent. Higher averages indicate a processor bottleneck. Frequent spikes in processor time above 90 percent also indicate a processor bottleneck.

Removing Processor Bottlenecks

There are many ways to remove processor bottlenecks from your Exchange server.

  • First, review the applications or tasks that are causing load on the server. Determine whether the application should be using the processor time that it is or if there might be an issue with the process.

  • If a non-Exchange application is not important to that server, run that application on another server. If you can do this, move server roles to other computers also. For example, if the Inetinfo process is using lots of CPU utilization, consider adding front-end servers to assume responsibility for the protocol work that Inetinfo performs. You can also move public folder access to a dedicated public folder server. Finally, if a server performs lots of distribution list expansions, you can reduce CPU utilization by moving distribution list expansion to a dedicated distribution-list expansion server.

  • If you can do this, add more or faster processors to the server. Also, enable hyper-threading if it is supported by the processors. You can enable hyper-threading by configuring the system BIOS. For more information, see the computer manufacturer's Help documentation.

  • If increasing the processing power is not a good option, you must reduce the load on the processors. To reduce the overall effect on the server, make sure that I/O-intensive, CPU-intensive, or memory-consuming tasks occur outside ordinary operation hours.

  • Make sure that CPU-intensive tasks, such as backup and maintenance, occur during off-peak hours. Also, make sure that these tasks are performed in a staged manner. Staging a task means setting different start times and, preferably, end times for each task. Staging the maintenance and backup of databases or storage groups also lessens the effect of these resource-intensive tasks.

For More Information

  • For more information about Processor Bottlenecks, see Processor Bottleneck.

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).

  • For more information about how to move user mailboxes to reduce server load, see Move User Mailboxes to Another Server.


Non-Exchange Process Consuming Greater than 50% Processor Time
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the %Processor Time (_Total) counter of the Processor performance object to analyze performance data.

This % Processor Time (_Total) performance counter under the Process performance object provides overall utilization of the processors. The average CPU utilization should always be below 80 percent. Higher averages indicate a processor bottleneck. Frequent spikes in processor time above 90 percent also indicate a processor bottleneck.

If the Exchange Server Analyzer determines that a non-Exchange process is using greater than 50% of the total average server CPU time, even if there is no actual processor bottleneck detected, the Exchange Server Analyzer Tool displays a warning.

Removing Potential Processor Bottlenecks

There are many ways to remove potential processor bottlenecks from your Exchange server.

  • First, review the applications or tasks that are causing load on the server. Determine whether the application should be using the processor time that it is or if there might be an issue with the process.

  • If a non-Exchange application is not important to that server, run that application on another server. If you can do this, move server roles to other computers also. For example, if the Inetinfo process is using lots of CPU utilization, consider adding front-end servers to assume responsibility for the protocol work that Inetinfo performs. You can also move public folder access to a dedicated public folder server. Finally, if a server performs lots of distribution list expansions, you can reduce CPU utilization by moving distribution list expansion to a dedicated distribution-list expansion server.

  • If you can do this, add more or faster processors to the server. Also, enable hyper-threading if it is supported by the processors. You can enable hyper-threading by configuring the system BIOS. For more information, see the computer manufacturer's Help documentation.

  • If increasing the processing power is not a good option, you must reduce the load on the processors. To reduce the overall effect on the server, make sure that I/O-intensive, CPU-intensive, or memory-consuming tasks occur outside ordinary operation hours.

  • Make sure that CPU-intensive tasks, such as backup and maintenance, occur during off-peak hours. Also, make sure that these tasks are performed in a staged manner. Staging a task means setting different start times and, preferably, end times for each task. Staging the maintenance and backup of databases or storage groups also lessens the effect of these resource-intensive tasks.

For More Information

  • For more information about Processor Bottlenecks, see Processor Bottleneck.

  • For more information about Exchange Server performance, see the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


An outdated version of HP/Compaq Secure Path is installed
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-13

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the software version of HP/Compaq Secure Path software installed on the Exchange server. If the Secure Path version is not 3.7.2.540, a warning is displayed.

To remedy this warning, update the Secure Path software. Contact your HP/Compaq reseller to update this software.

For more information about the HP/Compaq Secure Path software updates, visit the HP Web site, "HP StorageWorks Secure Path" (http://h18006.www1.hp.com/products/sanworks/softwaredrivers/securepath/index.html).

Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.


Port 25 is blocked
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether McAfee VirusScan for Microsoft Exchange is installed on the server that is running Exchange Server:

HKEY_LOCAL_MACHINE\Software\Network Associates\TVD\VirusScan Enterprise\CurrentVersion

The Exchange Server Analyzer also queries the following registry branch to determine how the VirusScan product is configured to block ports:

HKLM\Software\Network Associates\TVD\Shared Components\On Access Scanner\BehaviourBlocking

The keys in this branch are used to configure which processes and ports are blocked or allowed with the On Access feature of the VirusScan product.

Finally, the Exchange Server Analyzer also queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class for the value of the Started key for the McAfee VirusScan service to determine whether it is running on the Exchange server.

A value of False indicates that the McAfee VirusScan service is not running on this Exchange server. A value of True indicates that the McAfee VirusScan service is running.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • McAfee VirusScan is installed and running on the Exchange server.

  • The "Prevent mass mailing worms from sending mail" blocking rule is enabled for Port 25.

  • The Exchange Simple Mail Transfer Protocol (SMTP) service is not excluded from the blocking rule.

This warning indicates that the McAfee VirusScan application is configured so that it could block legitimate Exchange Server communication through port 25. Mail flow problems might occur.

To address this issue:

  • Consider whether to disable the "Prevent mass mailing worms from sending mail" blocking rule.

  • Add the Exchange Server SMTP service to the exclusion list for the "Prevent mass mailing worms from sending mail" blocking rule.

For More Information

  • For more information about how to configure McAfee VirusScan for Microsoft Exchange, visit the McAfee Service Portal (http://knowledge.mcafee.com/).

    Note:
    The third-party Web site information is provided to help you find the technical information that you need. The URLs are subject to change without notice.
  • For more information about the different types of virus-scanning programs that are typically used with Microsoft Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

  • For more information about the different types of virus-scanning programs that are typically used with Microsoft Exchange 2000 Server, see the Knowledge Base article 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

  • For information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see the Microsoft white paper, "Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment" (http://go.microsoft.com/fwlink/?LinkId=30732).


Red Earth Software Policy Patrol for Exchange Server Needs Update
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2007-07-24

The Microsoft Exchange Analyzer Tool reads the registry to determine if either of the following two subkeys are present:

HKEY_LOCAL_MACHINE\Software\Red Earth Software\Policy Patrol\3.0

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Red Earth Software\Policy Patrol\3.0

The presence of either of these branches indicates that Red Earth Software's Policy Patrol version 3.0 for Exchange Server is installed on the local computer.

If the Exchange Analyzer finds that Policy Patrol version 3 for Exchange Server is installed on the local computer, the Exchange Analyzer displays a warning.

This warning indicates that a recommended update of Policy Patrol for Exchange Server is available.

To correct this warning

  1. Visit the Red Earth Software Policy Patrol for Exchange Server download site at http://www.policypatrol.com/download.htm

  2. Download and install any required or recommended updates to Policy Patrol for Exchange Server.
Note:
The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.


ScanMail for Microsoft Exchange and CA eTrust running together
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer reads the following registry entry to determine the version of Trend Micro ScanMail for Microsoft Exchange that is installed on the Exchange server:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

If the value data for the Version value starts with 7, it indicates that ScanMail for Microsoft Exchange Version: 7 is installed.

The Exchange Server Analyzer also reads the following registry entry to determine whether eTrust from Computer Associates is also installed on the Exchange server:

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\

If the CurrentVersion registry value exists, it indicates that eTrust Antivirus version 7 from Computer Associates is installed on the Exchange server.

Finally, the Exchange Server Analyzer queries the Win32_Service Microsoft Windows® Management Instrumentation class to determine the value of the Started key for the InoRT service, also known as the eTrust Antivirus Realtime Server service, in eTrust Antivirus.

The Exchange Server Analyzer displays a best practice message if the following conditions are true:

  • Both ScanMail for Microsoft Exchange and eTrust Antivirus are installed on the Exchange server.

  • The eTrust Antivirus Realtime Server service is started.

Trend Micro recommends that any file-system-based antivirus software, such as eTrust Antivirus, exclude the ScanMail for Microsoft Exchange folders from scanning. ScanMail for Microsoft Exchange uses temporary folders in its path for its own scanning activity. If a file-system-based antivirus scanner scans these temporary folders, the scan could interfere with the ordinary operations of ScanMail for Microsoft Exchange.

It is a best practice to exclude ScanMail for Microsoft Exchange folders from real-time scanning by file-system-based antivirus software, such as eTrust Antivirus from Computer Associates. For more information about how to use ScanMail for Microsoft Exchange on a computer that has file-system-based antivirus software installed, see the Trend Micro knowledge base article, "Installing another antivirus application with ScanMail for Exchange also installed on the same server" (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=8540).

Note:
The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.


ScanMail for Microsoft Exchange archive directory contains too many files
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether version 7.0 of Trend Micro ScanMail for Microsoft Exchange is installed:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

The Exchange Server Analyzer then counts the number of files that are present in the archive directory used by ScanMail for Microsoft Exchange. By default, the archive directory path is as follows:

C:\Program Files\Trend Micro\Smex\Storage\Archive

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • Version 7.0 of ScanMail for Microsoft Exchange is installed.

  • More than 1,000 files are in the archive directory used by ScanMail for Microsoft Exchange.

This warning indicates the presence of many files in the archive directory used by ScanMail for Microsoft Exchange. Trend Micro recommends that you periodically review and clean out the archive folder used by ScanMail for Microsoft Exchange.


ScanMail for Microsoft Exchange backup directory contains too many files
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Version 7.0 of Trend Micro ScanMail for Microsoft Exchange is installed:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

The Exchange Server Analyzer then counts the number of files that are present in the backup directory used by ScanMail for Microsoft Exchange. By default, the backup directory path is as follows:

C:\Program Files\Trend Micro\Smex\Storage\Backup

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • Version 7.0 of ScanMail for Microsoft Exchange is installed.

  • More than 1,000 files are in the backup directory used by ScanMail for Microsoft Exchange.

This warning indicates the presence of many files in the backup directory used by ScanMail for Microsoft Exchange. Trend Micro recommends that you periodically review and clean out the backup folder used by ScanMail for Microsoft Exchange.


ScanMail for Microsoft Exchange backup exclusion
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the files and folders that have been excluded from backups using Windows Backup:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

The Exchange Server Analyzer specifically looks for a string that contains "SMEX\DATA".

If the Exchange Server Analyzer finds that the FilesNotToBackup key contains a value that contains the string "SMEX\DATA", the Exchange Server Analyzer displays a warning.

If you are not using Windows Backup, you can safely ignore this warning. If you are using Windows Backup, it is recommended that you remove the exclusion for the SMEX\DATA directory. Trend Micro recommends that users backup all files in this folder that have a .mdb file name extension. The backup files can be used in the event the production .mdb files in the SMEX\DATA folder become corrupted or are deleted.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

  3. Select FilesNotToBackup in the left pane.

  4. In the right pane, right-click the value that contains the string "SMEX\DATA" and select Delete.

  5. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


ScanMail for Microsoft Exchange debug mode is enabled
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether debug mode is enabled in ScanMail for Microsoft Exchange by Trend Micro:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\DebugModule

If the value data for DebugModule contains one or more of the following strings, the Exchange Server Analyzer displays a warning:

  • HOST:1

  • CONFIG:1

  • MASTER:1

  • WATCHER:1

  • STORE:1

  • INETINFO:1

  • TCHER:1

  • MON:1

  • MONITOR:1

This warning indicates that debug mode is currently enabled for one or more ScanMail for Microsoft Exchange module. Trend Micro recommends that debug mode be enabled only when it is required, for example, for troubleshooting. Trend Micro recommends that otherwise debug mode be disabled for ordinary operations.

To correct this warning

  1. Review the following Trend Micro knowledge base article, "Enabling the ScanMail for Exchange (SMEX) 7.0 debugging through the Registry Editor" (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=25532).

  2. Disable debugging for all modules by following the instructions in the Trend Micro knowledge base article.
Note:
The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.


ScanMail for Microsoft Exchange quarantine directory contains too many files
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether version 7.0 of Trend Micro ScanMail for Microsoft Exchange is installed:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

The Exchange Server Analyzer then counts the number of files in the quarantine directory used by ScanMail for Microsoft Exchange. By default, the path for the quarantine directory is as follows:

C:\Program Files\Trend Micro\Smex\Storage\Quarantine

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • Version 7.0 of ScanMail for Microsoft Exchange is installed.

  • More than 1,000 files are in the quarantine directory used by ScanMail for Microsoft Exchange.

This warning indicates the presence of many files in the quarantine directory used by ScanMail for Microsoft Exchange. Trend Micro recommends that you periodically review and clean out the quarantine folder used by ScanMail for Microsoft Exchange.


ScanMail for Microsoft Exchange SharedResPool directory in default path
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2007-06-05

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the version of Trend Micro ScanMail for Microsoft Exchange that is installed:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

The Exchange Server Analyzer also reads the following registry entry to determine the location of the SharedResPool folder:

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\SharedResPool

Finally, the Exchange Server Analyzer reads the following registry entry to determine the location where ScanMail for Microsoft Exchange has been installed:

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\HomeDir

The Exchange Server Analyzer displays a best practice message if the following conditions are true:

  • ScanMail for Microsoft Exchange Version: 7 is installed.

  • The SharedResPool folder is located in the path of the ScanMail root directory.

It is a best practice to relocate the SharedResPool directory to a drive that is faster than that of the root directory used by ScanMail for Microsoft Exchange. Trend Micro recommends that customers relocate the SharedResPool folder to a faster drive for better performance. The SharedResPool directory contains memory-mapping files for the shared resources between the processes included with ScanMail for Microsoft Exchange Version: 7.0. You should not delete the contents of this directory.

For more information about the SharedResPool folder, see "What are the ScanMail for Exchange (SMEX) 7.0 SharedResPool and Engine directories?" (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=26898).

For more information about moving the SharedResPool folder, see "Moving the ScanMail for Exchange (SMEX) 7.0 SharedResPool directory to another location" (http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-127549&id=EN-127549).

Note:
The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.


ScanMail for Microsoft Exchange SMTP scanning enabled on mailbox server
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following property in the Microsoft Internet Information Services (IIS) metabase to determine the current configuration settings for Trend Micro ScanMail for Microsoft Exchange:

LM/SmtpSvc/%SMTPINSTANCE%/EventManager/EventTypes/{76719654-05A6-11d2-9dfd-00C04FA322BA}/Bindings/{6BA0CE4C-AC34-411E-B58A-EB715D04019D}/Enabled

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value for the serverRole attribute of the Exchange server object. A value of 1 for the serverRole attribute indicates that the Exchange server has been configured as a front-end server. A value of 0 indicates that the Exchange server is not configured as a front-end server.

The Exchange Server Analyzer also queries the Win32_OperatingSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the OSProductSuite key for the Exchange server. This query is performed to determine the specific operating system that is running on the Exchange server.

The Exchange Server Analyzer also reads the following registry value to determine the version of ScanMail for Exchange that is running on the Exchange server:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

If the value data for the Version value starts with 7, it indicates that ScanMail for Microsoft Exchange Version: 7 is installed.

Finally, the Exchange Server Analyzer queries Active Directory to determine the number of objects that have a homeMDBBL attribute configured. Objects that have the homeMDBBL attribute configured are mailbox-enabled objects. Therefore, the count of the number of objects that have homeMDBBL configured is the number of mailboxes that exist.

The Exchange Server Analyzer displays a best practice message if the following conditions are true:

  • ScanMail for Microsoft Exchange Version: 7 is installed.

  • ScanMail for Microsoft Exchange is configured to perform SMTP scanning on an Exchange server that is not configured as a front-end server.

  • The Exchange server contains more than 20 mailboxes.

  • The Exchange server is not running Microsoft Windows Small Business Server 2003 or Microsoft Small Business Server 2000.

Trend Micro recommends that users of ScanMail for Microsoft Exchange Version: 7 disable SMTP scanning that uses the ScanMail management console on mailbox servers if there are separate dedicated gateway or bridgehead servers. For best performance and security, Trend Micro recommends that SMTP scanning be enabled on gateway bridgehead servers instead of on mailbox servers.


ScanMail for Microsoft Exchange TEMP directory contains many files
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether version 7.0 of Trend Micro ScanMail for Microsoft Exchange is installed:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

The Exchange Server Analyzer Tool then counts the number of files in the TEMP directory used by ScanMail for Microsoft Exchange. By default, the path of the TEMP directory used by ScanMail for Microsoft Exchange is as follows:

C:\Program Files\Trend Micro\Smex\Temp

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • Version 7.0 of ScanMail for Microsoft Exchange is installed.

  • More than 100 files are in the TEMP directory used by ScanMail for Microsoft Exchange.

This warning indicates the presence of many files in the TEMP directory used by ScanMail for Microsoft Exchange. The files in this folder are temporary files used by ScanMail for Microsoft Exchange. ScanMail for Microsoft Exchange is supposed to automatically delete these files.

If there are many files dated before the current date, Trend Micro recommends that you delete the old files.


ScanMail for Microsoft Exchange TEMP directory contains too many files
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether version 7.0 of Trend Micro ScanMail for Microsoft Exchange is installed:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

If ScanMail for Microsoft Exchange version 7 is installed, the Exchange Server Analyzer reads the following registry entry to determine the location of the TEMP directory used by ScanMail for Microsoft Exchange:

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\TempFolderPath

The Exchange Server Analyzer then counts the number of files in the TEMP directory used by ScanMail for Microsoft Exchange.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • Version 7.0 of ScanMail for Microsoft Exchange is installed.

  • More than 100 files are in the TEMP directory used by ScanMail for Microsoft Exchange.

This warning indicates the presence of many files in the TEMP directory used by ScanMail for Microsoft Exchange. The files in this folder are temporary files used by ScanMail for Microsoft Exchange. ScanMail for Microsoft Exchange is supposed to automatically delete these files.

If there are many files dated before the current date, Trend Micro recommends that you delete the old files.


ScanMail for Microsoft Exchange temporary folder path changed
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether version 7.0 of Trend Micro ScanMail for Microsoft Exchange is installed:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

The Exchange Server Analyzer also reads the following entry to determine the location for the temporary folder used by ScanMail for Microsoft Exchange:

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\TempFolderPath

If the TempFolderPath value is present and configured in the registry, its presence indicates that the temporary folder used by ScanMail for Microsoft Exchange has been moved from its default location.

Finally, the Exchange Server Analyzer queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for AdapterSMTP.dll. That module is included with ScanMail for Microsoft Exchange from Trend Micro. A value of the Version key for AdapterSMTP.dll of less than 7.0.1366 indicates that an updated version of ScanMail for Microsoft Exchange is required.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • ScanMail for Microsoft Exchange Version: 7 is installed.

  • The temporary folder used by ScanMail for Microsoft Exchange has been moved from its original location.

  • The file version for adapterSMTP.dll is 7.0.1366 or earlier.

Trend Micro introduced the ability to relocate the temporary folder in recent builds of ScanMail for Microsoft Exchange. This feature only works on builds later than 7.0.1366. This warning indicates that the temporary folder has been relocated but that the relocation will not take effect because this server is running an earlier build of ScanMail for Microsoft Exchange that does not support relocation of the temporary folder.

To correct this warning

  1. Visit the Trend Micro Update Center Web site (http://www.trendmicro.com/download).

  2. Download and install any required or recommended updates for ScanMail for Microsoft Exchange.
Note:
The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.


ScanMail for Microsoft Exchange temporary folder path optimization
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether version 7.0 of Trend Micro ScanMail for Microsoft Exchange is installed:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

The Exchange Server Analyzer also reads the following entry to determine the location for the temporary folder used by ScanMail for Microsoft Exchange:

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\TempFolderPath

If the TempFolderPath value is present and configured in the registry, its presence indicates that the temporary folder used by ScanMail for Microsoft Exchange has been moved from its default location.

Finally, the Exchange Server Analyzer queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for AdapterSMTP.dll. That module is included with ScanMail for Microsoft Exchange from Trend Micro.

The Exchange Server Analyzer displays a best practice message if the following conditions are true:

  • ScanMail for Microsoft Exchange Version: 7 is installed.

  • The temporary folder used by ScanMail for Microsoft Exchange remains in its original default location.

  • The version of AdapterSMTP.dll is a version that supports redirection of the temporary folder used by ScanMail for Microsoft Exchange.

Trend Micro introduced the ability to relocate the temporary folder in recent builds of ScanMail for Microsoft Exchange. This feature only works on builds later than 7.0.1366. If you are using a build of ScanMail for Microsoft Exchange that is later than version 7.0.1366, Trend Micro recommends that you relocate the temporary folder to a faster drive.

To relocate the temporary folder

  1. Review the Trend Micro knowledge base article, "Can users change the location of the ScanMail for Exchange (SMEX) 7.0 temporary folder?" (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=26343).

  2. Perform the procedures shown in that article to relocate the temporary folder to a faster drive.
Note:
The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.


ScanMail for Microsoft Exchange update available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-12-15

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for adapterSMTP.dll. This module is included with ScanMail for Microsoft Exchange from Trend Micro.

If the Exchange Server Analyzer finds the value of the Version key for adapterSMTP.dll to be less than 7.0.1366, the Exchange Server Analyzer displays a warning.

This warning indicates that ScanMail for Microsoft Exchange version 7 is installed on the Exchange server and that a recommended software update is available. This update is highly recommended and can improve the overall performance and reliability of the server.

To correct this warning

  1. Visit the Trend Micro Update Center Web site (http://www.trendmicro.com/download/).

  2. Download and install any required or recommended updates to ScanMail for Microsoft Exchange.
Note:
The third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.


SMTP transport antivirus scanning is not enabled
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the Started key on the SMSMSE (Symantec Mail Security for Microsoft Exchange) service. The Win32_Service class determines whether SMSMSE is installed on the Exchange Server 2003 computer. A value of True indicates that the SMSMSE service is running. A value of False indicates that the SMSMSE service is not running. The Exchange Server Analyzer displays a warning if the following conditions exist:

  • SMSMSE is installed on the Exchange Server 2003 computer.

  • SMTP transport antivirus scanning is not enabled.

In Exchange Server 2003, the advanced queuing engine uses the Exchange Transport AntiVirus API as one of the six transport event sinks to deliver messages to their destinations. The Exchange Transport AntiVirus API event sink is implemented in OnSubmit.dll and enables non-Microsoft vendors, such as Symantec, to implement virus scanners, which examine each message for malicious attachments and data structures before they reach their destinations. This event is registered for the OnSubmission event.

By default, transport antivirus scanning is not enabled because it causes messages to be scanned twice, one time at the SMTP layer and one time in the Exchange store. However, if you are using front-end servers to connect an Exchange organization to the Internet, you can enable transport antivirus scanning on these servers.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To enable transport antivirus scanning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\TransportAVAPI.

  3. Create a new DWORD value with a value name called Enabled. Assign a value data of 1 to the Enabled value name.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

Note:
Transport-scanning functionality is available only with Exchange virus scanners that are based on Virus Scanning Application Programming Interface (VSAPI) 2.5.

For more information about SMTP Transport Architecture, see the Exchange Server 2003 Technical Reference Guide (http://go.microsoft.com/fwlink/?LinkId=47891).

For more information about how to use antivirus software with Exchange Server, see the following Knowledge Base articles:

  • 328841, " Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841).

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105).

  • 245822, "Recommendations for troubleshooting an Exchange Server computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822).

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites that are mentioned here.


Simpler-Webb Exchange Resource Manager update is available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-04-14

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value that is set for the Version key for ERME2KAsyncSink.dll. If the Exchange Server Analyzer finds the value of Version for ERME2KAsyncSink.dll is less than 1015, a warning is displayed.

The ERME2KAsyncSink.dll file is a core binary for Simpler-Webb Exchange Resource Manager (ERM). If the version of ERME2KAsyncSink.dll is less than 1015, it indicates that ERM version 1.2 or earlier is installed on the server. There is a known issue with ERM version 1.2 that can cause the Exchange local delivery queue to stop the delivery of messages as Exchange OLE DB awaits a return call from the ERM event sink. Microsoft Exchange OLEDB is waiting for the event sink ERME2KAsyncSink.dll to return from OnSyncSave call, while Exchange store shutdown is in progress.

A failure to return from this call could prevent Exchange Store from completing shutdown. This issue is resolved in ERM version 1.35.

To correct this warning

  1. Use Add or Remove Programs to manually remove ERM version 1.2.

  2. Install ERM version 1.35, which is available at the Simpler-Webb Web site (http://www.swinc.com/products/ERM/upgrade/).

    Note:
    The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.


Sybari Antigen 7.5 for Microsoft Exchange Update for Exchange available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether a Virus Scanning Application Programming Interface (VSAPI) library file is registered with the Microsoft Exchange Information Store service:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

Antigen 7.5 for Microsoft Exchange is a Sybari product. When Antigen 7.5 for Microsoft Exchange is installed on Exchange 2000 Server or Exchange Server 2003, the Library registry entry will have a value of ANTIGENVSAPI.DLL. This library file performs several VSAPI-related functions in Antigen 7.5 for Microsoft Exchange.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for ANTIGENVSAPI.DLL. If the value for the Version key indicates that the build number is less than 1316 for this file, a warning is displayed.

A version number of less than 1316 for ANTIGENVSAPI.DLL indicates that the latest version of Antigen 7.5 for Microsoft Exchange is not installed. A software update is available for Antigen 7.5 for Microsoft Exchange from the Sybari Web site. This update is highly recommended and can improve overall performance and reliability.

To correct this warning

  1. Visit the Sybari Web site, "Licensed Download Center" (http://www.sybari.com/portal/alias__Rainbow/lang__en-US/tabID__3359/DesktopDefault.aspx).

    Note:
    Web addresses can change, so you might be unable to connect to the Web site mentioned here.

  2. Download the latest update for your version of Antigen 7.5 for Microsoft Exchange.

  3. Make a full backup of the Exchange Server computer.

  4. Install the latest update to Antigen 7.5 for Microsoft Exchange.

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange Server computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Sybari Antigen 8.0 for Microsoft Exchange Update for Exchange available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-01-09

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether a Virus Scanning Application Programming Interface (VSAPI) library file is registered with the Microsoft Exchange Information Store service:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

Antigen 8.0 for Microsoft Exchange is a Sybari product. When Antigen 8.0 for Microsoft Exchange is installed on Exchange 2000 Server or Exchange Server 2003, the Library registry entry will have a value of ANTIGENVSAPIEx.DLL. This library file performs several VSAPI-related functions in Antigen 8.0 for Microsoft Exchange.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for ANTIGENVSAPI.DLL. If the value for the Version key indicates that the build number is less than 1517 for this file, a warning is displayed.

A version number of less than 1517 for ANTIGENVSAPI.DLL indicates that the latest version of Antigen 8.0 for Microsoft Exchange is not installed. A software update is available for Antigen 8.0 for Microsoft Exchange from the Sybari Web site. This update is highly recommended and can improve overall performance and reliability.

To correct this warning

  1. Visit the Sybari Web site, "Licensed Download Center" (http://www.sybari.com/portal/alias__Rainbow/lang__en-US/tabID__3359/DesktopDefault.aspx).

    Note:
    Web addresses can change, so you might be unable to connect to the Web site mentioned here.

  2. Download the latest update for your version of Antigen 8.0 for Microsoft Exchange.

  3. Make a full backup of the Exchange Server computer.

  4. Install the latest update to Antigen 8.0 for Microsoft Exchange.

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange Server computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Sybari Antigen is installed on this Exchange server but the AntigenStore service is not running
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether Sybari Antigen is installed and if the AntigenStore service is running on the Exchange computer.

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine whether the value set for the Started key in the Microsoft Exchange Information Store service is set to True or False.

A value of False indicates that the Microsoft Exchange Information Store service is not running on this Exchange Server computer. A value of True indicates that the Microsoft Exchange Information Store service is running.

If the Exchange Server Analyzer finds that the Microsoft Exchange Information Store service is running, and that Sybari Antigen is installed, but the AntigenStore service is not started, a warning is displayed.

Sybari Antigen provides antivirus protection for Exchange Server. Some reasons the Sybari AntigenStore service may have been stopped, together with solutions are listed here.

  • The software you are running on your Exchange Server may be an evaluation or trial version that has expired. In this case, you may need to reinstall Sybari Antigen. At a minimum, to continue using the software, you must activate it.

  • An administrator may have unintentionally stopped the Sybari Antigen service. Verify that the service is set to start automatically, and then start the service.

  • A malicious worm, virus, or other program may have stopped the service. Verify that the service is set to start automatically, and start the service. If the service continues to stop unexpectedly without relevant error events, verify that the computer is not infected with a malicious worm and disinfect the system if needed.

It is generally recommended that you deploy antivirus software designed for messaging systems at either the Simple Mail Transfer Protocol (SMTP) gateway, or at the Exchange servers that host mailboxes. For the most protection, run antivirus software at the gateway that scans the incoming MIME messages, and a scanner on the Exchange Server that uses VSAPI 2.5. Additionally, you should be running client antivirus software on the user desktop. If you are running antivirus software designed for messaging systems (it can parse and scan MIME) at the gateway or on the Exchange server, running a file-level scanner at the desktop is sufficient.

To start the AntigenStore service

  1. Open the Services MMC snap-in.

  2. Right-click AntigenStore service, and then click Properties.

  3. On the General tab of the AntigenStore property page, make sure the Start-up type is set to Automatic. If it is not, set it to Automatic, click Apply, and then click OK.

  4. Right-click AntigenStore service, and then click Start.

  5. Close the Services snap-in.

For information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841

  • 823166, "Overview of Exchange Server 2003 and antivirus software" http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Sybari Antigen is installed on this Exchange server but the service is stopped
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether Sybari Antigen is installed and if the AntigenService service is running on the Exchange Server computer.

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine whether the value set for the Started key in the Microsoft Exchange Information Store service is set to True or False.

A value of False indicates that the Microsoft Exchange Information Store service is not running on this Exchange Server computer. A value of True indicates that the Microsoft Exchange Information Store service is running.

If the Exchange Server Analyzer finds that the Microsoft Exchange Information Store service is running, and that Sybari Antigen is installed, but the AntigenService service is not started, a warning is displayed.

Sybari Antigen provides antivirus protection for Exchange Server. The following are some reasons the Sybari Antigen service may have been stopped, together with solutions:

  • The software you are running on your Exchange Server may be an evaluation (or trial) version that has expired. In this case, you may need to reinstall Sybari Antigen. At a minimum, to continue using the software, you must activate it.

  • An administrator may have unintentionally stopped the Sybari Antigen service. Verify that the service is set to start automatically, and then start the service.

  • A malicious worm, virus, or other program may have stopped the service. Verify that the service is set to start automatically, and start the service. If the service continues to stop unexpectedly without relevant error events, verify that the computer is not infected with a malicious worm and disinfect the system if needed.

It is generally recommended that you deploy antivirus software designed for messaging systems at either the Simple Mail Transfer Protocol (SMTP) gateway or at the Exchange servers that host mailboxes. For the most protection, run antivirus software at the gateway that scans the incoming MIME messages, and run a scanner on the Exchange server that uses VSAPI 2.5. Additionally, you should run antivirus software on the client computers. If you are running antivirus software designed for messaging systems (it can parse and scan MIME) at the gateway or on the Exchange server, running a file-level scanner at the desktop is sufficient.

To start the AntigenService service

  1. Open the Services MMC snap-in.

  2. Right-click AntigenService service, and then click Properties.

  3. On the General tab of the AntigenService property page, make sure the Start-up type is set to Automatic. If it is not, set it to Automatic, click Apply, and then click OK.

  4. Right-click AntigenService service, and then click Start.

  5. Close the Services snap-in.
  • For more information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Symantec Antivirus definitions have not been updated in more than 30 days
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the following conditions are true:

  • The Symantec antivirus is installed on the server.

  • The following antivirus definition files are updated:

    HKEY_LOCAL_MACHINE\Software\Symantec\SharedDefs\MicroDefs

If the Exchange Server Analyzer finds that the value data for the BinHubStamp registry key has not been updated in more than 30 days, the Exchange Server Analyzer displays a warning.

Symantec antivirus for Microsoft Exchange Server provides antivirus protection for Exchange Server. It is recommended that you download the latest Symantec antivirus definition as soon as it is released. Make sure that you deploy the antivirus definition update to the following layers in your organization:

  • Message gateway servers

  • Exchange servers

  • Client workstations

To download the latest virus definitions, see the Symantec antivirus Web site, "Symantec home page" (http://www.symantec.com).

For more information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange Server computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites that are mentioned here.


Symantec Antivirus is installed on this Exchange server but the service is stopped
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether a value is set for the Started key. The Win32_Service class determines whether Symantec Antivirus for Exchange Server is installed. A value of True on the Started key indicates that the Symantec Antivirus service is running on this Exchange Server computer. A value of False on the Started key indicates that the Symantec Antivirus service is not running on this Exchange Server computer.

If the Exchange Server Analyzer finds that the Symantec Antivirus is installed on this Exchange Server computer but the Symantec Antivirus service is not started, the Exchange Server Analyzer displays a warning.

Symantec Antivirus provides antivirus protection for Exchange Server. Some reasons the Symantec Antivirus service may have been stopped, together with solutions, are listed here.

  • The software that you are running on your Exchange server may be an evaluation version or trial version that has expired. In this case, you may have to reinstall Symantec Antivirus. At a minimum, to continue to use the software, you must activate it.

  • An administrator may have unintentionally stopped the Symantec Antivirus service. Verify that the service is set to start automatically, and then start the service.

  • A malicious worm, virus, or other program may have stopped the service. Verify that the service is set to start automatically, and start the service. If the service continues to stop unexpectedly without relevant error events, verify that the computer is not infected with a malicious worm and disinfect the system if it is infected.

It is recommended that you deploy antivirus software designed for messaging systems at either the Simple Mail Transfer Protocol (SMTP) gateway or at the Exchange servers that host mailboxes. For the most protection, run antivirus software at the gateway that scans the incoming MIME messages, and a scanner on the Exchange Server that uses VSAPI 2.5.

To start the Symantec Antivirus service

  1. Open the Services MMC snap-in.

  2. Right-click Symantec Antivirus service, and then click Properties.

  3. On the General tab of the Symantec Antivirus property page, make sure the Start-up type is set to Automatic. If it is not, click Apply, and then click OK.

  4. Right-click Symantec Antivirus service, and then click Start.

  5. Close the Services snap-in.

Additionally, you should run client antivirus software on the user desktop. A file-level scanner at the desktop provides sufficient protection if one of the following conditions is true:

  • You are running antivirus software that is designed for messaging systems that can parse and scan MIME at the gateway.

  • You are running antivirus software that is designed for messaging systems that can parse and scan MIME on the Exchange server.

For more information about the different types of virus-scanning programs that are typically used with Microsoft Exchange Server 2003, see the Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166).

For more information about the different types of virus-scanning programs that are typically used with Microsoft Exchange 2000 Server, see the Knowledge Base article 328841, "Exchange and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841).

For information about fortifying an Exchange Server environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).


Symantec Mail Security for Exchange antivirus scanning configuration alerts
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value set for the Started key for the SMSMSE (Symantec Mail Security for Microsoft Exchange) service.

A value of True indicates that Symantec Mail Security for Microsoft Exchange Server is installed on this Exchange Server computer and that the SMSMSE service is running. A value of False indicates that the SMSMSE service is not running.

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine whether the value set for the Started key in the Microsoft Exchange Information Store service is set to True or False.

A value of False indicates that the Microsoft Exchange Information Store service is not running on this Exchange Server computer. A value of True indicates that the Microsoft Exchange Information Store service is running.

If the Exchange Server Analyzer finds that the Microsoft Exchange Information Store service is running, and that Symantec Mail Security for Microsoft Exchange is installed, but the SMSMSE service is not running, a warning is displayed.

One of the significant threats to your environment is viruses transmitted through e-mail messages. E-mail viruses may attack the computer systems themselves, or they may attack the e-mail environment, by flooding the system with messages to the point of overload. You need to ensure that you have sufficient protection against viruses in your environment. You should consider protecting against viruses at the firewall, at or outside the SMTP gateway, at each Exchange server and on every client.

To correct this warning

  1. Start the Windows Services snap-in on the Exchange Server computer.

  2. In the right pane, scroll down to the Symantec Mail Security for Microsoft Exchange service and double-click it.

  3. Make sure the value in the Startup type drop-down box is set to Automatic.

  4. Click Start to start the Symantec Mail Security for Microsoft Exchange service.

  5. Click OK to save the changes and close the Properties dialog box, and then exit the snap-in.

For information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Symantec Mail Security for Microsoft Exchange 4.5 update available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-02-14

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for Savfmsevsapi.dll. If the value for the Version key indicates that the build number is 4.5 for this file, a warning is displayed.

A version number of 4.5 for Savfmsevsapi.dll indicates that you are not running the most current version of Symantec Mail Security for Microsoft Exchange 4.6x. A software update is available for Symantec Mail Security for Microsoft Exchange 4.6x from the Symantec Web site. Upgrading to version 4.63 or later versions is highly recommended and can improve overall performance and reliability.

The following are some of the known issues when you run the version 4.5 of the Savfmsevsapi.dll.

  • Exchange server mail flow processes can experience a decrease in performance during ordinary operations.

  • SMTP queues such as the Directory Lookup queue and the Local Delivery queue are backed up.

  • The Microsoft Exchange Information Store service cannot be stopped.

  • Microsoft Outlook® clients cannot connect to the Exchange server.

  • Messages sent from Outlook clients take much more time than is typical to deliver a message to the Exchange server. Outlook clients may be unresponsive for 30 seconds.

To correct this warning

  1. Visit the Enterprise Support page of the Symantec Web site (http://www.symantec.com/techsupp/enterprise/).

  2. Upgrade to version 4.63 or a later version.
Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, Exchange and antivirus software (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, Overview of Exchange Server 2003 and antivirus software (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, Recommendations for troubleshooting an Exchange Server computer with antivirus software installed (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see Exchange Server Partners: Antivirus (http://go.microsoft.com/fwlink/?linkid=16226).


Trend Micro ScanMail for Microsoft Exchange Update available
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-01-09

The Microsoft® Exchange Server Analyzer Tool reads the following registry value to determine whether a Virus Scanning Application Programming Interface (VSAPI) library file is registered with the Microsoft Exchange Information Store:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

When ScanMail for Microsoft Exchange, which is a Trend Micro product, is installed on Exchange 2000 Server or Exchange Server 2003, the Library registry entry will have a value of SMXS3DLL.DLL. This library file performs several VSAPI-related functions in ScanMail for Microsoft Exchange.

The Exchange Server Analyzer also queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for SMXS3DLL.DLL. If the value for the Version key indicates that the build number is less than 1174 for this file, a warning is displayed.

A version number of less than 1174 for SMXS3DLL.DLL indicates that the latest version of ScanMail for Microsoft Exchange is not installed. A software update is available for ScanMail for Microsoft Exchange from the Trend Micro Web site. This update is highly recommended and can improve overall performance and reliability.

To correct this warning

  1. Visit the Trend Micro Web site, "Update Center, ScanMail for Microsoft Exchange" (http://www.trendmicro.com/download/product.asp?productid=8).

  2. Download the latest update for your version of ScanMail for Microsoft Exchange.

  3. Take a full backup of the Exchange Server computer.

  4. Install the latest update to ScanMail for Microsoft Exchange.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Trend Micro ServerProtect for Microsoft Windows is stopped
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the SpntSvc service. The SpntSvc service is installed by ServerProtect for Microsoft Windows, which is a Trend Micro product. A value of True for the Started key indicates the service is running, and a value of False indicates the service is not running. If the Exchange Server Analyzer finds the SpntSvc service is not started, a warning is displayed.

ServerProtect for Microsoft Windows provides file system-based antivirus scanning for servers, including detection and removal of viruses in real time.

To start the SpntSvc service

  1. Open the Services MMC snap-in.

  2. Right-click ServerProtect Server service, and then click Properties.

  3. On the General tab of the ServerProtect Server property page, make sure the Start-up type is set to Automatic. If it is not, set it to Automatic, click Apply, and then click OK.

  4. Right-click ServerProtect Server service, and then click Start.

  5. Close the Services snap-in.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Trend ScanMail configuration: performance may be improved
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-09-05

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for TempFileThreshold:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

The TempFileThreshold registry value is applicable for message body and attachment scanning. If the size of the message body or attachment is greater than the value specified in the TempFileThreshold key, the temp file will be created on disk. Otherwise, it will be created in memory. The default value for TempFileThreshold is 3,072 kilobytes (3 MB).

The Exchange Server Analyzer also queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value set for the TotalPhysicalMemory key. This value represents the amount of random access memory (RAM) installed on the computer.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value for the global settings delivContLength attribute located at:

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN= OrganizationName , CN=Global Settings, CN=Message Delivery

This attribute represents the maximum size of incoming SMTP messages.

If the Exchange Server Analyzer finds that the value for TempFileThreshold is less than 70 percent of the maximum incoming message size on an Exchange Server computer with 1 GB or more of RAM, a warning is displayed.

This warning indicates that the TempFileThreshold registry value may not be optimized for your environment. This value should be set to be at least equal to the attachment size limit you have set on your Exchange servers.

Note:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

  3. In the right-hand pane, double-click TempFileThreshold.

  4. Enter a value, in kilobytes, that is equal to the average message size in your orginization. For example, if your average message size is 10 MB, you would enter 10240.
Note:
Additional system memory may be required if you increase this value. For example, if the 'ScanningThreads' value is set to 8, and the 'TempFileThreshold' value is set to 10240, the minimum memory required for virus scanning will be 80 MB (ScanningThreads * TempFileThreshold).
  1. Close the registry editor, and then restart the ScanMail_RealTimeScan service and the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Trend ScanMail configuration: QuerySender registry value is enabled
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-04-20

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Trend Micro ScanMail for Microsoft Exchange ScanMail_Action service. A value of True indicates the ScanMail_Action service is running, and a value of False indicates it is not running.

The Exchange Server Analyzer also reads the following registry entry to determine if ScanMail for Microsoft Exchange is configured for wildcard character searches against the Active Directory® directory service:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\QuerySender

A value of 0 for the QuerySender registry entry indicates wildcard searches are disabled. A value of 1 for the QuerySender entry indicates that wildcard searches are enabled.

In addition, the Exchange Server Analyzer queries Active Directory to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer determines that the ScanMail_Action service is running, that the Exchange Server contains more than 100 mailboxes, and that the QuerySender registry entry is not set to 0, a warning is displayed.

Trend Micro ScanMail for Microsoft Exchange provides antivirus protection for Exchange Server. When ScanMail for Exchange is scanning a message sent to a distribution list, its default behavior is to query the Active Directory global catalog for all message recipients. If there are a large number of recipients in the distribution list, this behavior can cause performance problems. In addition, the following performance counters will be high if the recommendations in this article are not implemented:

  • MSExchangeIS/Virus Scan Queue Length

  • MSExchangeIS/RPC Requests

  • MSExchangeIS/RPC Averaged Latency

Setting the QuerySender value to 0 prevents ScanMail for Microsoft Exchange from querying the global catalog for all recipients when scanning messages sent to distribution lists.

To correct this warning

  1. Contact Trend Micro for information about using the QuerySender registry value (http://www.trendmicro.com/en/about/overview.htm).

  2. For more information about the QuerySender registry value, see Trend Micro Solution ID 120393 (http://esupport.trendmicro.com/support/viewxml.do?ContentID=en-120393).

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).


Trend ScanMail configuration: ScanMail_Monitor service is not dependent on Cluster Service
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry on each server that is a node of a cluster:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

A Version value of 6.2.000 indicates that version 6.2 of ScanMail for Microsoft Exchange is installed.

The Exchange Server Analyzer also queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for ClusSvc, the Cluster service. A value of True indicates the Cluster service is running, and a value of False indicates it is not running.

The Exchange Server Analyzer also reads the following registry entry on each server that is a node of a cluster:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ScanMail_Monitor

If the Exchange Server Analyzer finds that the ScanMail_Monitor key does not include the Multi-Value registry entry DependOnService with a value of ClusSvc, the ScanMail_Monitor service is not dependent on the Cluster service.

The Exchange Server Analyzer displays a Warning message if the following conditions are true:

  • The server is running version TrendMicro ScanMail for Microsoft Exchange 6.2.

  • The server is running the Cluster service (ClusSvc).

  • The ScanMail_Monitor service is not configured to depend on the Cluster service.

After you install builds of ScanMail for Microsoft Exchange 6.2, you must configure the ScanMail_Monitor service to depend on the Cluster service. If you do not configure this dependency, the Cluster service will stop responding every time that the node is restarted.

To correct this warning

  1. See The Microsoft Exchange Cluster Service unexpectedly stops after applying ScanMail for Exchange (SMEX) 6.2 Patch 1 [Solution ID: 21441]at the Trend Micro Web site (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionId=21441&id=21441).

    Note:
    Although Solution ID article 21441 specifically refers to the requirement to configure this dependency after you install Patch 1, this article applies to servers that are running any build of ScanMail for Microsoft Exchange 6.2.

  2. Add the DependOnService Multi-String value to the registry as specified in the "Solutions" section of Solution ID article 21441.
Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

For more information about other Trend Micro product updates, see the Trend Micro Update Center Web site (http://www.trendmicro.com/download/).

For more information about how to use antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, Exchange and antivirus software (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, Overview of Exchange Server 2003 and antivirus software (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, Recommendations for troubleshooting an Exchange Server computer with antivirus software installed (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software available for Exchange Server, see Exchange Server Partners: Antivirus (http://go.microsoft.com/fwlink/?linkid=16226).


Trend ScanMail configuration: SkipWildcardSearchInGC registry value is set to 0
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine value of the Started key for the Trend Micro ScanMail for Microsoft Exchange ScanMail_Action service. A value of True indicates the ScanMail_Action service is running, and a value of False indicates it is not running.

The Exchange Server Analyzer also reads the following registry entry to determine if ScanMail for Microsoft Exchange is configured for wildcard character searches against the Active Directory® directory service:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\SkipWildcardSearchInGC

A value of 1 for the SkipWildcardSearchInGC registry entry indicates wildcard searches are disabled. A value of 0 for the SkipWildcardSearchInGC entry indicates that wildcard searches are enabled.

In addition, the Exchange Server Analyzer also queries Active Directory to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer determines that the ScanMail_Action service is running, that the Exchange server contains more than 100 mailboxes, and that the SkipWildcardSearchInGC registry entry is set to 0, a warning is displayed.

Trend Micro ScanMail for Microsoft Exchange provides antivirus protection for Exchange Server. Setting the SkipWildcardSearchInGC value to 1 prevents ScanMail for Microsoft Exchange from resolving a name with a wildcard character (*) in it. Querying a name with a wildcard character can significantly slow down the Exchange Server computer's performance because ScanMail for Exchange ends up checking the entire directory. In addition, the following performance counters will be high if the recommendations in this article are not implemented:

  • MSExchangeIS/Virus Scan Queue Length

  • MSExchangeIS/RPC Requests

  • MSExchangeIS/RPC Averaged Latency

To correct this warning

  1. Contact Trend Micro for information about using the SkipWildcardSearchInGC registry value (http://www.trendmicro.com/en/about/overview.htm).

  2. For more information about the SkipWildcardSearchInGC registry value, see Trend Micro Solution ID 20393 (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=20393).

    Note:
    Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" at (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).


Trend ScanMail configuration: value for MaxMessageCount registry value is less than 500
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for MaxMessageCount:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion

In addition, the Exchange Server Analyzer also queries the Active Directory® directory service to determine the count of the entries listed in the homeMDBBL attribute of each mailbox store. The count of this attribute represents the number of mailboxes on the mailbox store.

If the Exchange Server Analyzer determines that the Exchange Server contains more than 100 mailboxes, and that the value for MaxMessageCount is less than 500, a warning is displayed.

Trend Micro ScanMail for Microsoft Exchange provides antivirus protection for Exchange Server. After ScanMail for Exchange scanning thread finishes a task, it writes the scanning results to a queue. If there are too many items in that queue, the scanning thread must wait before it can write to the queue and release the thread. The threshold of the scanning result queue size is controlled by MaxMessageCount. Setting the MaxMessageCount value to 500 optimizes performance for ScanMail for Exchange.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion

  3. In the right pane, double-click MaxMessageCount.

  4. Enter a value of 500 (decimal).

  5. Close the registry editor, and then restart the ScanMail_RealTimeScan service and the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about using the MaxMessageCount registry value, see the Trend Micro Web site (http://www.trendmicro.com/en/about/overview.htm).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).


Trend ScanMail is configured to delete all file attachments
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads several registry entries to determine whether ScanMail for Microsoft Exchange is configured to delete attachments. The read values are in the registry at:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption\Advance

Value | Description
ActionType | Indicates which attachments are to be blocked, if attachment blocking is turned on. A value of 0 indicated that all attachments are blocked. A value of 3 indicates that the administrator has specified a list of file name extensions, file names or true file types. This setting can be configured by selecting the appropriate option on the Attachment Blocking Settings dialog box in the ScanMail Management Console.
EnableAlert | Indicates if attachment blocking is enabled. A value of 1 indicates attachment blocking is enabled. A value of 0 indicates it is disabled. This setting can be configured by selecting (enable) or clearing (disable) the Enable attachment blocking check box on the Virus Scan | Options page in the ScanMail Management Console.

HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

Value | Description
EnableEManager | Indicates if ScanMail eManager is enabled. A value of 1 indicates eManager is enabled. A value of 0 indicates it is disabled. This setting can be configured by selecting (enable) or clearing (disable) the Enable eManager check box in the ScanMail Management Console. This setting is only available when ScanMail eManager, a separate, companion product, is installed.
EnableWebStoreDelMail | Indicates if the ScanMail Active Message Filter is enabled for inbound messages. A value of 1 indicates Active Message Filter is enabled for inbound messages. A value of 0 indicates it is not enabled for inbound messages. This setting can be configured by selecting (enable) or clearing (disable) the Inbound Messages check box on the Active Message Filter dialog box in the ScanMail Management Console.

The Exchange Server Analyzer also reads the following registry entry to determine whether Virus Scanning API (VSAPI) message scanning is enabled:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

A value of 1 for Enabled indicates that VSAPI scanning is enabled. A value of 0 indicates VSAPI scanning is not enabled. This setting can be configured by selecting (enable) or clearing (disable) the Enable VS API virus scanning check box on the Virus Scan | Options page in the ScanMail Management Console.

If the Exchange Server Analyzer finds that all the following criteria are true, a warning is displayed:

  • VSAPI scanning is Enabled in ScanMail for Exchange

  • EnableAlert has a value of 1

  • ActionType has a value of 0

  • EnableEManager has a value of 1

  • EnableWebStoreDelMail has a value of 1

This warning indicates that ScanMail is configured to delete all attachments during the next scheduled or manual scan.

To correct this warning

  1. Verify that you want attachments deleted.

  2. If you want to, disable attachment blocking or change the action from Delete to Quarantine. This enables an administrator to examine the quarantined files for attachments that may need to be kept.

For more information about ScanMail for Microsoft Exchange and ScanMail eManager, visit the Trend Micro Web site (http://www.trend.com).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Trend ScanMail is configured to delete attachments with specific file names
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads several registry entries to determine if ScanMail for Microsoft Exchange is configured to delete attachments. The read values are located in the registry at:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption\Advance

Value | Description
ActionType | Indicates which attachments are to be blocked, if attachment blocking is turned on. A value of 0 indicates that all attachments are blocked. A value of 3 indicates that the administrator has specified a list of file name extensions, file names, or true file types. This setting can be configured by selecting the desired option on the Attachment Blocking Settings dialog box in the ScanMail Management Console.
EnableAlert | Indicates if attachment blocking is enabled. A value of 1 indicates attachment blocking is enabled. A value of 0 indicates it is disabled. This setting can be configured by selecting (enable) or clearing (disable) the Enable attachment blocking check box on the Virus Scan | Options page in the ScanMail Management Console.
FileName | A semicolon delimited string value containing a list of files to be deleted. When specified files are being blocked, this setting can be configured by entering the desired file names on the Attachment Blocking Settings dialog box in the ScanMail Management Console.

HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

Value | Description
EnableEManager | Indicates if ScanMail eManager is enabled. A value of 1 indicates eManager is enabled. A value of 0 indicates it is disabled. This setting can be configured by selecting (enable) or clearing (disable) the Enable eManager check box in the ScanMail Management Console. This setting is only available when ScanMail eManager, a separate, companion product, is installed.
EnableWebStoreDelMail | Indicates if the ScanMail Active Message Filter is enabled for inbound messages. A value of 1 indicates Active Message Filter is enabled for inbound messages. A value of 0 indicates it is not enabled for inbound messages. This setting can be configured by selecting (enable) or clearing (disable) the Inbound Messages check box on the Active Message Filter dialog box in the ScanMail Management Console.

The Exchange Server Analyzer also reads the following registry entry to determine if Virus Scanning API (VSAPI) message scanning is enabled:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

A value of 1 for Enabled indicates that VSAPI scanning is enabled. A value of 0 indicates VSAPI scanning is not enabled. This setting can be configured by selecting (enable) or clearing (disable) the Enable VS API virus scanning check box on the Virus Scan | Options page in the ScanMail Management Console.

If the Exchange Server Analyzer finds that all of the following criteria are true, a warning is displayed:

  • VSAPI scanning is enabled in ScanMail for Exchange

  • EnableAlert has a value of 1

  • ActionType has a value of 3

  • EnableEManager has a value of 1

  • EnableWebStoreDelMail has a value of 1

  • FileName is not null or empty

This warning indicates that ScanMail is configured to delete all attachments with the names listed in the FileName key during the next scheduled or manual scan.

To correct this warning

  1. Verify that you want attachments that have the names listed in the FileName key deleted.

  2. If desired, disable attachment blocking or change the action from Delete to Quarantine. This enables an administrator to examine the quarantined files for attachments that may need to be kept.

For more information about ScanMail for Microsoft Exchange and ScanMail eManager, see the Trend Micro Web site (http://www.trend.com).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Trend ScanMail is configured to delete attachments with specific file extensions
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads several registry entries to determine whether ScanMail for Microsoft Exchange Server is configured to delete attachments. The read values are in the registry at:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption\Advance

Value | Description
ActionType | Indicates which attachments are to be blocked, if attachment blocking is turned on. A value of 0 indicates that all attachments are blocked. A value of 3 indicates that the administrator has specified a list of file extensions, file names, or true file types. This setting can be configured by selecting the desired option on the Attachment Blocking Settings dialog box in the ScanMail Management Console.
EnableAlert | Indicates if attachment blocking is enabled. A value of 1 indicates attachment blocking is enabled. A value of 0 indicates it is disabled. This setting can be configured by selecting (enable) or clearing (disable) the Enable attachment blocking check box on the Virus Scan | Options page in the ScanMail Management Console.
Extension | A semicolon delimited string value containing a list of file extensions for the attachments to be deleted. When specified attachments are being blocked, this setting can be configured by entering the desired extensions on the Attachment Blocking Settings dialog box in the ScanMail Management Console.

HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

Value | Description
EnableEManager | Indicates if ScanMail eManager is enabled. A value of 1 indicates eManager is enabled. A value of 0 indicates it is disabled. This setting can be configured by selecting (enable) or clearing (disable) the Enable eManager check box in the ScanMail Management Console. This setting is only available when ScanMail eManager, a separate, companion product, is installed.
EnableWebStoreDelMail | Indicates if the ScanMail Active Message Filter is enabled for inbound messages. A value of 1 indicates Active Message Filter is enabled for inbound messages. A value of 0 indicates it is not enabled for inbound messages. This setting can be configured by selecting (enable) or clearing (disable) the Inbound Messages check box on the Active Message Filter dialog box in the ScanMail Management Console.

The Exchange Server Analyzer also reads the following registry entry to determine if Virus Scanning API (VSAPI) message scanning is enabled:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

A value of 1 for Enabled indicates that VSAPI scanning is enabled. A value of 0 indicates VSAPI scanning is not enabled. This setting can be configured by selecting (enable) or clearing (disable) the Enable VS API virus scanning check box on the Virus Scan | Options page in the ScanMail Management Console.

If the Exchange Server Analyzer finds that all of the following criteria are true, a warning is displayed:

  • VSAPI scanning is Enabled in ScanMail for Exchange

  • EnableAlert has a value of 1

  • ActionType has a value of 3

  • EnableEManager has a value of 1

  • EnableWebStoreDelMail has a value of 1

  • Extension is not null or empty

This warning indicates that ScanMail is configured to delete all attachments with the extensions listed in the Extension key during the next scheduled or manual scan.

To correct this warning

  1. Verify that you want attachments with the extensions listed in the Extension key deleted.

  2. If you want to, disable attachment blocking or change the action from Delete to Quarantine. This enables an administrator to examine the quarantined files for attachments that may need to be kept.

For more information about ScanMail for Microsoft Exchange Server and ScanMail eManager, visit the Trend Micro Web site (http://www.trend.com).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Trend ScanMail is configured to process messages twice
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the ScanMail_RealTimeScan service. A value of True indicates the ScanMail_RealTimeScan service is started, and a value of False indicates the ScanMail_RealTimeScan service is not started. The ScanMail_RealTimeScan service is a component of the Trend Micro ScanMail for Microsoft Exchange application. Trend Micro ScanMail for Microsoft Exchange provides antivirus protection for Exchange.

In addition, the Exchange Server Analyzer reads the following registry entry to determine the setting for the Enabled value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\TransportAVAPI

A value of 1 for Enabled indicates that transport-level antivirus scanning (sometimes referred to as Simple Mail Transfer Protocol (SMTP) scanning) is enabled, and a value of 0 indicates that SMTP scanning is not enabled.

If the Exchange Server Analyzer finds Enabled set to 1, and the value of the Started key for the ScanMail_RealTimeScan service set to True, a warning is displayed.

This warning indicates that messages flowing through this Exchange Server computer are being scanned twice by the same application and virus scanning engine. Scanning the same message twice as it moves through the transport and storage components of Exchange Server needlessly consumes resources and does not provide any extra protection or benefits. It is recommended that you keep Virus Scanning API (VSAPI) virus scanning enabled, and disable SMTP mail scanning using the ScanMail Management Console.

It is generally recommended that you deploy antivirus software designed for messaging systems at either the SMTP gateway or at the Exchange servers that host mailboxes. For the most protection, run antivirus software at the gateway that scans the inbound MIME messages and a scanner on the Exchange Server that uses VSAPI 2.5. In addition, you should be running client antivirus software on the user desktop. If you are running antivirus software designed for messaging systems (it can parse and scan MIME) at the gateway or on the Exchange server, running a file-level scanner at the desktop is sufficient.

To correct this warning

  1. Open the ScanMail Management Console and enter your logon credentials.

  2. On the Virus Scan | Options page, ensure that the Enable VS API virus scanning check box is selected.

  3. On this same page, clear the Enable SMTP mail scanning check box.

  4. Click Apply to save your changes.

  5. Close the ScanMail Management Console.

For more information about Trend Micro ScanMail for Microsoft Exchange, see the Trend Web site (http://kb.trendmicro.com/solutions/search).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)


Trend ScanMail low thread count
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for MaxScanningThreadCount:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

The MaxScanningThreadCount registry value represents the maximum number of threads that ScanMail for Exchange can create for scanning. The default value is 12.

The Exchange Server Analyzer also reads the following registry entry to determine if Virus Scanning API (VSAPI) message scanning is enabled:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

A value of 1 for Enabled indicates that VSAPI scanning is enabled. A value of 0 indicates VSAPI scanning is not enabled.

The Exchange Server Analyzer also queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value set for the NumberOfProcessors key. This value represents the number of processors installed on the computer, and it includes both physical processors and logical processors. Using Hyper-Threading technology from Intel, a physical processor can be split into two logical processors.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the number of objects with an object class of msExchPrivateMDB. The count of these objects represents the number of mailbox stores on this Exchange Server computer.

If the Exchange Server Analyzer finds that the value for MaxScanningThreadCount is less than (2 × NumberOfProcessors + 1) + 3 + the number of mailbox stores) on an Exchange Server computer that has VSAPI scanning enabled, a warning is displayed.

Note:
If Hyper-Threading is enabled, the value for NumberOfProcessors will be double the number of physical processors. It is recommended that you use the above formula for systems that have physical processors, as well as for systems that have both physical and logical processors.

This warning indicates that the MaxScanningThreadCount registry value may not be optimized for your environment. This value should be set to be at least equal to the attachment size limit you have set on your Exchange servers. For information about a related registry value, see Trend ScanMail low thread pool count.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

  3. In the right pane, double-click MaxScanningThreadCount.

  4. Enter a value recommended by the Exchange Server Analyzer.

  5. Close the registry editor and restart the ScanMail_RealTimeScan service and the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the MaxScanningThreadCount registry value, see Trend Micro Solution ID 13176 (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=13176).

For more information about Hyper-Threading technology, see the Intel Web site (http://www.intel.com/technology/hyperthread).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Trend ScanMail low thread pool count
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for ScanningThreadPoolCount:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

The ScanningThreadPoolCount registry value represents the number of scanning threads that will be initialized and readied for use when ScanMail for Exchange services is started. The default value is 12. When all the threads created on startup are used up, ScanMail for Exchange will create additional threads to be used until it reaches the number of threads controlled by the MaxScanningThreadCount registry value described in Trend ScanMail low thread count.

The Exchange Server Analyzer also reads the following registry entry to determine whether Virus Scanning API (VSAPI) message scanning is enabled:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

A value of 1 for Enabled indicates that VSAPI scanning is enabled. A value of 0 indicates VSAPI scanning is not enabled.

The Exchange Server Analyzer also queries the Win32_ComputerSystem Microsoft Windows® Management Instrumentation (WMI) class to determine the value set for the NumberOfProcessors key. This value represents the number of processors installed on the computer, and it includes both physical processors and logical processors. Using Hyper-Threading technology from Intel, a physical processor can be split into two logical processors.

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the number of objects with an object class of msExchPrivateMDB. The count of these objects represents the number of mailbox stores on this Exchange Server computer.

If the Exchange Server Analyzer finds that the value for ScanningThreadPoolCount is less than (2 × NumberOfProcessors + 1) + 3 + the number of mailbox stores) on an Exchange Server computer that has VSAPI scanning enabled, a warning is displayed.

Note:
If Hyper-Threading is enabled, the value for NumberOfProcessors will be double the number of physical processors. It is recommended that you use the above formula for systems that have physical processors, as well as for systems that have both physical and logical processors.

This warning indicates that the ScanningThreadPoolCount registry value may not be optimized for your environment. This value should be set to be at least equal to the attachment size limit you have set on your Exchange servers.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption.

  3. In the right pane, double-click ScanningThreadPoolCount.

  4. Enter a value recommended by the Exchange Server Analyzer.

  5. Close the registry editor, and then restart the ScanMail_RealTimeScan service and the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about Hyper-Threading technology, visit the Intel Web site (http://www.intel.com/technology/hyperthread).

Note:
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Trend ScanMail is in debug mode
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-06-22

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the value for ModuleName:

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\Tools\Debug

The ModuleName registry value represents the name of the debug module file in use.

The Exchange Server Analyzer also reads the following registry entry to determine if Virus Scanning API (VSAPI) message scanning is enabled:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

A value of 1 for Enabled indicates that VSAPI scanning is enabled. A value of 0 indicates VSAPI scanning is not enabled.

If the Exchange Server Analyzer finds VSAPI scanning is enabled and that the ModuleName registry value is not empty or null, a warning is displayed.

Running in debug mode causes substantial performance degradation because of the background diagnostic tracing involved. Unless you are actively troubleshooting a problem that requires you to run ScanMail for Exchange in debug mode, you should turn off debug mode.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\TrendMicro\ScanMail for Exchange\Tools\Debug.

  3. In the right pane, double-click ModuleName.

  4. Delete the value data for this entry, leaving the string blank. Do not delete the ModuleName key.

  5. Close the registry editor and restart the ScanMail_RealTimeScan service and the Microsoft Exchange Information Store service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about verifying that debug mode has been disabled, see Trend Micro Solution ID 119149 (http://esupport.trendmicro.com/support/viewxml.do?ContentID=en-119149).

Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.


Trend ScanMail Mail Action service is installed on this Exchange server but the service is stopped
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether Trend Micro ScanMail for Exchange is installed and if the ScanMail_MailAction service is running on the Exchange computer.

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine whether the value set for the Started key in the Microsoft Exchange Information Store service is set to True or False.

A value of False indicates that the Microsoft Exchange Information Store service is not running on this Exchange Server computer. A value of True indicates that the Microsoft Exchange Information Store service is running.

If the Exchange Server Analyzer finds that the Microsoft Exchange Information Store service is running, and that Trend Micro ScanMail for Exchange is installed, but the ScanMail_MailAction service is not started, a warning is displayed.

Trend Micro ScanMail for Exchange provides antivirus protection for Exchange Server. Some reasons the Trend ScanMail service may have been stopped, together with solutions, are listed here.

  • The software you are running on your Exchange server may be an evaluation or trial version that has expired. In this case, you may need to reinstall Trend ScanMail. At a minimum, to continue using the software, you must activate it.

  • An administrator may have unintentionally stopped the ScanMail_MailAction service. Verify that the service is set to start automatically, and then start the service.

  • A malicious worm, virus, or other program may have stopped the service. Verify that the service is set to start automatically, and start the service. If the service continues to stop unexpectedly without relevant error events, verify that the computer is not infected with a malicious worm and disinfect the system if needed.

It is generally recommended that you deploy antivirus software designed for messaging systems at either the Simple Mail Transfer Protocol (SMTP) gateway or at the Exchange servers that host mailboxes. For the most protection, run antivirus software at the gateway that scans the incoming MIME messages, and a scanner on the Exchange server that uses VSAPI 2.5. Additionally, you should be running client antivirus software on the user desktop. If you are running antivirus software designed for messaging systems (it can parse and scan MIME) at the gateway or on the Exchange server, running a file-level scanner at the desktop is sufficient.

To start the ScanMail_MailAction service

  1. Open the Services MMC snap-in.

  2. Right-click the ScanMail_MailAction service, and then click Properties.

  3. On the General tab of the ScanMail_MailAction property page, make sure the Start-up type is set to Automatic. If it is not, set it to Automatic, click Apply, and then click OK.

  4. Right-click the ScanMail_MailAction service, and then click Start.

  5. Close the Services snap-in.
  • For information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?linkid=16226).


Trend ScanMail real-time service is installed on this Exchange server but the service is stopped
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine whether Trend Micro ScanMail for Microsoft Exchange is installed and if the ScanMail_RealTimeScan service is running on the Exchange Server computer. If the Exchange Server Analyzer finds Trend Micro ScanMail for Microsoft Exchange is installed, but the ScanMail_RealTimeScan service is not started, a warning is displayed.

Trend Micro ScanMail for Microsoft Exchange provides antivirus protection for Exchange. Some reasons the ScanMail_RealTimeScan service may have been stopped, and solutions are listed here:

  • The software you are running on your Exchange server may be an evaluation (or trial) version that has expired. In this case, you may need to reinstall Trend Micro ScanMail for Microsoft Exchange. At a minimum, to continue using the software, you must activate it.

  • An administrator may have unintentionally stopped the ScanMail_RealTimeScan service. Verify that the service is set to start automatically, and then start the service.

  • A malicious worm, virus, or other program may have stopped the service. Verify that the service is set to start automatically, and start the service. If the service continues to stop unexpectedly without relevant error events, verify that the computer is not infected with a malicious worm and disinfect the system if needed.

It is generally recommended that you deploy antivirus software designed for messaging systems at either the Simple Mail Transfer Protocol (SMTP) gateway or at the Exchange servers that host mailboxes. For the most protection, run antivirus software at the gateway that scans the inbound MIME messages, and a scanner on the Exchange server that uses Virus Scanning API (VSAPI) version 2.5. Additionally, you should be running client antivirus software on the user desktop. If you are running antivirus software designed for messaging systems (it can parse and scan MIME) at the gateway or on the Exchange server, running a file-level scanner at the desktop is sufficient.

To start the ScanMail_RealTimeScan service

  1. Open the Services MMC snap-in.

  2. Right-click ScanMail_RealTimeScan service, and then click Properties.

  3. On the General tab of the ScanMail_RealTimeScan property page, make sure the Start-up type is set to Automatic. If it is not, set it to Automatic, click Apply, and then click OK.

  4. Right-click ScanMail_RealTimeScan service, and then click Start.

  5. Close the Services snap-in.
  • For information about fortifying an Exchange environment against e-mail transmitted viruses and worms, see "Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment" (http://go.microsoft.com/fwlink/?LinkId=47587).

For more information about using antivirus software with Exchange Server, see the following Microsoft Knowledge Base articles:

  • 328841, "XADM: Exchange and Antivirus Software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 306105, "XGEN: Microsoft's Position on Antivirus Solutions for Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 245822, "Recommendations for troubleshooting an Exchange computer with antivirus software installed" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

For a list of third-party antivirus software that is available for Exchange Server, see the Exchange Server Partners: Antivirus Web site (http://go.microsoft.com/fwlink/?LinkId=16226).


Turn Off Third-Party Add-ins on Client
Microsoft Exchange Server Analyzer - Articles > Third-Party Software >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool has determined that you are running one of the following types of third-party software:

  • A third-party Microsoft Office Outlook® add-in, such as antivirus software or fax software

  • A third-party application that accesses your Exchange server

  • Third-party synchronization software for mobile devices

It is recommended that you investigate what types of third-party applications your users are running, and then decide whether you want to put restrictions on those applications or remove the applications completely. Remember that running third-party software can frequently cause excessive loads on your servers.

To turn off third-party add-ins in Outlook

  1. In Outlook, from the Tools menu, click Options.

  2. In Options, click the Other tab, and then click Advanced Options.

  3. In Advanced Options, click Add-In Manager.

  4. Clear the check boxes for any third-party add-ins.

  5. Click OK.

  6. Restart Outlook.

For More Information

  • For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).

  • For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).


Transport
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2005-11-18

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating with regard to Exchange transport components. Additionally, these articles describe actions that you can take to resolve transport-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


8BITMIME not registered
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-18

The Microsoft® Exchange Server Analyzer Tool transmits the EHLO Extended Simple Mail Transfer Protocol (ESMTP) command verb to port 25 of a remote server and analyzes the response to determine whether the remote server supports the 8BITMIME ESMTP verb.

If the response received from the remote server does not include the string '250-8BITMIME', the Exchange Server Analyzer displays a warning.

Exchange Server 2003 uses Exchange-specific extended SMTP verbs to communicate with other servers that are running Exchange Server in the organization. It is more efficient to communicate with Exchange-specific extended SMTP verbs than by using standard SMTP. If support for the ESMTP command set is disabled, Exchange Server performance may be hindered.

This error indicates that the remote server does not support the ESMTP 8BITMIME command verb. The error does not indicate that the remote server is or is not an Exchange server. In either instance, messages that require the 8BITMIME extension are not routed.

To address this issue, check the contents of the SMTP queues for messages that require the 8BITMIME extension.

For more information about how to remove or restore the default support for these verbs, see Microsoft Knowledge Base article 257569 "How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257569).

For more information about how Exchange Server uses the ESMTP command verbs, see "How to Load Exchange SMTP Properly" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=71800)


ADAM LDAP Port Identified
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-07-23

The Microsoft Exchange Analyzer Tool reads the following registry entries to determine the ports that are used by the Active Directory Application Mode (ADAM) directory service on the Edge Transport server:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\EdgeTransportRole\AdamSettings\MsExchangeAdam\LdapPort

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\EdgeTransportRole\AdamSettings\MsExchangeAdam\SslPort

ADAM is a Lightweight Directory Access Protocol (LDAP) directory service that is designed specifically for use with directory-enabled applications. ADAM stores and replicates only application-specific information and does not require deployment on a domain controller or depend on the Active Directory directory service. ADAM does not provide network operating system authentication or authorization.

In Microsoft Exchange Server 2007, the Edge Transport server role uses ADAM to store configuration information and recipient data for content filtering. When ADAM is synchronized with Active Directory, it can also be used to perform recipient lookup for message security.

When data is sent to ADAM from Active Directory, it is sent by using an LDAP connection through the following nondefault ports:

  • LDAP: Port 50389/TCP

  • Secure LDAP: Port 50636/UDP

When the Exchange Analyzer identifies the ports that are used by ADAM, the Exchange Analyzer displays a best practices message.

As a best practice, we recommend blocking all nonessential ports to outside access.

To address this issue, check that the ports identified by the Exchange Analyzer as used for ADAM are not open to outside access.

Caution:
Port 50636/UDP is used for the Exchange EdgeSync service and should remain open if EdgeSync functionality is desired.
To block the identified ADAM ports to outside access using Windows Firewall

  1. Click Start, Run, type firewall.cpl , and then click OK.

  2. Click the Exceptions tab.

  3. Select each Program or Service listed in the Name box and then click Edit to review the ports that are open.

  4. Verify that the ports reported by the Exchange Analyzer as used for ADAM are not listed.

  5. If the identified ports are listed, make sure that they are not used for other necessary communication, and close them by deselecting them in the Edit a Service window.

  6. Click OK two times to exit Windows Firewall configuration.

For More Information

For more information about ports, authentication and encryption for all data paths used by Exchange 2007, see "Data Path Security Reference" (http://go.microsoft.com/fwlink/?LinkId=95630).


Antivirus plug-in installed
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-18

The Microsoft® Exchange Server Analyzer Tool scans for the following registry entry to determine whether the Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is installed:

HKEY_LOCAL_MACHINE\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Snap-In\InternetMail

The presence of this registry branch indicates that the Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is installed on the server that is running Exchange Server.

The Exchange Server Analyzer also reads the following registry entry to determine whether the Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is enabled:

HKLM\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Snap-In\InternetMail\RealTimeScan\OnOff

A value of 1 for OnOff indicates that the Auto Protect plug-in is enabled. A value of 0 indicates the Auto Protect plug-in is not enabled.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • The Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is installed.

  • The Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is not enabled.

This warning indicates that the installation and configuration of the plug-in should be reviewed against current vendor recommended best practices.

For more information about the vendor recommended best practices for this plug-in, see "Best practices for Symantec AntiVirus Corporate Edition 9.x Auto-Protect on a Microsoft Exchange server" (http://service1.symantec.com/SUPPORT/ent-security.nsf/c9b1ac1936fbf63488256e77006521df/3d1bcbc855fce10288256e9e007e01f0?OpenDocument&src=bar_sch_nam).

Note:
The third-party Web site information in this topic is provided to help you find the technical information that you need. The URLs are subject to change without notice.


Antivirus plug-in enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-18

The Microsoft® Exchange Server Analyzer Tool scans for the following registry entry to determine whether the Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is installed.

HKEY_LOCAL_MACHINE\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Snap-In\InternetMail

The presence of this registry entry indicates that the Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is installed on the server that is running Exchange Server.

The Exchange Server Analyzer also reads the following registry entry to determine whether the Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is enabled.

HKLM\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Snap-In\InternetMail\RealTimeScan\OnOff

A value of 1 for OnOff indicates that the Auto Protect plug-in is enabled. A value of 0 indicates the Auto Protect plug-in is not enabled.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is installed.

  • The Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect plug-in is enabled.

This error indicates that the installation and configuration of the plug-in should be reviewed against current vendor recommended best practices.

For more information about the vendor recommended best practices for this plug-in, see "Best practices for Symantec AntiVirus Corporate Edition 9.x Auto-Protect on a Microsoft Exchange server" (http://service1.symantec.com/SUPPORT/ent-security.nsf/c9b1ac1936fbf63488256e77006521df/3d1bcbc855fce10288256e9e007e01f0?OpenDocument&src=bar_sch_nam).

Note:
The third-party Web site information in this topic is provided to help you find the technical information that you need. The URLs are subject to change without notice.


BCC journaling is enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether blind carbon copy (Bcc) journaling is enabled:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters\JournalBCC

If the Exchange Server Analyzer finds that the value for JournalBCC is set to 1, the Exchange Server Analyzer displays a non-default configuration message.

Bcc journaling is message-only journaling with the added ability to capture the Bcc recipients. When Bcc journaling is enabled, Exchange Server captures all recipients, including Bcc recipients, that are known at the originating server. If this recipient list includes hidden distribution lists, query-based distribution lists, or distribution lists that are expanded on another server, the recipients for these lists are not included in the journalized mail.

The Bcc journaling functionality is enabled by setting a registry key. For more information about setting this registry key, see Microsoft Knowledge Base article 810999, "XADM: Bcc Information Is Lost for Journaled Messages in Exchange 2000" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810999).

To enable Bcc journaling on a specific server, you must first configure message-only journaling. The JournalBCC setting is not active when the following conditions exist:

  • The JournalBCC registry is set to 1.

  • Message-only journaling is not enabled on any of the databases on the same server.

Journaling messages can consume many disk, network, and CPU resources. Therefore, journaling requires thorough deployment planning. Journaling should be enabled only in the context of an overall journaling solution framework.

Ignore this non-default configuration message if the following conditions exist:

  • Your business requires journaling.

  • You have deployed a journaling solution framework.

Otherwise, you should turn off journaling functionality. By turning off journaling on the database, you disable journaling.

To turn off message-only journaling on a database

  1. In Exchange System Manager, expand Servers, expand <your Exchange server>, expand <storage group>, and then right-click the mailbox store.

  2. On the General tab, clear the check box Archive all messages sent or received by mailboxes on this store.

  3. Wait 15 minutes for the Exchange store to apply changes. You do not have to restart the Microsoft Exchange Information Store service.

If you do not want the Exchange Server Analyzer to display this message again, you must delete the JournalBCC registry key. Deleting the JournalBCC registry key is not required to disable journaling functionality.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To delete the JournalBCC registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters\

  3. In the right pane, locate and delete the JournalBCC value.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about deploying a journaling solution, see Journaling with Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47581).


BDAT not registered
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-18

The Microsoft® Exchange Server Analyzer Tool transmits the EHLO Extended Simple Mail Transfer Protocol (ESMTP) command verb to port 25 of a remote server and analyzes the response to determine whether the remote server supports the BDAT ESMTP verb.

If the Exchange Server Analyzer receives a response with a string that indicates a non-retrievable error from the remote server, the Exchange Server Analyzer displays an error.

Exchange Server 2003 uses Exchange-specific extended SMTP verbs to communicate with other servers that are running Exchange Server in the organization. It is more efficient to communicate with Exchange-specific extended SMTP verbs than by using standard SMTP. If support for the ESMTP command set is disabled, Exchange Server performance may be hindered.

This error indicates that the remote server does not support the ESMTP BDAT command verb. The error does not indicate that the remote server is or is not an Exchange server. In either instance, messages that require the BDAT extension are not routed.

To address this issue, check the contents of the SMTP queues for messages that require the BDAT extension.

For more information about how to remove or restore the default support for these verbs, see Microsoft Knowledge Base article 257569 "How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257569).

For more information about how Exchange Server uses the ESMTP command verbs, see "How to Load Exchange SMTP Properly" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=71800).


Bridgehead server to check distribution group delivery restrictions for RGC
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-09-18

The Microsoft® Exchange Server Analyzer Tool queries the following attributes for each routing group connector object (msExchRoutingGroupConnector) detected in the Active Directory® directory service to determine whether delivery restrictions are set based on distribution group membership.

dLMemRejectPerms | Contains the domain names (DNs) of a distribution list (DL) whose members may not send through this routing group connector.
dLMemSubmitPerms | Contains the DNs of a distribution list (DL) whose members may send through this routing group connector.

If the Exchange Server Analyzer finds routing group connectors that have delivery restrictions based on distribution group membership, the Exchange Server Analyzer queries the msExchSourceBridgeheadServersDN attribute of the detected routing group connectors to determine whether the server being analyzed is set as a bridgehead server for any of those connectors.

Finally, the Exchange Server Analyzer reads the following registry key to determine whether the CheckConnectorRestrictions registry value is present and configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Resvc\Parameters

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • A routing group connector is used to restrict delivery based on distribution group membership.

  • The Exchange server being analyzed is designated as the bridgehead server for that routing group connector and is tasked with the distribution group expansion.

  • The CheckConnectorRestrictions key is present, set to 1, and therefore enabled.

The default behaviors for the categorizer is to recursively expand distribution groups and check restrictions for each message that passes through the system.

When you create a routing group, you designate a group of servers that can communicate directly with each other. For servers in different routing groups to communicate with each other, you must connect the routing groups.

The preferred connection method is a routing group connector because this connector is designed and intended specifically for connecting routing groups.

Servers that can send mail over a routing group connector are bridgehead servers. A bridgehead server is a combination of a Simple Mail Transfer Protocol (SMTP) virtual server and an Exchange server that is responsible for delivering all messages through a connector.

When you create a routing group connector, you can choose to keep all the servers as bridgehead servers for that connector or else specify that only a selected set of servers act as bridgehead servers for that connector. The designated bridgeheads are the servers that are tasked with the expansion of distribution group membership.

When you send mail by using routing group connectors that have delivery restrictions set based on distribution group membership, the message categorizer has to expand the membership of the distribution group, obtain the full list of DNs of the members, and then compare the list of DNs to the list sender's DNs. An access operation or a deny operation occurs when a DN on both lists match. If a distribution group is nested in another distribution group, the nested distribution is also expanded.

This warning indicates that the delivery restrictions based on distribution group membership may cause messages destined for the bridgehead to queue as the categorizer checks the restrictions.

To address this warning:

  • Configure the routing group connector to a local routing group as referenced in Microsoft Knowledge Base article 329171, "XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171).

  • Use a dedicated and more robust global catalog server as the designated bridgehead server for the connector.

  • Configure individual mailboxes and not distribution groups for delivery restrictions as referenced in Microsoft Knowledge Base article 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

  • Consider implementing SMTP Sender Filtering.

  • For servers that run Microsoft Exchange Server 2003 Service Pack 2 (SP2) or a later version, consider implementing non-hierarchal restriction checking. For servers that run Exchange versions earlier than Exchange 2003 SP2, consider upgrading to Exchange 2003 SP2.

For More Information

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking.

For more information about SMTP Sender Filtering, see "How to Enable Sender Filtering" in the Administration Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=71832).

For more information about the effect of distribution group restriction on Exchange mail flow, see the following Microsoft Knowledge Base articles:

  • 329171 " XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171).

  • 895407 "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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


Bridgehead server to check distribution group delivery restrictions for SMTP Connector
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool queries the following attributes for each Simple Mail Transfer Protocol (SMTP) connector object (msExchRoutingSMTPConnector) detected in the Active Directory® directory service to determine whether delivery restrictions are set based on distribution group membership.

dLMemRejectPerms | Contains the domain names (DNs) of a distribution list (DL) whose members may not send to through this SMTP connector.
dLMemSubmitPerms | Contains the DNs of a distribution list (DL) whose members may send through this SMTP connector.

If the Exchange Server Analyzer finds SMTP connectors that have delivery restrictions based on distribution group membership, the Exchange Server Analyzer then queries the msExchSourceBridgeheadServersDN attribute of the detected SMTP connectors to determine whether the server being analyzed is set as a bridgehead server for any of those connectors.

Finally, the Exchange Server Analyzer reads the following registry key to determine whether the CheckConnectorRestrictions registry value is present and configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Resvc\Parameters

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • An SMTP connector is used to restrict delivery based on distribution group membership.

  • The Exchange server being analyzed is designated as the bridgehead server for that SMTP connector and is tasked with the distribution group expansion.

  • The CheckConnectorRestrictions key is present, set to 1, and therefore enabled.

The default behaviors for the categorizer is to recursively expand distribution groups and check restrictions for each message that passes through the system.

When you send mail by using a connector that accepts or denies messages from a distribution group, the message categorizer has to expand the membership of the distribution group, obtain the full list of DNs of the members, and then compare the list of DNs to the list sender's DNs. An access operation or a deny operation occurs when a DN on both lists match. If a distribution group is nested in another distribution group, the nested distribution is also expanded.

The designated bridgehead is the server tasked with the expansion of distribution group membership.

Restriction checking is controlled by the CheckConnectorRestrictions registry value that must be set on the Exchange bridgehead server that is the source for the connector that is being checked. If you specify a restriction but do not create the CheckConnectorRestrictions registry value, the restriction is not checked.

By default, connector restriction checking is turned off. System performance is significantly affected if distribution groups are expanded and restrictions are checked for each message that passes through the system.

This warning indicates that the delivery restrictions based on distribution group membership may cause messages destined for the bridgehead to queue as the categorizer checks the restrictions.

To address this warning:

  • Design a dedicated routing group for connector restrictions and configure it to a local routing group as referenced in Microsoft Knowledge Base article 329171, "XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171)

  • Use a dedicated and more robust global catalog server as the designated bridgehead server for the connector.

  • Configure individual mailboxes and not distribution groups for delivery restrictions as referenced in Microsoft Knowledge Base article 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)

  • Consider implementing SMTP Sender Filtering.

  • For servers that run Microsoft Exchange Server 2003 Service Pack 2 (SP2) or a later version, consider implementing non-hierarchal restriction checking. For servers that run Exchange versions earlier than Exchange 2003 SP2, consider upgrading to Exchange 2003 SP2.

For More Information

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking.

For more information about SMTP Sender Filtering, see "How to Enable Sender Filtering" in the Administration Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=71832).

For more information about the effect of distribution group restriction on Exchange mail flow, see the following Microsoft Knowledge Base articles:

  • 329171 "XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171).

  • 895407 "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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


Cannot connect to the routing master on port 25
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-24

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchRoutingMasterDN attribute of each routing group in the current administrative group. The Exchange Server Analyzer then tries to open a socket connection to the routing master on TCP port 25. If the Exchange Server Analyzer does not receive an expected custom response of 25 Available, an error is displayed.

This error indicates that the routing master is not accessible on TCP port 25, and that routing failures may occur as a result. To correct this error, you can troubleshoot the connectivity problem with the routing master, or assign a new routing master.

To troubleshoot the connectivity problem with the routing master

  1. Can you telnet to port 25 from the routing master itself? If not, the problem is not with the network.

  2. Is everything plugged in? Is all your hardware functioning correctly?

  3. Is DNS working and configured correctly?

  4. Is your router functioning correctly?

  5. Are there any firewalls or applications preventing you from connecting?
To assign a new routing master

  1. Open Exchange System Manager

  2. Right-click the Organization Name (Exchange) icon at the top of the tree in the left pane (where Organization Name is the name that you selected for your Exchange 2000 organization), and then click Properties.

  3. Click Display administrative groups , click Display routing groups , and then click OK.

  4. Expand Administrative Groups, expand <AdministrativeGroup>, and then expand Routing Groups.

  5. Expand the routing group, and then click Members.

  6. In the right pane, right-click the Exchange computer that you want to configure as the routing group master, and then click Set as Master.

For more information about troubleshooting routing, configuring routing topologies, and advanced routing concepts, see "Troubleshooting Routing" in the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Cannot connect to the routing master on port 691
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-24

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchRoutingMasterDN attribute of each routing group in the current administrative group. The Exchange Server Analyzer then tries to open a socket connection to the routing master on TCP port 691. If the Exchange Server Analyzer does not receive an expected custom response of 691 Available, an error is displayed.

This error indicates that the routing master is not accessible on TCP port 691, and that routing failures may occur as a result. To correct this error, you can troubleshoot the connectivity problem with the routing master, or assign a new routing master.

To troubleshoot the connectivity problem with the routing master

  1. Can you telnet to port 691 from the routing master itself? If not, the problem is not with the network.

  2. Is everything plugged in? Is all your hardware functioning correctly?

  3. Is DNS working and configured correctly?

  4. Is your router functioning correctly?

  5. Are there any firewalls preventing you from connecting?
To assign a new routing master

  1. Open Exchange System Manager

  2. Right-click the Organization Name (Exchange) icon at the top of the tree in the left pane (where Organization Name is the name that you selected for your Exchange 2000 organization), and then click Properties.

  3. Click Display administrative groups , click Display routing groups , and then click OK.

  4. Expand Administrative Groups, expand <AdministrativeGroup>, and then expand Routing Groups.

  5. Expand the routing group, and then click Members.

  6. In the right pane, right-click the Exchange computer that you want to configure as the routing group master, and then click Set as Master.

For more information about troubleshooting routing, configuring routing topologies and advanced routing concepts, see "Troubleshooting Routing" in the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Cannot Find 'Host' or 'MX' Records
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-05-10

The Microsoft Exchange Analyzer Tool performs a Domain Name System (DNS) lookup to retrieve the Mail Exchanger (MX) records for a domain. If the Exchange Analyzer cannot retrieve MX records for a domain from the DNS server, the Exchange Analyzer then tries a DNS lookup to retrieve the Host (A) records of the domains that the Exchange server is trying to send messages to.

The Exchange Analyzer displays an error if the following conditions are true:

  • Exchange Analyzer cannot retrieve MX records for a domain.

  • The DNS lookup operation fails to return an IP address for any one of the Host (A) records.

This error indicates that the DNS Mail Exchanger (MX) and Host (A) records appear to be missing for the domain and servers. This error may cause messages destined for remote domains to back up in the Exchange server Remote Delivery queues in addition to other routing or service delays.

To determine mail hosts, the sending Exchange server checks for an MX record. Next, the sending server resolves the MX record to an IP address by checking for an address record (A record).

The DNS lookup of the Mail Exchanger (MX) and Host (A) records can fail for the following reasons:

  • The DNS server is down or unreachable because of a network failure or other reasons.

  • The Host (A) record for the remote server is missing from the DNS server because the record is unavailable or incorrect.

  • The DNS server is not configured to allow dynamic host record updates.

  • The system is trying to send non-delivery reports (NDRs) in response to spam messages that may disguise their originating domains. If this is the case, you should delete those messages. See the link for the Exchange Server Badmail Deletion and Archiving tool in the For More Information section of this article.

To verify that the DNS server is online and that the MX and Host records are present

  1. Verify that the DNS server is running by doing one or more of the following checks:

    • Look at the DNS server status from the DNS Administration program on the DNS server.

    • Restart the DNS server. For more information, see "Start, stop, pause, or restart a DNS server" (http://go.microsoft.com/fwlink/?LinkId=62999).

    • Verify the DNS server responsiveness by using the nslookup command. For more information, see the instructions in "Verify DNS server responsiveness using the nslookup command" (http://go.microsoft.com/fwlink/?LinkId=63000).

  2. Use nslookup to verify that the Mail Exchanger (MX) records are configured correctly. For more information, see "How to Use Nslookup to Verify MX record configuration" in the "Verifying DNS Design and Configuration" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  3. Use nslookup to verify that the Host (A) record exists on the DNS server. For more information, see "To verify A resource records exist in DNS" (http://go.microsoft.com/fwlink/?LinkId=63001).

  4. If the Host (A) resource record does not exist, manually add or modify the A resource record or configure the DNS server to enable dynamic record updates:

    • Manually add an A resource record. For more information, see "Add a resource record to a DNS zone" (http://go.microsoft.com/fwlink/?LinkId=63002).

    • Manually modify an A resource record. See the instructions in "Modify an existing resource record" (http://go.microsoft.com/fwlink/?LinkId=63014).

    • Configure the DNS server to enable dynamic host record updates. For more information, see Microsoft Knowledge Base article 816592, "How to configure DNS dynamic updates in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592).

For More Information

  • For information about how Exchange Server 2003 uses DNS to resolve external IP addresses, see "Transport Dependencies for Exchange Server 2003" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • For information about DNS name resolution, see Microsoft Knowledge Base article 322856, "How to configure DNS to use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856).

  • For information about how to troubleshoot DNS, see "Troubleshooting DNS" (http://go.microsoft.com/fwlink/?LinkId=63003).

  • For information about Exchange Server 2003 system monitoring, see "System Monitoring with Exchange Management Pack" in Exchange Server 2003 Management Pack for MOM 2005 (http://go.microsoft.com/fwlink/?LinkId=47573).

  • For information about Host (A) resource records, see "Managing Resource Records" (http://go.microsoft.com/fwlink/?LinkId=63004).

  • For information about Exchange Server Badmail Deletion and Archiving, see " Exchange Server Badmail Deletion and Archiving" (http://go.microsoft.com/fwlink/?LinkId=84239).


Cannot identify the sender
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-08

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service proxyAddress attribute value for all user objects to determine whether there is a match for the user specified local sender Simple Mail Transfer Protocol (SMTP) address.

If the Exchange Server Analyzer cannot find a proxyAddress match for the user-specified local sender SMTP address, the Exchange Server Analyzer displays an error.

This error indicates that one of the following conditions is true:

  • The local sender does not exist in the local Exchange Server organization.

  • The user-specified local sender SMTP address was incorrectly entered.

To resolve this error, verify the specified local sender's SMTP address and try the operation again.

To verify the local sender's address

  1. Start Exchange System Manager.

  2. Expand Recipients, and then All Global Address Lists.

  3. Right-click Default Global Address List and select Properties.

  4. Click Preview to display the SMTP addresses of recipients included in the Default Global Address List.

  5. Verify that the specified local sender is displayed and note the SMTP address.


CatDbgSink Event Sink Installed
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the data found in the LM/SmtpSvc/%SMTPINSTANCE%/EventManager/EventTypes property in the Internet Information Services (IIS) metabase to determine whether the CatDbgSink mail flow diagnostic application is installed on a computer that is running Exchange 2000 Server or Exchange Server 2003.

The CatDbgSink application is an event sink that can be used for troubleshooting mail flow problems on computers that are running Exchange 2000 Server or Exchange Server 2003. If the CatDbgSink application is installed on the Exchange server, the Exchange Server Analyzer displays a warning stating that the CatDbgSink application is installed and should be used only when you troubleshoot mail flow problems.

The CatDbgSink application is generally sent to customers for troubleshooting mail flow issues on both Exchange 2000 Server and Exchange Server 2003 computers. The CatDbgSink application is generally installed with the guidance of Microsoft Product Support Services (PSS). After the CatDbgSink application is installed and successfully registered, customers can use the CatDbgSink application to create log files to collect troubleshooting information about mail flow problems on an Exchange server.

Sometimes the CatDbgSink application cannot be removed from the production Exchange server after you have isolated and fixed a problem or problems. If the CatDbgSink application is not removed from the Exchange computer, the CatDbgSink application creates a significant load that causes unwanted performance issues on the Exchange server. After you have diagnosed mail flow issues on a production Exchange server, you must remove the CatDbgSink application.

To correct this warning

  1. Locate the local CatDbgSink installation folder. This folder contains the following setup files: Setup.vbs, CatDbgSink.dll, CatDbgSink.pdb and MustReadMe.txt.

  2. From a Command Prompt window, change the directory to the local drive location of the setup files, for example: C:\CatDbgSink.

  3. At the command prompt, type cscript setup.vbs uninstall 1

Note:
The number 1 in the command line designates the SMTP virtual server instance, starting at 1.

For more information about the CatDbgSink application, contact Microsoft Product Support Services (http://support.microsoft.com/default.aspx?pr=cntactms).


Categorizer is disabled for SMTP instance
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the data found in the LM/SmtpSvc/%SMTPInstance%/RoutingSources property in the Internet Information Services (IIS) metabase to determine the Message Categorizer state for each SMTP virtual server instance (VSI) on computers that are running Exchange 2000 Server or Exchange Server 2003.

The Exchange Server Analyzer determines whether the SMTPDSUseCat key exists in the IIS metabase and then reports the findings. If the Exchange Server Analyzer finds that the SMTPDSUseCat exists and is set to disabled, 0X000000, the Exchange Server Analyzer displays an error. If the Message Categorizer is disabled, the Exchange server experiences severe mail flow issues.

By default, when the SMTP service is installed on a computer that is running Microsoft Windows®°2000 Server or Microsoft Windows Server™ 2003, the SMTPDSUseCat key is created in the IIS metabase. By default, the SMTPDSUseCat key is disabled (0). When Exchange Server is installed, the SMTPDSUseCat IIS metabase key is removed. This enables the Message Categorizer. When the SMTP service or Exchange Server is installed on a computer that is running Windows 2000 Server or Windows Server 2003, a default (1) STMP VSI is created. The Message Categorizer may become disabled in situations in which Exchange Server is installed and the SMTP service uninstalled and then re-installed on the computer. The Message Categorizer may also be disabled when third party software is installed or an administrative configuration error occurs.

Note:
Each SMTP virtual server instance on the Exchange server has independent control of the Message Categorizer state.

The Message Categorizer examines every message that come into each SMTP VSI and determines the options. The messages may be destined for the local store, a remote host through the message transfer agent (MTA), or a remote host by through SMTP. The Message Categorizer also handles Distribution List (DL) expansion. The Message Categorizer examines messages that come to an SMTP server and determines what to do with the messages. The Message Categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The Message Categorizer is essentially a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine.

Note:
The SMTP Reinstall Tool (Smtpreinstall.exe) is located on the Exchange 2000 Server SP2 CD-ROM in the \SUPPORT\UTILS\I386 folder.
To enable the Message Categorizer by using the SMTP Reinstall Tool

  1. Copy Smtpreinstall.exe to the \Exchsrvr\Bin folder.

  2. Double-click Smtpreinstall.exe from the \Exchsrvr\Bin folder.

  3. Click OK in the Microsoft Exchange SMTP Reinstall dialog box to restart the Exchange server.

If you have to view the properties in the IIS metabase, you can do so by installing the Metaedit 2.2 utility for IIS 4.0/5.0 or the IIS Metabase Explorer utility on IIS 6.0.

Caution:
Directly editing the metabase is not a recommended practice.

For more information about the message categorizer or available IIS metabase utilities, see the following Microsoft Knowledge Base articles:

  • 290290, "XIMS: Cannot Send Mail After Re-Installing the IIS SMTP Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=290290)

  • 319885, " XCON: Messages Sent in the Exchange 2000 Server Organization Are Not Delivered" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319885)

  • 231729, "XCON: DSUseCat Key and the Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231729)

  • 232068, "How To: Download, Install, and Remove the IIS MetaEdit 2.2 Utility" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=232068)

To download IIS 6.0 Resource Kit Tools, see Internet Information Services (IIS) 6.0 Resource Kit Tools (http://go.microsoft.com/fwlink/?LinkId=33134)


A categorizer warning event (ID: 6004) was logged within the last 24 hours
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-05

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) class to determine whether an Event 6004 warning has been logged for MSExchangeTransport within the last 24 hours.

If the Exchange Server Analyzer finds that an Event 6004 warning has been logged for MSExchangeTransport within the last 24 hours, the Exchange Server Analyzer displays a warning.

This warning indicates that the categorizer encountered an error when it tried to process a message.

The message categorizer examines messages that come to a Simple Mail Transfer Protocol (SMTP) server and determines what to do with the messages. The messages may be destined for the local information store, for a remote host by using the message transfer agent (MTA), or for a remote host by using SMTP. The categorizer also handles distribution list expansion. The categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The categorizer is basically a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine. The categorizer performs address resolution and mail forwarding, sets content conversion flags, expands distribution lists, enforces global settings, and generates delivery status notifications. The categorizer also detects alternative recipient routes and performs bifurcation, journaling, and many other functions.

As soon as a message enters the message categorizer, the categorizer resolves the envelope sender by searching for the address in the proxy address attributes in the Active Directory® directory service. The categorizer also resolves the envelope recipient by searching for each address in the proxy addresses attribute in Active Directory. For example, if the list includes a distribution list, it expands the list to include those members if distribution list expansion is allowed on the server.

Possible causes of MSExchangeTransport Warning event 6004 include the following:

  • Directory Service Access (DSAccess) problems.

  • Directory replication latency or failures.

  • Overloaded global catalog servers

  • DNS problems.

To address this warning:

  • Verify that Exchange Server has connectivity to one or more global catalog servers. The Network Monitor tool in Windows is very useful for this.

  • Examine any delivery status notification (DSN) messages that are generated. DSNs can include non-delivery reports (NDRs). DSNs describe permanent failure messages and transient failure messages that frequently end as permanent delivery errors.

  • Use Message Tracking to troubleshoot messages that are stuck in the categorizer.

  • Use the Archive Sink tool to archive and analyze messages that enter and exit Exchange Server.

  • Monitor the categorizer performance counters by using System Monitor.

For more information about Exchange Server 2003 events and errors, see the "Events and Errors Message Center" (http://go.microsoft.com/fwlink/?LinkId=34258).

For a listing of the DSNs and NDRs generated by Exchange Server and Microsoft Windows Small Business Server, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

For information about how to use the Message Tracking Center in Exchange Server, see the following Microsoft Knowledge Base articles:

  • 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162).

  • 246856, "XADM: How to Enable Message Tracking in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856).

  • 821905, "Message Tracking Event IDs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905).

  • 823864, "Improved Message Tracking Features in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864).

For more information about how to troubleshoot message categorizer issues, see the Microsoft Support WebCast, "Exchange 2000 Server: Message Categorizer and NDR Troubleshooting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137).

For more information about the Archive Sink tool, see Microsoft Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798).

For general information about how to troubleshoot transport-related problems, see the following Microsoft Knowledge Base articles and resources:

  • 821910, "How To Troubleshoot for Exchange Server 2003 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910).

  • 257265, "General troubleshooting for transport issues in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265).

  • 895853, "How to troubleshoot mail relay issues in Exchange Server 2003 and in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853).

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server and Transport Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the message categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).


A categorizer warning event (ID: 6006) was logged within the last 24 hours
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) class to determine whether an Event 6006 warning has been logged for MSExchangeTransport within the last 24 hours.

If the Exchange Server Analyzer finds that an Event 6006 warning has been logged for MSExchangeTransport within the last 24 hours, the Exchange Server Analyzer displays a warning.

This warning indicates that messages are being trapped in the message categorizer.

The message categorizer examines messages that come to a Simple Mail Transfer Protocol (SMTP) server and determines what to do with the messages. The messages may be destined for the local information store, for a remote host by using the message transfer agent (MTA), or for a remote host by using SMTP. The categorizer also handles distribution list expansion. The categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The categorizer is basically a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine. The categorizer performs address resolution and mail forwarding, sets content conversion flags, expands distribution lists, enforces global settings, and generates delivery status notifications. The categorizer also detects alternative recipient routes and performs bifurcation, journaling, and many other functions.

As soon as a message enters the message categorizer, the categorizer resolves the envelope sender by searching for the address in the proxy address attributes in the Active Directory® directory service. The categorizer also resolves the envelope recipient by searching for each address in the proxy addresses attribute in Active Directory. For example, if the list includes a distribution list, it expands the list to include those members if distribution list expansion is allowed on the server.

Possible causes of MSExchangeTransport Warning event 6006 include the following:

  • Outdated or incorrectly configured antivirus software.

  • Much distribution group expansion.

  • Incorrectly configured journaling recipients.

  • Incorrectly configured permissions for Exchange objects in Active Directory.

To address this warning:

  • Make sure that you have correctly configured your file-level antivirus application to exclude specific Exchange Server directories. For a description of the folders that you should not include when you scan servers that are running Microsoft Exchange Server, see Microsoft Knowledge Base article 823166, "Overview of Exchange Server 2003 and antivirus software" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166).

  • Make sure that you are running the most current version of your antivirus application software.

  • Examine distribution group delivery restrictions settings and remove unnecessary restrictions.

  • Examine Journaling settings for possible incorrect configuration.

  • Examine Exchange objects in Active Directory for improperly configured permissions.

For More Information

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking.

For more information about the effect of distribution group restriction on Exchange Server mail flow, see the following Microsoft Knowledge Base articles:

  • 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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

  • 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

For more information about how to deploy a journaling solution, see "Journaling with Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47581).

For more information about the possible cause of categorizer Warning event ID 6006, see Microsoft Knowledge Base article 922256, "E-mail messages become stuck in the "Awaiting directory lookup" queue in an Exchange Server 2003 organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=922256).

For more information about Exchange Server 2003 events and errors, see the "Events and Errors Message Center" (http://go.microsoft.com/fwlink/?LinkId=34258).

For a listing of the DSNs and NDRs generated by Exchange Server and Microsoft Windows Small Business Server, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

For more information about how to troubleshoot message categorizer issues, see the Microsoft Support WebCast, "Exchange 2000 Server: Message Categorizer and NDR Troubleshooting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137).

For general information about how to troubleshoot transport-related problems, see the following Microsoft Knowledge Base articles and resources:

  • 821910, "How to Troubleshoot for Exchange Server 2003 transport issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910).

  • 257265, "General troubleshooting for transport issues in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265).

  • 895853, "How to troubleshoot mail relay issues in Exchange Server 2003 and in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853).

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server and Transport Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the message categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).


A categorizer warning event (ID: 6008) was logged within the last 24 hours
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) class to determine whether an Event 6008 warning has been logged for MSExchangeTransport within the last 24 hours.

If the Exchange Server Analyzer finds that an Event 6008 warning has been logged for MSExchangeTransport within the last 24 hours, the Exchange Server Analyzer displays a warning.

This warning indicates that the categorizer encountered an error when it tried to process a message.

The message categorizer examines messages that come to a Simple Mail Transfer Protocol (SMTP) server and determines what to do with the messages. The messages may be destined for the local information store, for a remote host by using the message transfer agent (MTA), or for a remote host by using SMTP. The categorizer also handles distribution list expansion. The categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The categorizer is basically a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine. The categorizer performs address resolution and mail forwarding, sets content conversion flags, expands distribution lists, enforces global settings, and generates delivery status notifications. The categorizer also detects alternative recipient routes and performs bifurcation, journaling, and many other functions.

As soon as a message enters the message categorizer, the categorizer resolves the envelope sender by searching for the address in the proxy address attributes in the Active Directory® directory service. The categorizer also resolves the envelope recipient by searching for each address in the proxy addresses attribute in Active Directory. For example, if the list includes a distribution list, it expands the list to include those members if distribution list expansion is allowed on the server.

Possible causes of MSExchangeTransport Warning event 6008 include the following:

  • Directory Service Access (DSAccess) problems.

  • Directory replication latency or failures.

  • Overloaded global catalog servers.

  • DNS problems.

  • Excessive distribution group expansion.

To address this warning:

  • Verify that the Exchange Server has connectivity to one or more global catalog servers. The Network Monitor tool in Windows is very useful for this.

  • Examine any delivery status notification (DSN) messages that are being generated. DSNs can include non-delivery reports (NDRs). DSNs describe permanent failure messages and transient failure messages that frequently end as permanent delivery errors.

  • Use Message Tracking to troubleshoot messages that are stuck in the categorizer.

  • Use the Archive Sink tool to archive and analyze messages that enter and exit Exchange Server.

  • Monitor the categorizer performance counters by using System Monitor.

  • Examine distribution group delivery restrictions settings and remove unnecessary restrictions.

For more information about Exchange Server 2003 events and errors, see the "Events and Errors Message Center" (http://go.microsoft.com/fwlink/?LinkId=34258).

For a listing of the DSNs and NDRs generated by Exchange Server and Microsoft Windows Small Business Server, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

For information about how to use the Message Tracking Center in Exchange Server, see the following Microsoft Knowledge Base articles:

  • 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162).

  • 246856, "XADM: How to Enable Message Tracking in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856).

  • 821905, "Message Tracking Event IDs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905).

  • 823864, "Improved Message Tracking Features in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864).

For more information about how to troubleshoot message categorizer issues, see the Microsoft Support WebCast, "Exchange 2000 Server: Message Categorizer and NDR Troubleshooting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137).

For more information about the Archive Sink tool, see Microsoft Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798).

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking.

For more information about the effect of distribution group restriction on Exchange Server mail flow, see the following Microsoft Knowledge Base articles:

  • 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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

  • 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

For general information about how to troubleshoot transport-related problems, see the following Microsoft Knowledge Base articles and resources:

  • 821910, "How To Troubleshoot for Exchange Server 2003 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910).

  • 257265, "General troubleshooting for transport issues in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265).

  • 895853, "How to troubleshoot mail relay issues in Exchange Server 2003 and in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853).

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server and Transport Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the message categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).


Connection Filtering is Enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchServerBindingsFiltering property of a Simple Mail Transfer Protocol (SMTP) virtual server object indicates that Connection Filtering is enabled for a SMTP virtual server instance.

The Exchange Server Analyzer also queries Active Directory to determine whether the msExchSmtpConnectionRulesPriority, the msExchSMTPGlobalIPAcceptList, or the msExchSMTPGlobalIPDenyList properties indicate that Connection Filtering is also enabled at the global settings level.

The Exchange Server Analyzer displays a warning message if the following conditions exist:

  • Connection Filtering is enabled at the SMTP virtual server instance.

  • Connection Filtering is enabled at the Global Settings level.

This warning indicates that Connection Filtering is effectively enabled. Connection Filtering is generally not an issue. However, if you are troubleshooting mail flow problems involving this particular server, you may want to verify the filter configuration or temporarily disable Connection Filtering to determine whether it is incorrectly blocking mail to valid recipients.

To disable a connection filter on an SMTP virtual server

  1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In the console tree, expand Servers, expand the server that you want, expand Protocols, and then expand SMTP.

  3. Right-click the SMTP virtual server on which you want to disable the filter, and then click Properties.

  4. In <SMTP Virtual Server> Properties, on the General tab, click Advanced.

  5. In Advanced, select the IP address for which you want to disable the filter, and then click Edit.

  6. In Identification, clear the Apply Connection Filter check box to disable the filter.

  7. If you have multiple virtual servers, repeat Steps 3 through 6 for each virtual server on which you want to disable the filter.

For more information about how to configure connection filters, see Microsoft Knowledge Base article 823866 "How to configure connection filtering to use Realtime Block Lists (RBLs) and how to configure recipient filtering in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823866).

For more information about intelligent message filtering, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).


Connector has accept restrictions set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the dLMemDefault attribute for each SMTP connector in the routing group. The Exchange Server Analyzer also queries Active Directory to determine the value for the authOrig and unauthOrig attributes of each connector. The unauthOrig and authOrig attributes contain lists of distinguished names (DNs) of accounts.

By default, all SMTP connectors allow all users to send messages through the connector. When dLMemDefault is set to the default setting of 1, messages from everyone are accepted except from those accounts listed in the unauthOrig attribute. When dLMemDefault is set to 0, messages from everyone are rejected except from those accounts listed in the authOrig attribute.

The Exchange Server Analyzer displays a non-default configuration message if the following conditions exist:

  • The value for the dLMemDefault attribute set to 0.

  • The authOrig attribute contains values.

The connector that is specified by the Exchange Server Analyzer is configured to only accept some messages. Only those accounts that have been granted explicit permissions on the Delivery Restrictions tab of the connector will be allowed to send messages through the connector.

The Exchange Server Analyzer displays the non-default configuration message for informational purposes only.

For more information about connectors, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Connector has reject restrictions set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the dLMemDefault attribute for each SMTP connector in the routing group. The Exchange Server Analyzer also queries Active Directory to determine the value for the authOrig and unauthOrig attributes of each connector. The unauthOrig and authOrig attributes contain lists of distinguished names (DNs) of accounts.

By default, all SMTP connectors allow all users to send messages through the connector. When dLMemDefault is set to the default setting of 1, messages from everyone are accepted except from those accounts listed in the unauthOrig attribute. When dLMemDefault is set to 0, messages from everyone are rejected except from those accounts listed in the authOrig attribute.

The Exchange Server Analyzer displays a non-default configuration message if the following conditions exist:

  • The value for the dLMemDefault attribute set to 1.

  • The unauthOrig attribute contains values.

The connector that is specified by the Exchange Server Analyzer is configured to reject some messages. The accounts that have explicitly been denied permissions on the Delivery Restrictions tab of the connector will not be allowed to send messages through the connector.

The Exchange Server Analyzer displays the non-default configuration message for informational purposes only.

For more information about connectors, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Connector rejects all messages by default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the dLMemDefault attribute of each connector. The dLMemDefault attribute controls whether messages are accepted or rejected by default.

A value of 0 for the dLMemDefault attribute indicates that messages are rejected by default. A value of 1 for the dLMemDefault attribute indicates that messages are accepted by default. If the Exchange Server Analyzer finds the value for the dLMemDefault attribute is 0, the Exchange Server Analyzer displays a non-default configuration message.

The connector that is specified by the Exchange Server Analyzer is configured to reject all messages by default. Only those accounts that have been granted explicit permissions on the Delivery Restrictions tab of the connector are allowed to send messages through the connector.

The Exchange Server Analyzer displays the non-default configuration message for informational purposes only.

For more information about connectors, see the Exchange Server 2003 Transport and Routing Guide at http://go.microsoft.com/fwlink/?LinkId=47579.


Connector restriction checking is enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry branch to determine if the CheckConnectorRestrictions registry value is present and configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Resvc\Parameters

If the Exchange Server Analyzer finds the value for CheckConnectorRestrictions present and set to 1, a warning is displayed.

If you need to apply a distribution list-based restriction to a connector, you must manually enable the checking process for these restrictions. Restriction checking is controlled by the CheckConnectorRestrictions registry value that must be set on the Exchange bridgehead server that is the source for the connector that is being checked. If you specify a restriction, but do not create the CheckConnectorRestrictions registry value, the restriction is not checked.

Connector restriction checking is turned off by default because expanding distribution groups and checking the restrictions for each message that passes through the system can significantly impact performance. If possible, enable this setting only where it is necessary (for example, on the bridgehead server for the restricted connector).

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To disable connector restriction checking

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\Resvc\Parameters

  3. In the right-hand pane, locate CheckConnectorRestrictions and delete it.

  4. Close the registry editor and restart the Microsoft Exchange Routing Engine service and the Simple Mail Transfer Protocol (SMTP) service for the change to take effect.

For more information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the connector restriction checking registry value, see Microsoft Knowledge Base article 277872, "XCON: Connector Delivery Restrictions May Not Work Correctly" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872).


Connector is scoped for local routing
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-04-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchRoutingSMTPConnector attribute of each SMTP connector. If the Exchange Server Analyzer finds that the value for the msExchRoutingSMTPConnector attribute includes the string "Local:", the Exchange Server Analyzer displays a non-default configuration message. The presence of the string "Local:" indicates that the SMTP connector is scoped for local routing.

An SMTP connector designates an isolated route for mail. You can use SMTP connectors to establish a gateway for Internet mail or to connect to a specific domain or mail system. Connectors let you define specific options for the designated mail route.

Although you can send and receive Internet mail by using an SMTP virtual server, many organizations configure a dedicated SMTP connector for routing Internet mail. Use of an SMTP connector is recommended because it provides an isolated route for mail that is destined to the Internet. Additionally, more configuration options are available on an SMTP connector than on the SMTP virtual server.

The Exchange Server Analyzer displays the non-default configuration message for informational purposes only.

For more information about SMTP connectors, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Consider non-hierarchical restriction checking
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the serialNumber attribute for each Exchange Server object in the directory. If the Exchange Server Analyzer finds that the value for the serialNumber attribute for an Exchange Server 2003 server object contains Service Pack 2 in its string value, the Exchange Server Analyzer then reads the following registry key to determine whether the CheckConnectorRestrictions registry value is present and configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Resvc\Parameters

This condition indicates that the server checks sending and receiving restrictions before letting a message to be processed.

If the Exchange Server Analyzer finds that the value for CheckConnectorRestrictions is present, set to 1, and therefore enabled, the Exchange Server Analyzer also reads the HKLM\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod registry key to determine whether the RestrictionMethod registry value is present and how it is configured.

If the Exchange Server Analyzer finds that the RestrictionMethod registry value is missing or set to a value other than 2, the Exchange Server Analyzer displays a best practice message.

In summary, the Exchange Server Analyzer displays a best practice message if the following conditions are true:

  • The Exchange Server 2003 server has SP2 installed.

  • The CheckConnectorRestrictions registry value from HKLM\System\CurrentControlSet\Services\Resvc\Parameters is configured to use a distribution list-based restriction to a connector on the local computer.

  • The RestrictionMethod registry value from HKLM\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod is missing or set to a value other than 2.

The RestrictionMethod value determines how the categorizer will process restrictions. The default behavior for the categorizer is to recursively expand distribution groups and check restrictions for each message that passes through the system. This default categorizer behavior can significantly affect performance and is not a best practice.

If you set the value of RestrictionMethod to 2, the transport components on this Exchange server will not expand membership of distribution groups when the server checks restrictions. This configuration provides the best performance for restriction checks. Additionally, for the RestrictionMethod registry entry to take effect, all distribution groups that include users who have delivery restrictions must be flat. That is, the restricted distribution groups must not have nested distribution groups. The expansion logic will not work if the restricted distribution groups are nested.

For distribution groups that are used in connector restrictions, it is recommended that you set the RestrictionMethod registry entry value on a connector bridgehead server that has no mailboxes. For Active Directory user restrictions, if the restricted distribution groups have expansion servers, we recommend that you create the RestrictionMethod registry entry on the expansion servers.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To create the RestrictionMethod registry entry and set its value of 2

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters

  3. In the left pane, click Parameters.

  4. On the Edit menu, point to New, and then click DWORD Value.

  5. Type RestrictionMethod, and then press ENTER to name the new registry entry.

  6. Right-click RestrictionMethod, and then click Modify.

  7. Type 2, and then press ENTER.

  8. Quit Registry Editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the RestrictionMethod registry value, see Microsoft Knowledge Base article 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

For more information about the registry value, see Microsoft Knowledge Base article 277872, "XCON: Connector Delivery Restrictions May Not Work Correctly" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872).


ConvertDSNInternetContent registry key is configured to perform content conversion of all messages
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the ConvertDSNInternetContent registry value has been configured to perform content conversion for all messages that are received by the Exchange Information Store on the Exchange Server 2003 computer:

HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The ConvertDSNInternetContent registry value was manually created.

  • The ConvertDSNInternetContent registry value data is set to 1.

A value data of 0 or no value on the ConvertDSNInternetContent registry value disables content conversion of SMTP messages by the Exchange Information Store. A value data of 1 enables content conversion of all messages including SMTP messages on all SMTP Virtual Server Instances (VSIs) or to individual VSIs.

By default, the ConvertDSNInternetContent registry value is not created during an Exchange Server 2003 installation. The ConvertDSNInternetContent registry value can be manually created after the Exchange Server Server installation to change the behavior of content conversion on the Exchange Server 2003 computer. Generally, submitted SMTP messages must not undergo content conversion. If you enable content conversion for all messages including SMTP messages, you add processing overhead on the Exchange server. This additional processing overhead may cause performance and log file storage problems.

The Exchange Server Analyzer reports this configuration for informational purposes only. You must edit the registry to return the content conversion behavior on Exchange Server 2003 computer to the most efficient method of content conversion.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to the following registry key: HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters

  3. In the details pane, right-click the ConvertDSNInternetContent registry value, click Modify, and then change the Value data to 80. Click OK.

    Note:
    To delete the ConvertDSNInternetContent registry value, in the details pane, right-click the ConvertDSNInternetContent registry value and then click Delete. Confirm deletion of the registry value by clicking Yes in the dialog box.

  4. Close the registry editor.

  5. Restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about editing the Microsoft Windows registry see the following Microsoft Knowledge Base articles:

  • 322755, "How to back up, edit, and restore the registry in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755 )

  • 322756, "How to back up, edit, and restore the registry in Windows XP and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


Distribution group identified as a common destination
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-04

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_Queue Windows® Management Instrumentation (WMI) class to determine the values of the following attributes for the Simple Mail Transfer Protocol (SMTP) queues of the SMTP virtual server.

LinkId | Indicates the identifier for the link that contains the queue.
QueueId | Indicates the identifier of the queue.
QueueName | Indicates the name of the queue.
VirtualMachine | Indicates the name of the virtual machine that contains the queue.
VirtualServerName | Indicates the name of the virtual server that the queue is on.
MessageCount | Indicates the number of messages in the queue.

The Exchange Server Analyzer uses the information obtained here to query the Exchange_QueuedSMTPMessage WMI class for the values of the following attributes of the messages in the queue:

Recipients | Indicates the recipients of the message.
Received | Indicates the received time stamp for the message.
MessageId | Indicates the identifier of the queued message.
StateRetry | Indicates that transmission is retried for a message that was not delivered successfully.

Finally, the Exchange Server Analyzer uses the data obtained here to query the Active Directory® directory service for the distinguishedName value of each Recipient object. The Exchange Server Analyzer then determines whether the recipient is a user, a distribution group, a public folder, or a public folder store.

If the Exchange Server Analyzer determines that at least 25 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to a specific distribution group, the Exchange Server Analyzer displays a warning.

If the Exchange Server Analyzer determines that at least 50 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to a specific distribution group, the Exchange Server Analyzer displays an error.

This warning or error means that the distribution group identified is a common destination for messages that are stuck in an SMTP queue.

To address this issue, the distribution group should be investigated as follows for configuration issues or other anomalies that could cause messages to queue for it:

  • Make sure that the distribution group object attributes are correctly set and contain the correct values in Active Directory.

  • Review the Active Directory permissions of the distribution group object for the correct settings.

  • If the distribution group contains a special use user object, that is, a designated Journaling recipient, review the configurations of the service or components that the user object is related to for the correct configuration.

  • Look for possible unsolicited commercial e-mail (UCE), or spam, or virus attacks against the distribution group.

  • Determine whether the distribution group's delivery restrictions are incorrectly set.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

For more information about the effect of distribution group restriction on Exchange Server mail flow, see the following Microsoft Knowledge Base articles:

  • 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)

  • 329171 "XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171).

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

  • 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).


Earlier categorizations failed with a retryable error
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Cat: Categorizations in progress and the Categorizer Queue length performance counters of the SMTP Server performance object to analyze performance data.

The Cat: Categorizations in progress performance counter shows the number of categorizations in progress whereas the Categorizer Queue length performance counter shows the number of messages in the categorizer queue.

For this query, the Exchange Server Analyzer retrieves a sample every 6 seconds for a two-minute period. The Exchange Server Analyzer reports the average value for the performance counter during the collection interval.

The Exchange Server Analyzer examines the average number of categorizations in progress and compares that number against the number of categorizations still in the queue.

The Exchange Server Analyzer displays an error if, over the sample period, the following conditions are true:

  • The average number of categorizations in progress is zero.

  • The average categorizer queue length is more than zero.

The categorizer performs the following core operations:

  • Resolves and validates all recipients.

  • Determines limits and restrictions for all recipients.

  • Expands distribution lists if that is required.

  • Determines whether the message is for local or remote delivery.

This error indicates that there are messages stuck in the categorizer queue that have failed categorization with a retryable error.

Generally, messages accumulate in queues because the advanced queuing engine is unable to categorize the message. The advanced queuing engine may be unable to access the global catalog servers and access recipient information. Alternatively, the global catalog servers may be unreachable or performing slowly. In addition, messages can accumulate for the following reasons:

  • The Active Directory® directory service is unavailable.

    Note:
    The categorizer uses Active Directory to categorize messages.
  • Active Directory may be too heavily loaded if many messages have queued in the pre-categorization queue.

  • There is a failure in conversion. The categorizer also handles content conversion.

  • The message categorizer cannot find the mailbox stores.

  • If Simple Mail Transfer Protocol (SMTP) was reinstalled or removed, this may invalidate the following IIS metabase keys: /smtpsvc/DsUseCat and /smtpsvc/vsi#/DsUseCat.

    Note:
    Determine whether SMTP was reinstalled or removed.

You can examine the properties of the queue to determine the cause of the failure. For example, if the queue properties display a message that resembles "An SMTP error has occurred," you should review your server's event logs to locate any SMTP errors. If there are no events in the log, you should increase the SMTP logging level.

For more information about how to troubleshoot Exchange and SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).

  • "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

  • "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the Message Categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).


Enable Intelligent Message Filter automatic update
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-02-13

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the serialNumber attribute for all Exchange Server objects in the directory. The serialNumber attribute is a string value that includes both the version of Exchange Server and the version of the service pack, if installed. A value of the serialNumber attribute equal to Version 6.5 (Build 7638: Service Pack 2) indicates that the server is running Exchange Sever 2003, Service Pack 2.

The Exchange Server Analyzer also queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for ClusSvc, the Cluster service. A value of True indicates the Cluster service is running, and a value of False indicates it is not running.

The Exchange Server Analyzer also reads the following registry entry to determine whether Microsoft Exchange Intelligent Message Filter is installed and enabled on the server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter

If the Exchange Server Analyzer finds that the ContentFilterBindings entry in the ContentFilter registry key is present, but the ContentFilterBindings value is not configured, it indicates that the Intelligent Message Filter is not enabled on the server.

Finally, the Exchange Server Analyzer queries the following registry entry to determine whether the ContentFilterState subkey is present and the Intelligent Message Filter automatic update is enabled on the server:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\

A value of anything other than 1 for the ContentFilterState subkey indicates that the automatic update for the Intelligent Message Filter is not enabled.

The Exchange Server Analyzer displays a best practices message if the following conditions are true:

  • The server is running Exchange Server 2003, Service Pack 2

  • The Exchange Server is non-clustered

  • The Intelligent Message Filter is enabled

  • Automatic updates for the Intelligent Message Filter are not enabled.

By default, the Intelligent Message Filter feature is installed with Exchange Server 2003 SP2. You must manually enable the Intelligent Message Filter feature to obtain the benefits of this new message filtering technology. After you enable the Intelligent Message Filter feature, the .dat file and the .dll file must be updated regularly to keep the filter current and effective. The article referenced in the following section describes the update process that keeps the Intelligent Message Filter up-to-date.

For information about how to enable the automatic update for Intelligent Message Filter, see Microsoft Knowledge Base article 907747, "How to update the Intelligent Message Filter version 2 in Exchange Server 2003 SP2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=907747).


Envelope journaling is enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-03-30

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the heuristics attribute has been configured to enable envelope journaling. By default, the heuristics attribute is not configured. If the Exchange Server Analyzer finds that the heuristics attribute is set to 512, the Exchange Server Analyzer displays a non-default configuration message.

Envelope journaling permits you to archive P1 message headers. The P1 message header is the address information that is used by message transfer agents (MTAs) to route mail. This address information includes information about the recipients who actually received the message, including blind carbon copy (Bcc) recipients and recipients from distribution groups. Envelope journaling delivers messages that are flagged to be archived by using an envelope message that contains a journal report and the original message. The original message is delivered as an attachment. The body of the journal report contains the transport envelope data of the archived message.

To enable Bcc journaling on a given server, you must first configure message-only journaling at the database level. The heuristics attribute is not active when the following conditions exist:

  • The heuristics attribute is set to 512.

  • Message-only journaling is not enabled on any of the database stores.

Journaling messages can consume many disk, network, and CPU resources. Therefore, journaling requires thorough deployment planning. Journaling should be enabled only in the context of an overall journaling solution framework.

Ignore this non-default configuration message if the following conditions exist:

  • Your business requires journaling.

  • You have deployed a journaling solution framework.

Otherwise, you should turn off journaling functionality.

To turn off message-only journaling on a database

  1. In Exchange System Manager, expand Servers, expand <your Exchange server>, expand <storage group>, and then right-click the mailbox store.

  2. On the General tab, clear the check box, Archive all messages sent or received by mailboxes on this store.

  3. Wait 15 minutes for the Exchange store to apply changes. You do not have to restart the Microsoft Exchange Information Store service.

If you do not want the Exchange Server Analyzer to display this message again, you must disable the heuristics attribute. Disabling the heuristics attribute is not required to disable journaling functionality.

You can disable envelope journaling by using the E-Mail Journaling Advanced Configuration tool (Exejcfg.exe). You can run the tool from any server with access to Active Directory, but it is recommended that you run the tool from a domain controller.

To obtain the E-Mail Journaling Advanced Configuration tool and the documentation, download the tools package at http://go.microsoft.com/fwlink/?LinkId=33122. The E-Mail Journaling Advanced Configuration tool can be used in Exchange 2000 Server environments and Exchange Server 2003 environments.

To disable the heuristics attribute

  1. Download and unzip the E-Mail Journaling Advanced Configuration tool to a directory of your choice.

  2. Open a command prompt.

  3. Go to the directory where you installed the E-Mail Journaling Advanced Configuration tool.

  4. Type the following command to disable envelope journaling:

    Copy Code
    exejcfg -d

For more information about deploying a journaling solution, see "Journaling with Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47581).


ESMTP Verb Not Supported
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the value for the msExchSmtpInboundCommandSupportOptions attribute for each instance of a Simple Mail Transfer Protocol (SMTP) virtual server is configured to support the default extended SMTP verbs for incoming connections.

These extended SMTP verbs are listed in the table below. If the Exchange Server Analyzer finds that any one of the listed default extended SMTP verbs for incoming connections is not supported, the Exchange Server Analyzer displays a warning.

Exchange Server 2003 uses these Exchange-specific extended SMTP verbs to communicate with other Exchange servers in the organization more efficiently than over standard SMTP. These verbs are controlled in the metabase and in Exchange Server event sinks. In Exchange Server 2003, the DS2MB process is responsible for updating the values in the metabase by copying the values from Active Directory. When you disable the event sinks, you may hinder Exchange Server performance.

Extended SMTP Verb Comments

8BITMIME

Indicates that the local SMTP virtual server supports eight-bit MIME messages.

BDAT, CHUNKING

An alternative to the DATA command. This takes two arguments. When an SMTP virtual server responds to the EHLO keyword with CHUNKING, the SMTP server indicates that it supports the BDAT command and will accept messages in chunks.

  • The first argument indicates the length of the binary data packet. Therefore the SMTP host does not have to continuously scan for the end of the data. The receiving server counts the bytes in the message. When the message size equals the value sent by the BDAT command, the server assumes that it has received all the message data.

  • The second argument indicates whether the data packet is the last packet in the current transmission. The second argument is optional.

BINARYMIME

Indicates that the SMTP virtual server accepts messages that contain binary material without transport encoding by using a BODY parameter with a value of BINARYMIME with the MAIL command. When the SMTP server accepts a MAIL command that has a BODY parameter of BINARYMIME, the server agrees to preserve all bits in each octet passed using the BDAT command. The BINARYMIME SMTP extension can only be used with CHUNKING.

DSN

An ESMTP command that enables delivery status notifications as defined in Request for Comments (RFC) 1891.

ENHANCEDSTATUSCODES

Indicates that the SMTP server provides enhanced error status codes. The text part of all SMTP status responses, other than the initial greeting and any response to HELO or EHLO, is prefaced with a status code as defined in RFC 1893.

ETRN

Sent by an SMTP server to request that the local virtual server send any e-mail messages that it has in the queue for the domains indicated in the ETRN command.

TURN

Allows a remote host and the local host to switch roles and send mail in the reverse direction, without establishing a new connection.

For more information about how to restore the default support for these verbs, see Microsoft Knowledge Base article 257569 "How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257569).


Extended verbs are not being advertised by the Exchange server
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the SmtpInboundCommandSupportOptions property in the Internet Information Services (IIS) metabase to determine whether Exchange Server has been configured to support Extended Verbs. If the Exchange Server Analyzer finds that the SmtpInboundCommandSupportOptions setting is not set to 7697601, a warning is displayed.

Extended SMTP Verbs are required by both Exchange 2000 Server and Exchange Server 2003. The value in the IIS metabase must match the value set in the Active Directory® directory service. If you are running Exchange Server in a mixed-mode environment, this value must be set to 7697601.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To restore the default value of SmtpInboundCommandSupportOptions

  1. Open ADSI Edit and connect to a domain controller.

  2. Open the Configuration Container.

  3. Move to the following location:

    Configuration/Services/Microsoft Exchange/<Your Organization>/Administrative Groups/<Your Administrative Group>/Servers/<Your Exchange Server>/Protocols/SMTP/<Your Virtual Server>.

  4. Right-click the virtual server object, and then click Properties.

  5. For Select a property to view, select msExchSmtpInboundCommandsSupportOptions.

  6. In the Edit Attribute, enter 7697601.

  7. Click Set, then click Apply, and then click OK.

  8. Close ADSI Edit.


Frozen Queues Detected
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-03

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the StateFrozen key for the Simple Mail Transfer Protocol (SMTP) queues on a server.

If the Exchange Server Analyzer finds that the value of the StateFrozen key for any one of the SMTP queues on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

A frozen queue means the transport sessions for that queue are stopped. A frozen queue prevents outgoing messages, although new messages can be added. You can manually change the state of a connection by using the shortcut menu on each link queue. When you use the Force Connection command to change a queue state to Active, you immediately enable a connection that sends the messages from that queue.

For information about the particular SMTP queues that are affected and the possible cause, see the following Exchange Server Analyzer Tool articles:

  • 'Messages awaiting directory lookup' Queue is Frozen

  • 'Messages waiting to be routed' Queue is Frozen

  • 'Messages Pending Submission' Queue is Frozen

  • 'Local Delivery' Queue is Frozen

  • 'Remote Delivery' Queue is Frozen

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579)

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


Filter update for Intelligent Message Filter is available
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine whether the MSExchange.UceContentFilter.dll exists in the following path on the Exchange Server:

<path to Exchange server binary files>\MSCFv2\MSExchange.UceContentFilter.dll

Note:
In this path, <path to Exchange server binary files> refers to the location of the bin folder.

If MSExchange.UceContentFilter.dll does not exist in this location, the Exchange Server Analyzer displays a best practice recommendation.

It is recommended that the filter update for Microsoft Exchange Intelligent Message Filter is installed on all Exchange Servers that have Intelligent Message Filter installed. The filter update for Intelligent Message Filter provides the latest Intelligent Message Filter SmartScreen™ filter update for Intelligent Message Filter. The filter update to the SmartScreen filter contains updated spam characteristics that improve the ability of Intelligent Message Filter to block unsolicited commercial e-mail messages, also known as spam.

Note:
Before you install the update, you must install Intelligent Message Filter. To install Intelligent Message Filter, use an account that has local administrative rights and a member of a group that has had Exchange Administrators role applied.

After you install Intelligent Message Filter, perform the following procedure to install updates.

To obtain and install the Intelligent Message Filter Update

  1. Obtain the latest update for Exchange Intelligent Message Filter at http://go.microsoft.com/fwlink/?LinkId=41026.

  2. Review the release notes for the Intelligent Message Filter update at http://go.microsoft.com/fwlink/?LinkId=41027.

  3. Run the update package and follow the instructions in the update package Setup Wizard.

For more information, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).


Flat restriction checking is enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the serialNumber attribute for each Exchange Server object in the directory. If the string value for the serialNumber attribute of an Exchange Server 2003 server object contains Service Pack 2, it indicates that the Exchange server is running a pre-release version of Exchange Server 2003 Service Pack 2.

The Exchange Server Analyzer also reads the following registry entry to determine whether the RestrictionMethod registry value is present:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod

The Exchange Server Analyzer displays a non-default configuration message if the following conditions are true:

  • The Exchange Server 2003 Service Pack 2 is installed.

  • The RestrictionMethod registry value present and configured to have a value of 2.

This configuration indicates that the transport components on this Exchange server will not expand membership of distribution groups when the server checks restrictions. This configuration provides the best performance for restriction checks.

If you believe the presence of and setting for the RestrictionMethod registry value is in error, you can use the following procedure to revert to the default configuration. However, because the presence of this key in combination with Exchange Server 2003 Service Pack 2 provides the best performance for checking restrictions, it is recommended that you leave the RestrictionMethod registry value at its current setting.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\

  3. In the right pane, right-click RestrictionMethod and select Delete.

  4. Close the registry editor and then restart the IIS Admin and Microsoft Exchange Routing Engine services for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the RestrictionMethod registry value, see Microsoft Knowledge Base article 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).


'Host' Records Found but not 'MX' Records
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Domain Name System (DNS) servers it uses for the mail exchanger (MX) records of remote domains that Exchange sends to. The Exchange Server Analyzer then performs a DNS lookup to retrieve the Host (A) records of the remote domains.

If the Exchange Server Analyzer DNS lookup operation does not return MX records for the remote domains but can subsequently retrieve Host (A) records for the same remote domains, the Exchange Server Analyzer displays a warning.

In this situation, after failing to retrieve the MX records, Exchange Server may try to send mail to the servers that the Host (A) records point to. It very important that those Host (A) records point to the correct mail servers.

Some domains may configure their Host (A) records to point to an Internet Service Provider (ISP) which, although it may have valid mail servers, might not be the authoritative mail server for the intended recipient. In this case the mail will be rejected.

The DNS lookup of the MX records can fail if the DNS server is down or unreachable because of a network failure or for other reasons.

To verify that the DNS server is online and that the MX records are present

  1. Verify that the DNS server is running by doing one or more of the following checks:

    • Look at the DNS server status from the DNS Administration program on the DNS server.

    • Restart the DNS server. For more information, see "Start, stop, pause, or restart a DNS server" (http://go.microsoft.com/fwlink/?LinkId=62999).

    • Verify the DNS server responsiveness by using the nslookup command. For more information, see the instructions in "Verify DNS server responsiveness using the nslookup command" (http://go.microsoft.com/fwlink/?LinkId=63000).

  2. Use nslookup to verify that the MX records are configured correctly. For more information, see "How to Use Nslookup to Verify MX record configuration" in the "Verifying DNS Design and Configuration" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For More Information

  • For information about how Exchange Server 2003 uses DNS to resolve external IP addresses, see "Transport Dependencies for Exchange Server 2003" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • For information about DNS name resolution, see Microsoft Knowledge Base article 322856, "How to configure DNS to use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856).

  • For information about how to troubleshoot DNS, see "Troubleshooting DNS" (http://go.microsoft.com/fwlink/?LinkId=63003).


The IIS PoolThreadLimit registry value has been manually added and configured
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entries to determine whether the maximum number of Internet Information Services (IIS) pool threads has been modified from the default value:

HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Services\Inetinfo\Parameters\PoolThreadLimit

If the Exchange Server Analyzer finds PoolThreadLimit to be present and configured with an alternate value, a non-default configuration message is displayed.

The PoolThreadLimit registry value specifies the maximum number of input/output (I/O) worker threads that can be created in the Inetinfo.exe process, which in turn controls the maximum number of simultaneous connections that can be made to IIS. Each pool thread watches for a network request and processes it, either by sending back a static file or by passing the request to an ISAPI extension DLL (such as ASP.DLL) or to a Common Gateway Interface (CGI) application. If the ISAPI extension processes a request synchronously and it takes a long time to process requests, it will tie up the worker thread, leaving IIS with fewer worker threads to process other requests. For this reason, well-written ISAPI extensions, such as ASP, implement their own thread pools, place requests in a queue, and process them asynchronously with their own threads, so as not to tie up IIS worker threads.

By default, IIS sets PoolThreadLimit to:

2 * number of megabytes of RAM present in the machine

If this value is larger than 256, it will be clamped to 256. By default, this registry value does not exist. If this value is present in the registry, it overrides IIS's default calculation.

Generally, if you find that the default limit of 256 threads is inadequate, you probably have a poorly written ISAPI extension tying up IIS worker threads. 256 is a lot of threads to have active simultaneously and will incur significant overhead in synchronization and context switching.

The PoolThreadLimit registry value is a hard limit that includes all IIS worker threads, including the HTTP, FTP, NNTP, and SMTP services.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

  3. Examine, delete, or modify the PoolThreadLimit value.

  4. Close the registry editor and restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read the Microsoft Knowledge Base Article, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).


Incoming and outgoing message size restriction
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-12-01

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the attribute for the outgoing message size limit, which is submissionContLength, differs from the attribute for the incoming message size limit, which is delivContLength. If the Exchange Server Analyzer finds that the outgoing message size limit and the incoming message size limit are different, the Exchange Server Analyzer displays a best practice recommendation message.

We recommend that you set the outgoing message size limit and the incoming message size limit to the same value to provide consistency on message restriction.

To change the outgoing message size limit for Exchange 2000 Server and Exchange Server 2003

  1. Start Exchange System Manager.

  2. In the left pane, expand Global Settings.

  3. Right-click Message Delivery, and then click Properties.

  4. On the Defaults tab, under Sending message size, click Maximum (KB), and then type a number.
To set the outgoing message size limits for Exchange Server 2007

  1. In Exchange Management Shell, run the following command where <size> is entered as the default of "unlimited" or the size in B (Bytes), KB (Kilobytes), or MB (Megabytes) in a range of 0 to 2147483647 bytes:
Copy Code
Set-TransportConfig -MaxSendSize <size>

For example, to set the maximum message size that can be sent by users in the Exchange Organization to 10 Megabytes you would enter:

Copy Code
Set-TransportConfig -MaxSendSize 10MB

To set the maximum message size that can be sent by users in the Exchange Organization to the default value of unlimited you would enter:

Copy Code
Set-TransportConfig -MaxSendSize unlimited
 To change the incoming message size limit

  1. Start Exchange System Manager.

  2. In the left pane, expand Global Settings.

  3. Right-click Message Delivery, and then click Properties.

  4. On the Defaults tab, under Receiving message size, click Maximum (KB), and then type a number.
To set the incoming message size limits for Exchange Server 2007

  1. In Exchange Management Shell, run the following command where <size> is entered as the default of "unlimited" or the size in B (Bytes), KB (Kilobytes), or MB (Megabytes) in a range of 0 to 2147483647 bytes:
Copy Code
Set-TransportConfig -MaxReceiveSize <size>

For example, to set the maximum message size that can be received by recipients in the Exchange Organization to 10 Megabytes you would enter:

Copy Code
Set-TransportConfig -MaxReceiveSize 10MB

To set the maximum message size that can be received by recipients in the Exchange Organization to the default value of unlimited you would enter:

Copy Code
Set-TransportConfig -MaxReceiveSize unlimited

For more information about how to set size limits for messages in Exchange 2000 Server and in Exchange Server 2003, see Microsoft Knowledge Base article 322679, "How to set size limits for messages in Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679).

For more information about the TransportConfig cmdlet for Exchange Server 2007, see "Set-TransportConfig" in the Exchange Server 2007 Technical Reference (http://go.microsoft.com/fwlink/?LinkId=79237).


Intelligent Message Filter custom response present
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether the CustomRejectResponse registry value is present:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter

The Exchange Server Analyzer displays a non-default configuration message if the following conditions exist:

  • The CustomRejectResponse value is present.

  • This value is a valid string.

    Note:
    The response string value must start with 550 5.7.1 to be recognized as valid.

No remedial action is required.

In Exchange Server 2003 Service Pack 2 (SP2), intelligent message filtering is installed and ready to use when you install SP2. Exchange Server 2003 SP2 allows for customization of the server response string that is generated and appended to the non-delivery report (NDR) sent back to the sender. The default response of 550 5.7.1 Requested action not taken: message refused can be changed to provide blocked legitimate users with a meaningful explanation as to why their message was blocked. This explanation can help reduce investigation of false positives and decrease support costs associated with the anti-spam processing.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To change the custom response string

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Exchange\ContentFilter

  3. In the right task pane, right-click the CustomRejectResponse value and select Modify.

  4. Enter the string value you want to use as the custom response, starting the string with 550 5.7.1. For example, you can enter 550 5.7.1 Domain not an allowed sender to set the string to a valid string that will be appended to the NDR.

  5. Save the changes, exit the registry editor, and restart the SMTP service for the changes to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about intelligent message filtering, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).

For detailed information about how to perform intelligent message filtering tasks, see "Configure Intelligent Message Filtering" in the Exchange Server 2003 SP2 online Help.

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site (http://go.microsoft.com/fwlink/?LinkId=52073).


Intelligent Message Filter custom word list present
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the CIM_Datafile Windows® Management Instrumentation (WMI) class for the presence of an MSExchange.UCEContentFilter.xml file on the Exchange server. If the Exchange Server Analyzer finds an MSExchange.UCEContentFilter.xml file on the Exchange server, the Exchange Server Analyzer displays a non-default configuration message. No remedial action is required.

The MSExchange.UCEContentFilter.xml file is a component of the custom weighting feature in Intelligent Message Filter for Exchange Server 2003 Service Pack 2 (SP2).

The custom weighting feature in Intelligent Message Filter for SP2 lets administrators customize the behavior of Intelligent Message Filter, based on phrases that are within the body of an e-mail message, the subject line, or both. There is no user interface associated with the custom weighting feature. Custom weighting is made available in the form of an XML configuration file, MSExchange.UCEContentFilter.xml, that is read by Intelligent Message Filter upon initialization, and then reloaded any time the file changes. If the MSExchange.UCEContentFilter.xml file is not present when Intelligent Message Filter is started, you must restart the SMTP service. The MSExchange.UceContentFilter.xml custom weighting file should be located in the same directory as the MSExchange.UceContentFilter.dll and .dat files.

For more information about the custom weighting file, see the Exchange Server 2003 Service Pack 2 Release Notes. The release notes for Exchange Server 2003 Service Pack 2 are available both on the CD for SP2 and at the Exchange Server 2003 Service Pack 2 Release Notes Web site (http://go.microsoft.com/fwlink/?LinkId=52072).

For more information about SP2 for Exchange Server 2003, see the Exchange Server 2003 Service Pack 2 Web site (http://go.microsoft.com/fwlink/?LinkId=52073).


Intelligent Message Filter invalid custom response
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry key to determine whether the CustomRejectResponse registry value is present:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter

The Exchange Server Analyzer displays a warning if the following conditions exist:

  • The CustomRejectResponse value is present.

  • This value string does not start with 550 5.7.1.

    Note:
    The response string value must start with 550 5.7.1 to be recognized as valid.

Exchange Server 2003 Service Pack 2 (SP2) allows for customization of the server response string that is generated and appended to the non-delivery report (NDR) sent back to the sender. The default response of 550 5.7.1 Requested action not taken: message refused can be changed to provide blocked legitimate users with a meaningful explanation as to why their message was blocked. This explanation can help reduce investigation of false positives and decrease support costs associated with the anti-spam processing.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Exchange\ContentFilter

  3. In the right task pane, right-click the CustomRejectResponse value and select Modify.

  4. Enter the string value you want to use as the custom response, starting the string with 550 5.7.1. For example, you can enter 550 5.7.1 Domain not an allowed sender to set the string to a valid string that will be appended to the NDR.

  5. Save the changes, exit the registry editor, and restart the SMTP service for the changes to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about intelligent message filtering, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).

For detailed information about how to perform intelligent message filtering tasks, see "Configure Intelligent Message Filtering" in the Exchange Server 2003 SP2 online Help.


Intelligent Message Filter is enabled on the mailbox server
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Microsoft Exchange Intelligent Message Filter is installed and enabled on the server:

HKEY_LOCAL_MACHINE\ Software\Microsoft\Exchange\ContentFilter

The Exchange Server Analyzer reads the ContentFilterBindings value in the ContentFilter registry key to determine whether Intelligent Message Filter is installed and enabled on the server.

The Exchange Server Analyzer then queries the Active Directory® directory service to determine the value for msExchAuthenticationFlags attribute for the Exchange Server object. The msExchAuthenticationFlags attribute represents the type of authentication that is allowed on the server. The Exchange Server Analyzer displays a warning message if the following conditions exist:

  • Authentication on the msExchAuthenticationFlags attribute has been configured to allow anonymous access to the server.

  • The server also hosts mailboxes on it.

Intelligent Message Filter identifies messages that are likely to be unsolicited commercial e-mail (UCE). To filter UCE effectively, you must deploy Intelligent Message Filter on your Exchange gateway servers or Exchange bridgehead servers if you use non-Microsoft e-mail servers at the gateway. These gateway servers accept incoming Internet e-mail messages and forward these messages to the appropriate mailbox server. Generally, gateway servers do not host mailboxes.

Additionally, you must enable Intelligent Message Filter on each SMTP virtual server that accepts Internet e-mail messages on your Exchange gateway servers.

Important:
Do not disable anonymous access on your Internet gateway SMTP virtual servers. These SMTP virtual servers that accept mail from the Internet must allow anonymous access.

To filter UCE, you can configure Intelligent Message Filter by setting thresholds for the spam confidence level (SCL) ratings that are assigned to incoming messages on both the gateway and the Exchange mailbox stores. Intelligent Message Filter evaluates each incoming message and assigns the message an SCL rating that is based on the likelihood that the message is UCE. Exchange mailbox servers use the SCL threshold and settings that are specified for the mailbox store to determine whether to deliver a message to a user's Inbox or to a user's Junk E-mail folder.

Important:
Intelligent Message Filter does not have to be installed on Exchange mailbox servers. If Intelligent Message Filter is installed and enabled on the gateway SMTP virtual servers, Exchange mailbox servers receive the SCL rating with each incoming message and take the appropriate action.

For information, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607). For more information about configuring your Microsoft Exchange Server 2003 organization to send and receive Internet mail, see Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Intelligent Message Filter is not enabled on the server
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Microsoft Exchange Intelligent Message Filter is installed and enabled on the server:

HKEY_LOCAL_MACHINE\ Software\Microsoft\Exchange\ContentFilter

If the Exchange Server Analyzer finds that the ContentFilterBindings value entry in the ContentFilter registry key is present, but the ContentFilterBindings value is not configured, the Exchange Server Analyzer displays a warning message.

Note:
The presence of the ContentFilterBindings value entry in the ContentFilter registry key when the ContentFilterBindings value is not configured indicates that Intelligent Message Filter is not enabled on the server.
Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

Microsoft Exchange Intelligent Message Filter identifies messages that are likely to be unsolicited commercial e-mail (UCE). After you deploy Intelligent Message Filter on your Exchange gateway servers or Exchange bridgehead servers that accept incoming e-mail, you must enable Intelligent Message Filter on each SMTP virtual server that accepts Internet e-mail messages.

To view the ContentFilter registry key

  1. In Registry Editor (regedit), in the details pane, right-click ContentFilter to view the setting for ContentFilterBindings.

    Note:
    If you have not configured Exchange Intelligent Message Filter on your SMTP virtual server, the ContentFilterBindings value will be null.

    Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

It is recommended that Exchange Intelligent Message Filter be enabled on all Exchange Servers that have Intelligent Message Filter installed. To enable Intelligent Message Filter on your SMTP virtual server, perform the following procedure. After enabling Intelligent Message Filter, you can verify the value of ContentFilter registry key in the registry.

To enable Intelligent Message Filter

  1. Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In Exchange System Manager, expand Servers, expand Server name, expand Protocols, expand SMTP, right-click Intelligent Message Filtering, and then click Properties.

  3. On the General tab, under Apply intelligent message filtering to the following virtual servers' IP addresses, click the check box next to each SMTP virtual server on which you want to enable Intelligent Message Filter.

    The Intelligent Message Filtering Properties dialog box

For information, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).


Invalid Recipient Update Service Server Designated
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-07-30

The Microsoft Exchange Analyzer Tool queries the Active Directory directory service to determine the value of the msExchAddressListServiceLink attribute for each Recipient Update Service object in the directory. The msExchAddressListServiceLink attribute is a link from the address list service to an Exchange Server computer that is running the Recipient Update Service (RUS).

The Exchange Analyzer then queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Version key for the Address Book View and Dynamic Groups Service (abv_dg.dll) on the identified Exchange Server computers. The Version WMI key indicates the build number for this file.

If the Exchange Analyzer finds that the build number for the abv_dg.dll file on any of the identified computers starts with 08, an error is displayed.

This error indicates that the computer designated as a RUS server is running Microsoft Exchange Server 2007.

The Recipient Update Service is a component of the Exchange System Attendant service found in Exchange 2000 Server and Exchange Server 2003. The Recipient Update Service for Exchange 2000 and Exchange 2003 creates and maintains Exchange-specific attribute values in Active Directory. This functionality is handled by the recipient creation process in Exchange 2007 and the legacy Recipient Update Service will not process updates if running on an Exchange 2007 server.

To address this error, designate an Exchange 2000 Server or Exchange Server 2003 to host the Recipient Update Service.

To correct this error

  1. Open Exchange System Manager.

  2. Under Recipients, click Recipient Update Services. In the right navigation pane, right-click the appropriate instance of the Recipient Update Service, and then click Properties.

  3. On the General tab, under Exchange Server, click Browse, and then specify a new, Exchange 2000 Server or Exchange Server 2003 server to run this RUS instance.

  4. Click OK, and then click OK again for the change to take effect.


Large number of categorizations in progress
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Cat: Categorizations in progress performance counter of the SMTP Server performance object to analyze performance data.

The Cat: Categorizations in progress performance counter shows the number of categorizations in progress.

For this query, the Exchange Server Analyzer retrieves a sample every 6 seconds for a two-minute period. The Exchange Server Analyzer reports the average value for the performance counter during the collection interval.

If the Exchange Server Analyzer determines that the average number of categorizations in progress over the sample period exceeds 800, the Exchange Server Analyzer displays an error.

The categorizer performs the following core operations:

  • Resolves and validates all recipients.

  • Determines limits and restrictions for all recipients.

  • Expands distribution lists if that is required.

  • Determines whether the message is for local or remote delivery.

This error may indicate that the server is experiencing an extraordinary load or has a performance related issue.

To resolve this error:

  • Determine whether the stress to the categorizer is expected or from a typical load. If the stress to the categorizer is from an expected load, review the Exchange performance guidance in the following Microsoft TechNet articles.

    • "Troubleshooting Exchange Server 2003 Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

    • "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

  • If the stress to the categorizer is not from an expected load, check for virus outbreaks or SPAM that might generate the load.

The message categorizer performance counters are published separately for each Simple Mail Transfer Protocol (SMTP) virtual server instance. For a list of the available performance counters related to the Message Categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).


Large number of mailboxes with distribution group delivery restrictions set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool queries the following attributes for each user object in all domains found in the Active Directory® directory service to determine whether any mailboxes in the domains have delivery restrictions set based on distribution group membership:

dLMemDefault | Controls whether messages are accepted or rejected by default. When set to the default setting of 1, messages from everyone are accepted.
dLMemRejectPerms | Contains the DNs of distribution lists (DL) whose members may not send to this recipient.
dLMemSubmitPerms | Contains the DNs of distribution lists (DL) whose members may send to this recipient.

If the Exchange Server Analyzer determines that there are more than 500 mailboxes in the domain that have delivery restrictions set based on distribution group membership, the Exchange Server Analyzer displays an error.

This error indicates that delivery restrictions based on distribution group membership for many mailboxes may affect Exchange mail flow performance.

By default, categorizer recursively expands distribution groups and checks restrictions for each message that passes through the system.

When the message categorizer sends mail to a user who accepts or denies messages from a distribution group, the message categorizer has to expand the membership of the distribution group, obtain the full list of DNs of the members, and then compare the list of DNs to the list sender's DNs. An access operation or a deny operation occurs when a DN appears on both lists. If a distribution group is nested in another distribution group, the nested distribution is also expanded.

To address this error:

  • Examine those users whose distribution group delivery restrictions are set and remove unnecessary restrictions.

  • Configure individual mailboxes and not distribution groups for delivery restrictions as referenced in Microsoft Knowledge Base article 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

  • For servers that are running Exchange Server 2003 Service Pack 2 (SP2) or a later version, consider implementing non-hierarchal restriction checking. For servers that are running Exchange versions earlier than Exchange Server 2003 SP2, consider upgrading to Exchange Server 2003 SP2.

For More Information

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking

For more information about the effect of distribution group restriction on Exchange Server mail flow, see the following Microsoft Knowledge Base articles:

  • 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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

  • 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).


Least Cost Routing is Enabled in a Mixed-Mode Organization
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether least cost routing is enabled on the server running Exchange Server version 5.5 in a mixed-mode environment. The Exchange Server Analyzer displays a warning if the following conditions exist:

  • Least cost routing is enabled.

  • Your organization is running Exchange Server 2003 in a mixed-mode environment with Exchange Server 5.5.

When least cost routing is enabled in a mixed-mode environment, message loops may be created. Exchange Server 2003 uses link state routing. Therefore, Exchange Server 2003 reroutes messages to another server when it detects that a link is down. When an Exchange Server 5.5 server is using the Only use least cost routes option in the Message Transfer Agent properties page, the best route frequently is determined to be back to the Exchange Server 2003 server from which the message was just sent. When the message is sent back to the Exchange Server 2003 server, the route becomes a loop.

In any mixed-mode organization that is running both Exchange Server 5.5 and Exchange Server 2003, it is recommended that the least cost routing option be disabled on all servers running Exchange Server 5.5.

To disable least cost routing in Exchange Server 5.5

  1. In the Microsoft Exchange Server Administrator program, expand the Organization container, expand the Site container, expand the Configuration container, expand the Servers container, and then click your server object.

  2. In the right pane, click the Message Transfer Agent object.

  3. Click the File menu, and then click Properties.

  4. In the Message Transfer Agent Properties dialog box, on the General tab, clear Only use least cost routing.

  5. Click OK.


The listening port for SMTP appears to have been changed from its default of 25
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchServerBindings attribute has been changed from the default value of 25. By default, the msExchServerBindings attribute is configured for TCP port 25. If the Exchange Server Analyzer finds that this attribute does not have a value of 25, a non-default configuration message is displayed.

The msExchServerBindings attribute represents the TCP port on which this Simple Mail Transfer Protocol (SMTP) server listens for inbound connections. SMTP virtual servers can be configured to listen on one or more TCP ports. By default, all SMTP virtual servers are configured to listen on TCP port 25, the default SMTP port. If the SMTP listening port has been modified from the default and no longer includes TCP port 25 in its list of listening ports, it could disrupt mail flow.

It is acceptable to change the SMTP listening port, provided that the rest of your internal messaging infrastructure is also modified accordingly. However, generally, alternate ports cannot be used for SMTP virtual servers that accept messages directly from the Internet, as SMTP servers on the Internet send messages through port 25.

Note that the Exchange Server Analyzer is looking at the value for the Exchange SMTP protocol virtual server. This SMTP protocol virtual server may or may not be the SMTP server that receives messages directly from the Internet. There are some antivirus and anti-spam products that are designed to receive SMTP messages from the Internet on port 25 and redirect to an Exchange SMTP virtual server on another port. In this scenario, an Exchange SMTP virtual server listening on something other than port 25 is an acceptable configuration.

To view or modify the SMTP virtual server listening port

  1. In Exchange System Manager, expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  2. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and then click Properties.

  3. Select the General tab, and then click Advanced.

  4. A list of IP addresses and ports will be displayed.

    • To change the existing port, select the IP address, and then click Edit. Change the TCP port field to 25.

    • To add port 25 as an additional listening port, click Add, and add the new IP address/port combination. If you are using Connection, Sender or Recipient Filtering, make sure that you select the appropriate check boxes.

  5. Click OK to save your changes, and then click OK to exit the Advanced dialog box. Click OK to close the Properties dialog box for the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


'Local Delivery' Queue is Frozen
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-03

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateFrozen key for the Simple Mail Transfer Protocol (SMTP) Local Delivery queue.

If the Exchange Server Analyzer finds that the value of the StateFrozen key for the Local Delivery queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

A frozen queue means the transport sessions for that queue are stopped. A frozen queue prevents outgoing messages, although new messages can be added. You can manually change the state of a connection by using the shortcut menu on each link queue. When you use the Force Connection command to change a queue state to Active, you immediately enable a connection that sends the messages from that queue.

The Local Delivery queue contains messages that are queued on the Exchange server for local delivery to an Exchange Server mailbox or public folder store.

Messages can accumulate in this queue if the Exchange server is not accepting messages for local delivery. Slow or intermittent message delivery can indicate a looping message or a performance problem.

To resolve this error, increase diagnostic logging for the MSExchangeTransport service to collect information about categorizer components.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mailflow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579)

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


'Local Delivery' Queue is in Retry
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-03

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateRetry key for the Simple Mail Transfer Protocol (SMTP) Local Delivery queue.

If the Exchange Server Analyzer finds that the value of the StateRetry key for the Local Delivery queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

If a queue is in retry status, this status indicates that at least one error occurred in the previous attempts to process the messages in the queue. You can change queues in the Retry or Scheduled state to Active with the Force Connection command. This causes the queue to function as if the retry interval had passed or the scheduled time was reached. However, this method may not always work. Remember that the properties of a queue can indicate a specific reason for a queue to be in Retry.

The Local Delivery queue contains messages that are queued on the Exchange server for local delivery to an Exchange Server mailbox or public folder store.

Messages can accumulate in this queue if the Exchange server is not accepting messages for local delivery. Slow or intermittent message delivery can indicate a looping message or a performance problem.

To resolve this error, increase diagnostic logging for the MSExchangeTransport service to collect information about categorizer components.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mailflow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579)

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


Mail Acceptance Failure
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool tries to send a message to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain as follows:

  • The Exchange Server Analyzer opens a socket connection to the SMTP server. If the Exchange Server Analyzer receives a response code of 220, this step is considered to have completed successfully.

  • The Exchange Server Analyzer transmits the EHLO SMTP command verb. If the following conditions are true, this step is considered to have completed successfully:

    • The Exchange Server Analyzer receives a series of response codes of 250.

    • One of these responses includes 250-X-LINK2STATE and 250-XEXCH50.

  • The Exchange Server Analyzer transmits the MAIL FROM: ExMFA-MailAcceptTest@Fabrikam.com SMTP command verb. If the Exchange Server Analyzer receives a response code of 250, this step is considered to have completed successfully.

  • The Exchange Server Analyzer transmits the RCPT TO: Postmaster (or a user-defined account)@<domainname>.com SMTP command verb. If the Exchange Server Analyzer receives a response code of 250, this step is considered to have completed successfully.

  • The Exchange Server Analyzer transmits the DATA SMTP command verb with a sample message body ending with a period. If the Exchange Server Analyzer receives a response code of 250, this step is considered to have completed successfully.

If the Exchange Server Analyzer is not able to complete all steps, the Exchange Server Analyzer displays an error. The error indicates that there may be a general mail flow issue. The following links are listed in the order in which you should troubleshoot, starting at the server level and working out to the network level.

To correct this error

  1. See "Troubleshooting Routing" in the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?linkid=47579).

  2. See Microsoft Knowledge Base article 324867, "Support WebCast: Microsoft Exchange 2000 Server: Troubleshooting Mail Flow Problems (Revisited)" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324867).

  3. See Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823489).

  4. See Microsoft Knowledge Base article 324759, "Support WebCast: Microsoft Exchange 2000 Server: DNS Troubleshooting in Transports" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759).

For more information about the Postmaster account in Exchange Server, see the following Microsoft Knowledge Base articles:

  • 223860, "XCON: SMTP Postmaster Mailbox Must Be Set Manually" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=223860).

  • 313832, "How To Set an SMTP Postmaster Account in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=313832).


Mail acceptance failure, BDAT command
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool transmits the EHLO Extended Simple Mail Transfer Protocol (ESMTP) command verb to port 25 of a remote server and analyzes the response to determine whether the remote server supports the BDAT ESMTP verb.

If the response received from the remote server in reply to the BDAT command verb does not indicate a non-retrievable error, the Exchange Server Analyzer then transmits a test message to the remote server and analyzes the response to determine whether the message transfer was successful.

If the Exchange Server Analyzer does not receive the expected response string of '250', the Exchange Server Analyzer displays an error.

Exchange Server 2003 uses Exchange-specific extended SMTP verbs to communicate with other servers that run Exchange Server in the organization. It is more efficient to communicate with Exchange-specific extended SMTP verbs than by using standard SMTP. If support for the ESMTP command set is disabled, Exchange Server performance may be hindered.

The BDAT ESMTP command verb is an alternative to the DATA command. When an SMTP virtual server responds to the EHLO keyword with CHUNKING, the SMTP server indicates that it supports the BDAT command and will accept messages in chunks. This takes two arguments:

  • The first argument indicates the length of the binary data packet. Therefore the SMTP host does not have to continuously scan for the end of the data. The receiving server counts the bytes in the message. When the message size equals the value sent by the BDAT command, the server assumes that it has received all the message data.

  • The second argument indicates whether the data packet is the last packet in the current transmission. The second argument is optional.

This error indicates that although the BDAT ESMTP command verb is supported by the remote server, the subsequent BDAT mail acceptance test failed.

To resolve this error, check the messaging environment for issues or configurations that might be blocking the BDAT command verb such as:

  • Transient network outages

  • SMTP proxies

  • Firewalls

  • Applications

For more information about how to remove or restore the default support for these verbs, see Microsoft Knowledge Base article 257569 "How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257569).

For more information about how Exchange Server uses the ESMTP command verbs, see "How to Load Exchange SMTP Properly" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=71800).


Mailbox store identified as a common destination
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-04

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_Queue Windows® Management Instrumentation (WMI) class to determine the values of the following attributes for the Simple Mail Transfer Protocol (SMTP) queues of the SMTP virtual server.

LinkId | Indicates the identifier for the link that contains the queue.
QueueId | Indicates the identifier of the queue.
QueueName | Indicates the name of the queue.
VirtualMachine | Indicates the name of the virtual machine that contains the queue.
VirtualServerName | Indicates the name of the virtual server that the queue is on.
MessageCount | Indicates the number of messages in the queue.

The Exchange Server Analyzer uses the information obtained here to query the Exchange_QueuedSMTPMessage WMI class for the values of the following attributes of the messages in the queue:

Recipients | Indicates the recipients of the message.
Received | Indicates the received time stamp for the message.
MessageId | Indicates the identifier of the queued message.
StateRetry | Indicates that transmission is retried for a message that was not delivered successfully.

Finally, the Exchange Server Analyzer uses the data obtained here to query the Active Directory® directory service for the following values of each Recipient object. The Exchange Server Analyzer then determines whether the recipient is a user, a distribution group, a public folder, or a public folder store:

distinguishedName | Indicates the distinguished name of the object.
msExchHomeServerName | Indicates the server the recipient is homed on.
homeMDB | Indicates the mailbox store of the recipient.

If the Exchange Server Analyzer determines that at least 25 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to recipients whose mailboxes are homed on the same mailbox store, the Exchange Server Analyzer displays a warning.

If the Exchange Server Analyzer determines that at least 50 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to recipients whose mailboxes are homed on the same mailbox store, the Exchange Server Analyzer displays an error.

This warning or error means that the mailbox store identified is a common destination for messages that are stuck in an SMTP queue.

To address this issue, the mailbox store should be investigated as follows for configuration issues or other anomalies that could cause messages to queue for it:

  • Make sure that the store object attributes are correctly set and contain the correct values in Active Directory.

  • Review the Active Directory permissions of the store object for the correct settings.

  • If the mailbox store is the store for a special use user object, that is, a designated Journaling recipient, review the configurations of the service or components that the user object is related to for correct configuration.

  • Look for possible unsolicited commercial e-mail (UCE), or spam, or virus attacks against the store recipients.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).


'Messages with an unreachable destination' queue holds messages
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-04

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the TypeCurrentlyUnreachable, LinkName, and NumberofMessages properties for the Simple Mail Transfer Protocol (SMTP) queues on a server.

The TypeCurrentlyUnreachable property, when True, specifies that the link (Exchange queue) holds messages for destinations that currently cannot be reached.

The LinkName property specifies the name of the link.

The NumberOfMessages property specifies the number of messages that are waiting for transmission across the link.

If the Exchange Server Analyzer determines that the Messages with an unreachable destination SMTP queue contains any messages, the Exchange Server Analyzer displays an error.

This error indicates that there are messages in the queue that cannot reach the intended destination server. For example, Exchange cannot determine a route or a connector to the final destination. Alternatively, all available routes or connectors are marked as down.

To address this error, take the following steps:

  • Determine whether the messages in the Messages with an unreachable destination queue are legitimate.

  • Review the error guidance and links provided by the Exchange Server Analyzer.

  • Follow the guidance in "For More Information" later in this topic.

For More Information

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).


'Messages with an unreachable destination' queue is frozen
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateFrozen key for the Simple Mail Transfer Protocol (SMTP) Messages with an unreachable destination queue.

If the Exchange Server Analyzer finds that the value of the StateFrozen key for the Messages with an unreachable destination queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

A frozen queue means the transport sessions for that queue are stopped. A frozen queue prevents outgoing messages, although new messages can be added.

The Messages with an unreachable destination queue contains messages that cannot reach the intended destination server. For example, Exchange cannot determine a route or a connector to the final destination. Alternatively, all available routes or connectors are marked as down. Messages can accumulate in this queue if any one of the following conditions is true:

  • No route exists for message delivery.

  • An Exchange connector or a remote delivery queue is unavailable.

  • New messages are moved to this queue when an Exchange connector or a remote delivery queue is in a retry status and no alternative available route exists to the connector or the remote destination.

To address this error, manually change the state of the connection by using the shortcut menu on each link queue. When you use the Force Connection command to change a queue state to Active, you immediately enable a connection that sends the messages from that queue. If the error persists, raise the diagnostics logging level of Queuing Engine as described in "For More Information" later in this topic.

For More Information

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


'Messages with an unreachable destination' queue is in retry
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateRetry key for the Simple Mail Transfer Protocol (SMTP) Messages with an unreachable destination queue.

If the Exchange Server Analyzer finds that the value of the StateRetry key for the Messages with an unreachable destination queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

If a queue is in retry status, it indicates that at least one error occurred in the previous attempts to process the messages in the queue.

Note:
The properties of a queue can indicate a specific reason for a queue to be in retry status.

The Messages with an unreachable destination queue contains messages that cannot reach the intended destination server. For example, Exchange cannot determine a route or a connector to the final destination. Alternatively, all available routes or connectors are marked as down. Messages can accumulate in this queue if any one of the following conditions is true:

  • No route exists for message delivery.

  • An Exchange connector or a remote delivery queue is unavailable.

  • New messages are moved to this queue when an Exchange connector or a remote delivery queue is in a retry status and no alternative available route exists to the connector or the remote destination.

To address this error, change the Retry state to Active with the Force Connection command. This causes the queue to function as if the retry interval had passed. However, this method may not always work. If the error persists, raise the diagnostics logging level of Queuing Engine as described in "For More Information" later in this topic.

For More Information

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


Mailboxes with distribution group delivery restrictions set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool queries the following attributes for each user object in all domains found in the Active Directory® directory service to determine whether any mailboxes in the domains have delivery restrictions set that are based on distribution group membership:

dLMemDefault | Controls whether messages are accepted or rejected by default. When set to the default setting of 1, messages from everyone are accepted.
dLMemRejectPerms | Contains the DNs of distribution lists (DL) whose members may not send to this recipient.
dLMemSubmitPerms | Contains the DNs of distribution lists (DL) whose members may send to this recipient.

If the Exchange Server Analyzer determines that there are mailboxes in the domain that have delivery restrictions set based on distribution group membership, the Exchange Server Analyzer displays a warning.

This warning indicates that delivery restrictions based on distribution group membership may affect Exchange Server mail flow performance.

By default, the categorizer recursively expands distribution groups and checks restrictions for each message that passes through the system.

When the message categorizer sends mail to a user who accepts or denies messages from a distribution group, the message categorizer has to expand the membership of the distribution group, obtain the full list of DNs of the members, and then compare the list of DNs to the list sender's DNs. An access operation or a deny operation occurs when a DN appears on both lists. If a distribution group is nested in another distribution group, the nested distribution is also expanded.

To address this warning:

  • Examine those users whose distribution group delivery restrictions are set and remove unnecessary restrictions.

  • Configure individual mailboxes and not distribution groups for delivery restrictions as referenced in Microsoft Knowledge Base article 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

  • For servers that are running Exchange Server 2003 Service Pack 2 (SP2) or a later version, consider implementing non-hierarchal restriction checking. For servers that are running Exchange versions earlier than Exchange Server 2003 SP2, consider upgrading to Exchange Server 2003 SP2.

For More Information

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking.

For more information about the effect of distribution group restriction on Exchange Server mail flow, see the following Microsoft Knowledge Base articles:

  • 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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

  • 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).


Maximum incoming message size has not been set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the global settings delivContLength attribute located at:

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=OrganizationName, CN=Global Settings, CN=Message Delivery

If the Exchange Server Analyzer finds the value for the delivContLength attribute to be less than 1, an error is displayed.

This error indicates that a maximum incoming message size limit has not been set. Based on network bandwidth and user requirements in your organization, you may want to limit the message size. In Exchange 2000 Server and Exchange Server 2007, there is no default message size limit. In Exchange Server 2003, the default size limit for sending and receiving messages is 10,240 KB. This default size limit for Exchange Server 2003 applies to new installations and to upgrades from Exchange 2000 Server in which no message size limit was set.

You can conserve system resources by setting message size limits that prevents users from sending and receiving large e-mail messages. This will help limit network traffic, save disk space, and improve overall network performance. For Exchange 2000 Server and Exchange Server 2003, you can use the Defaults tab in Message Delivery Properties of your Global Settings to specify message delivery restrictions for incoming and outgoing messages. To then set the maximum individual message size, select Maximum (KB), and then in the text box, type a maximum size, in kilobytes (KB). If you do not want to limit the size of messages, select No limit. Senders in your organization receive an NDR if they try to send a message to a user who goes beyond the specified size limit. Depending on the NDR settings that you configure in Internet Message Formats, external senders may not receive an NDR.

For Exchange Server 2007, you can use the Exchange Management Shell to set the TransportConfig MaxReceiveSize parameter for the Exchange organization.

We recommend that you set the maximum message size limit to no more than 10 MB. However, if you need a larger message size limit for messages that have large attachments to be sent through the Exchange organization, you may want to increase the maximum incoming message size limit to 30 MB. Increasing the message size limit over 30 MB can slow down the network performance and even cause your system to be more vulnerable to security attacks.

To set message size limits for Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, expand Global Settings, right-click Message Delivery, and then click Properties.

  2. In the Message Delivery Properties dialog box, on the Defaults tab, select the Receiving message size limit option and type the size limit you want.

To set message size limits for Exchange Server 2007

  1. In Exchange Management Shell, run the following command where <size> is entered as the default of "unlimited" or the size in B (Bytes), KB (Kilobytes), or MB (Megabytes) in a range of 0 to 2147483647 bytes:
Copy Code
Set-TransportConfig -MaxReceiveSize <size>

For example, to set the maximum message size that can be received by recipients in the Exchange Organization to 10 Megabytes you would enter:

Copy Code
Set-TransportConfig -MaxReceiveSize 10MB

To set the maximum message size that can be received by recipients in the Exchange Organization to the default value of unlimited you would enter:

Copy Code
Set-TransportConfig -MaxReceiveSize unlimited
  • For more information about how to set message size limits for Exchange 2000 Server and Exchange Server 2003, see the Microsoft Knowledge Base article, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679).

  • For more information about the TransportConfig cmdlet for Exchange Server 2007, see "Set-TransportConfig" in the Exchange Server 2007 Technical Reference (http://go.microsoft.com/fwlink/?LinkID=79237).

  • For more information about Internet Message Formats, see "Configuring SMTP Policies to Control Outbound Mail Formatting and Automatic Responses" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


Maximum incoming message size is set too high (>30MB)
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-02-27

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the global settings delivContLength attribute located at:

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=OrganizationName, CN=Global Settings, CN=Message Delivery

If the Exchange Server Analyzer finds the value for the delivContLength attribute to be more than 30720, an error is displayed.

This error indicates that a maximum incoming message size limit is set to a value more than 30 megabytes (MB). In Exchange 2000 Server and Exchange Server 2007, there is no default message size limit. In Exchange Server 2003, the default size limit for sending and receiving messages is 10,240 KB. This default size limit applies to new installations and to upgrades from Exchange 2000 Server in which no message size limit was set.

You can conserve system resources by setting message size limits that prevent users from sending and receiving large e-mail messages. This will help limit network traffic, save disk space, and improve overall network performance. For Exchange 2000 Server and Exchange Server 2003, you can use the Defaults tab in Message Delivery Properties of your Global Settings to specify message delivery restrictions for incoming and outgoing messages. To set the maximum individual message size, select Maximum (KB), and then in the text box, type a maximum size, in kilobytes (KB). If you do not want to limit the size of messages, select No limit. Senders in your organization receive a non-delivery report (NDR) if they try to send a message to a user who goes beyond the specified size limit. Depending on the NDR settings that you configure in Internet Message Formats, external senders may not receive an NDR.

For Exchange Server 2007, you can use the Exchange Management Shell to set the TransportConfig MaxSendSize parameter for the Exchange organization.

We recommend that you set the maximum message size limit to no more than 30 MB. However, if you need a larger message size limit for messages that have large attachments to be sent through the Exchange organization, you may want to increase the maximum incoming message size limit to more than 30 MB. Increasing the message size limit over 30 MB can slow down the network performance and even cause the system to be more vulnerable to security attacks.

Important:
Though they may seem similar, the results of the following settings differs dramatically for pure Exchange 2000 Server/Exchange Server 2003 environments and Exchange Server 2007 environments.

Setting send and receive message size restrictions to a value of 0 in the Global Settings for a mailbox enabled user in a pure Exchange 2000 Server/Exchange Server 2003 environment has the effect of removing message size restrictions entirely.

Setting the TransportConfig -MaxSendSize and TransportConfig -MaxreceiveSize parameters to a value of 0 in a pure Exchange 2007 environment has the effect of restricting messages of any size from being sent.

To set message size limits for Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, expand Global Settings, right-click Message Delivery, and then click Properties.

  2. In the Message Delivery Properties dialog box, on the Defaults tab, select the Receiving message size limit option and type the size limit you want.

To set message size limits for Exchange Server 2007

  1. In Exchange Management Shell, run the following command where <size> is entered as the default of "unlimited" or the size in B (Bytes), KB (Kilobytes), or MB (Megabytes) in a range of 0 to 2147483647 bytes:
Copy Code
Set-TransportConfig -MaxReceiveSize <size>

For example, to set the maximum message size that can be received by recipients in the Exchange Organization to 10 Megabytes you would enter:

Copy Code
Set-TransportConfig -MaxReceiveSize 10MB

To set the maximum message size that can be received by recipients in the Exchange Organization to the default value of unlimited you would enter:

Copy Code
Set-TransportConfig -MaxReceiveSize unlimited
  • For more information about how to set message size limits for Exchange 2000 Server and Exchange Server 2003, see the Microsoft Knowledge Base article 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679).

For more information about the TransportConfig cmdlet for Exchange Server 2007, see "Set-TransportConfig" in the Exchange Server 2007 Technical Reference (http://go.microsoft.com/fwlink/?LinkID=79237).

  • For more information about Internet Message Formats, see "Configuring SMTP Policies to Control Outbound Mail Formatting and Automatic Responses" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


Maximum incoming message size maybe set too low (<1MB)
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-05

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the global settings delivContLength attribute located at:

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=OrganizationName, CN=Global Settings, CN=Message Delivery

If the Exchange Server Analyzer finds the value for the delivContLength attribute to be less than 1024 but more than 0, an error is displayed.

This error indicates that a maximum incoming message size limit is set to a value less than 1 megabyte (MB). Such a low value may prevent Exchange Server from accepting some of the messages sent to your organization. In Exchange 2000 Server and Exchange Server 2007, there is no default message size limit. In Exchange Server 2003, the default size limit for sending and receiving messages is 10,240 KB. This default size limit applies to new installations and to upgrades from Exchange 2000 Server in which no message size limit was set.

You can conserve system resources by setting message size limits that prevent users from sending and receiving large e-mail messages. This will help limit network traffic, save disk space, and improve overall network performance. For Exchange 2000 Server and Exchange Server 2003, you can use the Defaults tab in Message Delivery Properties of your Global Settings to specify message delivery restrictions for incoming and outgoing messages. To set the maximum individual message size, select Maximum (KB), and then in the text box, type a maximum size, in kilobytes (KB). If you do not want to limit the size of messages, select No limit. Senders in your organization receive an NDR if they try to send a message to a user who exceeds the specified size limit. Depending on the NDR settings that you configure in Internet Message Formats, external senders may not receive an NDR.

For Exchange Server 2007, you can use the Exchange Management Shell to set the TransportConfig MaxSendSize parameter for the Exchange organization.

We recommend that you set the maximum message size limit to no more than 10 MB. However, if you need a larger message size limit for messages that have large attachments to be sent through the Exchange organization, you may want to increase the maximum incoming message size limit to 30 MB. Increasing the message size limit over 30 MB can slow down the network performance and even cause the system to be more vulnerable to security attacks.

To set message size limits for Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, expand Global Settings, right-click Message Delivery, and then click Properties.

  2. In the Message Delivery Properties dialog box, on the Defaults tab, select the Receiving message size limit option and type the size limit you want.

To set message size limits for Exchange Server 2007

  1. In Exchange Management Shell, run the following command where <size> is entered as the default of "unlimited" or the size in B (Bytes), KB (Kilobytes), or MB (Megabytes) in a range of 0 to 2147483647 bytes:
Copy Code
Set-TransportConfig -MaxReceiveSize <size>

For example, to set the maximum message size that can be received by recipients in the Exchange Organization to 10 Megabytes you would enter:

Copy Code
Set-TransportConfig -MaxReceiveSize 10MB

To set the maximum message size that can be received by recipients in the Exchange Organization to the default value of unlimited you would enter:

Copy Code
Set-TransportConfig -MaxReceiveSize unlimited
  • For more information about how to set message size limits for Exchange 2000 Server and Exchange Server 2003, see the Microsoft Knowledge Base article 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679).

For more information about the TransportConfig cmdlet for Exchange Server 2007, see "Set-TransportConfig" in the Exchange Server 2007 Technical Reference (http://go.microsoft.com/fwlink/?LinkID=79237).

  • For more information about Internet Message Formats, see "Configuring SMTP Policies to Control Outbound Mail Formatting and Automatic Responses" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


MaxDSNSize not set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the maximum size for delivery status notification (DSN) messages has been set:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\MaxDSNSize

The Exchange Server Analyzer also queries the Active Directory® directory service to determine the value of the serialNumber attribute for all objects with an object class of msExchExchangeServer. If the string value includes "Version 5.5," the computer is running Microsoft Exchange Server 5.5. If the string value includes "Version 6.0," the computer is running Microsoft Exchange 2000 Server. If the string value includes "Version 6.5," the computer is running Microsoft Exchange Server 2003.

If the Exchange Server Analyzer finds that the MaxDSNSize registry value does not exist on a computer that is running Exchange 2000 Server or Exchange Server 2003, a warning is displayed.

The MaxDSNSize registry value is an optional value in Exchange Server that limits the size of DSNs. This option configures Exchange to remove attachments if a message cannot be delivered. If you add this registry value, it is recommended that a value of 10240000 bytes (10 megabytes) be used.

Note:
The MaxDSNSize registry value was introduced in Service Pack 2 (SP2) for Exchange 2000 Server, and therefore requires Exchange 2000 Server SP2 or later versions to work. Additionally, in Service Pack 1 for Exchange Server 2003 and later versions, a value of 10 megabytes is used in the absence of the MaxDSNSize registry value. If you want, you can add the MaxDSNSize registry value to override this default behavior.

If you enable this option, you can save server and network resources. However, there are drawbacks to this implementation of Simple Mail Transfer Protocol (SMTP) attachment stripping. If you enable this option to strip the attachments from the non-delivery report (NDR), the details that are necessary to display the notification in the preview pane are also stripped, and the originator of the message cannot use the Send Again option. If the originator of the message tries to use the Send Again option from the NDR, the originator of the message receives the following error message: Unable to resend the message. The nondelivery report does not contain sufficient information about the original message. To resend the message, open it in your Sent Items folder, click the Actions menu, and click "Resend this message".

However, the originator of the message cannot resend the message, even by using the method in the error message.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\SMTPSvc

  3. Right-click SMTPSvc and select New | Key. Name the new key Queuing and leave the class blank.

  4. Right-click Queuing and select New | DWORD Value. Name the new value MaxDSNSize.

  5. In the right pane, double-click the MaxDSNSize registry value and enter the size limit (in bytes) that you want in the Value data field. Messages that are larger than this value that generate an NDR do not return attachments or full message properties.

  6. Close the registry editor, and then restart the Simple Mail Transfer Protocol (SMTP) service for the change to take effect.

For more information about the MaxDSNSize registry setting, see the following Microsoft Knowledge Base articles:

  • 308303, "XCON: Option to Strip Attachments for Messages That Generate an NDR," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=308303)

  • 323484, "XCON: Description of the Multipart/Report Internet Message Format in Exchange 2000," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=323484)


Maximum outgoing message size has not been set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-12-04

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the global settings submissionContLength attribute located at:

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=OrganizationName, CN=Global Settings, CN=Message Delivery

If the Exchange Server Analyzer finds the value for the submissionContLength attribute to be less than 1, an error is displayed.

This error indicates that a maximum outgoing message size limit has not been set. Based on network bandwidth and user requirements in your organization, you may want to limit the message size. In Exchange 2000 Server and Exchange Server 2007, there is no default message size limit. In Exchange Server 2003, the default size limit for sending and receiving messages is 10,240 KB. This default size limit applies to new installations and to upgrades from Exchange 2000 Server in which no message size limit was set.

You can conserve system resources by setting message size limits that prevent users from sending and receiving large e-mail messages. This will help limit network traffic, save disk space, and improve overall network performance. For Exchange 2000 Server and Exchange Server 2003, you can use the Defaults tab in Message Delivery Properties of your Global Settings to specify message delivery restrictions for incoming and outgoing messages. To set the maximum individual message size, select Maximum (KB), and then in the text box, type a maximum size, in kilobytes (KB). If you do not want to limit the size of messages, select No limit. Senders in your organization receive an NDR if they try to send a message to a user who goes beyond the specified size limit. Depending on the NDR settings that you configure in Internet Message Formats, external senders may or may not receive an NDR.

For Exchange Server 2007, you can use the Exchange Management Shell to set the TransportConfig MaxSendSize parameter for your Exchange organization.

It is recommended that you set the maximum message size limit to no more than 10 MB. However, if you need a higher message size limit for messages with large attachments to be sent through your Exchange organization, you may want to increase the maximum outgoing message size limit to 30 MB. Increasing the message size limit over 30 MB can slow down your network performance and even cause your system to be more vulnerable to security attacks.

To set message size limits for Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, expand Global Settings, right-click Message Delivery, and then click Properties.

  2. In the Message Delivery Properties dialog box, on the Defaults tab, select the Sending message size limit option and type the size limit you want.

To set message size limits for Exchange Server 2007

  1. In Exchange Management Shell, run the following command where <size> is entered as the default of "unlimited" or the size in B (Bytes), KB (Kilobytes), or MB (Megabytes) in a range of 0 to 2147483647 bytes:
Copy Code
Set-TransportConfig -MaxSendSize <size>

For example, to set the maximum message size that can be sent by users in the Exchange Organization to 10 Megabytes you would enter:

Copy Code
Set-TransportConfig -MaxSendSize 10MB

To set the maximum message size that can be sent by users in the Exchange Organization to the default value of unlimited you would enter:

Copy Code
Set-TransportConfig -MaxSendSize unlimited
  • For more details about setting message size limits for Exchange 2000 Server and Exchange Server 2003, see the Microsoft Knowledge Base article 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679).

  • For more information about the TransportConfig cmdlet for Exchange Server 2007, see "Set-TransportConfig" in the Exchange Server 2007 Technical Reference (http://go.microsoft.com/fwlink/?LinkID=79237).

  • For more information about Internet Message Formats, see the topic "Configuring SMTP Policies to Control Outbound Mail Formatting and Automatic Responses" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


Maximum outgoing message size is set too high (>30 MB)
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-12-04

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the global settings submissionContLength attribute located at:

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=OrganizationName, CN=Global Settings, CN=Message Delivery

If the Exchange Server Analyzer finds the value for the submissionContLength attribute to be greater than 30720, an error is displayed.

This error indicates that a maximum outgoing message size limit has been set to a value greater than 30 megabytes (MB). Based on network bandwidth and user requirements in your organization, you may want to limit the message size to smaller messages. In Exchange 2000 Server and Exchange Server 2007, there is no default message size limit. In Exchange Server 2003, the default size limit for sending and receiving messages is 10,240 KB. This default size limit applies to new installations and to upgrades from Exchange 2000 Server in which no message size limit was set.

You can conserve system resources by setting message size limits that prevent users from sending and receiving large e-mail messages. This will help to limit network traffic, save disk space, and improve overall network performance. For Exchange 2000 Server and Exchange Server 2003, you can use the Defaults tab in Message Delivery Properties of your Global Settings to specify message delivery restrictions for incoming and outgoing messages. To set the maximum individual message size, select Maximum (KB), and then in the text box, type a maximum size, in kilobytes (KB). If you do not want to limit the size of messages, select No limit. Senders in your organization receive an NDR if they try to send a message to a user who exceeds the specified size limit. Depending on the NDR settings that you configure in Internet Message Formats, external senders may or may not receive an NDR.

For Exchange Server 2007, you can use the Exchange Management Shell to set the TransportConfig MaxSendSize parameter for your Exchange organization.

It is recommended that you set the maximum message size limit to no more than 10 MB. However, if you need a higher message size limit for messages with large attachments to be sent through your Exchange organization, you may want to increase the maximum outgoing message size limit to 30 MB. Increasing the message size limit over 30 MB can slow down your network performance and even cause your system to be more vulnerable to security attacks.

To set message size limits for Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, expand Global Settings, right-click Message Delivery, and then click Properties.

  2. In the Message Delivery Properties dialog box, on the Defaults tab, select the Sending message size limit option and type the size limit you want.

To set message size limits for Exchange Server 2007

  1. In Exchange Management Shell, run the following command where <size> is entered as the default of "unlimited" or the size in B (Bytes), KB (Kilobytes), or MB (Megabytes) in a range of 0 to 2147483647 bytes:
Copy Code
Set-TransportConfig -MaxSendSize <size>

For example, to set the maximum message size that can be sent by users in the Exchange Organization to 10 Megabytes you would enter:

Copy Code
Set-TransportConfig -MaxSendSize 10MB

To set the maximum message size that can be sent by users in the Exchange Organization to the default value of unlimited you would enter:

Copy Code
Set-TransportConfig -MaxSendSize unlimited
  • For more details about setting message size limits for Exchange 2000 Server and Exchange Server 2003, see the Microsoft Knowledge Base article 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679).

For more information about the TransportConfig cmdlet for Exchange Server 2007, see "Set-TransportConfig" in the Exchange Server 2007 Technical Reference (http://go.microsoft.com/fwlink/?LinkID=79237).

  • For more information about Internet Message Formats, see the topic "Configuring SMTP Policies to Control Outbound Mail Formatting and Automatic Responses" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=21769).


Maximum outgoing message size may be set too low
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-12-04

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the global settings submissionContLength attribute located at:

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN= OrganizationName , CN=Global Settings, CN=Message Delivery

If the Exchange Server Analyzer finds the value for the submissionContLength attribute to be less than 1024 but greater than 0, a warning is displayed.

This warning indicates that a maximum outgoing message size limit has been set to less than 1 megabyte (MB). Based on network bandwidth and user requirements in your organization, you may want to increase the message size to allow for larger messages. In Exchange 2000 Server and Exchange Server 2007, there is no default message size limit. In Exchange Server 2003, the default size limit for sending and receiving messages is 10,240 KB. This default size limit applies to new installations and to upgrades from Exchange 2000 Server in which no message size limit was set.

You can conserve system resources by setting message size limits that prevent users from sending and receiving large e-mail messages. This will help limit network traffic, save disk space, and improve overall network performance. For Exchange 2000 Server and Exchange Server 2003, you can use the Defaults tab in Message Delivery Properties of your Global Settings to specify message delivery restrictions for incoming and outgoing messages. To set the maximum individual message size, select Maximum (KB), and then in the text box, type a maximum size, in kilobytes (KB). If you do not want to limit the size of messages, select No limit. Senders in your organization receive a non-delivery report (NDR) if they try to send a message to a user who goes beyond the specified size limit. Depending on the NDR settings that you configure in Internet Message Formats, external senders may or may not receive an NDR.

For Exchange Server 2007, you can use the Exchange Management Shell to set the TransportConfig MaxSendSize parameter for your Exchange organization.

It is recommended that you set the maximum message size limit to no more than 30 MB. However, if you need a higher message size limit for messages with large attachments to be sent through your Exchange organization, you may want to increase the maximum outgoing message size limit to more than 30 MB. Increasing the message size limit over 30 MB can slow down your network performance and even cause your system to be more vulnerable to security attacks.

To set message size limits for Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, expand Global Settings, right-click Message Delivery, and then click Properties.

  2. In the Message Delivery Properties dialog box, on the Defaults tab, select the Sending message size limit option and type the size limit you want.

To set message size limits for Exchange Server 2007

  1. In Exchange Management Shell, run the following command where <size> is entered as the default of "unlimited" or the size in B (Bytes), KB (Kilobytes), or MB (Megabytes) in a range of 0 to 2147483647 bytes:
Copy Code
Set-TransportConfig -MaxSendSize <size>

For example, to set the maximum message size that can be sent by users in the Exchange Organization to 10 Megabytes you would enter:

Copy Code
Set-TransportConfig -MaxSendSize 10MB

To set the maximum message size that can be sent by users in the Exchange Organization to the default value of unlimited you would enter:

Copy Code
Set-TransportConfig -MaxSendSize unlimited
  • For more details about setting message size limits for Exchange 2000 Server and Exchange Server 2003, see the Microsoft Knowledge Base article 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679).

For more information about the TransportConfig cmdlet for Exchange Server 2007, see "Set-TransportConfig" in the Exchange Server 2007 Technical Reference (http://go.microsoft.com/fwlink/?LinkID=79237).

  • For more information about Internet Message Formats, see the topic "Configuring SMTP Policies to Control Outbound Mail Formatting and Automatic Responses" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).


Message-only journaling is enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-10

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchMessageJournalRecipient attribute has been configured to copy mail to a recipient mailbox. The msExchMessageJournalRecipient attribute is an attribute of mailbox store objects in Active Directory. By default, the msExchMessageJournalRecipient attribute is not configured. If the Exchange Server Analyzer finds that the msExchMessageJournalRecipient attribute is configured, the Exchange Server Analyzer displays a non-default configuration message. The Exchange Server Analyzer also displays the database name and server name where message-only journaling is enabled.

Exchange Server 2003 Message-only journaling or Exchange Server 2007 Standard journaling creates a copy of all messages and the corresponding P2 message header data to and from users on a mailbox database and sends the message copy to a specified mailbox. The P2 message header contains only the message recipient data that the sender declared to the recipients. If an external message is received from the Internet, Exchange Server journals the P1 message headers. The P1 message header is the address information that is used by message transfer agents (MTAs) to route mail. By default, when message-only journaling is enabled, Exchange Server does not account for blind carbon copy (Bcc) recipients, recipients from transport forwarding rules, or recipients from distribution group expansions. Also, Exchange Server does not archive MAPI report messages, such as read receipts, and out-of-office notifications.

Journaling messages can consume many disk, network, and CPU resources. Therefore, journaling requires thorough deployment planning. Journaling should be enabled only in the context of an overall journaling solution framework.

Ignore this non-default configuration message if the following conditions are true:

  • Your business requires journaling.

  • You have deployed a journaling solution framework.

Otherwise, you should turn off journaling functionality.

To turn off message-only journaling on a database in Exchange 2000 Server and Exchange Server 2003

  1. In Exchange System Manager, expand Servers, expand <your Exchange server>, expand <storage group>, and then right-click the mailbox store.

  2. On the General tab, clear the check box Archive all messages sent or received by mailboxes on this store.

  3. Wait 15 minutes for the Exchange store to apply changes. You do not have to restart the Microsoft Exchange Information Store service.
To turn off standard journaling on a database Exchange Server 2007

  1. Follow the guidance in the Exchange Server 2007 product documentation How to Disable Per-Mailbox Database Journaling (http://go.microsoft.com/fwlink/?LinkId=80889).

For more information about how to deploy a journaling solution with Exchange Server 2003, see Journaling with Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47581).

For more information about how to deploy a journaling solution with Exchange Server 2007, see Overview of Journaling (http://go.microsoft.com/fwlink/?LinkId=80820).


Message routing loop may exist
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchAlternateServer attribute of each Simple Mail Transfer Protocol (SMTP) virtual server. The Exchange Server Best Practice Analyzer also determines whether the msExchNonAuthoritativeDomains attribute has been configured on any of the recipient policies in the organization. The Exchange Server Analyzer displays a warning if the following conditions exist:

  • Any instance of the msExchAlternateServer attribute has been set.

  • The msExchNonAuthoritativeDomains attribute has been set on any recipient policy.

The Exchange Server Analyzer displays a warning because the aforementioned configurations can cause message loops. Message loops can occur when different messaging systems are configured to operate together in a single organization. In this scenario, Exchange Server recipient policies and SMTP configurations are used to route and deliver messages for user groups that exist across heterogeneous messaging systems.

The msExchAlternateServer attribute is set when you specify an address in the Forward all mail with unresolved recipients to host field on an SMTP Virtual Server property page.

The msExchNonAuthoritativeDomains attribute is set when you clear the This Exchange Organization is responsible for all mail delivery to this address check box on the SMTP address properties page for a given recipient policy.

Therefore, if you specify an SMTP domain as non-authoritative by clearing the This Exchange Organization is responsible for all mail delivery to this address check box, and you have specified an address for unresolved recipients on any SMTP virtual server, the Exchange Server Analyzer displays a warning. However, it is important to note that the existence of this warning does not definitively indicate that a message loop is present in your organization.

If a non-authoritative domain exists and at least one server in the organization has msExchAlternateServer set, the potential for message routing loops exists. You should verify that the following conditions exist:

  • Authoritative domains exist for all domains in your organization.

  • Your SMTP virtual servers are configured so that authoritative domains are handling all unresolved messages.

Specifically, if you share a domain name with another organization, it is recommended that there is only one inbound path to that domain namespace. One mail server or one mail system should be authoritative for the domain, so looping does not occur. The authoritative server should be the last system on the inbound path.

It is not important which system is the initial receiver. It is not important if there are more than two initial receivers. It is important that only one system is the final destination.

To change the msExchAlternateServer attribute

  1. In Exchange System Manager, expand Servers, expand <Server Name>, expand Protocols, and then expand SMTP.

  2. Right-click your SMTP virtual server, and then click Properties.

  3. In the SMTP virtual server's Properties, click the Messages tab.

  4. In the Forward all messages with unresolved recipients to host box, type the FQDN of the server that will receive the unresolved mail. You may also enter the IP address of the server in square brackets ([ ]).

  5. Click OK.
To change the msExchNonAuthoritativeDomains attribute

  1. In Exchange System Manager, expand Recipients, and double-click <Recipient Policy Name>.

  2. On the E-Mail Addresses (Policy) tab, double-click an SMTP address.

  3. On the SMTP Address Properties page, a check in This Exchange Organization is responsible for all mail delivery to this address clears the msExchNonAuthoritativeDomains attribute. By clearing the check box, you set the msExchNonAuthoritativeDomains attribute with the SMTP address that is specified in the Address field.

For more information about sharing SMTP address spaces, see Microsoft Knowledge Base article 321721, "Sharing SMTP address spaces in Exchange 2000 Server and Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=321721).

For more information about deployment scenarios for Internet connectivity, see "Deployment Scenarios for Internet Connectivity" in the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


'Messages awaiting directory lookup' Queue is Frozen
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateFrozen key for the Simple Mail Transfer Protocol (SMTP) Messages awaiting directory lookup queue.

If the Exchange Server Analyzer finds that the value of the StateFrozen key for the Messages awaiting directory lookup queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

A frozen queue means the transport sessions for that queue are stopped. A frozen queue prevents outgoing messages, although new messages can be added. You can manually change the state of a connection by using the shortcut menu on each link queue. When you use the Force Connection command to change a queue state to Active, you immediately enable a connection that sends the messages from that queue.

The Messages awaiting directory lookup queue contains messages to recipients that have not yet been resolved against the Active Directory® directory service. Messages are also held in the queue while distribution lists are expanded.

Generally, messages accumulate in this queue because the advanced queuing engine is unable to categorize the message. The advanced queuing engine may not be able to access the global catalog servers and access recipient information, or the global catalog servers are unreachable or performing slowly. In addition, messages can accumulate for the following reasons:

  • Active Directory is unavailable.

    Note:
    The categorizer uses Active Directory to categorize messages.
  • Active Directory may be too heavily loaded if many messages are queuing in the pre-categorization queue.

  • There is a failure in conversion. The categorizer also handles content conversion.

  • The message categorizer cannot find the mailbox stores.

  • If SMTP was reinstalled or removed, this may invalidate the following IIS metabase keys: /smtpsvc/DsUseCat and /smtpsvc/vsi#/DsUseCat.

    Note:
    Determine whether SMTP was reinstalled or removed.

To resolve this error, increase diagnostic logging for the MSExchangeDSAccess service and for the MSExchangeTransport service to collect information about Categorizer components.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


'Messages awaiting directory lookup' Queue is in Retry
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateRetry key for the Simple Mail Transfer Protocol (SMTP) Messages awaiting directory lookup queue.

If the Exchange Server Analyzer finds that the value of the StateRetry key for the Messages awaiting directory lookup queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

If a queue is in retry status, this status indicates that at least one error occurred in the previous attempts to process the messages in the queue. You can change queues in the Retry or Scheduled state to Active with the Force Connection command. This causes the queue to function as if the retry interval had passed or the scheduled time was reached. However, this method may not always work.

Note:
The properties of a queue can indicate a specific reason for a queue to be in Retry.

The Messages awaiting directory lookup queue contains messages to recipients that have not yet been resolved against the Active Directory® directory service. Messages are also held in the queue while distribution lists are expanded.

Generally, messages accumulate in this queue because the advanced queuing engine is unable to categorize the message. The advanced queuing engine may not be able to access the global catalog servers and access recipient information, or the global catalog servers are unreachable or performing slowly. In addition, messages can accumulate for the following reasons:

  • Active Directory is unavailable.

    Note:
    The categorizer uses Active Directory to categorize messages.
  • Active Directory may be too heavily loaded if many messages are queuing in the pre-categorization queue.

  • There is a failure in conversion. The categorizer also handles content conversion.

  • The message categorizer cannot find the mailbox stores.

  • If SMTP was reinstalled or removed, this may invalidate the following IIS metabase keys: /smtpsvc/DsUseCat and /smtpsvc/vsi#/DsUseCat.

    Note:
    Determine whether SMTP was reinstalled or removed.

To resolve this error, examine the properties of the queue to determine why the queue is in retry status. For example, if the queue properties display a message that resembles "An SMTP error has occurred," you should review your server's event logs to locate any SMTP errors. If there are no events in the log, you should increase the SMTP Protocol logging level.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


'Messages Pending Submission' Queue is Frozen
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-16

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateFrozen key for the Simple Mail Transfer Protocol (SMTP) Messages Pending Submission queue.

If the Exchange Server Analyzer finds that the value of the StateFrozen key for the Messages Pending Submission queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

A frozen queue means the transport sessions for that queue are stopped. A frozen queue prevents outgoing messages, although new messages can be added. You can manually change the state of a connection by using the shortcut menu on each link queue. When you use the Force Connection command to change a queue state to Active, you immediately enable a connection that sends the messages from that queue.

The Messages Pending Submission queue holds messages that have been acknowledged and accepted by the SMTP service.

Messages that are in this queue have not been processed. If messages constantly accumulate, you may have a performance problem. Occasional peaks in CPU performance can cause messages to appear in this queue intermittently. Frequently, problems with event sinks, for example, custom SMTP processing code for antivirus screening and for disclaimers, cause messages to accumulate in this queue.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


'Messages Pending Submission' Queue is in Retry
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateRetry key for the Simple Mail Transfer Protocol (SMTP) Messages Pending Submission queue.

If the Exchange Server Analyzer finds that the value of the StateRetry key for the Messages Pending Submission queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

If a queue is in retry status, this status indicates that at least one error occurred in the previous attempts to process the messages in the queue. You can change queues in the Retry or Scheduled state to Active with the Force Connection command. This causes the queue to function as if the retry interval had passed or the scheduled time was reached. However, this method may not always work.

Note:
The properties of a queue can indicate a specific reason for a queue to be in Retry.

The Messages Pending Submission queue holds messages that have been acknowledged and accepted by the SMTP service.

Messages that are in this queue have not been processed. If messages are constantly accumulating, you may have a performance problem. Occasional peaks in CPU performance can cause messages to appear in this queue intermittently. Frequently, problems with event sinks, for example, custom SMTP processing code for antivirus screening and for disclaimers, cause messages to accumulate in this queue.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


'Messages waiting to be routed' Queue is Frozen
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateFrozen key for the Simple Mail Transfer Protocol (SMTP) Messages waiting to be routed queue.

If the Exchange Server Analyzer finds that the value of the StateFrozen key for the Messages awaiting directory lookup queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

A frozen queue means the transport sessions for that queue are stopped. A frozen queue prevents outgoing messages, although new messages can be added. You can manually change the state of a connection by using the shortcut menu on each link queue. When you use the Force Connection command to change a queue state to Active, you immediately enable a connection that sends the messages from that queue.

The Messages waiting to be routed queue holds messages until their next-destination server is determined, and then moves them to their respective link queues.

Messages accumulate in this queue if Exchange Server routing problems exist. Message routing may be backed up.

To resolve this error, increase diagnostic logging for the MSExchangeDSAccess service and for the MSExchangeTransport service to collect information about categorizer components.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


'Messages waiting to be routed' Queue is in Retry
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateRetry key for the Simple Mail Transfer Protocol (SMTP) Messages waiting to be routed queue.

If the Exchange Server Analyzer finds that the value of the StateRetry key for the Messages awaiting directory lookup queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

If a queue is in retry status, this status indicates that at least one error occurred in the previous attempts to process the messages in the queue. You can change queues in the Retry or Scheduled state to Active with the Force Connection command. This causes the queue to function as if the retry interval had passed or the scheduled time was reached. However, this method may not always work.

Note:
The properties of a queue can indicate a specific reason for a queue to be in Retry.

The Messages waiting to be routed queue holds messages until their next-destination server is determined and then moves them to their respective link queues.

Messages accumulate in this queue if Exchange Server routing problems exist. Message routing may be backed up.

To resolve this error, increase diagnostic logging for the MSExchangeTransport service to collect information about Categorizer components. Disable any unnecessary connector restrictions because the restrictions can cause a significant degradation in server performance. You may have to turn on the CheckConnectorRestrictions registry key for some restrictions.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


Missing Transport Event Sink Binding
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-01-11

The Microsoft® Exchange Server Analyzer Tool queries the Microsoft Internet Information Server (IIS) metabase to enumerate the list of Simple Mail Transport Protocol (SMTP) transport event sink bindings. The Exchange Server Analyzer tries to locate several standard event bindings, based on the following list that is pre populated in the Exchange Server Analyzer:

  • Custom Exchange DSN Sink

  • EHLO Inbound Command Handler Sink for XLSA

  • EHLO Response Handler Sink for X-LSA

  • EOD Inbound Command Handler Sink

  • Exchange Categorizer

  • Exchange LoadBalancer

  • Exchange NTFS Store Driver

  • Exchange Router

  • Exchange SMTP Protocol Logging Sink

  • Exchange SMTP Protocol Security EHLO Sink

  • Exchange SMTP Protocol Security EXPS Sink

  • Exchange SMTP Protocol Security EXPS-Aux Sink

  • Exchange SMTP Protocol Security EXPS-EOD Sink

  • Exchange SMTP Protocol Security Mail Sink

  • Exchange SMTP Protocol XEXCH50 Before Data Sink

  • Exchange SMTP Protocol XEXCH50 EHLO Response Sink

  • Exchange SMTP Protocol XEXCH50 EOD Sink

  • Exchange SMTP Protocol XEXCH50 Inbound EHLO Sink

  • Exchange SMTP Protocol XEXCH50 Inbound MAIL Sink

  • Exchange SMTP Protocol XEXCH50 Inbound RCPT Sink

  • Exchange SMTP Protocol XEXCH50 Inbound XEXCH50 Sink

  • Exchange SMTP Protocol XEXCH50 per recipient event Sink

  • Exchange SMTP Protocol XEXCH50 RCPT Response Sink

  • Exchange SMTP Protocol XEXCH50 Response Sink

  • Exchange Store Driver

  • Exchange Transport AntiVirus API

  • Exchange Transport XEXCH50 Submission Sink

  • MAIL Inbound Command Handler Sink for TURF

  • Mobile Categorizer

  • MSExchange Content Filter EOD Sink

  • MsgTrackLog Sink

  • RCPT Inbound Command Handler Sink

  • SMTP Eventlog Sink

  • UmConvSink

  • X-LSA Inbound Command Handler Sink

  • X-LSA Response Handler Sink

  • X-LSA Sink

If the Exchange Server Analyzer finds that one or more standard event bindings are missing, the Exchange Server Analyzer generates a warning.

An SMTP transport event occurs when message data is transported into or out of the SMTP service. All messages go through events. These include X.400 and RPC incoming or outgoing messages. One common example of an inbound transport event is the arrival of a message to the SMTP service either over the network or in the SMTP pickup directory. When this transport event occurs, a source for this event notifies the transport event sinks, each of which can take some type of action based on the data content of the message. The system performs no other action with the message data after it passes the message data to the sink until the sink completes its action and returns the message. The sink has exclusive control of the message data and state while it performs this action.

Missing transport event sink bindings can cause mail flow problems. If the Exchange Server shows symptoms of mail flow problems such as message queuing, reregister the transport event sinks.

To reregister the transport event sinks

  1. From the Microsoft Exchange Server, open a Command Prompt window and change to the \Program Files\Exchsrvr\Bin folder.

  2. Type the following commands to reregister transport event sinks:

    regsvr32 /i exps.dll

    regsvr32 /i miscat.dll

    regsvr32 /i onsubmit.dll

    regsvr32 /i peexch50.dll

    regsvr32 /i phatcat.dll

    regsvr32 /i protolog.dll

    regsvr32 /i reapi.dll

    regsvr32 /i regsinks.dll

    regsvr32 /i tranmsg.dll

    regsvr32 /i turflist.dll

    regsvr32 /i xlsasink.dll

    regsvr32 /i msgfilter.dll

  3. Rerun the Exchange Server Analyzer to verify that the warnings are no longer present. If event sink warnings continue to occur and you experience mail flow problems, contact Microsoft Product Support Services (PSS).

For more information about transport event sink bindings see the following Exchange resources:

  • Microsoft Knowledge Base article 258224, "XCON: Enumerating the Registered Transport Event Sinks" (http://go.microsoft.com/fwlink/?linkID=3052&kbid=258224)

  • "SMTP Service Design" in the Technical Reference Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=58876)


msExchAlternateServer attribute has been set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the msExchAlternateServer attribute of each Simple Mail Transfer Protocol (SMTP) virtual server. By default, the msExchAlternateServer attribute value is not set. If the Exchange Server Analyzer finds that the msExchAlternateServer attribute has been set, the Exchange Server Analyzer displays a non-default configuration message.

You would set the msExchAlternateServer attribute in the following example scenario. You share an SMTP address space, such as an SMTP domain, between Exchange Server 2003 and another e-mail system. In this scenario, Exchange Server 2003 accepts incoming mail from the Internet. Exchange Server 2003 looks for a matching recipient in the Exchange Server organization. If a match is not found, Exchange Server forwards the mail to the foreign mail system. The receiving system also may look for a match. If a match is not found, it may forward the mail to a third e-mail system. The final system in the chain must be authoritative for the domain. The final receiving system must look for a matching recipient. If a matching recipient is not found, a non-delivery report (NDR) must be generated for the message. If a receiving system looks for a match and then forwards the message back to the original system when a match is not found, looping messages occur.

To change the msExchAlternateServer attribute

  1. In Exchange System Manager, expand Servers, expand <Server Name>, expand Protocols, and then expand SMTP.

  2. Right-click your SMTP virtual server, and then click Properties.

  3. In the SMTP virtual server's Properties, click the Messages tab.

  4. In the Forward all messages with unresolved recipients to host box, type the FQDN of the server that will receive the unresolved mail. You may also enter the IP address of the server in square brackets ([ ]).

  5. Click OK.

For more information about sharing SMTP address spaces, see Microsoft Knowledge Base article 321721, "Sharing SMTP address spaces in Exchange 2000 Server and Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=321721).

For more information about deployment scenarios for Internet connectivity, see "Deployment Scenarios for Internet Connectivity" in the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


The msExchMaxIncomingConnections value has been changed from its default setting
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the configured value for the msExchSmtpMaxIncomingConnections attribute of each SMTP virtual server.

By default, on an Exchange Server computer that is not part of a Microsoft Windows® Small Business Server 2003 installation, the msExchSmtpMaxIncomingConnections attribute is configured for an unlimited number of connections, as represented by a default value of 2000000000 for this attribute. On an Exchange Server computer that is a part of a Microsoft Windows Small Business Server 2003 installation, the default maximum number of incoming connections is 500.

The Exchange Server Analyzer also queries the Win32_OperatingSystem Windows Management Instrumentation (WMI) class to determine the value of the OSProductSuite key. The value of this key corresponds to a specific version of a Windows Server operating system.

If the Exchange Server Analyzer finds that the msExchSmtpMaxIncomingConnections attribute on an Exchange Server computer that is not part of a Microsoft Windows Small Business Server 2003 installation does not have a value of 2000000000, a non-default configuration message is displayed. The value of 2000000000 used for this attribute is both a theoretical limit, and the limit imposed on the user interface elements that let you configure this value.

Alternatively, if the Exchange Server Analyzer finds that the msExchSmtpMaxIncomingConnections attribute on an Exchange Server computer that is a part of a Microsoft Windows Small Business Server 2003 installation does not have a value of 500, a non-default configuration message is displayed.

From a security perspective, limiting the number of incoming connections may make sense. The capability of accepting an essentially unlimited number of incoming SMTP connections could lend itself to a denial of service situation. Too many simultaneous connections to the virtual server can overload your network and cause poor performance. Each organization should decide for itself what an appropriate value for this attribute is.

To view or configure the maximum number of incoming connections

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server), and then click Properties.

  4. Click General:

    • To limit the number of incoming connections, select the Limit number of connections to check box and enter the value that you want.

    • To revert to the default of unlimited incoming connections, clear the Limit number of connections to check box.

  5. Click OK to save the changes.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" at (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The msExchSmtpMaxHopCount value has been altered from its default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpMaxHopCount attribute has been changed from its default value.

In Exchange 2000 Server, the msExchSmtpMaxHopCount attribute is configured with a default value of 15. In Exchange Server 2003, this attribute has a default value of 30. If the Exchange Server Analyzer finds that this attribute is no longer set to the default setting, a non-default configuration message is displayed.

A message can be routed through many different SMTP servers (each referred to as a hop) before the message reaches its final destination. To prevent a message from being repeatedly misrouted (a condition known as a message loop) an administrator can control the maximum number of hops that is allowed. The mxExchSmtpMaxHopCount attribute specifies the number of SMTP servers through which a message can pass before returned to the sender as non-deliverable.

A value of 30 for both Exchange 2000 Server and Exchange Server 2003 SMTP virtual servers is recommended.

To correct this error

  1. In Exchange System Manager, expand Servers, then expand an Exchange server, then expand Protocols, then expand SMTP.

  2. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and select Properties.

  3. Select the Delivery tab, and then click Advanced.

  4. Enter the desired value in the Maximum hop count field and click OK to save the change.

  5. Click OK to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The msExchSmtpMaxMessageSize value has been altered from its default of 0
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine if the value for the msExchSmtpMaxMessageSize attribute has been altered from the default value of 0. By default, the msExchSmtpMaxMessageSize attribute is configured for unlimited message size. If the Exchange Server Analyzer finds that this attribute does not have a value of 0, and Exchange is not running on Microsoft Windows® Small Business Server 2003, a warning message is displayed.

The msExchSmtpMaxMessageSize attribute represents the maximum size of each SMTP message that can be sent or received. From a security perspective, limiting the maximum size of SMTP messages that can be sent to and received from the Internet is a best practice. However, for internal SMTP messages, such as those that travel between Exchange servers in the same organization, it is recommended that you leave the msExchSmtpMaxMessageSize attribute set to 0.

Internally, Exchange uses SMTP messages to handle tasks such as public folder replication. If the msExchSmtpMaxMessageSize attribute is configured with too low a limit, it could cause public folder replication problems and other intra-organizational message delivery failures.

If this Exchange server is a bridgehead server that transfers SMTP messages to and from the Internet, you may be able to safely ignore this warning. If this Exchange server handles internal SMTP messages, you should change the value for the msExchSmtpMaxMessageSize attribute back to its default setting of 0.

Note:
If you set the message size limit too low, it could prevent offline address book replication between Exchange Server computers. For more information about this issue, see the Microsoft Knowledge Base article 326154, "XADM: The OAB Does Not Replicate If You Set a Message Size Restriction at the Transport Level," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=326154).

To view and configure the maximum SMTP message size

  1. In Exchange System Manager, expand Servers, then expand an Exchange server, then expand Protocols, then expand SMTP.

  2. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and select Properties.

  3. Select the Messages tab.

  4. To revert back to the default setting of 0, clear the Limit message size to (KB) check box. Alternatively, leave this box checked and configure any value that you want.

  5. Click OK to save the changes and to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The msExchSmtpMaxOutboundMsgPerDomain value has been changed from its default of 20
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpMaxOutboundMsgPerDomain attribute has been changed from the default value of 20. By default, the msExchSmtpMaxOutboundMsgPerDomain attribute is configured for a maximum of 20 outbound SMTP messages per connection. If the Exchange Server Analyzer finds that this attribute does not have a value of 20, a non-default configuration message is displayed.

The msExchSmtpMaxOutboundMsgPerDomain attribute represents the maximum number of messages per connection that can be sent by an SMTP virtual server on the Exchange server. For example, if an SMTP server has 35 messages to send to microsoft.com and the msExchSmtpMaxOutboundMsgPerDomain attribute is set at 20, two connections to the mail servers responsible for microsoft.com messages will be made. The first connection will send the maximum 20 messages, and a second connection will be made to send the remaining 15 messages.

Generally, there is no best practices recommendation for determining the correct value for this attribute. Each organization must determine for itself the appropriate value to set.

To set a maximum number of messages per connection

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and then click Properties.

  4. Click Messages.

  5. The current value for the msExchSmtpMaxOutboundMsgPerDomain attribute is listed in the Limit number of connections to field. Change this field as needed, and then click OK to save your changes. Accepted values for this field include any whole number between 1 and 1999999999..

  6. Click OK to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The msExchSmtpMaxOutgoingConnections value has been altered from its default of 1000
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpMaxOutgoingConnections attribute has been altered from the default value of 1000. By default, the msExchSmtpMaxOutgoingConnections attribute is configured for a maximum of 1000 outbound Simple Mail Transfer Protocol (SMTP) connections. If the Exchange Server Analyzer finds that this attribute does not have a value of 1000, a non-default configuration message is displayed.

The msExchSmtpMaxOutgoingConnections attribute represents the maximum number of outbound connections that can be made by an SMTP virtual server on the Exchange server.

Generally, there is no best practices recommendation for determining the correct value for this attribute. Each organization must determine for itself the appropriate value to set. That said, the default value may be too high for some organizations. You can monitor and determine the actual number of SMTP outbound connections made by an Exchange SMTP virtual server by collecting the following performance counters on your Exchange server:

Object | Counter | Explanation
SMTP Server | Outbound Connections Current | The number of connections currently outbound.
SMTP Server | Outbound Connections Total | The total number of outbound connections attempted.

If your organization does not make extensive use of outgoing SMTP on this Exchange server, consider lowering the value for this attribute. Lowering the maximum number of simultaneous outbound SMTP connections that can be made at any time could potentially slow any spikes in SMTP server activity that may be caused by incorrect configuration, innocent mistake, malicious activity, a message loop or other malfunction, or a virus outbreak or security breach.

To view and configure the outgoing connections limit

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and then click Properties.

  4. Click Delivery, and then click Outbound Connections.

  5. The current value for the msExchSmtpMaxOutgoingConnections attribute is listed in the Limit number of connections to field. Change this field as needed, and then click OK to save your changes. Accepted values for this field include any whole number between 1 and 1999999999.

  6. Click OK to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The msExchSmtpMaxOutgoingConnectionsPerDomain value has been changed from its default of 100
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpMaxOutgoingConnectionsPerDomain attribute has been changed from the default setting. The msExchSmtpMaxOutgoingConnectionsPerDomain attribute represents the maximum number of outbound connections per domain that can be made by an SMTP virtual server on the Microsoft Exchange server. By default, on an Exchange Server computer that is not part of a Microsoft Windows® Small Business Server 2003 installation, the msExchSmtpMaxOutgoingConnectionsPerDomain attribute is configured with a default value of 100. On an Exchange Server computer that is a part of a Windows Small Business Server 2003 installation, the default maximum number of outgoing connections per domain is 10.

The Exchange Server Analyzer also queries the Win32_OperatingSystem Windows Management Instrumentation (WMI) class to determine the value if the OSProductSuite key. The value of this key corresponds to a specific version of a Windows Server operating system.

If the Exchange Server Analyzer finds that the msExchSmtpMaxOutgoingConnectionsPerDomain attribute on an Exchange Server computer that is not part of a Windows Small Business Server 2003 installation does not have a value of 500, a non-default configuration message is displayed.

Alternatively, if the Exchange Server Analyzer finds that the msExchSmtpMaxOutgoingConnectionsPerDomain attribute on an Exchange Server computer that is a part of a Microsoft Windows Small Business Server 2003 installation does not have a value of 10, a non-default configuration message is displayed.

Generally, there is no best practices recommendation for determining the correct value for this attribute. Each organization needs to determine the appropriate value to set. That said, the default value may be too high for some organizations. You can monitor and determine the actual number of SMTP outbound connections made by an Exchange SMTP virtual server by collecting the following performance counters on your Exchange server:

Object | Counter | Explanation
SMTP Server | Outbound Connections Current | The number of connections currently outbound.
SMTP Server | Outbound Connections Total | The total number of outbound connections attempted.

If your organization does not extensively use outgoing SMTP on this Exchange server, consider lowering the value for this attribute. Lowering the maximum number of simultaneous outbound SMTP connections that can be made at any given time could potentially slow any spikes in SMTP server activity that may be caused by incorrect configuration, innocent mistake, malicious activity, a message loop or other malfunction, or a virus outbreak or security breach.

To view and configure the per-domain outgoing connections limit

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server), and then click Properties.

  4. Click Delivery, and then click Outbound Connections.

  5. The current value for the msExchSmtpMaxOutgoingConnectionsPerDomain attribute is listed in the Limit number of connections per domain to field. Change this field as you want and click OK to save your changes. Accepted values for this field include any whole number between 1 and 1999999999.

  6. Click OK to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The msExchSmtpMaxRecipients value has been altered from its default of 64000
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpMaxRecipients attribute has been changed from the default value of 64000. By default, the msExchSmtpMaxRecipients attribute is configured for 64,000 recipients. If the Exchange Server Analyzer finds that this attribute does not have a value of 64000, a non-default configuration message is displayed.

From a security perspective, limiting the maximum size of recipients for each message is a best practice. Each organization should determine for itself what an acceptable value is. Unless you have a reason to configure this value otherwise, it is recommended that you leave the msExchSmtpMaxRecipients attribute set at its default of 64000.

To view and configure the maximum number of recipients

  1. In Exchange System Manager, expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  2. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and then select Properties.

  3. Select the Messages tab.

  4. To revert to the default setting of 64000, make sure that the Limit number of recipients per message check box is selected and enter a value of 64000. Alternatively, you can configure this field with any value that you want, or clear the check box to allow an unlimited number of recipients.

  5. Click OK to save the changes and to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The msExchSmtpMaxSessionSize value has been altered from its default of 0
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine if the configured value for the msExchSmtpMaxSessionSize attribute has been altered from the default value of 0. By default, the msExchSmtpMaxSessionSize attribute is configured for unlimited message size. If the Exchange Server Analyzer finds that this attribute does not have a value of 0, a warning message is displayed.

The msExchSmtpMaxSessionSize attribute represents the maximum amount of data in kilobytes (KB) that will be accepted for each SMTP session. From a security perspective, limiting the size of SMTP sessions for messages sent to and received from the Internet is a best practice. However, for internal SMTP sessions, such as those between Exchange servers in the same organization, it is recommended that you leave the msExchSmtpMaxSessionSize attribute set at 0.

Internally, Exchange uses SMTP messages to handle tasks such as public folder replication. If the msExchSmtpMaxSessionSize attribute is configured with too low a limit, it could cause public folder replication problems and other intra-organizational message delivery failures.

If this Exchange server is a bridgehead server that transfers SMTP messages to and from the Internet, you can safely ignore this warning. If this Exchange server handles internal SMTP messages, you should change the value for the msExchSmtpMaxSessionSize attribute back to its default setting of 0.

To view and configure the maximum SMTP session size

  1. Open Exchange System Manager.

  2. Expand Servers, then expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, default SMTP virtual server) and then click Properties.

  4. Click Messages.

  5. To revert to the default setting of 0, clear the Limit session size to (KB) check box. Alternatively, leave this box checked and configure any desired value.

  6. Click OK to save the changes and to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The msExchSmtpOutgoingPort value has been altered from its default of 25
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpOutgoingPort attribute has been altered from the default value of 25. By default, the msExchSmtpOutgoingPort attribute is configured for TCP port 25. If the Exchange Server Analyzer finds that this attribute is configured for a port other than 25, a warning is displayed.

By default, Simple Mail Transfer Protocol (SMTP) servers are configured to accept inbound connections on TCP port 25. The msExchSmtpOutgoingPort parameter represents the TCP port to which this Exchange server will attempt to connect on all remote SMTP servers. If the remote SMTP servers have not been configured to listen on this port, a connection cannot be made.

Unless some, or your entire internal messaging infrastructure has been modified to use non-standard ports, it is recommended that you use TCP port 25 for all SMTP communication.

To view or change the default outgoing SMTP port

  1. In Exchange System Manager, expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  2. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and click Properties.

  3. Click Delivery, and then click Outbound Connections.

  4. In the TCP port field, enter the port you want to use for outbound connections. Every remote SMTP with which you want to communicate must be configured to accept connections on the specified port. In most cases, you will not want to change this value.

  5. Change this field as needed, and then click OK to save your changes.

  6. Click OK to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The msExchSmtpRelayForAuth value has been changed from its default of True
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpRelayForAuth attribute has been changed from the default value. By default, the msExchSmtpRelayForAuth attribute is configured with a value of True. If the Exchange Server Analyzer finds that the msExchSmtpRelayForAuth attribute does not have a value of True, a non-default configuration message is displayed.

When this value is set to True, only authenticated SMTP connections can relay SMTP messages through this SMTP virtual server. If this setting has been changed to False, this indicates that the check box for "Allow all computers which successfully authenticate to relay, regardless of the list above" in the Relay settings on the SMTP virtual server Properties dialog box, is clear.

Relaying is the action of an inbound connection to your SMTP server being used to send e-mail messages to external domains. With unsolicited commercial e-mail messages, sending a single e-mail message to your SMTP server with multiple recipients in domains external to your organization does this. Because the default setting for SMTP servers is to use anonymous authentication, the system being used to propagate the unsolicited commercial e-mail messages accepts the inbound message as typical.

After the message is accepted, the SMTP server recognizes that the message recipients belong to external domains, and then the SMTP server delivers the messages. Therefore, the unauthorized users who send unsolicited commercial e-mail messages only have to send one inbound message to your SMTP server so that it can then be delivered to thousands of recipients, which slows down your Exchange Server computer's responsiveness, congests queues, and causes dissatisfaction to the recipients when the messages arrive in their Inboxes.

The primary means of controlling relaying is by not granting relay permissions to any other hosts. However, sometimes relaying is required. For example, if you have Post Office Protocol (POP3) and Internet Message Access Protocol (IMAP4) clients who rely on SMTP for message delivery and have legitimate reasons for sending e-mail messages to external domains. You can work around this issue by creating a second SMTP virtual server that is dedicated to receiving e-mail messages from POP3 and IMAP4 clients. This additional SMTP virtual server can use authentication combined with Secure Sockets Layer (SSL)-based encryption and can be configured to enable relaying for authenticated clients. For more information about implementing this configuration, see the Microsoft Knowledge Base article 319267, "HOW TO: Secure Simple Message Transfer Protocol Client Message Delivery in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319267).

To view or modify the msExchSmtpRelayForAuth value in System Manager

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and click Properties.

  4. Select the Access tab, and then click Relay.

  5. Clear or select the Allow all computers which successfully authenticate to relay, regardless of the list above check box.

  6. Click OK to save the changes.

If the box is checked, the msExchSmtpRelayForAuth attribute should be set to True. If the box is clear, the msExchSmtpRelayForAuth attribute should be set to False.

For additional information about controlling which accounts can relay messages, see the following Microsoft Knowledge Base articles:

  • 818778, "Users Without Permissions to Relay Messages Can Still Send Messages Through the SMTP Virtual Server," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=818778)

  • 310380, "HOW TO: Prevent Exchange 2000 from Being Used as a Mail Relay in Windows 2000," (http://go.microsoft.com/fwlink/?linkid=3052&kbid=310380)


The msExchSmtpSmartHostType value has been altered from its default of 0
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpSmartHostType attribute has been changed from the default value of 0. By default, the msExchSmtpSmartHostType attribute is set to 0. If the Exchange Server Analyzer finds that this attribute does not have a value of 0, a non-default configuration message is displayed.

The msExchSmtpSmartHostType attribute indicates whether an SMTP virtual server is configured to use a smart host for delivering messages. You can route all outgoing messages for remote domains through a smart host, instead of sending those messages directly to the recipient domains. When Exchange is configured to use a smart host, the value for the msExchSmtpSmartHostType attribute is changed as detailed in the following table.

Smart host setting | msExchSmtpSmartHostType attribute value
No smart host | 0
Smart host | 2
Smart host with direct delivery attempted first | 1

On Exchange Server 2003 computers, this value will be either 0 or 2. On Exchange 2000 Server computers, the value can be 0, 1, or 2. A value of 1 is set when the Attempt direct delivery before sending to smart host check box is checked. This check box is only on Exchange 2000 Server computers. Exchange Server 2003 does not include this check box.

Unless you have a specific reason to do this, it is recommended that you leave the msExchSmtpSmartHostType attribute at its default setting of 0.

If your environment requires a smart host, and you have (or are planning to have) more than one Exchange Server computer in your environment, it is recommended that you use an SMTP Connector for any smart host entries. This way all your internal mail is routed by Exchange Server and only your external mail will be routed through the smart host.

To view and configure smart host settings

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and select Properties.

  4. Select the Delivery tab, and then click Advanced.

  5. Enter the smart host you want to use. You can identify the smart host by the fully qualified domain name or by an IP address. If you use an IP address, you must enclose it in brackets ([ ]). Exchange checks first for a server name, and then for an IP address. The brackets identify the value as an IP address; therefore, the DNS lookup is bypassed.

  6. If this is an Exchange 2000 Server computer, optionally select the Attempt direct delivery before sending to smart host check box.

  7. Click OK to save the changes, and then click OK to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=268163)


MTA Stacks service is configured to interact with desktop
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the DesktopInteract property for the Microsoft Exchange MTA Stacks (MSExchangeMTA) service. If the Exchange Server Analyzer finds that the MTA service is configured to interact with the desktop, the Exchange Server Analyzer displays an error.

This configuration should only be used under the guidance of Microsoft Product Support Services (PSS). Unless PSS has instructed you to run the MTA service in this configuration, it is recommended that you re-configure the MTA Stacks service properties so that it does not interact with the desktop.

To configure the Exchange MTA Stacks service account

  1. Open the Services MMC snap-in.

  2. Locate and stop the Microsoft Exchange MTA Stacks service.

  3. Double-click the Microsoft Exchange MTA Stacks service.

  4. On the Log On tab of the Microsoft Exchange MTA Stacks Properties page, select Local System account under Log on as.

  5. Clear the Allow service to interact with desktop check box, and then click Apply.

  6. Under Service status, click Start, and then click OK.

  7. Close the Services snap-in.

For more information about the correct Exchange service configuration, see Microsoft Knowledge Base article 239762, "Exchange Services Run Under LocalSystem" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762).


No 'Host' Records Found for 'MX' Records
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-03

The Microsoft® Exchange Server Analyzer Tool performs a Domain Name System (DNS) lookup to retrieve the Mail Exchanger (MX) records for a domain. If the MX records are successfully retrieved, the Exchange Server Analyzer then performs a DNS lookup to retrieve the Host (A) records of the servers that the MX records point to. If the DNS lookup operation does not return an IP address for any one of those Host (A) records, the Exchange Server Analyzer displays an error.

This error indicates that the DNS Host (A) record appears to be missing for the server. This error may cause messages destined for remote domains to back up in the Exchange server Remote Delivery queues. This error may also cause other routing or service delays.

The DNS lookup of the Host (A) record for an MX record can fail for the following reasons:

  • The DNS server is down or not responding because of a network failure or other reasons.

  • The Host (A) record for the remote server is missing from the DNS server because the record is unavailable or is incorrect.

  • The DNS server is not configured to enable dynamic host record updates.

To verify that the DNS server is online and that the Host record is present

  1. Verify that the DNS server is running by doing one or more of the following checks:

    • Look at the DNS server status from the DNS Administration program on the DNS server.

    • Restart the DNS server. For more information, see "Start, stop, pause, or restart a DNS server" (http://go.microsoft.com/fwlink/?LinkId=62999).

    • Verify the DNS server responsiveness by using the nslookup command. For more information, see "Verify DNS server responsiveness using the nslookup command" (http://go.microsoft.com/fwlink/?LinkId=63000).

  2. Use nslookup to verify that the Host (A) record exists on the DNS server. For more information, see "To verify A resource records exist in DNS" (http://go.microsoft.com/fwlink/?LinkId=63001).

  3. If the Host (A) resource record does not exist, manually add or modify the A resource record or configure the DNS server to enable dynamic record updates:

    • Manually add an A resource record. For more information, see "Add a resource record to a DNS zone" (http://go.microsoft.com/fwlink/?LinkId=63002).

    • Manually modify an A resource record. For more information, see "Modify an existing resource record" (http://go.microsoft.com/fwlink/?LinkId=63014).

    • Configure the DNS server to enable dynamic host record updates. For more information, see Microsoft Knowledge Base article 816592, "How to configure DNS dynamic updates in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592).

For More Information

  • For information about how Exchange Server 2003 uses DNS to resolve external IP addresses, see "Transport Dependencies for Exchange Server 2003" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • For information about DNS name resolution, see Microsoft Knowledge Base article 322856, "How to configure DNS to use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856).

  • For information about how to troubleshoot DNS, see "Troubleshooting DNS" (http://go.microsoft.com/fwlink/?LinkId=63003).

  • For information about Exchange Server 2003 system monitoring, see "Chapter 3: System Monitoring with Exchange Server 2003 Management Pack" in the Exchange Server 2003 Management Pack Guide for MOM 2000 SP1 (http://go.microsoft.com/fwlink/?LinkId=47573).

  • For information about Host (A) resource records, see "Managing Resource Records" (http://go.microsoft.com/fwlink/?LinkId=63004).


No 'Host' Records Found
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-04

The Microsoft® Exchange Server Analyzer Tool performs a Domain Name System (DNS) lookup to retrieve the Host (A) records of remote servers that the Exchange server is trying to send messages to. If the DNS lookup operation does not return an IP address, the Exchange Server Analyzer displays an error.

This error indicates that the DNS Host (A) record appears to be missing for the remote server. This error may cause messages to back up in the Exchange server Remote Delivery queues.

The DNS lookup of the Host (A) record from the remote server can fail for the following reasons:

  • The DNS server is down or not responding because of a network failure or other reasons.

  • The Host (A) record for the remote server is missing from the DNS server because the record is unavailable or is incorrect.

  • The DNS server is not configured to enable dynamic host record updates.

To verify that the DNS server is online and that the Host record is present

  1. Verify that the DNS server is running by doing one or more of the following checks:

    • Look at the DNS server status from DNS Administration program on the DNS server.

    • Restart the DNS server. For more information, see "Start, stop, pause, or restart a DNS server" (http://go.microsoft.com/fwlink/?LinkId=62999).

    • Verify the DNS server responsiveness by using the nslookup command. For more information, see "Verify DNS server responsiveness using the nslookup command" (http://go.microsoft.com/fwlink/?LinkId=63000).

  2. Use nslookup to verify that the Host (A) record exists on the DNS server. For more information, see "To verify A resource records exist in DNS" (http://go.microsoft.com/fwlink/?LinkId=63001).

  3. If the Host (A) resource record does not exist, manually add or modify the A resource record or configure the DNS server to enable dynamic record updates:

    • Manually add an A resource record. For more information, see "Add a resource record to a DNS zone" (http://go.microsoft.com/fwlink/?LinkId=63002).

    • Manually modify an A resource record. For more information, see "Modify an existing resource record" (http://go.microsoft.com/fwlink/?LinkId=63014).

    • Configure the DNS server to enable dynamic host record updates. For more information, see Microsoft Knowledge Base article 816592, "How to configure DNS dynamic updates in Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592).
  • For information about how Exchange Server 2003 uses DNS to resolve external IP addresses, see "Transport Dependencies for Exchange Server 2003" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • For information about DNS name resolution, see Microsoft Knowledge Base article 322856, "How to configure DNS to use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856).

  • For information about how to troubleshoot DNS, see "Troubleshooting DNS" (http://go.microsoft.com/fwlink/?LinkId=63003).

  • For information about Exchange Server 2003 system monitoring, see "Chapter 3: System Monitoring with Exchange Server 2003 Management Pack" in the Exchange Server 2003 Management Pack Guide for MOM 2000 SP1 (http://go.microsoft.com/fwlink/?LinkId=47573).

  • For information about Host (A) resource records, see "Managing Resource Records" (http://go.microsoft.com/fwlink/?LinkId=63004).


No 'MX' Records Found
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Domain Name System (DNS) servers it uses for the mail exchanger (MX) records of remote domains that Exchange sends to.

If the Exchange Server Analyzer cannot retrieve MX records for a remote domain from the DNS servers it uses, the Exchange Server Analyzer displays a warning.

This warning indicates that the DNS MX records appear to be missing for the remote domain.

To determine mail hosts, the sending Exchange server checks for an MX record. Next, the sending server resolves the MX record to an IP address by checking for an address (A) record.

If MX records for remote domains are missing, this may cause messages destined for the remote domains to back up in the Exchange server Remote Delivery queues in addition to other routing or service delays.

The DNS lookup of the MX records can fail if the DNS server is down or unreachable because of a network failure or for other reasons.

To verify that the DNS server is online and that the MX records are present

  1. Verify that the DNS server is running by doing one or more of the following checks:

    • Look at the DNS server status from the DNS Administration program on the DNS server.

    • Restart the DNS server. For more information, see "Start, stop, pause, or restart a DNS server" (http://go.microsoft.com/fwlink/?LinkId=62999).

    • Verify the DNS server responsiveness by using the nslookup command. For more information, see the instructions in "Verify DNS server responsiveness using the nslookup command" (http://go.microsoft.com/fwlink/?LinkId=63000).

  2. Use nslookup to verify that the MX records are configured correctly. For more information, see "How to Use Nslookup to Verify MX record configuration" in the "Verifying DNS Design and Configuration" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For More Information

  • For information about how Exchange Server 2003 uses DNS to resolve external IP addresses, see "Transport Dependencies for Exchange Server 2003" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • For information about DNS name resolution, see Microsoft Knowledge Base article 322856, "How to configure DNS to use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856).

  • For information about how to troubleshoot DNS, see "Troubleshooting DNS" (http://go.microsoft.com/fwlink/?LinkId=63003).

  • For information about Exchange Server 2003 system monitoring, see "Chapter 3: System Monitoring with Exchange Server 2003 Management Pack" in the Exchange Server 2003 Management Pack Guide for MOM 2000 SP1 (http://go.microsoft.com/fwlink/?LinkId=47573).


Nested distribution group found in delivery restrictions
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool queries the following attributes for each distribution group object in all domains found in the Active Directory® directory service to determine whether any of the groups are used to set delivery restrictions based on membership in the group:

dLMemRejectPermsBL | Contains the DNs of recipients or connectors that will not accept messages from this group.
dLMemSubmitPermsBL | Contains the DNs of recipients or connectors that will accept messages from this group.

If the Exchange Server Analyzer finds that there are group objects that are used to set delivery restrictions, the Exchange Server Analyzer examines those groups to determine whether they contain any nested groups.

The Exchange Server Analyzer also reads the following registry key to determine whether the RestrictionMethod registry value is present and how it is configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • Distribution Group membership is used to set delivery restrictions.

  • There are distribution groups nested in the distribution groups that have delivery restrictions set.

  • The RestrictionMethod registry value is present and not set to force flat restriction checking.

This error indicates that delivery restrictions based on distribution group membership may significantly affect Exchange mail flow performance.

The default behaviors for the categorizer is to recursively expand distribution groups and check restrictions for each message that passes through the system.

When you send mail to a user who accepts or denies messages from a distribution group or send mail that travels through a connector that accepts or denies message from a distribution group, the message categorizer has to expand the membership of the distribution group, obtain the full list of DNs of the members, and then compare the list of DNs to the list sender's DNs. An access operation or a deny operation occurs when a DN on both lists match. If a distribution group is nested in another distribution group, the nested distribution is also expanded.

The RestrictionMethod value determines how the categorizer will process restrictions. If you set the value of RestrictionMethod to 2, the transport components on this server that runs Exchange Server will not expand membership of distribution groups when the server checks restrictions. This configuration provides the best performance for restriction checks. Additionally, for the RestrictionMethod registry entry to take effect, all distribution groups that include users who have delivery restrictions must be flat. That is, the restricted distribution groups must not have nested distribution groups. The expansion logic will not work if the restricted distribution groups are nested.

For distribution groups that are used in connector restrictions, it is recommended that you set the RestrictionMethod registry entry value on a connector bridgehead server that has no mailboxes. For Active Directory user restrictions, if the restricted distribution groups have expansion servers, we recommend that you create the RestrictionMethod registry entry on the expansion servers.

To address this error:

  • Examine those users who have distribution group delivery restrictions set and remove unnecessary restrictions.

  • Configure individual mailboxes and not distribution groups for delivery restrictions as referenced in Microsoft Knowledge Base article 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

  • For servers that run Microsoft Exchange Server 2003 Service Pack 2 (SP2) or a later version, consider implementing non-hierarchal restriction checking. For servers that run Exchange versions earlier than Exchange 2003 SP2, consider upgrading to Exchange 2003 SP2.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To create the RestrictionMethod registry entry and set its value to 2

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters

  3. In the left pane, click Parameters.

  4. On the Edit menu, point to New, and then click DWORD Value.

  5. Type RestrictionMethod, and then press ENTER to name the new registry entry.

  6. Right-click RestrictionMethod and then click Modify.

  7. Type 2, and then press ENTER.

  8. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For More Information

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking.

For more information about the effect of distribution group restriction on Exchange mail flow, see the following Microsoft Knowledge Base articles:

  • 895407 "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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

  • 812298 "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

For more information about the RestrictionMethod registry value, see Microsoft Knowledge Base article 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

For more information about the registry value, see Microsoft Knowledge Base article 277872, "XCON: Connector Delivery Restrictions May Not Work Correctly" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872).


Nested distribution group found but flat restriction checking enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool queries the following attributes for each distribution group object in all domains found in the Active Directory® directory service to determine whether any of the groups are used to set delivery restrictions based on membership in the group:

dLMemRejectPermsBL | Contains the DNs of recipients or connectors that will not accept messages from this group.
dLMemSubmitPermsBL | Contains the DNs of recipients or connectors that will accept messages from this group.

If the Exchange Server Analyzer finds that there are group objects that are used to set delivery restrictions, the Exchange Server Analyzer then examines those groups to determine whether they contain any nested groups.

The Exchange Server Analyzer also reads the following registry key to determine whether the RestrictionMethod registry value is present and how it is configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • Distribution group membership is used to set delivery restrictions.

  • There are distribution groups nested in the distribution groups that have delivery restrictions set.

  • The RestrictionMethod registry value is present and set to force flat restriction checking.

This warning indicates that, although the RestrictionMethod registry value is set to force flat (non-hierarchical) restriction checking, the distribution groups that have delivery restrictions set have other distribution groups embedded in them (nested). Flat restriction checking will not correctly identify the allowed or denied senders if the distribution groups contain nested distribution groups. With flat restriction checking, nested distribution groups are not expanded.

The default behaviors for the categorizer is to recursively expand distribution groups and check restrictions for each message that passes through the system.

When you send mail to a user who accepts or denies messages from a distribution group or send mail that travels through a connector that accepts or denies message from a distribution group, the message categorizer has to expand the membership of the distribution group, obtain the full list of DNs of the members, and then compare the list of DNs to the list sender's DNs. An access operation or a deny operation occurs when a DN on both lists match. If a distribution group is nested in another distribution group, the nested distribution is also expanded.

The RestrictionMethod value determines how the categorizer will process restrictions. If you set the value of RestrictionMethod to 2, the transport components on this server that runs Exchange Server will not expand membership of distribution groups when the server checks restrictions. This configuration provides the best performance for restriction checks. Additionally, for the RestrictionMethod registry entry to take effect, all distribution groups that include users who have delivery restrictions must be flat. That is, the restricted distribution groups must not have nested distribution groups.

To address this warning, do not nest distribution groups within other distribution groups that are used for delivery restrictions when flat restriction checking is enabled.

For More Information

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking.

For more information about the effect of distribution group restriction on Exchange mail flow, see the following Microsoft Knowledge Base articles:

  • 895407 "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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

  • 812298 "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

For more information about the RestrictionMethod registry value, see Microsoft Knowledge Base article 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

For more information about the registry value, see Microsoft Knowledge Base article 277872, "XCON: Connector Delivery Restrictions May Not Work Correctly" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872).


No message from the specified sender
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-03-07

The Microsoft Exchange Server Analyzer tool queries the Active Directory directory service proxyAddress attribute value for all user objects to determine whether there is a match for the user-specified local sender Simple Mail Transfer Protocol (SMTP) address.

If a user object proxyAddress match is found, the Exchange Server Analyzer then queries the Active Directory msExchHomeServerName attribute value of the user object to determine whether that value matches the user-specified Exchange Server name.

Finally, the Exchange Server Analyzer queries the SenderAddress property for the Exchange_MessageTrackingEntry Microsoft Windows Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to identify any messages tracked by the message tracking logs as being from the user-specified sender.

If the Exchange Server Analyzer cannot find a message tracking log entry with a senderAddress property value that matches the legacyDN or SMTP address of the user-specified sender, the Exchange Server Analyzer displays an error.

  • This error indicates that one or more of the following conditions are true:

  • The user specified sender did not send any messages.

  • The message tracking log retention period has elapsed and the relevant log entries have already been deleted.

  • Message Tracking is not enabled for the server.

To resolve this issue:

  • Have the specified sender submit another message to the specified recipient.

  • Enable Message Tracking Center.

  • Increase the message tracking log retention period or track a more current message.

For more information about how to enable Message Tracking Center, see "How to Enable Message Tracking Center on a Server" (http://go.microsoft.com/fwlink/?LinkId=71257) in "Troubleshooting Mail Flow and SMTP" in the Exchange Server and Transport Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

For more information about how to use message tracking, see Microsoft Knowledge Base article 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=262162).


No message to the specified recipient
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-12-07

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service proxyAddress attribute value for all user objects to determine whether there is a match for the user-specified local sender Simple Mail Transfer Protocol (SMTP) address.

If a user object proxyAddress match is found, the Exchange Server Analyzer then queries the Active Directory msExchHomeServerName attribute value of the user object to determine whether that value matches the user-specified Exchange Server name.

The Exchange Server Analyzer then queries the SenderAddress property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to identify any messages tracked by the message tracking logs from the user-specified sender.

Finally, the Exchange Server Analyzer queries the RecipientAddress property for the Exchange_MessageTrackingEntry WMI class to identify any messages tracked by the message tracking logs to the user-specified recipient.

If the Exchange Server Analyzer cannot find a message-tracking log entry with a RecipientAddress property value that matches the SMTP address of the user-specified recipient, the Exchange Server Analyzer displays an error.

This error indicates that one or more of the following conditions are true:

  • The user-specified sender did not send any messages to the user-specified recipient.

  • The message-tracking log retention period has elapsed and the relevant log entries have already been deleted.

To resolve this issue:

  • Verify the specified recipient address is correct.

  • Have the specified sender submit another message to the specified recipient.

  • Increase the message-tracking log retention period or track a more current message.

For more information about how to increase the Message Tracking Center log-retention period, see "How to Enable Message Tracking Center on a Server" (http://go.microsoft.com/fwlink/?LinkID=71257).

For more information about how to use message tracking, see Microsoft Knowledge Base article 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=262162).


No queue status available. SMTP queue analysis aborted.
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-03-15

The Microsoft Exchange Analyzer tool queries the ExchangeLink Microsoft Windows Management Instrumentation (WMI) class to check the status of the Simple Mail Transfer Protocol (SMTP) queues for an Exchange server.

SMTP is the native mail protocol for mail submission and mail transport for Exchange Server. This means that clients use SMTP to send messages and Exchange servers use SMTP to deliver messages and message data.

Properties of the ExchangeLink WMI class return information about message-handling links (queues) between mail servers. A link can contain zero or more ExchangeQueue objects. This number depends on the current message traffic along the link.

SMTP uses the SMTP queues to deliver mail internally and externally. During message categorization and delivery, the advanced queuing engine sends all mail through the SMTP queues of an SMTP virtual server. If there is a problem delivering the message at any point in the process, the message remains in the queue where the problem occurred.

Descriptions of SMTP queues

SMTP queue Description

[Local domain name] (Local Delivery)

Contains messages that are queued on the Exchange server for local delivery to an Exchange mailbox or public folder store.

Messages awaiting directory lookup

Contains messages to recipients that have not yet been resolved against Microsoft Active Directory directory service. Messages are also held here while distribution lists are expanded.

Messages waiting to be routed

Holds messages until their next-destination server is determined, and then moves them to their respective link queues.

Remote delivery

[Connector name|

Server name| Remote domain]

Holds messages that are destined for remote delivery. The name of the queue matches the remote delivery destination, which may be a connector, a server, or a domain.

Final destination currently unreachable

The final destination server for these messages cannot be reached. For example, Exchange cannot determine a network path to the final destination.

Pre-submission

Holds messages that have been acknowledged and accepted by the SMTP service. The processing of these messages has not begun.

DSN messages pending submission

Contains delivery status notifications, also known as non-delivery reports that are ready to be delivered by Exchange.

Note The following operations are unavailable for this queue:

  • Delete All Messages (no NDR)

  • Delete All Messages (NDR)

Failed message retry queue

Contains messages that failed some type of queue submission, often before any other processing has taken place. By default, messages in this queue are reprocessed in 60 minutes.

Messages queued for deferred delivery

Contains messages that are queued for delivery at a later time, including messages that were sent by older versions of Outlook. (You can set this option on Outlook client computers.)

Previous versions of Outlook depend on the message transfer agent (MTA) for message delivery. Now, however, SMTP handles message delivery, not the MTA. Therefore, messages that are sent by older versions of Outlook treat deferred delivery differently.

These messages remain in this queue until their scheduled delivery time.

If the Exchange Analyzer cannot successfully complete the query to the ExchangeLink WMI class for a server, the Exchange Analyzer displays an error.

This error indicates that the WMI query was unable to retrieve the data requested.

The likely causes of this error are:

  • The account that runs the Exchange Analyzer does not have sufficient permissions to query WMI classes.

  • A network issue prevents the Exchange Analyzer from contacting the computer.

  • A transient condition of unknown origin has caused a time-out for the query.

To correct this error, do the following:

  1. Make sure that the Exchange Server computer has been started and is connected to the network.

  2. Use the PING command to see if the Exchange Server computer is reachable.

  3. If there is a firewall, check to see if remote procedure call (RPC) ports are blocked.

  4. Examine the permissions for the account under which the Exchange Analyzer is running. The account under which the Exchange Analyzer is running must have local Administrator permissions on each Exchange server that it is scanning.

    Alternatively, you can grant specific WMI permission to the account under which the Exchange Analyzer is running:

    1. On the Exchange computer, open the Computer Management Microsoft Management Console (MMC) tree.

    2. Under Services and Applications, right-click WMI Control, and then click Properties.

    3. On the WMI Controls Property page, click the Security tab, and then expand Root.

    4. Select the CIMV2 folder, and click Security.

    5. On the Security for ROOT\CIMV2 page, add the account under which the Exchange Analyzer runs.

  5. Select the account that you added in Step 5 above. In Permissions for Selected_Account, under the Allow column, select both Remote Enable and Read Security, and then click OK.

For more information about troubleshooting network connectivity problems, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about troubleshooting Exchange Best Practices Analyzer tool connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).

For more information about port requirements, see Microsoft Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


No remote servers or domains were available for DNS record tests
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-07-06

The Microsoft® Exchange Server Analyzer Tool tries to identify and build a list of the Fully Qualified Domain Names (FQDN), IP addresses, and domain names of remote servers that mail in a remote delivery queue is destined for.

The list of the FQDNs, IP addresses, and domain names of remote servers is built as follows:

  • The msExchSmtpFullyQualifiedDomainName property of the Active Directory® directory service object of the Simple Mail Transfer Protocol (SMTP) virtual server is queried.

    Note:
    The msExchSmtpFullyQualifiedDomainName property, in turn, is read from the msExchTargetBridgeheadServersDN property of a routing group connector directory object when that is queried for the designated target bridgehead servers
  • The msExchSmtpSmartHost property of the SMTP connector Active Directory object is queried for the designated smart host for an SMTP connector.

  • The LinkName property of the ExchangeLink Microsoft Windows® Management Instrumentation (WMI) class is queried for any remote server direct connections.

If the Exchange Server Analyzer determines that the attempt to build this list resulted in no entries, the Exchange Server Analyzer displays an error.

This error indicates:

  • There may be intermittent network or Active Directory connection issues that are causing mail flow issues.

  • The account that runs the Exchange Server Analyzer may not have sufficient permissions to query for the information.

To correct this error

  1. Make sure that the Exchange Server computer has been started and is connected to the network.

  2. Verify that you have network connectivity to an Active Directory domain controller.

  3. Specify an Active Directory domain controller in the Exchange Server Analyzer.

  4. Use the PING command to see whether the Exchange Server computer is reachable.

  5. If there is a firewall, check to see whether RPC ports are blocked.

  6. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange Server computer that it scans.

For more information about network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about Exchange Server Analyzer connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).

For more information about port requirements, see the Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


No Servers Available for SMTP Command Tests
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-16

The Microsoft® Exchange Server Analyzer Tool tries to identify and build a list of the fully qualified domain names (FQDN), IP addresses, and domain names of remote servers that mail in a remote delivery queue is destined for.

The list of the FQDNs, IP addresses, and domain names of remote servers is built as follows:

  • The msExchSmtpFullyQualifiedDomainName property of the Active Directory® directory service object of the Simple Mail Transfer Protocol (SMTP) virtual server is queried.

    Note:
    The msExchSmtpFullyQualifiedDomainName property, in turn, is read from the msExchTargetBridgeheadServersDN property of a routing group connector directory object when that is queried for the designated target bridgehead servers.
  • The msExchSmtpSmartHost property of the SMTP connector Active Directory object is queried for the designated smart host for an SMTP connector.

  • The LinkName property of the ExchangeLink Microsoft Windows® Management Instrumentation (WMI) class is queried for any remote server direct connections.

If the Exchange Server Analyzer determines that the attempt to build this list resulted in no entries, the Exchange Server Analyzer displays an error.

This error indicates the following:

  • Intermittent network or Active Directory connection issues may be causing mail flow issues.

  • The account that runs the Exchange Server Analyzer may not have sufficient permissions to query for the information.

To correct this error

  1. Make sure that the server that is running Exchange server has been started and is connected to the network.

  2. Verify that you have network connectivity to an Active Directory domain controller.

  3. Specify an Active Directory domain controller in the Exchange Server Analyzer.

  4. Use the PING command to see whether the Exchange server is reachable.

  5. If there is a firewall, check to see whether remote procedure call (RPC) ports are blocked.

  6. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange Server computer that it scans.

For more information about network connectivity problems, see Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about Exchange Server Analyzer connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).

For more information about port requirements, see Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


No Servers Were Available for Connectivity Tests
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool tries to identify and build a list of the Fully Qualified Domain Names (FQDN), IP addresses, and domain names of remote servers that mail in a remote delivery queue is destined for.

  • The list of the FQDNs, IP addresses, and domain names of remote servers is built as follows:

  • The msExchSmtpFullyQualifiedDomainName property of the Active Directory® directory service object of the Simple Mail Transfer Protocol (SMTP) virtual server is queried.

    Note:
    The msExchSmtpFullyQualifiedDomainName property, in turn, is read from the msExchTargetBridgeheadServersDN property of a routing group connector directory object when that is queried for the designated target bridgehead servers
  • The msExchSmtpSmartHost property of the SMTP connector Active Directory object is queried for the designated smart host for an SMTP connector.

  • The LinkName property of the ExchangeLink Microsoft Windows® Management Instrumentation (WMI) class is queried for any remote server direct connections.

If the Exchange Server Analyzer determines that the attempt to build this list resulted in no entries, the Exchange Server Analyzer displays an error.

This error indicates:

  • There may be intermittent network or Active Directory connection issues that are causing mail flow issues.

  • The account that runs the Exchange Server Analyzer may not have sufficient permissions to query for the information.

To correct this error

  1. Make sure that the Exchange Server computer has been started and is connected to the network.

  2. Verify that you have network connectivity to an Active Directory domain controller.

  3. Specify an Active Directory domain controller in the Exchange Server Analyzer.

  4. Use the PING command to see whether the Exchange Server computer is reachable.

  5. If there is a firewall, check to see whether RPC ports are blocked.

  6. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange Server computer that it scans.

For more information about network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about Exchange Server Analyzer connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).

For more information about port requirements, see the Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


No servers were available for SMTP instance name checks
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool tries to identify and build a list of the Fully Qualified Domain Names (FQDN), IP addresses, and domain names of remote servers that mail in a remote delivery queue is destined for.

The list of the FQDNs, IP addresses, and domain names of remote servers is built as follows:

  • The msExchSmtpFullyQualifiedDomainName property of the Active Directory® directory service object of the Simple Mail Transfer Protocol (SMTP) virtual server is queried.

    Note:
    The msExchSmtpFullyQualifiedDomainName property, in turn, is read from the msExchTargetBridgeheadServersDN property of a routing group connector directory object when that is queried for the designated target bridgehead servers
  • The msExchSmtpSmartHost property of the SMTP connector Active Directory object is queried for the designated smart host for an SMTP connector.

  • The LinkName property of the ExchangeLink Microsoft Windows® Management Instrumentation (WMI) class is queried for any remote server direct connections.

If the Exchange Server Analyzer determines that the attempt to build this list resulted in no entries, the Exchange Server Analyzer displays an error.

This error indicates:

  • There may be intermittent network or Active Directory connection issues that are causing mail flow issues.

  • The account that runs the Exchange Server Analyzer may not have sufficient permissions to query for the information.

To correct this error

  1. Make sure that the Exchange Server computer has been started and is connected to the network.

  2. Verify that you have network connectivity to an Active Directory domain controller.

  3. Specify an Active Directory domain controller in the Exchange Server Analyzer.

  4. Use the PING command to see whether the Exchange Server computer is reachable.

  5. If there is a firewall, check to see whether RPC ports are blocked.

  6. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange Server computer that it scans.

For more information about network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about Exchange Server Analyzer connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).

For more information about port requirements, see the Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


Non-default Routing Service Cache Setting
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default setting for the routing service cache has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\

If the Exchange Server Analyzer finds that the ServerCacheRefreshInterval registry value has been manually created, changing the default Exchange Server binary setting of 900, the Exchange Server Analyzer displays a warning. By default, the ServerCacheRefreshInterval registry value is not created by an Exchange Server installation. However, the ServerCacheRefreshInterval registry value can be manually created after the Exchange Server installation in order to change the default routing service cache setting. If the registry value is manually created and the setting for the registry value is configured incorrectly, the Exchange server may experience mail flow issues.

It is recommended that the ServerCacheRefreshInterval registry value be created or modified only after serious consideration. The default values in the binaries for Exchange Server were carefully selected for optimal performance for use in most Exchange Server environments. A general best practice is to address the root cause of the problem instead of modifying the default behavior of Exchange Server by manually configuring the registry. To comply with best practices, if the ServerCacheRefreshInterval registry value exists, you may want to delete this registry value to configure the Exchange server back to the default binary setting for the routing service cache. Your decision, however, depends on the Exchange Server custom configuration settings or Exchange environment.

The Exchange Server Analyzer reports this configuration for informational purposes only. However, you may want to change the registry value back to the default setting by editing the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Click Start, click Run, type Regedit, and then click OK.

  2. In the console tree, locate and then click the following registry key: HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\RESvc\Parameters\

  3. In the details pane, right-click the ServerCacheRefreshInterval registry value. Change value data to 900.

  4. Optionally, in the details pane, you can right-click the ServerCacheRefreshInterval registry value and then click Delete. Confirm the deletion of the registry value by clicking Yes in the dialog box.

  5. Restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about editing the Microsoft Windows registry see the following Microsoft Knowledge Base articles:

  • 322755, "How to back up, edit, and restore the registry in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 322756, "How to back up, edit, and restore the registry in Windows XP and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756).


Non-default SMTP LdapRequestTimeLimit registry value
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default LdapRequestTimeLimit has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

If the Exchange Server Analyzer finds that the LdapRequestTimeLimit registry value has been manually created to change the default Exchange server binary setting of 600 seconds, the Exchange Server Analyzer displays a non-default warning message. By default, the LdapRequestTimeLimit registry value is not created by an Exchange Server installation. However, the LdapRequestTimeLimit registry value can be manually created after the Exchange Server installation in order to change the maximum time in seconds that a single LDAP request waits in the queue. If the registry value is manually created and the setting for the registry value is configured incorrectly, the Exchange server may experience message transport problems.

It is recommended that the LdapRequestTimeLimit registry value should be created or modified only after careful consideration. The default values in the binaries for Exchange server were carefully selected for optimal performance for use in most Exchange server environments. A general best practice is to address the root cause of the problem instead of modifying the default behavior of Exchange Server by manually configuring the registry. To comply with best practices, if the LdapRequestTimeLimit registry value exists, you may want to delete this registry value to configure the Exchange server back to the default binary setting.

The Exchange Server Analyzer reports this configuration for informational purposes only. However, you may want to change the registry value back to the default setting by editing the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Click Start, click Run, type Regedit, and then click OK.

  2. In the console tree locate and then click the following registry key: HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. In the details pane right-click on the LdapRequestTimeLimit registry value. Change value data to 600.

  4. Optionally, in the details pane you can right-click the LdapRequestTimeLimit registry value and then click Delete. Confirm the deletion of the registry value by clicking Yes in the dialog box.

  5. Restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about editing the Microsoft Windows registry see the following Microsoft Knowledge Base articles:

  • 322755, "How to back up, edit, and restore the registry in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 322756, "How to back up, edit, and restore the registry in Windows XP and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


Non-default SMTP LdapResultTimeout registry value
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default LdapResultTimeout has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

If the Exchange Server Analyzer finds that the LdapResultTimeout registry key has been manually created, changing the default Exchange server binary setting of 121 seconds, the Exchange Server Analyzer displays a non-default warning message. By default, the LdapResultTimeout registry key is not created by an Exchange Server installation. However, the LdapResultTimeout registry key can be manually created after the Exchange Server installation in order to change the time-out value. LdapResultTimeout is the maximum time in seconds that the LDAP completion threads, for categorizer's LDAP connections, waits for processing. If the time-out expires and no new results have been received from a global catalog server, the pending searches fails on the connection with LDAP_SERVER_DOWN. This process then enables those pending searches to be reissued to new connections. If the registry value is manually created and the setting for the registry value is configured incorrectly, the Exchange server may experience message transport problems.

It is recommended that the LdapResultTimeout registry value be created or modified only after serious consideration. The default values in the binaries for Exchange Server were carefully selected for optimal performance for use in most Exchange Server environments. A general best practice is to address the root cause of the problem instead of modifying the default behavior of Exchange by manually configuring the registry. To comply with best practices, if the LdapResultTimeout registry value exists, you may want to delete this registry value to configure the Exchange server back to the default binary setting.

The Exchange Server Analyzer reports this configuration for informational purposes only. However, you may want to change the registry value back to the default setting by editing the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Click Start, click Run, type Regedit, and then click OK.

  2. In the console tree locate and then click the following registry key: HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. In the details pane right-click the LdapResultTimeout registry value. Change value data to 121.

  4. Optionally, in the details pane you can right-click the LdapResultTimeout registry value and then click Delete. Confirm the deletion of the registry value by clicking Yes in the dialog box.

  5. Restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about editing the Microsoft Windows registry see the following Microsoft Knowledge Base articles:

  • 322755, "How to back up, edit, and restore the registry in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 322756, "How to back up, edit, and restore the registry in Windows XP and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


Non-default SMTP MaxConnectionRetries registry value
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default MaxConnectionRetries has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

If the Exchange Server Analyzer finds that the MaxConnectionRetries registry value has been manually created, changing the default Exchange Server binary setting of 20, the Exchange Server Analyzer displays a non-default warning message. By default, the MaxConnectionRetries registry value is not created by an Exchange Server installation. However, the MaxConnectionRetries registry value can be manually created after the Exchange Server installation in order to change the value. The MaxConnectionRetries value sets the maximum number of times a single categorization can have its LDAP connection fail and then be reissued on a new connection. After the MaxConnectionRetries connection categorization fails, it is placed in the retry queue. If the registry value is manually created and the setting for the registry value is configured incorrectly, the Exchange Server may experience message transport problems.

It is recommended that the MaxConnectionRetries registry value be created or modified only after careful consideration. The default values in the binaries for Exchange Server were carefully selected for optimal performance for use in most Exchange Server environments. A general best practice is to address the root cause of the problem instead of modifying the default behavior of Exchange Server by manually configuring the registry. To comply with best practices, if the MaxConnectionRetries registry value exists, you may want to delete this registry value to configure the Exchange Server back to the default binary setting.

The Exchange Server Analyzer reports this configuration for informational purposes only. However, you may want to change the registry value back to the default setting by editing the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Click Start, click Run, type Regedit, and then click OK.

  2. In the console tree locate and then click the following registry key: HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. In the details pane right-click the MaxConnectionRetries registry value. Change value to 20.

  4. Optionally, in the details pane you can right-click the MaxConnectionRetries registry value and then click Delete. Confirm the deletion of the registry value by clicking Yes in the dialog box.

  5. Restart the Exchange Server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry". (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986)

For more information about editing the Microsoft Windows registry see the following Microsoft Knowledge Base articles:

  • 322755, "How to back up, edit, and restore the registry in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 322756, "How to back up, edit, and restore the registry in Windows XP and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


Non-default SMTP MaxLdapConnections registry value
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default MaxLdapConnections has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

If the Exchange Server Analyzer finds that the MaxLdapConnections registry value has been manually created, changing the default Exchange server binary setting of 8, the Exchange Server Analyzer displays a non-default warning message. By default, the MaxLdapConnections registry value is not created by an Exchange installation. However, MaxLdapConnections registry value can be manually created after the Exchange installation to change the value. The MaxLdapConnections value sets the maximum number of LDAP connections that the categorizer opens to a single global catalog server. If the registry value is manually created and the setting for the registry value is configured incorrectly, the Exchange server may experience message transport problems.

Caution:
The MaxLdapConnections registry value should match the value for the HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters\MaxPoolThreads registry value setting at all times.

It is recommended that the MaxLdapConnections registry value be created or modified only after careful consideration. The default values in the binaries for Exchange server were carefully selected for optimal performance for use in most Exchange server environments. A general best practice is to address the root cause of the problem instead of modifying the default behavior of Exchange Server by manually configuring the registry. To comply with best practices, if the MaxLdapConnections registry value exists, you may want to delete this registry value to configure the Exchange server back to the default binary setting.

The Exchange Server Analyzer reports this configuration for informational purposes only. However, you may want to change the registry value back to the default setting by editing the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Click Start, click Run, type Regedit, and then click OK.

  2. In the console tree, locate and then click the following registry key: HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. In the details pane, right-click the MaxLdapConnections registry value. Change value data to 8.

  4. Optionally, in the details pane you can right-click the MaxLdapConnections registry value and then click Delete. Confirm the deletion of the registry value by clicking Yes in the dialog box.

  5. Restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry". (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986)

For more information about editing the Microsoft Windows registry, see the following Microsoft Knowledge Base articles:

  • 322755, "How to back up, edit, and restore the registry in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 322756, "How to back up, edit, and restore the registry in Windows XP and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


Non-default SMTP MaxPendingSearches registry value
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default MaxPendingSearches has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

If the Exchange Server Analyzer finds that the MaxPendingSearches registry value has been manually created, changing the default Exchange server binary setting of 60, the Exchange Server Analyzer displays a non-default warning message. By default, the MaxPendingSearches registry value is not created by an Exchange Server installation. However, the MaxPendingSearches registry value can be manually created after the Exchange Server installation in order to change the value. The MaxPendingSearches value sets the number of outstanding LDAP searches the categorizer holds at a time against a particular global catalog server. The maximum number of pending searches per connection was 1024 in Exchange 2000 Server earlier than SP3. The default value in Exchange 2000 Server SP3 and Exchange Server 2003 is set to 60. For example, changing this value from the default of 60 to 30 reduces the overall number of LDAP searches the categorizer holds against the global catalog server.

If the registry value is manually created and the setting for the registry value is configured incorrectly, the Exchange server may experience message transport problems.

It is recommended that the MaxPendingSearches registry value be created or modified only after careful consideration. The default values in the binaries for Exchange server were carefully selected for optimal performance for use in most Exchange server environments. A general best practice is to address the root cause of the problem instead of modifying the default behavior of Exchange by manually configuring the registry. To comply with best practices, if the MaxPendingSearches registry value exists, you may want to delete this registry value to configure the Exchange server back to the default binary setting.

The Exchange Server Analyzer reports this configuration for informational purposes only. However, you may want to change the registry value back to the default setting by editing the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Click Start, click Run, type Regedit, and then click OK.

  2. In the console tree locate and then click the following registry key: HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. In the details pane right-click the MaxPendingSearches registry value. Change value data to 60.

  4. Optionally, in the details pane you can right-click the MaxPendingSearches registry value and then click Delete. Confirm the deletion of the registry value by clicking Yes in the dialog box.

  5. Restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about editing the Microsoft Windows registry see the following Microsoft Knowledge Base articles:

•322755, "How to back up, edit, and restore the registry in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

•322756, "How to back up, edit, and restore the registry in Windows XP and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


Non-default SMTP MaxSearchBlockSize registry value
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default MaxSearchBlockSize has been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

If the Exchange Server Analyzer finds that the MaxSearchBlockSize registry value has been manually created, changing the default Exchange server binary setting of 20, the Exchange Server Analyzer displays a non-default warning message. By default, the MaxSearchBlockSize registry value is not created by an Exchange Server installation. However, the MaxSearchBlockSize registry value can be manually created after the Exchange Server installation to change the value. The MhelpsBlockSize value sets the maximum number of categorizer searches that can be submitted together as a single LDAP search. By setting the maximum number of categorizer searches, you can help simplify the search filters for the categorizer.

This process enables those pending searches to be reissued to new connections. If the registry value is manually created and the setting for the registry value is configured incorrectly, the Exchange server may experience message transport problems.

It is recommended that the MaxSearchBlockSize registry value be created or modified only after careful consideration. The default values in the binaries for Exchange Server were carefully selected for optimal performance for use in most Exchange server environments. A general best practice is to address the root cause of the problem instead of modifying the default behavior of Exchange Server by manually configuring the registry. To comply with best practices, if the MaxSearchBlockSize registry value exists, you may want to delete this registry value to configure the Exchange server back to the default binary setting.

The Exchange Server Analyzer reports this configuration for informational purposes only. However, you may want to change the registry value back to the default setting by editing the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Click Start, click Run, type Regedit, and then click OK.

  2. In the console tree locate and then click the following registry key: HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. In the details pane right-click the MaxSearchBlockSize registry value. Change value data to 20.

  4. Optionally, in the details pane you can right-click the MaxSearchBlockSize registry value and then click Delete. Confirm the deletion of the registry value by clicking Yes in the dialog box.

  5. Restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about editing the Microsoft Windows registry see the following Microsoft Knowledge Base articles:

  • 322755, "How to back up, edit, and restore the registry in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 322756, "How to back up, edit, and restore the registry in Windows XP and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


Non-default SMTP TopoRecheckSecs registry value
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether it has been changed from its default value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\TopoRecheckSecs.

If the Exchange Server Analyzer finds that the value of TopoRecheckSecs is not equal to the default value of 900 seconds, a non-default configuration message is displayed. The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.Because DSAccess uses the value of the TopoRecheckSecs registry value to set the interval at which the global catalog list is rebuilt, an incorrect setting can cause a decrease in performance. Best practice is to use default configuration settings for Exchange Server whenever possible. However, if this registry value is present, it may have been added and configured on the recommendation of Microsoft Product Support Services to correct an issue that arose previously. You should consider removing this registry value unless it was added and configured on the recommendation of Microsoft PSS or other expert guidance.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To delete the TopoRecheckSecs registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess

  3. In the right pane, locate and delete the TopoRecheckSecs value.

  4. Close the registry editor.

  5. To make this change permanent, restart System Attendant.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about optimizing global catalog placement for Exchange Server, see Understanding and Troubleshooting Directory Access (http://go.microsoft.com/fwlink/?LinkId=39012).


Non-Exchange gateway server not set as smart host
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-09

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service for the distingushedName attribute value of the protocolCfgSMTPServer object class to list all Simple Mail Transfer Protocol (SMTP) virtual server instances on the user-specified Exchange gateway.

The Exchange Server Analyzer then queries Active Directory for the value of the msExchSourceBridgeheadServersDN and routingList attributes for each msExchRoutingSMTPConnector object found to determine whether an SMTP connector correctly has one of the detected SMTP virtual server instances set as its local bridgehead to an external SMTP address space.

Finally, the Exchange Server Analyzer queries Active Directory for the value of the msExchSmtpSmartHost attribute on all the detected SMTP connectors (msExchRoutingSMTPConnector object) to determine whether one of them has been designated as a smart host for the user-specified non-Exchange gateway server.

If the Exchange Server Analyzer determines that the user-specified non-Exchange gateway server is not set up as a smart host for one of the SMTP connectors, the Exchange Server Analyzer displays a warning.

This warning indicates that there is no explicit route set up from the user-specified Exchange gateway server to the user-specified non-Exchange gateway server and that servers other than the non-Exchange gateway may unintentionally route messages outside the organization.

To address this issue, designate the non-Exchange gateway server as a smart host for an SMTP connector.

To view and configure smart host settings

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server, for example, Default SMTP Virtual Server, and select Properties.

  4. Select the Delivery tab, and then click Advanced.

  5. Enter the smart host you want to use. You can identify the smart host by the fully qualified domain name or by an IP address. If you use an IP address, you must enclose it in brackets ([ ]). Exchange checks first for a server name, and then for an IP address. The brackets identify the value as an IP address. Therefore, the DNS lookup is bypassed.

  6. If this is a server that is running Exchange 2000 Server, optionally select the Attempt direct delivery before sending to smart host check box.

  7. Click OK to save the changes, and then click OK to close the Properties dialog box of the SMTP virtual server.

For more information about how to configure a smart host connector, see Microsoft Knowledge Base article 821911, "How to Configure Exchange Server 2003 to Use a Smart Host IP Address" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821911).

For more information about how to use SMTP connectors, see Microsoft Knowledge Base article 294736, "When to create SMTP connectors in Exchange 2000 and later versions" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=294736).

For more information about SMTP connectors, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Possible categorizer overload
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Cat: Messages submitted/sec and the Cat: Categorizations completed/sec performance counters of the SMTP Server performance object to analyze performance data.

The Cat: Messages submitted/sec performance counter shows the number of messages submitted per second to the categorizer whereas the Cat: Categorizations completed/sec shows the rate of categorizations completed per second.

The Exchange Server Analyzer compares the average total of the two counters to determine whether more messages are consistently submitted than are processed.

If the Exchange Server Analyzer determines that the average total number of messages submitted per second to the categorizer is consistently greater, by two messages, than the average total number of messages completed per second, the Exchange Server Analyzer displays a warning.

The categorizer performs the following core operations:

  • Resolves and validates all recipients.

  • Determines limits and restrictions for all recipients.

  • Expands distribution lists if that is required.

  • Determines whether the message is for local or remote delivery.

This warning indicates that the categorizer may be under stress. Possible causes should be investigated and remedied where you can.

Categorizer stress can be caused by a demand to process many messages because of:

  • Unsolicited commercial e-mail (UCE) or spam.

  • Virus proliferation.

  • Server performance issues.

To address this warning:

  • Determine whether the stress to the categorizer is expected or from a typical load. If the stress to the categorizer is from an expected load, review the Exchange performance guidance in these Microsoft TechNet Articles.

    • "Troubleshooting Exchange Server 2003 Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).

    • "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

  • If the stress to the categorizer is not from an expected load, check for virus outbreaks or spam that might generate the load.


Possible gateway problem
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-09

The Microsoft® Exchange Server Analyzer Tool sends a test message to a user-defined external account from the server that is running Exchange Server. The Exchange Server Analyzer then scans the message tracking logs of the server to determine whether any issues were found with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer queries the EntryType property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine why one or more message tracking log entries were created.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The message tracking log can be scanned successfully.

  • The test message did not successfully transfer out of the queue.

  • A non-delivery report (NDR) was not generated.

  • A value of 1034 exists for the EntryType property.

  • The message reached the specified local Exchange outbound gateway server.

This error may indicate that there is a connection problem between the user-specified local Exchange outbound gateway server and the remote server.

To resolve this error, use the NSlookup utility to review possible issues with Domain Name System (DNS) resolution. For connection and protocol issues such as Host unreachable errors, use Telnet.exe to try to connect to the destination computer. To troubleshoot protocol errors, increase diagnostic logging for the MSExchangeTransport service for the Simple Mail Transfer Protocol (SMTP) component, and review the logs for errors. Alternatively, you can use the Network Monitor (Netmon.exe) tool to obtain information about network connection errors.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


Possible Inetinfo problem
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool includes a performance data collection engine that is used to query performance counter objects on computers that are running Exchange 2000 Server or Exchange Server 2003. The performance data collection engine collects data from the Cat: Categorizations in progress performance counter of the SMTP Server performance object to analyze performance data.

The Cat: Categorizations in progress performance counter shows the number of categorizations in progress.

For this query, the Exchange Server Analyzer retrieves a sample every 6 seconds for a two-minute period. The Exchange Server Analyzer reports the average value for the performance counter during the collection interval.

If the Exchange Server Analyzer determines that the minimum number of categorizations in progress over the sample period is never equal to zero, the Exchange Server Analyzer displays a warning.

The categorizer performs the following core operations:

  • Resolves and validates all recipients.

  • Determines limits and restrictions for all recipients.

  • Expands distribution lists if that is required.

  • Determines whether the message is for local or remote delivery.

If the server is not under heavy load, this warning may indicate that the Inetinfo.exe process, or resources that the Inetinfo.exe process depends on, are deadlocked.

The Simple Mail Transfer Protocol (SMTP) service runs in the Inetinfo.exe process and when messages pass through the transport subsystem, SMTP makes heavy use of Internet Information Services (IIS) resources.

A deadlock occurs when two or more processes (or threads) each wait for the other to complete before the process can continue. The result is that all the processes (or threads) stop responding (hang). In a deadlock, processes never finish executing and system resources are occupied. This prevents other jobs from starting.

To address this warning:

  • Determine whether there is stress to the categorizer from an expected or from a typical load. If the categorizer is not under a heavy load, use the resources referenced in the "For More Information" section to identify possible performance issues with the Inetinfo.exe process or related resources.

  • Check whether the Inetinfo.exe process is up and running.

  • Check for an Inetinfo.exe deadlock situation by following the debug guidance in Microsoft Knowledgebase article 919791 "How to use the Debug Diagnostics Tool to troubleshoot high CPU usage by a process in IIS" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=919791).

For More Information

For more information about Inetinfo.exe, see "Internet Information Services" in the Technical Reference Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=72966).

For more information about how to troubleshoot a deadlocked process, see Microsoft Knowledgebase article 919791 "How to use the Debug Diagnostics Tool to troubleshoot high CPU usage by a process in IIS" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=919791).

For more information about Exchange Server performance, see the "Performance and Scalability Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47576).

For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).


Possible non-gateway problem
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-09

The Microsoft® Exchange Server Analyzer Tool sends a test message to a user-defined external recipient SMTP address from the server that is running Exchange Server. The Exchange Server Analyzer then scans the message tracking logs of the server to determine whether any issues were found with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer queries the EntryType property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine why one or more message tracking log entries were created.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The message tracking log can be scanned successfully.

  • The test message did not successfully transfer out of the queue.

  • A non-delivery report was not generated.

  • A value of 1034 exists for the EntryType property.

  • The message did not reach the specified local Exchange outbound gateway server.

This error may indicate that the test message is still in one of the Simple Mail Transfer Protocol (SMTP) remote Delivery queues for the sending server and there is an issue with the queue.

A remote Delivery queue holds messages that are destined for remote delivery. The name of the queue matches the remote delivery destination. This destination may be a connector, a server, or a domain.

To troubleshoot protocol errors, increase diagnostic logging for the MSExchangeTransport service for the SMTP component, and review the logs for errors. Alternatively, you can use the Network Monitor (Netmon.exe) tool to obtain information about network connection errors. To reproduce the problem, you may have to force the queue to try again. Examine the event log for possible errors associated with the Microsoft Exchange Information Store service.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


Possible SMTP proxy detected
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-12-06

The Microsoft® Exchange Server Analyzer Tool tries to send a message to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain.

The following default response is expected when the Exchange Server Analyzer opens a socket connection to the SMTP server:

"220 Computer Name . Domain Name .com Microsoft ESMTP MAIL Service, Version: Version Number ready at Date Time +0000"

If the Exchange Server Analyzer receives a non default response that contains a third-party-specific string, the Exchange Server Analyzer displays an error.

This error indicates that there may be a third-party SMTP proxy server that is running behind the remote server.

If the default SMTP banner has not been intentionally customized by the Exchange Server administrator, this warning may indicate that the Exchange Server is behind an SMTP proxy that is filtering the Exchange Server Extended Simple Mail Transfer Protocol (ESMTP) commands.

If Exchange Server ESMTP commands are filtered, this can have a significant effect on Exchange performance and may produce the behavior described in Microsoft Knowledge Base article 320027, "Cannot send or receive e-mail messages behind a Cisco PIX firewall" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320027).

For more information about customized SMTP banners, see the following Microsoft Knowledge Base article:

  • 281224: XCON: How to Modify the SMTP Banner (http://go.microsoft.com/fwlink/?linkid=3052&kbid=281224)


Potential categorizer performance issue
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Microsoft Windows® Management Instrumentation (WMI) class for the value of the TypePendingCategorization attribute of the Simple Mail Transfer Protocol (SMTP) ProtocolName instance to determine the number of messages in the Messages Awaiting Directory Lookup (MADL) SMTP queue.

Properties of the ExchangeLink WMI class return information about message-handling links (queues) between mail servers. A link can contain zero or more ExchangeQueue objects. This number depends on the current message traffic along the link.

The Exchange Server Analyzer also includes a performance data collection engine that is used to query performance counter objects on computers that run Exchange 2000 Server or Exchange Server 2003.

If the Exchange Server Analyzer determines that there are currently more than fifty messages in the MADL queue, the Exchange Server Analyzer has the performance data collection engine collect data from the Cat: Messages Categorized and the Cat: Categorizations completed performance counters of the SMTP Server performance object to analyze performance data.

The Cat: Messages Categorized performance counter shows the number of messages the categorizer has submitted for queuing whereas the Cat: Categorizations completed performance counter shows the total number of messages submitted to the categorizer that have been completed.

The categorizer performs the following core operations:

  • Resolves and validates all recipients.

  • Determines limits and restrictions for all recipients.

  • Expands distribution lists if that is required.

  • Determines whether the message is for local or remote delivery.

The Exchange Server Analyzer examines the average total of the two counters to determine whether their numbers increase over the sampling period.

The Exchange Server Analyzer displays an error if the following conditions are true.

  • There are fifty or more messages in the MADL queue.

  • The Cat: Messages Categorized performance counter shows an increase over the sample period that indicates progress in passing submitted messages to the next process.

  • The Cat: Categorizations completed performance counter shows an increase over the sample period that indicates progress in successfully completing the categorization of the submitted messages.

This error indicates that, although the categorizer processes messages successfully, its queue length remains high and performance may be damaged.

Categorizer performance can be affected by a demand to process many messages because of:

  • Unsolicited commercial e-mail (UCE) or spam.

  • Virus proliferation.

  • Server performance issues.

To address this warning:

  • Determine whether the stress to the categorizer is expected or from a typical load. If the stress to the categorizer is from an expected load, review the Exchange performance guidance in the following Exchange resources:

    • Troubleshooting Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588)

    • Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)

  • If the stress to the categorizer is not from an expected load, check for virus outbreaks or spam that might generate the load.


Potential Distribution Group Expansion Issues Found
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Exchange server is running Exchange Server 2003 Service Pack 2 (SP2) and is configured to expand distribution groups when it checks delivery restrictions:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod

  • A value of 1 for this entry means that the server is configured to expand distribution groups when it checks delivery restrictions.

  • A value of 2 for this entry indicates that the server is configured not to expand distribution groups when it checks delivery restrictions.

If the Exchange Server Analyzer finds that the server is set up to expand distribution groups when it checks delivery restrictions, the Exchange Server Analyzer then checks the server event logs to see whether error events 6004, 6006, and 6008 have all occurred in the past 24 hours.

These events indicate that messages are being trapped in the message categorizer. The message categorizer is a component of the advanced queuing engine that sends Lightweight Directory Access Protocol (LDAP) queries to the global catalog server to perform directory lookups.

Finally, the Exchange Server Analyzer queries the Active Directory® directory service to determine the following:

  • Whether there are more than 500 mailboxes in the forest that have delivery restrictions set so that at least one distribution group is used either to permit or prohibit senders.

  • Whether a Routing Group Connector has delivery restrictions based on distribution group membership and the bridgehead server has connector restriction checking enabled.

  • Whether an SMTP connector has delivery restrictions based on distribution groups membership and the bridgehead server has connector restriction checking enabled.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The Exchange Server 2003 SP2 server is configured to expand distribution groups when it checks delivery restrictions.

  • The Exchange server has logged events 6004, 6006, and 6008 in the past 24 hours.

  • There are more than 500 mailboxes in the forest that have delivery restrictions set so that at least one distribution group is used either to permit or prohibit senders, or there is a Routing Group Connector that has delivery restrictions based on distribution groups membership and the bridgehead server has connector restriction checking enabled, or an SMTP connector has delivery restrictions based on distribution groups membership and the bridgehead server has connector restriction checking enabled.

The RestrictionMethod value determines how the categorizer will process restrictions. The default behavior for the categorizer is to recursively expand distribution groups and check restrictions for each message that passes through the system. When an e-mail message is sent to a recipient that is configured to have a restriction that rejects messages from members of a particular distribution group or security group, Exchange Server must expand that group to make sure that the sender is not a member of the restricted group. The results of this group expansion are not cached by Exchange Server and must be performed every time. This causes the messages to be held in the categorizer queues and may delay message processing.

If you set the value of RestrictionMethod to 2, the transport components on this Exchange server will not expand membership of distribution groups when the server checks restrictions. This configuration provides the best performance for restriction checks. Additionally, for the RestrictionMethod registry entry to take effect, all distribution groups that include users who have delivery restrictions must be flat. That is, the restricted distribution groups must not have nested distribution groups. The expansion logic will not work if the restricted distribution groups are nested.

For distribution groups that are used in connector restrictions, it is recommended that you set the RestrictionMethod registry entry value on a connector bridgehead server that has no mailboxes. For Active Directory user restrictions, if the restricted distribution groups have expansion servers, it is recommended that you create the RestrictionMethod registry entry on the expansion servers.

For more information about what occurs when delivery restrictions are configured, see Microsoft Knowledge Base article 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

For more information about the RestrictionMethod registry value, see Microsoft Knowledge Base article 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

For more information about Exchange Server 2003 events and errors, see the "Events and Errors Message Center" (http://go.microsoft.com/fwlink/?LinkId=34258).

For more information about Connector Restrictions, see Microsoft Knowledge Base article 277872, "XCON: Connector Delivery Restrictions May Not Work Correctly" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872).

For more information about the SMTP Queues, see Microsoft Knowledge Base article 884996,"Messages remain in the 'Messages awaiting directory lookup' SMTP queue in Exchange Server 2003 or in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=884996).


Potential Message Journaling Recipient Problems Found
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) class to determine whether either of the following Categorizer Warning/Error Event combinations has occurred in the past 24 hours:

  • Event 9004 and Event 9003

  • Event 9035 and Event 6004

These events indicate that messages are being trapped in the message categorizer. The message categorizer is a component of the advanced queuing engine that sends Lightweight Directory Access Protocol (LDAP) queries to the global catalog server to perform directory lookups.

  • The Exchange Server Analyzer also queries the Active Directory® directory service to determine whether any one of the following conditions is also true:

  • The designated journaling recipient for a store points to a deleted object.

  • The designated journaling recipient for a store points to an object that does not have a valid mailNickname.

  • The designated journaling recipient for a store points to a disabled account.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • Either of the Warning/Error event combinations listed earlier has occurred.

  • Any one of the designated journaling recipient conditions is also true.

This error indicates that there is a potential problem with journaling in the Exchange environment that may cause messages to queue.

For information about how to correct this issue, see the specific Exchange Server Analyzer article that relates to your issue:

  • Journaling recipient points to a deleted object

  • Journaling recipient is not valid

  • Journaling recipient points to a disabled account

  • For information about Exchange Server 2003 events and errors, see the "Events and Errors Message Center" (http://go.microsoft.com/fwlink/?LinkId=34258).


Potential Message Journaling and Store Service Problems Found
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) class to determine whether the Categorizer Warning event 9004 has occurred in the past 24 hours.

The Exchange Server Analyzer also queries the Win32_Service WMI class to determine whether the Microsoft Exchange Information Store service (MSExchangeIS) is started or stopped. A value of anything other than Started for the MSExchangeIS instance means that the MSExchangeIS service is stopped.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The server has logged a Categorizer Warning event 9003 in the past 24 hours.

  • The MSExchangeIS service is stopped.

This error indicates that there is a problem with Message Journaling or the Microsoft Exchange Information Store service (Store.exe) that may cause messages to queue.

This issue may occur if one of the following conditions is true:

  • The journaling recipient object has been deleted from the Active Directory® directory service.

  • The Information Store service is not running or has been disabled on the Exchange Server computer that is the SMTP bridgehead server.

  • One or more mailbox stores on the SMTP bridgehead server are dismounted.

To resolve this issue:

  • Make sure that the SMTP bridgehead server has the Information Store service enabled and running. Make sure that the mailbox stores on the SMTP bridgehead server are mounted.

  • Make sure that the journaling recipient object for mailbox stores has not been deleted from Active Directory.

To determine the journaling recipient for a mailbox store

  1. Start Exchange System Manager.

  2. Expand Servers, expand <your Exchange server>, expand <storage group>, and then right-click the mailbox store and select Properties.

  3. On the General tab, view the account that appears immediately under the Archive all messages sent or received by mailboxes on this store check box. This is the account that is being used as the journal recipient.

    Note:
    Make sure that you verify the journal recipient for each mailbox store object.
To nominate a new user mailbox as the journaling recipient

  1. Start Exchange System Manager.

  2. Expand Servers, expand <your Exchange server>, expand <storage group>, and then right-click the mailbox store and select Properties.

  3. On the General tab, click Browse, to the right of the Archive all messages sent or received by mailboxes on this store text, to specify a mailbox as the journaling mailbox.

    Note:
    All journalized messages for senders on this mailbox store are sent to the mailbox you specify.

For information about this issue see Journaling recipient points to a deleted object.

For more information about Exchange Server 2003 events and errors, see the "Events and Errors Message Center" (http://go.microsoft.com/fwlink/?LinkId=34258).

For more information about how to deploy a journaling solution, see "Journaling with Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47581).


Potential Permissions Problems Found
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) class to determine whether the following Exchange Server Error Events have occurred in the past 24 hours:

  • Event 929.

  • Event 9035.

  • A combination of Events 9003, 9004, and 6004.

Exchange Server Error event 929 can occur because of incorrect access permissions on the Exchange Server objects in the Active Directory® directory service.

Exchange Server Error events 9003, 9004, and 6004 indicate that messages are being trapped in the message categorizer. The message categorizer is a component of the advanced queuing engine that sends Lightweight Directory Access Protocol (LDAP) queries to the global catalog server to perform directory lookups.

The Exchange Server Analyzer also queries Active Directory to determine whether the attributes of the objects related to Exchange indicate that there are permissions-inheritance problems for those objects.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • One of the following Events or combination of Events has been logged in the last 24 hours on a server that has queued messages in its Messages awaiting directory lookup queue:

    • Event 929.

    • Event 9035.

    • The combination of Events 9003, 9004, and 6004.

  • Objects related to Exchange have missing or incorrect access permissions.

This error means that there are permissions-inheritance problems in the Exchange environment that can cause mail to queue.

To resolve this problem, follow the steps in Microsoft Knowledge Base article 907969, "Event ID 929 is logged, and mail is not delivered from one mail server to another mail server in an Exchange 2000 Server organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=907969).

For more information about Exchange Server 2003 events and errors, see the "Events and Errors Message Center" (http://go.microsoft.com/fwlink/?LinkId=34258).


Public folder identified as a common destination
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-04

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_Queue Windows® Management Instrumentation (WMI) class to determine the values of the following attributes for the Simple Mail Transfer Protocol (SMTP) queues of the SMTP virtual server.

LinkId | Indicates the identifier for the link that contains the queue.
QueueId | Indicates the identifier of the queue.
QueueName | Indicates the name of the queue.
VirtualMachine | Indicates the name of the virtual machine that contains the queue.
VirtualServerName | Indicates the name of the virtual server that the queue is on.
MessageCount | Indicates the number of messages in the queue.

The Exchange Server Analyzer uses the information obtained here to query the Exchange_QueuedSMTPMessage WMI class for the values of the following attributes of the messages in the queue:

Recipients | Indicates the recipients of the message.
Received | Indicates the received time stamp for the message.
MessageId | Indicates the identifier of the queued message.
StateRetry | Indicates that transmission is retried for a message that was not delivered successfully.

Finally, the Exchange Server Analyzer uses the data obtained here to query the Active Directory® directory service for the distinguishedName value of each Recipient object. The Exchange Server Analyzer then determines whether the recipient is a user, a distribution group, a public folder, or a public folder store.

If the Exchange Server Analyzer determines that at least 25 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to a specific public folder, the Exchange Server Analyzer displays a warning.

If the Exchange Server Analyzer determines that at least 50 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to a specific public folder, the Exchange Server Analyzer displays an error.

This warning or error means that the public folder identified is a common destination for messages that are stuck in an SMTP queue.

To address this issue, the public folder should be investigated as follows for configuration issues or other anomalies that could cause messages to queue for it:

  • Make sure that the public folder object attributes are set correctly and contain the correct values in Active Directory.

  • Review the Active Directory permissions of the public folder object for the correct settings.

  • Look for possible unsolicited commercial e-mail (UCE), or spam, or virus attacks against the public folder.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).


Public folder store identified as a common destination
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-04

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_Queue Windows® Management Instrumentation (WMI) class to determine the values of the following attributes for the Simple Mail Transfer Protocol (SMTP) queues of the SMTP virtual server.

LinkId | Indicates the identifier for the link that contains the queue.
QueueId | Indicates the identifier of the queue.
QueueName | Indicates the name of the queue.
VirtualMachine | Indicates the name of the virtual machine that contains the queue.
VirtualServerName | Indicates the name of the virtual server that the queue is on.
MessageCount | Indicates the number of messages in the queue.

The Exchange Server Analyzer uses the information obtained here to query the Exchange_QueuedSMTPMessage WMI class for the values of the following attributes of the messages in the queue:

Recipients | Indicates the recipients of the message.
Received | Indicates the received time stamp for the message.
MessageId | Indicates the identifier of the queued message.
StateRetry | Indicates that transmission is being retried for a message that was not delivered successfully.

Finally, uses the data obtained here to query the Active Directory® directory service for the distinguishedName value of each Recipient object. The Exchange Server Analyzer then determines whether the recipient is a user, a distribution group, a public folder, or a public folder store.

If the Exchange Server Analyzer determines that at least 25 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to recipients whose mailboxes are homed on the same public folder store, the Exchange Server Analyzer displays a warning.

If the Exchange Server Analyzer determines that at least 50 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to recipients whose mailboxes are homed on the same public folder store, the Exchange Server Analyzer displays an error.

This warning or error means that the public folder store identified is a common destination for messages that are stuck in an SMTP queue.

To address this issue, the public folder store should be investigated as follows for configuration issues, replication storms, or other anomalies that could cause messages to queue for it:

  • Make sure that the store object attributes are set correctly and contain the correct values in Active Directory.

  • Review the Active Directory permissions of the store object for the correct settings.

  • Look for possible unsolicited commercial e-mail (UCE), or spam, or virus attacks against the public folder.

  • Check for changes to the public folder hierarchy or content that might generate lots of replication between public folder stores.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 842273, "How to troubleshoot public folder replication problems in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=842273).


Recipient Filtering is Enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchServerBindingsFiltering property of a Simple Mail Transfer Protocol (SMTP) virtual server object indicates that Recipient Filtering is enabled for a SMTP virtual server instance.

The Exchange Server Analyzer Tool also queries Active Directory to determine whether the msExchRecipTurfListNames or msExchRecipTurfListOptions properties indicate that Recipient Filtering is also enabled at the global settings level.

If the Exchange Server Analyzer Tool finds that Recipient Filtering is enabled at both the SMTP virtual server instance and at the Global Settings level, the Exchange Server Analyzer displays a warning.

This warning indicates that Recipient Filtering is effectively enabled. Recipient Filtering is generally not an issue. However, if you are troubleshooting mail flow issues involving this particular server, you may want to verify the filter configuration or temporarily disable Recipient Filtering to determine whether it is incorrectly blocking mail to valid recipients.

To disable a recipient filter on an SMTP virtual server

  1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In the console tree, expand Servers, expand the server that you want, expand Protocols, and then expand SMTP.

  3. Right-click the SMTP virtual server on which you want to disable the filter, and then click Properties.

  4. In <SMTP Virtual Server> Properties, on the General tab, click Advanced.

  5. In Advanced, select the IP address for which you want to disable the filter, and then click Edit.

In Identification, clear the Apply Recipient Filter check box to disable the filter.

  1. If you have multiple virtual servers, repeat Steps 3 through 6 for each virtual server on which you want to disable the filter.

For more information about how to configure recipient filters, see Microsoft Knowledge Base article 823866 "How to configure connection filtering to use Realtime Block Lists (RBLs) and how to configure recipient filtering in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823866).

For more information about intelligent message filtering, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).


'Remote Delivery' Queue is Frozen
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateFrozen key for the Simple Mail Transfer Protocol (SMTP) Remote Delivery queue.

If the Exchange Server Analyzer finds that the value of the StateFrozen key for the Remote Delivery queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

A frozen queue means the transport sessions for that queue are stopped. A frozen queue prevents outgoing messages, although new messages can be added. You can manually change the state of a connection by using the shortcut menu on each link queue. When you use the Force Connection command to change a queue state to Active, you immediately enable a connection that sends the messages from that queue.

The Remote Delivery queue holds messages that are destined for remote delivery. The name of the queue matches the remote delivery destination. This destination may be a connector, a server, or a domain.

To resolve this error, use the NSlookup utility to review possible issues with Domain Name System (DNS) resolution. For connection and protocol issues such as Host unreachable errors, use Telnet.exe to try to connect to the destination computer. To troubleshoot protocol errors, increase diagnostic logging for the MSExchangeTransport service for the SMTP Protocol component, and review the logs for errors. Alternatively, you can use the Network Monitor (Netmon.exe) tool to obtain information about network connection errors. To reproduce the problem, you may have to force the queue to try again. Examine the event log for possible errors associated with the Microsoft Exchange Information Store service.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


'Remote Delivery' Queue is in Retry
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the ExchangeLink Windows® Management Instrumentation (WMI) class to determine the value of the StateRetry key for the Simple Mail Transfer Protocol (SMTP) Remote Delivery queue.

If the Exchange Server Analyzer finds that the value of the StateRetry key for the Remote Delivery queue on an Exchange server is set to True, the Exchange Server Analyzer displays an error.

If a queue is in retry status, this status indicates that at least one error occurred in the previous attempts to process the messages in the queue. You can change queues in the Retry or Scheduled state to Active with the Force Connection command. This causes the queue to function as if the retry interval had passed or the scheduled time was reached. However, this method may not always work.

Note:
The properties of a queue can indicate a specific reason for a queue to be in Retry.

The Remote Delivery queue holds messages that are destined for remote delivery. The name of the queue matches the remote delivery destination. This destination may be a connector, a server, or a domain.

To resolve this error, use the NSlookup utility to review possible issues with Domain Name System (DNS) resolution. For connection and protocol issues such as Host unreachable errors, use Telnet.exe to try to connect to the destination computer. To troubleshoot protocol errors, increase diagnostic logging for the MSExchangeTransport service for the SMTP Protocol component, and review the logs for errors. Alternatively, you can use the Network Monitor (Netmon.exe) tool to obtain information about network connection errors. To reproduce the problem, you may have to force the queue to try again. Examine the event log for possible errors associated with the Microsoft Exchange Information Store service.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


'Remote Delivery' Queue Issue
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool sends a test message from the Exchange server to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain and then scans the message tracking logs of the server to determine whether any issues were found with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer queries the EntryType property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine what caused the message tracking log entry(s) to be created.

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The message tracking log can be scanned successfully.

  • The test message did not successfully transfer out of the queue.

  • A Non Delivery Report (NDR) was not generated.

  • A value of 1034 exists for the EntryType property.

This error indicates that the test message is still in one of the Simple Mail Transfer Protocol (SMTP) Remote Delivery queues for the sending server and there is an issue with the queue.

A Remote Delivery queue holds messages that are destined for remote delivery. The name of the queue matches the remote delivery destination. This destination may be a connector, a server, or a domain.

To resolve this error, use the NSlookup utility to review possible issues with Domain Name System (DNS) resolution. For connection and protocol issues such as Host unreachable errors, use Telnet.exe to try to connect to the destination computer. To troubleshoot protocol errors, increase diagnostic logging for the MSExchangeTransport service for the SMTP Protocol component, and review the logs for errors. Alternatively, you can use the Network Monitor (Netmon.exe) tool to obtain information about network connection errors. To reproduce the problem, you may have to force the queue to try again. Examine the event log for possible errors associated with the Microsoft Exchange Information Store service.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


Retry Categorization
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool sends a test message from the Exchange server to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain and then scans the message tracking logs of the server to determine whether there were issues found with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer queries the EntryType property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine the cause of the message tracking log entry.

If the Exchange Server Analyzer finds a value of 1032 for the EntryType property, the Exchange Server Analyzer displays a warning.

This warning indicates that the test message is in a queue that is scheduled for a retry of categorization. If a queue is in retry status, this status indicates that at least one error occurred in the previous attempts to process the messages in the queue. You can change queues in the Retry or Scheduled state to Active with the Force Connection command. This causes the queue to function as if the retry interval had passed or the scheduled time was reached. However, this method may not always work.

Note:
The properties of a queue can indicate a specific reason for a queue to be in Retry.

Generally, messages accumulate in queues awaiting retry because the advanced queuing engine is unable to categorize the message. The advanced queuing engine may not be able to access the global catalog servers and access recipient information, or the global catalog servers are unreachable or performing slowly. In addition, messages can accumulate for the following reasons:

  • Active Directory is unavailable.

    Note:
    The categorizer uses Active Directory to categorize messages.
  • Active Directory may be too heavily loaded if many messages are queuing in the pre-categorization queue.

  • There is a failure in conversion. The categorizer also handles content conversion.

  • The message categorizer cannot find the mailbox stores.

  • If SMTP was reinstalled or removed, this may invalidate the following IIS metabase keys: /smtpsvc/DsUseCat and /smtpsvc/vsi#/DsUseCat.

    Note:
    Determine whether SMTP was reinstalled or removed.

If a queue is in a "Retry" status, examine the properties of the queue to determine the cause. For example, if the queue properties display a message that resembles "An SMTP error has occurred," you should review your server's event logs to locate any SMTP errors. If there are no events in the log, you should increase the SMTP Protocol logging level.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


Retry Local Delivery
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-04

The Microsoft® Exchange Server Analyzer Tool sends a test message from the Exchange server to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain and then scans the message tracking logs of the server to determine whether there were any issues found with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer queries the EntryType property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine the cause of the message tracking log entry.

If the Exchange Server Analyzer finds a value of 1037 for the EntryType property, the Exchange Server Analyzer displays a warning.

This warning indicates that at least one error occurred in the previous attempts to process the message in the Local Delivery queue.

The Local Delivery queue contains messages that are queued on the Exchange server for local delivery to an Exchange Server mailbox or public folder store.

Messages can accumulate in this queue if the Exchange server is not accepting messages for local delivery. Slow or intermittent message delivery can indicate a looping message or a performance problem.

You can change queues that are in the Retry or Scheduled state to the Active state with the Force Connection command. This causes the queue to function as if the retry interval had passed or the scheduled time was reached. However, this method may not always work.

Note:
The properties of a queue can indicate a specific reason for a queue to be in Retry.

To resolve this error, increase diagnostic logging for the MSExchangeIS and MSExchangeTransport service SMTP store driver components.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mailflow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


Retry Routing
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool sends a test message from the Exchange server to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain and then scans the message tracking logs of the server to determine whether there were issues found with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer Tool queries the EntryType property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine the cause of the message tracking log entry.

If the Exchange Server Analyzer finds a value of 1035 for the EntryType property, the Exchange Server Analyzer displays a warning.

This warning indicates that the test message is in a queue that is scheduled for a retry of routing. If a queue is in retry status, this status indicates that at least one error occurred in the previous attempts to process the messages in the queue. You can change queues in the Retry or Scheduled state to Active with the Force Connection command. This causes the queue to function as if the retry interval had passed or the scheduled time was reached. However, this method may not always work.

Note:
The properties of a queue can indicate a specific reason for a queue to be in Retry.

Messages accumulate in queues awaiting retry if Exchange Server routing problems exist. Messages have not been routed because of a transient error, that is, the routing engine did not successfully initialize. The messages are in the pre-routing queue waiting to be retried or are being rerouted.

To resolve this error, increase diagnostic logging for the MSExchangeTransport service to collect information about the Routing category component. Disable any unnecessary connector restrictions because the restrictions can cause a significant degradation in server performance. You may have to turn on the CheckConnectorRestrictions registry key for some restrictions.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


Reverse DNS lookups have been enabled in the metabase but not on the associated SMTP server in the Active Directory
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following property in the Internet Information Services (IIS) metabase to determine if its value matches the configured value for the msExchSmtpPerformReverseDnsLookup attribute in the Active Directory® directory service:

/LM/SmtpSvc/<SMTP virtual server instance>/EnableReverseDnsLookup

If the Exchange Server Analyzer finds that the values do not match, a warning message is displayed.

If the value in the IIS metabase does not match the value in Active Directory, it could indicate a problem with Active Directory replication or a problem with the Directory-service-to-Metabase-replication component (DS2MB) in Exchange.

The function of the DS2MB process is to transfer configuration information from Active Directory to the local metabase. This configuration is stored in the local metabase instead of the registry for performance and scalability reasons. In Exchange 2000 Server and Exchange Server 2003, all of the Internet protocols (SMTP, NNTP, POP3, IMAP4, and HTTP) run as components of IIS.

Every 15 minutes, the DS2MB process copies entire subtrees from Active Directory without changing the shape of the subtree. This is a one-way write from Active Directory to the metabase; the metabase never writes to Active Directory.

The EnableReverseDnsLookup property and the msExchSmtpPerformReverseDnsLookup attribute can both have a value of TRUE or FALSE. A value of TRUE means that the SMTP virtual server will perform reverse DNS lookups on all incoming messages. A value of FALSE means that it will not perform reverse DNS lookups. Because of the potential for performance degradation due to mis-configured DNS records or intermittent connections to the Internet, the EnableReverseDnsLookup property and the msExchSmtpPerformReverseDnsLookup attribute are set to FALSE by default.

If the EnableReverseDnsLookup property is set to TRUE (enabled) and the msExchSmtpPerformReverseDnsLookup attribute is set to FALSE (disabled), it means that Active Directory and the IIS metabase are not in sync. If the problem is caused by a failure of the DS2MB process, you can correct the problem by following the procedure below for the version of Exchange Server you are running. If the problem is caused by a partial or complete failure of Active Directory replication, you can use the Active Directory Replication Monitor utility (ReplMon.exe) to check the health and status of Active Directory replication. You can find ReplMon.exe in the Windows® Support Tools on the Windows Server CD-ROM.

To correct this error on Exchange Server 2003

  1. Check for the presence of application event log entries with a source of MSExchangeMU. If DS2MB fails, it will log an event on Exchange Server 2003.

  2. If you do not see any DS2MB failures, use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  3. If you do see DS2MB failures, or after you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

To correct this error on Exchange 2000 Server

  1. Use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  2. After you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

For more information about the reverse DNS lookup feature in Exchange, see Microsoft Knowledge Base article 297412, "The 'Perform Reverse DNS Lookup for Incoming Messages' Option Is for Host Name Resolution" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412).

For more information about SMTP virtual server settings, see Microsoft Knowledge Base articles 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686) and 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163).

For more information about Active Directory replication, see Microsoft Knowledge Base article 232072, "Initiating Replication Between Active Directory Direct Replication Partners" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072).

For more information about the DS2MB process, see Microsoft Knowledge Base article 240105, "XGEN: General Information on Directory Service/Metabase Synchronization in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105).


Routing Engine: AttachedTimeout parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Simple Mail Transfer Protocol (SMTP) connector routing logic has been modified from its default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\AttachedTimeout

If the Exchange Server Analyzer finds that the AttachedTimeout registry key is present and configured with a value greater than 300, a non-default configuration message is displayed.

The AttachedTimeout registry entry is a custom configuration setting for Exchange Server that determines the frequency at which the ORG_INFO packet is sent. Every time the routing client does not connect to a routing server, the user version of the topology will be incremented and will cause the ORG_INFO packet to be broadcast throughout the whole organization.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. Delete the AttachedTimeout registry key.

  4. Close the registry editor.

  5. Restart the IIS Admin Service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the AttachedTimeout registry value, see Knowledge Base article 832281, "Link state issues and routing issues in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832281).


Routing Engine: BestAddressMatchOnly parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Simple Mail Transfer Protocol (SMTP) connector routing logic has been modified from its default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\BestAddressMatchOnly

If the Exchange Server Analyzer finds that the BestAddressMatchOnly registry key is present and configured with a value greater than 0, a non-default configuration message is displayed.

The BestAddressMatchOnly registry entry is a custom configuration setting for Exchange Server that forces mail sent to a specific domain to be routed through a specific connector, regardless of any existing restrictions.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. Delete the BestAddressMatchOnly registry key.

  4. Close the registry editor.

  5. Restart the IIS Admin Service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Routing Engine: CheckConnectorRestrictions parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Simple Mail Transfer Protocol (SMTP) connector routing logic has been modified from its default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\CheckConnectorRestrictions

If the Exchange Server Analyzer finds that the CheckConnectorRestrictions registry key is present and configured with a value greater than 0, a non-default configuration message is displayed.

The CheckConnectorRestrictions registry entry is a custom configuration setting for Exchange Server that enables restriction checking on the Exchange bridgehead server that is the source for the connector that is being checked. By default, connector restriction checking is turned off because it can significantly affect performance, notably in configurations that use many distribution groups. Restrictions will be checked for each message sent to each member of each distribution group that passes through the system. If restrictions are specified but this registry entry does not exist, restriction checking will not be performed.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. Delete the CheckConnectorRestrictions registry key.

  4. Close the registry editor.

  5. Restart the IIS Admin Service.

  6. On the connector's Delivery Restrictions tab, re-enable the restriction option.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the CheckConnectorRestrictions registry value, see Knowledge Base article 277872, "XCON: Connector Delivery Restrictions May Not Work Correctly" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872).


Routing Engine: Configuration parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the Active Directory® directory service read interval for the Exchange routing engine setting has been modified from the default setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc\Parameters\ReloadOsInterval

If the Exchange Server Analyzer finds that the value data for ReloadOsInterval is set to anything other than 3600, a non-default configuration message is displayed.

The ReloadOsInterval value is used to specify the interval at which routing link state information is updated between servers running Exchange. Exchange uses routing link state information so that each server can determine the most inexpensive route to deliver a message, and also whether the connectors that make up the route are functioning. By default, Exchange servers read link state information from Active Directory every 3,600 seconds, which is 1 hour.

In certain situations, routing status information may not be dynamically propagated correctly across servers throughout an Exchange organization. Some servers in the organization continue to operate with old and possibly incorrect routing status information. An outcome of this situation may include new connectors that do not appear when you view a remote routing group by using the WinRoute tool (Winroute.exe). You can use the WinRoute tool to verify that link state information is propagating. To verify that information is propagating, use the WinRoute tool to view the link state information from several different locations in the Exchange organization, and then compare the version numbers for each routing group. The WinRoute tool connects to the link state port on an Exchange Server computer and extracts the link state information for the Exchange organization. Although link state information is a series of globally unique identifiers (GUIDs), WinRoute matches the GUIDs of connectors and of bridgehead servers to objects in Active Directory and presents the information in a readable format.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To revert to the default configuration

  1. Open a registry editor such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\RESvc\Parameters

  3. In the right pane, double-click ReloadOsInterval.

  4. In the Value data box, type 3600, and then click OK.

  5. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about routing and link state information, see the following Knowledge Base articles:

  • 842026, "Routing status information is not propagated correctly to all servers in Exchange 2000 Server or in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=842026)

  • 285130, "XCON: Link State Information" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=285130)

To download WinRoute, a tool that helps you determine the link state information known to the routing master, see "Exchange Server WinRoute" (http://go.microsoft.com/fwlink/?LinkId=25049).


Routing Engine: PollingInterval parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Simple Mail Transfer Protocol (SMTP) connector routing logic has been modified from its default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\PollingInterval

If the Exchange Server Analyzer finds that the PollingInterval registry key is present and configured with a value greater than 300, a non-default configuration message is displayed.

The PollingInterval registry entry is a custom configuration setting for Exchange Server that helps control the frequency of link state traffic among routing groups, specifically to and from the routing group master within a routing group. Increasing this setting will prevent connections from failing, but it may prevent you from addressing the larger issue of slow links between members of a routing group.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. Delete the PollingInterval registry key.

  4. Close the registry editor.

  5. Restart the IIS Admin Service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Routing Engine: StateChangeDelay parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Simple Mail Transfer Protocol (SMTP) connector routing logic has been modified from its default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\StateChangeDelay

If the Exchange Server Analyzer finds that the StateChangeDelay registry key is present and configured with a value greater than 0, a non-default configuration message is displayed.

The StateChangeDelay registry entry is a custom configuration setting for Exchange Server that helps control the interval at which connectors are marked as unavailable and the notifications that occur because of connector and server state change. When StateChangeDelay is set to greater than 0, a server can only be marked as available or unavailable one time in each time period that is set by this value.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. Delete the StateChangeDelay registry key.

  4. Close the registry editor.

  5. Restart the IIS Admin Service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


Routing Engine: SuppressStateChanges parameter is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Simple Mail Transfer Protocol (SMTP) connector routing logic has been modified from its default setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\SuppressStateChanges

If the Exchange Server Analyzer finds that the SuppressStateChanges registry key is present and configured with a value greater than 0, a non-default configuration message is displayed.

Exchange Server 2003 includes functionality to detect automatically changes in the state of a link. This information can be used to inform other servers running Exchange Server 2003 that an alternative route should be used instead of the lowest cost primary route. Link state information is divided into major and minor changes. A major change occurs when the administrator changes the routing topology, such as the addition of a new connector or a cost change. Minor updates occur when the system automatically detects the failure or restoration of a link.

This feature works well in small to medium-sized organizations. However, in large multi-site environments, mass network fluctuation can cause link update floods for the minor version. To be truly effective, link state data must be broadcast to all the servers in the organization. Additionally, when state changes, the whole link state table is rebroadcast, which can cause a significant amount of data to be transmitted over the network. In these scenarios, it may be useful to suppress minor link state changes. The SuppressStateChanges registry entry is a custom configuration setting used to suppress minor link state changes. When SuppressStateChanges is set to greater than 0, all link state changes on this Exchange Server computer are suppressed.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. Delete the SuppressStateChanges registry key.

  4. Close the registry editor.

  5. Restart the Simple Mail Transfer Protocol (SMTP), the Microsoft Exchange Routing Engine, and the Microsoft Exchange MTA Stacks services for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the SuppressStateChanges registry key, see the following Microsoft guides:

  • Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579)

  • Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576)


Routing group connector with distribution group delivery restrictions set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool queries the following attributes for each Routing Group Connector object (msExchRoutingGroupConnector) detected in the Active Directory® directory service to determine whether they have delivery restrictions set based on distribution group membership.

dLMemRejectPerms | Contains the domain names (DNs) of distribution lists (DL) whose members may not send through this Routing Group Connector.
dLMemSubmitPerms | Contains the domain names (DNs) of distribution lists (DL) whose members may send through this Routing Group Connector.

If the Exchange Server Analyzer determines that there are routing group connectors that have delivery restrictions set based on distribution group membership, the Exchange Server Analyzer displays a warning.

This warning indicates that delivery restrictions based on distribution group membership may affect Exchange mail flow performance.

When you send mail by using routing group connectors that have delivery restrictions set based on distribution group membership, the message categorizer must expand the membership of the distribution group, obtain the full list of DNs of the members, and then compare the list of DNs to the list sender's DNs. An access operation or a deny operation occurs when a DN on both lists match. If a distribution group is nested in another distribution group, the nested distribution is also expanded.

To address this warning:

  • Design a dedicated routing group for connector restrictions and configure it to a local routing group as referenced in Microsoft Knowledge Base article 329171, "XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171).

  • Use a dedicated and more robust global catalog server as the designated bridgehead server for the connector.

  • Configure individual mailboxes and not distribution groups for delivery restrictions as referenced in Microsoft Knowledge Base article 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

  • Consider implementing Simple Mail Transfer Protocol (SMTP) sender filtering.

  • For servers that run Exchange Server 2003 Service Pack 2 (SP2) or a later version, consider implementing non-hierarchal restriction checking. For servers that run Exchange versions earlier than Exchange 2003 SP2, consider upgrading to Exchange 2003 SP2.

For More Information

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking

For more information about SMTP sender filtering, see "How to Enable Sender Filtering" in the Administration Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=72967).

For more information about the effect of distribution group restriction on Exchange mail flow, see the following Microsoft Knowledge Base articles:

  • 329171 " XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171).

  • 895407 "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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


Routing group master has been deleted
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value of the msExchRoutingMasterDN attribute for each Routing Group container. If the Exchange Server Analyzer finds that the value for the msExchRoutingMasterDN attribute contains the string "DEL:", an error is displayed.

The msExchRoutingMasterDN attribute is a single-valued attribute that stores the distinguished name of the Exchange Server computer that serves as the routing group master for each routing group. The presence of the string "DEL:" could indicate that the previous routing group master was deleted using the Active Directory Users and Computers tool. Without the routing group master, Exchange will not be able to correctly update or maintain the routing topology.

When you create a routing group, the first server in that routing group is assigned the role of routing group master. The routing group master maintains current link state information for its routing group and propagates it to the other servers within the routing group. The routing group master monitors the routing configuration that is written in Active Directory for its routing group only. Member servers can communicate any connector state or server availability information to the routing group master. For example, if a member server tries to contact another server in a different routing group over a connector, and this link is unavailable, the member server immediately notifies the routing group master. Similarly, when a non-master server receives new link state information, it immediately transfers the connector state information to the routing group master, so that other servers can receive the information about the routing change.

To correct this error

  1. In Exchange System Manager, and under Administrative Groups, expand Administrative_Group, and then expand Routing Groups.

  2. Expand the routing group, and then click Members.

  3. In the right pane, right-click the Exchange computer that you want to configure as the routing group master, and then click Set as Master.

For more information about routing group masters, see "Configuring a Routing Topology" in Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?linkid=47579).


Routing group membership error
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service for each value of the msExchRoutingGroupMembersBL attribute on the Routing Group objects to determine whether the back-linked server belongs to the dedicated Microsoft Exchange Server 2007 administrative group, Exchange Administrative Group (FYDIBOHF23SPDLT).

The Exchange Server Analyzer also queries the value of the CN attribute for the Routing Group object to determine whether the value is equal to the Exchange 2007 routing group default, Exchange Routing Group (DWBGZMFD01QNBJR).

The Exchange Server Analyzer displays an error if the following conditions are true:

  • The back-linked server belongs to the dedicated Exchange 2007 administrative group, Exchange Administrative Group (FYDIBOHF23SPDLT).

  • The routing group is not the Exchange 2007 routing group default, Exchange Routing Group (DWBGZMFD01QNBJR).

This error indicates that the server may have been manually moved from the Exchange 2007 default routing group. This may cause routing issues.

Microsoft Exchange Server 2003 and Microsoft Exchange 2000 Server use routing groups to define an Exchange-specific routing topology. Exchange 2007 uses Active Directory sites to define its routing topology. Exchange 2003 and Exchange 2000 use a routing topology that is based on routing groups and connectors. An Exchange-specific routing configuration is no longer required in a pure Exchange 2007 organization. A pure Exchange 2007 organization uses the Active Directory site topology to determine its routing topology.

To support coexistence between these two routing topologies, all Exchange 2007 servers are automatically added to a single routing group when Exchange 2007 is installed. The Exchange 2007 routing group is recognized in the Exchange System Manager in Exchange 2003 or Exchange 2000 as Exchange Routing Group (DWBGZMFD01QNBJR) within Exchange Administrative Group (FYDIBOHF23SPDLT).

To resolve this issue, move Exchange 2007 servers to the Exchange 2007 dedicated routing group, or remove and reinstall the server.


Send Connector Disabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-07-30

The Microsoft Exchange Analyzer Tool uses the following Exchange Management Shell cmdlet to query for all Send connectors in the Exchange environment that have the value of their Enabled attribute set to False. A value of False for the Send connector Enabled attribute indicates that the Send connector is disabled.

Get-SendConnector | where { $_.Enabled -eq $False}

The Exchange Analyzer then queries the Active Directory directory service for the value of the serialNumber attribute for all objects with an object class of msExchExchangeServer.

If the string value includes Version 5.5, the computer is running Microsoft Exchange Server 5.5. If the string value includes Version 6.0, the computer is running Exchange 2000 Server. If the string value includes Version 6.5, the computer is running Exchange Server 2003. If the string value includes Version 8, the computer is running Exchange Server 2007.

If the Exchange Analyzer determines that a Send connector is disabled in an Exchange environment that also has Exchange 2000 or Exchange 2003 servers, the Exchange Analyzer displays an error.

This error indicates that while Exchange 2007 routing will ignore disabled Send connectors, Exchange 2000 and Exchange 2003 will not recognize the disabled flag for the connector and may still attempt to route messaging through the connector resulting in routing loops.

To address this error, delete any disabled Send connectors in Exchange environments that are running Exchange 2000 or Exchange 2003.

To delete a disabled Send connector, follow the guidance for using the Exchange Management Shell Remove-SendConnector cmdlet in the "Remove-SendConnector" (http://go.microsoft.com/fwlink/?LinkId=96007) topic of the Exchange Server 2007 product documentation.


Sender Filtering Enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchServerBindingsTurflist property of a Simple Mail Transfer Protocol (SMTP) virtual server object indicates that sender filtering is enabled for an SMTP virtual server instance.

The Exchange Server Analyzer also queries Active Directory to determine whether the msExchTurfListNames or msExchTurfListOptions properties indicate that sender filtering is also enabled at the global settings level.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • Sender filtering is enabled at the SMTP virtual server instance.

  • Sender filtering is enabled at the global settings level.

This warning indicates that sender filtering is effectively enabled. Sender filtering is generally not an issue unless you are troubleshooting mail flow problems with this particular server. If this is the case, you may want to verify the filter configuration or temporarily disable sender filtering to determine whether it is incorrectly blocking legitimate mail from valid senders.

To disable a sender filter on an SMTP virtual server

  1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In the console tree, expand Servers, expand the server that you want, expand Protocols, and then expand SMTP.

  3. Right-click the SMTP virtual server on which you want to disable the filter, and then click Properties.

  4. In <SMTP Virtual Server> Properties, on the General tab, click Advanced.

  5. In Advanced, select the IP address for which you want to disable the filter, and then click Edit.

  6. In Identification, clear the Apply Sender Filter check box to disable the filter.

  7. If you have multiple virtual servers, repeat Steps 3 through 6 for each virtual server on which you want to disable the filter.

For more information about intelligent message filtering, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).

For more information about how to configure filtering and control spam see "Configuring Filtering and Controlling Spam" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Sender ID Filtering Enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchServerBindingsFiltering property of a Simple Mail Transfer Protocol (SMTP) virtual server object indicates that sender ID filtering is enabled for an SMTP virtual server instance.

The Exchange Server Analyzer also queries Active Directory to determine whether the wWWHomePage attribute of the UCE Content Filter object contains entries for sender ID and connection filtering.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • Sender filtering is enabled at the SMTP virtual server instance.

  • Sender filtering is enabled at the UCE Content Filter object level.

This warning indicates that sender ID filtering is effectively enabled. Sender ID filtering is generally not an issue unless you are troubleshooting mail flow problems involving this particular server. If this is the case, you may want to verify the filter configuration or temporarily disable sender ID filtering to determine whether it is incorrectly blocking mail from valid senders.

To disable a sender ID filter on an SMTP virtual server

  1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In the console tree, expand Servers, expand the server that you want, expand Protocols, and then expand SMTP.

  3. Right-click the SMTP virtual server on which you want to disable the filter, and then click Properties.

  4. In <SMTP Virtual Server> Properties, on the General tab, click Advanced.

  5. In Advanced, select the IP address for which you want to disable the filter, and then click Edit.

  6. In Identification, clear the Apply Sender Filter check box to disable the filter.

  7. If you have multiple virtual servers, repeat Steps 3 through 6 for each virtual server on which you want to disable the filter.

For more information about intelligent message filtering, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).


Server identified as a common destination
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-04

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_Queue Windows® Management Instrumentation (WMI) class to determine the values of the following attributes for the Simple Mail Transfer Protocol (SMTP) queues of the SMTP virtual server.

LinkId | Indicates the identifier for the link that contains the queue.
QueueId | Indicates the identifier of the queue.
QueueName | Indicates the name of the queue.
VirtualMachine | Indicates the name of the virtual machine that contains the queue.
VirtualServerName | Indicates the name of the virtual server that the queue is on.
MessageCount | Indicates the number of messages in the queue.

The Exchange Server Analyzer uses the information obtained here to query the Exchange_QueuedSMTPMessage WMI class for the values of the following attributes of the messages in the queue:

Recipients | Indicates the recipients of the message.
Received | Indicates the received time stamp for the message.
MessageId | Indicates the identifier of the queued message.
StateRetry | Indicates that transmission is being retried for a message that was not delivered successfully.

Finally, the Exchange Server Analyzer uses the data obtained here to query the Active Directory® directory service for the following values of each Recipient object. The Exchange Server Analyzer then determines whether the recipient is a user, a distribution group, a public folder, or a public folder store:

distinguishedName | Indicates the distinguished name of the object.
msExchHomeServerName | Indicates the server the recipient is homed on.
homeMDB | Indicates the mailbox store of the recipient.

If the Exchange Server Analyzer determines that at least 25 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to recipients homed on a particular server, the Exchange Server Analyzer displays a warning.

If the Exchange Server Analyzer determines that at least 50 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to recipients homed on a particular server, the Exchange Server Analyzer displays an error.

This warning or error means that the server that is identified is a common destination for messages that are stuck in an SMTP queue.

To address this issue, the server should be investigated as follows for configuration issues or other anomalies that could cause messages to queue for it:

  • Make sure that the server object attributes are set correctly and contain the correct values in Active Directory.

  • Review the Active Directory permissions of the server object for the correct settings.

  • If the server is the home server for a special use user object, that is, a designated Journaling recipient, review the configurations of the service or components that the user object is related to for correct configuration.

  • Look for possible unsolicited commercial e-mail (UCE), or spam, or virus attacks against the public folder.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

For more information about the effect of distribution group restriction on Exchange Server mail flow, see the following Microsoft Knowledge Base articles:

  • 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

  • 329171 "XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171).

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

  • 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).


Sink Registration Not Found
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-01-11

The Microsoft® Exchange Server Analyzer Tool queries the Microsoft Internet Information Server (IIS) metabase to enumerate the list of Simple Mail Transport Protocol (SMTP) transport event sink bindings. The Exchange Server Analyzer attempts to locate a number of standard event bindings, based on a list pre-populated in the Exchange Server Analyzer. For each binding, the Exchange Server Analyzer verifies the Component Object Model (COM) registration details in the Registry under the following branch:

HKEY_CLASSES_ROOT\CLSID\

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • A transport event sink binding is found in the metabase.

  • The corresponding COM registration is missing from the registry.

An SMTP transport event occurs when message data is transported into or out of the SMTP service. All messages go through events. These include X.400 and RPC incoming or outgoing messages. One common example of an inbound transport event is the arrival of a message to the SMTP service either over the network or in the SMTP pickup directory. When this transport event occurs, a source for this event notifies the transport event sinks, each of which can take some type of action based on the data content of the message. The system performs no other action with the message data after it passes the message data to the sink until the sink completes its action and returns the message. The sink has exclusive control of the message data and state while it performs this action.

Missing COM registrations for transport event sink bindings can cause mail flow problems. If the Exchange Server shows symptoms of mail flow problems such as message queuing, reregister the transport event sinks.

To reregister the transport event sinks

  1. From the Microsoft Exchange Server, open a command prompt window and change to the \Program Files\Exchsrvr\Bin folder.

  2. Type the following commands to re-register transport event sinks:

    regsvr32 /i exps.dll

    regsvr32 /i miscat.dll

    regsvr32 /i onsubmit.dll

    regsvr32 /i peexch50.dll

    regsvr32 /i phatcat.dll

    regsvr32 /i protolog.dll

    regsvr32 /i reapi.dll

    regsvr32 /i regsinks.dll

    regsvr32 /i tranmsg.dll

    regsvr32 /i turflist.dll

    regsvr32 /i xlsasink.dll

    regsvr32 /i msgfilter.dll

  3. Rerun the Exchange Server Analyzer to verify that the warnings are no longer displayed. If event sink registration warnings continue and you experience mail flow problems, contact Microsoft Product Support Services (PSS).

For more information about transport event sink bindings see the following Exchange resources:

  • Microsoft Knowledge Base article 258224, " XCON: Enumerating the Registered Transport Event Sinks" (http://go.microsoft.com/fwlink/?linkID=3052&kbid=258224)

  • "SMTP Service Design" in the Technical Reference Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=58876)


Smart host is set on SMTP virtual server
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchSmtpSmartHost attribute has been configured on a particular SMTP virtual server. If the Exchange Server Analyzer finds that the msExchSmtpSmartHost attribute is configured, the Exchange Server Analyzer displays a warning.

It is not a best practice to configure a smart host on an SMTP virtual server. Instead, you should create an SMTP connector and configure the smart host setting there.

In Exchange Server 2003, use Internet Mail Wizard to configure Internet mail delivery. For more information, in the Exchange Server Transport and Routing Guide, see "How to Use Internet Mail Wizard" (http://go.microsoft.com/fwlink/?LinkId=50099).

For more information about how to create SMTP connectors, in the Exchange Server Transport and Routing Guide, see "How to Create an SMTP Connector" (http://go.microsoft.com/fwlink/?LinkId=50100).


The SMTP AdditionalPoolThreadsPerProc registry value has been manually set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if additional pool threads have been manually configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters\AdditionalPoolThreadsPerProc

If the Exchange Server Analyzer finds AdditionalPoolThreadsPerProc to be present and configured, a non-default configuration message is displayed.

There are five work queues in SMTP that use a pool of threads known as the ATQ threads. By design, two of these queues can, by default, use up to 90 percent of the available threads. This thread pool is shared by the process accepting POP and IMAP requests. Therefore, in a moderate to high load scenario, a situation can arise where SMTP can keep resources from POP and IMAP services.

You can reserve adequate threads for POP and IMAP by limiting the percentage of threads SMTP can use. To make this change, increase the overall number of threads available to IIS. The only tradeoff here is increased memory usage for the additional threads.

There are two registry values that allow you to control the SMTP percentage of threads and additional threads per processor:

Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Parameters

Value: AdditionalPoolThreadsPerProc

Type: REG_DWORD

Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Parameters

Value: MaxPercentPoolThreads

Type: REG_DWORD

Both registry values should be adjusted on clustered Exchange Server computers if high SMTP activity causes POP3, IMAP4 or both resources to fail. You can use the following formulas to calculate the optimum value for your cluster:

Registry Value | Formula
AdditionalPoolThreadsPerProc | ((9 / (MaxPercentPoolThreads/100)) - 4) / 2
MaxPercentPoolThreads | 90 / (2 * Number of protocol virtual servers)

For example, in an Exchange Server cluster with two protocol virtual servers, the formula for MaxPercentPoolThreads is 90 / (2*2) = 22. When calculating the MaxPercentPoolThreads value, if your calculations result in a value that includes a decimal point, you should round the result down to the next integer. When calculating the AdditionalPoolThreadsPerProc value, if your calculations result in a value that is greater than 200, you will also need to assign the resulting value to an additional registry value:

Location: HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\

Value: PoolThreadLimit

Type: REG_DWORD

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the optimal setting on your Exchange cluster

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. Create a DWORD registry value called AdditionalPoolThreadsPerProc and set its value data to the appropriate number based on the above formulas.

  4. Create a DWORD registry value called MaxPercentPoolThreads and set its value data to the appropriate number based on the above formulas.

  5. Close the registry editor and restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the specific cluster resource issue described in this article, see Microsoft Knowledge Base article 281868, "XADM: POP\IMAP4 Virtual Servers Repeatedly Fail Over Under High Load" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=281868).


SMTP Archive Sink: Archive P1 headers set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the SMTP Archive Sink has been installed and enabled:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Dump P1

If the Exchange Server Analyzer finds that the value for Dump P1 is greater than 0, a non-default configuration message is displayed.

A value of 0 indicates that P1 header archiving is disabled. A value of 1 indicates that P1 header archiving is enabled. Values other than 0 or 1 are not supported.

The SMTP Archive Sink tool is a custom script that enables the archiving of all messages coming into and moving out of a specific folder on an Exchange server. By default, when the SMTP Archive Sink is enabled, all messages and their recipients are archived to an .eml file, except for Bcc recipients.

P1 headers are also referred to as "envelope" data. The envelope data is the actual recipient list that Exchange generates as a message is in transit that enables a message to reach all recipients. Unlike the P2 headers, which are the recipients as declared by the sender in a particular piece of received mail, the envelope data changes as it travels to the many destinations. These changes occur because of distribution list expansion and hidden distribution list behavior.

By default, P1 headers are not archived when you install and enable the SMTP Archive Sink. Typically, P1 header archiving is enabled only for troubleshooting purposes.

If you do not want to archive P1 headers on this Exchange computer, you can set the Dump P1 registry key to 0, or you can uninstall the SMTP Archive Sink. When you uninstall the SMTP Archive Sink, all registry keys used by SMTP Archive Sink are deleted.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To disable P1 header archiving

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. Double-click the registry key Dump P1, in the Value data field, enter 0, and then click OK.

  4. Close the registry editor, and restart the IIS Admin Service for the changes to take effect.

To uninstall the SMTP Archive Sink

  1. Click Start, click Run, type cmd, and then click OK.

  2. In the C:\Program Files\Exchsrvr\bin folder, type cscript archivesink_setup.vbs, and then press Enter.

  3. Type cscript archivesink_setup.vbs uninstall Virtual Server ID, where Virtual Server ID is the virtual server number of the virtual server where the SMTP Archive Sink is installed.

  4. Exit the Command Prompt window, and restart the IIS Admin Service for the changes to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting up and configuring the SMTP Archive Sink in Exchange Server 2003, see Knowledge Base article 871110, "How to install and use the Archive Sink utility in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110).

For more information about setting up and configuring the SMTP Archive Sink in Exchange 2000 Server, see Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=307798).

For information about deploying a comprehensive journaling solution for the purposes of regulatory compliance, see Journaling with Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47581).


SMTP Archive Sink enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the SMTP Archive Sink has been installed and enabled:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Enable Smtp Messages

If the Exchange Server Analyzer finds that the value for Enable Smtp Messages is greater than 0, a non-default configuration message is displayed.

A value of 0 indicates that the SMTP Archive Sink is disabled. A value of 1 indicates that the SMTP Archive Sink is enabled. Values other than 0 or 1 are not supported.

The SMTP Archive Sink tool is a custom script that enables the archiving of all messages coming into and moving out of a specific folder on an Exchange server. By default, when SMTP Archive Sink is enabled, all messages and their recipients are archived to an .eml file, except for Bcc recipients.

By default, when you enable SMTP archiving with the SMTP Archive Sink, all messages submitted to transport by Simple Mail Transfer Protocol (SMTP), by the Exchange store, or by any other sinks trigger this event. Theoretically, this event can be raised one time for each message, and this event can be archived only one time. The OnMessageSubmission event is raised before the routing or categorizer events. Therefore, these messages are referred to as PreCat messages. By default, messages are archived for this event when the SMTP Archive Sink tool is installed. Messages that are archived for this event contain the prefix file name: ARCH_random number.xml.

If you do not want to archive messages on this Exchange computer, you can set the Enable Smtp Messages registry key to 0, or you can uninstall the SMTP Archive Sink. When you uninstall the SMTP Archive Sink, all registry keys used by SMTP Archive Sink are deleted.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To disable the SMTP Archive Sink

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. Double-click the registry key Enable Smtp Messages, in the Value data field, enter 0, and then click OK.

  4. Exit the registry editor, and restart the IIS Admin Service to make the changes take effect.

To uninstall the SMTP Archive Sink

  1. Click Start, click Run, type cmd, and then click OK.

  2. In the C:\Program Files\Exchsrvr\bin folder, type cscript archivesink_setup.vbs, and then press Enter.

  3. Type cscript archivesink_setup.vbs uninstall Virtual Server ID, where Virtual Server ID is the virtual server number of the virtual server where the SMTP Archive Sink is installed.

  4. Exit the Command Prompt window, and restart the IIS Admin Service to make the changes take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting up and configuring the SMTP Archive Sink in Exchange Server 2003, see Knowledge Base article 871110, "How to install and use the Archive Sink utility in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110).

For more information about setting up and configuring the SMTP Archive Sink in Exchange 2000 Server, see Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=307798).

For more information about deploying a comprehensive journaling solution for the purposes of regulatory compliance, see Journaling with Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47581).


SMTP Archive Sink: Post-categorization set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the SMTP Archive Sink has been installed and enabled:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Enable PostCat

If the Exchange Server Analyzer finds that the value for Enable PostCat is greater than 0, a non-default configuration message is displayed.

A value of 0 indicates that post-categorization message archiving is disabled. A value of 1 indicates that post-categorization message archiving is enabled. Values other than 0 or 1 are not supported.

The SMTP Archive Sink tool is a custom script that enables the archiving of all messages coming into and moving out of a specific folder on an Exchange server. By default, when SMTP Archive Sink is enabled, all messages and their recipients are archived to an .eml file, except for Bcc recipients.

When Enable PostCat is set to 1, messages are archived after the categorization of a message occurs. Messages can trigger this event more than one time, but this can occur only when a message has been categorized, queued, and then enumerated again. Messages that are archived for this event contain the prefix file name ARCH_POSTCAT_random number.xml.

If you do not want to archive post-categorization messages on this Exchange computer, you can set the Enable PostCat registry key to 0. If you do not want to archive at all on this computer, you can uninstall the SMTP Archive Sink. When you uninstall the SMTP Archive Sink, all registry keys used by SMTP Archive Sink are deleted.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To disable post-categorization message archiving

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. Double-click the registry key Enable PostCat, in the Value data field, enter 0, and then click OK.

  4. Exit the registry editor, and restart the IIS Admin Service to make the changes take effect.

To uninstall the SMTP Archive Sink

  1. Click Start, click Run, type cmd, and then click OK.

  2. In the C:\Program Files\Exchsrvr\bin folder, type cscript archivesink_setup.vbs, and then press Enter.

  3. Type cscript archivesink_setup.vbs uninstall Virtual Server ID, where Virtual Server ID is the virtual server number of the virtual server where the SMTP Archive Sink is installed.

  4. Exit the Command Prompt window, and restart the IIS Admin Service to make the changes take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting up and configuring the SMTP Archive Sink on Exchange Server 2003, see Knowledge Base article 871110, "How to install and use the Archive Sink utility in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110).

For more information about setting up and configuring the SMTP Archive Sink on Exchange 2000 Server, see Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=307798).

For information about deploying a comprehensive journaling solution for the purposes of regulatory compliance, see Journaling with Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47581).


SMTP Archive Sink: Pre-categorization set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the SMTP Archive Sink has been installed and enabled:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Enable PreCat

If the Exchange Server Analyzer finds that the value for Enable PreCat is greater than 0, a non-default configuration message is displayed.

A value of 0 indicates that pre-categorization message archiving is disabled. A value of 1 indicates that pre-categorization message archiving is enabled. Values other than 0 or 1 are not supported.

The SMTP Archive Sink tool is a custom script that enables the archiving of all messages coming into and moving out of a specific folder on an Exchange server. By default, when SMTP Archive Sink is enabled, all messages and their recipients are archived to an .eml file, except for Bcc recipients.

All messages submitted to transport by Simple Mail Transfer Protocol (SMTP), by the Exchange store, or by any other sinks trigger this event. Theoretically, this event can be raised one time for each message, and this event can be archived only one time. The OnMessageSubmission event is raised before the routing or categorizer events. Therefore, these messages are referred to as PreCat messages. By default, messages are archived for this event when the SMTP Active Sink utility is installed. Messages that are archived for this event contain the prefix file name ARCH_random number.xml.

If you do not want to archive pre-categorization messages on this Exchange computer, you can set the Enable PreCat registry key to 0. If you do not want to archive at all on this computer, you can uninstall the SMTP Archive Sink. When you uninstall the SMTP Archive Sink, all registry keys used by SMTP Archive Sink are deleted.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To disable pre-categorization message archiving

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. Double-click the registry key Enable PreCat, in the Value data field, enter 0, and then click OK.

  4. Close the registry editor, and restart the IIS Admin Service to make the changes take effect.

To uninstall the SMTP Archive Sink

  1. Click Start, click Run, type cmd, and then click OK.

  2. In the C:\Program Files\Exchsrvr\bin folder, type cscript archivesink_setup.vbs, and then press Enter.

  3. Type cscript archivesink_setup.vbs uninstall Virtual Server ID, where Virtual Server ID is the virtual server number of the virtual server where the SMTP Archive Sink is installed.

  4. Exit the Command Prompt window, and restart the IIS Admin Service to make the changes take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting up and configuring the SMTP Archive Sink in Exchange Server 2003, see Knowledge Base article 871110 "How to install and use the Archive Sink utility in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110).

For more information about setting up and configuring the SMTP Archive Sink in Exchange 2000 Server, see Knowledge Base article 307798 "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=307798).

For information about deploying a comprehensive journaling solution for the purposes of regulatory compliance, see Journaling with Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47581).


SMTP Archive Sink: System messages are being archived
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the SMTP Archive Sink has been installed and enabled:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Archive System Messages

If the Exchange Server Analyzer finds that the value for Archive System Messages is greater than 0, a non-default configuration message is displayed.

A value of 0 indicates that system messages are not archived. A value of 1 indicates that system messages are archived. Values other than 0 or 1 are not supported.

The SMTP Archive Sink tool is a custom script that enables the archiving of all messages coming into and moving out of a specific folder on an Exchange server. By default, when SMTP Archive Sink is enabled, all messages and their recipients are archived to an .eml file, except for Bcc recipients.

If you do not want to archive system messages on this Exchange computer, you can set the Archive System Messages registry key to 0. If you do not want to archive at all on this computer, you can uninstall the SMTP Archive Sink. When you uninstall the SMTP Archive Sink, all registry keys used by SMTP Archive Sink are deleted.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To disable system message archiving

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. Double-click the registry key Archive System Messages, in the Value data field, enter 0, and then click OK.

  4. Close the registry editor, and restart the IIS Admin Service for the changes to take effect.

To uninstall the SMTP Archive Sink

  1. Click Start, click Run, type cmd, and then click OK.

  2. In the C:\Program Files\Exchsrvr\bin folder, type cscript archivesink_setup.vbs, and then press Enter.

  3. Type cscript archivesink_setup.vbs uninstall Virtual Server ID, where Virtual Server ID is the virtual server number of the virtual server where the SMTP Archive Sink is installed.

  4. Close the Command Prompt window, and restart the IIS Admin Service for the changes to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting up and configuring the SMTP Archive Sink in Exchange Server 2003, see Knowledge Base article 871110, "How to install and use the Archive Sink utility in Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110).

For more information about setting up and configuring the SMTP Archive Sink in Exchange 2000 Server, see Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=307798).

For information about deploying a comprehensive journaling solution for the purposes of regulatory compliance, see Journaling with Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47581).


SMTP BadMail data is being written to a compressed folder
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Compressed key for the Simple Mail Transfer Protocol (SMTP) BadMail folder. If the Exchange Server Analyzer finds the value for Compressed set to True, a warning is displayed.

When messages arrive at the Exchange computer through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are stored in the <drive>:\Program Files\Exchsrvr\Mailroot folder on the same partition that Exchange is installed on. If the folder where the SMTP badmail data is stored has file compression turned on, Exchange performance may be severely degraded. Therefore, compression in the folder where the SMTP BadMail data is stored is not supported.

If you receive this warning, you must turn off compression on the folder where the SMTP badmail data is stored, or you must move the SMTP badmail data to a folder that is not compressed.

Microsoft does not support the storage of Exchange data files on a compressed volume. When you store your Exchange data files on a compressed volume, the additional overhead significantly impacts the performance of Exchange. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To turn off file compression on a given folder

  1. Right-click the folder where you want to turn off file compression, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Compress contents to save disk space check box, and then click OK.

To move the BadMail folder on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Click Administrative Groups, expand your administrative group, expand Servers, expand your server, expand Protocols, and then expand SMTP.

  3. Right-click your SMTP virtual server, and then click Stop.

  4. Right-click your SMTP virtual server, and then click Properties.

  5. On the Messages tab, next to the BadMail directory box, click Browse, and then type the path of the new location of the Queue folder.

  6. Click OK.

  7. Right-click your SMTP virtual server, and then click Start.

For more information about moving the Mailroot folder, see the Microsoft Knowledge Base article 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933).


SMTP BadMail data is being written to a non-NTFS partition
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FSName key for Exchange SMTP BadMail directory. If the Exchange Server Analyzer determines that the value for the FSName key does not equal NTFS, a warning is displayed.

Microsoft does not support the storage of Exchange data files on non-NTFS volumes. Exchange data files include the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

If you see this warning, you must move the SMTP BadMail directory to a folder on an NTFS file system drive. Alternatively, if the drive on which the BadMail directory is stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS.

To move the SMTP BadMail directory to another folder

  1. Start Exchange System Manager.

  2. Click Administrative Groups, expand your administrative group, expand Servers, expand your server, expand Protocols, and then expand SMTP.

  3. Right-click your SMTP virtual server, and then click Stop.

  4. Right-click your SMTP virtual server, and then click Properties.

  5. On the Messages tab, next to the BadMail directory box, click Browse, and then type the path of the new location of the BadMail folder.

  6. Click OK.

  7. Right-click your SMTP virtual server, and then click Start.

For more information about moving the Mailroot folder, see the Microsoft Knowledge Base article 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933).

As an alternative to the procedure, if the drive on which the files are stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS. For information about using the convert.exe command-line tool to convert a FAT partition to an NTFS partition, see the Microsoft Knowledge Base article 214579, "How to Use Convert.exe to Convert a Partition to the NTFS File System" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579).


SMTP BadMail data is being written to an encrypted folder
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Encrypted key for the SMTP BadMail folder. If the Exchange Server Analyzer finds the value for Encrypted set to True, a warning is displayed.

When messages arrive at the Exchange computer through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are stored in the <drive>:\Program Files\Exchsrvr\Mailroot folder on the same partition that Exchange is installed on. If the folder where the SMTP BadMail data is stored has file encryption turned on, Exchange performance may be severely degraded. Therefore, encrypting the folder where the SMTP BadMail data is stored is not supported.

If you receive this warning, you must turn off encryption on the folder where the SMTP BadMail data is stored, or you must move the SMTP BadMail data to a non-encrypted folder.

Microsoft does not support the storage of Exchange data files on an Encrypting File System (EFS) encrypted volume. When you store your Exchange data files on an encrypted volume, the additional overhead significantly affects Exchange performance. Exchange data files include the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To help secure your Exchange data files, it is recommended that you prevent unauthorized access to the Exchange computer and that you use the S/MIME message format to encrypt message data.

To resolve this error, you must either turn off file encryption on the BadMail folder, or move the BadMail folder to a location where encryption is not enabled.

To turn off file encryption on a given folder

  1. Right-click the folder where you want to turn off file encryption, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Encrypt contents to secure data check box, and then click OK.

To move the BadMail folder on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Click Administrative Groups, expand your administrative group, expand Servers, expand your server, expand Protocols, and then expand SMTP.

  3. Right-click your SMTP virtual server, and then click Stop.

  4. Right-click your SMTP virtual server, and then click Properties.

  5. On the Messages tab, next to the BadMail directory box, click Browse, and then type the path of the new location of the Queue folder.

  6. Click OK.

  7. Right-click your SMTP virtual server, and then click Start.

For more information about moving the Mailroot folder, see the Microsoft Knowledge Base article 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933).

For more information about Exchange Server data files and EFS, see the Microsoft Knowledge Base article 834638, "Information about the storage of data files on an encrypted volume in Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638).

For information about how to secure messages in Exchange Server 2003, see the Exchange Server 2003 Message Security Guide (http://go.microsoft.com/fwlink/?linkid=47574).


The SMTP CatRetryMinutes registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether default SMTP queuing configurations have been changed:

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

If the Exchange Server Analyzer finds that the CatRetryMinutes key has been set, the Exchange Server Analyzer displays a non-default message.

It is recommended that the default queuing values be modified only after complete consideration. The defaults were carefully selected for optimal performance in most environments. A general best practice is to address the root cause of the problem instead of modifying the queuing behavior on Exchange Server.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about Exchange SMTP queuing, see the Microsoft Exchange Team Blog entry, "Explaining the Mysterious SMTP Advanced Queuing Engine" (http://go.microsoft.com/fwlink/?LinkId=48585).


SMTP configuration warning
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-03

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the value for the msExchSmtpMaxMessageSize.attribute has been changed from the default value of 0. By default, the msExchSmtpMaxMessageSize attribute is configured for unlimited message size.

The Exchange Server Analyzer displays a warning if the following conditions exist:

  • The msExchSmtpMaxMessageSize attribute does not have a value of 0.

  • Exchange is not running on Microsoft Windows® Small Business Server 2003.

The msExchSmtpMaxMessageSize attribute represents the maximum size of each SMTP message that can be sent or received. From a security perspective, it is a best practice to limit the maximum size of SMTP messages that can be sent to and received from the Internet. However, for internal SMTP messages, such as those that travel between Exchange servers in the same organization, it is recommended that you leave the msExchSmtpMaxMessageSize attribute set to 0.

Internally, Exchange uses SMTP messages to handle tasks such as public folder replication. If the msExchSmtpMaxMessageSize attribute is configured to have too low a limit, this limit could cause public folder replication problems and other intra-organizational message delivery failures.

If this Exchange server is a bridgehead server that transfers SMTP messages to and from the Internet, you may be able to safely ignore this warning. If this Exchange server handles internal SMTP messages, you should change the value for the msExchSmtpMaxMessageSize attribute back to its default setting of 0.

Note:
If you set the message size limit too low, it could prevent offline address book replication between Exchange Server computers. For more information, see Microsoft Knowledge Base article 326154, "You cannot download the offline address book in Microsoft Outlook in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=326154).
To view and configure the maximum SMTP message size

  1. In Exchange System Manager, expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  2. Right-click an SMTP virtual server, for example, Default SMTP Virtual Server, and then select Properties.

  3. Select the Messages tab.

  4. To revert to the default setting of 0, clear the Limit message size to (KB) check box. Alternatively, leave this box checked and configure any value that you want.

  5. Click OK to save the changes and to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686).

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163).


SMTP connector with distribution group delivery restrictions set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool queries the following attributes for each Simple Mail Transfer Protocol (SMTP) Connector object (msExchRoutingSMTPConnector) detected in the Active Directory® directory service to determine whether they have delivery restrictions set based on distribution group membership.

dLMemRejectPerms | Contains the domain names (DNs) of distribution lists (DL) whose members may not send through this SMTP Connector
dLMemSubmitPerms | Contains the domain names (DNs) of distribution lists (DL) whose members may send through this SMTP Connector

If the Exchange Server Analyzer determines that there are SMTP Connectors that have delivery restrictions set based on distribution group membership, the Exchange Server Analyzer displays a warning.

This warning indicates that delivery restrictions based on distribution group membership may affect Exchange mail flow performance.

When you send mail by using SMTP Connectors that have delivery restrictions set based on distribution group membership, the message categorizer must expand the membership of the distribution group, obtain the full list of DNs of the members, and then compare the list of DNs to the list sender's DNs. An access operation or a deny operation occurs when a DN on both lists match. If a distribution group is nested in another distribution group, the nested distribution is also expanded.

To address this warning:

  • Design a dedicated Routing Group for connector restrictions and configure it to a local Routing Group as referenced in Microsoft Knowledge Base article 329171, "XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171).

  • Use a dedicated and more robust global catalog server as the designated bridgehead server for the connector.

  • Configure individual mailboxes and not distribution groups for delivery restrictions as referenced in Microsoft Knowledge Base article 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).

  • Consider implementing SMTP sender filtering.

  • For servers that run Exchange Server 2003 Service Pack 2 (SP2) or a later version, consider implementing non-hierarchal restriction checking. For servers that run Exchange versions earlier than Exchange 2003 SP2, consider upgrading to Exchange 2003 SP2.

For More Information

For more information about non-hierarchal restriction checking, see Consider non-hierarchical restriction checking.

For more information about SMTP sender filtering, see "How to Enable Sender Filtering" in the Administration Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=72967).

For more information about the effect of distribution group restriction on Exchange mail flow, see the following Microsoft Knowledge Base articles:

  • 329171 " XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171)

  • 895407 "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

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


SMTP domain re-writing is enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the value for the heuristics attribute on the SMTP Virtual Server object for this Exchange server. If the Exchange Server Analyzer finds that the value of the heuristics attribute is not the default value of 131072, an error is displayed.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about the Exchange Server Address Rewrite tool, see Exchange Server Address Rewrite (http://go.microsoft.com/fwlink/?LinkId=25932).


The SMTP FailedMsgQRetryMinutes registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether default SMTP queuing configurations have been changed:

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

If the Exchange Server Analyzer finds that the FailedMsgQRetryMinutes key has been set, the Exchange Server Analyzer displays a non-default message.

It is recommended that the default queuing values be modified only after complete consideration. The defaults were carefully selected for optimal performance in most environments. A general best practice is to address the root cause of the problem instead of modifying the queuing behavior on Exchange Server.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about Exchange SMTP queuing, see the Microsoft Exchange Team Blog entry, "Explaining the Mysterious SMTP Advanced Queuing Engine" (http://go.microsoft.com/fwlink/?LinkId=48585).


The SMTP LocalDeliveryMaxBatch registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the default setting on the LocalDeliveryMaxBatch registry value has been changed:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\StoreDriver\Exchange\%SMTPVirtualServerInstance%.

If the Exchange Server Analyzer finds that the LocalDeliveryMaxBatch registry value setting is manually created, changing the default Exchange server binary setting of 80, the Exchange Server Analyzer displays a non-default warning message.

By default, the LocalDeliveryMaxBatch registry value is not created during an Exchange Server installation. The LocalDeliveryMaxBatch registry value can be manually created after the Exchange Server installation to change how the Exchange Information Store internally processes and delivers messages. The Exchange server may experience problems with message transport and store performance if the following conditions are true:

  • The LocalDeliveryMaxBatch registry value is manually created.

  • The LocalDeliveryMaxBatch registry value setting is configured incorrectly.

It is recommended that the LocalDeliveryMaxBatch registry value be created or modified only after careful consideration. The default values, in the binaries, for Exchange server were carefully selected for optimal performance for use in most Exchange server environments. A general best practice is to address the root cause of the problem instead of modifying the default behavior of Exchange Server by manually configuring the registry. To comply with best practices, if the LocalDeliveryMaxBatch registry value already exists, you may want to delete this registry value to configure the Exchange server back to the default binary setting.

The Exchange Server Analyzer reports this configuration for informational purposes only. However, you may want to change the registry value back to the default setting by editing the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To correct this warning

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\StoreDriver\Exchange\%SMTPVirtualServerInstance%

  3. In the details pane, right-click the LocalDeliveryMaxBatch registry value, click Modify, and then change the Value data to 80. Click OK.

    Note:
    To delete the LocalDeliveryMaxBatch registry value, in the details pane, right-click the LocalDeliveryMaxBatch registry value and then click Delete. Confirm the deletion of the registry value by clicking Yes in the dialog box.

  4. Close the registry editor.

  5. Restart the Exchange server.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about editing the Microsoft Windows registry, see the following Microsoft Knowledge Base articles:

  • 322755, "How to back up, edit, and restore the registry in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 322756, "How to back up, edit, and restore the registry in Windows XP and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756 )


SMTP instance FQDN does not match DNS resolved server name
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-04

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service for the value of the msExchSmtpFullyQualifiedDomainName attribute from the Default Simple Mail Transfer Protocol (SMTP) virtual server object.

The Exchange Server Analyzer also tries a Domain Name System (DNS) query against the configured DNS servers for the Fully Qualified Domain Name (FQDN) of the server that is running Exchange Server. This connection is made with a custom object processor that performs a name resolution request and analyzes the results.

The Exchange Server Analyzer compares the results of the two queries. If the value of the msExchSmtpFullyQualifiedDomainName attribute from the Default Simple Mail Transfer Protocol (SMTP) virtual server object does not match the DNS FQDN of the Exchange server, the Exchange Server Analyzer displays a warning.

This warning indicates that the values of these attributes may have been manually changed. Therefore, these changed values might contribute to mail flow problems on this server.

The value of the msExchSmtpFullyQualifiedDomainName attribute specifies the FQDN for the SMTP virtual server and must be resolvable by the Domain Name System (DNS) networking protocol.

A valid DNS HOST (A) record must exist for the value of this attribute so that messaging servers that try to resolve the FQDN of the SMTP virtual server can retrieve the correct IP address and route mail appropriately.

To address this warning, determine whether the values were intentionally changed for a valid purpose. If the values were changed for a valid purpose, take one of the following steps:

  • Change the value of the msExchSmtpFullyQualifiedDomainName attribute to match the DNS FQDN.

  • Configure the Exchange Server DNS FQDN to match the value of the msExchSmtpFullyQualifiedDomainName attribute.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To update the value of the msExchSMTPFullyQualifiedDomainName attribute

  1. Open Exchange System Manager.

  2. Expand Administrative Groups, expand Servers, expand the Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click the default SMTP virtual server and select Properties.

  4. Select the Delivery tab, and then click Advanced.

  5. Under Fully qualified domain name, enter the value for the msExchSmtpFullyQualifiedDomainName attribute.

  6. Click OK to save the changes, and then click OK to close the Properties dialog box of the SMTP virtual server.
To configure the DNS FQDN of the Exchange Server

  1. Follow the guidance in How to Configure Settings on the DNS Server.

For more information about the reverse DNS lookup feature in Exchange, see "Add a resource record to a DNS zone" (http://go.microsoft.com/fwlink/?LinkId=63002).

For more information about SMTP virtual server settings, see the following Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686).

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163).

For more information about SMTP Service Design, see "SMTP Service Design" in the Technical Reference Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=58876).


SMTP instance with no outbound SMTP connector set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-22

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service for the distingushedName attribute value of the protocolCfgSMTPServer object class to list all Simple Mail Transfer Protocol (SMTP) virtual server instances on the user-specified Exchange gateway.

The Exchange Server Analyzer then queries Active Directory for the value of the msExchSourceBridgeheadServersDN and routingList attributes for each msExchRoutingSMTPConnector object that is found to determine whether an SMTP connector has one of the detected SMTP virtual server instances set as its local bridgehead to an external SMTP address space.

An SMTP connector designates an isolated route for mail. You can use SMTP connectors to establish a gateway for Internet mail or to connect to a specific domain or mail system. Connectors let you define specific options for the designated mail route.

If the Exchange Server Analyzer determines that there are no SMTP connectors with an SMTP virtual server instance from the specified Exchange gateway server set as its local bridgehead server, the Exchange Server Analyzer displays a warning.

This warning indicates that servers other than the user-specified Exchange gateway server may unintentionally route messages outside the organization.

You may want to create an SMTP connector that designates an SMTP virtual server instance on the specified Exchange gateway server as its bridgehead to avoid this condition in which servers other than the user-specified Exchange gateway server can unintentionally route messages outside the organization.

Although you can send and receive Internet mail by using just an SMTP virtual server, it is a recommended best practice to configure a dedicated SMTP connector for routing Internet mail. Use of an SMTP connector is recommended because it provides an isolated route for mail that is destined to the Internet. In addition, more configuration options are available on an SMTP connector than on the SMTP virtual server.

For more information about how to use SMTP connectors, see Microsoft Knowledge Base article 294736, "When to create SMTP connectors in Exchange 2000 and later" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=294736).

For more information about SMTP connectors, see the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


The SMTP LocalRetryMinutes registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether default SMTP queuing configurations have been changed:

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

If the Exchange Server Analyzer finds that the LocalRetryMinutes key has been set, the Exchange Server Analyzer displays a non-default message.

It is recommended that the default queuing values be modified only after complete consideration. The defaults were carefully selected for optimal performance in most environments. A general best practice is to address the root cause of the problem instead of modifying the queuing behavior on Exchange.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about Exchange SMTP queuing, see the Microsoft Exchange Team Blog entry, "Explaining the Mysterious SMTP Advanced Queuing Engine" (http://go.microsoft.com/fwlink/?LinkId=48585).


The SMTP FileCacheLifeTimeSeconds registry value has been manually added but may no longer be needed
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the default time to live for each cached Internet Information Services (IIS) file handle has been modified from the default value of 1,880 seconds (30 minutes):

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters\FileCacheLifeTimeSeconds

If the Exchange Server Analyzer finds FileCacheLifeTimeSeconds to be present and configured with an alternate value, a non-default configuration message is displayed.

The FileCacheLifeTimeSeconds value specifies the time to live for cached IIS file handles. File handles are cached to improve performance because cached file handles save the server from performing redundant input/output (I/O) and CPU cycles. Each time the SMTP transport stack on an Exchange Server computer receives a message, it is streamed out to the file system where it waits to be routed to its destination. To write to the file system, the SMTP transport stack obtains a file handle and then passes the message into that handle. Each file handle consumes approximately 2 kilobytes (KB) of paged pool memory. The default number of IIS cache file handles is 800 for every 32 MB.

This registry value is not present by default, because Exchange 2000 Server Service Pack 2 (SP2) and later and Exchange Server 2003 are configured to cache an optimal number of file handles. Exchange Server 2003 dynamically calculates the appropriate settings for SMTP files handles, so these settings are no longer needed. Therefore, before upgrading any Exchange 2000 Server computers with these settings to Exchange Server 2003, you should delete these entries from the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

  3. In the right-hand pane, delete the FileCacheLifeTimeSeconds value.

  4. Close the registry editor and restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


The SMTP FileCacheMaxHandles registry value has been manually added but may no longer be required
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the maximum number of Internet Information Services (IIS) file cache handles has been modified from the default value of 800:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters\FileCacheMaxHandles

If the Exchange Server Analyzer finds FileCacheMaxHandles to be present and configured with a value other than 800, a non-default configuration message is displayed.

The FileCacheMaxHandles value specifies the maximum number of IIS file handles used by Exchange for every 32 megabytes (MB) of physical memory. File handles are cached to improve performance because cached file handles save the server from performing redundant input/output (I/O) and CPU cycles. Every time the SMTP transport stack on an Exchange Server computer receives a message, it is streamed out to the file system where it waits to be routed to its destination. To write to the file system, the SMTP transport stack obtains a file handle and then passes the message to that handle. Each file handle consumes approximately 2 kilobytes (KB) of paged pool memory. The default number of IIS cache file handles is 800 for every 32 MB.

Before Service Pack 2 (SP2) for Exchange 2000 Server, Exchange servers that sustained large SMTP message queues (for example, an average of 1,000 or more messages) performance constraints have been historically encountered because of a default setting on the SMTP service of a maximum of 1,000 file handles. Because Exchange 2000 Server defaulted to a maximum of 1,000 file handles, the SMTP service could only write 1,000 simultaneous messages to the file system.

To improve performance for these large systems, three registry entries were frequently simultaneously adjusted to increase the maximum number of file handles that could be opened by the SMTP service (so that more messages could be processed) and to decrease the number of open file handles for the installable file system, another Exchange component (to avoid running out of memory when the queue is large). These registry values, which did not exist by default and therefore needed to be manually added, are listed below:

Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing

Value: MsgHandleThreshold

Type: REG_DWORD

Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing

Value: MsgHandleAsyncThreshold

Type: REG_DWORD

Location: HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

Value: FileCacheMaxHandles

Type: REG_DWORD

The MsgHandleThreshold and MsgHandleAsyncThreshold entries are typically tuned to the same value (usually a value greater than 1,000) and the FileCacheMaxHandles value is usually reduced from 800 to 600.

This registry value is not present by default because Exchange 2000 Server Service Pack 2 (SP2) and later dynamically determines the optimal values to use. If this Exchange server is running Exchange 2000 Server with Service Pack 1 or earlier, it is recommended as a best practice that you upgrade to the latest level of service pack and Roll-up package. As soon as you have upgraded to the latest code, you can delete these registry entries.

Exchange Server 2003 dynamically calculates the appropriate settings for SMTP file handles, so these settings are no longer needed. Therefore, before upgrading any Exchange 2000 Server computers with these settings to Exchange Server 2003, you should delete these entries from the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

  3. Delete the FileCacheMaxHandles value.

  4. Close the registry editor and restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


The SMTP GlitchRetrySeconds registry value has been manually set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the default glitch retry wait time has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\GlitchRetrySeconds

If the Exchange Server Analyzer finds GlitchRetrySeconds to be present and configured, a non-default configuration message is displayed.

If Exchange 2000 Server or Exchange Server 2003 tries to route a message to a heavily loaded external SMTP system, it can receive a Server busy error. When this happens, Exchange goes into a state known as "glitch retry." In this state, Exchange waits 60 seconds before attempting to resend the message, and it repeats this process three times before resorting to other actions. If external SMTP servers are consistently busy, it is recommended that you reduce the glitch retry wait time to prevent mass message queuing.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. In the right-hand pane, delete the GlitchRetrySeconds value. Alternatively, you can reduce the value for the GlitchRetrySeconds if mass queuing is occurring.

  4. Close the registry editor and restart the Simple Mail Transfer Protocol (SMTP) service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, read Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


The SMTP IgnorePFTimeLimit registry value has been manually set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the number of days that the SMTP service routing engine bypasses the new public folder store has been manually set:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters\IgnorePFTimeLimit

If the Exchange Server Analyzer finds IgnorePFTimeLimit to be present and configured, a non-default configuration message is displayed.

When a new public folder store is brought online, you may notice in the Queue Viewer that the local delivery queue is growing. If the public folder hierarchy is large, the messages in the local queue continue to grow and may take additional time to be delivered. In some cases, the messages may not be delivered.

When the new server is introduced, its distinguished name is added to the msExchOwningPFTreeBL attribute of the administrative group's Folder Hierarchies Public Folder object in the Active Directory® directory service. When the categorizer for the server that receives messages bound for public folders reads the msExchOwningPFTreeBL attribute, it should first select the local public folder store, if it exists. For load balancing, it then selects the public folder stores in the order that they are listed. Because the new server is listed first, the messages are routed to it, where they are added to the new server's local delivery queue. If a public folder store has not received a copy of the hierarchy, the server cannot route the messages to a store that owns a copy of the destination folder.

You can avoid this issue by adding the IgnorePFTimeLimit value to the registry of the new public folder server. This will specify the number of days that the routing engine bypasses the new public folder store.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. In the right-hand pane, delete IgnorePFTimeLimit.

  4. Close the registry editor, and then restart the IIS Admin service for the change to take effect.

For more information about the issue and the IgnorePFTimeLimit registry value described in this article, see Microsoft Knowledge Base article 328870, "XADM: Public Folder Routing is Enabled Before the Hierarchy is Replicated" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328870).

Before you edit the registry, and for information about how to edit the registry, read Microsoft Knowledge Base Article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


SMTP instance has multiple port bindings configured
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchServerBindings attribute has been changed from the default value of 25 or if multiple values have been set. By default, the msExchServerBindings attribute is configured for TCP port 25. If the Exchange Server Analyzer finds that this attribute has more than one value set, a non-default configuration message is displayed together with the name of the virtual Simple Mail Transfer Protocol (SMTP) server that has multiple values set.

The msExchServerBindings attribute represents the TCP port on which this SMTP server listens for inbound connections. SMTP virtual servers can be configured to listen on one or more TCP ports. By default, all SMTP virtual servers are configured to listen on TCP port 25, the default SMTP port. If the SMTP listening port has been modified from the default and includes multiple port bindings, it could disrupt mail flow.

It is acceptable to change the SMTP listening port as long as the rest of your internal messaging infrastructure is also modified accordingly. However, generally, alternative ports cannot be used for SMTP virtual servers that accept messages directly from the Internet because SMTP servers on the Internet send messages through port 25.

The Exchange Server Analyzer is looking at the value for the Exchange SMTP protocol virtual server. This SMTP protocol virtual server may or may not be the SMTP server that receives messages directly from the Internet. There are some antivirus and anti-spam products that are designed to receive SMTP messages from the Internet on port 25 and redirect them to an Exchange SMTP virtual server on another port. In this scenario, an Exchange SMTP virtual server listening on multiple ports may be an acceptable configuration.

To view or modify the SMTP virtual server listening port

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server), and then click Properties.

  4. Select the General tab, and then click Advanced.

  5. A list of IP addresses and ports will be displayed.

    • To change the existing port, select the IP address, and then click Edit. Change the TCP port field to 25.

    • To add port 25 as an additional listening port, click Add, and add the new IP address/port combination. If you are using Connection, Sender, or Recipient Filtering, make sure that you select the appropriate check boxes.

  6. Click OK to save your changes, and then click OK to exit the Advanced dialog box.

  7. Click OK to close the Properties dialog box for the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


SMTP message failure warning - BadMail messages general failure
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the BadmailedMessagesGeneralFailure key. The value of this key represents the number of messages sent to the Badmail directory for reasons not associated with a specific counter. The Badmail directory is used to store undeliverable messages. For information about some of the other Badmail WMI counters, see the following Exchange Server Analyzer articles:

  • SMTP message failure warning - BadMail messages hop count threshold

  • SMTP message failure warning - BadMail messages NDR of DSN

There are counters that increment when a message is sent to the Badmail directory for other reasons, as well, including a bad pickup file, no recipients, and triggered via event.

The Exchange Server Analyzer also queries the Win32_PerfRawData_PerfOS_System WMI key to determine the value for SystemUpTime.

If the Exchange Server Analyzer determines the value for the SystemUpTime key is greater than 0 and that the result of the value for BadmailedMessagesGeneralFailure divided by the value for SystemUpTime is greater than 1000, a warning is displayed.

This warning indicates that an average of 1,000 or more messages per day are marked as non-deliverable and stored in the Badmail directory. Messages in the Badmail directory must be manually deleted. It is recommended that review and deletion of messages in the Badmail directory be part of regular Exchange Server maintenance. Allowing the Badmail directory to grow without restrictions could consume all available disk space, and in turn cause Exchange databases to dismount.

To correct this warning

  1. Examine the messages in the Badmail directory to determine whether the source of the message is internal or external. Messages in the Badmail directory are stored in ASCII format, and can be opened and viewed in Notepad or another text editor.

    • If the messages appear to be generated internally, you can examine the message headers to determine their origin.

    • If the messages appear to be generated externally, it may indicate that your Exchange Server is being used as a mail relay.

For information about how to control and configure relay options, see the following Microsoft Knowledge Base articles:

  • 310380, "HOW TO: Prevent Exchange 2000 from Being Used as a Mail Relay in Windows" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=310380)

  • 313395, "HOW TO: Examine Relay Restrictions for Anonymous SMTP Connections" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=313395)

For more information about database dismounts because of insufficient free disk space, see Microsoft Knowledge Base article 321825, "Databases Become Dismounted Because of Lack of Disk Space" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=321825).


SMTP message failure warning - BadMail messages hop count threshold
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the BadmailedMessagesHopCountExceeded key. The value of this key represents the number of messages sent to the Badmail directory because they had exceeded the maximum hop count. The Badmail directory is used to store undeliverable messages. For information about some of the other Badmail WMI counters, see the Exchange Server Analyzer Tool articles, SMTP message failure warning - BadMail messages general failure and SMTP message failure warning - BadMail messages NDR of DSN.

There are counters that increment when a message is sent to the Badmail directory for other reasons, as well, including a bad pickup file, no recipients, and triggered via event.

The Exchange Server Analyzer also queries the Win32_PerfRawData_PerfOS_System WMI key to determine the value for SystemUpTime.

If the Exchange Server Analyzer determines the value for the SystemUpTime key is greater than 0 and that the result of the value for BadmailedMessagesHopCountExceeded divided by the value for SystemUpTime is greater than 100, a warning is displayed.

This warning indicates that an average of 100 or more messages per day are marked as non-deliverable and stored in the Badmail directory because they exceed the maximum hop count. The maximum hop count is the maximum number of SMTP servers through which a message can travel on its way from the sender to the recipient. Each time a message travels through an SMTP server, a line of text representing the hop is added to the message header.

The optimal number of message hops varies depending on the topology of your network and your messaging needs. To prevent a message from being repeatedly misrouted (a condition known as a message loop) an administrator can control the maximum number of hops that is allowed. This can be done by setting a maximum hop count for the SMTP virtual server. In Exchange 2000 Server, the default hop count is 15. In Exchange Server 2003, the default is 30. A value of 30 for both Exchange 2000 Server and Exchange Server 2003 SMTP virtual servers is recommended.

Messages in the Badmail directory must be manually deleted. It is recommended that regular review and deletion of messages in the Badmail directory be a part of regular Exchange Server maintenance. Allowing the Badmail directory to grow without restrictions could consume all available disk space, and in turn cause Exchange databases to dismount.

To correct this warning

  1. Examine the messages in the Badmail directory to determine if the source of the message is internal or external. Messages in the Badmail directory are stored in ASCII format, and can be opened and viewed in Notepad or another text editor.

    • If the messages appear to be generated internally, you can examine the message headers to determine their origin.

    • If the messages appear to be generated externally, it may indicate that your Exchange Server is being used as a mail relay.

  2. Set the Maximum hop count value to 30.

    1. Open Exchange System Manager.

    2. Expand Servers, then expand an Exchange server, then expand Protocols, then expand SMTP.

    3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and select Properties.

    4. Select the Delivery tab, and then click Advanced.

    5. Enter the desired value in the Maximum hop count field and click OK to save the change.

    6. Click OK to close the Properties dialog box of the SMTP virtual server.

For information about how to control and configure relay options, see the following Microsoft Knowledge Base articles:

  • 310380, "HOW TO: Prevent Exchange 2000 from Being Used as a Mail Relay in Windows" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=310380)

  • 313395, "HOW TO: Examine Relay Restrictions for Anonymous SMTP Connections" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=313395)

For more information about database dismounts due to insufficient free disk space, see Microsoft Knowledge Base article 321825, "Databases Become Dismounted Because of Lack of Disk Space" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=321825).


SMTP message failure warning - BadMail messages NDR of DSN
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-23

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the BadmailedMessagesNDRofDSN key. The value of this key represents the number of delivery status notification (DSN) messages sent to the Badmail directory because they were undeliverable. The Badmail directory is used to store undeliverable messages. For information about some of the other Badmail WMI counters, see the Exchange Server Analyzer articles, SMTP message failure warning - BadMail messages general failure and SMTP message failure warning - BadMail messages hop count threshold.

There are counters that increment when a message is sent to the Badmail directory for other reasons, including a bad pickup file, no recipients, and triggered via event.

The Exchange Server Analyzer also queries the Win32_PerfRawData_PerfOS_System WMI key to determine the value for SystemUpTime.

If the Exchange Server Analyzer determines the value for the SystemUpTime key is greater than 0 and that the result of the value for BadmailedMessagesNDRofDSN divided by the value for SystemUpTime is greater than 1000, a warning is displayed.

This warning indicates that an average of 1,000 or more DSNs per day are stored in the Badmail directory because they could not be delivered. Messages in the Badmail directory must be manually deleted. It is recommended that regular review and deletion of messages in the Badmail directory be a part of regular Exchange Server maintenance. Allowing the Badmail directory to grow without restrictions could consume all available disk space, and in turn cause Exchange databases to dismount.

To correct this warning

  • Examine the messages in the Badmail directory to determine if the DSNs are intended for internal or external recipients. Messages in the Badmail directory are stored in ASCII format, and can be opened and viewed in Notepad or another text editor.

    • If the DSNs are intended for internal recipients, it indicates a message flow problem. Troubleshooting this issue will depend on the specific numeric code returned with the DSN.

    • If the DSNs are intended for external recipients, it may indicate that your Exchange Server is being used as a mail relay. Troubleshooting this issue will also depend on the returned numeric code.

For more information about delivery DSN numeric return codes, see Microsoft Knowledge Base article 284204, Delivery status notifications in Exchange Server and in Small Business Server.

For information about how to control and configure relay options, see the following Microsoft Knowledge Base article 313395, How To Examine Relay Restrictions for Anonymous SMTP Connections and Filter Unsolicited E-mail Messages in Exchange 2000 Server.

For more information about database dismounts due to insufficient free disk space, see Microsoft Knowledge Base article 321825, Databases Become Dismounted Because of Lack of Disk Space.


SMTP message failure warning - Categorizer address lookups not found
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-03-20

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the CatAddresslookupsnotfound key. The value of this key represents the number of address lookups performed by the message categorizer that did not find a directory service object. The Exchange Server Analyzer also queries the Win32_PerfRawData_PerfOS_System WMI key to determine the value for SystemUpTime.

If the Exchange Server Analyzer determines the value for the SystemUpTime key is more than 0 and that the result of the value for CatAddresslookupsnotfound divided by the value for SystemUpTime is more than 5000, a warning is displayed.

The message categorizer examines messages that come to an SMTP server and determines what to do with the messages. The messages may be destined for the local information store, a remote host by using the message transfer agent (MTA), or the messages may be destined for a remote host by using SMTP. The categorizer also handles distribution list expansion. The categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The categorizer is essentially a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine. It performs address resolution, mail forwarding, sets content conversion flags, expands distribution lists, enforces global settings, generates delivery status notifications, and it performs alternate recipient route detection, bifurcation, journaling, and many other functions.

When a message enters the message categorizer, the categorizer resolves the envelope sender by searching for the address in the proxy address attributes in the Active Directory® directory service. The categorizer also resolves the envelope recipient by searching for each address in the proxy addresses attribute in Active Directory. For example, if the list includes a distribution list, it expands the list to include those members if distribution list expansion is allowed on the server.

This warning indicates that an average of 5,000 or more categorizer address lookups are failing each day. There are several causes for this, including problems with directory service access (DSAccess), directory replication latency or failures, dictionary attacks against directories, problems with DNS, or using bad addresses.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Examine the event logs on the Exchange Server computer for errors.

  2. If you do not find any events that let you resolve the problem, consider turning up diagnostic logging on the MSExchangeTransport Categorizer to Maximum. When diagnostic logging is enabled, re-check the event log for errors. If configuring diagnostic logging to maximum does not produce any event log entries, configure diagnostic logging to level 7 using the registry. When set to level 7, Event ID 9000 generated by the Message Categorizer will be logged, which details the function, the reason for failure, the name of the recipient that failed, and the type of recipient. To set diagnostic logging to level 7:

    1. Open a registry editor, such as Regedit.exe or Regedt32.exe

    2. Navigate to:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. In the right pane, double-click 2 Categorizer, set the value data to 7, and then click OK.

    4. Close the registry editor.

      Note:
      When you have completed troubleshooting, reset the value data for 2 Categorizer back to 0.

  3. Verify that the Exchange Server has connectivity to one or more global catalog servers. The Network Monitor tool in Windows is very useful for this.

  4. Examine any delivery status notification (DSN) messages that are being generated. DSNs, which can include non-delivery reports (NDRs), describe permanent failure messages and transient failure messages that frequently end as permanent delivery errors.

  5. Use Message Tracking to troubleshoot messages that are stuck in the categorizer.

  6. Use the Archive Sink tool to archive and analyze messages coming into and moving out of Exchange Server.

  7. Monitor the categorizer performance counters using System Monitor.

For a listing of the DSNs and NDRs generated by Exchange Server and Microsoft Windows Small Business Server, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

For information about using the Message Tracking Center in Exchange Server, see the following Microsoft Knowledge Base articles:

  • 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 246856, "XADM: How to Enable Message Tracking in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 821905, "Message Tracking Event IDs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 823864, "Improved Message Tracking Features in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

For more information about troubleshooting message categorizer issues, see the Microsoft Support webcast, "Exchange 2000 Server: Message Categorizer and NDR Troubleshooting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137).

For more information about the Archive Sink tool, see Microsoft Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798).

For general information about troubleshooting transport-related problems, see the following Microsoft Knowledge Base articles:

  • 821910, "How To Troubleshoot for Exchange Server 2003 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 257265, "XCON: General Troubleshooting for Exchange 2000 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the Message Categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).

For information about some of the other Categorizer WMI counters, see the following Exchange Server Analyzer articles:

  • SMTP message failure warning - Categorizer directory service failure

  • SMTP message failure warning - Categorizer directory logon failure

  • SMTP message failure warning - Categorizer non-retryable error

  • SMTP message failure warning - Categorizer out of memory failure

  • SMTP message failure warning - Categorizer retryable error


SMTP message failure warning - Categorizer directory logon failure
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the CatCategorizationsfailedDSlogonfailure key. The value of this key represents the number of categorizations that failed because of a directory service logon failure. The Exchange Server Analyzer also queries the Win32_PerfRawData_PerfOS_System WMI key to determine the value for SystemUpTime.

If the Exchange Server Analyzer determines the value for the SystemUpTime key is more than 0 and that the result of the value for CatCategorizationsfailedDSlogonfailure divided by the value for SystemUpTime is more than 50, a warning is displayed.

The message categorizer examines messages that come to an SMTP server and determines what to do with the messages. The messages may be destined for the local information store, a remote host by using the message transfer agent (MTA), or the messages may be destined for a remote host by using SMTP. The categorizer also handles distribution list expansion. The categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The categorizer is essentially a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine. It performs address resolution, mail forwarding, sets content conversion flags, expands distribution lists, enforces global settings, generates delivery status notifications, and it performs alternate recipient route detection, bifurcation, journaling, and many other functions.

As soon as a message enters the message categorizer, the categorizer resolves the envelope sender by searching for the address in the proxy address attributes in the Active Directory® directory service. The categorizer also resolves the envelope recipient by searching for each address in the proxy addresses attribute in Active Directory. For example, if the list includes a distribution list, it expands the list to include those members if distribution list expansion is allowed on the server.

This warning indicates that an average of 50 or more directory service connection attempts made by the message categorizer are failing each day because of logon failures. There are a variety of causes for this, including problems with directory service access (DSAccess), directory replication latency or failures, overloaded global catalog servers, and problems with DNS.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Check the event logs on the Exchange Server computer for errors.

  2. If you do not find any events that enable you to resolve the problem, consider turning up diagnostic logging on the MSExchangeTransport Categorizer to Maximum. As soon as diagnostic logging is enabled, re-check the event log for errors. If configuring diagnostic logging to maximum does not produce any event log entries, configure diagnostic logging to level 7 by using the registry. When set to level 7, Event ID 9000 generated by the message categorizer will be logged, which details the function, the reason for failure, the name of the recipient that failed, and the type of recipient. To set diagnostic logging to level 7:

    1. Open a registry editor, such as Regedit.exe or Regedt32.exe

    2. Navigate to:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. In the right-hand pane, double-click 2 Categorizer and set the value data to 7 and click OK.

    4. Close the registry editor.

      Note:
      When you have completed troubleshooting, reset the value data for 2 Categorizer back to 0.

  3. Verify that the Exchange Server has connectivity to one or more global catalog servers. The Network Monitor tool in Windows is very useful for this.

  4. Examine any delivery status notification (DSN) messages that are being generated. DSNs, which can include non-delivery reports (NDRs), describe permanent failure messages and transient failure messages that frequently end as permanent delivery errors.

  5. Use Message Tracking to troubleshoot messages that are stuck in the categorizer.

  6. Use the Archive Sink tool to archive and analyze messages coming into and moving out of Exchange Server.

  7. Monitor the categorizer performance counters using System Monitor.

For a listing of the DSNs and NDRs generated by Exchange Server and Microsoft Windows Small Business Server, see the Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

For information about using the Message Tracking Center in Exchange Server, see the following Knowledge Base articles:

  • 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 246856, "XADM: How to Enable Message Tracking in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 821905, "Message Tracking Event IDs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 823864, "Improved Message Tracking Features in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

For more information about troubleshooting message categorizer issues, see the Microsoft Support WebCast, "Exchange 2000 Server: Message Categorizer and NDR Troubleshooting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137).

For more information about the Archive Sink tool, see Microsoft Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798).

For general information about troubleshooting transport-related problems, see the following Knowledge Base articles:

  • 821910, "How To Troubleshoot for Exchange Server 2003 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 257265, "XCON: General Troubleshooting for Exchange 2000 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the message categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).

For information about some of the other Categorizer WMI counters, see the following Exchange Server Analyzer articles

  • SMTP message failure warning - Categorizer directory service failure

  • SMTP message failure warning - Categorizer address lookups not found

  • SMTP message failure warning - Categorizer non-retryable error

  • SMTP message failure warning - Categorizer out of memory failure

  • SMTP message failure warning - Categorizer retryable error


SMTP message failure warning - Categorizer directory service failure
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-03-20

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the CatCategorizationsfailedDSconnectionfailure key. The value of this key represents the number of categorizations that failed because of a directory service connection service failure. The Exchange Server Analyzer also queries the Win32_PerfRawData_PerfOS_System WMI key to determine the value for SystemUpTime.

If the Exchange Server Analyzer determines the value for the SystemUpTime key is more than 0 and that the result of the value for CatCategorizationsfailedDSconnectionfailure divided by the value for SystemUpTime is more than 50, a warning is displayed.

The message categorizer examines messages that come to an SMTP server and determines what to do with the messages. The messages may be destined for the local information store, a remote host by using the message transfer agent (MTA), or the messages may be destined for a remote host by using SMTP. The categorizer also handles distribution list expansion. The categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The categorizer is essentially a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine. It performs address resolution, mail forwarding, sets content conversion flags, expands distribution lists, enforces global settings, generates delivery status notifications, and it performs alternate recipient route detection, bifurcation, journaling, and many other functions.

When a message enters the message categorizer, the categorizer resolves the envelope sender by searching for the address in the proxy address attributes in the Active Directory® directory service. The categorizer also resolves the envelope recipient by searching for each address in the proxy addresses attribute in Active Directory. For example, if the list includes a distribution list, it expands the list to include those members if distribution list expansion is allowed on the server.

This warning indicates that an average of 50 or more directory service connection attempts made by the message categorizer are failing each day. There are several causes for this, including problems with directory service access (DSAccess), directory replication latency or failures, overloaded global catalog servers, and problems with DNS.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Examine the event logs on the Exchange Server computer for errors.

  2. If you do not find any events that let you resolve the problem, consider turning up diagnostic logging on the MSExchangeTransport Categorizer to Maximum. As soon as diagnostic logging is enabled, re-check the event log for errors. If configuring diagnostic logging to maximum does not produce any event log entries, configure diagnostic logging to level 7 using the registry. When set to level 7, Event ID 9000 generated by the Message Categorizer will be logged, which details the function, the reason for failure, the name of the recipient that failed, and the type of recipient. To set diagnostic logging to level 7:

    1. Open a registry editor, such as Regedit.exe or Regedt32.exe

    2. Navigate to:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. In the right pane, double-click 2 Categorizer, set the value data to 7, and then click OK.

    4. Close the registry editor.

      Note:
      When you have completed troubleshooting, reset the value data for 2 Categorizer back to 0.

  3. Verify that the Exchange Server has connectivity to one or more global catalog servers. The Network Monitor tool in Windows is very useful for this.

  4. Examine any delivery status notification (DSN) messages that are being generated. DSNs, which can include non-delivery reports (NDRs), describe permanent failure messages and transient failure messages that frequently end as permanent delivery errors.

  5. Use Message Tracking to troubleshoot messages that are stuck in the categorizer.

  6. Use the Archive Sink tool to archive and analyze messages coming in and moving out of Exchange Server.

  7. Monitor the categorizer performance counters using System Monitor.

For a listing of the DSNs and NDRs generated by Exchange Server and Microsoft Windows Small Business Server, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

For information about using the Message Tracking Center in Exchange Server, see the following Microsoft Knowledge Base articles:

  • 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 246856, "XADM: How to Enable Message Tracking in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 821905, "Message Tracking Event IDs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 823864, "Improved Message Tracking Features in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

For more information about troubleshooting message categorizer issues, see the Microsoft Support WebCast, "Exchange 2000 Server: Message Categorizer and NDR Troubleshooting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137).

For more information about the Archive Sink tool, see Microsoft Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798).

For general information about troubleshooting transport-related problems, see the following Microsoft Knowledge Base articles:

  • 821910, "How To Troubleshoot for Exchange Server 2003 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 257265, "XCON: General Troubleshooting for Exchange 2000 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the Message Categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).

For information about some of the other Categorizer WMI counters, see the following Exchange Server Analyzer articles:

  • SMTP message failure warning - Categorizer address lookups not found

  • SMTP message failure warning - Categorizer directory logon failure

  • SMTP message failure warning - Categorizer non-retryable error

  • SMTP message failure warning - Categorizer out of memory failure

  • SMTP message failure warning - Categorizer retryable error


SMTP message failure warning - Categorizer non-retryable error
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the CatCategorizationsfailednonretryableerror key. The value of this key represents the number of categorizations that failed because of a hard error (not retryable). The Exchange Server Analyzer also queries the Win32_PerfRawData_PerfOS_System WMI key to determine the value for SystemUpTime.

If the Exchange Server Analyzer determines the value for the SystemUpTime key is more than 0 and that the result of the value for CatCategorizationsfailednonretryableerror divided by the value for SystemUpTime is more than 50, a warning is displayed.

The message categorizer examines messages that come to an SMTP server and determines what to do with the messages. The messages may be destined for the local information store, a remote host by using the message transfer agent (MTA), or the messages may be destined for a remote host by using SMTP. The categorizer also handles distribution list expansion. The categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The categorizer is essentially a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine. It performs address resolution, mail forwarding, sets content conversion flags, expands distribution lists, enforces global settings, generates delivery status notifications, and it performs alternate recipient route detection, bifurcation, journaling, and many other functions.

As soon as a message enters the message categorizer, the categorizer resolves the envelope sender by searching for the address in the proxy address attributes in the Active Directory® directory service. The categorizer also resolves the envelope recipient by searching for each address in the proxy addresses attribute in Active Directory. For example, if the list includes a distribution list, it expands the list to include those members if distribution list expansion is allowed on the server.

This warning indicates that an average of 50 or more hard errors are occurring each day. There are several causes for this, including problems with directory service access (DSAccess), directory replication latency or failures, overloaded global catalog servers, and problems with DNS.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Check the event logs on the Exchange Server computer for errors.

  2. If you do not find any events that enable you to resolve the problem, consider turning up diagnostic logging on the MSExchangeTransport Categorizer to Maximum. After diagnostic logging is enabled, re-check the event log for errors. If configuring diagnostic logging to maximum does not produce any event log entries, configure diagnostic logging to level 7 by using the registry. When set to level 7, Event ID 9000 generated by the message categorizer will be logged, which details the function, the reason for failure, the name of the recipient that failed, and the type of recipient. To set diagnostic logging to level 7:

    1. Open a registry editor, such as Regedit.exe or Regedt32.exe

    2. Navigate to:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. In the right pane, double-click 2 Categorizer, set the value data to 7, and then click OK.

    4. Close the registry editor.

      Note:
      When you have completed troubleshooting, reset the value data for 2 Categorizer back to 0.

  3. Verify that the Exchange Server has connectivity to one or more global catalog servers. The Network Monitor tool in Windows is very useful for this.

  4. Examine any delivery status notification (DSN) messages that are being generated. DSNs, which can include non-delivery reports (NDRs), describe permanent failure messages and transient failure messages that frequently end as permanent delivery errors.

  5. Use Message Tracking to troubleshoot messages that are stuck in the categorizer.

  6. Use the Archive Sink tool to archive and analyze messages coming in and moving out of Exchange Server.

  7. Monitor the categorizer performance counters using System Monitor.

For a listing of the DSNs and NDRs generated by Exchange Server and Microsoft Windows Small Business Server, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

For information about using the Message Tracking Center in Exchange Server, see the following Microsoft Knowledge Base articles:

  • 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 246856, "XADM: How to Enable Message Tracking in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 821905, "Message Tracking Event IDs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 823864, "Improved Message Tracking Features in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

For more information about troubleshooting message categorizer issues, see the Microsoft Support WebCast, "Exchange 2000 Server: Message Categorizer and NDR Troubleshooting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137).

For more information about the Archive Sink tool, see Microsoft Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798).

For general information about troubleshooting transport-related problems, see the following Microsoft Knowledge Base articles:

  • 821910, "How To Troubleshoot for Exchange Server 2003 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 257265, "XCON: General Troubleshooting for Exchange 2000 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the Message Categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).

For information about some of the other Categorizer WMI counters, see the following Exchange Server Analyzer articles:

  • SMTP message failure warning - Categorizer address lookups not found

  • SMTP message failure warning - Categorizer directory logon failure

  • SMTP message failure warning - Categorizer directory service failure

  • SMTP message failure warning - Categorizer out of memory failure

  • SMTP message failure warning - Categorizer retryable error


SMTP message failure warning - Categorizer out of memory failure
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-03-28

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the CatCategorizationsfailedOutOfMemory key. The value of this key represents the number of categorizations that failed because of a lack of available memory. The Exchange Server Analyzer also queries the Win32_PerfRawData_PerfOS_System WMI key to determine the value for SystemUpTime.

If the Exchange Server Analyzer determines the value for the SystemUpTime key is more than 0 and that the result of the value for CatCategorizationsfailedOutOfMemory divided by the value for SystemUpTime is more than 50, a warning is displayed.

The message categorizer examines messages that come to an SMTP server and determines what to do with the messages. The messages may be destined for the local information store, a remote host by using the message transfer agent (MTA), or the messages may be destined for a remote host by using SMTP. The categorizer also handles distribution list expansion. The categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The categorizer is essentially a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine. It performs address resolution, mail forwarding, sets content conversion flags, expands distribution lists, enforces global settings, generates delivery status notifications, and it performs alternate recipient route detection, bifurcation, journaling, and many other functions.

As soon as a message enters the message categorizer, the categorizer resolves the envelope sender by searching for the address in the proxy address attributes in the Active Directory® directory service. The categorizer also resolves the envelope recipient by searching for each address in the proxy addresses attribute in Active Directory. For example, if the list includes a distribution list, it expands the list to include those members if distribution list expansion is allowed on the server.

This warning indicates that an average of 50 or more categorizations are failing each day because of a lack of available memory. There are several causes for this, including problems with directory service access (DSAccess), directory replication latency or failures, overloaded global catalog servers, and problems with DNS.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Check the event logs on the Exchange Server computer for errors.

  2. If you do not find any events that enable you to resolve the problem, consider turning up diagnostic logging on the MSExchangeTransport Categorizer to Maximum. After diagnostic logging is enabled, re-check the event log for errors. If configuring diagnostic logging to maximum does not produce any event log entries, configure diagnostic logging to level 7 by using the registry. When set to level 7, Event ID 9000 generated by the message categorizer will be logged, which details the function, the reason for failure, the name of the recipient that failed, and the type of recipient. To set diagnostic logging to level 7:

    1. Open a registry editor, such as Regedit.exe or Regedt32.exe

    2. Navigate to:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. In the right pane, double-click 2 Categorizer, set the value data to 7, and then click OK.

    4. Close the registry editor.

      Note:
      When you have completed troubleshooting, reset the value data for 2 Categorizer back to 0.

  3. Verify that the Exchange Server has connectivity to one or more global catalog servers. The Network Monitor tool in Windows is very useful for this.

  4. Examine any delivery status notification (DSN) messages that are being generated. DSNs, which can include non-delivery reports (NDRs), describe permanent failure messages and transient failure messages that frequently end as permanent delivery errors.

  5. Use Message Tracking to troubleshoot messages that are stuck in the categorizer.

  6. Use the Archive Sink tool to archive and analyze messages coming into and moving out of Exchange Server.

  7. Monitor the categorizer performance counters using System Monitor.

For a listing of the DSNs and NDRs generated by Exchange Server and Microsoft Windows Small Business Server, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

For information about using the Message Tracking Center in Exchange Server, see the following Microsoft Knowledge Base articles:

  • 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 246856, "XADM: How to Enable Message Tracking in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 821905, "Message Tracking Event IDs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 823864, "Improved Message Tracking Features in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

For more information about troubleshooting message categorizer issues, see the Microsoft Support WebCast, "Exchange 2000 Server: Message Categorizer and NDR Troubleshooting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137).

For more information about the Archive Sink tool, see Microsoft Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798).

For general information about troubleshooting transport-related problems, see the following Microsoft Knowledge Base articles:

  • 821910, "How To Troubleshoot for Exchange Server 2003 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910).

  • 257265, "General troubleshooting for transport issues in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=305 2 &kbid=257265).

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the Message Categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).

For information about some of the other Categorizer WMI counters, see the following Exchange Server Analyzer articles:

  • SMTP message failure warning - Categorizer address lookups not found

  • SMTP message failure warning - Categorizer directory logon failure

  • SMTP message failure warning - Categorizer directory service failure

  • SMTP message failure warning - Categorizer non-retryable error

  • SMTP message failure warning - Categorizer retryable error


SMTP message failure warning - Categorizer retryable error
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-03-20

The Microsoft® Exchange Server Analyzer Tool queries the Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft Windows® Management Instrumentation (WMI) class to determine the value for the CatCategorizationsfailedretryableerror key. The value of this key represents the number of categorizations that failed with a retryable error. The Exchange Server Analyzer also queries the Win32_PerfRawData_PerfOS_System WMI key to determine the value for SystemUpTime.

If the Exchange Server Analyzer determines the value for the SystemUpTime key is greater than 0 and that the result of the value for CatCategorizationsfailedretryableerror divided by the value for SystemUpTime is greater than 500, a warning is displayed.

The message categorizer examines messages that come to an SMTP server and determines what to do with the messages. The messages may be destined for the local information store, a remote host by using the message transfer agent (MTA), or the messages may be destined for a remote host by using SMTP. The categorizer also handles distribution list expansion. The categorizer is a plug-in to the advanced queuing engine that performs Lightweight Directory Access Protocol (LDAP) queries against global catalog servers on TCP port 3268. The categorizer is essentially a collection of event sinks that perform advanced address resolution on every message that travels through the advanced queuing engine. It performs address resolution, mail forwarding, sets content conversion flags, expands distribution lists, enforces global settings, generates delivery status notifications, and it performs alternate recipient route detection, bifurcation, journaling, and many other functions.

As soon as a message enters the message categorizer, the categorizer resolves the envelope sender by searching for the address in the proxy address attributes in the Active Directory® directory service. The categorizer also resolves the envelope recipient by searching for each address in the proxy addresses attribute in Active Directory. For example, if the list includes a distribution list, it expands the list to include those members if distribution list expansion is allowed on the server.

This warning indicates that an average of 500 or more categorizations are failing each day with a retryable error. There are a variety of causes for this, including problems with directory service access (DSAccess), directory replication latency or failures, overloaded global catalog servers, and problems with DNS.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this warning

  1. Check the event logs on the Exchange Server computer for errors.

  2. If you do not find any events that enable you to resolve the problem, consider turning up diagnostic logging on the MSExchangeTransport Categorizer to Maximum. After diagnostic logging is enabled, re-check the event log for errors. If configuring diagnostic logging to maximum does not produce any event log entries, configure diagnostic logging to level 7 by using the registry. When set to level 7, Event ID 9000 generated by the message categorizer will be logged, which details the function, the reason for failure, the name of the recipient that failed, and the type of recipient. To set diagnostic logging to level 7:

    1. Open a registry editor, such as Regedit.exe or Regedt32.exe

    2. Navigate to:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. In the right pane, double-click 2 Categorizer, set the value data to 7, and then click OK.

    4. Close the registry editor.

      Note:
      When you have completed troubleshooting, reset the value data for 2 Categorizer back to 0.

  3. Verify that the Exchange Server has connectivity to one or more global catalog servers. The Network Monitor tool in Windows is very useful for this.

  4. Examine any delivery status notification (DSN) messages that are being generated. DSNs, which can include non-delivery reports (NDRs), describe permanent failure messages and transient failure messages that frequently end as permanent delivery errors.

  5. Use Message Tracking to troubleshoot messages that are stuck in the categorizer.

  6. Use the Archive Sink tool to archive and analyze messages coming into and moving out of Exchange Server.

  7. Monitor the categorizer performance counters using System Monitor.

For a listing of the DSNs and NDRs generated by Exchange Server and Microsoft Windows Small Business Server, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

For information about using the Message Tracking Center in Exchange Server, see the following Microsoft Knowledge Base articles:

  • 262162, "XADM: Using the Message Tracking Center to Track a Message" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 246856, "XADM: How to Enable Message Tracking in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 821905, "Message Tracking Event IDs in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 823864, "Improved Message Tracking Features in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

For more information about troubleshooting message categorizer issues, see the Microsoft Support WebCast, "Exchange 2000 Server: Message Categorizer and NDR Troubleshooting" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137).

For more information about the Archive Sink tool, see Microsoft Knowledge Base article 307798, "The Archive Sink utility is available in Service Pack 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798).

For general information about troubleshooting transport-related problems, see the following Microsoft Knowledge Base articles:

  • 821910, "How To Troubleshoot for Exchange Server 2003 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 257265, "XCON: General Troubleshooting for Exchange 2000 Transport Issues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

The message categorizer performance counters are published separately for each SMTP virtual server instance. For a list of the available performance counters related to the Message Categorizer, see Microsoft Knowledge Base article 231734, "XCON: Performance Monitor Counters for Message Categorizer" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734).

For information about some of the other Categorizer WMI counters, see the following Exchange Server Analyzer Tool articles:

  • SMTP message failure warning - Categorizer address lookups not found

  • SMTP message failure warning - Categorizer directory logon failure

  • SMTP message failure warning - Categorizer directory service failure

  • SMTP message failure warning - Categorizer non-retryable error

  • SMTP message failure warning - Categorizer out of memory failure


SMTP mail queue data is being written to a compressed folder
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Compressed key for the SMTP mail queue folder. If the Exchange Server Analyzer finds the value for Compressed set to True, a warning is displayed.

When messages arrive at the Exchange computer through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are stored in the <drive>:\Program Files\Exchsrvr\Mailroot folder on the same partition that Exchange is installed on. If the folder where the SMTP mail queue is stored has file compression turned on, Exchange performance may be severely degraded. Thus, compression for the folder where the SMTP mail queue is stored is not supported.

Microsoft does not support the storage of Exchange data files on a compressed volume. When you store your Exchange data files on a compressed volume, the additional overhead significantly impacts the performance of Exchange. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To turn off file compression on a given folder

  1. Right-click the folder where you want to turn off file compression, and click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Compress contents to save disk space check box, and then click OK.

To move the Mailroot folder on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Click Administrative Groups, expand your administrative group, expand Servers, expand your server, expand Protocols, and then expand SMTP.

  3. Right-click your SMTP virtual server, and then click Stop.

  4. Right-click your SMTP virtual server, and then click Properties.

  5. On the Messages tab, next to the Queue directory box, click Browse, and then type the path of the new location of the Queue folder.

  6. Click OK.

  7. Right-click your SMTP virtual server, and then click Start.

For more information about moving the Mailroot folder, see the Microsoft Knowledge Base article 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933).


SMTP mail queue data is being written to an encrypted folder
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Encrypted key for the Simple Mail Transfer Protocol (SMTP) mail queue folder. If the Exchange Server Analyzer finds the value for Encrypted set to True, a warning is displayed.

When messages arrive at the Exchange computer through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are stored in the <drive>:\Program Files\Exchsrvr\Mailroot folder on the same partition that Exchange is installed on. If the folder where the SMTP mail queue is stored has file encryption turned on, Exchange performance may be severely degraded. Therefore, encrypting the folder where the SMTP mail queue is stored is not supported.

Microsoft does not support the storage of Exchange data files on an Encrypting File System (EFS) encrypted volume. When you store your Exchange data files on an encrypted volume, the additional overhead significantly impacts the performance of Exchange. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To help secure your Exchange data files, it is recommended that you prevent unauthorized access to the Exchange computer and that you use the S/MIME message format to encrypt message data.

To resolve this error, you must either turn off file encryption on the SMTP mail queue folder, or move the SMTP mail queue folder to a location where encryption is not enabled.

To turn off file encryption on a given folder

  1. Right-click the folder where you want to turn off file encryption, and click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Encrypt contents to secure data check box, and then click OK.

To move the SMTP mail queue folder on Exchange 2000 Server or Exchange Server 2003

  1. Open Exchange System Manager.

  2. Click Administrative Groups, expand your administrative group, expand Servers, expand your server, expand Protocols, and then expand SMTP.

  3. Right-click your SMTP virtual server, and then click Stop.

  4. Right-click your SMTP virtual server, and then click Properties.

  5. On the Messages tab, next to the BadMail directory box, click Browse, and then type the path of the new location of the Queue folder.

  6. Click OK.

  7. Right-click your SMTP virtual server, and then click Start.

For more information about moving the Mailroot folder, see the Microsoft Knowledge Base article 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933).

For more information about Exchange Server data files and EFS, see the Microsoft Knowledge Base article 834638, "Information about the storage of data files on an encrypted volume in Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638).

For information about how secure messages in Microsoft Exchange Server 2003, see the "Exchange Server 2003 Message Security Guide" (http://go.microsoft.com/fwlink/?LinkId=47574).


SMTP mail queue data is being written to non-NTFS partition
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FSName key for the Exchange SMTP queue directory. If the Exchange Server Analyzer determines that the value for the FSName key does not equal NTFS File System, an error is displayed.

Microsoft does not support the storage of Exchange data files on non-NTFS volumes. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

If you experience this error, you must move the SMTP queue directory to a folder on an NTFS drive. Alternatively, if the drive on which the queue directory is stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS.

To move the SMTP queue to another folder

  1. Open Exchange System Manager.

  2. Click Administrative Groups, expand your administrative group, expand Servers, expand your server, expand Protocols, and then expand SMTP.

  3. Right-click your SMTP virtual server, and then click Stop.

  4. Right-click your SMTP virtual server, and then click Properties.

  5. On the Messages tab, next to the BadMail directory box, click Browse, and then type the path of the new location of the Queue folder.

  6. Click OK.

  7. Right-click your SMTP virtual server, and then click Start.

For more information about moving the Mailroot folder, see the Microsoft Knowledge Base article 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933).

As an alternative to the procedure that is described in this article, if the drive on which the files are stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS. For information about using the convert.exe command line tool to convert a FAT partition to an NTFS partition, see the Microsoft Knowledge Base article 214579, "How to Use Convert.exe to Convert a Partition to the NTFS File System" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=214579).


The SMTP MaxDSNSize value has been manually set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry subkey to determine if the maximum size of delivery status notification (DSN) messages has been manually overridden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\MaxDSNSize

If the Exchange Server Analyzer finds MaxDSNSize to be present and configured, a non-default configuration message is displayed.

The MaxDSNSize registry value enables a computer running Exchange 2000 Server Service Pack 2 (SP2) or later to remove attachments if a message cannot be delivered. If you enable this option, you can save server and network resources. However, there are drawbacks to this implementation of SMTP attachment stripping.

If you enable this option to strip the attachments from the non-delivery report (NDR), the details that are necessary to display the notification in the preview pane are also stripped, and the originator of the message cannot use the Send Again option. If the originator of the message tries to use the Send Again option from the NDR, the originator of the message receives the following error message:

"Unable to resend the message. The nondelivery report does not contain sufficient information about the original message. To resend the message, open it in your Sent Items folder, click the Actions menu, and click Resend this message."

However, the originator of the message cannot resend the message, even by using the method in the error message. Therefore, it is recommended that you use this option with caution.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To modify the MaxDSNSize registry value

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. Create a DWORD registry value called MaxDSNSize and set its value data (in bytes) to the desired amount.

  4. Exit the registry editor and restart the SMTP service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base Article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the MaxDSNSize registry value, see the following Knowledge Base articles:

  • 308303, "XCON: Option to Strip Attachments for Messages That Generate an NDR" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=308303)

  • 323484, "XCON: Description of the Multipart/Report Internet Message Format in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=323484)


The SMTP MaxPendingCat registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether default SMTP queuing configurations have been changed:

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

If the Exchange Server Analyzer finds that the MaxPendingCat key has been set, the Exchange Server Analyzer displays a non-default message.

It is recommended that the default queuing values be modified only after complete consideration. The defaults were carefully selected for optimal performance in most environments. A general best practice is to address the root cause of the problem instead of modifying the queuing behavior on Exchange.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about Exchange SMTP queuing, see the Microsoft Exchange Team Blog entry, "Explaining the Mysterious SMTP Advanced Queuing Engine" (http://go.microsoft.com/fwlink/?LinkId=48585).


SMTP MaxMessageObjects has been set too low
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the maximum number of mail messages that the system can allocate:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\MailMsg\MaxMessageObjects

If the Exchange Server Analyzer finds the value for MaxMessageObjects is less than 30001, a warning is displayed.

When the queue contains the maximum number of messages, no additional inbound messages are accepted by Simple Mail Transfer Protocol (SMTP). Each mail message resident in the SMTP queue uses at least 4 kilobytes (KB) of memory; therefore, it is possible to run into a low memory situation with a very large queue.

The MaxMessageObjects value is not present by default, and the maximum number of messages is set to 100,000. Setting MaxMessageObjects lower reduces the maximum number of messages that can reside in the queue, therefore decreasing the maximum memory footprint for SMTP. After this limit is reached, each SMTP connection made to the server will return with an out of memory error.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set a limit on the number of SMTP messages that may be queued

  1. Start a registry editor such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Exchange

  3. Right-click the Exchange key, and then click New Key. Name the new key MailMsg.

  4. Right-click the MailMsg key, and then click New DWORD Value.

  5. Right-click the new value, click Rename, and then type MaxMessageObjects.

  6. Double-click the MaxMessageObjects value, and then set it to the maximum number of messages that you want to be in queues at any time. Unless you need to process more messages, a maximum value of 100,000 is recommended.

  7. Exit the registry editor and restart the SMTP service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about setting limits on messages in queues, see the Microsoft Knowledge Base article 258748, "How to set a limit on the number of SMTP messages in queues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258748).


The SMTP MaxMessageObjects registry parameter has been changed from its default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the maximum number of mail messages that the system can allocate:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\MailMsg\MaxMessageObjects

If the Exchange Server Analyzer finds the value for MaxMessageObjects is more than 0, a non-default configuration message is displayed.

When the queue contains the maximum number of messages, no additional inbound messages are accepted by SMTP. Each mail message resident in the SMTP queue uses at least 4 kilobytes (KB) of memory; therefore, you can experience a low memory situation with a very large queue.

The MaxMessageObjects value is not present by default, and the maximum number of messages is set to 100,000. Setting MaxMessageObjects lower reduces the maximum number of messages that can reside in the queue, thereby decreasing the maximum memory footprint for SMTP. After this limit is reached, each SMTP connection made to the server will return with an out of memory error.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To set a limit on the number of SMTP messages that may be queued

  1. Start a registry editor such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\Software\Microsoft\Exchange

  3. Right-click the Exchange key, and then click New Key. Name the new key MailMsg.

  4. Right-click the MailMsg key, and then click New DWORD Value.

  5. Right-click the new value, click Rename, and then type MaxMessageObjects.

  6. Double-click the MaxMessageObjects value, and then set it to the maximum number of messages that you want to be in queues at any time. Unless you need to process more messages, it is recommended that you use a maximum value of 100,000.

  7. Exit the registry editor and restart the Simple Mail Transfer Protocol (SMTP) service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986).

For more information about setting limits on messages in queues, see the Knowledge Base article 258748, "How to set a limit on the number of SMTP messages in queues" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258748).


The SMTP MaxPercentPoolThreads registry value has been manually set
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if additional pool threads have been manually configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters\MaxPercentPoolThreads

If the Exchange Server Analyzer finds MaxPercentPoolThreads to be present and configured, a non-default configuration message is displayed.

There are five work queues in SMTP that use a pool of threads known as the ATQ threads. By design, two of these queues can, by default, use up to 90 percent of the available threads. This thread pool is shared by the process accepting POP and IMAP requests. Therefore, in a moderate to high load scenario, a situation can arise where SMTP can keep resources from POP and IMAP services.

You can reserve adequate threads for POP and IMAP by limiting the percentage of threads SMTP can use. To make this change, you have to increase the overall number of threads available to IIS. The only tradeoff here is increased memory usage for the additional threads.

There are two registry values that allow you to control the SMTP percentage of threads and additional threads per processor:

Location: HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

Value: AdditionalPoolThreadsPerProc

Type: REG_DWORD

Location: HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

Value: MaxPercentPoolThreads

Type: REG_DWORD

Both registry values should be adjusted on clustered Exchange Server computers if high SMTP activity causes POP3, IMAP4, or both resources to fail. You can use the following formulas to calculate the optimum value for your cluster:

Registry Value | Formula
AdditionalPoolThreadsPerProc | ((9 / (MaxPercentPoolThreads/100)) - 4) / 2
MaxPercentPoolThreads | 90 / (2 * Number of protocol virtual servers)

For example, in an Exchange Server cluster with two protocol virtual servers, the formula for MaxPercentPoolThreads would be: 90 / (2*2) = 22. When calculating the MaxPercentPoolThreads value, if your calculations result in a value that includes a decimal point, you should round the result down to the next integer. When calculating the AdditionalPoolThreadsPerProc value, if your calculations result in a value that is greater than 200, you will also need to assign the resulting value to an additional registry value:

Location: HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\

Value: PoolThreadLimit

Type: REG_DWORD

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To configure the optimal setting on your Exchange cluster

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. Create a DWORD registry value called AdditionalPoolThreadsPerProc and set its value data to the appropriate number based on the above formulas.

  4. Create a DWORD registry value called MaxPercentPoolThreads and set its value data to the appropriate number based on the above formulas.

  5. Exit the registry editor and restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about the specific cluster resource issue described in this article, see the Knowledge Base article 281868, "XADM: POP\IMAP4 Virtual Servers Repeatedly Fail Over Under High Load" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=281868).


The SMTP MsgHandleAsyncThreshold registry value has been manually added but may no longer be needed
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the maximum number of asynchronous Internet Information Services (IIS) file handles has been modified from the default value of 1,000:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\MsgHandleAsyncThreshold

If the Exchange Server Analyzer finds MsgHandleAsyncThreshold to be present and configured with an alternate value, a warning is displayed.

The MsgHandleAsyncThreshold value specifies the maximum number of asynchronous file handles that IIS can use. File handles are cached to improve performance because cached file handles save the server from performing redundant input/output (I/O) and CPU cycles. Each time the SMTP transport stack on an Exchange Server computer receives a message, it is streamed out to the file system where it waits to be routed to its destination. To write to the file system, the SMTP transport stack obtains a file handle and then passes the message into that handle. Each file handle consumes approximately 2 kilobytes (KB) of paged pool memory. The default number of IIS cache file handles is 800 for every 32 MB.

Prior to Exchange 2000 Server with Service Pack 2 (SP2), Exchange servers that sustained large SMTP message queues (for example, an average of 1,000 or more messages) have encountered performance constraints because of a default setting on the SMTP service of a maximum of 1,000 file handles. Because Exchange 2000 Server defaulted to a maximum of 1,000 file handles, the SMTP service could write only 1,000 simultaneous messages to the file system.

To improve performance for these large systems, three registry entries were often simultaneously adjusted to increase the maximum number of file handles that could be opened by the SMTP service (so that more messages could be processed) and to decrease the number of open file handles for the installable file system, another Exchange component (to avoid running out of memory when the queue is large). These registry values, which did not exist by default and therefore needed to be manually added, are listed below:

Location: HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

Value: MsgHandleThreshold

Type: REG_DWORD

Location: HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

Value: MsgHandleAsyncThreshold

Type: REG_DWORD

Location: HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

Value: FileCacheMaxHandles

Type: REG_DWORD

The MsgHandleThreshold and MsgHandleAsyncThreshold entries are typically tuned to the same value (usually a value greater than 1,000) and the FileCacheMaxHandles value is usually reduced from 800 to 600.

This registry value is not present by default because Exchange 2000 Server with SP2 and later dynamically determines the optimal values to use. If this Exchange server is running Exchange 2000 Server with Service Pack 1 (SP1) or earlier, it is recommended as a best practice that you upgrade to the latest service pack and roll-up package. After you have upgraded to the latest code, you can delete these registry entries.

Exchange Server 2003 dynamically calculates the appropriate settings for SMTP file handles, so these settings are no longer needed. Therefore, unless directed otherwise by Microsoft Product Support Services, before upgrading any Exchange 2000 Server computers with these settings to Exchange Server 2003, you should delete these entries from the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To revert to the default configuration

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. In the right-hand pane, delete the MsgHandleAsyncThreshold value.

  4. Close the registry editor, and then restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


The SMTP MsgHandleThreshold registry value has been manually added but may no longer be needed
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if the maximum number of Internet Information Services (IIS) file handles has been modified from the default value of 1,000:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\MsgHandleThreshold

If the Exchange Server Analyzer finds MsgHandleThreshold to be present and configured with an alternate value, a non-default configuration message is displayed.

The MsgHandleThreshold value specifies the maximum number of file handles that IIS can use. File handles are cached to improve performance because cached file handles save the server from performing redundant input/output (I/O) and CPU cycles. Each time the SMTP transport stack on an Exchange Server computer receives a message, it is streamed out to the file system where it waits to be routed to its destination. To write to the file system, the SMTP transport stack obtains a file handle and then passes the message into that handle. Each file handle consumes approximately 2 kilobytes (KB) of paged pool memory. The default number of IIS cache file handles is 800 for every 32 MB.

Prior to Exchange 2000 Server with Service Pack 2 (SP2), Exchange servers that sustained large SMTP message queues (for example, an average of 1,000 or more messages) have historically encountered performance constraints because of a default setting on the SMTP service of a maximum of 1,000 file handles. Because Exchange 2000 Server defaulted to a maximum of 1,000 file handles, the SMTP service could write only 1,000 simultaneous messages to the file system.

To improve performance for these large systems, three registry entries were often simultaneously adjusted to increase the maximum number of file handles that could be opened by the SMTP service (so that more messages could be processed) and to decrease the number of open file handles for the installable file system, another Exchange component (to avoid running out of memory when the queue is large). These registry values, which did not exist by default and therefore needed to be manually added, are listed below:

Location: HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

Value: MsgHandleThreshold

Type: REG_DWORD

Location: HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

Value: MsgHandleAsyncThreshold

Type: REG_DWORD

Location: HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

Value: FileCacheMaxHandles

Type: REG_DWORD

The MsgHandleThreshold and MsgHandleAsyncThreshold entries are typically tuned to the same value (usually a value greater than 1,000) and the FileCacheMaxHandles value is usually reduced from 800 to 600.

If this Exchange server is running Exchange 2000 Server, it is recommended as a best practice that you upgrade to the latest level of service pack and roll-up package. After you have upgraded to the latest code, it is recommended that the MsgHandleThreshold value be set to the default of 1000.

The default MsgHandleThreshold value for Exchange Server 2003 is 1000, so these registry override settings are no longer needed. Therefore, unless directed otherwise by Microsoft Product Support Services, before upgrading any Exchange 2000 Server computers with these settings to Exchange Server 2003, you should delete these entries from the registry.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

To correct this error

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. Delete the MsgHandleThreshold value.

  4. Close the registry editor, and then restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).


SMTP Pickup files are being written to a compressed folder
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Compressed key for the Simple Mail Transfer Protocol (SMTP) PickUp folder. If the Exchange Server Analyzer finds the value for Compressed set to True, a warning is displayed.

When messages arrive at the Exchange computer through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are stored in the <drive>:\Program Files\Exchsrvr\Mailroot folder on the same partition that Exchange is installed on. If the folder where the SMTP PickUp data is stored has file compression turned on, Exchange performance may be severely degraded. Therefore, compression for the folder where the SMTP PickUp data is stored is not supported.

If you receive this warning, you must turn off compression on the folder where the SMTP PickUp data is stored, or you must move the SMTP PickUp data to a folder that is not compressed.

Microsoft does not support the storage of Exchange data files on a compressed volume. When you store your Exchange data files on a compressed volume, the additional overhead significantly affects Exchange performance. The Exchange data files include all the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To turn off file compression on a given folder

  1. Right-click the folder where you want to turn off file compression, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Compress contents to save disk space check box, and then click OK.

For more information about moving the PickUp folder, see the Microsoft Knowledge Base article, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933).


SMTP Pickup files are being written to an encrypted folder
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Encrypted key for the Simple Mail Transfer Protocol (SMTP) PickUp folder. If the Exchange Server Analyzer finds the value for Encrypted set to True, a warning is displayed.

When messages arrive at the Exchange computer through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are stored in the <drive>:\Program Files\Exchsrvr\Mailroot folder on the same partition that Exchange is installed on. If the folder where the SMTP PickUp data is stored has file encryption turned on, Exchange performance may be severely degraded. Therefore, encrypting the folder where the SMTP PickUp data is stored is not supported.

If you receive this warning, you must turn off encryption on the folder where the SMTP PickUp data is stored, or you must move the SMTP PickUp data to a non-encrypted folder.

Microsoft does not support the storage of Exchange data files on an Encrypting File System (EFS) encrypted volume. When you store your Exchange data files on an encrypted volume, the additional overhead significantly affects Exchange performance. Exchange data files include the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

  • .chk files

To help secure your Exchange data files, it is recommended that you prevent unauthorized access to the Exchange computer and that you use the S/MIME message format to encrypt message data.

To resolve this error, you must either turn off file encryption on the PickUp folder, or move the PickUp folder to a location where encryption is not enabled.

To turn off file encryption on a given folder

  1. Right-click the folder where you want to turn off file encryption, and then click Properties.

  2. On the General tab, click Advanced.

  3. In the Advanced Attributes dialog box, clear the Encrypt contents to secure data check box, and then click OK.

For more information about moving the PickUp folder, see the Microsoft Knowledge Base article 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933).

For more information about Exchange Server data files and EFS, see the Knowledge Base article 834638, "Information about the storage of data files on an encrypted volume in Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638).

For information about how to secure messages in Exchange Server 2003, see the Exchange Server 2003 Message Security Guide (http://go.microsoft.com/fwlink/?linkid=47574).


SMTP Pickup files are being written to a non-NTFS partition
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Directory Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the FSName key for the Exchange SMTP PickUp directory. If the Exchange Server Analyzer determines that the value for the FSName key does not equal NTFS, a warning is displayed.

Microsoft does not support the storage of Exchange data files on non-NTFS volumes. Exchange data files include the following files:

  • .edb files

  • .stm files

  • .log files

  • .dat files

  • .eml files

If you see this warning, you must move the SMTP PickUp directory to a folder on an NTFS file system drive. Alternatively, if the drive on which the PickUp directory is stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS.

For more information about moving the PickUp folder, see the Microsoft Knowledge Base article 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933).

Alternatively, if the drive on which the files are stored is formatted as a FAT drive, you can use the convert.exe command-line tool to convert the drive to NTFS. For information about using the convert.exe command-line tool to convert a FAT partition to an NTFS partition, see the Knowledge Base article 214579, "How to Use Convert.exe to Convert a Partition to the NTFS File System" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579).


SMTP Port Change
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-11

The Microsoft® Exchange Server Analyzer Tool reads the following property in the Internet Information Services (IIS) metabase to determine whether its value matches the default value of 25:

LM/SmtpSvc/<SMTP virtual server instance>/SMTPPORT

If the Exchange Server Analyzer finds that the value for the SMTPPORT property is not 25, the Exchange Server Analyzer displays a warning.

The SMTPPORT property represents the TCP port on which this Simple Mail Transfer Protocol (SMTP) server listens for incoming connections. SMTP virtual servers can be configured to listen on one or more TCP ports. By default, all SMTP virtual servers are configured to listen on TCP port 25, the default SMTP port. If the SMTP listening port has been modified from the default and no longer includes TCP port 25 in its list of listening ports, this modification could disrupt mail flow.

It is acceptable to change the SMTP listening port, provided that the rest of your internal messaging infrastructure is also modified accordingly. However, generally, alternative ports cannot be used for SMTP virtual servers that accept messages directly from the Internet, as SMTP servers on the Internet send messages through port 25.

Note:
The Exchange Server Analyzer examines the value for the Exchange SMTP protocol virtual server. This SMTP protocol virtual server is not necessarily the SMTP server that receives messages directly from the Internet. There are some antivirus and anti-spam products that are designed to receive SMTP messages from the Internet on port 25 and redirect to an Exchange SMTP virtual server on another port. In this scenario, an Exchange SMTP virtual server that listens on something other than port 25 is an acceptable configuration.
To view or modify the SMTP virtual server listening port

  1. In Exchange System Manager, expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  2. Right-click an SMTP virtual server, for example, Default SMTP Virtual Server, and then click Properties.

  3. Select the General tab, and then click Advanced.

  4. A list of IP addresses and ports will be displayed.

    • To change the existing port, select the IP address, and then click Edit. Change the TCP port field to 25.

    • To add port 25 as an additional listening port, click Add, and add the new IP address/port combination. If you are using connection, sender or recipient filtering, make sure that you select the appropriate check boxes.

  5. Click OK to save your changes, and then click OK to exit the Advanced dialog box. Click OK to close the Properties dialog box for the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Microsoft Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686).

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163).


SMTP queue folder contains a large number of files
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the Internet Information Services (IIS) metabase for the value of the QueueDirectory attribute of each Simple Mail Transfer Protocol (SMTP) virtual server instance.

The Exchange Server Analyzer then counts the number of files in the queue folder that is specified for each SMTP virtual server.

If the Exchange Server Analyzer finds that there are 50,000 or more files in the queue folder for an SMTP virtual server, the Exchange Server Analyzer displays a warning.

If the Exchange Server Analyzer finds that there are 90,000 or more files in the queue folder for an SMTP virtual server, the Exchange Server Analyzer displays an error.

This warning or error means that there is a buildup of messages that the SMTP virtual server instance must process. The warning or error indicates a significant performance issue or outage on the server, because the server can no longer deliver the incoming mail in a timely manner. The following conditions can cause this delay:

  • The Active Directory® directory service is not being consulted quickly.

  • Messages are not being handed off quickly for local delivery or SMTP.

To address this issue:

  • Review the messages in the queue folder for legitimacy to verify that the server is not under abnormal load because of unsolicited commercial e-mail (UCE), or spam, or a virus attack.

  • Verify the SMTP service is enabled and running.

To verify the SMTP service is started

  1. Open the Services Microsoft Management Console (MMC) snap-in.

  2. In the right pane, scroll down to the Simple Mail Transfer Protocol (SMTP) service and double-click it. This will display the Simple Mail Transfer Protocol (SMTP) Properties dialog box.

  3. Verify the value in the Startup type drop-down menu is set to Automatic.

  4. Click Start to start the System Attendant service.

  5. Click OK to save the changes and close the Simple Mail Transfer Protocol (SMTP) Properties dialog box.

  6. Close the Services snap-in.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


SMTP queue folder and pickup folder are identical
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to verify that the directory from which messages are picked up is not the same directory to which messages are queued for a specific SMTP virtual server. If the Exchange Server Analyzer finds that the attribute for the Queue directory, which is msExchSmtpQueueDirectory, and the attribute for the Pickup directory, which is msExchSmtpPickupDirectory, are the same, the Exchange Server Analyzer displays an error.

This error is a critical error. If the msExchSmtpQueueDirectory attribute and the msExchSmtpPickupDirectory attribute are set to the same directory, duplicate messages are delivered. You can update these attributes by using Active Directory Service Interfaces (ADSI) Edit.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.
To update the attribute for msExchSmtpPickupDirectory or msExchSmtpQueueDirectory by using ADSI Edit

  1. Start the ADSI Edit tool from Windows® 2000 Support Tools or from Windows Server 2003 Support Tools.

  2. Expand the following nodes:

    • Configuration Container

    • Configuration

    • Services

    • Microsoft Exchange

    • Organization_Name

    • Recipient Policies

    • Administrative_Group_Name

    • Servers

    • Server_Name

    • Protocols

    • SMTP

  3. In the details pane, right-click CN=1 (where 1 is the default SMTP virtual server), and then click Properties.

  4. In the Select which properties to view list, click Both.

  5. Update the attribute for msExchSmtpPickupDirectory so that it no longer conflicts with msExchSmtpQueueDirectory, and then click Set after you are finished.

  6. Click OK, click Apply, and then close ADSI Edit.

  7. Wait at least 15 minutes for replication.


SMTP queue is on the same drive as the system partition
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the configured value for the msExchSmtpQueueDirectory attribute.

The Exchange Server Analyzer also queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Simple Message Transfer Protocol (SMTP) service. A value of False indicates that the service is not running. A value of True indicates that the service is running. Additionally, the Exchange Server Analyzer queries the Win32_OperatingSystem WMI class to determine the value of the WindowsDirectory key. The value of this key indicates the location of the Windows system drive.

If the Exchange Server Analyzer finds that the msExchSmtpQueueDirectory attribute is configured with a path that includes the same drive as the system drive, the SMTP service is running, and Exchange is not running on Microsoft Windows Small Business Server, a warning is displayed.

The msExchSmtpQueueDirectory attribute represents the path for the SMTP queue folder, also known as the Mailroot folder. When messages arrive at the Exchange server through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are stored on the <drive>:\Program Files\Exchsrvr\Mailroot folder on the same partition on which Exchange is installed.

In some scenarios, such as when you configure a bridgehead server, you can increase the performance of the Exchange server if you move the SMTP Mailroot directory to a different hard disk or partition. As a best practice, the SMTP Mailroot folder should not be on the same drive as the Windows system drive. Instead, it should be on a fast disk or fast disk subsystem for optimal performance.

While the Mailroot folder can be moved in Exchange System Manager on an Exchange Server 2003 SMTP virtual server, moving it on an Exchange 2000 Server SMTP virtual server requires using a low-level Active Directory editor, such as Active Directory Service Interfaces (ADSI) Edit.

Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

To correct this error on Exchange Server 2003

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server), and then click Stop.

  4. Right-click the SMTP virtual server again, and then click Properties.

  5. Click the Messages tab.

  6. In the Queue directory field, specify the full path of the appropriate Mailroot folder. You can click Browse to browse the local computer for the path.

  7. Click OK to save the changes.

  8. Right-click the SMTP virtual server, and then click Start. The new location will be used immediately.

To correct this error on Exchange 2000 Server

  1. Stop all the Exchange Server and IIS services on the Exchange 2000 Server computer whose SMTP virtual server Mailroot folder you want to modify.

  2. Modify the affected SMTP virtual server's value for msExchSmtpQueueDirectory so that it is configured with the appropriate path.

  3. Wait for Active Directory to replicate this change to the global catalog servers used by this Exchange server.

  4. Start the Microsoft Exchange System Attendant service.

  5. On the Exchange Server computer, check for the presence of three instances of Event ID 1005 in the Application event log that have an Event Source of MSExchangeMU and a Category of General.

  6. Restart the Exchange Server computer for the changes to take effect.

For more information about both of the procedures that are described, see the following Microsoft Knowledge Base articles:

  • 822933, "How to change the Exchange 2003 SMTP Mailroot folder location" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822933)

  • 318230, "XCON: How to Change the Exchange 2000 SMTP Mailroot Directory Location" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=318230)

For more information about SMTP virtual server settings, see the Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


The SMTP ResetMessageStatus registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether default SMTP queuing configurations have been changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing

The Exchange Server Analyzer displays an error if the following conditions exist:

  • The ResetMessageStatus key is not set to 0 (zero).

  • The Cluster service is not running on the Exchange Server.

When the ResetMessageStatus registry key is set to 1, all messages currently in the queue go through all internal processing queues again when the Exchange Server is restarted. For example, all messages currently in the queue will go through the categorizer again when the Exchange Server is restarted. Therefore, the ResetMessageStatus key should be set to 1 only for troubleshooting SMTP installation issues, as documented in the Microsoft Knowledge Base article 279616, "XCON: Adding a Registry Key to Re-Categorize Messages" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=279616). If you are not troubleshooting SMTP installation issues, you should delete this registry key.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To delete the ResetMessageStatus registry key

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. In the right pane, locate and delete the ResetMessageStatus value.

  4. Close the registry editor.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

For more information about Exchange SMTP queuing, see the Microsoft Exchange Team Blog entry, "Explaining the Mysterious SMTP Advanced Queuing Engine" (http://go.microsoft.com/fwlink/?LinkId=48585).


The SMTP ResetRoutesRetryMinutes registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether default SMTP queuing configurations have been changed:

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

If the Exchange Server Analyzer finds that the ResetRoutesRetryMinutes key has been set, the Exchange Server Analyzer displays a non-default message.

It is recommended that the default queuing values be modified only after complete consideration. The defaults were carefully selected for optimal performance in most environments. A general best practice is to address the root cause of the problem instead of modifying the queuing behavior on Exchange Server.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about Exchange SMTP queuing, see the Microsoft Exchange Team Blog entry, "Explaining the Mysterious SMTP Advanced Queuing Engine" (http://go.microsoft.com/fwlink/?LinkId=48585).


The SMTP RoutingRetryMinutes registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether default SMTP queuing configurations have been changed:

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

If the Exchange Server Analyzer finds that the RoutingRetryMinutes key has been set, the Exchange Server Analyzer displays a non-default message.

It is recommended that the default queuing values be modified only after complete consideration. The defaults were carefully selected for optimal performance in most environments. A general best practice is to address the root cause of the problem instead of modifying the queuing behavior on Exchange Server.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about Exchange SMTP queuing, see the Microsoft Exchange Team Blog entry, "Explaining the Mysterious SMTP Advanced Queuing Engine" (http://go.microsoft.com/fwlink/?LinkId=48585).


The SMTP SecondsPerDSNPass registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine the setting on the SecondsPerDSNPass registry value:

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

If the Exchange Server Analyzer finds that the SecondsPerDSNPass key is present and not set to 10, the Exchange Server Analyzer displays a non-default configuration message.

This setting is used to optimize Delivery Status Notifications (DSNs) and specifies the number of seconds for each DSN processing pass. As soon as this threshold has been surpassed, DSN generation will be stopped and then restarted later. It is recommended that the default values be modified only after serious consideration. This specific setting should only be modified after consulting with Microsoft Support Services. The defaults were carefully selected for optimal performance in most environments. A general best practice is to address the root cause of the problem instead of modifying the queuing behavior on the Exchange server.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.


SMTP server has NTLM authentication disabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-11-10

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the NTLM authentication protocol (also known as Integrated Windows Authentication) bit in the msExchAuthenticationFlags attribute is set. If the Exchange Server Analyzer determines that the bit is not set, and Exchange is not running on Microsoft Windows® Small Business Server, a warning is displayed.

The msExchAuthenticationFlags attribute indicates which type of authentication a protocol virtual server accepts. This attribute uses a three-bit mask.

Bit | Authentication Method
0 | Anonymous
1 | Basic
2 | NTLM (Integrated Windows Authentication)

If the bit that controls NTLM authentication is not set, the SMTP virtual server will not allow NTLM authentication. This can cause authentication problems between Exchange Server computers.

To correct this warning

  1. Open Exchange System Manager.

  2. Expand Servers, expand the server Name, expand Protocols, and then expand SMTP.

  3. Right-click the Exchange SMTP virtual server, and then click Properties.

  4. Click the Access tab, click Authentication, and then click to select the Integrated Windows Authentication check box.

  5. Click OK, and then click OK again.

  6. Close Exchange System Manager.

For more information about authentication methods for SMTP, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579), and see the Microsoft Knowledge Base article 319267, "HOW TO: Secure Simple Message Transfer Protocol Client Message Delivery in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319267).


The SMTP SubmissionRetryMinutes registry value is non-default
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether default SMTP queuing configurations have been changed:

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

If the Exchange Server Analyzer finds that the SubmissionRetryMinutes key has been set, the Exchange Server Analyzer displays a non-default message.

It is recommended that the default queuing values be modified only after complete consideration. The defaults were carefully selected for optimal performance in most environments. A general best practice is to address the root cause of the problem instead of modifying the queuing behavior on Exchange.

The Exchange Server Analyzer reports this configuration for informational purposes only. No action is required.

For more information about Exchange SMTP queuing, see the Microsoft Exchange Team Blog entry, "Explaining the Mysterious SMTP Advanced Queuing Engine" (http://go.microsoft.com/fwlink/?LinkId=48585).


The SMTP virtual server has a higher message size limit than the global message size limit
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to compare the SMTP virtual server incoming message size limits with the incoming global message size limits.

The Active Directory attribute that represents the SMTP virtual server message size limit for incoming and outgoing messages is msExchSmtpMaxMessageSize. This value is an attribute of the SMTP virtual server object in Active Directory, which is found at:

CN= <Virtual Server Number>, CN=SMTP, CN=Protocols, CN= <ServerName> , CN=Servers, CN= <AdministrativeGroupName> , CN=Administrative Groups, CN= <OrganizationName>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC= <DomainName>, DC=com

The Active Directory attribute that represents the global incoming message size limit is delivContLength. This value is an attribute of the organization's global settings message delivery object in Active Directory, which is found at:

CN=Message Delivery, CN=Global Settings, CN= <OrganizationName> , CN=Microsoft Exchange, CN=Services, CN=Configuration, DC= <DomainName>, DC=com

If the Exchange Server Analyzer finds that the value for msExchSmtpMaxMessageSize is greater than the value for delivContLength, a warning is displayed.

If any SMTP virtual server has a higher message size limit than the global message size limit, it could cause oversize messages to be accepted inbound and then subsequently non-delivered. To resolve this issue, configure the SMTP virtual server with a maximum message size that is equal to or less than the global incoming message size limit.

Note:
If you set the message size limit too low, it could prevent offline address book replication between Exchange Server computers. For more information about this issue, see the Microsoft Knowledge Base article 326154, "XADM: The OAB Does Not Replicate If You Set a Message Size Restriction at the Transport Level" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=326154).

To correct this warning

  1. In Exchange System Manager, expand Servers, then expand an Exchange server, then expand Protocols, then expand SMTP.

  2. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and select Properties.

  3. Select the Messages tab.

  4. Edit the value for the Limit message size to (KB) field so that it is equal to or less than the global message size limit.

  5. Click OK to save the changes and to close the Properties dialog box of the SMTP virtual server.

For more information about SMTP virtual server settings, see the following Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

For more information about viewing and editing organization-wide settings, see Knowledge Base article 821881, "How to Modify Global Settings in Exchange System Manager" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821881).

For more information about global message size limits, see the following Knowledge Base articles:

  • 298572, "An E-Mail Message That Is Larger Than the Sending Message Size Limit or the Receiving Message Size Limit Is Not Delivered" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=298572)

  • 322679, "Set Size Limits for Messages" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679)

  • 824111, "Security Setting Changes and Updates That Are Introduced in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=824111)


This SMTP virtual server is configured to perform reverse DNS lookups for incoming messages
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-24

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the configured value for the msExchSmtpPerformReverseDnsLookup attribute has been changed from the default value of False. By default, the msExchSmtpPerformReverseDnsLookup attribute is configured not to perform reverse DNS lookups for incoming messages. If the Exchange Server Analyzer finds that this attribute is set to True, a warning is displayed.

The Perform Reverse DNS Lookup for Incoming Messages option does not have functionality to prevent the receipt of spam e-mail messages. When this option is used, Exchange Server performs a DNS query to resolve the originating Internet Protocol (IP) address of the incoming messages to a host name. Then, the host name is attached to the headers of e-mail messages.

With this feature enabled, you may experience performance degradation because of incorrectly configured DNS records or intermittent connections to the Internet. Therefore, you may want to disable this option when the Internet mail delivery is slower than expected.

To enable or disable reverse DNS lookups for incoming SMTP messages

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server), and then click Properties.

  4. Click the Delivery tab, and then click Advanced.

    • To enable reverse DNS lookups, select the Perform reverse DNS lookup on incoming messages check box.

    • To disable reverse DNS lookups, clear the Perform reverse DNS lookup on incoming messages check box.

  5. Click OK to save the change, and then click OK to exit the SMTP virtual server Properties dialog box.

For more information about the reverse DNS lookup feature in Exchange, see the Microsoft Knowledge Base article 297412, "The 'Perform Reverse DNS Lookup for Incoming Messages' Option Is for Host Name Resolution" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412).

For more information about SMTP virtual server settings, see the following Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


SP1 Version of Intelligent Message Filter is Enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether Microsoft Exchange Intelligent Message Filter is installed and enabled on the server:

HKEY_LOCAL_MACHINE\ Software\Microsoft\Exchange\ContentFilter

The Exchange Server Analyzer reads the ContentFilterBindings value in the ContentFilter registry key to determine whether Intelligent Message Filter is installed and enabled on the server.

The Exchange Server Analyzer then queries the CIM_Datafile Microsoft Windows® Management Instrumentation (WMI) class to determine whether the Exchange Server 2003 Service Pack 1 (SP1) version of Intelligent Message Filter MSExchange.UceContentFilter.dll is in the following path on the Exchange Server:

<path to Exchange server binary files>\MSCFv1\MSExchange.UceContentFilter.dll

Note:
In this path, <path to Exchange server binary files> refers to the location of the bin folder.

If the Exchange Server 2003 SP1 version of Intelligent Message Filter is installed and enabled on the server, the Exchange Server Analyzer displays a warning.

This warning indicates that a more recent version of Intelligent Message Filter is available. It is recommended that you install the latest version of Intelligent Message Filter. If you are troubleshooting mail flow issues that involve this particular server, you may want to temporarily disable the Intelligent Message Filter to determine whether it is incorrectly blocking legitimate mail.

To Disable Intelligent Message Filter

  1. Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In Exchange System Manager, expand Servers, expand Server name, expand Protocols, expand SMTP, right-click Intelligent Message Filtering, and then click Properties.

  3. On the General tab, under Apply intelligent message filtering to the following virtual servers' IP addresses, clear the check box next to each SMTP virtual server on which you want to disable Intelligent Message Filter.

    The Intelligent Message Filtering Properties dialog box

For more information, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).


SP2 Version of Intelligent Message Filter Enabled
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-04

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the msExchServerBindingsFiltering property of a Simple Mail Transfer Protocol (SMTP) virtual server object indicates that the Intelligent Message Filter is enabled for an SMTP virtual server instance.

The Exchange Server Analyzer also queries Active Directory to determine whether the msExchUceEnabled is enabled at the Global Settings level.

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • The Intelligent Message Filter is enabled for an SMTP virtual server instance.

  • The Intelligent Message Filter is enabled at the Global Settings level.

This warning indicates that the Exchange Server 2003 Service Pack 2 (SP2) version of Intelligent Message Filter is effectively enabled. Having the SP2 version of Intelligent Message Filter enabled is not generally an issue unless you are troubleshooting mail flow issues involving this particular server. If that is the case, you may want to verify the filter configuration or temporarily disable the Intelligent Message Filter to determine whether it is incorrectly blocking legitimate mail.

To Disable Intelligent Message Filter

  1. Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In Exchange System Manager, expand Servers, expand Server name, expand Protocols, and then expand SMTP.

  3. In SMTP Virtual Server Properties, on the General tab, click Advanced.

  4. Select the IP address for which you want to disable the Intelligent Message Filter and then click Edit.

  5. In Identification, clear the Apply Intelligent Message Filter.

  6. If you have multiple virtual servers, repeat Steps 3 through 6 for each virtual server on which you want to disable the Intelligent Message Filter.

For more information, see the Exchange Intelligent Message Filter Web site (http://go.microsoft.com/fwlink/?LinkId=21607).


Specified gateway server not used
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-09

The Microsoft® Exchange Server Analyzer Tool sends a test message from the Exchange server to a user-defined external account and then scans the message tracking logs of the server to determine whether there were any issues found with the delivery of the test message.

As part of this scan, the Exchange Server Analyzer checks to see whether the Exchange gateway server that is used to route the message to the external recipient is the same as the one specified by the user on the Enter Server and User information page of the Server Name and Credentials step.

If the Exchange Server Analyzer determines that the message was successfully routed outside the Exchange organization but did not use the gateway server specified, the Exchange Server Analyzer displays a warning.

This warning indicates that there may be a problem with the Exchange routing topology and that unknown outbound gateway servers are present.

Routing problems may occur if Smart Host entries are set at the virtual server level instead of at the connector level. It is a recommended best practice that any Smart Host entries be set on the SMTP connector and not on the SMTP virtual server.

To troubleshoot this warning, take the following steps:

  • Review the Simple Mail Transfer Protocol (SMTP) virtual server's configuration to make sure that there are no Smart Host entries set.

  • Review the configuration of local bridgehead servers for correct address spaces and costs on the connectors.

To view and configure smart host settings

  1. Open Exchange System Manager.

  2. Expand Servers, expand an Exchange server, expand Protocols, and then expand SMTP.

  3. Right-click an SMTP virtual server (for example, Default SMTP Virtual Server) and select Properties.

  4. Select the Delivery tab, and then click Advanced.

  5. Clear any entries under Smart host.

  6. Click OK to save the changes, and then click OK to close the Properties dialog box of the SMTP virtual server.

For more information about how to configure SMTP connectors, see Microsoft Knowledge Base article 822941, "How to use SMTP connectors to connect routing groups in Exchange 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822941).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).


Specified sender on different server
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-08-10

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service proxyAddress attribute value for all user objects to determine whether there is a match for the user-specified local sender Simple Mail Transfer Protocol (SMTP) address.

If a user object proxyAddress match is found, the Exchange Server Analyzer then queries Active Directory for the value of the msExchHomeServerName attribute for the user object to determine whether that value matches the user-specified Exchange Server name.

If the Exchange Server Analyzer determines that the value of the msExchHomeServerName attribute for the user-specified sender does not match the user specified Exchange Server name, the Exchange Server Analyzer displays a warning.

This warning indicates either that an incorrect Exchange Server name has been provided or that the mail flow issue affects a server other than the one specified by the user.

To address this issue, verify the correct Exchange Server name is entered.

To view the user mailboxes on the specified server

  1. Start Exchange System Manager:

    Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.

  2. In Exchange System Manager, navigate to and then click the following container:

    \Administrative Groups\ GroupName \Servers\ ServerName \ StorageGroupName \Mailbox Store\Mailboxes

  3. Verify the user mailbox specified is displayed on the Exchange server specified.


Target destination servers could not be identified
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-07-06

The Microsoft® Exchange Server Analyzer Tool tries to identify and build a list of the Fully Qualified Domain Names (FQDN), IP addresses, and domain names of remote servers that mail in a remote delivery queue is destined for.

The list of the FQDNs, IP addresses, and domain names of remote servers is built as follows:

  • The msExchSmtpFullyQualifiedDomainName property of the Active Directory® directory service object of the Simple Mail Transfer Protocol (SMTP) virtual server is queried.

    Note:
    The msExchSmtpFullyQualifiedDomainName property, in turn, is read from the msExchTargetBridgeheadServersDN property of a routing group connector directory object when that is queried for the designated target bridgehead servers
  • The msExchSmtpSmartHost property of the SMTP connector Active Directory object is queried for the designated smart host for an SMTP connector.

  • The LinkName property of the ExchangeLink Microsoft Windows® Management Instrumentation (WMI) class is queried for any remote server direct connections.

If the Exchange Server Analyzer determines that the attempt to build this list resulted in no entries, the Exchange Server Analyzer displays an error.

This error indicates:

  • There may be intermittent network or Active Directory connection issues that are causing mail flow issues.

  • The account that runs the Exchange Server Analyzer may not have sufficient permissions to query for the information.

To correct this error

  1. Make sure that the Exchange Server computer has been started and is connected to the network.

  2. Verify that you have network connectivity to an Active Directory domain controller.

  3. Specify an Active Directory domain controller in the Exchange Server Analyzer.

  4. Use the PING command to see whether the Exchange Server computer is reachable.

  5. If there is a firewall, check to see whether RPC ports are blocked.

  6. Examine the permissions for the account under which the Exchange Server Analyzer is running. The account under which the Exchange Server Analyzer is running must have local Administrator permissions on each Exchange Server computer that it scans.

For more information about network connectivity problems, see the Microsoft Knowledge Base article 325487, "How to troubleshoot network connectivity problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487).

For more information about Exchange Server Analyzer connectivity problems, see "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?LinkId=56285).

For more information about port requirements, see the Knowledge Base article 832017, "Service overview and network port requirements for the Windows Server system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017).


TarpitTime has been implemented
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-02-21

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine whether the tar pit feature of recipient filtering has been set:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters\TarpitTime

If the Exchange Server Analyzer finds that the value for TarpitTime is larger than 0 (zero), the Exchange Server Analyzer displays a non-default message.

Tar pitting is the practice of intentionally slowing down or delaying illegitimate connections to reduce the rate at which automated spam can be sent or at which a dictionary harvest attack can be conducted.

The tar pit feature that is available in Microsoft Windows Server™ 2003 Service Pack 1 (SP1) can be added to work with recipient filtering as described in the Microsoft Knowledge Base article 842851, "SMTP tar pit feature for Microsoft Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=842851). Specifically, the tar pit feature extends the usefulness of recipient filtering when the Filter recipients who are not in the Directory check box is selected on the Recipient Filtering tab in Global Settings.

The tar pit feature is implemented by setting the TarpitTime registry subkey. The TarpitTime registry subkey takes a decimal value. The decimal value translates to the number of seconds the SMTP session waits to respond to a sender when a recipient does not exist in the target Exchange Server organization.

Tar pit functionality makes it much more difficult for spammers who send unsolicited mail to automate a directory harvest attack. A directory harvest attack is an attempt to retrieve a list of known good e-mail addresses from a particular organization.

The SMTP protocol acknowledges acceptable recipients during an SMTP session by returning "2.1.5 Recipient OK." In the case where an unknown recipient is sent mail, the SMTP protocol returns a "5.x.x" error. Therefore, a spammer can write an automated program that uses common names or dictionary terms to construct e-mail addresses to a specific domain. The program can then collect all e-mail addresses that return "2.1.5 Recipient OK," and discard all e-mail address that cause "5.x.x" errors. The spammer can then sell the "good" e-mail addresses or use them as recipients for unsolicited mail.

If the Filter recipients who are not in the Directory check box is selected, but the TarpitTime registry subkey is not set, Exchange Server immediately returns a "5.x.x" error during the SMTP session to the sender when a recipient does not exist in the target Active Directory® directory service.

Alternatively, if the TarpitTime registry subkey is set, and the Filter recipients who are not in the Directory check box is selected, SMTP waits before returning the "5.x.x" error. The decimal value that is entered for the TarpitTime registry subkey is the number of seconds that SMTP will wait before returning the error. This pause in the SMTP session makes automating a directory harvest attack much more difficult.

As mentioned previously, the Exchange Server Analyzer displays a non-default message if the TarpitTime registry subkey is set. This message is for informational purposes only.

Important:
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To view or change the TarpitTime registry subkey

  1. Click Start, click Run, type regedit in the Open box, and then click OK.

  2. Locate and then click the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters\TarpitTime

  3. The Value data box contains a decimal number. This value represents the number of seconds that you want to delay SMTP address verification responses for each address that does not exist in Active Directory.

  4. If you change the value or delete the TarpitTime registry subkey, you must restart the Simple Mail Transport Protocol (SMTP) Service.

For more information, see the Microsoft Knowledge Base article 842851, "SMTP tar pit feature for Microsoft Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=842851).


Test Mail Generated NDR
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool sends a test message from the Exchange server to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain and then scans the message tracking logs of the server to determine whether issues were found with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer queries the EntryType property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine what occurred to cause the message tracking log entry(s) to be created.

If the Exchange Server Analyzer Tool finds a value of 1030 for the EntryType property, the Exchange Server Analyzer displays a warning.

This warning indicates that the test message generated a Non Delivery Report (NDR) and there may be a problem with the Simple Mail Transfer Protocol (SMTP) configuration for the server. An NDR should be expected if the targeted recipient does not exist, but this is an issue if the test message was sent to a legitimate recipient.

As a troubleshooting step, you may want to try to send other messages to the same recipient and review the NDRs to determine the cause.

For more information about how to troubleshoot NDRs, see "Troubleshooting Non-Delivery Report Messages" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Test Mail Sent to Badmail Directory
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-05-17

The Microsoft® Exchange Server Analyzer Tool sends a test message from the Exchange server to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain and then scans the message tracking logs of the server to determine whether there were issues with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer queries the EntryType property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine what caused the message tracking log entry.

If the Exchange Server Analyzer finds a value of 1021 for the EntryType property, the Exchange Server Analyzer displays a warning.

This warning indicates that the test message was sent to the Badmail directory for the Exchange server and there is a problem with the Simple Mail Transfer Protocol (SMTP) configuration for the server.

A message is entered into the Badmail directory for one of the following reasons:

  • It cannot be delivered.

  • The maximum number of retries has been exceeded.

  • It cannot be returned to the sender as undeliverable.

For more information about how to test outgoing mail flow, see Microsoft Knowledge Base article 297700, "How to test outbound mail flow with a file in the Pickup folder" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297700).

For more information about how to troubleshoot mail flow and SMTP, see "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).


Test Message Sitting in SMTP Queue
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-07-06

The Microsoft® Exchange Server Analyzer Tool sends a test message from the Exchange server to the Postmaster account or a user-defined account for the Simple Mail Transfer Protocol (SMTP) domain and then scans the message tracking logs of the server to determine whether any issues were found with the delivery of the test message.

As a part of this scan, the Exchange Server Analyzer queries the EntryType property for the Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) class under the root\MicrosoftExchangeV2 namespace to determine why the message tracking log entries were created.

The following table lists the possible EntryType values returned.

Value Name | Value
Message received through X400 | 0
Report received | 2
Message submitted | 4
Message transferred out | 7
Report transferred out | 8
Message delivered | 9
Report delivered | 10
Distribution list expanded | 26
Message redirected | 28
Message rerouted | 29
Server downgraded by MTA | 31
Report absorbed | 33
Report generated | 34
Unroutable report discarded | 43
Message deleted by Administrator | 50
Probe deleted by Administrator | 51
Report deleted by Administrator | 52
Message delivered locally | 1000
Message transferred in over backbone | 1001
Message transferred out over backbone | 1002
Message transferred out over gateway | 1003
Message transferred in over gateway | 1004
Report transferred in over gateway | 1005
Report transferred out over gateway | 1006
Report generated | 1007
SMTP: Message queued outbound | 1010
SMTP: Message transferred out | 1011
SMTP: Inbound message received | 1012
SMTP: Inbound message transferred | 1013
SMTP: Message rerouted | 1014
SMTP: Report transferred in | 1015
SMTP: Report transferred out | 1016
SMTP: Report generated | 1017
SMTP: Report absorbed | 1018
SMTP: Message submitted to Advanced Queuing | 1019
SMTP: Started outbound transfer of message | 1020
SMTP: Message sent to badmail directory | 1021
SMTP: Advanced Queue failure | 1022
SMTP: Message delivered locally | 1023
SMTP: Message submitted to Categorizer | 1024
SMTP: Started message submission to Advanced Queue | 1025
SMTP: Advanced Queue failed to deliver message | 1026
SMTP Store Driver: Message submitted from Store | 1027
SMTP Store Driver: Message delivered locally to Store | 1028
SMTP Store Driver: Message submitted to MTA | 1029
SMTP: Non-delivery report (NDR) generated | 1030
SMTP: Message transferred out | 1031

The Exchange Server Analyzer displays an error if the EntryType values returned indicate the following conditions are true:

  • The test message tracking log can be scanned successfully.

  • The test message did not successfully transfer out of the queue.

  • A Non Delivery Report (NDR) was not generated for the test message.

  • The test message was not transferred to the Badmail directory.

  • The test message is not queued for remote delivery.

  • The test message was not successfully delivered to the local store.

  • The test message is not scheduled to retry categorization.

  • The test message is not scheduled to retry routing.

  • The test message is not scheduled to retry local delivery.

This error means that the test message is sitting in one of the SMTP queues and additional analysis is necessary to determine the reason it is stuck there.

To resolve this error, use the NSlookup utility to review possible issues with Domain Name System (DNS) resolution. For connection and protocol issues such as Host unreachable errors, use Telnet.exe to try to connect to the destination computer. To troubleshoot protocol errors, increase diagnostic logging for the MSExchangeTransport service for the SMTP component, and review the logs for errors. Alternatively, you can use the Network Monitor (Netmon.exe) tool to obtain information about network connection errors. To reproduce the problem, you may have to force the queue to try again. Examine the event log for possible errors associated with the Microsoft Exchange Information Store service.

For more information about how to modify logging settings, see "How to Modify Logging Settings for MSExchangeTransport" in the "Troubleshooting Mail Flow and SMTP" section of the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

  • Microsoft Knowledge Base article 821877, "Description of Fields on the SMTP and X.400 Queue Properties Tabs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877).

  • Microsoft Knowledge Base article 264054, "XCON: Understanding Queue States in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054).


There are more than 900 connectors in a Routing Group
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of connectors that are present in a given routing group, including SMTP connectors, routing group connectors, X.400 connectors, and EDK connectors. If the Exchange Server Analyzer finds more than 900 total connectors in any single routing group, a warning is displayed.

It is recommended that you use a maximum of 900 instances for any single Exchange object type. This is because Active Directory defaults to 1,000 as the maximum page size that it returns for any given request. This means that if a Lightweight Directory Access Protocol (LDAP) request is made for an object, and more than 1,000 instances of that object exist in Active Directory, no results will be returned because the maximum page size is exceeded.

In the case of Exchange Server, various processes request instantiation of specific object types. For example, Exchange System Manager makes an LDAP request to Active Directory to create a list view of all connectors within a routing group. If there are more than 1,000 connectors in any single routing group, Active Directory will not return any query results. When this happens, an error is displayed in Exchange System Manager.

Although the maximum page size value for Active Directory can be increased, this is not recommended or supported for Exchange Server. Odd behavior and failures have been exposed in Exchange environments where the maximum page size value has been increased.

Although the recommendation is to remain at or below 900 for any single object type in Exchange Server, up to 1,000 object types are supported.

To correct this warning

  1. Consider consolidating connectors or creating more routing groups and load balancing the existing connectors among them.

  2. Examine Active Directory for orphaned connectors and remove them from Active Directory.

  3. Consider consolidating Exchange servers in your organization.

For information about routing group design and connectors, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

For more information about consolidating Exchange servers, see Server Consolidation Using Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=47586).


There is a discrepancy with the fully-qualified domain name setting between the Active Directory and metabase
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following property in the Internet Information Services (IIS) metabase to determine if its value matches the configured value for the msExchSmtpFullyQualifiedDomainName attribute in the Active Directory® directory service:

/LM/SmtpSvc/<SMTP virtual server instance>/FullyQualifiedDomainName

If the Exchange Server Analyzer finds that the values for the two attributes do not match, a warning message is displayed.

If the value in the IIS metabase does not match the value in Active Directory, it could indicate a problem with Active Directory replication or a problem with the Directory-service-to-Metabase-replication component (DS2MB) in Exchange.

The function of the DS2MB process is to transfer configuration information from Active Directory to the local metabase. This configuration is stored in the local metabase instead of the registry for performance and scalability reasons. In Exchange 2000 Server and Exchange Server 2003, all of the Internet protocols (SMTP, NNTP, POP3, IMAP4, and HTTP) run as components of IIS.

Every 15 minutes, the DS2MB process copies entire subtrees from Active Directory without changing the shape of the subtree. This is a one-way write from Active Directory to the metabase; the metabase never writes to Active Directory.

The FullyQualifiedDomainName property and the msExchSmtpFullyQualifiedDomainName attribute use a default server name that corresponds to the fully-qualified domain name of the Exchange server (for example, server.domain.com). If the FullyQualifiedDomainName property and the msExchSmtpFullyQualifiedDomainName attribute do not have the same fully qualified domain name value, it means that Active Directory and the IIS metabase are not in sync. If the problem is caused by a failure of the DS2MB process, you can correct the problem by following the procedure below for the version of Exchange Server you are running. If the problem is caused by a partial or complete failure of Active Directory replication, you can use the Active Directory Replication Monitor utility (ReplMon.exe) to check the health and status of Active Directory replication. You can find ReplMon.exe in the Microsoft Windows® Support Tools on the Windows Server™ 2003 CD-ROM.

To correct this warning on Exchange Server 2003

  1. Check for the presence of application event log entries with a source of MSExchangeMU. If DS2MB fails, it will log an event on Exchange Server 2003.

  2. If you do not see any DS2MB failures, use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  3. If you do see DS2MB failures, or after you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

To correct this warning on Exchange 2000 Server

  1. Use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  2. After you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

For more information about the reverse DNS lookup feature in Exchange, see Microsoft Knowledge Base article 297412, "The 'Perform Reverse DNS Lookup for Incoming Messages' Option Is for Host Name Resolution" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412).

For more information about SMTP virtual server settings, see Knowledge Base articles 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686) and 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163).

For more information about Active Directory replication, see Knowledge Base article 232072, "Initiating Replication Between Active Directory Direct Replication Partners" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072).

For more information about the DS2MB process, see Knowledge Base article 240105, "XGEN: General Information on Directory Service/Metabase Synchronization in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105).


There is a discrepancy with the maximum hop count setting between the Active Directory and metabase
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following property in the Internet Information Services (IIS) metabase to determine if its value matches the configured value for the msExchSmtpMaxHopCount attribute in the Active Directory® directory service:

/LM/SmtpSvc/<SMTP virtual server instance>/HopCount

If the Exchange Server Analyzer finds that the values do not match, a warning is displayed.

If the value in the IIS metabase does not match the value in Active Directory, it could indicate a problem with Active Directory replication or a problem with the Directory-service-to-Metabase-replication component (DS2MB) in Exchange.

The function of the DS2MB process is to transfer configuration information from Active Directory to the local metabase. This configuration is stored in the local metabase instead of the registry for performance and scalability reasons. In Exchange 2000 Server and Exchange Server 2003, all of the Internet protocols (SMTP, NNTP, POP3, IMAP4, and HTTP) run as components of IIS.

Every 15 minutes, the DS2MB process copies entire subtrees from Active Directory without changing the shape of the subtree. This is a one-way write from Active Directory to the metabase; the metabase never writes to Active Directory.

On an Exchange 2000 Server SMTP virtual server, the default hop count is 15. On an Exchange Server 2003 SMTP virtual server, the default hop count is 30. Regardless of the configured value, if the HopCount property and the msExchSmtpMaxHopCount attribute do not match, it means that Active Directory and the IIS metabase are not in sync. If the problem is caused by a failure of the DS2MB process, you can correct the problem by following the procedure below for the version of Exchange Server you are running. If the problem is caused by a partial or complete failure of Active Directory replication, you can use the Active Directory Replication Monitor utility (ReplMon.exe) to check the health and status of Active Directory replication. You can find ReplMon.exe in the Microsoft Windows® Support Tools on the Windows Server™ 2003 CD-ROM.

To correct this error on Exchange Server 2003

  1. Check for the presence of application event log entries with a source of MSExchangeMU. If DS2MB fails, it will log an event on Exchange Server 2003.

  2. If you do not see any DS2MB failures, use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  3. If you do see DS2MB failures, or after you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

To correct this error on Exchange 2000 Server

  1. Use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  2. After you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

For more information about the reverse DNS lookup feature in Exchange, see Microsoft Knowledge Base article 297412, "The 'Perform Reverse DNS Lookup for Incoming Messages' Option Is for Host Name Resolution" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412).

For more information about SMTP virtual server settings, see the following Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

For more information about Active Directory replication, see Knowledge Base article 232072, "Initiating Replication Between Active Directory Direct Replication Partners" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072).

For more information about the DS2MB process, see Knowledge Base article 240105, "XGEN: General Information on Directory Service/Metabase Synchronization in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105).


There is a discrepancy with the maximum message size setting between Active Directory and metabase
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the following property in the Internet Information Services (IIS) metabase to determine if its value matches the configured value for the msExchSmtpMaxMessageSize attribute in the Active Directory® directory service:

/LM/SmtpSvc/<SMTP virtual server instance>/MaxMessageSize

If the Exchange Server Analyzer finds that the values do not match, a warning is displayed.

If the value in the IIS metabase does not match the value in Active Directory, it could indicate a problem with Active Directory replication or a problem with the Directory-service-to-Metabase-replication component (DS2MB) in Exchange.

The function of the DS2MB process is to transfer configuration information from Active Directory to the local metabase. This configuration is stored in the local metabase instead of the registry for performance and scalability reasons. In Exchange 2000 Server and Exchange Server 2003, all of the Internet protocols (SMTP, NNTP, POP3, IMAP4, and HTTP) run as components of IIS.

Every 15 minutes, the DS2MB process copies entire subtrees from Active Directory without changing the shape of the subtree. This is a one-way write from Active Directory to the metabase; the metabase never writes to Active Directory.

Both the MaxMessageSize property and the msExchSmtpMaxMessageSize attribute use a default setting of 0, which means there are no imposed message size limits. If the MaxMessageSize property and the msExchSmtpMaxMessageSize attribute do not have the same value, it means that Active Directory and the IIS metabase are not in sync. If the problem is caused by a failure of the DS2MB process, you can correct the problem by following the procedure below for the version of Exchange Server you are running. If the problem is caused by a partial or complete failure of Active Directory replication, you can use the Active Directory Replication Monitor utility (ReplMon.exe) to check the health and status of Active Directory replication. You can find ReplMon.exe in the Microsoft Windows® Support Tools on the Windows Server™ 2003 CD-ROM.

To correct this error on Exchange Server 2003

  1. Check for the presence of application event log entries with a source of MSExchangeMU. If DS2MB fails, it will log an event on Exchange Server 2003.

  2. If you do not see any DS2MB failures, use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  3. If you do see DS2MB failures, or after you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

To correct this error on Exchange 2000 Server

  1. Use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  2. After you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

For more information about the reverse DNS lookup feature in Exchange, see the Microsoft Knowledge Base article 297412, "The 'Perform Reverse DNS Lookup for Incoming Messages' Option Is for Host Name Resolution" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412).

For more information about SMTP virtual server settings, see the following Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

For more information about Active Directory replication, see the Knowledge Base article 232072, "Initiating Replication Between Active Directory Direct Replication Partners" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072).

For more information about the DS2MB process, see the Knowledge Base article 240105, "XGEN: General Information on Directory Service/Metabase Synchronization in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105).


There is a discrepancy with the maximum session size setting between the Active Directory and metabase
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool reads the /LM/SmtpSvc/<SMTP virtual server instance>/MaxSessionSize property in the Internet Information Services (IIS) metabase to determine if its value matches the configured value for the msExchSmtpMaxSessionSize attribute in the Active Directory® directory service.

If the Exchange Server Analyzer finds that the values do not match, a warning message is displayed.

If the value in the IIS metabase does not match the value in Active Directory, it could indicate a problem with Active Directory replication or a problem with the Directory-service-to-Metabase (DS2MB) replication component in Exchange.

The function of the DS2MB process is to transfer configuration information from Active Directory to the local metabase. This configuration is stored in the local metabase instead of the registry for performance and scalability reasons. In Exchange 2000 Server and Exchange Server 2003, all of the Internet protocols (SMTP, NNTP, POP3, IMAP4, and HTTP) run as components of IIS.

Every 15 minutes, the DS2MB process copies entire subtrees from Active Directory without changing the shape of the subtree. This is a one-way write from Active Directory to the metabase; the metabase never writes to Active Directory.

Both the MaxSessionSize property and the msExchSmtpMaxSessionSize attribute use a default setting of 0, which means that there are no imposed session size limits. If the MaxSessionSize property and the msExchSmtpMaxSessionSize attribute do not have the same value, it means that Active Directory and the IIS metabase are not in sync. If the problem is caused by a failure of the DS2MB process, you can correct the problem by following the procedure below for the version of Exchange Server you are running. If the problem is caused by a partial or complete failure of Active Directory replication, you can use the Active Directory Replication Monitor utility (ReplMon.exe) to check the health and status of Active Directory replication. ReplMon can be found in the Microsoft Windows® Support Tools on the Windows Server™ 2003 CD-ROM.

To correct this error on Exchange Server 2003

  1. Check for the presence of application event log entries with a source of MSExchangeMU. If DS2MB fails, it will log an event on Exchange Server 2003.

  2. If you do not see any DS2MB failures, use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  3. If you do see DS2MB failures, or after you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

To correct this error on Exchange 2000 Server

  1. Use ReplMon to diagnose Active Directory replication. Pay particular attention to the global catalog servers that are being used by your SMTP virtual server.

  2. After you have eliminated or resolved any problems with Active Directory replication, restart the Exchange System Attendant service.

For more information about the reverse DNS lookup feature in Exchange, see the Microsoft Knowledge Base article 297412, "The 'Perform Reverse DNS Lookup for Incoming Messages' Option Is for Host Name Resolution" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412).

For more information about SMTP virtual server settings, see the following Knowledge Base articles:

  • 266686, "XCON: How to Configure a SMTP Virtual Server Part 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON: How to Configure a SMTP Virtual Server Part 2" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

For more information about Active Directory replication, see the Knowledge Base article 232072, "Initiating Replication Between Active Directory Direct Replication Partners" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072).

For more information about the DS2MB process, see the Knowledge Base article 240105, "XGEN: General Information on Directory Service/Metabase Synchronization in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105).


Transport connection manager warning event was logged within the last 24 hours
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) class to determine whether an Event 4006 warning has been logged for MSExchangeTransport within the last 24 hours.

If the Exchange Server Analyzer finds that an Event 4006 warning has been logged for MSExchangeTransport within the last 24 hours, the Exchange Server Analyzer displays a warning.

This warning usually indicates that an attempt to send mail to a remote server has failed.

An MSExchangeTransport Event 4006 warning can occur because of the following conditions:

  • The connection was dropped by the remote host.

  • The remote Simple Mail Transfer Protocol (SMTP) service rejected AUTH negotiation.

  • The server that is trying to deliver the message cannot access the message delivery information in the message.

  • An SMTP error occurred.

  • The server that is trying to deliver the message cannot connect to the remote server.

  • A smart host that has been specified in the properties of the SMTP virtual server is unreachable for any reason.

For more information about an MSExchangeTransport Event 4006 warning, you can locate event details from the Events and Errors Message Center (http://go.microsoft.com/fwlink/?LinkId=34258).

For more information about mail relay issues in Exchange Server, see Microsoft Knowledge Base article 895853, "How to troubleshoot mail relay issues in Exchange Server 2003 and in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853).

For more information about mail flow and SMTP issues, see "Troubleshooting Mail Flow and SMTP" in the Exchange Server and Transport Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).


A transport connection manager warning event was logged within the last 24 hours
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool queries the Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) class to determine whether an Event 4001 warning has been logged for MSExchangeTransport within the last 24 hours.

If the Exchange Server Analyzer finds that an Event 4001 warning has been logged for MSExchangeTransport within the last 24 hours, the Exchange Server Analyzer displays a warning.

This warning usually indicates that an attempt to send mail to a remote server has failed.

An MSExchangeTransport Event 4001 warning can occur when the Simple Mail Transfer Protocol (SMTP) service on Exchange 2000 Server or Exchange Server 2003 has one or more mail-delivery problems. Possible causes of mail-delivery problems include issues with the Domain Name System (DNS), IP configuration, or installation of wrong DLL files.

For more information about an Event 4001 warning, you can locate event details from the Events and Errors Message Center (http://go.microsoft.com/fwlink/?LinkId=34258).

For more information about mail relay issues in Exchange Server, see Microsoft Knowledge Base article 895853, "How to troubleshoot mail relay issues in Exchange Server 2003 and in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853).

For more information about mail flow and SMTP issues, see "Troubleshooting Mail Flow and SMTP" in the Exchange Server and Transport Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).


Transport Event Sink File Not Found
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-01-10

The Microsoft® Exchange Server Analyzer Tool queries the Microsoft Internet Information Server (IIS) metabase to enumerate the list of Simple Mail Transport Protocol (SMTP) transport event sink bindings. The Exchange Server Analyzer tries to locate several standard event bindings, based on a list pre-populated in the Exchange Server Analyzer. For each binding, the Exchange Server Analyzer verifies the Component Object Model (COM) registration details in the Registry under the following branch:

HKEY_CLASSES_ROOT\CLSID\

The COM registration details contain the full path of the associated .dll file. The Exchange Server Analyzer uses Microsoft Windows® Management Instrumentation (WMI) to locate the .dll file and display its version number. If the Exchange Server Analyzer does not locate the .dll file, the Exchange Server Analyzer displays a warning detailing the file name and path of the missing .dll file

If the Exchange Server Analyzer finds that one or more standard event bindings are missing, the Exchange Server Analyzer generates a warning.

An SMTP transport event occurs when message data is transported into or out of the SMTP service. All messages go through events. These include X.400 and RPC incoming or outgoing messages. One common example of an inbound transport event is the arrival of a message to the SMTP service either over the network or in the SMTP pickup directory. When this transport event occurs, a source for this event notifies the transport event sinks, each of which can take some type of action based on the data content of the message. The system performs no other action with the message data after it passes the message data to the sink until the sink completes its action and returns the message. The sink has exclusive control of the message data and state while it performs this action.

Missing .dll files for transport event sink COM registrations can cause mail flow problems. If the Exchange Server shows symptoms of mail flow problems such as message queuing, verify the presence of the identified .dll files and re-install them if that is required.

To resolve this issue

  1. Use Explorer to manually locate the identified .dll file. Typically, this file will be located in the \Program Files\Exchsrvr\Bin folder.

  2. It is safe to ignore the warning generated by the Exchange Server Analyzer if the following conditions are true:

    • The .dll file is present in the listed folder.

    • The server does not show signs of a mail flow problem.

  3. Copy the missing .dll file from the original Exchange Server installation media if the following conditions are true:

    • The .dll file is not present in the folder listed by the Exchange Server Analyzer.

    • The server shows signs of a mail flow problem.

    Alternatively, reapply the latest Exchange service pack.

  4. Rerun the Exchange Server Analyzer to verify that the warning no longer is displayed.


User version changes of the link state information are suppressed
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether the heuristics attribute has been configured to suppress user version changes of the link state information. By default, the heuristics attribute is not configured. If the Exchange Server Analyzer finds that the heuristics attribute is set to 2048, the Exchange Server Analyzer displays a non-default configuration message.

Link state tables are used to guarantee efficient and reliable message routing. The link state table contains version information for each routing group in the form of major, minor, and user version numbers. Major version changes have highest priority, followed by minor changes, and finally changes to user version numbers.

User version changes occur when there is a base-level directory service update. These minimal changes include routing group master changes, when services are started or stopped on an Exchange server, when another server is added to the routing group, or when a member server loses connectivity to the routing group master.

A base-level directory service update may occur when an Exchange Server administrator changes something at the routing group level. For example, a user version change occurs when an administrator changes a routing group name, adds a server, or removes a server. However, the primary cause of user version changes is the Microsoft Windows® Management Instrumentation (WMI) data that is in each server. This data states which services are running. If you stop and start a service, user version changes in the link state table are replicated to all Exchange Server computers in the organization.

Frequent user version updates could create an unwanted amount of network traffic and can be suppressed by first obtaining a hotfix from Microsoft Product Support Services and then setting the heuristics attribute to 2048 (0x800 in hexadecimal).

If user version updates are not generating excessive network traffic, it is recommended that you do not suppress them.

To revert to the default configuration

  1. Open Active Directory Service Interfaces (ADSI) Edit.

  2. In ADSI Edit, expand Configuration Container, expand CN=Configuration, DC=DomainName, DC=com, expand CN=Services, and then expand CN=Microsoft Exchange.

  3. Right-click CN=OrganizationName, and then click Properties.

  4. In the Select a property to view box, click Heuristics.

  5. In Edit Attribute box, clear the value 0x800.

  6. Click Set, and then click OK.

  7. Close ADSI Edit.
Caution:
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP (ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft Windows Server™ 2003, Exchange Server 2003, or both. Modify Active Directory object attributes at your own risk.

For more information about link state and user version numbers, see "Link State Propagation" in the Technical Reference Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=49367).


User identified as a common destination
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-09-06

The Microsoft® Exchange Server Analyzer Tool queries the Exchange_Queue Windows® Management Instrumentation (WMI) class to determine the values of the following attributes for the Simple Mail Transfer Protocol (SMTP) queues of the SMTP virtual server.

LinkId | Indicates the identifier for the link that contains the queue.
QueueId | Indicates the identifier of the queue.
QueueName | Indicates the name of the queue.
VirtualMachine | Indicates the name of the virtual machine that contains the queue.
VirtualServerName | Indicates the name of the virtual server the queue is on.
MessageCount | Indicates the number of messages in the queue.

The Exchange Server Analyzer uses the information obtained above to query the Exchange_QueuedSMTPMessage WMI class for the values of the following attributes of the messages in the queue:

Recipients | Indicates the recipients of the message.
Received | Indicates the received time stamp for the message.
MessageId | Indicates the identifier of the queued message.
StateRetry | Indicates that transmission is being retried for a message that was not delivered successfully.

Finally, using the data obtained in the previous query, the Exchange Server Analyzer queries the Active Directory® directory service for the following values of each Recipient object to determine if the recipient is a user, a distribution group, a public folder, or a public folder store:

distinguishedName | Indicates the distinguished name of the object.
msExchHomeServerName | Indicates the server the recipient is homed on.
homeMDB | Indicates the mailbox store of the recipient.

If the Exchange Server Analyzer determines that at least 25 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to a particular user, the Exchange Server Analyzer displays a warning.

If the Exchange Server Analyzer determines that at least 50 percent of the messages stuck in the queue are addressed, in either the To: or Cc: fields, to a particular user, the Exchange Server Analyzer displays an error.

This warning or error means that the user identified is a common destination for messages that are stuck in an SMTP queue.

To address this issue, the user should be investigated for configuration issues or other anomalies that could cause messages to queue for them.

Areas for investigation include:

  • Ensure the user object's attributes are properly set and contain the correct values in Active Directory.

  • Review the user object's Active Directory permissions for the correct settings.

  • Look for possible Unsolicited Commercial E-mail (UCE or SPAM) or virus attacks against the user.

  • Determine if the user belongs to a distribution group that has improperly set delivery restrictions.

  • If user object is a special use, i.e., a designated Journaling recipient, review the configurations of the service or components that the user object is related to for correct configuration.

For more information about how to troubleshoot SMTP queues, see the following Exchange resources:

  • "Troubleshooting Mail Flow and SMTP" in the Exchange Server Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkID=67875).

  • Microsoft Knowledge Base article 823489, "How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489).

For more information about the effect of distribution group restriction on Exchange Server mail flow, see the following Microsoft Knowledge Base articles:

  • 895407, "In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407).

  • 329171 "XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171).

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

  • 812298, "Mail delivery is slow after you configure delivery restrictions that are based on a distribution list" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298).


Unknown SMTP Issue
Microsoft Exchange Server Analyzer - Articles > Transport >

Topic Last Modified: 2006-10-06

The Microsoft® Exchange Server Analyzer Tool queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) class to determine the value of the Started key for the Simple Mail Transfer Protocol (SMTP) service. A value of False indicates that the SMTP service is not running. A value of True indicates that the SMTP service is running.

The Exchange Server Analyzer also queries the Internet Information Services (IIS) metabase to determine the value for the ServerState property for the SMTP virtual server instance.

The ServerState property presents the current state of the server instance. The state codes, and the corresponding states, are as follows:

State Code | State
1 | Starting
2 | Started
3 | Stopping
4 | Stopped
5 | Pausing
6 | Paused
7 | Continuing

The Exchange Server Analyzer displays a warning if the following conditions are true:

  • The SMTP service is running.

  • All SMTP virtual server instances on the server are started.

This warning indicates that, although the SMTP service and SMTP virtual server instances appear to be functional, an issue that requires additional investigation prevents the SMTP ports from responding correctly.

This issue might be caused by the following:

  • The SMTP service is in a hung state.

  • A firewall or antivirus application is blocking communication to the SMTP ports.

To address this issue:

  • Restart the SMTP service.

  • Review the configuration of any firewalls or antivirus applications with regard to the SMTP ports.

  • Review the specific error guidance and links provided by the Exchange Server Analyzer.

To start, stop, or pause the SMTP service

  1. Click Start, point to Administrative Tools, and then click Component Services.

  2. In the console tree, click Services (Local).

  3. In the results pane, right-click Simple Mail Transfer Protocol (SMTP), and then click Start, Stop, or Pause.


Exchange Server 2007 Readiness
Microsoft Exchange Server Analyzer - Articles >

Topic Last Modified: 2006-07-18

The articles in this section provide details about what the Microsoft® Exchange Server Analyzer Tool is evaluating with regard to Exchange Server 2007 readiness. Additionally, these articles describe actions that you can take to resolve prerequisite-related errors, warnings, and non-default configurations found by the Exchange Server Analyzer.


Access control list (ACL) inheritance is blocked
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-06-19

Microsoft Exchange Server 2007 setup cannot continue because the required permissions have not been able to propagate.

Exchange setup requires that inheritance for permissions be enabled on the Public Folder tree objects.

To resolve this issue, make sure that the "Allow permissions to propagate to follow to this object and child objects" setting is enabled, and then rerun Exchange Server 2007 setup.

To re-enable the Public Folder tree inheritance

  1. Open Exchange Server 2003 System Manager.

  2. Right-click the Public Folder store, and then click Properties.

  3. Click the Security tab, and then click to select the Allow inheritable permissions to propagate to this object check box.


Active Directory Schema Extension Requires That Ldifde.exe be Installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-06-19

Microsoft Exchange Server 2007 setup cannot continue because the local computer cannot update the Active Directory schema.

Microsoft Exchange setup requires that Ldifde.exe be installed on the local computer to make necessary extensions to the Active Directory schema.

To resolve this issue, install Ldifde.exe on the local computer and rerun Exchange Server 2007 setup or start Exchange Server 2007 setup from a domain controller.

Note:
When the Active Directory schema has been extended, Exchange 2007 server roles can be installed on the local computer without ldifde.exe being installed.
To install Ldifde.exe on the local computer

  1. Click Start, Run, and in the Open field run 'ServerManagerCmd -i RSAT-ADDS'


ADAM Install Path Exists
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-26

Microsoft Exchange Server 2007 setup cannot continue because the attempt to install the Active Directory Application Mode (ADAM) failed.

An older installation of ADAM exists in the default location. Exchange setup cannot perform a new ADAM install to an existing ADAM directory structure.

To resolve this issue, remove the existing ADAM folder and then rerun Exchange setup.


ADAM not Installed on the Local Computer
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-22

Microsoft Exchange Server 2007 setup cannot continue because Active Directory Application Mode (ADAM) is not installed on this computer.

ADAM is a Lightweight Directory Access Protocol (LDAP) directory service that is designed specifically for use with directory-enabled applications. ADAM stores and replicates only application-specific information and does not require deployment on a domain controller or depend on the Active Directory directory service. ADAM does not provide network operating system authentication or authorization.

In Exchange 2007, the Exchange Transport server role uses ADAM to store configuration information. When ADAM is synchronized with Active Directory, it can also be used to perform recipient lookup for message security.

Microsoft Exchange setup requires that the ADAM service be installed on the local computer before it can continue.

To resolve this issue, install ADAM Service Pack 1 (SP1) from "Active Directory Application Mode (ADAM)" (http://go.microsoft.com/fwlink/?linkid=71063) and then run setup again.


ADAM is not installed on the Local Computer (Windows Server 2008)
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-08-13

Microsoft Exchange Server 2007 setup cannot continue because Active Directory Application Mode (ADAM) is not installed on this Windows Server 2008 -based computer.

ADAM is a Lightweight Directory Access Protocol (LDAP) directory service that is designed specifically for use with directory-enabled applications. ADAM stores and replicates only application-specific information and does not require deployment on a domain controller or depend on the Active Directory directory service. ADAM does not provide network operating system authentication or authorization.

In Exchange 2007, the Exchange Transport server role uses ADAM to store configuration information. When ADAM is synchronized with Active Directory, it can also be used to perform recipient lookup for message security.

Microsoft Exchange setup requires that the ADAM service be installed on the local computer before it can continue.

To resolve this issue, install ADAM on the local computer that is running the Windows Server 2008 operating system, and then run setup again.

To install ADAM to the Windows Server 2008 operating system

  1. Click Start, select Run, and then enter the following command:

  2. cmd.exe /c start /w pkgmgr.exe /iu:"DirectoryServices-ADAM"

  3. Run Exchange 2007 Setup again.


Analyzer Search Warning
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-08-09

This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue.

The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime.

For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at http://go.microsoft.com/fwlink/?linkid=34707.


32-bit compatibility warning
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-08-13

Microsoft Exchange Server 2007 setup displayed this warning because you are installing the 32-bit version of Microsoft Exchange.

Exchange 2007 is available in two platform versions: one platform version (the 64-bit version) is for live production environments and the other platform version (the 32-bit version) is for non-production environments (such as labs, training facilities, demo, and evaluation environments). Only the 64-bit version can be purchased because you cannot run 32-bit Exchange 2007 servers in production.

There are two exceptions with respect to production and non-production use of the 32-bit platform because Microsoft does allow minimal supported use of the 32-bit version in production environments. Specifically:

  • You can use the 32-bit version of the Exchange Management Tools in production to administer Exchange 2007 servers from Windows Server 2003 or Windows XP. At this time, you cannot use either the 32-bit version or the 64-bit version on Windows Vista, or on Windows Server 2008. Support for Windows Vista and Windows Server 2008 is expected to be delivered in Service Pack 1 for Exchange 2007.

  • You can use the 32-bit version of Setup in production to extend your Active Directory directory service schema. For detailed steps to prepare Active Directory for Exchange 2007, see How to Prepare Active Directory and Domains.

All other uses of the 32-bit version of Exchange 2007 in production environments are unsupported.

To download the 32-bit version of the Exchange Management Tools, see "Microsoft Exchange Server 2007 Management Tools (32-Bit)" (http://go.microsoft.com/fwlink/?LinkId=82335). For more information about Exchange 2007 platform versions, see "Exchange Server 2007: Platforms, Editions, and Versions" (http://go.microsoft.com/fwlink/?LinkId=88051) in the Exchange 2007 product documentation.


2007 Time Zone Update for Microsoft Windows Operating Systems Needs to be Installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-02-20

Microsoft Exchange Server 2007 setup cannot continue because an update is required to correct time zone information settings for this computer.

Exchange 2007 setup requires that the time zone update for Windows operating systems referred to in Microsoft Knowledge Base article 931836 be installed.

To resolve this issue, install the update referred to in Microsoft Knowledge Base article 931836, "February 2007 cumulative time zone update for Microsoft Windows operating systems" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=931836), and then rerun Exchange 2007 setup.


Active Directory does not exist or cannot be contacted
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-04-18

Microsoft Exchange Server 2007 setup cannot continue because it is unable to contact a valid Active Directory directory service site.

Microsoft Exchange setup requires that the server that is used for installation of Microsoft Exchange be able to locate the configuration naming context in Active Directory.

To resolve this issue, verify that the user account running Microsoft Exchange setup is logged on to Active Directory and then rerun setup. If this does not resolve the issue, follow the guidance on using the NETDIAG.Exe and DCDIAG.Exe support tools from the topics below to further diagnose the problem.

For more information about Active Directory troubleshooting and configuration for Microsoft Exchange, see the following:

  • "Troubleshooting Active Directory Operations" in Windows Server 2003: Operations (http://go.microsoft.com/fwlink/?LinkId=68099).

  • "Tools for Troubleshooting Active Directory" in the Active Directory Operations Guide (http://go.microsoft.com/fwlink/?LinkId=68100).

  • "Configuration Naming Context" in "Working with Active Directory Permissions in Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47592).

  • "Working with Active Directory Permissions in Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47592).

  • "Netdiag Overview" (http://go.microsoft.com/fwlink/?LinkID=69481).

  • "Dcdiag Overview" (http://go.microsoft.com/fwlink/?LinkID=68936).


Active Directory domain is mixed mode
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-10

Microsoft® Exchange Server 2007 setup cannot continue because an existing Active Directory domain is not set to Microsoft Windows®°2000 Server native mode or better.

Exchange 2007 setup will create Universal Security Groups that can only exist in Windows 2000 Server native mode, or better, domains.

To resolve this issue, follow these steps to raise the domain functional level to at least the Windows 2000 Server native level, and then rerun Exchange 2007 setup.

To raise the domain functional level

  1. Open Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain for which you want to raise functionality, and then click Raise Domain Functional Level.

  3. In Select an available domain functional level, use one of the following procedures:

    • To raise the domain functional level to Windows 2000 Server native, click Windows 2000 native, and then click Raise.

    • To raise domain functional level to Windows Server® 2003, click Windows Server 2003, and then click Raise.
Caution:

If you have or will have any domain controllers running Windows NT® 4.0 and earlier, do not raise the domain functional level to Windows 2000 Server native. After the domain functional level is set to Windows 2000 Server native, it cannot be changed back to Windows 2000 Server mixed.

If you have or will have any domain controllers running Windows NT 4.0 and earlier or Windows 2000 Server, do not raise the domain functional level to Windows Server 2003. After the domain functional level is set to Windows Server 2003, it cannot be changed back to Windows 2000 Server mixed or Windows 2000 Server native.


Active Directory Preparation Required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-26

Microsoft Exchange Server 2007 setup cannot continue because the attempted domain preparation failed.

Exchange setup requires that the Active Directory directory service be modified for Exchange Server 2007 before domains in the Active Directory can be prepared.

To resolve this issue, prepare Active Directory with the Setup /PrepareAD command and then prepare the domains.

For more information about how to perform the PrepareAD process, see "How to Prepare Active Directory and Domains" (http://go.microsoft.com/fwlink/?LinkId=78453).


ADAM port is already in use
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because its attempt to install the Gateway Server role detected that the ports assigned for Active Directory® Application Mode (ADAM) synchronization are already being used.

ADAM is a Lightweight Directory Access Protocol (LDAP) directory service that is designed specifically for use with directory-enabled applications. ADAM stores and replicates only application-specific information and does not require deployment on a domain controller or depend on the Active Directory service. ADAM does not provide network operating system authentication or authorization.

In Exchange 2007, the gateway server uses ADAM to store configuration information. When ADAM is synchronized with Active Directory directory service, it can also be used to perform recipient lookup for message security.

Microsoft Exchange setup requires that specific ports be available (unused) so that they can be assigned to the ADAM synchronization process when the Gateway Server role is installed.

To resolve this issue, identify and stop the process that is already using the ports required for ADAM or run Exchange 2007 setup with command line switches to override the default ADAM port assignments.

To run setup with an override of the default ADAM port assignments

  1. At a command prompt, type the following:

    Setup.exe /adamport:xxxx /adamsslport:yyyy

    • /adamport:<port number to assign to ADAM>

    • /adamsslport:<port number to assign to ADAM>


Application Public Folder Hierarchy Present
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

The Microsoft® Exchange Server Analyzer Tool searches for the application public folder hierarchy in the Active Directory® directory service domain. When the Exchange Server Analyzer finds non-MAPI public folder trees, the Exchange Server Analyzer displays a warning. The warning indicates that non-MAPI public folder trees are present in the Exchange organization. These custom application trees are not supported in Exchange Server 2007.

Non-MAPI public folder trees are used for custom application development. These trees occur in Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 but are not supported in Exchange 2007. It is recommended that before you deploy Exchange 2007 you either:

  • Move the non-MAPI public folder trees to a SharePoint Portal Server.

  • Maintain the data on the Exchange 2003 server.

For more information about different public folder hierarchies, see "Selecting the Appropriate Client for Exchange Public Folder Access" (http:// go.microsoft.com/fwlink/?LinkId =46439).


Cannot determine the name of the Active Directory site
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because this server does not appear to belong to a valid Active Directory® directory service site.

Microsoft Exchange setup requires that the server that is used for installation of Exchange 2007 belong to a valid Active Directory site.

To resolve this issue, verify that the local server is a member of a valid Active Directory site and rerun Exchange Server 2007 setup.

You can use the /DsGetSite option of the Nltest.exe command line tool to verify and display site membership. For more information, see "Nltest.exe: NLTest Overview" in the "Tools and Settings Collection" of Windows Server 2003 Technical Reference (http://go.microsoft.com/fwlink/?LinkId=27734).

For more information about Active Directory troubleshooting, see "Troubleshooting Active Directory Operations" in Windows Server 2003: Operations (http://go.microsoft.com/fwlink/?linkid=68099).


Cannot find a recipient update service
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-05-16

Microsoft® Exchange Server 2007 setup cannot continue because the Recipient Update Service (RUS) responsible for a domain in the existing Exchange organization cannot be found.

Microsoft Exchange setup requires that each domain in the existing Exchange organization have an instance of the Recipient Update Service.

If an instance of the Recipient Update Service is missing for a domain, new user objects created in the domain will not receive e-mail addresses issued to them.

To resolve this issue, verify that an instance of the Recipient Update Service exists for each domain and create an instance of the Recipient Update Service for the domains that do not have one and then rerun Microsoft Exchange setup.

To create a Recipient Update Service instance for a domain

  1. Open Exchange System Manager.

  2. Expand Recipients.

  3. Right-click the Recipient Update Services node, click New, and then click Recipient Update Service.

  4. In the New Object window, click Browse to locate the name of the domain.

  5. Select the name of the domain and then click OK.

  6. In the New Object window, click Next, and then Finish.

For more information about the Recipient Update Service, see the following Microsoft Knowledge Base articles:

  • "How the Recipient Update Service applies recipient policies" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738).

  • "How the Recipient Update Service Populates Address Lists" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828).

  • "How to check the progress of the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127).

  • "Tasks performed by the Exchange Recipient Update Service" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770).


Cannot remove mailbox database
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-06-20

Microsoft Exchange Server 2007 setup cannot continue because the Uninstall Mailbox server role process cannot remove a user mailbox database (store) from the local server without potential data loss.

Exchange 2007 setup checks whether all mailbox stores are removed from the server before the Mailbox server role is removed. However, user mailboxes might still remain on the server.

To resolve this issue, move or disable all user mailboxes on the server and rerun Exchange 2007 setup.

For more information about identifying mailboxes in the database, see the "Get-Mailbox" cmdlet (http://go.microsoft.com/fwlink/?LinkId=93470) in the Exchange Server 2007 product documentation.

For more information about disabling a mailbox, see "How to Disable a Mailbox" (http://go.microsoft.com/fwlink/?LinkId=93471) in the Exchange Server 2007 product documentation.

For more information about how to remove mailbox databases in Exchange Server 2007, see "How to Remove a Mailbox Database" (http://go.microsoft.com/fwlink/?LinkId=93473) in the Exchange Server 2007 product documentation.

For more information about how to manage user mailbox database stores or replicas, see Managing Mailbox Stores and Public Folder Stores in the "Administration Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47617).


Cannot remove public folder database
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-01-23

Microsoft® Exchange Server 2007 setup cannot continue because the Uninstall Mailbox Server role process cannot remove the public folder database from the local server without potential data loss.

Exchange 2007 setup requires that the public folder database be removed from the server before the Mailbox Server role is removed.

Public folder replicas might remain on the server or the public folder database might be the last in the Exchange organization.

To resolve this issue, move or delete the public folder database on the server and rerun Exchange Server 2007 setup.

For more information about removing public folder databases in Exchange Server 2007, see "How to Remove a Public Folder Database" (http://go.microsoft.com/fwlink/?LinkId=81409) in the Exchange Server 2007 product documentation.

For more information about how to manage public folder database stores or replicas, see Managing Mailbox Stores and Public Folder Stores in the "Administration Guide for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=47617).


Cannot Remove Unified Messaging Server Role
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-26

Microsoft Exchange Server 2007 setup cannot continue because its attempt to uninstall the Unified Messaging server role failed.

Exchange 2007 setup checks to see whether the Unified Messaging server role to be uninstalled is hosting the prompt publishing point for a dial plan and whether that dial plan has other servers linked to it.

If the Unified Messaging server role is hosting the prompt publishing point for a dial plan, the uninstall process will fail.

To resolve this issue, move the prompt publishing point to another server, and then rerun Exchange 2007 setup.

For more information about moving the prompt publishing point for a dial plan, see "How to Change the Prompt Publishing Point" (http://go.microsoft.com/fwlink/?LinkId=82356).


Cannot Write to CMS Data Path
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-26

Microsoft Exchange Server 2007 setup cannot continue because the attempt to install the clustered Mailbox server role to a shared cluster drive failed.

Exchange setup was unable to write to the target install path submitted for the /CMSDataPath parameter. Exchange setup requires that the target path for the clustered mailbox server data be a writable volume.

To resolve this issue, specify a target path for the /CMSDataPath that is on writable storage media.

For more information about installing the clustered mailbox server, see "How to Install the Mailbox Server Role on the Active Node" (http://go.microsoft.com/fwlink/?LinkId=86624) in the Exchange Server 2007 product documentation.


Cannot write to the Exchange organization container
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-05-04

Microsoft Exchange Server 2007 setup cannot continue because the logged on user does not have the account permissions that are required to write to the organization container in the Active Directory directory service.

Microsoft Exchange setup requires that the user who is logged on when Exchange 2007 is installed has Enterprise Administrator or Exchange Organization administrative credentials.

As part of the installation process, Exchange 2007 setup may have to create objects in the Microsoft Exchange organization container.

To resolve this issue, grant the logged-on user Enterprise Administrator or Exchange Organization Administrator permissions, or log on with an account that has those permissions and rerun Exchange 2007 setup.

Important:
Cross forest installation of Exchange 2007 is not supported. Use an account that is a member of the Active Directory forest where you are installing Exchange 2007.

For more information about Active Directory permissions that are needed with Microsoft Exchange, see "Working with Active Directory Permissions in Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47592).


Client Access role not detected in local site
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup displayed this warning because an existing Client Access role could not be detected in the local Active Directory® directory service site.

You have chosen to install the Mailbox Server role before an instance of the Client Access role is installed in the Active Directory site.

The Client Access server role accepts connections to your Exchange 2007 server from a variety of different clients. Software clients such as Microsoft Outlook Express and Eudora use POP3 or IMAP4 connections to communicate with the Exchange server. Hardware clients, such as mobile devices, use ActiveSync, POP3, or IMAP4 to communicate with the Exchange server.

If users access their Inbox by using any client other than Microsoft Office Outlook®, you must install the Client Access server role in your Exchange organization.

Users will be able to logon to their mailboxes with Outlook but will not be able to use Outlook Web Access or mobile devices against the same mailbox until a Client Access role is present in the local Active Directory site.


Cluster Managed Resources Need to be Moved or Taken Offline
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-04-09

Microsoft Exchange Server 2007 setup cannot continue because the attempt to install a new active cluster Mailbox server role failed.

Exchange Server 2007 requires that cluster-managed resources be inactive on the cluster node that setup is being run against.

To resolve this issue, move all cluster-managed resources owned by this node, including non-Exchange Server cluster resources, to another node in the cluster. Alternatively, take them offline, and then rerun setup.

For more information about how to move the Exchange-related clustered managed services, see the "Move-ClusteredMailboxServer" (http://go.microsoft.com/fwlink/?LinkId=86627) cmdlet topic in the Exchange Server 2007 product documentation.

For more information about how to take the Exchange-related clustered managed services offline, see the "Stop-ClusteredMailboxServer" (http://go.microsoft.com/fwlink/?LinkId=86635) cmdlet topic in the Exchange Server 2007 product documentation.

For more information about managing non-Exchange cluster resources, see "Manage Resources" (http://go.microsoft.com/fwlink/?LinkId=86637) in the Windows Server 2003 Product Help.


Cluster Service is Not Started
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-26

Microsoft Exchange Server 2007 setup cannot continue because the Microsoft Windows Server Cluster service is not started.

Exchange 2007 setup requires that the cluster service be started when the cluster service is installed on the local computer.

To resolve this issue, start the cluster service on the local computer and then rerun Exchange setup.

To start the cluster service, see "Start the Cluster service" (http://go.microsoft.com/fwlink/?LinkId=86638) in the Windows Server 2003 Technical Library.


Cluster update required (KB921181)
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-11

Microsoft® Exchange Server 2007 setup cannot continue because an update to the cluster node is required.

Exchange 2007 setup requires that the cluster node update referred to in Microsoft Knowledge Base article 921181 be installed.

To resolve this issue, install the update referred to in Microsoft Knowledge Base article 921181, "An update is available that adds a file share witness feature and a configurable cluster heartbeats feature to Windows Server 2003 Service Pack 1-based server clusters" (http://go.microsoft.com/fwlink/?LinkId=69785), and then rerun Exchange 2007 setup.


CMS Data Path Must Be NTFS Volume
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-26

Microsoft Exchange Server 2007 setup cannot continue because the attempt to install the clustered Mailbox server role to a shared cluster drive failed.

The target install path submitted for the /CMSDataPath parameter is a non-NTFS volume. Exchange setup requires that the target path for the clustered Mailbox server data be an NTFS volume.

To resolve this issue, select a different target path for the /CMSDataPath or, convert the target volume to NTFS and then rerun Exchange 2007 setup.

For more information about converting a volume to NTFS, see the "Convert" (http://go.microsoft.com/fwlink/?LinkId=86642) topic in the Windows XP Professional Product Documentation.


Current Cluster Node Owns Clustered Management Services
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-04-09

Microsoft Exchange Server 2007 setup cannot continue because its attempt to uninstall the cluster passive node failed.

The Exchange clustered management services are owned by this cluster node. Exchange 2007 setup requires that the Exchange clustered management services be moved from this node before the Exchange files can be removed.

To resolve this issue, move all cluster-managed resources owned by this node, including non-Exchange Server cluster resources, to another node in the cluster, or take them offline, and then rerun setup.

For more information about how to move the Exchange related clustered managed services, see the "Move-ClusteredMailboxServer" (http://go.microsoft.com/fwlink/?LinkId=86627) cmdlet topic in the Exchange Server 2007 product documentation.

For more information about how to take the Exchange-related clustered managed services offline, see the "Stop-ClusteredMailboxServer" (http://go.microsoft.com/fwlink/?LinkId=86635) cmdlet topic in the Exchange Server 2007 product documentation.

For more information about managing non-Exchange cluster resources, see "Manage Resources" (http://go.microsoft.com/fwlink/?LinkId=86637) in the Windows Server 2003 Product Help.


The COM+ Event System Service Must be Started Before Setup can Continue
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-16

Microsoft Exchange Server 2007 setup cannot continue because its attempt to install the Client Access Server or Edge Transport server roles failed because the COM+ Event System service is not started on the target computer.

Exchange 2007 setup requires the computer that you are installing Microsoft Exchange to have the COM+ Event System service status set to Started.

The COM+ Event System service supports system event notification for COM+ components, which provide automatic distribution of events to subscribing COM components.

Both the Client Access Server and Edge Transport server roles have dependencies on COM+ components that subscribe to the COM+ Event System service.

To resolve this issue, verify that the COM+ Event System service status is set to Started on the local computer, and then rerun Microsoft Exchange setup.

To set the status of the COM+ Event System service to 'Started'

  1. Right-click My Computer, and then click Manage.

  2. Expand the Services and Applications node, and then click the Services node.

  3. In the right pane, locate the Com+ Event System.

  4. Right-click Com+ Event System, and then click Properties.

  5. Set the Startup Type to Automatic and the Service status to Started.

  6. Click Apply, and then click OK.


Complex Exchange Organization Model Detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-10

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of routing groups in the Exchange Server organization. The Exchange Server Analyzer also queries Active Directory to determine the number of Active Directory sites that have Exchange servers that are running Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003.

The Exchange Server Analyzer categorizes the Exchange organization as a complex Exchange organization if the following conditions are true:

  • More than one Active Directory forest exists.

  • Microsoft Identity Integration Server (MIIS) is installed on one or more forests.

Of the four defined organization models for Microsoft Exchange Server 2007, the complex Exchange organization is the only model that includes multiple Active Directory forests or the use of synchronization technology.

To transition a Complex Exchange Organization to Exchange 2007

  1. Visit the Exchange 2007 product documentation online (http://go.microsoft.com/fwlink/?LinkId=69434).

  2. Review the "Planning for a Complex Exchange Organization" topic (http://go.microsoft.com/fwlink/?LinkId=70505).


The 'Default Web Site' cannot be found on the local computer
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because setup is unable to access the default Web site on this server.

Exchange 2007 setup requires that the installation of the Client Access role access the default Web site created by Microsoft Internet Information Services (IIS).

The Client Access server role provides client access functionality, such as Microsoft Office Outlook® (when it connects over HTTP), Outlook Web Access, Exchange ActiveSync®, and clients that use the POP3 or IMAP4 protocols.

IIS acts as the protocol engine for the HTTP, POP3, IMAP4, Simple Mail Transfer Protocol (SMTP), and Network News Transfer Protocol (NNTP) protocols.

Situations may occur in which the IIS default Web site no longer exists. It may have been deleted or renamed to something other than Default Web Site.

To resolve this issue, first remove, and then reinstall IIS on this server. Then rerun Exchange 2007 setup.

Important:
You must uninstall and then reinstall IIS to resolve this issue. It is insufficient to re-create or rename the directory.
To uninstall IIS using Add or Remove a Windows Component in Control Panel

  1. On the Start menu, click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list click the Application Server check box.

  5. Click Details.

  6. Click Internet Information Services Manager.

  7. Click Next.

  8. Click Finish when un-installation of IIS is finished.
To install IIS using Control Panel

  1. On the Start menu, click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list click the Application Server check box.

  5. Click Details.

  6. Click the Internet Information Services Manager check box.

  7. Click OK until you are returned to the Windows Component Wizard.

  8. Click Next and complete the Windows Component Wizard.


The Distributed Transaction Coordinator Service Must be Started Before Setup can Continue
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-16

Microsoft Exchange Server 2007 setup cannot continue because its attempt to install the Client Access Server or Unified Messaging server roles failed because the Distributed Transaction Coordinator service is not started on the target computer.

Exchange 2007 setup requires the computer that you are installing Microsoft Exchange to have the Distributed Transaction Coordinator service status set to Started.

The Distributed Transaction Coordinator service provides services designed to ensure successful and complete transactions, even with system failures, process failures, and communication failures.

Each computer participating in a distributed transaction manages its own resources and data and also acts in concert with other computers in the transaction. Above all, a distributed transaction must commit or abort its work entirely on all participating computers. The Distributed Transaction Coordinator performs the transaction coordination role for the components involved and acts as a transaction manager for each computer that manages transactions.

Both the Client Access Server and Unified Messaging server roles have dependencies on the Distributed Transaction Coordinator service.

To resolve this issue, verify that the Distributed Transaction Coordinator service status is set to Started on the local computer, and then rerun Microsoft Exchange setup.

To set the status of the Distributed Transaction Coordinator service to 'Started'

  1. Right-click My Computer, and then click Manage.

  2. Expand the Services and Applications node, and then click the Services node.

  3. In the right pane, locate the Distributed Transaction Coordinator.

  4. Right-click Distributed Transaction Coordinator, and then click Properties.

  5. Set the Startup Type to Automatic and the Service status to Started.

  6. Click Apply, and then click OK.


The DNS suffix is not set on the local computer
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

Microsoft® Exchange Server 2007 setup cannot continue because the Fully Qualified Domain Name (FQDN) of the local computer is not set.

Exchange 2007 setup requires that the local computer have a valid Domain Name System (DNS) suffix set.

To resolve this issue, set the DNS suffix for the local computer, restart the computer, and rerun Exchange 2007 setup.

To set the primary DNS suffix of the local computer

  1. Right-click My Computer, and then click Properties. The System Properties dialog box will appear.

  2. Click the Computer Name tab.

  3. Click Change. The Computer Name Changes dialog box will appear.

  4. Click More. The DNS Suffix and NetBIOS Computer Name dialog box will appear.

  5. Enter the appropriate DNS suffix for the domain.

  6. Select the Change primary DNS suffix when domain membership changes check box.

  7. Click OK to save the changes, and then click OK to exit the Computer Name Changes dialog box.

  8. Click OK to close the System Properties dialog box, and then restart the computer for the change to take effect.

For more information about DNS Names, see Microsoft Knowledge Base article 909264, "Naming conventions in Active Directory for computers, domains, sites, and OUs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=909264).


Domain Controller Override is set in the Registry
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because its attempt to use the specified domain controller failed. A domain controller has been statically mapped in the registry.

Exchange 2007 setup requires that the domain controller specified in the setup command match the domain controller that has been statically mapped using a registry override.

To resolve this issue, run setup again, specifying the statically mapped domain controller for the /DomainController: <FQDN of the statically mapped domain controller> parameter.

For more information about DSAccess and directory services detection, see Microsoft Knowledge Base article 250570, "Directory Service Server Detection and DSAccess Usage" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570).


Domain Preparation Required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the attempt to install the server role failed.

Microsoft Exchange setup requires that the local domain be prepared for Exchange Server 2007 before certain server roles can be installed.

Preparation of the domain for Exchange Server 2007 consists of the following tasks:

  • Setting permissions on the Domain container for the Exchange Servers, Exchange Organization Administrators, Authenticated Users, and Exchange Mailbox Administrators.

  • Creating the Microsoft Exchange System Objects container if it does not exist, and setting permissions on this container for the Exchange Servers, Exchange Organization Administrators, and Authenticated Users.

  • Creating a new domain global group in the current domain called Exchange Install Domain Servers.

  • Adding the Exchange Install Domain Servers group to the Exchange Servers USG in the root domain.

To resolve this issue, run setup /PrepareDomain to prepare the local domain and retry the server role installation.

For more information about how to perform the PrepareDomain process, see "How to Prepare Active Directory and Domains" (http://go.microsoft.com/fwlink/?LinkId=78453).


The Edge Transport role cannot be installed on the local computer
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-01-03

Microsoft® Exchange Server 2007 setup cannot continue because its attempt to install the Edge Server role found other Microsoft Exchange roles already installed on this server.

Exchange 2007 setup cannot install the Edge Server role on a server that has other Microsoft Exchange roles installed.

The Microsoft Exchange Edge Server role is deployed in your organization's perimeter network and handles all Internet-facing mail flow. It provides the encryption and decryption of messages sent between trusted Microsoft Exchange organizations, and also protection against spam.

To resolve this issue, install the Edge Server role on a computer that does not have other Microsoft Exchange roles installed.


EDK Connector Found in Topology
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-04

The Microsoft® Exchange Server Analyzer Tool checks the Active Directory® directory service for Exchange Development Kit (EDK) connectors in the Exchange organization. If EDK connectors are found in Active Directory, the Exchange Server Analyzer displays a warning. The warning indicates that EDK connectors are not supported in Microsoft Exchange Server 2007.

It is recommended that you contact the third-party vendor for a replacement connector product for Exchange 2007. Alternatively, you can keep an Exchange 2003 or Microsoft Exchange 2000 Server to support the EDK connector.

Note:
EDK connectors are third-party applications built to connect to communication systems such as fax machines, Short Message Service (SMS), telex, or to connect to other messaging systems, such as Lotus Notes, that use a gateway connector. Non-Microsoft vendors use the Exchange Development Kit (EDK) to develop proprietary connectors.


Esm.dll is in use by one or more processes
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-28

Microsoft Exchange Server 2007 setup cannot continue because its attempt to upgrade the server encountered a module access issue.

Exchange 2007 setup requires that certain modules not be running so that the upgrade can modify the binary files. The Esm.dll file is one such module.

To resolve this issue, unload the processes that have Esm.dll open, and then rerun Exchange 2007 setup.

To stop the process that has Esm.dll open

  1. Start the Exchange Management Shell

  2. Use the Get-Process cmdlet to find the process ID for the processes that the Exchange Analyzer has identified.

  3. Get-Process < process name >

  4. Use the Stop-Process cmdlet to stop the process.

  5. Stop-Process < process ID >

  6. Where <process ID> is the process ID value returned from the Get-Process cmdlet in step 2 here.

For more information about the Get-Process cmdlet, see Using the Get-Process Cmdlet in the "What Can I Do With Windows PowerShell?" topic.


'ExchHelp.chm' is open
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-16

Microsoft Exchange Server 2007 setup cannot continue because its attempt to upgrade the server encountered a file access issue.

Exchange 2007 setup requires that certain files be closed so that the upgrade process can modify the files or processes that access them. The local Exchange Help (ExchHelp.chm) file is one such file.

To resolve this issue, close the ExchHelp.chm file, and then rerun Exchange 2007 setup.


Exchange 2000 Server computers require upgrade to SP3
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because one or more servers in the existing organization are running Exchange 2000 Server without Service Pack 3 or a later version.

Exchange 2007 setup requires that all existing Exchange 2000 Server computers in the organization be running Exchange 2000 Server Service Pack 3 (SP3).

To resolve this issue, upgrade all existing Exchange 2000 Server computers in the organization to Exchange 2000 Server SP3 or a later version, and then rerun Exchange 2007 setup.

For more information about upgrading Exchange 2000 Server computers to Exchange 2000 Server SP3 or a later version, see "Downloads for Exchange 2000 Server" (http://go.microsoft.com/fwlink/?LinkId=86647).


Exchange Organization is in Mixed Mode
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

The Microsoft® Exchange Server Analyzer Tool queries the Exchange organization container to determine the mode of the Exchange organization. The Exchange Server Analyzer checks the value of msExchangeMixedMode attribute. If the value of the msExchangeMixedMode attribute is True, the Exchange Server Analyzer displays an error. The error message indicates that the Exchange organization is running in mixed mode. Microsoft Exchange Server 2007 can only be installed in an organization that is in native mode. Therefore, you must switch an organization that runs in mixed mode to native mode to prepare for an Exchange 2007 deployment.

Note:
An organization that runs in native mode can contain only Exchange 2000 servers or later versions.

To prepare for an Exchange 2007 deployment, you must convert the Exchange organization to native mode by following these steps:

  1. Remove or decommission any remaining Exchange 5.5 servers.

  2. In Exchange System Manager, open the properties of the Exchange organization object, and then switch to native mode.

For more information about how to convert an Exchange organization to native mode, see "How to Convert from Mixed Mode to Native Mode in Exchange" (http://go.microsoft.com/fwlink/?LinkId=56642) in the Exchange Server 2003 Deployment Guide.

For more information about mixed mode and native mode for Microsoft Exchange, see the following Microsoft Knowledge Base articles:

  • 270143, "Description of mixed mode and native mode in Exchange 2000 Server and in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=270143).

  • 327779, "How To Convert from Mixed Mode to Native Mode in Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327779).

  • 272314, "XADM: Preparing a Mixed Mode Organization for Conversion to Native Mode" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=272314).


Exchange Server 2003 computers require upgrade to SP2
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because one or more servers in the existing organization are running Exchange Server 2003 without Service Pack 2 (or a later version).

Exchange 2007 setup requires that all existing Exchange Server 2003 computers in the organization be running Exchange Server 2003 Service Pack 2 (SP2) or a later version.

To resolve this issue, upgrade all existing Exchange Server 2003 computers in the organization to Exchange Server 2003 SP2 or a later version, and then rerun Exchange 2007 setup.

For more information about upgrading Exchange Server 2003 computers to Exchange Server 2003 SP2 or a later version, see "Downloads for Exchange Server 2003" (http://go.microsoft.com/fwlink/?LinkId=21030).


Exchange Server 2007 cannot be used with this version of Windows
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the local computer is not running a version of the Microsoft Windows Server operating system that is supported with Exchange Server 2007.

Exchange 2007 setup requires that the version of Windows Server on the local computer be supported for running Exchange Server 2007 as specified by the Exchange Server 2007 System Requirements.

To resolve this issue, install an Exchange Server 2007 supported version of the Windows Server operating system on the local computer or install Exchange Server 2007 on a computer that is running a supported version of Windows Server.

For more information about Exchange Server 2007 system requirements, see "Exchange Server 2007 System Requirements" (http://go.microsoft.com/fwlink/?LinkId=86651).


File Share Witness Not Configured
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-23

Microsoft Exchange Server 2007 setup cannot continue because a file share witness has not been configured for the cluster continuous replication (CCR) cluster.

To sustain the failure of any one node in a Majority Node Set (MNS) quorum cluster, you must have at least three devices that can be considered as available. The file share witness feature enables you to use an external file share as a witness. This witness acts as the third available device in a two-node MNS quorum cluster.

Exchange 2007 setup requires that the file share witness feature be configured for installation of the clustered Mailbox server role in a CCR environment.

To address this issue, follow the procedure to create and secure the file share for the file share witness as shown in "How to Configure the File Share Witness" (http://go.microsoft.com/fwlink/?LinkId=78278). Then set the MNSFileShare value, move the cluster group two times, and try Microsoft Exchange setup again.


First role installation cannot be delegated
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because the logged-on user does not have the account permissions that are required to install the first of any server role in the topology.

Although Microsoft Exchange setup allows the use of delegation to install subsequent server roles, setup requires that the user who is logged on has Exchange Organization administrative credentials when the first of any of the Exchange 2007 server roles in the topology is installed.

As part of the installation of the first of any server role, Exchange 2007 setup may have to create objects in the Exchange Organization container.

To resolve this issue, grant the logged-on user Exchange Organization Administrator permissions or log on using an account that has those permissions and rerun Exchange 2007 setup.


Forefront Security for Exchange Server Services Must be Disabled
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-06-20

Microsoft Exchange Server 2007 setup cannot continue the Exchange Server 2007 upgrade because Microsoft Forefront Security for Exchange Server services are running on the local computer.

Exchange setup requires that the Forefront Security for Exchange Server services be disabled before the Exchange Server 2007 upgrade can continue.

To resolve this issue, disable the Forefront Security for Exchange Server services and then rerun the Exchange Server upgrade.

For more information about installing a service pack or software update to an Exchange Server that is running Forefront Security, see Microsoft Knowledge Base article 929080 How to install a service pack or a software update on an Exchange Server computer that is running Forefront Security.


Forefront Security for Exchange Server Upgrade Required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Applies to: Exchange Server 2007, Exchange Server 2007 SP1
Topic Last Modified: 2007-08-08

Microsoft Exchange Server 2007 setup cannot continue the Exchange 2007 upgrade because the local computer is running a version of the Microsoft Forefront Security for Exchange Server that is not supported with Exchange Server 2007 Service Pack 1 (SP1).

Exchange setup requires that the version of Microsoft Forefront Security for Exchange Server be upgraded and its services be disabled before the Exchange Server 2007 upgrade can continue.

To resolve this issue, upgrade Microsoft Forefront Security version 10.0 for Exchange Server to Microsoft Forefront Security for Exchange Server SP1 and then disable the Microsoft Forefront Security for Exchange Server services before resuming the Exchange Server upgrade.

For More Information

For more information about installing a service pack or software update to an Exchange Server that is running Forefront Security, see Microsoft Knowledge Base article 929080 "How to install a service pack or a software update on an Exchange Server computer that is running Forefront Security" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=929080).


The fully-qualified domain name of the computer matches a recipient policy
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-05-16

Microsoft® Exchange Server 2007 setup cannot continue because the Fully Qualified Domain Name (FQDN) of the local computer matches the Simple Mail Transfer Protocol (SMTP) address of a recipient policy.

Microsoft Exchange setup requires that the FQDN of the servers in an Exchange organization not match any SMTP addresses of recipient policies in the same Exchange organization.

If the FQDN of a computer matches the SMTP address of a recipient policy, this match can cause mail to fail over SMTP and stall in the MTA queues.

To resolve this issue, rename the local computer or remove or rename the recipient policy and rerun Microsoft Exchange setup.

To rename the local computer

  1. Open System in Control Panel.

  2. On the Computer Name tab, click Change.

  3. Under Computer name, type a new name for the computer, and then click OK. You will be prompted to provide a user name and user password to rename the computer in the domain.

  4. Click OK to close the System Properties dialog box. You will be prompted to restart your computer to apply your changes.
Important:
If the computer that you want to rename is a domain controller, see "Rename a domain controller" (http://go.microsoft.com/fwlink/?LinkId=66828).
To modify the recipient policy SMTP address

  1. Start Exchange System Manager.

  2. Click Organization, click Recipients, and then click Recipient Policies.

  3. Double-click the policy that you want to change.

  4. Click the E-Mail Addresses tab, and then change the appropriate SMTP address

For more information about Recipient Policy naming issues, see Microsoft Knowledge Base article 288175, "XCON: Recipient Policy Cannot Match the FQDN of Any Server in the Organization, 5.4.8 NDRs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=288175).


A global catalog server does not exist in the local site
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because there is no Global Catalog server in the site in which you are trying to install Microsoft Exchange.

Microsoft Exchange setup requires that the Active Directory® directory service site of the computer that is running setup contain a server that acts as a global catalog.

To resolve this issue, take one of the following steps:

  • Make an existing domain controller in the site a Global Catalog server.

  • Install a new server in the Global Catalog server role.

To make an existing domain controller a global catalog server

  1. Open Active Directory Sites and Services.

  2. Expand Sites, expand the Site, and then expand Servers.

  3. Select the domain controller that you want to specify as a global catalog server.

  4. In the right pane, right-click NTDS Settings and select Properties.

  5. On the General tab, select the Global Catalog check box. The change occurs dynamically without restarting the server.
  • For more information about how to create global catalog servers, see the Microsoft Knowledge Base article 313994, "How to create or move a Global Catalog in Windows 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=313994).

  • For more information about global catalog server placement and availability as it relates to Exchange Server, see Microsoft Knowledge Base article 875427, "Global catalog server placement and ratios in an Exchange 2000 Server organization or in an Exchange Server 2003 organization" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=875427).


Global updates required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-09-19

Microsoft® Exchange Server 2007 setup cannot continue because the logged on user does not have the account permissions that are required to make Global updates to the Active Directory® directory service.

Microsoft Exchange setup requires that the user who is logged on when Exchange 2007 is installed has Enterprise Administrator administrative credentials.

As part of the installation process, Exchange 2007 setup may have to do the following:

  • Create or modify Exchange organization objects in the Active Directory directory service

  • Prepare all domains in the Active Directory forest for Exchange 2007.

  • Prepare the existing Exchange 2000 Server and Exchange Server 2003 domains for Exchange 2007.

To resolve this issue, grant the logged on user Enterprise Administrator permissions, or log on with an account that has those permissions and rerun Exchange 2007 setup.

For more information about Active Directory permissions needed with Exchange, see "Working with Active Directory Permissions in Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47592).


The Host record for the local computer cannot be found in the DNS database
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

Microsoft® Exchange Server 2007 setup cannot continue because the Host (A) record for this computer cannot be found in the Domain Name System (DNS) database.

Exchange 2007 setup requires that the local computer have a valid HOST (A) record registered with the authoritative DNS database for the domain.

Microsoft Exchange depends on DNS Host (A) records for the IP Address of its next internal or external destination server.

To resolve this issue:

  • Verify that the local TCP/IP configuration points to the correct DNS server.

    To verify the local TCP/IP configuration

    1. Review the local TCP/IP configuration. For more information, see "Configure TCP/IP to use DNS" (http://go.microsoft.com/fwlink/?LinkId=68094).
  • Use Nslookup.exe to verify that the Host (A) record exists on the DNS server. For more information, see "To verify A resource records exist in DNS" (http://go.microsoft.com/fwlink/?LinkId=63001).

For information about DNS name resolution, troubleshooting, and Host (A) records, see the following:

  • Microsoft Knowledge Base article 322856, "How to configure DNS to use with Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856).

  • "Troubleshooting DNS" (http://go.microsoft.com/fwlink/?LinkId=63003).

  • "Managing resource records" (http://go.microsoft.com/fwlink/?LinkId=63004).


Hub Transport role not detected in local site
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup displays this warning because an existing Hub Transport server role could not be detected in the local Active Directory® directory service site.

You have chosen to install the Mailbox Server role before an instance of the Hub Transport role is installed in the Active Directory site.

Exchange 2007 Hub Transport Services are deployed inside your organization's Active Directory. Hub Transport Services handle all mail flow inside the organization, applies organizational mail flow routing rules, and are responsible for delivering messages to a recipient's mailbox.

Users will be able to log on to their mailboxes, but mail cannot be sent or received from this mailbox server until a Hub Transport role is installed.


Hub Transport Server Not Present in Active Directory Site
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-07-25

The Microsoft Exchange Analyzer Tool queries the Active Directory directory service for the value of any object of the msExchAdminGroupContainer class in the Exchange organization that contains the Exchange Server 2007 specific Administrative Group identifier, FYDIBOHF23SPDLT.

If the Exchange Analyzer determines that there is an Exchange Server 2007 administrative group in the Exchange organization, the Exchange Analyzer then queries all Active Directory sites in the organization for the value of the msExchCurrentServerRoles attribute for each msExchExchangeServer object to determine whether there is a Mailbox server role installed in any of the sites found.

Finally, if the Exchange Analyzer determines that there is a Mailbox server role installed in a site, the Exchange Analyzer queries the msExchCurrentServerRoles attribute of each msExchExchangeServer object in that site to determine whether there is also a Hub Transport server role installed in that same site.

If the Exchange Analyzer determines that there is a Mailbox server role installed in an Active Directory site that has no Hub Transport server role installed, the Exchange Analyzer displays an error.

This error indicates that, although there is a Mailbox server role installed in the Active Directory site, mail will not be transferred from mailbox to mailbox, even if the mailboxes are on the same server, until at least one Hub Transport server role is installed in the site.

The Hub Transport server role is deployed inside your organization's Active Directory directory service. It handles all mail flow inside the organization, applies organizational message policies, and is responsible for delivering messages to a recipient's mailbox. Hub Transport servers provide the following functionality:

Mail flow The Hub Transport server role processes all messages that are sent inside the Exchange 2007 organization before they are delivered to a recipient's Inbox inside the organization or routed to users outside the organization. There are no exceptions to this behavior.

Categorization The categorizer performs recipient resolution, routing resolution, and content conversion for all messages that move through the Exchange 2007 transport pipeline.

Routing The Hub Transport server role determines the routing path for all messages that are sent and received in the organization.

Delivery Messages are delivered to a recipient's mailbox by the store driver. Messages that are sent by users in your organization are picked up from the sender's Outbox by the store driver and are put in the Submission queue on a Hub Transport server.

To address this error, install the Hub Transport server role in the sites that have a Mailbox server role installed.

For More Information

For more information about deploying the Hub Transport server role in a site, see "Deploying Server Roles" (http://go.microsoft.com/fwlink/?LinkId=83282) in the Exchange Server 2007 product documentation.


IIS 6 Compatibility Components Not Installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-08-13

Microsoft Exchange Server 2007 setup cannot continue its attempt to install the Client Access server role, Mailbox server role, or the Exchange 2007 Administrative Tools on the Windows Server 2008 -based destination computer because the Internet Information Server (IIS) 6 Metabase Compatibility and IIS 6 Management Console components are not installed.

Exchange 2007 setup requires that the Windows Server 2008 -based computer that you are installing the Exchange 2007 Client Access server role, Mailbox server role, or the Exchange 2007 Administrative Tools has the IIS 6 Metabase Compatibility and IIS 6 Management Console components installed.

To address this issue, install the IIS 6 Metabase Compatibility Component to the destination computer, and then rerun Microsoft Exchange setup.

To install the IIS 6.0 Management Compatibility Components by using the Windows Server 2008 Server Manager

  1. Click Start, click Administrative Tools and then Server Manager.

  2. In the left navigation pane, expand Roles, and then right-click Web Server (IIS) and select Add Role Services.

  3. On the Select Role Services pane, scroll down to IIS 6 Management Compatibility.

  4. Select the check boxes for IIS 6 Metabase Compatibility and IIS 6 Management Console.

  5. Click Next from the Select Role Services pane, and then click Install at the Confirm Installations Selections pane.

  6. Click Close to leave the Add Role Services wizard.


IIS 7 Component Not Installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-08-09

Microsoft Exchange Server 2007 setup cannot continue to install the Client Access server role on the Microsoft Windows Server 2008-based system because the required Internet Information Server (IIS) 7 components are not installed.

Exchange 2007 setup requires that the Windows Server 2008-based computer where you are installing the Client Access server role has the following IIS 7 components installed before installing the Client Access server role.

Required IIS 7 Components

Dynamic Content Compression

Static Content Compression

Basic Authentication

Windows Authentication

To address this issue, install the required IIS 7 component(s) to the destination computer, and then rerun Microsoft Exchange setup.

To install the IIS 7 Components by using the Windows Server 2008 Server Manager

  1. Click Start, click Administrative Tools and then Server Manager.

  2. In the left navigation pane, expand Roles, and then right-click Web Server (IIS) and select Add Role Services.

  3. On the Select Role Services pane, scroll down to IIS.

  4. Select the check boxes under Security for Basic Authentication and Windows Authentication.

  5. Select the check boxes under Performance for Static Compression and Dynamic Compression.

  6. Click Next from the Select Role Services pane, and then click Install at the Confirm Installations Selections pane.

  7. Click Close to leave the Add Role Services wizard.


IIS Common Files are required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-14

Microsoft® Exchange Server 2007 setup cannot continue because Microsoft Internet Information Services (IIS) Common Files are not installed on this server.

Microsoft Exchange Management Shell may require remote IIS Metabase access. The metabase is a repository for most IIS configuration values. Remote access to the metabase requires that the appropriate COM+ DLLs be installed on the local computer.

To resolve this issue, install the IIS Common Files on this server and then rerun Exchange 2007 setup.

To install IIS Common Files by Using Control Panel on Windows Server™ 2003

  1. On the Start menu, click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list click the Application Server check box.

  5. Click Details.

  6. In the Subcomponents of Application Server list click the Internet Information Services (IIS) check box.

  7. Click Details.

  8. Click the Common Files check box.

  9. Click OK until you are returned to the Windows Component Wizard.

  10. Click Next and complete the Windows Component Wizard.
To install IIS Common Files by Using Control Panel on Windows® XP

  1. On the Start menu, click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list click the Internet Information Services (IIS) check box.

  5. Click Details.

  6. Click the Common Files check box.

  7. Click OK until you are returned to the Windows Component Wizard.

  8. Click Next and complete the Windows Component Wizard.


IIS is in 32-bit compatibility mode
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-11

Microsoft® Exchange Server 2007 setup cannot continue because the Microsoft Internet Information Service (IIS) is running in 32-bit mode on this 64-bit computer.

Exchange 2007 requires that IIS be in full 64-bit mode when it runs on a 64-bit computer.

To resolve this issue, switch IIS to 64-bit mode, and then rerun Microsoft Exchange setup.

To switch IIS to 64-bit mode

  1. Open a command prompt.

  2. Type the following:

    cscript c:\inetpub\adminscripts\adsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 False

  3. Press enter


Insufficient Permissions to Prepare Active Directory
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-21

Microsoft Exchange Server 2007 setup cannot continue because the attempted domain preparation failed.

Exchange setup requires that the Active Directory directory service be modified for Exchange Server 2007 before domains in the Active Directory can be prepared.

The account being used to run the setup /PrepareAD command has insufficient permissions to execute this command even though it appears to belong to the Enterprise Admins group. The account may have expired.

To resolve this issue, verify that the logged-on user account is valid and belongs to the Enterprise Admins group, or log on with an account that has those permissions and rerun setup /PrepareAD.

For more information about how to perform the PrepareAD process, see "How to Prepare Active Directory and Domains" (http://go.microsoft.com/fwlink/?LinkId=78453).

For more information about Active Directory permissions that are needed with Microsoft Exchange, see "Working with Active Directory Permissions in Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47592).


Insufficient Permissions to Remove All Server Roles
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the attempt to uninstall all server roles failed.

Exchange 2007 setup requires that the user who is logged on when uninstalling all server roles be a member of the Exchange Organization Administrators groups, or the Enterprise Admins group.

To resolve this issue, grant the logged-on user Exchange Organization Administrator permissions or enroll them in the Enterprise Admins group, or log on with an account that has those permissions and rerun Exchange 2007 setup.

For more information about Active Directory permissions needed with Microsoft Exchange, see "Working with Active Directory Permissions in Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47592).


Insufficient Permissions to Run /PrepareDomain
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the attempt to run the /PrepareDomain process failed. The logged on user has insufficient permissions to perform the /PrepareDomain process.

Exchange 2007 setup requires that the user who is logged on when running the /PrepareDomain process be a member of the Domain Admins group for the domain to be prepared, and a member of the Exchange Organization Administrators group, or the Enterprise Admins group.

To resolve this issue, grant the logged-on user Domain Admins group permissions for the domain being prepared and enroll them in the Exchange Organization Administrators or Enterprise Admins groups, or log on with an account that has those permissions and rerun Exchange 2007 setup.

For more information about Active Directory permissions that are needed with Microsoft Exchange, see "Working with Active Directory Permissions in Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47592).


Invalid Domain Name System Domain Name
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-04-13

Microsoft Exchange Server 2007 setup cannot continue because the Domain Name System (DNS) domain name set on the local computer is invalid.

Exchange 2007 setup requires that the DNS domain name not contain characters other than 'A-Z', 'a-z','0-9', '.' and '-'.

To resolve this issue, determine whether the invalid characters are in the local computer's machine name or the actual DNS Domain Name.

  • If the invalid characters are in the machine name for the local computer, reset the DNS domain name for the domain on the local computer by using only valid characters in the range of 'A-Z', 'a-z','0-9', '.' and '-', restart the computer, and rerun Exchange 2007 setup.

  • If the invalid characters are in the organization's DNS domain name, consider the feasibility of renaming the DNS domain or installing Exchange 2007 into a new domain tree.

Caution:
Changing the DNS domain name can dramatically affect your whole network. Before you make any change to the DNS domain name, coordinate with you network administrator.
To verify the DNS domain name of the local computer

  1. Right-click My Computer, and then click Properties. The System Properties dialog box will appear.

  2. Click the Computer Name tab.

  3. Click Change. The Computer Name Changes dialog box will appear.

  4. Click More. The DNS Suffix and NetBIOS Computer Name dialog box will appear.

  5. Verify that only characters in the range of 'A-Z', 'a-z','0-9', '.' and '-' are used.

  6. Select the Change primary DNS suffix when domain membership changes check box.

  7. Click OK to save any changes, and then click OK to exit the Computer Name Changes dialog box.

  8. Click OK to close the System Properties dialog box, and then restart the computer for any changes to take effect.

For more information about DNS Names, see Microsoft Knowledge Base article 909264, "Naming conventions in Active Directory for computers, domains, sites, and OUs" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=909264).


Invalid Installation Path
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the attempt to install a Mailbox server or Cluster Mailbox server role to a shared cluster drive failed.

Exchange setup requires that Exchange Server roles be installed to a drive that is not a shared cluster resource.

To resolve this issue, install the Mailbox server role or cluster Mailbox server to a path that is not designated as a shared cluster drive.

For more information about clustering configurations, see "High Availability" (http://go.microsoft.com/fwlink/?linkid=68190) in the Exchange Server 2007 product documentation.


Invalid CMS Target Path Format
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the attempt to install the clustered Mailbox server role to a shared cluster drive failed.

The /CMSDataPath: <PathToTheDatabase> parameter submitted was in an invalid Universal Naming Convention (UNC) format. Exchange setup requires that the /CMSDataPath: <PathToTheDatabase> parameter specified use a valid drive letter assignment, for example, /CMSDataPath: s:\<PathToTheDatabase>, and not the UNC format.

To resolve this issue, use a valid drive letter assignment for the /CMSDataPath: <PathToTheDatabase> parameter.

For more information about installing the clustered Mailbox server, see "How to Install the Mailbox Server Role on the Active Node" (http://go.microsoft.com/fwlink/?LinkId=86624) in the Exchange Server 2007 product documentation.


The installed version of MOUNTMGR.SYS is incompatible with Exchange Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because the installed version of Mountmgr.sys is incompatible with Microsoft Exchange.

Exchange 2007 setup requires that the cluster node have the update referred to by Microsoft Knowledge Base article 898790 installed.

The version of Mountmgr.sys currently installed on the cluster node may cause volume mount point failures. This problem occurs because of a problem in the Mountmgr.sys driver. This is an intermittent timing problem that can occur when a volume arrives to be mounted to a mount point.

To resolve this issue, install the update referred to by Microsoft Knowledge Base article 898790 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=898790), and then rerun Exchange 2007 setup.

For more information about this issue, see Microsoft Knowledge Base article 898790, "Volume mount points on disks in a server cluster may intermittently become unavailable after you install Windows Server 2003 Service Pack 1" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=898790).


The installed version of TCPIP.SYS is incompatible with Exchange Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because the installed version of Tcpip.sys is incompatible with Microsoft Exchange.

Exchange 2007 setup requires that the local computer have the update referred to by Microsoft Knowledge Base article 898060 installed.

This machine is currently running the Tcpip.sys driver from Windows Server™ 2003 Service Pack 1. This driver may cause connectivity issues in wide area networks.

To resolve this issue, install the update referred to by Microsoft Knowledge Base article 898060 from "Update for Windows Server x64 Edition (KB898060)" (http://go.microsoft.com/fwlink/?linkid=59272), and then rerun Exchange 2007 setup.

For more information about this warning, see Microsoft Knowledge Base article 898060, "Installing security update MS05-019 or Windows Server 2003 Service Pack 1 may cause network connectivity between clients and servers to fail" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=898060).


Large Exchange Organization Model Detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-10

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of routing groups in the Exchange Server organization. The Exchange Server Analyzer also queries Active Directory to determine the number of Active Directory sites that have Exchange servers that are running Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003.

The Exchange Server Analyzer categorizes the Exchange organization as a large Exchange organization if the following conditions are true:

  • There are more than 5 routing groups in the Exchange organization.

  • Servers that are running Exchange 2000 or Exchange 2003 are installed on more than 5 Active Directory sites.

To transition a Large Exchange Organization to Exchange 2007

  1. Visit the Microsoft Exchange Server 2007 product documentation online (http://go.microsoft.com/fwlink/?LinkId=69434).

  2. Review the "Planning for a Large Exchange Organization" topic (http://go.microsoft.com/fwlink/?LinkId=70504).


The local computer is a domain controller of a child domain
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-12-29

Microsoft® Exchange Server 2007 setup cannot continue because the local computer is a domain controller for a child domain.

Exchange 2007 setup will not install on to a domain controller for a child domain unless the domain controller is a global catalog server.

To resolve this issue, promote the domain controller to a global catalog server or install Exchange 2007 to a non-domain controller, a member server, in the child domain, and then rerun the Microsoft Exchange setup.

To correct this warning by making the Exchange server a global catalog server

  1. On the domain controller, click Start, point to Programs, click Administrative Tools, and then click Active Directory Sites and Services.

  2. In the console tree, double-click Sites, double-click the name of the site, and then double-click Servers.

  3. Double-click the target domain controller.

  4. In the results pane, right-click NTDS Settings, and then click Properties.

  5. On the General tab, click to select the Global catalog check box.

  6. Restart the domain controller.


The local computer is already running Exchange Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-01-15

Microsoft® Exchange Server 2007 setup cannot continue because the local computer has previous Microsoft Exchange components installed.

Exchange 2007 setup requires that the local computer not have existing Microsoft Exchange components installed.

To resolve this issue, remove any Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003 components, and then rerun Microsoft Exchange setup.

To remove Microsoft Exchange components

  1. Click Start, point to Settings, and then click Control Panel.

  2. Double-click Add or Remove Programs.

  3. In the Currently installed programs list, click Microsoft Exchange, and then click Change/Remove.

  4. In Microsoft Exchange Installation Wizard, click Next.

  5. In the Action list on the Component Selection page, click the down arrow next to each component that has been installed, and then click Remove.

    Note:
    Installed components have a check mark in the Action list. When you click Remove, the check mark is replaced by the word Remove.

  6. Click Next two times.

  7. Click Finish.


The local computer is not running Windows Server 2003 Service Pack 1 or later
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

Microsoft Exchange Server 2007 setup cannot continue because the local computer is not running Microsoft Windows Server™ 2003 Service Pack 1 (SP1) or a later version.

Exchange 2007 setup requires that the computer that is used for Microsoft Exchange be running Windows Server 2003 SP1 or a later version.

To resolve this issue:

  • Run Exchange 2007 setup from a computer that is running Windows Server 2003 SP1 or a later version.

  • Upgrade the computer that you want to run Exchange 2007 setup from to Windows Server 2003 SP1 or a later version.

For more information about how to upgrade to Windows Server 2003, see Microsoft Knowledge Base article 810613, "Supported paths for upgrading to Windows Server 2003 or to Windows Small Business Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810613).

To obtain the latest service pack for Windows Server 2003, see the Windows Server TechCenter (http://go.microsoft.com/fwlink/?LinkId=45315).


The local computer is responsible for expanding group membership
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because its attempt to uninstall a Hub Transport role responsible for expanding group membership failed.

Exchange 2007 setup requires that distribution list expansion be removed from the current Bridgehead server before the Hub Transport role can be uninstalled.

The expansion of distribution lists enables identification of individual recipients who belong to the distribution list to be identified, or the identification of additional distribution lists for expansion. An expanded distribution list can return the path for any required delivery status notification (DSN). DSNs notify the Microsoft Exchange administrator or e-mail sender of the status of a particular e-mail message. Additionally, distribution list expansion identifies whether Out of Office messages or automatically generated replies should be sent to the sender of the original message.

To resolve this issue, move distribution group expansion to another server and rerun Microsoft Exchange setup.

To change the expansion server for a distribution group or dynamic distribution group

  1. Open the Exchange Management Console.

  2. In the console tree, expand Recipient Configuration.

  3. In the console tree, click Distribution Group.

  4. Create a filter to view all distribution groups and dynamic distribution groups that use the current Bridgehead server as an expansion server.

    1. In the action pane, click Create Filter.

    2. In the property drop-down list, click Expansion Server.

    3. In the operator drop-down list, click Equals.

    4. At the value box, click the Browse button to select the Bridgehead server that currently acting as the expansion server.
Note:
The following step is optional.
  1. Click Add Expression to specify additional filter criteria. Only messages that meet all filter criteria will be displayed.

  2. Click Apply Filter. The results that meet the filter criteria are displayed.

  1. In the results pane, click the distribution group you want to change the expansion server for, and then click Properties in the action pane.

  2. On Properties, click the Advanced tab.

  3. In the Expansion server drop-down list, select a specific server from the list or select Any server in the organization.

  4. Repeat steps 5 through 7 for all distribution groups or for dynamic distribution groups that are using the Bridgehead server as their expansion server.


The local computer is responsible for generating the offline address book
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because its attempt to uninstall a Mailbox role responsible for generating the offline address book failed.

Exchange 2007 setup requires that, unless the Mailbox role is the last one in the Exchange organization, the offline address book generation be removed from the current Mailbox server before the Mailbox role can be uninstalled.

To resolve this issue, move the offline address book generation to another server and rerun Microsoft Exchange setup.

To move offline address book generation using Exchange System Manager

  1. Open Exchange System Manager.

  2. Under Recipients, click Offline Address Lists.

  3. In the right pane, right-click Default Offline Address List and then click Properties.

    Note:
    Use the same procedure for any other offline address list that produces this message.

  4. On the General tab, under Offline address list server, click Browse, and then click the Exchange server that you want to use.
To move offline address book generation using Exchange Management Console

  1. Open the Exchange Management Console.

  2. Expand Microsoft Exchange, expand Organization Configuration, and then select Mailbox.

  3. In the results pane, click the Offline Address Book tab.

  4. On the Offline Address Book tab, select the offline address book you want to move. In the action pane, click Move.

  5. After the Move Offline Address Book Wizard appears, select the new server to host the offline address book generation by using the Browse button and then click Move.

  6. To close the wizard, click Finish.
To use the Exchange Management Shell to move offline address book generation

  • Run the following command:

    Copy Code
    Move-OfflineAddressBook -Identity <OfflineAddressBookIdParameter> -Server <ServerIdParameter> [-DomainController <String>]


The local computer is running the Edge Transport role
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because its attempt to install an Exchange 2007 role found the Gateway Server role already installed on this server.

Exchange 2007 setup cannot install other server roles on a server that has the Microsoft Exchange Gateway Server role installed.

The Microsoft Exchange Gateway Server role is deployed in your organization's perimeter network, handles all Internet-facing mail flow, and provides the encryption and decryption of messages sent between trusted Microsoft Exchange organizations in addition to protection against spam.

To resolve this issue, install the other Microsoft Exchange 2007 roles to a computer that does not have the Gateway Server role installed.


The local computer is running Windows Server 2003 Web Edition
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because the local computer is running Microsoft Windows Server ™ 2003, Web Edition.

Exchange 2007 setup requires you install Microsoft Exchange to a computer that runs on a supported operating system.

To resolve this issue, install Microsoft Exchange to a non-Web Edition of Windows Server 2003 Service Pack 1 (SP1) or later.


The local domain needs to be updated
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the logged on user does not have the account permissions that are required for domain preparation.

Exchange setup requires that the user who is logged on when Setup /PrepareDomain is run be a member of the Domain Administrators and Exchange Organization Administrators groups, or the Enterprise Admins group.

To resolve this issue, grant the logged on user Domain Admins and Exchange Organization Administrator permissions, enroll them in the Enterprise Admins group, or log on with an account that has those permissions and rerun Exchange 2007 setup.

For more information about Active Directory permissions that are needed with Microsoft Exchange, see "Working with Active Directory Permissions in Exchange Server" (http://go.microsoft.com/fwlink/?LinkId=47592).


The local metabase cannot be accessed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because it was unable to read data from the local metabase.

Exchange 2007 setup requires that the installation of the Mailbox Server or Client Access roles be able to read from the Microsoft Internet Information Services (IIS) metabase.

The IIS metabase includes information that affects Microsoft Exchange, such as protocol settings for HTTP; virtual directories for mailbox and mobile device access; and HTTP security settings.

To resolve this issue, verify that IIS is correctly installed and then rerun Microsoft Exchange setup.

To verify that IIS is correctly installed, see the following resources:

  • Microsoft Knowledge Base article 843093, "How to troubleshoot IIS metabase corruption on a Windows 2000 Server-based computer that is running Exchange 2000 Server or Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=843093).

  • Microsoft Knowledge Base article 240225, "Description of Adsutil and MetaEdit Utilities Used to Modify the Metabase" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=240225).

  • Microsoft Knowledge Base article 317678, "HOW TO: Restart Internet Information Services (IIS) on Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=317678).

If the guidance in these resources does not resolve the issue, you may have to uninstall and then reinstall IIS.

To uninstall IIS using Add or Remove a Windows Component in Control Panel

  1. On the Start menu, click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list click the Application Server check box.

  5. Click Details.

  6. Click Internet Information Services Manager.

  7. Click Next.

  8. Click Finish when IIS is uninstalled.
To install IIS using Control Panel

  1. On the Start menu, click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list click the Application Server check box.

  5. Click Details.

  6. Click the Internet Information Services Manager check box.

  7. Click OK until you are returned to the Windows Component Wizard.

  8. Click Next and complete the Windows Component Wizard.


The logged-on user is not a member of the local Administrators group
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because the logged-on user is not a member of the local computer's administrators group.

Exchange 2007 setup requires that the logged-on user who installs Microsoft Exchange has full access to the local computer.

To resolve this issue, log on to the computer by using an account that has local administrator access and then rerun Microsoft Exchange setup.


The logged on user is not a member of the Schema Admins group
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-09-06

Microsoft® Exchange Server 2007 setup cannot continue because the schema update process does not have Active Directory® directory service Schema administrative and Enterprise administrative credentials.

Exchange 2007 setup requires that the logged on user who installs Microsoft Exchange has Schema administrative and Enterprise administrative credentials for the Active Directory forest.

As part of the installation process, Microsoft Exchange setup extends the Active Directory schema to add Exchange 2007-specific classes and attributes.

If the logged on user does not have Schema Administrator and Enterprise administrative rights, the schema update process will fail.

To resolve this issue, add the logged on user to the Schema Admins and Enterprise Admins groups, then log off and log on again, or log off and log on using an account that already has Schema administrative and Enterprise credentials for the Active Directory forest.


Too Many Active Nodes
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-23

Microsoft Exchange Server 2007 setup cannot continue because the attempt to create a new active cluster Mailbox server role failed.

Exchange Server 2007 requires that at least one node of the cluster be passive to support failure recovery.

To address this issue, first install another passive clustered Mailbox server role in the environment and then rerun setup.

For more information about installing active and passive nodes, see "High Availability" (http://go.microsoft.com/fwlink/?LinkId=68190) in the Exchange Server 2007 product documentation.


Mailbox database drive specification is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-05-15

Microsoft® Exchange Server 2007 Disaster Recovery setup cannot continue because Disaster Recovery setup cannot access the mailbox database drive specification that was used in the previous installation of this server.

Microsoft Exchange Disaster Recovery setup requires that the same mailbox database drive specifications previously used for this server be available during the restore.

To resolve this situation, configure the drives to match the original logical drive configuration and rerun Microsoft Exchange Disaster Recovery setup.

Assign or change a drive letter

  1. Open Computer Management (Local).

  2. In the console tree, click Computer Management (Local), click Storage, and then click Disk Management.

  3. Right-click a partition, logical drive, or volume, and then click Change Drive Letter and Paths.

  4. Use one of the following procedures:

    • To assign a drive letter, click Add, click the drive letter you want to use, and then click OK.

    • To modify a drive letter, click it, click Change, click the drive letter you want to use, and then click OK.

For more information about how to assign drive letters, see "Assign, change, or remove a drive letter" (http://go.microsoft.com/fwlink/?LinkId=66764).


Messages currently exist in one or more queues
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

Microsoft® Exchange Server 2007 setup displays this warning because its attempt to uninstall a transport role could cause data loss from a transport queue.

Exchange 2007 setup checks to make sure that the transport queues are empty before it removes the roles associated with managing those queues.

If you remove the transport roles before delivery of messages still in the transport queues, those messages may be held indefinitely.

To resolve this issue, inspect the referenced queues to make sure that they are empty of messages before you continue with setup.

To view the contents of a queue

  1. Open the Exchange Management Console.

  2. In the console tree, click Toolbox.

  3. In the result pane, click Exchange Queue Viewer.

  4. In the action pane, click Open Tool.

  5. In the Queue Viewer, click the Queues tab. A list of all queues on the server to which you are connected is displayed.

  6. Right-click the queue you want and select Properties to view the properties of the queue.
To view messages in a queue

  1. Follow steps 1 through 4.

  2. In the Queue Viewer, click the Messages tab. A list of all messages on the server to which you are connected is displayed. To adjust the view to a single queue, click the Queues tab, double-click the queue name, and then click the Server\Queue tab that appears.

  3. To view detailed information about a message, select a message, and then click Properties in the action pane.


Microsoft .NET Framework Update Required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-02-26

Microsoft Exchange Server 2007 setup cannot continue because the local computer requires a software update.

Exchange 2007 setup requires that the appropriate Microsoft .NET Framework update referenced here be installed on the local computer.

To resolve this issue, exit Exchange 2007 setup, download and install the appropriate (32-bit or 64-bit) update from the following URLs, and then rerun Exchange 2007 setup.

Note:
Clicking the links here prompts you to download files directly.
  • 64-bit download, http://go.microsoft.com/fwlink/?linkid=74465

  • 32-bit download, http://go.microsoft.com/fwlink/?linkid=74469


Microsoft Core XML Services (MSXML) 6.0 required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-21

Microsoft® Exchange Server 2007 setup cannot continue because Microsoft Core XML Services (MSXML) 6.0 is not installed on this server.

For all Unified Messaging server role installations, Exchange 2007 setup requires that MSXML 6.0 be installed on the computer to support Microsoft speech services.

To resolve this issue, install the MSXML 6.0 software from http://go.microsoft.com/fwlink/?LinkId=70796 and then rerun Exchange 2007 setup.


The MNSFileShare path is invalid
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the MNSFileShare path is invalid.

The MNSFileShare value must be set to a string value that contains the Universal Naming Convention (UNC) path of a file share that is external to the cluster such as \\server\sharename.

To address this issue, provide a value for the MNSFileShare property that is a valid UNC path.

For more information about how to configure the MNSFileShare property, see "How to Configure the File Share Witness" (http://go.microsoft.com/fwlink/?LinkId=78278).


MSDAPS.DLL Update Required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-12-05

Microsoft® Exchange Server 2007 setup cannot continue because the local computer requires a software update.

Exchange 2007 setup requires that the MSDAPS.DLL update referenced below be installed on the local computer.

To resolve this issue, download and install the update linked below, and then rerun Exchange 2007 setup.

  • http://go.microsoft.com/fwlink/?linkid=74467


The Network News Transport Service is currently installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-01-22

Microsoft® Exchange Server 2007 setup cannot continue because the Microsoft Windows® Server™ 2003 Network News Transport Protocol (NNTP) service is installed on this computer.

Microsoft Exchange setup requires that the NNTP service not be installed on servers that are used for Exchange 2007.

To resolve this issue, uninstall the NNTP service and rerun Microsoft Exchange setup.

To uninstall the NNTP service by using Add or Remove a Windows Component in Control Panel

  1. On the Start menu, click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list, select the Application Server check box and then click Details.

  5. Select Internet Information Services Manager and then click Details.

  6. Select NNTP Service and then click to clear the check box.

  7. Click OK two times to return to the Components list and then click Next.

  8. Click Finish when the NNTP service is uninstalled.


No Client Access server role found
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-02-16

The Microsoft Exchange Analyzer Tool queries the Active Directory directory service for the value of any object of the msExchAdminGroupContainer class in the Exchange organization that contains the Exchange Server 2007 specific Administrative Group identifier, FYDIBOHF23SPDLT.

If the Exchange Analyzer determines that there is an Exchange Server 2007 administrative group in the Exchange organization, the Exchange Analyzer then queries all Active Directory sites in the organization for the value of the msExchCurrentServerRoles attribute for each msExchExchangeServer object to determine whether there is a Mailbox server role installed in any of the sites found.

Finally, if the Exchange Analyzer determines that there is a Mailbox server role installed in a site, the Exchange Analyzer queries the msExchCurrentServerRoles attribute of each msExchExchangeServer object in that site to determine whether there is also a Client Access server role installed in that same site.

If the Exchange Analyzer determines that there is a Mailbox server role installed in an Active Directory site that has no Client Access server role installed, the Exchange Analyzer displays a warning.

This warning indicates that, although there is a Mailbox server role installed in the Active Directory site, Microsoft Office Outlook Web Access and Exchange ActiveSync mobile device access clients will be unable to access their mail on that Mailbox server until at least one Client Access server role is installed in the site.

The Client Access server role accepts connections to the Exchange 2007 server from a variety of different clients. Software clients such as Microsoft Outlook Express and Eudora use POP3 or IMAP4 connections to communicate with the Exchange server. Hardware clients, such as mobile devices, use ActiveSync, POP3, or IMAP4 to communicate with the Exchange server.

If users access their Inbox by using any client other than Microsoft Outlook, you must install the Client Access server role in the Exchange organization.

To address this warning, if you have clients other than those using Microsoft Outlook that have to access mailboxes, install the Client Access server role in the sites that have a Mailbox server role installed.

For More Information

For more information about how to install the Client Access server role in a site, see "Deploying Server Roles" (http://go.microsoft.com/fwlink/?LinkId=83282) in the Exchange Server 2007 product documentation.


Non-standard address space found
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-21

The Microsoft® Exchange Server Analyzer Tool displays this warning if it determines that there is a non-standard address space on one or more recipient policies.

A non-standard, or proxy, address space is the address by which an Exchange Server recipient object is recognized in a foreign messaging system.

In earlier versions of Exchange Server, support for non-standard address spaces was the responsibility of the Recipient Update Service.

In Microsoft Exchange Server 2007, the Recipient Update Service is not implemented. It is the responsibility of the Exchange 2007 administrative console to generate proxy addresses.

The administrative consoles must have a proxy-generator DLL loaded for each non-standard address space detected.

Important:
If the administrative console runs on a 64-bit computer, a 64-bit version of the proxy-generator DLL will be required.

To address this warning, contact the vendor that supports the foreign address space to obtain the Exchange 2007-compatible proxy-generator DLL.


Not in schema master site/domain
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-10

Microsoft® Exchange Server 2007 setup cannot continue because the computer that is running setup is not in the same Active Directory® directory service site or domain as the server that is assigned the domain schema master role, also known as flexible single master operations or FSMO.

Exchange 2007 setup requires the domain controller that serves as the domain schema master to be in the same site and domain as the local computer that is running Exchange setup.

The domain schema master controls all updates and modifications to the Active Directory schema.

To resolve this issue, run Exchange Server 2007 setup from the same site and domain as the domain schema master.

You can use the Schema Master tool to identify the role. However, the Schmmgmt.dll DLL must be registered in order to make the Schema tool available as an MMC snap-in.

To view the current schema master

  1. At a command prompt, type regsvr32 schmmgmt.dll

    Note:
    RegSvr32 has been successfully registered when the following dialog box is displayed:

    DllRegisterServer in schmmgmt.dll succeeded.

  2. To open a new management console, click Start, click Run, and then type mmc.

  3. On the Console menu, click Add/Remove Snap-in.

  4. Click Add to open the Add Standalone Snap-in dialog box.

  5. Select Active Directory Schema, and then click Add.

  6. "Active Directory Schema" is displayed in the Add/Remove snap-in. Click Close, and then click OK to return to the console.

  7. Select Active Directory Schema so that the Classes and Attributes sections are displayed on the right side.

  8. Right-click Active Directory Schema and then click Operations Master.

  9. The current schema master is displayed


No Windows Server 2003 SP1 Domain Controller in Domain
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the setup /PrepareLegacyExchangePermissions process could not find a domain controller running Microsoft Windows Server 2003 Service Pack 1 (SP1) or a later version in the domain being prepared.

In each domain where you will run setup /PrepareLegacyExchangePermissions, setup must contact a Windows Server 2003 SP1 domain controller. Setup /PrepareLegacyExchangePermissions will not be completed successfully if it cannot find at least one Windows Server 2003 SP1 domain controller.

Running the setup /PrepareLegacyExchangePermissions command enables the legacy Recipient Update Service to function correctly. Before importing the new Exchange 2007 schema, Exchange 2007 must grant new permissions in each domain in which you have run Exchange Server 2003 or Exchange 2000 Server DomainPrep. The setup /PrepareLegacyExchangePermissions command grants these new permissions.

To resolve this issue, upgrade at least one domain controller in each domain where you will run setup /PrepareLegacyExchangePermissions to Windows Server 2003 SP1 or a later version, and then run Setup again.

For more information about how to prepare legacy Exchange permissions, see "Preparing Legacy Exchange Permissions" (http://go.microsoft.com/fwlink/?linkid=81776) in the Exchange Server 2007 product documentation.


OAB Server Has Been Deleted
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-21

Microsoft Exchange Server 2007 setup cannot continue because its attempt to install the Client Access server role failed. The Exchange Mailbox server designated to host the Offline Address Book (OAB) has been deleted.

Exchange 2007 setup requires that there be a valid Exchange Mailbox server hosting OAB generation for the Client Access server role installation to continue.

To address this issue, designate a valid Exchange Mailbox server as OAB generation host, and then rerun Exchange 2007 setup.

For information about how to designate an Exchange server to be the host for Offline Address Book generation, see "How to Create an Offline Address Book" (http://go.microsoft.com/fwlink/?LinkId=86314) in the Exchange 2007 product documentation.


Older database files present
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because it detected existing Microsoft Exchange database files in the target installation path.

Exchange 2007 setup requires that the target installation path be empty of Microsoft Exchange database files.

To resolve this issue, remove all existing files from target installation paths and then rerun setup.

To delete existing Exchange Server database files from the target installation path

  1. In My Computer or Windows Explorer, locate the target install path.

    Note:
    By default, the database files are located in:

    <systemDrive>:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group.

  2. Right-click the files to be removed, and then select Delete.

  3. At the Confirm File Delete dialog, click Yes.

  4. Repeat steps 2 and 3 for all files in the target install paths.


Older Version of ADAM Installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup displays this warning because its attempt to install the Gateway Server role detected an older version of the Active Directory® Application Mode (ADAM) on the current server.

ADAM is a Lightweight Directory Access Protocol (LDAP) directory service that is designed specifically for use with directory-enabled applications. ADAM stores and replicates only application-specific information and does not require deployment on a domain controller or depend on the Active Directory service. ADAM does not provide network operating system authentication or authorization.

In Exchange 2007, the gateway server uses ADAM to store configuration information. When ADAM is synchronized with Active Directory, it can also be used to perform recipient lookup for message security.

Exchange 2007 setup will automatically upgrade the ADAM install to the Service Pack 1 (SP1) version.

No action is necessary unless you do not want to upgrade ADAM. In that case you should not install the Gateway Server role on the local computer.


One or more Active Directory Connector servers were found
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because one or more Active Directory Connectors (ADC) have been found in the current Microsoft Exchange environment.

ADC replicates objects from Exchange Server version 5.5 to the Active Directory® directory service in a mixed mode Microsoft Exchange environment and is not supported by Exchange 2007.

Exchange 2007 setup requires that all ADC components be removed.

To resolve this issue, remove all ADC components, and rerun Exchange 2007 setup.

To remove Active Directory Connector components

  1. To disable the ADC service on the server that is running the ADC service, right-click My Computer on the desktop, and then click Manage.

  2. Expand the Services and Applications node, and then click the Services node.

  3. In the right pane, right-click Microsoft Active Directory Connector and then click Properties.

  4. Change the Startup Type to Disabled. The next time that the computer starts, the ADC service will not start.

  5. Click Apply, and then click OK.

  6. To uninstall the ADC service, use the Active Directory Installation Wizard on the Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003 CD. Open the \ADC\I386 folder and double-click the Setup.exe program. Follow the prompts to Remove All ADC service components.

    Important:
    You must complete step 6 and Remove All ADC components to resolve this issue. It is insufficient to disable the ADC service.

For more information about ADC, see the following Microsoft Knowledge Base articles:

  • 325300, "Support WebCast: Introduction to the Active Directory Connector" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325300).

  • 325221, "Support WebCast: Microsoft Advanced Active Directory Connector" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325221).

  • 312632, "How To Install and Configure the Active Directory Connector in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=312632).


Only One CCR Server Allowed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the attempt to create a new cluster mailbox server failed.

Exchange Server 2007 requires that only one cluster continuous replication cluster mailbox server exist in the cluster continuous replication (CCR) cluster. A cluster mailbox server already exists in this CCR cluster.

To resolve this issue, do not attempt to install an additional cluster continuous replication cluster mailbox server in this cluster.

For more information about installing the cluster mailbox server in a CCR environment, see "How to Install the Mailbox Server Role on the Active Node" (http://go.microsoft.com/fwlink/?LinkId=86624) in the Exchange Server 2007 product documentation.


Only the Mailbox role can be installed on a cluster server
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-07

Microsoft® Exchange Server 2007 setup cannot continue because its attempt to install a role other than the Mailbox Server role on this clustered server failed.

Microsoft Exchange does not support Exchange 2007 roles other than the Mailbox Server role on servers that have the Cluster service installed.

To address this issue, see "High Availability for Exchange 2007" in the Exchange Server 2007 Operations Guide (http://go.microsoft.com/fwlink/?LinkId=68190).


Organization is in mixed mode
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-05-15

Microsoft® Exchange Server 2007 setup cannot continue because the existing Microsoft Exchange organization is not in native mode.

Exchange 2007 setup requires that the existing Exchange organization be in native mode.

To resolve this issue, follow these steps after the last Exchange Server version 5.5 in the existing organization is upgraded or before the last Exchange 5.5 server is decommissioned. Then rerun the Exchange 2007 setup.

Note:
After switching to native mode you cannot switch back to mixed mode.
To switch to native mode

  1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  2. In the console tree, right-click the organization that you want to switch to native mode, and then click Properties.

  3. In <Organization Name> Properties, under Change operation mode, click Change Mode.

  4. In the warning dialog box, click Yes if you are sure that you want to permanently switch to native mode. Click Apply to accept your new Exchange mode.

You must restart the Microsoft Exchange Information Store service on all the Exchange servers in your organization to take full advantage of Exchange native mode. You do not have to restart all the Microsoft Exchange Information Store services at the same time, but you must restart the service on each server so that the server can take advantage of all Exchange native mode features. Restart the service on your servers after the change to native mode has been replicated to the local Microsoft Windows® domain controller.

To restart the Microsoft Exchange Information Store service

  1. Click Start, click Run, type services.msc, and then click OK.

  2. In the Services (Local) pane, find the Microsoft Exchange Information Store service.

  3. Right-click the service and then click Restart.

For more information about how to convert from mixed to native mode, see Microsoft Knowledge Base article 32779, "How To Convert from Mixed Mode to Native Mode in Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=327779).


The primary DNS server cannot be contacted
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

Microsoft® Exchange Server 2007 setup cannot continue because communication with the primary Domain Name System (DNS) server cannot be established.

Exchange 2007 setup requires that the local computer communicate with the authoritative DNS database for the domain.

Microsoft Exchange depends on DNS to resolve the IP Address of its next internal or external destination server.

Communication with the primary DNS server can fail for the following reasons:

  • The local TCP/IP configuration does not point to the correct DNS server.

  • The DNS server is down or unreachable because of a network failure or other reasons.

To resolve this issue:

  • Verify that the local TCP/IP configuration points to the correct DNS server.

To verify the local TCP/IP configuration

  1. Review the local TCP/IP configuration:

    For more information, see "Configure TCP/IP to use DNS" (http://go.microsoft.com/fwlink/?LinkId=68094).
  • Verify that the DNS server is running and can be contacted.

To verify that the DNS server is running and can be contacted

  1. Verify that the DNS server is running by doing one or more of the following checks:

    • Look at the DNS server status from the DNS Administration program on the DNS server.

    • Restart the DNS server.

      For more information, see "Start, stop, pause, or restart a DNS server" (http://go.microsoft.com/fwlink/?LinkId=62999).

    • Verify the DNS server responsiveness by using the nslookup command.

      For more information, see the instructions in "Verify DNS server responsiveness using the nslookup command" (http://go.microsoft.com/fwlink/?LinkId=63000).


Public folder database drive specification is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-05-15

Microsoft® Exchange Server 2007 Disaster Recovery setup cannot continue because Disaster Recovery setup cannot access the public folder database drive specification that was used in the previous installation of this server.

Microsoft Exchange Disaster Recovery setup requires that the same public folder database drive specifications previously used for this server be available during the restore.

To resolve this situation, configure the drives to match the original logical drive configuration and rerun Microsoft Exchange Disaster Recovery setup.

Assign or change a drive letter

  1. Open Computer Management (Local).

  2. In the console tree, click Computer Management (Local), click Storage, and then click Disk Management.

  3. Right-click a partition, logical drive, or volume, and then click Change Drive Letter and Paths.

  4. Use one of the following procedures:

    • To assign a drive letter, click Add, click the drive letter you want to use, and then click OK.

    • To modify a drive letter, click it, click Change, click the drive letter you want to use, and then click OK.

For more information about how to assign drive letters, see "Assign, change, or remove a drive letter" (http://go.microsoft.com/fwlink/?LinkId=66764).


The Registry on a Clustered Node Could not be Accessed Remotely
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-04-13

Microsoft Exchange Server 2007 setup cannot continue because the registry on a cluster node could not be accessed.

Exchange 2007 setup requires access to the registry of all nodes in the cluster to retrieve various settings.

To address this issue, do the following:

  • Verify that the Remote Registry service is running on all nodes of the cluster.

  • Verify that File and Printer Sharing for Microsoft Networks is enabled for the network adapter that is listed first in the binding order.

  • Verify that the values of the following registry keys are the same on each node of the cluster and are valid for the relevant group policy:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\parameters\RequireSecuritySignature

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\EnableSecuritySignature

For more information about troubleshooting registry connectivity issues, see the Troubleshooting Registry Connectivity Issues section in "Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems" (http://go.microsoft.com/fwlink/?linkid=56285).


Remove Edge Subscription before Uninstalling Server Role
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-21

Microsoft Exchange Server 2007 setup cannot continue because the uninstall Edge or Hub Transport server role process failed because the server role has an Edge Subscription.

You subscribe an Edge Transport server to an Active Directory site to associate the Edge Transport server with the Exchange organization. A subscribed Edge Transport server is stamped with an Active Directory site attribute. Among other things, this association enables you to configure the Edge Subscription as a source server for Send connectors that are created in the Exchange organization. The Hub Transport servers in the Exchange organization use an implicit intra-organizational Send connector to route e-mail messages to the Internet through the subscribed Edge Transport server. The Active Directory site association enables the Hub Transport servers to locate the Edge Transport server for routing purposes.

Exchange 2007 setup requires that all Edge subscriptions for the target Edge Transport server role, or the last Hub Transport server role in a site, be removed before the uninstall of the Edge or Hub Transport server role can proceed.

To address this error, use the Get-EdgeSubscription cmdlet to retrieve information about the Edge Subscriptions and the Remove-EdgeSubscription cmdlet to remove the Edge Subscription from the target server, and then rerun Exchange 2007 setup.

To identify and remove the Edge Subscription

  1. Follow the guidance in the Get-EdgeSubscription (http://go.microsoft.com/fwlink/?LinkId=86320) cmdlet topic to identify Edge Subscriptions for the target server.

  2. Follow the guidance in the Remove-EdgeSubscription (http://go.microsoft.com/fwlink/?LinkId=86321) cmdlet topic to remove the Edge Subscription from the target server.


Schema FSMO is Not Windows Server 2003 Service Pack (SP1) or Above
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

The Microsoft® Exchange Server Analyzer Tool checks the Active Directory® directory service forest to learn what server operating system version is running on the Active Directory domain controller schema master. If the Exchange Server Analyzer finds that the Active Directory operations master domain controller, also known as flexible single master operations or FSMO, is not running Microsoft Windows Server™ 2003 Service Pack 1 (SP1) or a later version, the Exchange Server Analyzer displays an error.

The error indicates that Windows Server 2003 SP1 or a later version is required to install Microsoft Exchange Server 2007. Windows Server 2003 SP1 or a later version is required to support new Exchange 2007 permission structures.

If the Active Directory schema FSMO domain controller is not running Windows Server 2003 SP1 or a later version, the Exchange 2007 installation will fail during setup.

This message is a prerequisite check before you deploy Exchange 2007. It is recommended that you have Windows Server 2003 SP1 or a later version running in the forest-wide Active Directory domain controller schema master if you plan to install Exchange 2007.


The schema master is running Windows 2000 Server
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-01-08

Microsoft® Exchange Server 2007 setup cannot continue because the domain controller assigned the Active Directory® directory service schema master role, also known as flexible single master operations (FSMO), is running Microsoft Windows® 2000 Server.

Exchange 2007 setup requires that the domain controller that serves as the schema FSMO run Microsoft Windows Server™ 2003 Service Pack 1 (SP1) or a later version.

The FSMO controls all updates and modifications to the Active Directory schema.

To resolve this issue, upgrade or move the FSMO domain controller to a Windows Server 2003 SP1 or a later server version and rerun Microsoft Exchange setup.

For more information, see Microsoft Knowledge Base article 325379, "How to upgrade Windows 2000 domain controllers to Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325379).

For more information about transferring the infrastructure master role from one domain controller to another domain controller, see the following Microsoft Knowledge Base articles:

  • For Microsoft Windows Server™ 2003, see 324801, "How To View and Transfer FSMO Roles in Windows Server 2003" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801)

  • For Microsoft Windows 2000 Server, see 255690, "HOW TO: View and Transfer FSMO Roles in the Graphical User Interface" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690)


The schema master is not running Windows Server 2003 Service Pack 1 or later
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the domain controller assigned the Active Directory directory service schema master role, also known as flexible single master operations (FSMO), is not running Microsoft Windows Server 2003 Service Pack 1 (SP1) or a later version.

Exchange 2007 setup requires that the domain controller that serves as the schema FSMO run Windows Server 2003 SP1 or a later version.

The FSMO controls all updates and modifications to the Active Directory schema.

To resolve this issue, do one or more of the following:

  • Upgrade the FSMO domain controller to Windows Server 2003 SP1 or a later version and rerun Microsoft Exchange setup.

  • If there is a FSMO domain controller running Microsoft Windows Server 2003 Service Pack 1 (SP1) or a later version in the Exchange organization, run Exchange 2007 setup with the /domaincontroller parameter pointing to that FSMO domain controller:

    [/DomainController, or /dc <FQDN of domain controller>]

    Use the /DomainController parameter to specify the domain controller to use to read from and write to Active Directory during setup. You can use NetBIOS or the fully qualified domain name (FQDN) format.

To obtain the latest service pack for Windows Server 2003, see the "Windows Server TechCenter" (http://go.microsoft.com/fwlink/?LinkId=45315).

For more information about Exchange Server 2007 Setup parameters, see "How to Install Exchange 2007 in Unattended Mode" (http://go.microsoft.com/fwlink/?LinkId=86476) in the Exchange Server 2007 product documentation.


Setup Cannot Install Exchange to a Read-Only Domain Controller
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-07-23

Microsoft Exchange Server 2007 Setup cannot continue the installation because the target computer is a Read-Only Domain Controller (RODC).

Read-Only Domain Controllers are a feature of Windows Server 2008 Active Directory. The RODC is a type of domain controller install option that can be installed in remote sites that may have lower levels of physical security.

Exchange Setup requires write access to the target install computer.

To resolve this issue, select a target install computer that is not designated as an RODC, and rerun Setup.


Setup Failure Occurred While Installing a Server Role
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-04-12

Microsoft Exchange Server 2007 setup cannot continue because a previous setup failure occurred while installing a server role.

Exchange 2007 setup requires that a failed server role installation be successfully re-installed, or removed from the setup process, before any other setup task can continue.

To address this issue, either reinstall just the failed server role(s), or remove the server role(s).

To reinstall the failed server role from the command line

  1. Open a Command Prompt window, and then navigate to the installation files.

  2. Run the following command:

    Copy Code
    Setup /roles:<Failed Server Role>

    Select from one or more of the following roles, in a comma-separated list:

    ClientAccess (or CA, or C)

    EdgeTransport (or ET, or E)

    Note:
    The Edge Transport server role cannot coexist on the same computer with any other server role.
    Note:
    You must deploy the Edge Transport server role in the perimeter network and outside the Active Directory forest.

    HubTransport (or HT, or H)

    Mailbox (or MB, or M)

    UnifiedMessaging (or UM, or U)

    ManagementTools (or MT, or T)

    Note:
    If you specify ManagementTools, you will install the Exchange Management Console, the Exchange cmdlets for the Exchange Management Shell, the Exchange Help file, the Exchange Best Practices Analyzer Tool, and the Exchange Troubleshooting Assistant. If you install any other server role, the management tools will be installed automatically.

    For example, to add the Hub Transport server role to an existing Mailbox server, type the following: %LocalExchangeInstallationDir%\bin\Setup.com /role:HubTransport /Mode:Install

Note:
If any Exchange Server 2007 server role previously installed successfully, the Setup wizard will run in maintenance mode. If no Exchange 2007 server roles were previously successfully installed, the Setup wizard will start from where it stopped.
To use the Exchange Server 2007 Setup wizard in maintenance mode to reinstall the failed server role

  1. Log on to the server for which you want to reinstall a server role.

  2. Open Control Panel and then double-click Add or Remove Programs.

  3. On the Change or Remove Programs page, select Microsoft Exchange Server, and then click Change.

  4. In the Exchange Server 2007 Setup wizard, on the Exchange Maintenance Mode page, click Next.

  5. On the Server Role Selection page, select the check boxes for the server roles that you want to install, and then click Next.

    Note:
    The Edge Transport server role cannot coexist on the same computer with any other server role.
    Note:
    You must deploy the Edge Transport server role in the perimeter network and outside the Active Directory forest.
    Note:
    If you select Management Tools, you will install the Exchange Management Console, the Exchange cmdlets for the Exchange Management Shell, and the Exchange Help file. The management tools will be installed automatically if you install any other server role.

  6. If you selected Hub Transport Role, and if you are installing Exchange 2007 in a forest that has an existing Exchange Server 2003 or Exchange 2000 Server organization, on the Mail Flow Settings page, select a bridgehead server in the existing organization that is a member of the Exchange 2003 or Exchange 2000 routing group to which you want to create a routing group connector.

  7. On the Readiness Checks page, view the status to determine if the organization and server role prerequisite checks completed successfully. If they have completed successfully, click Install to install Exchange 2007.

  8. On the Completion page, click Finish.
To use the Exchange Server 2007 Setup wizard to reinstall the failed server role when no other server role was previously successfully installed

  1. Follow the guidance in "How to Perform a Custom Installation Using Exchange Server 2007 Setup" (http://go.microsoft.com/fwlink/?LinkId=86648) in the Exchange Server 2007 product documentation.
To remove the failed server role

  1. Follow the guidance in "How to Remove Exchange 2007 Server Roles" (http://go.microsoft.com/fwlink/?LinkId=86649) in the Exchange Server 2007 product documentation.

For More Information

For more information about how to install Exchange 2007 in unattended mode, see "How to Install Exchange 2007 in Unattended Mode" (http://go.microsoft.com/fwlink/?LinkId=86476).


This Server is the Source for a Routing Group Connector
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because its attempt to remove the Hub Transport server role failed. The local computer is the source for one or more routing group connectors in the Exchange organization.

A routing group connector is used to send and receive messages between Exchange 2007 Hub Transport servers and Exchange Server 2003 or Exchange 2000 Server bridgehead servers. When Exchange Server 2007 is installed in an existing Exchange Server 2003 and Exchange 2000 Server organization, the required routing group connector is created during setup.

Exchange 2007 setup requires that all routing group connectors for an Exchange organization be moved or deleted from the Hub Transport server computer before the server role can be deleted.

To resolve this issue, move or delete all routing group connectors from the local computer and then rerun setup.

To move the Routing Group Connector using the Exchange Management Shell

  1. Use the Set-RoutingGroupConnector cmdlet to modify the properties of an existing routing group connector between a Microsoft Exchange Server 2007 routing group and an Exchange Server 2003 or Exchange 2000 Server routing group.

  2. This example uses the Set-RoutingGroupConnector cmdlet to modify the source of a routing group connector
Copy Code
Set-RoutingGroupConnector -Identity "[[Administrative Group Name\]Routing Group Name]\Routing Group Connector Name" -SourceTransportServers [FQDN of desired Hub Transport Server]
 To remove the Routing Group Connector using the Exchange Management Shell

  1. Use the Remove-RoutingGroupConnector cmdlet to remove a routing group connector between a Microsoft Exchange Server 2007 routing group and an Exchange Server 2003 or Exchange 2000 Server routing group.

  2. The following example shows how to use the Remove-RoutingGroupConnector cmdlet to remove the specified routing group connector.
Copy Code
Remove-RoutingGroupConnector -Identity"[[Administrative Group Name\]Routing Group Name]\Routing Group Connector Name"

For more information about modifying or removing routing group connectors, see the following topics in the Exchange Server 2007 product documentation:

  • Set-RoutingGroupConnector (http://go.microsoft.com/fwlink/?LinkId=86659).

  • Remove-RoutingGroupConnector (http://go.microsoft.com/fwlink/?LinkId=86660).


This Server is the Source for a Send Connector
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because its attempt to remove the Hub Transport server role failed. The local computer is the source for one or more Send connectors in the Exchange organization.

A Send connector represents a logical gateway through which outbound messages are sent.

Exchange 2007 setup requires that all Send connectors for an Exchange organization be moved or deleted from the Hub Transport server computer before the server role can be deleted.

To resolve this issue, move or delete all Send connectors from the local computer and then rerun setup.

For more information about modifying or removing Send connectors, see the following topics in the Exchange Server 2007 product documentation:

  • "How to Remove a Send Connector" (http://go.microsoft.com/fwlink/?LinkId=86655).

  • "How to Modify the Configuration of a Send Connector" (http://go.microsoft.com/fwlink/?LinkId=86656).


Simple Exchange Organization Model Detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-18

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the number of mailboxes on the server. Each mailbox store object (msExchPrivateMDB class) has a multivalued attribute homeMDBBL that lists all the mailboxes in the store. The Exchange Server Analyzer counts these values to obtain the total number of mailboxes on the server.

The Exchange Server Analyzer also queries Active Directory to determine the number of Active Directory sites that contain Exchange Servers. In addition, the Exchange Server Analyzer queries Active Directory to determine the number of servers that are running either Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003. Finally, the Exchange Server Analyzer queries the Win32_Service Microsoft Windows® Management Instrumentation (WMI) object to determine whether the Windows Cluster service is present and running.

The Exchange Server Analyzer categorizes the Exchange organization as a simple Exchange organization if the following conditions are true:

  • The total number of mailboxes in the organization is less than 1,000.

  • Exchange servers are installed only in one Active Directory site.

  • There are fewer than 3 computers running either Exchange 2000 or Exchange 2003.

  • There are no clustered Exchange servers deployed.

Of the four defined organization models for Microsoft Exchange Server 2007, the simple Exchange organization represents the most basic topology into which Exchange 2007 can be deployed. The simple Exchange organization contains either:

  • A single Exchange server that provides all Exchange services and stores all Exchange data for the whole organization.

  • Multiple Exchange servers in a topology that includes redundant directory servers and an Edge Transport server in a perimeter network.

To transition a Simple Exchange Organization to Exchange 2007

  1. Visit the Exchange 2007 product documentation online (http://go.microsoft.com/fwlink/?LinkId=69434).

  2. Expand "Planning and Architecture," expand "Planning Your Deployment," and then click "Planning for a Simple Exchange Organization."


The Simple Mail Transport Protocol is currently installed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-01-22

Microsoft® Exchange Server 2007 setup cannot continue because the Microsoft Windows Server™ 2003 Simple Mail Transfer Protocol (SMTP) service is installed on this computer.

Microsoft Exchange setup requires that the SMTP service not be installed on servers that are used for Exchange 2007.

To resolve this issue, uninstall the SMTP service and rerun Microsoft Exchange setup.

To uninstall the SMTP service by using Add or Remove a Windows Component in Control Panel

  1. On the Start menu, click Control Panel.

  2. Double-click Add or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. In the Components list, select the Application Server check box and then click Details.

  5. Select Internet Information Services Manager and then click Details.

  6. Select SMTP Service and then click to clear the check box.

  7. Click OK two times to return to the Components list and then click Next.

  8. Click Finish when the SMTP service is uninstalled.


Site cannot support Exchange 2007 servers
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-11

The Microsoft® Exchange Server Analyzer Tool displayed this warning because there are sites in the Active Directory directory service forest that do not have at least one global catalog server that is running on Microsoft Windows Server™ 2003 Service Pack 1 (SP1) or a later version.

Microsoft Exchange Server 2007 setup requires each Active Directory site that will host a server that is running Exchange 2007 to have at least one global catalog server that is running on Windows Server 2003 SP1 or a later version.

To address this issue, upgrade at least one global catalog server in each Active Directory site to Windows Server 2003 SP1 or a later version.

For more information about how to upgrade to Windows Server 2003, see Microsoft Knowledge Base article 810613, "Supported paths for upgrading to Windows Server 2003 or to Windows Small Business Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810613).

To obtain the latest service pack for Windows Server 2003, see the Windows Server TechCenter (http://go.microsoft.com/fwlink/?LinkId=45315).


Standard Exchange Organization Model Detected
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-08-10

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine:

  • The number of mailboxes in the organization.

  • The number of routing groups in the organization.

  • The number of Active Directory sites in the organization.

  • The number of Active Directory forests in the organization.

  • Whether Microsoft Identity Integration Server (MIIS) is installed.

The amount for each item determines whether the Exchange organization model is simple, standard, large, or complex. Any organization that is not classified as simple, large, or complex, is automatically classified as a standard Exchange organization.

Of the four defined organizational models for Microsoft Exchange Server 2007, the standard Exchange organization represents the most common topology into which Exchange 2007 is deployed. As messaging service needs grow beyond the resource limits of a single computer, separation of Exchange 2007 services onto multiple computers becomes the next topological division: the standard Exchange organization. The standard Exchange organization builds upon the simple Exchange organization by deploying multiple computers that are running Exchange.

To transition a Standard Exchange Organization to Exchange 2007

  1. View the Exchange 2007 product documentation online (http://go.microsoft.com/fwlink/?LinkId=69434).

  2. Expand "Planning and Architecture," expand "Planning Your Deployment," and then click "Planning for a Standard Exchange Organization."


Static IP addresses are recommended in a cluster
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

Microsoft® Exchange Server 2007 setup displayed this warning because one or more network interfaces are configured to use the Dynamic Host Configuration Protocol (DHCP).

It is a recommended best practice that static IP addresses be used for network interfaces managing client connections and heartbeat links in a Microsoft Windows server cluster. Using a dynamic configuration through DHCP is not recommended, as the failure to renew a DHCP lease could disrupt cluster operations.

To address this warning, configure each network interface managing client connections or heartbeat links to use a static IP address.

To Configure a Static IP address for a network connection

  1. On the Start menu, click Settings, and then Network Settings.

  2. Right-click the connection you want to configure, and then click Properties.

  3. On the General tab, in This connection uses the following items, click Internet Protocol (TCP/IP), and then click Properties.

  4. Click Use the following IP address, and in IP address, type the IP address.

  5. Click OK two times to finish.

For more information about the optimal network configuration for Windows Server clusters, see "Server Clusters: Network Configuration Best Practices for Windows 2000 and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=34304).

For more information about the correct cluster heartbeat configuration, see Microsoft Knowledge Base article 258750, "Recommended private "Heartbeat" configuration on a cluster server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750).


Storage path for a single copy cluster must be a clustered disk
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the storage path for a single copy cluster must be a clustered disk.

In Exchange Server 2007, single copy cluster (SCC) is a clustered solution that uses a single copy of a storage group on storage that is shared between the nodes in the cluster.

To address this issue, specify a clustered drive for the datapath, and then rerun Exchange 2007 setup.

For more information about single copy clusters, see "Installing a Single Copy Cluster" (http://go.microsoft.com/fwlink/?LinkId=76162) in the Exchange Server 2007 product documentation.


SMTP Addressing Format Not Supported
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the specified recipient policy uses an unsupported Simple Mail Transfer Protocol (SMTP) address format.

Exchange 2007 setup requires that all SMTP addresses used for e-mail address policies not contain IP address literals, for example: user@[10.10.1.1].

To resolve this issue, change the value of the SMTP address in the recipient policy so that it does not contain an IP address literal. Replace brackets ([]) and numbers (10.10.1.1) of the IP address literal with the Domain Name System (DNS) naming format, for example: user@contoso.com, and then rerun Exchange setup.

For more information about managing recipient policies in Exchange Server 2007, see "Managing E-Mail Address Policies" (http://go.microsoft.com/fwlink/?LinkId=86653).


SMTP site link found
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-12-07

The Microsoft® Exchange Server Analyzer Tool displays this warning if it finds Simple Mail Transfer Protocol (SMTP)-based site links in the Active Directory® directory service.

Microsoft Exchange Server 2007 routing will ignore Active Directory sites connected by SMTP site links. If Exchange 2007 is installed in sites that are connected only by an SMTP site link, routing errors will occur.

To address this issue, replace the SMTP site links with IP-based site links.

For more information about Active Directory IP site links, see "Planning to Use Active Directory Sites for Routing Mail" (http://go.microsoft.com/fwlink/?LinkId=71803).


Storage group drive specification is missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-05-15

Microsoft® Exchange Server 2007 Disaster Recovery setup cannot continue because Disaster Recovery setup cannot access the storage group database drive specification that was used in the previous installation of this server.

Microsoft Exchange Disaster Recovery setup requires that the same storage group database drive specifications previously used for this server be available during the restore.

To resolve this situation, configure the drives to match the original logical drive configuration and rerun Microsoft Exchange Disaster Recovery setup.

Assign or change a drive letter

  1. Open Computer Management (Local).

  2. In the console tree, click Computer Management (Local), click Storage, and then click Disk Management.

  3. Right-click a partition, logical drive, or volume, and then click Change Drive Letter and Paths.

  4. Use one of the following procedures:

    • To assign a drive letter, click Add, click the drive letter you want to use, and then click OK.

    • To modify a drive letter, click it, click Change, click the drive letter you want to use, and then click OK.

For more information about how to assign drive letters, see "Assign, change, or remove a drive letter" (http://go.microsoft.com/fwlink/?LinkId=66764).


Target Install Path Mis-Match
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 setup cannot continue because the target path for the Exchange binary files does not match the existing Exchange install path on other cluster nodes.

Exchange Server 2007 requires that nodes of the same cluster have consistent target install paths for the Exchange binary files.

To resolve this issue, use a target install path for the Exchange binary files that is consistent across all nodes of the cluster.

For more information about High Availability Exchange Server 2007 installations, see "High Availability" (http://go.microsoft.com/fwlink/?linkid=68190) in the Exchange Server 2007 product documentation.


Target path is compressed
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-06

Microsoft® Exchange Server 2007 setup cannot continue because the target folder path for the Microsoft Exchange installation is compressed.

Microsoft Exchange setup requires that the first folder in the target path for the installation not be compressed. By default, the first folder in the target path for the installation is C:\Program Files.

To resolve this issue, disable compression for the first folder in the target path and rerun Exchange 2007 setup.

To disable compression for the target path

  1. In My Computer or Windows Explorer, right-click the folder to decompress.

  2. Click Properties to display the Properties dialog box.

  3. On the General tab, click Advanced.

  4. In the Advanced Attributes dialog box, clear the Compress contents to save disk space check box and then click OK.

  5. In the Properties dialog box, click OK.

  6. When the compression state is changed for the folder, in the Confirm Attribute Changes dialog box, select Apply changes to this folder, subfolders, and files.

  7. Click OK when done.


Two or more network interfaces are recommended in a cluster
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

Microsoft® Exchange Server 2007 setup displays this warning because the current Microsoft Windows cluster environment has only one network interface that is defined.

It is a recommended best practice to implement at least one network interface for the public network (client connection) and one network interface for the private network (administrative/heartbeat) to avoid a single point of failure.

To address this warning, implement at least one additional network interface for the Microsoft Windows cluster.

For more information about the optimal network configuration for Windows server clusters, see "Server Clusters: Network Configuration Best Practices for Windows 2000 and Windows Server 2003" (http://go.microsoft.com/fwlink/?linkid=34304).


Unable to connect to Remote Registry service
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-01-23

Microsoft® Exchange Server 2007 setup cannot continue because the registry on the local computer could not be accessed.

Exchange 2007 setup requires access to the local registry to retrieve various settings.

Exchange setup tries to use the Domain Name System (DNS) to obtain the fully qualified domain name (FQDN) of the local computer to access the registry.

Either setup was unable to retrieve the FQDN from the DNS because of a network error or it was unable to access the registry.

To address this issue, verify that the remote registry service is running on the local computer and that File and Print Sharing is enabled on the first network adapter in the binding order, and then run Exchange setup again.

To verify the Remote Registry Service is running

  1. Click Start, point to Settings, Control Panel, Administrative Tools, and then double-click Services.

  2. Verify that the Remote Registry Service has a status of Started.
To enable File and Print Sharing on the primary network adapter

  1. Click Start, point to Settings, Control Panel, Network Connections, and then Local Area Connection.

  2. Verify that File and Printer Sharing for Microsoft Networks is enabled, that is, the check box is selected.
Note:
If this is a clustered server, you must verify that the Remote Registry service is running on all nodes of the cluster and that File and Printer Sharing for Microsoft Networks is enabled for the network adapter that is listed first in the binding order.


Windows Media Audio Voice Codec update required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-07-13

Microsoft® Exchange Server 2007 setup cannot continue because Microsoft Windows Media Audio Voice Codec is not installed or a more recent version of Windows Media Audio Voice Codec is available.

Exchange 2007 setup requires that you install the most recent version of Windows Media Audio Voice Codec on the server. Windows Media Audio Voice Codec is needed to support the Exchange Server 2007 Unified Messaging server role.

To resolve this issue, install the most recent version of Windows Media Audio Voice Codec from http://go.microsoft.com/fwlink/?LinkId=67407 and then rerun Exchange 2007 setup.


Windows Media Encoder update required
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-07-13

Microsoft® Exchange Server 2007 setup cannot continue because Microsoft Windows Media Encoder is not installed or a more recent version of Windows Media Encoder is available.

Exchange 2007 setup requires that you install the most recent version of Windows Media Encoder on the server. Windows Media Encoder is necessary to support the Exchange Server 2007 Unified Messaging Server role.

To resolve this issue, install the most recent version of Windows Media Encoder from http://go.microsoft.com/fwlink/?LinkId=67406 and then rerun Exchange 2007 setup.


The World Wide Web Publishing Service is disabled or missing
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-02-14

Microsoft® Exchange Server 2007 setup cannot continue because its attempt to install the Mailbox Server or Client Access role found that the World Wide Web Publishing Service is either disabled or not installed on this computer.

Exchange 2007 setup requires the computer that you are installing Microsoft Exchange to have the World Wide Web Publishing Service installed and set to something other than disabled.

To resolve this issue, verify that the World Wide Web Publishing service is installed and not disabled on the local computer, and then rerun Microsoft Exchange setup.

To verify that the World Wide Web Publishing Service is installed and not disabled

  1. Right-click My Computer on the desktop, and then click Manage.

  2. Expand the Services and Applications node, and then click the Services node.

  3. In the right pane, locate the World Wide Web Publishing Service.

    If the World Wide Web Publishing Service is not displayed in the list of services installed, follow the steps in the procedure below to install it.

  4. If the World Wide Web Publishing Service is displayed but has a status other than Started, continue with the steps below to start it.

  5. Right-click World Wide Web Publishing Service, and then click Properties.

  6. Verify the Startup Type is Automatic and the Service status is set to Started.

  7. Click Apply, and then click OK.
To install the World Wide Web Publishing Service

  1. On the Start menu, select Settings, Control Panel, and then click Add or Remove Programs

  2. Click Add/Remove Windows Components.

  3. In the Components list, select the Application Server check box, and then click Details.

  4. Select Internet Information Services Manager, and then click Details.

  5. Select World Wide Web Service, and then select the check box.

  6. Click OK two times to return to the Components list, and then click Next.

  7. Click Finish when the IIS service is installed.


Uninstall Unified Messaging Language Packs
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-16

Microsoft Exchange Server 2007 setup cannot continue because the Unified Messaging server role upgrade failed.

Exchange setup requires that all Unified Messaging server role language packs, except the US English language pack, be uninstalled before the Unified Messaging server role upgrade can continue.

Unified Messaging (UM) language packs that are included with Exchange 2007 contain pre-recorded prompts, Text-to-Speech (TTS) conversion support for a given language.

Exchange 2007 UM language packs enable callers and Outlook Voice Access users to interact with the Unified Messaging system in multiple languages.

The existing non-US English language packs need to be uninstalled so that new language packs can be installed.

To resolve this issue, uninstall all Unified Messaging server role language packs, except the US English language pack, and then rerun Exchange 2007 setup.

For more information about uninstalling Unified Messaging server role language packs, see How to Remove a Unified Messaging Language Pack from a Unified Messaging Server in the Exchange 2007 product documentation.


Update Needed for Disaster Recovery
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2007-03-27

Microsoft Exchange Server 2007 Disaster Recovery cannot continue because a later version of Exchange Server 2007 was originally used to install Exchange Server on this computer.

Microsoft Exchange Disaster Recovery requires that the version of Exchange Server 2007 used to perform a recovery of the Exchange Server be equal to or greater than the version that was originally used to install the Exchange Server.

To resolve this issue, start Exchange Server 2007 Disaster Recovery from a version of Exchange Server 2007 that is equal to or greater than the version that was originally used to install the Exchange Server.


X400 Connector Found in Topology
Microsoft Exchange Server Analyzer - Articles > Exchange Server 2007 Readiness >

Topic Last Modified: 2006-06-05

The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service for X.400 connectors. If the Exchange Server Analyzer finds X.400 connectors present in the Microsoft Exchange organization, the Exchange Server Analyzer displays a warning. The warning indicates that the X.400 connector, a protocol that is used to transport messages between previous messaging systems, is not supported in Microsoft Exchange Server 2007.

In Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003, Simple Mail Transfer Protocol (SMTP) was made the default transport protocol. Although X.400 connectors are supported in Exchange 2000 and Exchange 2003, they are not supported in Exchange 2007 because the use of X.400 connectors has declined over the years. If X.400 support is still required, it is recommended that you keep an Exchange 2000 or Exchange 2003 server. Otherwise X.400 connector can be replaced with SMTP.

For more information about X.400 transport architecture in Exchange 2003, see "Exchange Server 2003 Message Routing" (http://go.microsoft.com/fwlink/?LinkId=65578).

For more information about how to implement the X.400 connector in Exchange 2003, see "Implementing the X.400 Connector - Is It Worth Using with Exchange Server 2003?" (http://www.msexchange.org/tutorials/X400-Connector-Exchange-Server-2003.html)

Note:
The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.


Legal Information

Topic Last Modified: 2007-04-06

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

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

© 2007 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveSync, ActiveX, MSDN, Outlook, SharePoint, Visual C++, Win32, Windows, Windows NT, Windows Server, and Windows Server System are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.