This document lists critical issues that can potentially impede you from successfully installing or deploying Exchange 2000 Server Service Pack 3 (SP3) in your environment.
Note The release notes in this document have been updated since the release of Microsoft Exchange 2000 Server Service Pack 3.
Information in this document, including URL and other Internet Web site references, is subject to change without notice and is provided for informational purposes only. The entire risk of the use or results of the use of this document remains with the user, and Microsoft Corporation makes no warranties, either express or implied. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person 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.
Copyright 2002 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Active Directory, and Outlook are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.
This document contains the following sections:
About This DocumentThis document lists critical issues that can potentially impede you from successfully installing or deploying Exchange 2000 Service Pack (SP3) in your environment. The issues listed in this document do not include Microsoft Exchange 2000 Conferencing Server release notes.
The following are important notes about upgrading to Exchange SP3:
Immediately before and after upgrading your servers to Exchange 2000 SP3, you should make a full backup of your servers. Making this backup ensures that you have a valid backup of your servers should you require one. This is considered a best practice for all upgrades.
For more information about backup and restore, see the "Disaster Recovery for Microsoft Exchange 2000 Server" white paper at http://go.microsoft.com/fwlink/?linkid=1714.
After installing Exchange 2000 SP3 on a clustered server, some organization-level permissions that you may have modified, can be reset to their original default value. For example, in Exchange System Manager, if you removed the "everyone" group from the permissions on the Organization object, you will need to reset those permissions after installing Exchange 2000 SP3.
It is recommended that you keep track of any permission modifications in order to re-apply them after installing Exchange 2000 SP3.
Outlook Web Access clients download script files from the front-end server to which they connect. These script files are not compatible with back-end servers that are running a later version of Exchange than the front-end server. When you upgrade a server running Exchange 2000 to a later service pack, you must upgrade all front-end servers before you upgrade Exchange on any back-end servers. The script files on an upgraded front-end server are compatible with any back-end server running a previous service pack of Exchange 2000.
Note If there are multiple front-end servers, you do not have to upgrade all front-end servers simultaneously. However, you must upgrade all front-end servers before you upgrade any back-end servers.
Exchange 2000 SP3 includes the SMTP Reinstall tool (Smtpreinstall.exe), which is available in the Support Tools directory on the Exchange SP3 compact disc. Use the SMTP Reinstall tool to repair Exchange 2000 without completely reinstalling Exchange if you uninstall the Windows 2000 SMTP service. To repair Exchange, you must first reinstall the Windows 2000 SMTP service and then run the SMTP Reinstall tool. However, you cannot use the SMTP Reinstall tool on a cluster running Exchange 2000. If you try to run the tool, you will encounter issues that prevent you from repairing Exchange successfully. Therefore, the SMTP Reinstall tool is not supported on an Exchange 2000 cluster. Instead of using the SMTP Reinstall tool on a cluster, you will need to completely reinstall Exchange and any previously applied Exchange service packs after you reinstall the SMTP service.
Exchange 2000 Server SP3 does not support GB 18030 encoded messages. GB 18030 encoded messages will be successfully routed by a server running Exchange 2000 SP3 with Internet Explorer 6.0 Service Pack 1 (SP1) installed. Otherwise GB 18030 encoded messages generate Non-Delivery Reports (NDRs) on servers running Exchange 2000 SP3.
Note Exchange requires the updated version of mlang.dll found in Internet Explorer 6.0 SP1 to receive GB 18030 encoded mail.
If you are developing applications for Exchange, Microsoft recommends installing MSXML Parser 3.0 Service Pack 2 on your Exchange 2000 server. For more information about MSXML Parser 3.0 Service Pack 2, see the following Web site at http://go.microsoft.com/fwlink/?LinkId=8078.
A security modification in Microsoft Exchange Server 2000 Service Pack 3 (SP3) removes broadly available read access to the Microsoft Internet Information Services (IIS) metabase. As a result, a Collaboration Data Objects for Exchange (CDOEX) or Collaboration Data Objects for Windows (CDOSYS) application that sends mail using Simple Mail Transport Protocol (SMTP) could fail. Although this change may cause a disruption to some customers, the end result is a more secure system.
Exchange and Microsoft are deeply committed to improving the security of our products for customers. Although this access path doesnt represent a widespread problem, it has been determined to constitute a serious enough security vulnerability to warrant immediate closure in SP3. The following Microsoft Knowledge Base article outlines four small and secure workarounds (each dependent on the customers application) and includes guidelines for secure development of similar future applications.
Microsoft Knowledge Base article "PRB: Microsoft Exchange 2000 Server Service Pack 3 Security Modification and CDOEX/CDOSYS" at http://go.microsoft.com/fwlink/?LinkId=3052&ID=324037 describes the symptom and describes how to work with CDOEX after Exchange 2000 SP3 has been applied. Sample code is written in the context of an ASP page.
You can configure an Exchange server to automatically send fatal service error reports to Microsoft. If a fatal error occurs, the server sends information about the error over a secure (https) connection to Microsoft, where it is stored with limited access. Microsoft uses the reports only to improve Exchange and treats all information as confidential.
The report contains the following information:
Microsoft does not intentionally collect your files, name, address, e-mail address, or any other form of personal information. However, the report may contain customer-specific information from files that were open when the error occurred. Although this information could potentially be used to determine your identity, Microsoft does not use this information.
For the Microsoft Error Reporting Data Collection Policy, see http://watson.microsoft.com/dw/1033/dcp.asp
By default, error reporting is disabled. To enable error reporting, in Exchange System Manager, in the console tree, right-click the server you want, and then click Properties. In the server properties dialog box, on the General tab, select the Automatically send fatal service error information to Microsoft check box.
You can use the Exchange SP3 Migration Wizard to migrate from Microsoft Exchange 5.5 Server and Microsoft Exchange 2000 servers in separate Exchange organizations. When you migrate accounts using Migration Wizard, a disabled user account is created in the target directory. If you decide to enable these accounts, you should use Active Directory Migration Tool (ADMT) to migrate the accounts (with security identifiers [SIDs]).
For more information about using ADMT, see the following white paper:
If you use Exchange Migration Wizard to perform a two-step Exchange migration , and the Microsoft Outlook folder language is different from the user locale of the server that is performing the migration, two copies of the special folders (Inbox, Sent Items, Deleted Items, and Outbox) are created and appear in the Outlook client after migration. One copy of each folder is created for the language used by Outlook, and another copy of each folder is created for the language used by the user locale of the server.
Note It is recommended that you delete the set of folders with non-standard icons. It is also recommended that you empty these folders before deleting them.
Front-End servers used by Outlook Web Access clients must be upgraded before Back-End servers. For more information, see the Upgrading to Exchange SP3 section of this document.
When you install Exchange 2000 SP3, help files for Outlook Web Access clients are not installed. Administrators must manually update or install these help files by running an .msi file, or language pack, for each language used by Outlook Web Access clients.
Important If you previously updated your Outlook Web Access Help files with Exchange 2000 Server SP1 or SP2, you must first uninstall the SP1 or SP2 Help file updates before you can install the Outlook Web Access SP3 Help file updates. To remove SP1 or SP2 Help file updates, in Control Panel, double-click Add/Remove Programs.
To manually update Outlook Web Access HelpInstallation of Exchange 2000 SP3 removes the Microsoft Exchange Multimedia Control from the Options page in Outlook Web Access.
Outlook Web Access users who are connected directly to a back end server in an Exchange 2000 Server cluster will receive a "500 Internal Server Error" error when clicking "Log Off."
Note This does not apply to users connecting through a front end server.
To allow Outlook Web Access users who are connected directly to a back end server to use the "Log Off" button
To view and configure Directory Access information for any server running Exchange SP2 or SP3 in your topology, in Exchange System Manager, right-click a server, click Properties, and then use the Directory Access tab. You can add servers to or remove servers from the topology list for Exchange SP2 or SP3 servers only. For Exchange 2000 and SP1 servers, you can only view a partial current topology list. If you try to select a server running Exchange or Exchange SP1, only the names of the domain controllers that Directory Access uses are listed; you cannot manually configure the servers because the Add and Remove buttons are not available.
After you upgrade to Exchange SP3 from Exchange 2000 or Exchange 2000 SP1, the Microsoft Exchange MTA Stacks service and Microsoft Exchange Information Store service will not start unless both of the following requirements are met:
In Exchange SP2 or SP3, Directory Access uses only the domain controllers and global catalog servers that give the server running Exchange permission to use the system access control lists (SACLs). If you use a global catalog server in a different domain, you must run the DomainPrep utility in that domain, create a new Recipient Update Service for that domain, and then restart the server running Exchange that was upgraded to SP3 from Exchange 2000 or Exchange 2000 SP1 for Directory Access to run properly.
By default, Directory Access pings each server it connects to using Internet Control Message Protocol (ICMP) to determine if the server is available. In a perimeter network (also known as DMZ, demilitarized zone, and screened subnet) firewall scenario, there is no ICMP connectivity between the server running Exchange and the domain controllers. This situation causes Directory Access to respond as if every domain controller is unavailable. Directory Access then discards old topologies and frequently performs new topology discoveries, which impact server performance. You can turn off the Directory Access ping by creating a registry key for the Windows implementation of LDAP (wLDAP).
The registry key controlling the ping is:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\LdapKeepAliveSecs
Caution Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Exchange 2000. To configure or customize Exchange 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.
Note To manually configure Directory Access from Exchange System Manager, use the Directory Access tab and configure the server while it is not in the perimeter network. After you make the manual configurations, you can put the server back in the perimeter network. However, the registry key setting above is still required for Directory Access to function.
In Exchange SP2 or SP3, the Directory Access display is new and the Message Tracking Center functionality is updated. When you install Exchange SP2 or SP3, the new Microsoft Exchange Management Service, which is used by both Directory Access and Message Tracking Center, is automatically installed and started.
To use the new Directory Access display, the server that you want to configure must also be running Exchange SP2 or SP3. If the service is not running on a server running Exchange SP3, the Directory Access tab will not display information about how or allow you to configure connected domain controllers. If an administrator wants to view or change Directory Access configurations, he or she is able to only configure servers running SP2 or SP3.
To provide message-tracking information to the Message Tracking Center, the server or workstation running Exchange System Manager from SP3 must be running Microsoft Exchange Management Service, as well as all SP3 servers. Also, the more servers that are running Microsoft Exchange Management Service, the better your tracking performance results are. For administrator-only installations, the Microsoft Exchange Management Service must be running on the workstation. After you install Exchange SP3, an administrator can use the new Message Tracking Center to track e-mail anywhere in the entire Exchange organization, including servers running Exchange 5.5, Exchange 2000, and Exchange 2000 SP1. If the administrator uses the Message Tracking Center from any server or workstation running SP3, he or she is able to track e-mail on any server that does not yet have SP3 installed; however, message tracking takes longer to search on non-SP3 servers than on SP3 servers.
If you manually created Directory Access profiles in the registry before you upgraded to Exchange SP3, the profiles are preserved after you upgrade. The servers that were manually configured through the profiles also appear in Exchange System Manager. To view the Directory Access properties of these servers, in Exchange System Manager, in the console tree, right-click the server you want, click Properties, and then click the new Directory Access tab.
If an invalid entry in the profile exists, or if a server is invalid, the following message appears after you upgrade to Exchange SP2 or SP3 and access the Directory Access tab: "The server servername does not exist or is not appropriately configured. Do you want this server removed from this list?"
To fix this problem and create a valid profile
In Message Tracking Center, tracking a message may fail to complete and fail to show all events for a message if the message traveled between two servers with system times that, at the time of the message transfer, were more than five minutes apart. This issue does not impact servers with different system times, such as differences in time zones or daylight savings times. Changing the system time after message delivery does not correct this problem, but it does prevent the problem from happening in the future.
The updated Message Tracking Center now requires an administrator to have specific permissions to track a message. Only administrators who have one of the following delegated roles on the servers running Exchange 2000 or Exchange 5.5 can track a message using the updated Message Tracking Center:
You use Exchange Delegation of Control Wizard to assign these roles. To access Delegation of Control Wizard, in Exchange System Manager, right-click the organization root or an administrative group root, and then click Delegate control.
To track messages in the updated Message Tracking Center, the user must be assigned one of the delegated roles listed above. In SP3, Message Tracking Center checks the roles assigned to the user before allowing the user to track messages. Because permissions are checked on a per-server basis, a user must have one of the delegated roles for all servers on which he or she needs to track e-mail messages. This new security measure does not negate the need to grant proper access control to the \\server\server.log share that is automatically created when you install Exchange. You should continue to control access to that share as well as assign appropriate roles to users who track messages, or you may risk the possibility that anyone with read access to the file share can analyze message traffic on the server.
The different administrator levels do not control how and where a particular user can track e-mail; the different levels only grant a user who is assigned one of these roles the ability to track messages. Any user not assigned one of these roles on any particular server is unable to track e-mail on that server only. For example, if you have a group of administrators whose job is to only track e-mail, you should only grant them Exchange View-Only Administrator rights. Otherwise, if you grant them Exchange Administrator or Exchange Full Administrator rights, they have permission to make changes to the Exchange installation. If you had another group of administrators who are responsible for installing or modifying the Exchange installation, you should grant them Exchange Full Administrator permissions so that they can make changes to the Exchange installation, as well as have permission to track e-mail.
It is strongly recommended that you use the Check Pointing script provided with Exchange SP3 to prevent possible indexing problems. If the Microsoft Search service (MSSearch) terminates abnormally during an incremental crawl (population), some folders and messages may not be properly indexed. Check Pointing remedies this problem by maintaining the following backup files in the catalog directory:
Check Pointing is not enabled by default because it requires a significant amount of additional disk space. The additional file size is approximately 200 bytes for each document in your database. For example, 5,000,000 messages or documents in your database generates Check Pointing files totaling 1 GB. The size of these files grows as the number of documents in your database grows. You should ensure that there is sufficient disk space before you run the Check Pointing script. It is recommended that at least 15 percent free disk space be available on the disk in which you keep full-text indexing catalogs.
To set up Check Pointing
<SystemDrive>:\Program Files\Common Files\System\MSSearch\Bin\EnableCheckPoints.vbs <APPLICATION> [CATALOG]
Parameter Definitions