This document lists critical issues that can potentially impede you from successfully installing or deploying Exchange 2000 Server Service Pack 2 (SP2) in your environment.
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 2001 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:
This document lists critical issues that can potentially impede you from successfully installing or deploying Exchange SP2 in your environment. The issues listed in this document do not include Microsoft Exchange 2000 Conferencing Server release notes.
Immediately before and after upgrading your servers to Exchange 2000 Service Pack 2, you should make a full backup of your servers. Making this backup will ensure that you have a valid backup of your servers should you require one. This is considered a best practice for all upgrades.
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 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 upgrading 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, all front-end servers must be upgraded before any back-end servers are upgraded.
Exchange 2000 SP2 includes the SMTP Reinstall tool (Smtpreinstall.exe), which is available in the Support Tools directory on the Exchange SP2 compact disc. Use this 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, the SMTP Reinstall tool cannot be used on a cluster running Exchange 2000. If you try to run the tool, you will encounter issues that block 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, completely reinstall Exchange and any previously applied Exchange service packs after you reinstall the SMTP service.
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, set general properties on the Server object from Exchange System Manager.
For more information, see the following white paper:
If you perform a two-step Exchange migration using the Exchange Migration Wizard, and the Outlook folder language is different from the user locale of the server running 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 the folder is created for the language used by Outlook, and another copy of the 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.
Support continues for user interface in Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English, French, Finnish, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese (Portugal), Portuguese (Brazilian), Russian, Spanish, Swedish, and Turkish. Added support for Catalan.
Contact Distribution Lists
Log Off Page
Segmentation
New and Improved for Internet Explorer 5 and Later
Please refer to server documentation for addition details about these items.
If a user logs on to Outlook Web Access from Internet Explorer 5.5, goes to his or her calendar, and clicks Print on the toolbar, an error occurs. To fix this problem, users must upgrade their browsers to Internet Explorer 5.5 SP2.
Using Outlook Web Access while logging off from a front-end server running Exchange SP2 may result in an incomplete logoff attempt. For example, clicking Log Off in Outlook Web Access may result in a request to type your network identification and password. However, typing valid network credentials will not log you off the server. You must disable Integrated Windows Authentication for the front-end server using Internet Services Manager to completely log off using the Outlook Web Access client.
To allow an Outlook Web Access client to log off from a front-end server running Exchange SP2
When accessing the pages used to log off or download the Unified Messaging controls in Outlook Web Access, you may receive an HTTP 500 error. Incorrect settings on the Exchweb\bin virtual directory cause this error. This error may occur on a front-end or back-end server.
To resolve these HTTP 500 errors
When you install Exchange 2000 Server Service Pack 2, 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 Service Pack 1, you must first uninstall the Service Pack 1 Help file updates before you can install the Outlook Web Access Service Pack 2 Help file updates. To remove Service Pack 1 Help, in Control Panel, double-click Add/Remove Programs.
To manually update Outlook Web Access HelpIf you already installed Service Pack 2, you can also access these language packs by going to <drive>:\Program Files\Exchsrvr\exchweb.
In Exchange SP2, right-click a server, click Properties, and then use the new Directory Access tab to view and configure Directory Access information for any server running Exchange SP2 in your topology. You can add or remove servers to the topology list for Exchange SP2 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, and you cannot manually configure the servers because Add and Remove are not available.
After you upgrade to Exchange SP2, 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, 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 then 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 SP2 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, using the Directory Access Tab you must 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, the Directory Access display is new and the Message Tracking Center functionality is updated. When you install Exchange SP2, a new Microsoft Exchange Management Service used by both of these features is automatically installed and started.
To use the new Directory Access display, the server that you want to configure in the Directory Access tab must also be running Exchange SP2. If the service is not running on a server running Exchange SP2, the Directory Access tab will not display information about 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.
To use the updated Message Tracking functionality, the server or workstation running Exchange System Manager from SP2 must be running the Microsoft Exchange Management Service, as well as all SP2 servers in order to provide message tracking information to the Message Tracking Center. Also, the more servers that are also running the service, the better your tracking performance results will be. For administrator-only installations, the service must be running on the workstation. After you install Exchange SP2, 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 SP2, he or she is able to track e-mail on any server that does not yet have SP2 installed; however, the message tracking takes longer to search on non-SP2 servers than on SP2 servers.
If you manually created Directory Access profiles in the registry before you upgraded to Exchange SP2, the profiles are preserved after you upgrade. The servers that were manually configured through the profiles also appear in System Manager. To view the Directory Access properties of these servers in System Manager, right-click on the server, click Properties, and then click the new Directory Access tab.
If an invalid entry in the profile exists, or if a server is invalid, after you upgrade to Exchange SP2 and access the Directory Access tab, the following message appears: "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 System Manager, 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 due to time zone differences or daylight savings differences. Changing the system time after message delivery does not correct this problem, but it does prevent it 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 the 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 roles listed above. In SP2, Message Tracking Center will check 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 he or she needs to track e-mail messages on. This new security measure also 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 granted them Exchange Administrator or Exchange Full Administrator rights, they would 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, and they would also have permission to track e-mail.
It is strongly recommended that you use the Check Pointing script provided with Exchange SP2 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 generate 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