Microsoft KB Archive/156063
Article ID: 156063
Article Last Modified on 10/28/2006
- Microsoft Exchange Server 5.0 Standard Edition
This article was previously published under Q156063
NOTE: As of 1/28/98, Quarterdeck Mail became StarNine Mail.
The following is the Readme.wri file from the version 5.0 Microsoft Exchange Server compact disc.
Microsoft Exchange Server Version 5.0 Release Notes Copyright (c) Microsoft Corp. 1997 Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation. (c) 1985 - 1997 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, and Windows NT are registered trademarks, and BackOffice and Outlook are trademarks of Microsoft Corporation in the USA and other countries. All other companies and product names are trademarks or registered trademarks of their respective holders. About This Document This document contains information not available in the Microsoft Exchange Server documentation and information about changes that occurred after publication. Viewing This Document This file is best viewed using Write version 3.51. Contents 1.0 Installing Microsoft Exchange Server Version 5.0 1.1 Setup Requirements 1.2 Upgrading to Microsoft Exchange Server 5.0 1.3 Installing a Microsoft Exchange Server 4.0 into a Microsoft Exchange Server Site After Microsoft Exchange Server 5.0 Has Been Installed 1.4 Running Microsoft Exchange Server Setup and Server Monitor 1.5 Upgrading the Key Management Server to Microsoft Exchange Server 5.0 1.6 Installing the Internet Mail Service 1.7 Upgrading Active Server Pages from Beta 1 or RC1 1.8 Installing Anonymous Postings 1.9 Internet Mail Routing Information Not Transferred During Upgrade 1.10 Link Monitors 2.0 Changes in Microsoft Exchange Server 5.0 2.1 General Server Notes 2.2 Internet Mail Service (Formerly Internet Mail Connector) 2.3 Internet News Service 2.4 Administrator Program 2.5 Microsoft Exchange Active Server Components 2.6 Microsoft Exchange Connector for Lotus cc:Mail 2.7 Internet Protocol Support 2.8 POP3 Clients 2.9 Known Issues with the Internet Mail Service and Internet News Service 2.10 Banyan VINES Configuration 2.11 Address Book Views 3.0 Connectors 3.1 Microsoft Mail Connector 3.2 Internet Mail Service 3.3 Dynamic RAS Connector 4.0 Backup and Restore 4.1 Ntbackup.exe: Windows NT Server 3.51, Service Pack 5 4.2 Restoring the Public or Private Information Store on a Different Server 4.3 Restoring the Information Store to an Alternate Server 4.4 Command Line Limit for Backup Batch Processes 5.0 Migration 5.1 Character Mismatching with Some Code Pages 5.2 Backslash Characters in Directory Sections of Migration Files 5.3 MS Mail (PC): Using SUBST Drive When Migrating from MS Mail (PC) 5.4 MS Mail (PC): Invalid Server Specified During Microsoft Mail (PC) Postoffice Migration 5.5 MS Mail (PC): International Issues with Code Pages and MS Mail Postoffices 5.6 Running Lotus cc:Mail and Novell GroupWise Migration on Intel Processors Gives Best Performance 5.7 cc:Mail Migration 5.8 Collabra Migration 5.9 GroupWise Migration 5.10 PROFS Migration 6.0 International Issues 6.1 Far East Languages Not Supported for LDAP 6.2 Installing Foreign Language Display Templates 6.3 Microsoft Exchange Server and Windows NT Server Languages Must Match to Use Performance Monitor Counters 6.4 Considerations for French Canadian Customers 6.5 Maintaining Index Consistency 7.0 Directory and Information Store 7.1 Running Directory Import and Export in Raw Mode 7.2 Additional Columns for Private and Public Information Stores 7.3 Command Line Directory Import and Export Parameters 7.4 Directory Import/Export: New Quoting Behavior for Multivalued Attributes 7.5 Size of Information Store 8.0 Corrections to Documentation 8.1 What's New 8.2 Microsoft Exchange Server Administrator's Guide 8.3 Microsoft Exchange Server Installation Guide 8.4 Microsoft Exchange Server Concepts and Planning Guide 8.5 Web Access Help 8.6 Administrator Program Help 1.0 Installing Microsoft Exchange Server Version 5.0 ----------------------------------------------------- 1.1 Setup Requirements 1.1.1 Microsoft Windows NT Service Pack 3 Recommended Microsoft Exchange Server version 5.0 requires either Windows NT 3.51 Service Pack (SP) 5 or Windows NT Server 4.0 SP2; however, it is strongly recommended that you run Windows NT Server version 4.0 SP3. Web access to Microsoft Exchange supports only Windows NT Server version 4.0 SP2 or higher. NOTE: For information about installing and logging on to Web access, see sections 2.5.3 and 2.5.6, respectively. The following are known issues with Windows NT Server version 4.0 SP2 that may cause either Windows NT Server or Microsoft Exchange Server to malfunction: - The Dynamic RAS Connector cannot connect to other Microsoft Exchange Server sites. For additional information, see section 3.3.5. - Running the Internet News Service with a full newsfeed may cause Afd.sys to crash, resulting in a Windows NT blue screen. Windows NT 4.0 SP3 includes fixes for both of these issues. You can download Microsoft Windows NT 4.0 SP3 from the Microsoft Web Server (http://www.microsoft.com), or you can transfer it from ftp.microsoft.com. Another option is to order SP3 on compact disc by contacting the Microsoft Order Desk in the U.S. at (800) 360-7561 between 6:30 A.M. and 5:30 P.M., Pacific time. To download Service Pack 3, select Support Drivers, Patches & Service Packs, and then select Windows NT Service Packs. Select the appropriate Windows NT 4.0 service pack for your processor. 1.1.2 Windows NT Service Packs Must Be Installed on Primary Domain Controller If you are running Microsoft Exchange Server and install a Windows NT Service Pack on that computer, you must also install the service pack on the Windows NT primary domain controller. 1.2 Upgrading to Microsoft Exchange Server 5.0 When Setup starts, it checks for any Microsoft Exchange Server components installed on your computer. Previous versions are detected when Setup connects to the directory and reads the version on every Microsoft Exchange Server computer in the site. It also detects the language and server type. You can determine the version of a Microsoft Exchange Server by viewing the properties on the server object in the Administrator window. When you are planning your upgrade, it will take one hour for each gigabyte (GB) of directory data converted to the new schema. It will take 30 minutes for each GB of information store data converted to the new store format. Recommended Upgrade Procedure Due to directory schema changes between versions 4.0 and 5.0, it is recommended you first upgrade all Microsoft Exchange Server sites to version 4.0, Service Pack 2 (SP2). Once you have upgraded all servers in the site to SP2, you can then upgrade them to version 5.0 in any order. NOTE: In a single server site, you can upgrade to version 5.0 directly from version 4.0. You do not have to upgrade to SP2. You do not have to restart the services after an upgrade. You can download Microsoft Exchange Server SP2 from the Microsoft Web Server (http://www.microsoft.com), or you can transfer it from ftp.microsoft.com. Another option is to order SP2 on compact disc by contacting the Microsoft Order Desk in the U.S. at (800) 360-7561 between 6:30 A.M. and 5:30 P.M., Pacific time. Alternate Upgrade Procedure If you cannot upgrade your servers to SP2 first, it is strongly recommended that you first upgrade any directory replication bridgehead servers in the site to version 5.0. A directory replication bridgehead server is a server connected to another site using the directory replication connector. You must upgrade one server and allow the changes to replicate throughout the site. This can take from a few minutes to an hour, depending on the number of servers in your site. To determine which servers are directory replication bridgehead servers, view the General property page of each directory replication connector in the site. They are located in the Directory Replication container under the Site container in the Administrator window. If you have more than one directory replication bridgehead server in your site, you should upgrade all of them to version 5.0. IMPORTANT: If you do not upgrade your directory replication bridgehead servers first, directory replication stops and won't restart until you upgrade these bridgehead servers. After you install version 5.0 on the first server in the site, restart all computers running Microsoft Exchange Server 4.0 in that site after the new directory is replicated. This can take from a few minutes to an hour, depending upon the number of servers in your organization. 1.3 Installing a Microsoft Exchange Server 4.0 into a Microsoft Exchange Server Site After Microsoft Exchange Server 5.0 Has Been Installed When Microsoft Exchange Server is installed into an existing site of Microsoft Exchange Server computers, it reads information from all other servers within that site and builds databases (such as the directory). New features added to Microsoft Exchange Server 5.0 require an updated set of database schemas. When a Microsoft Exchange Server 5.0 is installed in a Microsoft Exchange Server 4.0 site, the schema is updated to version 5.0. The directory in version 4.0 did not allow installation in a site where the schema was different from the default. To install a new version 4.0 server to a site after version 5.0 has been installed, use the following procedure to create a setup point from which you can install any new Microsoft Exchange Server 4.0 computers to your site. Be sure you have 120 MB of free disk space on each computer. 1. Place the Microsoft Exchange Server 4.0 compact disc into your CD-ROM drive. 2. Copy the contents, including all subdirectories, in the Setup\<platform> directory on the version 4.0 compact disc to a directory named 40Setup. 3. Place the Microsoft Exchange Server 5.0 compact disc into your CD-ROM drive. 4. Copy the contents of the Support\Exch40\<platform> directory to the 40Setup directory. 5. Click Yes to overwrite the files. 6. Run Setup.exe in the \40Setup directory to add a new server to the site. 1.4 Running Microsoft Exchange Server Setup and Server Monitor Before upgrading a Microsoft Exchange Server computer, turn off all server monitors that include the computer on which Setup is being run. Alternatively, you can use the Maintenance Status property page in the Administrator program to put the server monitor into maintenance mode. 1.5 Upgrading the Key Management Server to Microsoft Exchange Server 5.0 Because the Key Management server (KM server) is installed using a separate Setup program, it must also be upgraded in a similar fashion. The upgrade needs to be performed only on the original KM server computer; you do not need to upgrade other sites that were previously configured to use this KM server. To upgrade a version 4.0 KM server to version 5.0: 1. Back up the advanced security data on the Microsoft Exchange Server computer that hosts the KM server. See "Backing Up and Restoring Advanced Security Data" in the Microsoft Exchange Server Administrator's Guide. 2. Run the KM server Setup program, which is on the Microsoft Exchange Server 5.0 compact disc in the \Exchkm directory. 3. If Setup detects a previous installation of KM server, it asks if you want to replace the existing version with the new version. Click OK to continue. Any existing advanced security data is preserved during the upgrade. A dialog box with the following message confirms this. The Microsoft Exchange Key Manager database exists on C:\<directory>. Back up this directory using Windows NT Backup. The database will be preserved by the installation process. 4. Click OK. 5. Click Typical to continue with Setup. When Setup is finished, click OK. 6. Place the original KM server startup disk (from the original installation of the KM server) into the A drive and start the Microsoft Key Management Service. If you originally chose to use a password, type the original password in the Startup Parameters box of the Services application in Control Panel. 1.6 Installing the Internet Mail Service The Internet Mail Service is now a wizard and is not part of the Setup program. To install the Internet Mail Service, On the File menu in the Administrator window, click New Other, and then click Internet Mail Service. 1.7 Upgrading Active Server Pages from Beta 1 or RC1 If you previously installed the Beta 1 or RC1 version of the Active Server Pages, you must use the respective Setup program to remove the previous installation before upgrading to Microsoft Exchange Server 5.0 Active Server Pages. 1.8 Installing Anonymous Postings Use the following procedure to create a mailbox for installing the sample application called Anonymous Postings: 1. Using the Microsoft Exchange Server Administrator program, create a mailbox named Anonymous. 2. Set the primary Windows NT account for the mailbox to the Windows NT user account named Anonymous. 3. Using the Permissions property page for the site object that contains the Anonymous mailbox, grant Administrator permissions to the Windows NT account referenced in step 2. Currently, Anonymous needs Administrator permissions in the Microsoft Exchange Server organization. 4. With the Administrator program running, make a note of the following configuration settings. Organization Name: The text next to the upper-most object in the graphical directory tree. Home Site: Located in the General property page for the mailbox. Directory Name: Located in the Advanced property page for the mailbox. 1.9 Internet Mail Routing Information Not Transferred During Upgrade If you have a specific routing set up before upgrading, the routing information is not transferred from the registry to the directory. To reset routing information: 1. Locate the path for the ExtensionDLL parameter under the following registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIMC\ Parameters 2. In the Administrator window, click the Configuration container for the site, and then click Connections. 3. Double-click the Internet Mail Service. 4. On the File menu, click Properties, and then select the Routing tab. 5. Select Instead of the table, use this custom routing program, and type the path from the ExtensionDLL parameter. 1.10 Link Monitors When you set up link monitors, a non-existent custom recipient that the link monitor can send to is specified. The link monitor uses this recipient to determine if the link is active by sending a message to the recipient and waiting for a non-delivery report (NDR) from the target server. If a custom recipient that matches this non-existent custom recipient is created on the target server, the link monitor does not receive an NDR and reports that the link is unavailable. 2.0 Changes in Microsoft Exchange Server 5.0 --------------------------------------------- 2.1 General Server Notes 2.1.1 Using Advanced Security in France Microsoft Exchange Server includes the Key Management server (KM server) component, which enables secure messaging and key management for Microsoft Exchange Server. French law (Decree 92-1358 of December 1992) generally prohibits the use of such technology in France unless special approvals are granted. This law applies to any software product providing information security. Microsoft Exchange Server has been modified to prevent installation of the KM server component on servers in France. Microsoft has also disabled the property page in the Microsoft Exchange Server Administrator program that is used to enable security. At this time, the KM server component should not be installed on computers in France. 2.1.2 Not All Microsoft Exchange Active Server Components Templates Are Installed with Microsoft Exchange Server The Microsoft Exchange Server languages and their corresponding Microsoft Exchange Active Server components templates are as follows. Server Template -------------------- English English French English, French German English, German Japanese English, Japanese 2.1.3 Localized Microsoft Exchange Active Server Components Templates Localized templates for many languages will be available as language packs with the localized Microsoft Exchange Client in those languages. They will also be posted to http://www.microsoft.com. After installing a language pack, the Web Publishing Service must be stopped and restarted to make the new language scripts available. 2.1.4 Selecting Which Microsoft Exchange Active Server Components Templates to Use Microsoft Exchange Active Server components automatically determine the template language based on the browser's HTTP Accept-Language property. Microsoft Internet Explorer 3.0 links its Accept-Language property to the Regional Settings application in Control Panel. Users running Netscape Navigator 3.0 can manually set its Accept-Language property by choosing General Preferences On the Options menu and then choosing Language. Templates are not selected based on the browser language, operating system language, or server language. 2.1.5 Viewing Messages in a Foreign Code Page To view messages in a foreign code page (a code page other than the Active Server code page), users must change their browser's code page. 2.1.6 Template Language and the Language of the Message Content Don't Match If the language of the template and the language of the message content don't match, the message content may appear corrupt if the message content requires a different code page and font from the template. If this occurs, the user should manually change the browser's code page to view the message content correctly. For Microsoft Internet Explorer 3.0, click the code page shortcut menu in the right corner of the status bar and select the correct code page. For Netscape Navigator 3.0, click Document Encoding on the Options menu, and then select the correct code page. 2.1.7 Microsoft Outlook 97 Client The English Outlook client is included with this release; localized versions of Outlook are not provided. 2.1.8 Automatically Creating Profiles for Non-English Outlook Clients You can automatically create a default profile for Outlook clients to connect to a Microsoft Exchange Server computer. To configure default profiles for non-English installations of the Outlook client: 1. Create a network share for installing Outlook from a network server. 2. Rename the file called Outlook.prf to Outlook.prf.old. This file is located in the Office directory of the network share. 3. Rename the file called Exchange.prf to Outlook.prf. This file is located in the Office directory of the network share. 4. Edit the HomeServer= setting in the Outlook.prf file to provide the name of a Microsoft Exchange Server computer in your site. This server does not need to be the user's mailbox server. NOTE: If Outlook and the original Outlook.prf file have already been installed on a user's computer, replace the original Outlook.prf file in the Windows directory with the new Outlook.prf file. The new file automatically creates a profile that enables the Outlook client to connect to a Microsoft Exchange Server computer. 2.1.9 Enabling Outlook Automatic Upgrade If you use a shared installation point for Outlook clients you can enable the automatic upgrade feature by adding the following line to the end of the Outlook.srg file in the \Program files\Microsoft Office\Office directory: [HKEY_LOCAL_MACHINE\software\microsoft\office\8.0\outlook\upgradepath] "serverpath" = "<\\\\server\\share\\subdir>" NOTE: Do not add a trailing backslash. All backslashes must be doubled. 2.1.10 Other Issues Cannot Delete Private Information Store The private information store cannot be deleted from a Microsoft Exchange Server. The server now depends on the private information store to send and receive directory replication messages between sites. Microsoft Exchange Server Administrators Need Local Computer Administrator Rights Many operations done by the Administrator program require it to write both to the Microsoft Exchange Server directory and the Windows NT registry of the target server. Windows NT 4.0 requires that users have administrator rights on servers to access the registry. Previous versions of Windows NT did not impose this restriction. Installing Windows NT 4.0 Service Pack 3 alleviates this problem. To guarantee successful completion of tasks in the Administrator program on previous versions of Windows NT 4.0, users should have Administrator permissions on the Microsoft Exchange Server directory objects they need to change and Windows NT administrator rights on target servers. Remotely installing new services, such as the Internet Mail Service or the Internet News Service, requires Windows NT administrator rights on all versions of Windows NT. Directory Names with Commas Are Unacceptable to the Key Management Server It is possible to create a mailbox with a comma in its directory name using a comma in the Alias box. If you then try to enable advanced security for the mailbox, the KM server returns an error, and the operation fails. Deleting the mailbox and re-creating it without commas in the Alias box solves the problem. DBCS Characters Are Not Accepted In Database Paths Attempts to declare server database paths that include DBCS characters will be rejected. Converting DBCS Display and Attachment Names If you are connecting two Microsoft Exchange Server sites with an X.400 Connector and the sites are not configured for directory replication, double-byte character set (DBCS) display names and attachment names on messages sent between the sites are not converted properly. Public Folder Propagation-Only Support Replaces Client Permissions When client permissions are propagated through a public folder subtree, the new client permissions list is copied exactly from the parent folder to each subfolder, replacing any previously defined client permissions. Cannot Delete More Than One Server at a Time If more than one server is selected to be deleted, the first server appears to have been deleted successfully, but the Administrator program stops responding immediately after the completion dialog box is closed. Cannot Enter Escape Characters When Creating/Editing SMTP E-mail Addresses When creating or modifying an SMTP e-mail address using the Administrator program, escape characters cannot be used. Microsoft Mail (PC) SMTP Gateway Access Component Available on Microsoft Exchange Server Version 5.0 Compact Disc The Microsoft Mail (PC) SMTP gateway access component is located on the Microsoft Exchange Server version 5.0 compact disc in the Support\Msmail\Smtp directory. It can be used only with Microsoft Exchange Server version 5.0. The access component must be used in conformance with the Microsoft software license agreement when being used on an MS Mail (PC) postoffice. To install the Microsoft Mail (PC) SMTP gateway access component on a Microsoft Mail(PC) postoffice, run Install.exe. The installation program prompts you for the location of the MS Mail (PC) postoffice through which mail will be forwarded. 1. At the "Enter drive/path to the Microsoft Mail data files" prompt, type the drive and path to the MS Mail (PC) postoffice database. 2. At the "Enter network name" prompt, type the network name of the upstream postofffice or Microsoft Exchange Server computer. 3. At the "Enter postoffice name" prompt, type the postoffice name of the upstream postoffice or Microsoft Exchange Server computer. When the installation is complete, you receive the following message: The installation is successful. If there is a hub postoffice between the downstream postoffice and the Microsoft Exchange Server computer running the Internet Mail Service, type the network and postoffice names for the intermediate postoffice at the installation prompts. 2.2 Internet Mail Service (Formerly Internet Mail Connector) 2.2.1 Internet Mail Service Wizard To access the Internet Mail Service Wizard, on the File menu in the Administrator window, click New Other, and then click Internet Mail Service. 2.2.2 Configuring POP3 Rerouting By default, the Internet Mail Service is configured to reroute all messages except for messages addressed to the domain specified in the SMTP entry on the Site Addressing property page of the Site Addressing object in the site's Configuration container. If your Internet Mail Service is responsible for delivering messages inbound to Microsoft Exchange Server for domains other than the domain specified in the Site Addressing object, you must add these domains to the Routing property page on the Internet Mail Service object. If you do not add these additional domains, mail may be rerouted through the Internet Mail Service several times and finally generate a non-delivery report (NDR) without being delivered inbound to Microsoft Exchange Server. This results in performance degradation and mail non-delivery. For an explanation of routing configurations, see "Routing Properties" in Chapter 10 of What's New. It is strongly recommended that you review this information if you are servicing POP3 clients or multiple SMTP domains and subdomains. 2.2.3 POP3 Clients and SMTP Simultaneous Connections If you have a server supporting POP3 clients, you may need to increase the maximum number of simultaneous simple mail transport protocol (SMTP) connections on the server. POP3 clients need to create an SMTP connection to the Internet Mail Service to send mail, but the number of simultaneous connections required varies based on the number and type of POP3 clients. If you are installing a new Internet Mail Service and not upgrading from a previous version, the maximum number of inbound connections is set to 30; otherwise, it is set to 20. If you are upgrading from Microsoft Exchange Server version 4.0 and are supporting a heavy load of POP3 client users, you should increase this setting to 30; otherwise, it will remain at 20 after an upgrade. To access the Inbound Connections option, click Advanced in the Connections property page of the Internet Mail Service. 2.2.4 Run Performance Optimizer After Internet Mail Service Installation It is recommended that you run the Performance Optimizer after installing the Internet Mail Service, even if you ran it before installing the Internet Mail Service. The Performance Optimizer is available in Exchsrvr\Bin\Perfwiz.exe. 2.2.5 Use Forward All Messages to Host When Using a Dial-up Connection with the Outbound Mail Queued for x Minutes Option If you are using the If Outbound Mail Queued for x minutes option in the Dial-up Connections property page, you must use the Forward all messages to host option in the Connections property page, or outbound mail will never be delivered. 2.2.6 Event ID 4057 If the Internet Mail Service generates event ID 4057 in the event log that indicates a routing lookup failure, verify that your DNS server is functioning properly. You should also verify that your DNS database and/or Hosts file are properly configured. 2.2.7 Feature Shown in What's New Not Implemented The Show in Each Message Whether That Message Came On the Internet option shown and described in Chapter 10 of What's New was removed from the product and is not supported in this release. 2.2.8 Do Not Use a Windows NT User Account with a Blank Password Security provided by the encryption feature of the Internet Mail Service may be weakened if the Windows NT user account you specify in the Security property page of the Internet Mail Service has a blank password (for example, encryption may fail if you use the built-in system account). You should use a user account with a non-blank password to ensure the strongest encryption over outbound connections. 2.2.9 Do Not Include an At Sign (@) in the Routing Address if Using the Internet Mail Service to Route Other Address Types If you route other address types through an Internet Mail Service (for example, by including an MS Mail type in the Internet Mail Service address space), do not prefix the SMTP routing address in the Routing Address property page of the address space entry with an at sign (@). If you do, mail to this address type is not routed. This also applies if you are using the Internet Mail Service as a site connector. When you add the entry for the site in the Connected Sites property page, do not prefix the routing address with an at sign (@). 2.2.10 Mail Addressed to X.400 Addresses is Not Transferred Across Non- Replicated Sites Connected by the Internet Mail Service If you are connecting two sites using an Internet Mail Service in each site without replicating their directories, mail sent to one-off X.400 addresses from one site is not transferred to the other site. This is true even if you have configured an X.400 address space on the Internet Mail Service in the first site with a routing address to the second site's Internet Mail Service. 2.2.11 If Outbound Mail Queued for x Min Option in the Dial-up Connections Property Page The If Outbound Mail Queued For X Min option in the Dial-up Connections property page of the Internet Mail Service indicates that if mail destined for outbound transfer arrives at the Internet Mail Service and a dial-up connection was not made for at least x minutes, the connection will be made and all outbound mail will be transferred. If x minutes has not passed, the mail will be transferred after this much time has passed. If this setting is used, connections will never be made less than x minutes apart. 2.2.12 20-Character Limit for Dial-up Connection Names Windows NT version 4.0 allows dial-up connection names up to 256 characters in length. However, the Internet Mail Service fails to dial out to any connections with names longer than 20 characters. 2.2.13 Using Multiple Dial-up Connections If you have multiple dial-up connections defined on your server and have selected the check boxes next to them in the Dial-up Connections property page, the Internet Mail Service dials each connection, even though only the connection selected in the Connections property page is used to transfer mail. 2.2.14 Relayed Delivery Reports Returned from Hosts Supporting DSN The Internet Mail Service does not generate a relayed delivery receipt when delivering messages to an SMTP host that does not support delivery status notifications (DSNs). For example, if a message with the NOTIFY parameter set to the value SUCCESS is delivered to an SMTP host not supporting DSN, the Internet Mail Service does not return a relayed delivery receipt to the sender. 2.2.15 DSN RET=HDRS Returns the Entire Message In RFC 1891, Delivery Status Notification (DSN) is defined as supporting a RET keyword. This keyword indicates whether notifications for delivery failure return the entire contents of a message or only the message headers. The Internet Mail Service always returns the full message, regardless of this keyword. 2.2.16 Delete Button in the Queues Property Page Is Not Functional When the Inbound messages awaiting conversion queue is selected in the Internet Mail Service Queues property page, the Delete button does not function. The IMCSAVE utility, found in the Support directory on the Microsoft Exchange Server compact disc, can be used to delete messages from this queue. 2.2.17 Setting Character Sets on Outbound MIME and non-MIME Messages In the Internet Mail property page, the Send Attachments Using setting applies to outbound messages. Under Character Set Translation, the MIME selection refers to outbound and inbound if the MIME message does not specify a character set. The Non-MIME selection refers to both inbound and outbound messages. For inbound MIME messages, the character set is specified in the message. For outbound MIME messages, the MIME character set setting is used only if the code page the message was composed in can map to more than one character set. For non-MIME messages, the non-MIME character set specified is always used. The setting is applied to a message regardless of the original character set the message was composed in. Remote hosts need to have the same character settings to receive messages correctly for both inbound and outbound mail. If you previously used the registry values ISO-8859-1, DefaultUseSJIS, or NonMacCreatorTypes to alter inbound character sets, these values are now located in a new key. The former key was: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIMC\ Parameters The new key is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ ParametersSystem\InternetContent Microsoft Exchange Server Setup automatically relocates these values to the new key. 2.2.18 Disable Guest Windows NT Account on Server Running the Internet Mail Service If you specify a Windows NT account that is not valid in the Security property page of the Internet Mail Service (for example, an incorrect domain is specified) the destination Windows NT Server will default to use the built-in Guest account if it is enabled on that server. This will cause the SMTP session to fail and be retried until it results in a time-out non- delivery report to the sender (the default time-out is 48 hours). Disabling the Guest account on the server of the destination Internet Mail Service will eliminate this problem because the session will fail and messages will be immediately non-delivered, alerting the administrator to reconfigure the specified account. This problem is more likely to occur on Windows NT Server 3.51 because the Guest account is enabled by default. On Windows NT Server 4.0, the Guest account is disabled by default. 2.3 Internet News Service 2.3.1 Certain Security Protocols for NNTP Connections to Peer Servers Are Not Supported Microsoft Exchange Server 5.0 does not support Windows NT Challenge/Response authentication or Secure Sockets Layer (SSL) for NNTP connections initiated to other peer servers. However, these security features are supported for connections received from NNTP clients or peer servers. 2.3.2 Changing the NNTP Port The services file, located in %SystemRoot%\system32\drivers\etc. contains a list of well-known port numbers for TCP/IP services. Microsoft Exchange Server uses the services file to determine which TCP port is used for accepting or initiating NNTP connections. For connections using SSL, the port number associated with the snews service is used; for all other connections, the port number associated with the nntp service is used. To change the port number used by the server, edit the services file and change the port number associated with these services. The default port numbers for the snews and nntp services are 563 and 119, respectively. You can also force the Internet News Service to connect to a specific port number when making an outbound connection for a newsfeed. This is useful when traversing a firewall that can map port numbers to different destination hosts on the Internet. To specify the port number for outbound connections, create the following REG_DWORD registry value after you have created the newsfeed and set it to a value between 1 and 65535. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeINS\ Parameters\Newsfeeds\<newsfeed-name>\PortNumber The <newsfeed-name> should be replaced with the name of the newsfeed you want to customize. If this registry value exists, it overrides the value in the services file for any outbound NNTP connections for that newsfeed. It does not affect the port number used for accepting inbound NNTP connections. That is always obtained from the services file. If you plan to specify a custom NNTP port, you may not be able to download the active newsgroup list from your news provider with the Newsfeed Configuration Wizard because the registry value does not exist at that point. Instead, you should import it from a file or download the active file after you have set the registry value. 2.3.3 Setting Up Moderators for Newsgroup Public Folders Created with RC1 Servers The RC1 version of Microsoft Exchange Server did not set up moderators on moderated newsgroups when newsgroup public folders were created. If you have newsgroup public folders that were created with an RC1 server, you can set up moderator addresses using the Administrator program. To set up moderator addresses: 1. In the Inbound property page of the newsfeed properties, click Create Newsgroups. 2. Select the moderated folders, and click OK. This adds a moderator rule to any moderated folder that does not specify a moderator. 2.3.4 Customizing the Default Moderator Address for a Moderated Newsgroup Public Folder When a moderated newsgroup public folder is created, the default moderator address is determined by rules specified in the Moderatr.txt file, which is located in the Exchsrvr\Add-ins\Ins directory. You can customize the default moderator address by editing the rules in this file using a text editor such as Notepad. Each entry in the Moderatr.txt file is the SMTP address of the newsgroup moderator in the format newsgroup:address, where the newsgroup is a newsgroup name or a wildcard pattern that matches multiple names. The rules are processed from top to bottom, and the first match that is found is used. The special value "%s" in the address causes the newsgroup name to be substituted with all dots replaced by dashes. For example, the default rule in the moderator file is *:%firstname.lastname@example.org. The asterisk (*) matches all newsgroup names, and the %s substitutes the newsgroup name in the address. If a moderated newsgroup called foo.bar is created, the default moderator address is email@example.com. Once a newsgroup public folder has been created, the public folder owner can change the moderator address with the Microsoft Exchange Client or the Outlook client by editing the moderator rule in the folder properties. 2.3.5 Anonymous Access to Public Folders To allow anonymous access to public folders using NNTP, the Windows NT Guest account must exist on the Microsoft Exchange Server computer, although the account does not have to be enabled. This account is used for logging anonymous access with the license manager. 2.3.6 To Select a New Active File from Your Internet Service Provider, the Internet News Service Must Be Running When selecting a new active file for newsfeed configuration, the Internet News Service must be running if the active file is downloaded from your Internet service provider. 2.3.7 Replication Conflicts When Configuring Multiple Newsfeeds on Multiple Servers To avoid public folder replication conflicts, do not configure multiple newsfeeds on more than one Microsoft Exchange Server computer at the same time. You should wait until changes made on one server are replicated to the other servers before configuring additional newsfeeds. 2.3.8 Default Character Set for Newsgroup Public Folders The default character set for newsgroup public folders is US-ASCII. For international newsgroups, you should select appropriate character sets. You can change the character set in the Administrator program in the NNTP property pages for the public folder. You can also set it recursively to change the character set for an entire newsgroup hierarchy in one operation. However, this operation is not possible from the Internet Newgroups public folder. 2.3.9 Updating Newsgroup Lists When Upgrading from RC1 to Microsoft Exchange Server 5.0 If you are upgrading from RC1 to Microsoft Exchange Server version 5.0, you must refresh your newsgroup lists in your newsfeeds before you can administer your newsfeed subscriptions. This is due to a change in the format in which the data is stored. Once you download a new list of newsgroups or import one from a file, you can administer your newsfeed. 2.3.10 Disabling Support for Pull Newsfeeds A large number of NNTP pull newsfeeds can create a significant amount of overhead on your Microsoft Exchange Server computer, which slows response times for other operations such as servicing NNTP newsreader clients. If you have a Microsoft Exchange Server computer configured to support NNTP newsreaders and you would like to disable support for pull newsfeeds, create the following DWORD registry value and set the value to 1: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ ParametersSystem\NNTP NewNews Disabled This can be useful in cases where your computer is freely accessible on your intranet or the Internet and you do not want people to pull newsfeeds from your server. 2.3.11 Catching Up to Current Newsfeeds After you set up an outbound newsfeed, the server sends every message in the newsgroup public folder that is included in the newsfeed to the other host. This can result in a large amount of traffic and a delay until the other server catches up with the backlog of messages. If you do not want to backfill all existing messages to the remote host, select Mark all as delivered in the Advanced property page of the newsfeed properties. After you set up an inbound pull newsfeed, the server downloads only the messages from the previous seven days. If you do not want to backfill any messages, you can select Mark all as delivered, as described above. To retrieve more than the seven previous days' messages, you can use the INSTIMES tool that is included in the Support\Utils directory on the Microsoft Exchange Server compact disc to adjust the amount of backfill. Run this tool on the computer that is hosting the newsfeed, and set the last download date as far back as you would like to backfill. The next time the Internet News Service makes a pull feed connection, it will backfill any messages posted at or after the selected date. 2.3.12 Minimizing the Impact of Replicating Large Numbers of Newsgroup Public Folders Every Microsoft Exchange Server computer maintains a copy of the public folder hierarchy information. Therefore, when public folders are created or deleted, replication messages are sent to the other servers in your organization to inform them of changes to the public folder hierarchy. If you plan to receive a large newsfeed with several thousands of newsgroups, you should consider doing a phased rollout of your newsgroup public folders by creating only a few thousand at a time. This helps to avoid the risk of overloading your network or servers with a sudden rush of public folder replication traffic generated when new public folders are created. It is particularly important to consider phased rollout if your topology includes slow connections to remote sites. The replication impact should also be considered when you bring up a new server in a site or establish a new site connection. The entire public folder hierarchy must be replicated to the new server. If you have a large public folder hierarchy, there may initially be a significant amount of public folder replication traffic between the servers until the new server's copy of the public folder hierarchy is up-to-date. You should also consider the replication impact if you create public folder replicas for a large number of existing public folders on another Microsoft Exchange Server computer. When you create a public folder replica on another server, Microsoft Exchange Server replicates the entire contents of the folder to the other server. If you have a large existing database of newsgroup messages, you may want to do a phased rollout of the folder replicas to avoid overloading your network or servers with a sudden rush of public folder replication traffic. To do a phased rollout, create folders or folder replicas for a few thousand newsgroups at a time. Use the replication performance counters available under MSExchangeIS Public in the Windows NT Performance Monitor to determine when the replication messages have been received by the other server(s). Once the replication message traffic has subsided, repeat the operation on the next set of folders. 2.3.13 Sessions Tuning The best default configuration for a Microsoft Exchange Server that is hosting NNTP newsgroups is to set it up as a public folder server using the Performance Optimizer. Under heavy NNTP client load, you may see occurrences of event 1165 in the Windows NT Event Viewer under MSExchangeIS Public. This event is a notification that the information store does not have enough database sessions for the threads in the store process that are servicing client requests. Whenever this occurs, performance will be adversely affected. If you see this event in the Event Viewer, you can tune the performance of the store by creating the following REG_DWORD value called Sessions in the Windows NT registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ ParametersPublic. The appropriate value for Sessions depends on the setting of the Max Threads and Background Threads registry values under the ParametersSystem key. Use the following calculation to determine an initial value for Sessions: Sessions = (((Max Threads * 3)/4 + Background Threads) * 3)/5 + 1 The default values if no registry entries exist are 20 for Max Threads and 25 for Background Threads. Once you have set a value for Sessions, restart the store. You may need to experiment by gradually increasing values for Sessions until event 1165 is no longer logged. Do not set Sessions to an arbitrarily large number because this will degrade store performance in other areas. You can also tune store performance by adjusting two other REG_DWORD registry values under the ParametersSystem key called Preferred Max Open Tables and Max Buffers. If the information store contains a large number of newsgroups, you can improve performance by increasing the value of Preferred Max Open Tables to reflect the number of newsgroups in the store. To avoid causing memory paging problems, an increase in Preferred Max Open Tables should be offset by a reduction in Max Buffers, using an 8:1 ratio. That is, for every increase in Preferred Max Open Tables by eight, you should decrease Max Buffers by one. The store requires multiple tables for each open folder, so the ideal setting for Preferred Max Open Tables may be higher than the number of newsgroups in the store. However, reducing Max Buffers significantly can have an adverse effect on performance. Therefore, some experimentation with different settings may be required to find the best configuration for your system. 2.3.14 Changing the USENET Site Name You can change the server's USENET site name by performing the following steps: 1. In the Administrator window, choose a server, and then click Protocols. 2. Double-click NNTP (News) Settings for the server. 3. Click the Newsfeeds tab. 4. In the USENET site name box, type the USENET site name. 2.3.15 NNTP Users May Require Increased Information Store Threads A server supporting a large number of NNTP clients may need to increase the maximum number of information store threads. NNTP clients create a connection to the information store to receive mail. The number of simultaneous connections required varies depending upon the number and type of NNTP clients. Consider that NNTP clients poll the server and are not always connected when estimating the number of simultaneous connections. The duration of the connection is the time required to download mail. NNTP clients receiving slow response from a server is an indicator for increasing information store threads. Information store threads can be increased without adversely affecting server performance. The information store will start more threads only if they are actually needed. To increase information store threads for NNTP clients: 1. Start Registry Editor, and then open the following registry keys: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ ParametersNetIf\MaxPoolThreads 2. Under Value data, type 100. 2.4 Administrator Program 2.4.1 Moving Mailboxes When moving mailboxes to a new server, the size of the mailbox contents on the destination server can increase. This is because individual copies of single-instance messages are created for each moved mailbox in the private information store on the destination server. 2.4.2 Custom Recipients Using Target Addresses That Are Different from the Primary Proxy The Microsoft Exchange Server 4.0 Administrator program did not allow the primary proxy and target addresses for custom recipients to be different. If you edit a custom recipient object with the version 5.0 Administrator program, make the addresses different, and subsequently open the custom recipient object in the version 4.0 Administrator program, the program may copy the target address to the primary proxy causing you to lose the distinction between the two addresses. 2.4.3 Moving the Key Management Server The instructions in the Microsoft Exchange Server Administrator's Guide on moving the KM server to another server in the same site are incorrect. Use these revised instructions to move an existing KM server to another server in the same site. NOTE: It is recommended that you do not move the KM server from one Microsoft Exchange Server computer to another because of the critical information kept in the KM server database. 1. Back up the advanced security data on the Microsoft Exchange Server computer that hosts the KM server. See "Backing Up and Restoring Advanced Security Data" in the Microsoft Exchange Server Administrator's Guide. 2. In Control Panel, click the Services icon, and stop the Microsoft Key Management Service. 3. Run the KM server Setup program, and click Remove All. This renames your Security directory to Security.bak and removes the KM server components. 4. Go to the Microsoft Exchange Server that will now host the KM server. 5. Run the KM server Setup program on the Microsoft Exchange Server compact disc in the \Exchkm directory. 6. In Control Panel, click the Services icon, and stop the Microsoft Key Management Service. 7. Restore the advanced security data on the server where you previously had the KM server. See "Backing Up and Restoring Advanced Security Data" in the Microsoft Exchange Server Administrator's Guide. 8. Place the original KM server disk (from the original installation of the KM server) into the A drive and start the Microsoft Key Management Service. 9. After allowing for replication to occur within your organization (this could take several hours depending on your topology), run the KM server Setup program on each of the other sites in your organization. The original KM server disk is needed because it contains the 64-bit encryption key for the database. Because the data that is being moved was created with this key, it needs to be present to issue and revoke certificates in the new location. If this disk is not used, new tokens must be issued for all users in the organization. The disk that is created during KM server Setup should be backed up and kept in a secure place in case the original is lost or damaged. 2.4.4 Members in Distribution Lists Are Exposed in Reports When a user sends to a distribution list located on a different home server, that user is not prevented from receiving read receipts, delivery reports, and non-delivery reports from individual distribution list members. Selecting the Report to message originator and Hide membership from address book options in the distribution list Advanced property page does not affect this behavior. Be especially careful when using the Hide membership from address book option because membership can be exposed when these reports are generated and user privacy is not guaranteed. 2.4.5 Report to Distribution List Owner Doesn't Work Between Sites If the Report to distribution list owner option in the Advanced property page of distribution list recipients is selected, the distribution list owner will receive any delivery or non-delivery reports and read receipts that the distribution list generates if they are requested by the sender. However, no reports are sent to the distribution list owner if a message to a distribution list is sent between sites or uses a connector. 2.5 Microsoft Exchange Active Server Components Microsoft Exchange Active Server components are included with Microsoft Exchange Server. They allow webmasters and developers to use Microsoft Exchange Server features in Web applications. The Web access application allows users to access e-mail and the Microsoft Exchange Server directory using Microsoft Internet Explorer version 3.0 or Netscape Navigator version 3.0. Authenticated users must have their mailboxes on a Microsoft Exchange Server version 5.0 to use Web access. NOTE: The Microsoft Internet Information Server (IIS) can be installed either on the same server as Microsoft Exchange Server or on a separate server. With a single-server installation, all types of authentication supported by IIS may be used. With a separate-server installation, only basic authentication may be used; Windows NT Challenge/Response authentication does not work. 2.5.1 Using Localized Versions of Microsoft Exchange Active Server Components Microsoft Exchange Active Server components must be installed on Windows NT Server version 4.0 Service Pack 2 or later. Service Pack 3 is strongly recommended. Localized versions of Microsoft Exchange Active Server components should be installed on localized versions of Windows NT and Active Server. To reduce hardware requirements, you can support additional languages on a single Active Server as long as the languages uses the same code page as the Active Server. For example, German and Danish (code page 1252) can co- exist on a computer running the French edition of Windows NT with Active Server using French regional settings (code page 1252). However, Polish (code page 1250) would require a separate Windows NT/Active Server with Polish regional settings (code page 1250). Use the following list of some of the languages supported by Microsoft Exchange Active Server components and their code pages to determine languages that can co-exist. 1252: English, German, French, Dutch, Danish, Swedish, Norwegian, Finnish, Italian, Spanish, Portuguese 1250: Polish, Czech, Hungarian 1251: Russian 1253: Greek 1254: Turkish 932: Japanese 950: Chinese (Traditional) 936: Chinese (Simplified) 949: Korean To change regional settings in Windows NT, use the Regional Settings application in Control Panel. A version of Active Server that supports Far East languages (Japanese, Korean, Chinese) is expected to be available around the same time as Far East versions of Microsoft Exchange Server 5.0. 2.5.2 Requirements The following are needed to perform this installation. - Microsoft Windows NT Server 4.0 compact disc. - Microsoft Exchange Server 5.0 compact disc. - Microsoft Windows NT 4.0 Service Pack (SP) 2 compact disc. You can download Microsoft Windows NT 4.0 SP2 from the Microsoft Web Server (http://www.microsoft.com), or you can transfer it from ftp.microsoft.com. Another option is to order SP2 on compact disc by contacting the Microsoft Order Desk in the U.S. at (800) 360-7561 between 6:30 A.M. and 5:30 P.M., Pacific time. To download Service Pack 2, select Support Drivers, Patches & Service Packs, and then select Windows NT Service Packs. Select the appropriate Windows NT 4.0 service pack for your processor. - A Web browser, such as Microsoft Internet Explorer 3.0 or Netscape Navigator 3.0. 2.5.3 Installation Complete the following procedures to install Microsoft Exchange Server for Web access. Installing Microsoft Windows NT Server and Microsoft Internet Information Server 1. Install Microsoft Windows NT Server 4.0. When prompted to install the Microsoft Internet Information Server 2.0, click Yes. 2. From the Service Pack 2 compact disc or the expanded subdirectory from the Service Pack 2 downloaded software, install Active Server Pages to update Microsoft Internet Information Server to version 3.0. The Active Server Pages Setup program (Apsetup.bat) is located in the Iis30\asp directory. 3. From the Microsoft Windows NT Service Pack 2 compact disc or the expanded subdirectory from the Service Pack 2 downloaded software, install the Service Pack 2 update. The Service Pack 2 Update program (Update.exe) is located in the \i386 directory. It is strongly recommended that you install Windows NT Server Service Pack 3. NOTE: Windows NT Challenge/Response authentication must be disabled on the Internet Information Server whenever IIS and Microsoft Exchange Server are on different computers. Installing Microsoft Exchange Server 1. Install Microsoft Exchange Server 5.0, and click Complete/Custom (not Typical). - If you are installing this server to function as a Microsoft Exchange Server, select the Microsoft Exchange Server, Microsoft Exchange Administrator, and Active Server Components check boxes. You can also install Books Online. - If you are installing this server to provide Web access to another Microsoft Exchange Server on the network, select only the Active Server Components check box. You must provide the name of the Microsoft Exchange Server. 2. Complete the Microsoft Exchange Server installation as described in the documentation. 2.5.4 Setting Up a Guest Account For anonymous access to public folders, a Guest account must be set up on the Internet Information Server. 1. On the Windows NT Start menu, click Programs. 2. Click Administrative Tools, and then click User Manager for Domains. 3. Click User, click Select Domain, and type the name of the local Microsoft Internet Information Server. 4. Double-click Guest, and clear the Account Disabled check box. For authenticated access to their mailboxes and public folders, users of Microsoft Exchange Active Server components must have the Log On Locally permission on the Internet Information Server. To set up Log on Locally permission: 1. On the Windows NT Start menu, click Programs. 2. Click Administrative Tools, and then click User Manager for Domains. 3. Click Policies, and then click User Rights. 4. Click Log On Locally. 2.5.5 Adding Mailboxes to the Microsoft Exchange Server To test Web access capabilities, you must add at least one mailbox to the Microsoft Exchange Server. For more information about adding mailboxes, see your Microsoft Exchange Server documentation. 2.5.6 Logging On to Microsoft Exchange Server Through a Web Browser 1. Start an Internet browser, such as Microsoft Internet Explorer 3.0. 2. In the Address (or Location) box, type the following URL: http://<server name>/exchange NOTE: The <server name> must be the name of the server where the Active Server components are installed. 3. Verify that a logon screen is displayed in the Web browser window. 4. To log on, type an e-mail name in the Logon box. Use one of the names you provided when you added mailboxes. 5. In the Authentication box, type the user name in the following format: domain\e-mail name 6. Type the user's Windows NT domain password. 7. Verify that the main mailbox Viewer is displayed in the Web browser window. 2.5.7 Removing Web Access from the Microsoft Exchange Server 1. Run the Microsoft Exchange Server Setup program, and click Complete/Custom. 2. Clear the Active Server Components check box, and then click OK. 2.5.8 Setting Up Basic Authentication and Security Basic authentication is the lowest level of security available for Internet or intranet users. It can be configured through the Microsoft Internet Service Manager provided with Microsoft Internet Information Server. When setting up basic authentication, you must also set up Log on Locally permission on the Internet Information Server. This allows users to access their mailboxes using the Web access URL. For a remote installation (where Active Server components are not on the Microsoft Exchange Server), Windows NT Challenge/Response authentication must be disabled. Secure Sockets Layer (SSL) can be used to encrypt data passed between the browser and the Internet Information Server (IIS) with browsers that support SSL. A security certificate must be obtained to enable the use of SSL, and the company that provides the security certificate will also supply instructions for setting up the server and the browsers. Either basic or NTLM security must be enabled to use SSL. SSL should not be used with Microsoft Internet Explorer version 3.0 running on Windows 95. This problem will be fixed in Microsoft Internet Explorer 4.0. For more information about basic authentication and other security capabilities, see your Microsoft Internet Information Server documentation. 2.5.9 Setting Up Anonymous Access to Public Folders 1. On the Windows NT Start menu, click Programs. 2. Click Microsoft Exchange, and then click Microsoft Exchange Administrator. 3. Select the server you are configuring, and then open the Configuration container. 4. Click Protocols, and then double-click HTTP (Web) Site Settings. 5. Select the Allow Anonymous Users to Access the Anonymous Public Folders check box. 6. Select the Folder Shortcuts tab. 7. Click New to add folders for anonymous viewing, and select an existing folder in the Public Folders dialog box. 8. Click OK. Published folders must have at least Read permission granted to Anonymous. This is set in the Permissions tab for the specified folder. Folder permissions can be accessed from either the Microsoft Exchange Server Administrator program or from the client. 1. In the Microsoft Exchange Server Administrator program, browse to the public folder for which you created a shortcut. 2. On the File menu, click Properties. 3. Click Client Permissions. 4. In the box at the top of the Client Permissions dialog box, select Anonymous, and change its role from None to the desired level of access. If you want to publish all subfolders of this folder for anonymous access, select the Propagate these properties to all subfolders check box. 5. Click OK. 2.5.10 Known Issues Installation French, German, and Japanese installations will include an English script directory. Do not delete this directory. Attachments Sending attachments is not supported in this release. Users can receive and forward attachments, but there is no provision for creating an attachment. Embedded messages and OLE objects contained in messages are not accessible when viewing the message from the browser. Views Some complex, categorized views do not appear correctly in the browser. When viewing folders with these views, the page count may be incorrect. Some previous/next interactions may appear inconsistent. Messages The Inbox is not automatically updated when reading, deleting, or receiving new mail. To update the Inbox, click the Check for new messages button on the Web access toolbar. Logging Off For security reasons, users should close the browser when logging off. Errors may occur if users try to log on with a different user ID or as an anonymous user. Anonymous Connections Anonymous public folder access is available only when viewing public folders located on a Microsoft Exchange Server version 5.0. On the Microsoft Exchange Server computer, you must enable the Guest account in User Manager. Double-click the Guest Account. Make sure the Disable Account box is cleared. To publish public folders for anonymous access, you must publish folders below the All Public Folders level. It is not possible to publish in the All Public Folders level in this release. Refreshing or Reloading the Viewer This condition occurs while viewing a folder using either Microsoft Internet Explorer or Netscape Navigator. If you click the browser Refresh or Reload button, the top-level folder is displayed regardless of the level you were previously viewing. To refresh or update the Viewer to the level that you are currently viewing, click the Update page address button on the Web access toolbar. Printing Messages from an Internet Browser To print a message while using the Web access to Microsoft Exchange Server in a Microsoft Internet Explorer window, right-click the title bar of the message, and then select the toolbar. Next, click the Print button on the toolbar. The Windows Print dialog box displays, allowing you to complete the process. To print a message while using the Web access to Microsoft Exchange Server in a Netscape Navigator window, ensure that the message you want to print is in the top window, and press CTRL+P. The Windows Print dialog box displays, allowing you to complete the process. Public Folder Shortcuts with Web Access and Microsoft Internet Explorer If you are using Microsoft Internet Explorer and attempting to open a shortcut to a public folder within a posted message, the following message may be displayed: Windows Internet Extension support has been shut down. Microsoft Office 97 Attachments Web access users may experience problems opening Microsoft Word or Microsoft Excel attachments with .rtf, .doc, or .xls extensions. 2.6 Microsoft Exchange Connector for Lotus cc:Mail 2.6.1 Troubleshooting Tips Consider the following when configuring the Connector for cc:Mail. - Sufficient permissions on the cc:Mail post office data directory share if the cc:Mail post office you are connecting to is on a NetWare server. The Windows NT account that the connector service is running under must have read/write permission on this share. See section 2.6.6. - The directory where Import.exe and Export.exe are located must be present in the path SYSTEM environment variable for the connector to function. The path is modified using the System application in Control Panel. It is recommended that you copy these utilities to the Winnt\System32 directory. Additionally, the IE.RI file for a cc:Mail DB8 (Release 6) post office must be included in the path. - If the connected cc:Mail post office does not have ADE enabled, verify that Permit ADE to propagate entries synched to cc:Mail to downstream post offices on the Post Office property page is not selected. - The Connector for cc:Mail transfers mail every 15 seconds inbound from cc:Mail to Microsoft Exchange Server by exporting from the remote PO entry in the cc:Mail directory that represents the connected site. If the remote post office entry does not exist (for example, before you have run directory synchronization), this export will fail. Although the directory synchronization process creates this post office entry in the cc:Mail directory, message transfer will fail until this post office entry has been created. - If you manually create remote post office entries for your Microsoft Exchange Server sites or entries for Microsoft Exchange recipients in the cc:Mail directory (this is not recommended if you are not planning to use directory synchronization), see sections 2.6.2 and 2.6.3. 2.6.2 Do Not Manually Create Remote Post Office Entries in the cc:Mail Directory if Running Directory Synchronization The Connector for cc:Mail directory synchronization process automatically creates remote post office entries, including downstream Microsoft Exchange Server sites, in the cc:Mail directory. The connector creates a comment for each post office entry created that must remain for future directory synchronization processes to function properly. If these comments are removed, directory synchronization fails. The format is as follows MSExchangeCCMC servername where servername is the name of the computer where the connector is installed. Do not delete or modify these comments. If the Microsoft Exchange Server hosting the Connector for cc:Mail and performing directory synchronization is removed and relocated on another server, then you must delete post office and user references created automatically by the original connector. 2.6.3 Directory Synchronization Uses FAN in the cc:Mail Directory When directory synchronization creates entries in the cc:Mail directory, it uses the foreign address name (FAN) field. Do not modify or delete this field. If entries to the cc:Mail directory are created manually for Microsoft Exchange Server recipients, the FAN fields for these entries must be complete. The field must include the CCMAIL address of the Microsoft Exchange Server recipient. For example, the Microsoft Exchange Server recipient Sally Brady will, by default, have the CCMAIL e-mail address Brady, Sally. Use Microsoft Exchange Server Administrator program to determine the CCMAIL e-mail address of a recipient. 2.6.4 What's New Chapter 8 In the "Testing from a cc:Mail Client" section, the Note requires further explanation. The text states that before testing the connection, you must add the Microsoft Exchange Server site as a cc:Mail post office using the cc:Mail Administrator program. This is true if directory synchronization has not yet occurred or if directory synchronization will never occur. If you plan to use directory synchronization after a post office has been created manually, you must delete the post office entry before running directory synchronization. Directory synchronization will re-create the post office. 2.6.5 Import/Export Version 5.12 Should be Upgraded to Import 5.15 and Export 5.14 Testing for the Connector for cc:Mail was done using Import 5.15 and Export 5.14 and Import/Export 6.0. No thorough testing has been done for Import/Export versions 5.12. No incompatibilities are known to exist using Import/Export versions 5.12. However, it is recommended that you upgrade to Import 5.15 and Export 5.14. 2.6.6 Configuring the Connector for cc:Mail to a Post Office on a NetWare Server Sufficient access rights are necessary when configuring the Connector for cc:Mail to a cc:Mail post office residing on a NetWare server (version 3.1x or 4.x). The service account accessing the directory where the cc:Mail post office data (\CCDATA) resides must have full access and the account must be configured to never expire. Sufficient access can be accomplished by either: - Installing and configuring Gateway Services for NetWare on the Windows NT Server where the Connector for cc:Mail resides. The directory that contains the cc:Mail post office data files can be shared using the gateway service. Share permissions are determined by the Microsoft Exchange Server service account. -or- - Creating an account on the NetWare server where the cc:Mail post office resides that is identical to the Microsoft Exchange Server service account. The NetWare account must have the same user account name and password information as the Windows NT Server account used as the Microsoft Exchange Server service account. NetWare rights for the account must be set for Read, File Scan, Modify, and Create to the directory. To test the Microsoft Exchange Server service account for verification of sufficient rights when installing the connector: 1. On Microsoft Windows NT Server, create the account that will be used as the Microsoft Exchange Server service account. This account should have the Password Never Expires box selected. 2. Verify that Gateway Services for NetWare is properly installed and configured. 3. Using the appropriate NetWare Administration tool, create an account on the Novell server to access the cc:Mail post office. This account must have the same user ID and password as the Microsoft Exchange Server service account. This account will need access to the cc:Mail post office directory with Read, Modify, File Scan, and Create rights. 4. On Microsoft Windows NT Server, temporarily give the Microsoft Exchange Server service account local logon rights using the Windows NT User Manager for Domains utility. Log on as the Microsoft Exchange Server service account. The first time you log on after Gateway Services for NetWare is installed, Windows NT Server will prompt you for your default server (for NetWare 3.1x or 4.x using bindery emulation), or the correct NDS Tree and Context for NetWare 4.x. Select the default server or NDS Tree/Context for the Microsoft Exchange Server service account. 5. While logged on using the Microsoft Exchange Server service account, run the cc:Mail Admin utility to verify the service account has sufficient rights. You should have access to the cc:Mail post office for creating local users and post office entries. If you can access the post office, but cannot create new directory entries, the Microsoft Exchange service account on the NetWare server does not have Create rights to the cc:Mail post office directory. 6. Log off the Microsoft Exchange Server service account. You may remove local logon rights from the Microsoft Exchange Server service account using the User Manager for Domains utility. For information on configuring Gateway Services for NetWare, see your Windows NT Server documentation or visit the Microsoft Knowledge Base at http://www.microsoft.com/kb and search for knowledge base articles Q149524 and Q118469. 2.6.7 Manual E-mail Address Modification Required for Microsoft Exchange Clients Sending to Downstream Bulletin Boards Directory synchronization creates custom recipient entries for cc:Mail bulletin boards in the Microsoft Exchange Server directory. Messages sent to these custom recipients will be delivered only to the bulletin boards on the connected post office. You must modify the CCMAIL target address on the bulletin board custom recipients to propagate bulletin board messages to downstream post offices. For example, a bulletin board named "Social" located on the cc:Mail post office "PO5" would have the address "#Social." Modify this to read "#Social at PO5." You can determine the home post office for a bulletin board from the cc:Mail Admin program. 1. Double-click the bulletin board custom recipient. 2. On the General tab, click E-mail. 3. Select Modify Existing E-Mail Address. 4. Type E-mail address information. 5. Run directory synchronization. 2.6.8 Propagation of Messages Between cc:Mail Bulletin Boards and Microsoft Exchange Server Public Folders Microsoft Exchange Server and cc:Mail can be configured to forward mail sent to a public folder or a bulletin board respectively. Because of limitations in the propagation of bulletin board messages, forwarding can be configured for one direction only (cc:Mail to Microsoft Exchange Server or Microsoft Exchange Server to cc:Mail). Configuration of cross posting between a cc:Mail bulletin board and a Microsoft Exchange Server public folder will result in message looping. The Lotus cc:Mail Router program (an agent that propagates bulletin board messages on a cc:Mail system) must be active between the bulletin board home post office and the recipient post office for the propagation of cc:Mail bulletin board messages to occur. Messages sent through the Connector for cc:Mail to Microsoft Exchange Server are extracted from the connected cc:Mail post office using the cc:Mail Import/Export utilities. These messages are not delivered by the cc:Mail Router. As a result, bulletin boards propagated into Microsoft Exchange Server public folders cannot be hosted on the connected cc:Mail post office. Furthermore, bulletin boards hosted on the connected cc:Mail post office must be moved and homed to another post office. To configure propagation from cc:Mail bulletin boards into Microsoft Exchange Server public folders: 1. Create a Microsoft Exchange Server public folder into which bulletin board messages will be propagated. The public folder must have the same name as the cc:Mail bulletin board. In the Microsoft Exchange Server Administrator program, select Folders, select Public Folders, and then double-click the public folder used for propagating bulletin board messages. Select the Advanced tab, and disable Hide from address book. 2. Configure the connector and run directory synchronization. Verify that the cc:Mail SiteProxy post office has propagated through Automatic Directory Exchange (ADE) to the cc:Mail post office hosting the bulletin board. 3. Modify the Microsoft Exchange Server custom recipient for the cc:Mail bulletin board as described in section 2.6.7. 4. On the cc:Mail Admin utility main menu, select manage Bulletin boards. Choose the name of the bulletin board to be propagated, and press ENTER. 5. On the Bulletin Board menu, select Add names to propagation list. If the target public folder is the same as the bulletin board, select the Exchange SiteProxy post office name; otherwise, select the name of the Microsoft Exchange Server public folder. Other methods for synchronizing messages posted to bulletin boards into public folders include: - Use cc:Mail's client-based rules to automatically add the address of a public folder to messages the user sends to a bulletin board. These rules must be created on a per-bulletin board basis and must be created directly by the end user or by an administrator who then distributes the .rul files to end users. - Create mailing lists in the cc:Mail directory that include a bulletin board/public folder pair. Instruct users to send to these mailing lists instead of posting directly to the bulletin board. Propagating Microsoft Exchange Server Public Folder Messages into cc:Mail Bulletin Boards Messages are propagated from Microsoft Exchange Server public folders using a Folder Assistant rule. You will create a rule to forward all messages posted or sent to the public folder to the cc:Mail bulletin board. 1. Configure the connector and run directory synchronization. Verify that the cc:Mail SiteProxy post office has propagated through Automatic Directory Exchange (ADE) to the cc:Mail post office hosting the bulletin board. 2. Modify the Microsoft Exchange Server custom recipient for the cc:Mail bulletin board as described in section 2.6.7. 3. In the Microsoft Exchange Client, right-click the public folder to be propagated, and click Properties. 4. On the Administration tab, select the check boxes Folder Assistant, Add Rule, and Forward. 5. Double-click To, and select the cc:Mail bulletin board for receiving the propagated messages. In the Method box, select Leave message intact. 6. A dialog box appears: This rule will fire for all incoming messages. Is this what you want? Click Yes. Another method of synchronizing messages posted or sent to public folders is to create a distribution list for each public folder and include the public folder and the corresponding bulletin board as members. Instruct users to send to the distribution list instead of sending or posting directly to the public folder. 2.6.9 Stop the Connector for cc:Mail Service Prior to cc:Mail Post Office Maintenance It is recommended that you stop the Microsoft Exchange Connector for cc:Mail service before performing cc:Mail post office maintenance (for example, chkstat and reclaim). The directory synchronization process must not be running while attempting to stop the service. Do not perform cc:Mail post office maintenance during a directory synchronization cycle. 2.6.10 Site Addresses for cc:Mail Post Offices Cannot be the Same as Existing cc:Mail Mailboxes Do not use a CCMAIL type site address for the Connector for cc:Mail that is identical to an existing cc:Mail mailbox. Mail from cc:Mail to Microsoft Exchange Server will be delivered to the existing mailbox and not the connector. 2.6.11 Delivery Restrictions Property Page for the Connector for cc:Mail The Delivery Restrictions property page is not documented in What's New. Use the Delivery Restrictions property page to accept or reject messages from any sender listed in the Microsoft Exchange Server directory. For example, if a message is addressed to a foreign system, it is returned to the sender if the sender's address is in the Reject messages from box or does not appear in the Accept messages from box. Delivery restrictions are optional and do not affect incoming messages. The default is to accept messages from all senders and reject messages from none. To get to the Delivery Restrictions property page, click Connections, double-click Connector for cc:Mail, and select the Delivery Restrictions tab. 2.6.12 Lotus cc:Mail Requires Unique Proxy Names Lotus cc:Mail proxy names such as "user at ex1" and "user at ex2" are considered unique to Microsoft Exchange Server, but not to cc:Mail. Modify user names using the Microsoft Exchange Server Administrator program. For example, rename "user at ex1" to "user1 at ex1." 2.6.13 Configure Windows NT Regional Settings to the Same Language as the Connector Postoffice Language You may experience language-specific conversion problems when configuring the postoffice language setting in the Post Office property page that is different from the Windows NT Server Regional Settings application in Control Panel. 2.6.14 Some Code Pages Are Not Supported by cc:Mail Release 6 (DB8) At the time of this writing, Lotus cc:Mail Release 6 (DB8) is not available for Chinese Simplified, Chinese Traditional, or Russian code pages. If you select Import 6.0/Export 6.0 in Post Office, do not select Chinese (Simplified), Chinese (Traditional), or Russian under Post office language. Otherwise, message transfer will fail. 2.6.15 Lotus cc:Mail Import.exe Converts Text Items Greater Than 20K into File Items The text of a cc:Mail message may be separated into multiple items. Each item begins with the words Text item: followed by the title. Each text item is limited to 20 KB. A text item greater than 20K is made into a file item. 2.6.16 NTVDM May Fail When Running German Against a DB8 Post Office Without a Remote Post Office Entry Created for Microsoft Exchange Server If you're running the connector against a German DB8 (Release 6) post office and there is no post office entry for the Microsoft Exchange Server site in the cc:Mail directory (for example, you have not run directory synchronization), NTVDM may produce a Stop error when the connector attempts to export from cc:Mail. 2.7 Internet Protocol Support 2.7.1 Protocol Settings Are Not Replicated Between Sites HTTP, LDAP, NNTP, and POP3-related settings are not replicated between multiple sites. To view or edit any of these protocol settings, the Administrator program must be connected to a server in the same site as the custom recipient, mailbox, server, or site configuration object that you want to view or edit. 2.7.2 Using SSL with NNTP, POP3, and LDAP To use SSL encryption with NNTP, POP3, and LDAP, the Microsoft Exchange Server service account must be granted Administrator permissions for the local computer. 2.7.3 Correction to Authentication Documentation for NNTP, POP3, and LDAP Supported authentication/encryption mechanisms for NNTP and POP3 are: Basic (clear text) Basic (clear text) using SSL Windows NT Challenge/Response Windows NT Challenge/Response using SSL Supported authentication/encryption mechanisms for LDAP are: Basic (clear text) Basic (clear text) using SSL 2.7.4 Correction to POP3 and NNTP Event Logging Documentation POP3 and NNTP event logging is enabled in the Diagnostics Logging property pages for POP3 and NNTP. 2.7.5 Using LDAP to Access the Directory as an Authenticated User Microsoft Exchange Server supports authenticated and anonymous access to the directory. You can specify which attributes are accessible to authenticated and anonymous users using the Attributes property page on the DS Site Configuration object. By default, authenticated users can view more attributes than anonymous users. In addition, authenticated users can see all objects in the directory, whereas anonymous users can see only mail recipients. To use an LDAP client to access the directory as an authenticated user, the user must provide valid Windows NT Server credentials in the following format: cn=username,cn=NT domain. For example, a user with the Windows NT user account redmond\mblack, would specify cn=mblack,cn=redmond. The user should also provide a password for this user account. 2.8 POP3 Clients 2.8.1 POP3 Clients and SMTP Simultaneous Connections If you have a server supporting POP3 clients, you may need to increase the maximum number of simultaneous simple mail transport protocol (SMTP) connections on the server. POP3 clients need to create an SMTP connection to the Internet Mail Service to send mail, but the number of simultaneous connections required varies based on the number and type of POP3 clients. If you are installing a new Internet Mail Service and not upgrading from a previous version, the maximum number of inbound connections is set to 30; otherwise, it is set to 20. If you are upgrading from Microsoft Exchange Server version 4.0 and are supporting a heavy load of POP3 client users, you should increase this setting to 30; otherwise, it will remain at 20 after an upgrade. To access the Inbound Connections option, click Advanced in the Connections property page of the Internet Mail Service. 2.8.2 Using Backslashes in Mailbox Names with POP3 Mail Clients If a mailbox has an alias name that contains a backslash (\) character, when you specify the POP3 account for the mail client, the mailbox name must be preceded by the Windows NT user account associated with the mailbox. For example, a mailbox with the alias name joe\smith, should be specified as Windows NT_domain\userid\joe\smith. 2.8.3 POP3 Users May Require Increased Information Store Threads A server supporting a large number of POP3 clients may need to increase the maximum number of information store threads. POP3 clients create a connection to the information store to receive mail. The number of simultaneous connections required varies depending upon the number and type of POP3 clients. Consider that POP3 clients poll the server and are not always connected when estimating the number of simultaneous connections. The duration of the connection is the time required to download mail. POP3 clients receiving slow response from a server is an indicator for increasing information store threads. Information store threads can be increased without adversely affecting server performance. The information store will start more threads only if they are actually needed. To increase information store threads for POP3 clients: 1. Open Registry Editor, and then open the following registry keys: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ ParametersNetIf\MaxPoolThreads 2. Under Value data, type 100. 2.8.4 Microsoft Windows CE Mail Requires Full Transfer of POP3 Messages You may receive the following error when accessing a portion of a nested MIME message from a Microsoft Windows CE Mail client: Error getting the message: Error retrieving from POP3 server. [Service error: 29] To configure the Microsoft Windows CE Mail client to accept all lines of a POP3 message: 1. On the Service menu, click Properties. 2. Click Inbox Folder Preferences for Mail. 3. Under Transfer Limit, select All lines in message. 2.8.5 Problems Displaying Some International Character Sets The Internet Mail program included with the Microsoft Windows 3.x version of Microsoft Internet Explorer version 2.1 may have difficulties displaying some international character sets. To solve this problem, upgrade to the Internet Mail and News program available with Internet Explorer 3.0. Obtain the upgrade from http://www.microsoft.com/ie. 2.8.6 Macintosh Appledouble Attachments If an Internet message is received with Appledouble attachments (such as those generated by the Netscape mail client for Macintosh), the attachments are lost when the message is converted to an Internet message for a POP3 client. You can access the attachments through the Microsoft Exchange Client. 2.8.7 Using the Banyan BeyondMail POP3 Client Some versions of Banyan BeyondMail cannot receive mail from a Microsoft Exchange Server 5.0 supporting POP3. Contact Banyan Customer Services for a software solution. 2.9 Known Issues with the Internet Mail Service and Internet News Service 2.9.1 When Sending Rich Text Formatting, Use MIME Messages Rather Than Non- MIME If non-MIME with rich text formatting is used, you may experience the following problems: - Extraneous duplicate attachment icons when sending messages from Microsoft Exchange Server using Japanese JIS or Japanese EUC character sets. - When sending to a 4.0 server, if the Internet character set cannot represent every character in the message, then the 4.0 server may lose the rich text formatting. - Macintosh UUENCODE attachments sent from 4.0 servers to 5.0 servers are not tagged as Macintosh attachments. (This can also be solved by using BinHex instead of uuencode.) - Macintosh uuencode attachments from 5.0 servers are sent with only the data fork. 2.9.2 Inbound UTF-7 Corruption When Using Windows NT Server 4.0 To process UTF-7 messages correctly, Windows NT 4.0 Service Pack 2 (SP2) is required for the following languages: English, French, Spanish, Italian, Swedish, Dutch, Brazilian, Danish, Finnish, Norwegian, and Japanese. The Russian Microsoft Windows NT Server 4.0 has the updated UTF-7 files. Windows NT Server 4.0 SP2 is not available for: Polish, Czech, Hungarian, Chinese, and Korean. These locales require Microsoft Windows NT Server 4.0 Service Pack 3 (SP3). Users in other countries can use English Windows NT Server 4.0 configured for their country locale. 2.9.3 NLS File Installation Requires Restarting Microsoft Windows NT Server Microsoft Exchange Server Setup installs the latest NLS files available for Windows NT Server. You must restart Windows NT Server to load the newest NLS. The updated NLS files are for the iso-8859 series. They provide improved mapping between Internet character sets and code pages. 2.9.4 IA5 and UTF in the Headers of Embedded Messages Are Not Decoded The message header is not decoded for embedded messages that use IA5 or UTF character sets in the header. 2.9.5 Use Shift-JIS for Japanese Messages Between Microsoft Exchange Server and MS Mail (PC) When sending Japanese messages in the JIS or EUC character set between Microsoft Exchange Server 5.0 and MS Mail (PC) and using the SMTP gateway as a backbone, rich text formatting is lost, and attachments lose their positioning in the message. The Japanese Shift-JIS character set should be used instead. 2.9.6 Use Only Typical Internet Character Sets Selecting a different but compatible character set for a message will result in an Internet message whose body is encoded using the selected character set, but whose body is labeled with the default Internet character set for that type of message. For example, a Western European message will typically use "iso-8859-1." Selecting any compatible character set to use for this message, such as "windows-1252," displays an Internet message that is labeled with "iso-8859-1," but is actually encoded as "windows-1252." 2.9.7 DBCS Attachment Names Become a Series of Question Marks When There Is No Text in the Body of a Message When you send an Internet message, DBCS attachment names become a series of question marks (????) when there is no text in the body of the message. 2.10 Banyan VINES Configuration To ensure that Microsoft Exchange Client can connect to a Microsoft Exchange Server computer on a Banyan VINES network, the Banyan VINES protocol (ncacn_vns_spp) should be the first protocol listed in the RPC binding order. In addition, any unused protocols should be removed from the binding order. For more information, see the Microsoft Exchange Server Resource Guide. To run Microsoft Exchange Server on a Banyan VINES network: 1. Install the Banyan VINES redirector on the Microsoft Exchange Server computer. 2. Configure RPC support for Banyan VINES. If Windows NT Server version 3.51 is installed, copy the DLLs in the Support\Banyan directory on the Microsoft Exchange Server compact disc to your Windows System32 directory. If Windows NT Server version 4.0 is installed, perform the following procedure: 1. In Control Panel, click Network. 2. On the Services tab, click Add. 3. Select RPC support for Banyan, and click OK. If Microsoft Exchange Server and Windows NT Server version 4.0 are installed on a computer running in a Banyan VINES network, the Banyan VINES computer name must be the same as the Microsoft Exchange Server computer name. For example, if the Microsoft Exchange Server name is MailServer1, the Banyan VINES computer name should also be MailServer1. To set the Banyan VINES computer name to the same name as Microsoft Exchange Server: 1. In the VINES program group, click Setup. 2. Click Computers. 3. Select Name Workstation on Network. 4. In the Computer Name box, type the name used by Microsoft Exchange Server. For more information, see the Microsoft Knowledge Base at the Microsoft Web site, www.microsoft.com. 2.11 Address Book Views 2.11.1 Exporting Recipients from Address Book View Containers The default set of attributes exported using the Directory Export command on the Tools menu does not include the attributes used for creating Address Book Views. To preserve Address Book View memberships when mail recipients are exported and subsequently re-imported, make sure to include all Address Book View grouping attributes in the header line of your export .csv file. The following .csv file headers contain all the attributes typically exported and imported for mailboxes and custom recipients. For mailboxes: Obj-Class,Mail-Nickname,Common-Name,Display-Name,Given-Name, Initials,Surname,Company,Department,Title,Physical-Delivery-Office-Name, Assistant-Name,Address,City,State-Or-Province-Name,Country,Postal-Code, Custom Attribute 1,Custom Attribute 2,Custom Attribute 3, Custom Attribute 4,Custom Attribute 5,Custom Attribute 6, Custom Attribute 7,Custom Attribute 8,Custom Attribute 9, Custom Attribute 10,Phone number,Business phone number 2,Fax number, Assistant phone number,Home phone number,Home phone number 2,Mobile number, Pager number,Simple display name,Home-Server,Primary Windows NT Account, Comment For custom recipients: Obj-Class,Mail-Nickname,Common-Name,Target-Address,Display-Name, Given-Name,Initials,Surname,Company,Department,Title, Physical-Delivery-Office-Name,Assistant-Name,Address,City, State-Or-Province-Name,Country,Postal-Code,Custom Attribute 1, Custom Attribute 2,Custom Attribute 3,Custom Attribute 4, Custom Attribute 5,Custom Attribute 6,Custom Attribute 7, Custom Attribute 8,Custom Attribute 9,Custom Attribute 10, Phone number,Business phone number 2,Fax number, Assistant phone number,Home phone number,Home phone number 2, Mobile number,Pager number,Simple display name,Comment 2.11.2 Address Book View Max New Containers Registry Key Directory performance can degrade when large, complex Address Book Views are being generated for the first time. This can be alleviated by reducing the number of new Address Book View containers that the directory creates at a time. This can be done by adding the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDS\ Parameters\ABV max new containers The process that creates Address Book View containers pauses for five minutes after creating this number of containers, allows replication and other directory processes to catch up, and then resumes. The default value is 500. 2.11.3 Removing Empty View Containers Empty view containers are not removed automatically by the directory. However, they can be removed in any of the following ways: - Use the Remove empty containers button in the view's Advanced property page. - Modify the Group By attributes so that the empty containers will not be needed. The directory will discard them when it recalculates the Address Book View. - Delete the empty Address Book View containers individually. 2.11.4 Moving Recipients Between Servers and Sites The Add to Address Book View command on the Tools menu does not work with Address Book Views based on site or home server attributes. The Move Mailbox command on the Tools menu can be used to move mailboxes between servers. 2.11.5 Add to Address Book View Command The Add to Address Book View command on the Tools menu can be used as a bulk editing tool for mail recipient objects. Moving recipients in bulk between Address Book View containers only changes the value of the underlying grouping attribute. However, there can be unexpected results when using the Add to Address Book View command. For example, in a view defined with groupings on the Country, State, and City attributes, the following sample hierarchy exists: USA Texas Dallas Austin Canada British Columbia Vancouver By selecting all the recipients in the Dallas container and using the Add to Address Book View command to move those recipients into the Canada container, only the Country attribute will be changed on the recipient objects. When the view is recalculated, the following hierarchy will exist: USA Texas Austin Canada British Columbia Vancouver Texas Dallas Notice that the original Dallas container under USA/Texas no longer exists and the view hierarchy now exists under the Canada container. 3.0 Connectors 3.1 Microsoft Mail Connector 3.1.1 Importing the Directory Synchronization Master List Manually If you are configuring Microsoft Exchange Server as a directory synchronization server for one or more MS Mail (PC) remote directory synchronization requestors, the initial export of the directory synchronization master list may be large. In particular, if the export is done over a slow network link or asynchronously, the time required for export may be significant. For the remote directory synchronization requestor, the limit you specified in MS Mail (PC) Administrator program with the Config/Dir-Sync/Requestor/Options/Limit may be less than the size of the master list you are importing, and you cannot import the list. You must import the directory synchronization master list manually. To import the directory synchronization master list manually from a Microsoft Exchange Server directory server to one or more MS Mail (PC) remote directory synchronization requestors, do the following: 1. Edit the Windows NT Server registry (description below). 2. Restart the Microsoft Exchange Directory Synchronization Service (description below). 3. Copy the directory synchronization master list (Resync.glb) to an external storage device (description below). 4. Import the master list to the remote directory synchronization requestor and run the MS Mail (PC) Import utility (description below). Edit the Windows NT Registry The following procedure describes how to configure the Windows NT registry for generating the directory synchronization master list for export. 1. Open Regedt32, and then open the following registry keys: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDX 2. Click Edit, and then click Add Value. 3. In the Value name box, type ResyncConnectionRDNs. 4. In the Data type box, select REG_MULTI_SZ and click OK. 5. Under Data, type the common name or RDN given to the remote directory synchronization requestor object for which you are generating the master list. If there is more than one postoffice, type each postoffice name, and press ENTER. 6. Click OK. 7. Stop and restart the Microsoft Exchange Directory Synchronization Service. Restart the Microsoft Exchange Directory Synchronization Service. After successful generation of the Resync.glb file, restart the Microsoft Exchange Directory Synchronization Service from the Windows NT Control Panel. Copy the Resync.glb File to an External Storage Device After the manual directory synchronization cycle has completed, copy The Exchsrvr\Dxadata\Resync.glb file to an external storage device (for example, disk or tape device) for transport to the remote directory synchronization requestor. Import the Resync.glb File to the Remote Directory Synchronization Requestor When the Resync.glb file is received for the remote directory synchronization requestor, it must be imported manually. The remote requestor administrator copies the Resync.glb file to the remote requestor's Glb directory. To import the list immediately, run the Import utility with the -q command line option. For information on using the Import utility, see the Microsoft Mail for PC Networks Administrator's Guide. Because of the flexibility of Microsoft Exchange Server (for example, export of custom recipients, trust levels, and containers), you can generate unique master address lists for individual remote directory synchronization requestors or groups of requestors. The directory synchronization server can be configured for: - All remote directory synchronization requestors with identical configurations. - Groups of remote directory synchronization requestors with identical configurations. - Unique configurations for each remote directory synchronization requestor. If you have one or more remote directory synchronization requestors and they share similar configurations, follow the procedures above. When creating the ResyncConnectionRDNs value, be sure to enter all postoffice names. For multiple groups of remote directory synchronization requestors that have identical configurations, follow the procedures above for each group. When creating the ResyncConnectionRDNs value, be sure to enter the names of all postoffices for each group. You must create a ResyncConnectionRDNs value for each group. For each manual generation of the master directory synchronization list, copy the Resync.glb file from Exchsrvr\Dxadata directory before doing manual import for the next group of MS Mail (PC) requestors. After the Resync.glb file has been generated for a group, restart the Microsoft Exchange Directory Synchronization Service. For individual remote directory synchronization requestors that have unique configurations, follow the procedures above for each requestor. When creating the ResyncConnectionRDNs value, be sure to enter the name of the requestor postoffice only. You must create a ResyncConnectionRDNs value for each requestor. For each manual generation of the master directory synchronization list, copy the Resync.glb file from the Exchsrvr\Dxadata directory before doing manual import for the next MS Mail (PC) requestor. After the Resync.glb file has been generated for a requestor, restart the Microsoft Exchange Directory Synchronization Service. 3.1.2 Microsoft Exchange Server as a Directory Synchronization Requestor If Microsoft Exchange Server is configured as a directory synchronization requestor, run the manual export procedure for the Microsoft Mail (PC) directory synchronization server as documented in the Microsoft Mail for PC Networks Administrator's Guide. Once Resync.glb has been generated, copy it to the Exchsrvr\Dxadata directory on the Microsoft Exchange Server Directory Requestor. You must then stop and restart the Microsoft Exchange Directory Synchronization Service using the Services application in Windows NT Server Control Panel. 3.1.3 Manual Directory Synchronization Directory synchronization messages are sent at the beginning of each hour selected in the schedule grid for the directory synchronization server object. If you do not want to wait for the next scheduled directory synchronization event, you can manually start the directory synchronization process. You must add a value to the Windows NT Server registry to use this function. Manual directory synchronization can be done from the command prompt or from the Services application in Control Panel. To start a directory synchronization process manually from the Windows NT Server command prompt: 1. At the command prompt, type Net pause msexchangedx. Ignore the error message "The Microsoft Exchange Directory Synchronization service failed to pause. More help is available by typing NET HELPMSG3539." The directory synchronization process has started successfully and can be viewed from the Windows NT Event Viewer if diagnostics logging has been enabled for the directory synchronization object (MSExchangeDX). 2. Quit the MS-DOS session. To start a directory synchronization process manually from the Services application in Control Panel: 1. In Control Panel, open the Services application. 2. Select Microsoft Exchange Directory Synchronization. 3. Click Pause. Ignore the error message "Could not pause the Microsoft Exchange Directory Synchronization service on \\<servername>. Error 2140: An internal Windows NT error occurred." The directory synchronization process was successfully started by issuing the pause command. Logging can be viewed from the Windows NT Event Viewer if diagnostics logging has been enabled for the directory synchronization object (MSExchangeDX). 4. Click OK, and then close the Services application. If your Microsoft Exchange Server computer has been configured as a directory synchronization server, a manual directory synchronization checks the current status of remote directory synchronization requestors. If your Microsoft Exchange Server has been configured as a directory synchronization requestor, a manual directory synchronization searches for updates from the directory synchronization server. 3.1.4 Microsoft Exchange Connection DER Memory Configuration Previous usage of the Microsoft Exchange Connection Directory Exchange Requestor (DER) application required a large amount of pre-allocated memory. This is no longer required on the Macintosh Mail Server. The default memory allocation during Setup is 512K and should be increased by 100 KB for every 1,500 addresses above 4500. 3.1.5 Importing Address Templates for Third-Party Mail Systems You can install third-party gateway templates required for sending messages from a Microsoft Exchange Client computer to a foreign mail system. For example, if you have an MHS gateway on an MS Mail (PC) system and have installed the MHS Gateway Access component on the Microsoft Exchange Server connector postoffice, you should install the MHS gateway template. This template enables Microsoft Exchange Clients to send mail destined to an MHS system through the MHS gateway. For information on configuring a Microsoft Gateway Access component on a Microsoft Mail Connector, see the Microsoft Exchange Server Administrator's Guide. To create addresses in Microsoft Exchange Client for gateways if a third-party gateway template is not available: 1. In the Address Book, click New, and then select Other Address. 2. Type the display name, the address, and set the address type to the type used by the gateway. The following third-party gateway templates are available for installation on Microsoft Exchange Server. MHS IBM PROFS SNADS FAX AT&T Easylink The templates are stored in the Microsoft Exchange Server directory. They need to be installed on only one server in your organization. As long as directory replication is configured correctly, the templates will be replicated to other sites. The installation of French, German, and Japanese foreign language templates is similar to installing English language templates. To install an English version of a third-party gateway template: 1. On the Tools menu in the Administrator window, click Directory Import. 2. In the Windows NT domain box, select the domain for Microsoft Exchange Server computer on which you want to install the template. 3. In the MS Exchange server box, select the Microsoft Exchange Server on which you want to install the template. 4. Click Import File. 5. From the Microsoft Exchange Server compact disc, select setup\i386\tpl\usa. To install foreign language templates, select the appropriate language directory. 6. Select a third-party template file, and then click OK. 7. Click Import. You can now view the imported third-party template from Microsoft Exchange Client. To send a message from a Microsoft Exchange Client to a foreign mail system: 1. In the Microsoft Exchange Client, compose a new message. 2. Click To. 3. Click New. 4. Under Select The Entry Type, choose the template. 5. Type the information required for the foreign mail system. To create addresses in the Microsoft Exchange Client for third-party gateways without using the supplied template: 1. In the Address Book, click New, and then click Other Address. 2. Type the display name, the address, and set the address type to the type used by the gateway. The address types for the templates are the same as the names of the templates (ATT, FAX, MHS, SNADS, and PROFS). 3.1.6 Configuring Microsoft Exchange Server and Quarterdeck Mail (Formerly Microsoft Mail for AppleTalk Networks) There are several ways to configure the connection between Quarterdeck Mail (QMail) and Microsoft Exchange Server, depending on the number of sites and the number of connectors. Some of these ways are more efficient and more reliable than others and are recommended. For all connections, empirical tests by customers have shown that the best performance comes when the polling interval (set from the Gateway Connect menu) is set to Always with an interval of three minutes and a blocking factor (set from the Gateway Configuration menu) of 30. This allows the QMail server to empty the gateway queue without wasting too much time checking the connection status. Microsoft Exchange Server is faster than QMail and can process the messages without becoming backlogged. The following options are available when configuring Microsoft Exchange Server with QMail. - Single connection. This can be a single Macintosh server or a single instance of the AppleTalk Connector to a QMail site. There is no additional configuration required. - Multiple connections, no backboning. This is the recommended method for linking Microsoft Exchange Server to a collection of QMail servers in a single site or multiple sites. Keep Microsoft Exchange Server messages on Microsoft Exchange Server and QMail messages on QMail. This avoids problems with message conversion and the delays inherent in transferring messages from one native format to the other and back again. It also makes it possible to have more than 32,000 Microsoft Exchange Server addresses on the QMail system. However, it requires additional configuration for addressing and message replies to work correctly. This additional configuration consists of adding a new addressing DLL to Microsoft Exchange Server that automatically generates QMail proxy addresses for Microsoft Exchange Server users. This is required due to a limitation of QMail when sending a message to multiple gateway addresses that are defined on different QMail servers; those addresses defined on a different server appear as user@GatewayName on Microsoft Exchange Server and replies will fail. The QMail proxy allows Microsoft Exchange Server to convert these addresses into the correct Microsoft Exchange Server address so that replies will function correctly. For users to have the MSA proxy created for them automatically, install the Macproxy.dll before adding any users to Microsoft Exchange Server. To install the Macproxy.dll: 1. Create the following subdirectories in the Exchange\Address directory. msa\server type (i386, alpha, ppc) 2. In the platform-specific directory, copy the Macproxy.dll from the Connect\Msmcon\Bin subdirectory. Then run the address installation program (Addrinst.exe) located in the Support\Macproxy\platform\Msmcon directory with the following parameters: /sitedn=site name /name="Quarterdeck Mail proxy generator" /machine=server type /type=MSA /proxydll=path to macproxy.dll /server=server name /gwproxy=gateway name on Mail server By default, the gateway name on the QMail server is Exchange Connection, but it can be changed by the administrator at installation. Once the QMail Proxy.dll is installed, it functions like other proxy generators and can be configured in the Site Addressing property page. Additionally, all QMail sites must exchange address lists with each other to avoid another addressing feature of QMail. If the sites are not fully replicated, QMail cannot resolve the name that the gateway gives it into the full gateway address. Instead, it returns what information it has. This can make the address appear as user@QMailServerName or user@QMailSiteName (depending on how QMail routing and address list exchange is configured), and Microsoft Exchange Server will send a non-delivery report (NDR) because it does not understand either the ServerName or the SiteName routing. This feature of QMail allows for sites that do not exchange address lists but want to send messages to users in the other sites. However, it has strange effects when sending out through any gateway, including Microsoft Exchange Server. With multiple QMail servers that are backboned over Microsoft Exchange Server, the QMail servers do not have a direct connection between each other, so messages must first be transferred to Microsoft Exchange Server and then delivered to the other QMail servers. This is not an efficient structure and is not recommended due to the inherent difficulties in translating a message from one format to the other and then back again. Because all messages going to and from QMail and Microsoft Exchange Server must first be converted into MS Mail (PC) format, then converted into the correct format for the next system, and then back again, backboning introduces substantial overhead that can be avoided by using the preceding configuration. However, for small, isolated sites, backboning over Microsoft Exchange Server may be the only way to deliver messages. In this environment, backboning functions well. The Macproxy.dll may be required in this configuration if more than one QMail server has a connection to Microsoft Exchange Server. 3.2 Internet Mail Service 3.2.1 Internet Mail Service Text Quoting Registry Parameters A new registry value has been added under the Internet Mail Service Parameters key to provide control over the Internet Mail Service text quoting behavior. The UseRTFText registry value is a DWORD value that specifies if reply-and-forward text will be quoted in outgoing messages that are not sent with rich text formatting. If it is enabled (non-zero), Internet-style quoting is applied to reply-and-forward text by inserting a greater than (>) character before each line. If UseRTFText is disabled (set to zero or not present), no Internet-style quoting is applied. UseRTFText is enabled by default. NOTE: UseRTFText also affects word-wrap. If enabled, text lines in all non-TNEF messages are wrapped at a fixed column. The word-wrap setting for non-MIME messages on the Internet Mail Service properties in the Microsoft Exchange Server Administrator program is ignored. 3.2.2 Using Internet-style Quoting with List Servers When the UseRTFText registry parameter is enabled, Internet-style quoting is applied to forward-and-reply text in messages. This quoting is also applied to text that is cut and pasted from a message into a compose note. When sending a message with a command to a list server, it is important to make sure the text is not quoted; otherwise, the list server cannot interpret the command. You can type the command manually. Alternatively, you can use the Paste Special command to paste the plain text. Do not paste the formatted text. 3.2.3 Site Address Required to Start the Internet Mail Service The Internet Mail Service determines the domain to use in the originator address for reports from the site address for its address type. If you set the address type in the Internet Mail property page of the Internet Mail Service to a type for which there is no site address, the Internet Mail Service will not start. If you want to set an address type without specifying the site address, you can modify the registry by adding the value SiteDomain to: SYSTEM\CurrentControlSet\Services\MSExchangeIMC\Parameters SiteDomain is a REG_SZ value that should be set to the domain you want to be used in the originator address for reports generated by the Internet Mail Service. 3.2.4 Sending Imported Messages Using the Internet Mail Service Messages that have been imported into Microsoft Exchange Server with the migration tools cannot be embedded in messages and sent through the Internet Mail Service. The Internet Mail Service cannot process the embedded message and generates a non-delivery report (NDR). The problem also occurs if you try to embed an unsent message into another message and send it out on the Internet Mail Service. To work around this problem, cut and paste the contents of the migrated message or forward it instead of embedding it in another message. 3.2.5 Microsoft Exchange Server Routing Table The Internet Mail Service reads the Microsoft Exchange Server routing table every 15 minutes to determine its routing responsibilities. The 15-minute interval is configurable through the Windows NT registry. It is recommended that you use this default setting (0xF). If you need to modify it, use the following registry key: SYSTEM\CurrentControlSet\Services\MSExchangeIMC\ Parameters\RouteCalculationInterval NOTE: Setting this registry value to 0x0 means the Internet Mail Service checks the routing table only at startup. The Internet Mail Service checks the Last Modified box for the routing table to determine whether changes have been made. If the last modified time in the routing table is newer than the timestamp on the Route.txt file, the Internet Mail Service will update its routing information and create the Route.txt file in the Exchsrvr\Imcdata\Log directory. Using the Route.txt File The Route.txt file contains the current routes that the Internet Mail Service uses to determine delivery destinations for connected sites. This file is not used by the Internet Mail Service for routing; it's a text representation of the routes that the Internet Mail Service is responsible for. If changes are made to the routing table, the Internet Mail Service copies the existing Route.txt file to Route.old and updates the Route.txt file with the latest changes at the next checking interval. The Internet Mail Service always reads the routing table at startup. Troubleshooting a Routing Problem If the Internet Mail Service does not route correctly, check the following configuration items: - Entries in the Control Panel, Network, TCP/IP, and DNS configuration. The host name and domain name need to be reachable by other computers (that is, registered within the DNS or specified in the local Hosts file). - Internet Mail Service Connected Sites property page to ensure that all entries are correct. - Routing table using the Site Addressing object, Routing property page in the Administrator program. In addition, check the following files: - Route.txt - the current routes the Internet Mail Service services. - Route.old - the previous routing information the Internet Mail Service used before it created the new Route.txt file. Equal Cost Routes and Undelivered Mail If your configuration consists of multiple routes with the same cost for a destination, the Internet Mail Service balances loads between the different routes. If a route has problems, any queued mail for that destination is not rerouted through a different route. If the problems continue longer than the maximum allowed delivery time-outs, a non-delivery report will be generated. Least Cost Routes If your configuration contains multiple routes to the same destination with different costs, the Internet Mail Service uses only the least cost route defined. If that connection is unavailable due to a communication problem, the Internet Mail Service does not use any of the higher cost routes. Correct configuration of your DNS with MX records can override this behavior and allows all incoming mail to use a secondary route. Routing Table Can't Be Read If the Internet Mail Service has started and the routing table cannot be read at the specified checking interval, the Internet Mail Service continues to use its existing routing information. No event is logged. Correction to the Administrator's Guide In the "Using Routing Addresses for Address Space Entries" section in Chapter 11, the Routing Address property page no longer needs to be used when connecting two replicated Microsoft Exchange Server sites. It can be used to send mail to different organizations that are not replicated. 3.2.6 Maximum Number of Inbound and Outbound Connections Setting the maximum number of inbound and outbound connections to 0 in the Connections property page does not stop the Internet Mail Service from accepting inbound or attempting outbound connections. To stop both inbound and outbound connections, set the Transfer Mode to None. To stop inbound connections, click Outbound Only. To stop outbound connections, click Inbound Only. 3.2.7 Removing an Installed Internet Mail Service Before removing the Internet Mail Service, be sure there are no messages left in the queues awaiting delivery. To flush the queues: 1. In the Connections property page, set the Transfer Mode to None (Flush Queues). 2. Set the retry interval for the connector message queues to a short interval, such as .25 (15 minutes). 3. Set the message time-outs for normal, urgent, and non-urgent mail to one hour. 4. Restart the Internet Mail Service. The Internet Mail Service does not accept new messages and continues to process the messages already in its queues. Non-delivery reports (NDRs) are generated for any messages that cannot be delivered in one hour (for example, host unreachable). Check the status of the queues in the Queues property page. When the queues are empty, shut down the Internet Mail Service, and begin removing the installation. 3.2.8 Loopback Detection The Internet Mail Service allows configurations where SMTP connections are made to itself. There are cases where this behavior is desired, such as when one Microsoft Exchange Client user addresses another using an SMTP proxy. However, this can also allow loopbacks and inefficient configurations. You can configure the Internet Mail Service so that it won't initiate SMTP connections if the destination host's IP address matches its own. Instead, it creates a non-delivery report (NDR) for the message. To enable the Internet Mail Service's connection loopback detection, create the following DWORD registry value, and set it equal to 1. SYSTEM\CurrentControlSet\Services\MSExchangeIMC\Parameters\ DisableLoopbackConnection 3.2.9 Delivery Restrictions for Custom Recipients Delivery of inbound messages to custom recipients cannot be controlled using the Delivery Restrictions property page. 3.2.10 Internet Mail Service Performance Monitor Counters The Microsoft Exchange Server Performance Monitor counters for the Internet Mail Service described in Chapter 17 of the Microsoft Exchange Server Administrator's Guide have changed. Name Description ========================================================================== Counters for MTS-IN Queued MTS-IN The number of messages awaiting final delivery in Microsoft Exchange Server. Bytes Queued MTS-IN The size, in bytes, of messages that have been converted from Internet Mail and are awaiting final delivery within Microsoft Exchange Server. Messages Entering MTS-IN The number of messages entering the MTS-IN folder after conversion from Internet Mail format. Counters for MTS-OUT Queued MTS-OUT The number of messages waiting to be converted to Internet Mail format. Bytes Queued MTS-OUT The size, in bytes, of the messages waiting to be converted to Internet Mail format. Messages Entering MTS-OUT Messages that have entered the Internet Mail Service MTS-OUT folder for conversion to Internet Mail format. Messages Leaving MTS-OUT The number of messages entering the outbound queue. Associations Connections Inbound The number of current SMTP connections to the Internet Mail Service established by other SMTP hosts. Connections Outbound The number of current SMTP connections the Internet Mail Service has established to other SMTP hosts. Connections Total Outbound The total number of successful SMTP Connections that the Internet Mail Service has established since it was started. Connections Total Inbound The total number of SMTP connections the Internet Mail Service has accepted from other hosts since it was started. Connections Total Rejected The total number of SMTP connections that the Internet Mail Service has rejected from other hosts since it was started. Connections Total Failed The total number of SMTP connections the Internet Mail Service has attempted to other hosts that failed since it was started. Internet Queues Queued Outbound The number of messages from Microsoft Exchange Server that are queued for delivery to the Internet. Queued Inbound The number of messages received from the Internet destined for Microsoft Exchange Server. Counters for NDRs NDRs Total Inbound The total number of non-delivery reports generated for outbound mail. NDRs Total Outbound The total number of non-delivery reports generated for inbound mail. Counters for Messages/Bytes Transferred Inbound Bytes Total The total size in bytes transferred into Microsoft Exchange Server. Outbound Bytes Total The total size in bytes transferred from Microsoft Exchange Server. Inbound Messages Total The total number of Internet messages delivered into Microsoft Exchange Server. Outbound Messages Total The total number of outbound messages delivered to their destinations. 3.2.11 Internet Mail Service Queues The "Selecting a Queue" section in Chapter 17 of the Microsoft Exchange Server Administrator's Guide has changed. Option Description =========================================================================== Inbound messages awaiting conversion Incoming messages waiting to be converted by the Internet Mail Service and then delivered to the information store. Inbound messages awaiting delivery Messages in the MTS-IN folder in the information store. Outbound messages awaiting conversion Outgoing messages received from the MTA and waiting to be converted by the Internet Mail Service. The next destination is the out queue. Outbound messages awaiting delivery Messages queued for delivery in the Internet Mail Service scheduler, which roughly corresponds to the message files in the Imcdata\Out directory. Because some messages require delivery to multiple hosts, there are more entries in the queue than there are files in the directory. 3.2.12 Using a Wildcard MX DNS Record If you are using a wildcard MX DNS record, the Internet Mail Service appends the default domain from your TCP/IP configuration to each host name before trying to resolve it in DNS. To prevent this, create a REG_DWORD registry value named DisableResolverSearchList under the SYSTEM\CurrentControlSet\Services\MSExchangeIMC\Parameters key, and set its value to 1. This stops the Internet Mail Service from appending a domain to host names before trying to resolve them. 3.2.13 Using the Internet Mail Service as a Site Connector In Chapter 8 of the Microsoft Exchange Server Concepts and Planning Guide, the "Connecting Microsoft Exchange Server Sites over the Internet" section has changed. The following information supplements the section and describes steps that can be eliminated. - Step 1: Multiple Internet Mail Services in one site are no longer required. - Step 8: The address space routing address is no longer required. Sites that can be connected (reached) only through site B (that is, site A has no direct connection to them) do not need to be added to the Connected Sites property page on the Internet Mail Service in site A. The Internet Mail Service reads the routing information from the Microsoft Exchange Server routing table and determines that these sites are routable through site B. - Step 9: You no longer have to add routing addresses for address spaces that are serviced in other sites that an Internet Mail Service connects to. When sites are replicated, the Internet Mail Service accesses this information directly. In addition to the steps in the Microsoft Exchange Server Concepts and Planning Guide, use the following procedure to connect site A and site B. 1. Use the Connected Sites property page in site A to add a new connected site for site B. 2. Using the Routing Address property page, add the routing address for the Internet Mail Service computer on site B. 3. Add site A to the Connected Sites property page for the Internet Mail Service on site B and use the routing address for site A. - Step 10: It is no longer necessary to define custom recipients in the site where the Internet Mail Service servicing the external Internet mail resides. 3.2.14 Connecting Sites with the Internet Mail Service For best performance when connecting sites, configure the Internet Mail Service to use MIME encoding. When sending rich text formatting, the Internet Mail Service handles attachments differently when performing MIME encoding than it does with uuencode. Attachments are transmitted in rich text format, instead of being broken out separately as they are in uuencoded messages. Due to the internal design of the Internet Mail Service, this results in much better performance in processing messages sent with rich text formatting. Therefore, to maximize site replication performance, it is recommended that you use MIME encoding with rich text formatting when connecting sites using the Internet Mail Service. 3.2.15 Do Not Use an Ending Period to Specify an FQDN When specifying message delivery by domain, a fully qualified domain name (FQDN) ending with a period (.) is not supported. A non-delivery report (NDR) specifying "host unreachable" is generated. 3.2.16 Specifying the Maximum Message Size The description of the No limit option in the Internet Mail Service General property page in the "Specifying the Maximum Message Size" section in Chapter 11 of the Microsoft Exchange Server Administrator's Guide should read as follows: Send an inbound or outbound message of any size. 3.3 Dynamic RAS Connector 3.3.1 Dynamic RAS Connector Requires Override Account Information Override account information is required to log on to a remote network using the Dynamic RAS Connector. In the Override property page of the Dynamic RAS Connector, you must specify either the service account used in the remote site or a Windows NT user account that has Send As and Mailbox Owner (User role) permissions for the Servers or Configuration containers in the remote site. 3.3.2 Using RAS over NetBEUI, IPX, and TCP/IP RAS supports NetBEUI, IPX, and TCP/IP transport protocols, and Microsoft Exchange Server can operate over any of these transports; however, some special configuration and topology settings are required. For RAS to operate correctly over one of these supported protocols, the protocol must be properly installed and configured in Windows NT. In addition, the two systems involved in the RAS connection must have no other source of connectivity other than the RAS connection itself. You cannot have a configuration where the computers have any LAN-based connectivity to each other except when connected over the RAS link. It is also important to ensure that these computers have never communicated over any connection other than RAS since the last time they were restarted. This is important for a testing environment because Windows NT caches information about computer accessibility. If there has been a prior LAN connection other than RAS, this connection information can cause confusion to the network layers. Microsoft Exchange Server supports the following RPC bindings over a RAS connection: NetBIOS over NetBEUI (NB_NB) Native SPX (NCACN_SPX) Native TCP/IP (NCACN_TCPIP) 3.3.3 RAS Authentication Issues The Windows NT RAS services currently support two authentication mechanisms. The first is to use the credentials of the currently logged on user to establish the connection to the remote server. The second is to use credentials that have been supplied by the user. The decision as to which method to use is controlled by the RAS Phone Book entry used to reach the remote system. If the check box is selected to use the credentials of the logged on user, Microsoft Exchange Server uses the credentials defined by the service account specified during Setup. These are the credentials used by the MTA when running on the Windows NT Server and are the only default credentials available. If the local service account has full Administrator permissions within the remote Microsoft Exchange Server site, this will work correctly. It should be noted, however, that the Microsoft Exchange Server MTA requires a duplex communication link between the two systems. This means that the remote MTA also attempts to bind back to the local computer over RPC. To do this, the credentials from the remote system to access the local system must also be present and validated. If the check box is not selected, credentials must be provided at the time the Microsoft Exchange Server MTA attempts to connect to the remote server over RAS. To do this, the local MTA uses the user account information provided in the RAS Override property page of the RAS Connector. The information supplied here should be an authorized account in the remote system that can both log on to the remote system over RAS and access the Microsoft Exchange Server directory database with full permissions. It is recommended that the service account of the remote Microsoft Exchange Server installation be used because it is guaranteed to have the correct permissions within the remote installation. The administrator must then ensure that this account has permissions to access the network over a RAS connection. This is controlled by Windows NT and the RAS Administrator program. Because the two sites being connected by the RAS Connector have no trust relationship between them, the override logon values must be set. The user name, password, and domain information supplied in the RAS Override property page needs to have Microsoft Exchange Server administrative and RAS dial-in permissions in the remote site. For this reason, the service account of the remote site should be used in the Override property page. 3.3.4 RAS over TCP/IP RAS Connectors can use TCP/IP network protocols. However, there is currently a Windows NT RAS problem that requires some special configuration to make this work correctly. Windows NT uses the WINS server to locate computers on the network. You cannot run the WINS services on the same computer that you are running the RAS Connector. There is a problem where the RAS software cannot do correct name resolution with the WINS server if both services are running on the same computer. This means that you must have at least two Windows NT Servers running in a remote site: one that supports the RAS Connectors and one that is running the WINS services. When using TCP/IP over RAS, the connection between sites should always be made from the same site. Due to the way that RAS and the WINS software registers and assigns IP addresses, problems can occur if both sites are attempting to establish connections. Configuring one site with a schedule to be remotely initiated and then having the other site establish the connections on a timely basis provides good bidirectional message throughput. 3.3.5 Microsoft Exchange Server Computers Configured to Use a Dynamic RAS Connector Will Fail to Connect if Windows NT 4.0 Service Pack 2 (SP2) is Applied Windows NT 4.0 Service Pack (SP) 2 introduces a problem in Windows NT RAS support that will cause Microsoft Exchange Server computers to fail when attempting to use a Dynamic RAS Connector. When using RAS Dial to attempt to connect to the server, the client will wait at the Registering your computer on the network dialog box, and then the 718 error occurs. Prior to Windows NT 4.0 SP2, a problem existed on some systems depending on the choice of network protocol. The modem connects for approximately 10 seconds and then hangs up. The Event Log reports that the remote caller was successfully authenticated. However, the message transfer agent (MTA) logs "Unable to bind over RPC" events. To correct this problem, the following DLLs have been updated: Rpcltccm.dll, Rpcltscm.dll, and Rpcrt4.dll. They are available as part of Windows NT 4.0 SP3. 4.0 Backup and Restore 4.1 Ntbackup.exe: Windows NT Server 3.51, Service Pack 5 Microsoft Exchange Server currently requires Windows NT 3.51 (build 1057) with Service Pack 5 or later for installation. If you install Service Pack 5 after installing Microsoft Exchange Server, a version of Windows NT Backup (Ntbackup.exe) without Microsoft Exchange Server functionality is installed. If this occurs, copy Exchsrvr\Bin\Ntbackup.exe from the Microsoft Exchange Server compact disc to your Windows\System32 directory. 4.2 Restoring the Public or Private Information Store on a Different Server To restore either the public or private information store on a server other than the one used for backup, select the following check boxes in the Restore Information dialog box. Erase all existing data Private Public NOTE: You must select both Private and Public, even if the backup contains only one of these databases. 4.3 Restoring the Information Store to an Alternate Server The "Restoring an Information Store to a Different Server" section in Chapter 15 of the Microsoft Exchange Server Administrator's Guide does not completely document the procedure for restoring the information store to an alternate server. The following is more complete. If you need to restore specific items from a particular mailbox or public folder and you do not want to restore over the existing information store, you can restore the information store to an alternate server. This alternate server cannot replicate its directory with the existing organization. To recover specific user mailbox data: 1. Find an alternate server that is not replicating with the existing organization. 2. Install Microsoft Exchange Server on the alternate server, and create an organization and site with the same names as those of the backed up server. 3. Run Backup, and restore the information store. In the Restore Information dialog box, specify the alternate server name for the destination server, and select Erase All Existing Data. 4. In the Administrator window, select the server and open its property pages. 5. Select the Advanced property page. Under the DS/IS consistency adjustment, select All Inconsistencies, and click Adjust. This runs the DS/IS consistency adjuster to synchronize the directory and information store. 6. Grant yourself permissions for the mailbox from which you want to restore data. If restoring data from a public folder, click any mailbox. 7. With the User Profile Editor, create a user profile. 8. Log on to the client, and move the data to a .pst file. You can then give the .pst to the user. 4.4 Command Line Limit for Backup Batch Processes If you use a batch file to launch backup processes on multiple Windows NT Server computers, you must limit command line strings to fewer than 256 characters. It is recommended that you specify no more than six servers in a command line string. Use the APPEND command to segment batch processes that require backing up more than six servers. 5.0 Migration 5.1 Character Mismatching with Some Code Pages The Migration Wizard uses the code page information in the packing list file to determine how to convert characters in migrated data. When the packing list has code page 10000 or 437 specified, some characters can be mismatched as follows: Characters included Incorrectly mapped to Not equal ? Infinity 8 Less than or equal = Greater than or equal = Delta ? Sigma ? Pi ? Function symbol ? Approximately equal to ~ Delta symbol ? Diamond ? fi ? fl ? i with no dot i Brave ? cp 10000 chars 250 252 253 ? Reverse not not Alpha a Gamma G Tau t Phi F Theta T Omega O Epsilon e Union n Exactly equal to = Square root v Superscript n n cp 437 chars 244 245 ? 5.2 Backslash Characters in Directory Sections of Migration Files The Migration Wizard tries to import all directory sections in the migration files without modifications. If there is a single backslash (\), it is interpreted as an escape character. If the next character is an "r" or an "n," the two characters are interpreted as a carriage return or a new line character, respectively. If the next character after the backslash is not an "r" or an "n," a warning is logged in the application log. If you are creating a source extractor, you can avoid this problem by replacing all backslash characters with two backslashes (\\) in the directory section. If you see the error in the application log, you can modify the directory section in the primary file by deleting the backslash, or replacing it with two backslashes. NOTE: This is not a problem with messages, attachments, schedule information, or personal address books. 5.3 MS Mail (PC): Using SUBST Drive When Migrating from MS Mail (PC) The SUBST drive command cannot be used when migrating data from MS Mail (PC). To access your MS Mail (PC) mail data directory, it is recommended that you specify the local path or share the directory and use the net use command. Using the SUBST command results in MMF data not being migrated. 5.4 MS Mail (PC): Invalid Server Specified During Microsoft Mail (PC) Postoffice Migration When migrating Microsoft Mail (PC) postoffice information to Microsoft Exchange Server, the Windows NT user account used to log on to Windows NT Server must also have permissions on Microsoft Exchange Server. If you are attempting to migrate postoffice information, and the Windows NT account does not have sufficient permissions on Microsoft Exchange Server, you receive the error message "Invalid server specified." To migrate postoffice information successfully, you must assign Microsoft Exchange Server permissions for this account or log off Windows NT Server and log on with an appropriate Windows NT user account. 5.5 MS Mail (PC): International Issues with Code Pages and MS Mail Postoffices The Microsoft Mail (PC) migration component of the Migration Wizard accesses the postoffice using the Microsoft Mail MAPI service. The Migration Wizard ships with the version of the Microsoft Mail MAPI service for the appropriate server language: U.S., French, German, or Japanese. The Microsoft Mail MAPI service assumes the postoffice is in the default code page for that language. For French, German, and U.S., this is code page 850. For Japanese, this is code page 932. If the postoffice uses a different code page, some non-7 bit ASCII characters will be mapped incorrectly during migration because the characters are actually in one code page but assumed to be in another. You must use the localized version of the MS Mail MAPI service that matches the language of the postoffice (Microsoft Mail for PC Networks 3.x) from which you are migrating. For example, if you want to migrate a Swedish postoffice to a computer running an English version of the Administrator program, first copy the Swedish Microsoft Mail Msfs32.dll file in the Windows\System32 directory over the English Msfs32.dll file prior to running the Migration Wizard. This prevents the message subject from being truncated to 40 characters. For Far East postoffices, the DBCS-enabled MS Mail MAPI service gathers its settings from the Windows NT environment. Therefore, to migrate a Korean postoffice, install the Migration Wizard on a Korean Windows NT computer. The following lists the postoffice code pages and the corresponding Windows NT code pages the data is translated into. Language Postoffice Windows NT Chinese (Simplified) 936 936 Chinese (Traditional) 950 950 Czech 852 1250 Danish 850 1252 Dutch 850 1252 English 850 1252 Finnish 850 1252 French 850 1252 German 850 1252 Greece 737 1252 Hungarian 852 1250 Italian 850 1252 Japanese (3.0) 932 932 Japanese 932 932 Korean 949 949 Norwegian 850 1252 Polish 852 1250 Portuguese 850 1252 Russian 866 1251 Spanish 850 1252 Swedish 850 1252 Turkey 737 1252 5.6 Running Lotus cc:Mail and Novell GroupWise Migration on Intel Processors Gives Best Performance During Lotus cc:Mail and Novell GroupWise migration, 16-bit code is run as part of the extraction phase of the migration process. Running extractors on RISC platform computers results in significantly slower migration performance due to 16-bit code running Intel x86 emulation mode. Performance for the import phase of the migration process is not affected. For maximum performance, run the migration extraction phase for Lotus cc:Mail and Novell GroupWise on a computer with an Intel processor. 5.7 cc:Mail Migration 5.7.1 Code Pages The migration files produced by the cc:Mail source extractor are created in the code page specified on the first line of the PostOfficeName.pkl file. The .pkl file is in the current Windows default code page (900 or 1200 series code page), not the code page listed on the first line of that file. 5.7.2 Migrating cc:Mail Post Offices on Microsoft Windows NT Server RISC Computers The OS/2 version of Lotus cc:Mail Export.exe is not supported for RISC computers running Microsoft Windows NT Server. Use MS-DOS Export.exe version 5.13 or later when running the Microsoft Exchange Server Migration Wizard to migrate cc:Mail users and bulletin boards on a RISC computer running Windows NT Server. 5.7.3 One-Step Migration for Japanese cc:Mail Fails to Import When Long Bulletin Board Names Exist When performing a one-step migration for a Japanese cc:Mail post office containing long bulletin board names, no data is migrated. The data is extracted successfully to migration files but fails on import as part of a one-step migration. To import the extracted data from the migration files, use the Import from Migration Files option in the Migration Wizard. Microsoft Exchange Server mailboxes and Windows NT user accounts will be created as expected, and message data will be imported. 5.8 Collabra Migration 5.8.1 Malformed DBCS Characters in Forum or Category Names It is possible for Collabra to have malformed double-byte character set (DBCS) characters in the Forum and Category boxes. The Migration Wizard cannot correctly interpret the data that follows malformed DBCS characters and may fail to migrate the data. When migrating Japanese, Korean, Chinese Traditional, or Chinese Simplified data, ensure that all DBCS characters in the Forum and Category boxes are valid. NOTE: DBCS characters can become corrupted when a string of characters is edited on a computer that is running with a different code page from the original string it was created with. 5.8.2 Empty Forums Not Included in Event Log "Forums Created" Counter If you extract Collabra forums that contain no documents, these forums are not included in the Forums Created counter (Event ID: 100003) written to the event log. However, during the import phase, the number of public folders created, including forums with no data, are recorded in the Accounts were created successfully counter (Event ID: 8001). 5.8.3 Collabra QuickLinks Not Supported Collabra QuickLinks cannot be migrated using the Migration Wizard. Messages that contain QuickLinks are migrated with a placeholder indicating that a QuickLink exisited in the original message. An event log message stating Collabra QuickLinks are removed from the migrated messages is generated. 5.9 GroupWise Migration 5.9.1 Migrating Large OLE Objects from Novell GroupWise OLE objects that are approximately 1 MB or greater will not be migrated from Novell GroupWise to Microsoft Exchange Server. 5.9.2 Migrating Macintosh Binary Files from Novell GroupWise Some Macintosh binary file attachments created in the Novell GroupWise Macintosh client and stored in the Novell GroupWise database fail to open after migration. The resource fork element of the MacBinary file is not available to the Migration Wizard and the MacBinary header information cannot be saved during extraction. Macintosh binary files can be accessed using the Macintosh RESEDIT utility. Configure correct file Type and Creator information to the Macintosh binary file after migration. The modified file should enable the associated application when selected. 5.9.3 Migrating a User with Partial Proxy Access Rights Does Not Generate an Error To migrate GroupWise users, the Migration Wizard requires that each user grant read and write access rights to Mail/Phone, Appointments, Notes, Tasks, and selecting "Read Items Marked Private." If none of these access rights are selected, the error is detected and recorded in the application event log. If partial access rights are granted (for example, grant read and write access to Mail/Phone and Appointments, but no rights to Notes and Tasks), the migration completes without reporting an error accessing Note and Task information. Only Mail/Phone and Appointment data is migrated. Due to Novell GroupWise implementation issues, Microsoft Exchange Server cannot detect and report on access rights to individual mail types. 5.9.4 Possible Issues Running the Sample Proxy Access Macro The sample proxy access macro provided with the migration tools uses Novell Shared Code facilities to grant proxy access rights to the User ID performing the migration. GroupWise 4.1x clients running on Windows 3.1 and Windows 95 can run the macro successfully. GroupWise 4.1x clients running on Windows NT may fail due to a problem in Novell GroupWise where the sample macro cannot find the user ID to whom proxy access rights are to be granted. As a result, proxy access rights are granted to the first entry in the address list. This problem with Novell GroupWise is corrected by a Novell GroupWise patch release to the affected client installations. Novell GroupWise patches can be obtained from Novell GroupWise technical support. 5.9.5 Far East Languages and Novell GroupWise Migration To migrate from Novell GroupWise to Microsoft Exchange Server using the Migration Wizard, the Novell GroupWise version 4.1x client must be installed and running on the computer performing the migration. However, data cannot be migrated in some scenarios because the Novell GroupWise 4.1x client cannot be successfully installed and run on some Windows NT Far East versions and platforms. The following table indicates the Far East languages, versions, and platforms that the Novell GroupWise 4.1x client runs on: Windows NT 3.51 Windows NT 4.0 | Intel | Alpha | | Intel | Alpha | Chinese Simplified | | | | | | Chinese Traditional | | | | X | | Japanese | X | | | X | X | Korean | X | | | X | X | NOTE: The Migration Wizard runs on the above Far East language, version, and platform combinations indicated by an "X." 5.9.6 Running GroupWise Migration from the Migration Wizard Novell GroupWise dialog boxes appear each time an OLE object is extracted when migrating messages containing OLE objects from Novell GroupWise. This is the only method for obtaining this data and is expected behavior. You must run the Migration Wizard in the foreground and allow no user interaction with other applications during the Novell GroupWise extraction process. When the extraction process has finished and the import process has begun, this restriction no longer applies. 5.10 PROFS Migration 5.10.1 Typical PROFS Extractor MIGWIZRD Scenario Command Performed on Function =========================================================================== migwizrd host migrator account Customize MIGPARMS DATA file and select data to extract. migxfer host migrator transfer account Transfer IFF reader files to 191 disk and set up .bat file for transfer. receive xfer.bat migrator bat ( ASCII CRLF) PC Download transfer .bat file. migrator PC Transfer IFF files to PC. 5.10.2 Typical PROFS Extractor Command Line Scenario Command Performed on Function =========================================================================== xedit host migrator account Edit the MIGPARMS DATA file to set up the migration parameters. These are the same parameters that are set up on the first two screens of Migwizrd. migusers create remaddr host migrator account Create remote address list. migusers send remaddr host migrator account Create remote address download files. migusers create mailbox host migrator account Create mailbox list. migusers send mailbox host migrator account Create mailbox download files. migrator accounts file (6) host migrator account Use 6 threads to migrate all accounts in "accounts file." migxfer host migrator transfer account Transfer IFF reader files to 191 disk and set up.bat file for transfer. receive xfer.bat migrator bat (ASCII CRLF) PC Download Transfer.bat file. migrator PC Transfer IFF files to PC. 6.0 International Issues 6.1 Far East Languages Not Supported for LDAP In this release, LDAP does not support Far East languages. 6.2 Installing Foreign Language Display Templates Display templates for the server language are included with server installation. To enable the address detail display for additional client languages, you must install foreign language display templates on a Microsoft Exchange Server computer. Foreign language templates are provided on the Microsoft Exchange Client compact disc for the client's language. To install a template on a Microsoft Exchange Server: 1. Run the Microsoft Exchange Server Administrator program. 2. On the Tools menu, click Directory Import. 3. Click File. 4. In the Tpl directory on the Microsoft Exchange Client compact disc, select the .csv file for the template you are installing. 5. Click OK. 6.3 Microsoft Exchange Server and Windows NT Server Languages Must Match to Use Performance Monitor Counters If the languages for Microsoft Exchange Server and Windows NT Server are not the same, Performance Monitor counters will not work as expected. Copy several .pmw files from the Setup\platform\Bin directory on the Microsoft Exchange Server compact disc that match the Windows NT Server language to the Exchsrvr\Bin directory on the Microsoft Exchange Server computer. The files are: Exhealth.pmw Exhist.pmw Exload.pmw Exqueues.pmw Exusers.pmw Imcqueue.pmw Imcstats.pmw Imcflow.pmw 6.4 Considerations for French Canadian Customers The following are considerations for French customers in Canada. - Only the French Microsoft Exchange Client is included in the North American English version of the Microsoft Exchange Server package. The French Microsoft Exchange Server is available separately. - French Web access is a feature of the French Microsoft Exchange Server and is available with the French Microsoft Exchange Server package. It may also be available on the Web at www.microsoft.com. 6.5 Maintaining Index Consistency Some changes have been made to sorting behavior in Windows NT 3.51 SP5 and Windows NT 4.0 that may require you to defragment your Microsoft Mail 3.x database to maintain index consistency. This applies only if you meet all the following criteria: - You use directory synchronization to update address books between Microsoft Exchange Server and a Microsoft Mail 3.x postoffice. - You use any of the following languages in your Microsoft Mail 3.x postoffice: Korean Arabic Hebrew Thai Vietnamese - You previously used Windows NT 3.51 and have now upgraded the computer running the directory synchronization service to Windows NT 3.51 Service Pack 5 or to Windows NT 4.0 or later. As soon as possible after upgrading your operating system, you should perform the following steps to regenerate indexes: 1. Shut down your directory synchronization service. 2. In the Exchsrvr\Dxadata directory, locate the Xdir.edb database file. 3. Use the Edbutil utility located in the Exchsrvr\Bin directory to defragment this database. 4. Restart your directory synchronization service. For more information on Edbutil, see Chapter 17 in the Microsoft Exchange Server Administrator's Guide. 7.0 Directory and Information Store 7.1 Running Directory Import and Export in Raw Mode Microsoft Exchange Server supports a command line directory import and export utility (see the "Command Line Switches" topic in online Help for the Administrator program). When using this, you can specify additional options in an Options file that allow you to further control how the import or export should be performed. One of these options is: RawMode=[Yes,No] (default No) This option is primarily intended for developers and should be enabled only by advanced users. Raw mode requires specific details about the directory schema. Files that could be imported normally are likely to fail in raw mode because they don't contain sufficient information. For more details on the directory schema, see the Microsoft Exchange Server Software Developer's Kit. 7.2 Additional Columns for Private and Public Information Stores Additional column views are available in the Logons property pages of the private and public information stores. An administrator can view information about logged on users and information store statistics in the Logons property pages. The following is a list of additional column views: Messaging Ops Folder Ops Table Ops Transfer Ops Stream Ops Progress Ops Other Ops Total Ops Client Version These column views, with the exception of Client Version, must be added by using the Columns option in the Logons property page. The Client Version column view is added to the columns view by default. Additionally, each view, with the exception of Client Version, displays statistics for the number of remote procedure calls (RPCs) of the viewed category. The Client Version view is the version of the information store provider of a user's Microsoft Exchange Client. 7.3 Command Line Directory Import and Export Parameters The following are corrections to the Administrator program online Help. The following command line parameters for column, quote, and property separators can be used for directory import and export: ColumnSeparator=<ascii value from 0-255> QuoteSeparator=<ascii value from 0-255> MVSeparator=<ascii value from 0-255> NOTE: Command line import and export support only the ASCII values that are equivalent to the separators that are available in the Administrator program directory import and export. The following command line parameter for directory export is available to specify whether hidden objects can be exported: hiddenobjects=<yes, no> 7.4 Directory Import/Export: New Quoting Behavior for Multivalued Attributes The handling of multivalued attributes by the Directory Import and Directory Export tools has changed in Microsoft Exchange Server 5.0. In Microsoft Exchange Server 4.0, if a multivalued attribute contained embedded delimiters (commas, tabs, and so forth), the attribute values making up the multivalued attribute were quoted individually. If Microsoft Excel was then used to edit the exported data file, the quotes embedded in the multivalued attribute value string were not recognized, and the attribute would be incorrectly split across several Microsoft Excel cells. In version 5.0, the entire multivalued attribute is quoted. Embedded, multivalued attribute separator characters are prefixed with a backslash (\) character. For example, a multivalued attribute with values "v,1", "v,2", and "v,3", is exported as: "v,1%v,2%v,3" A multivalued attribute with values "v%1", "v,2", and "v,3", is exported as: "v\%1%v,2%v,3" Import files generated for use with version 4.0 will still work, with the following exceptions: - If a quoted string is specified for a multivalued attribute, and the string contains one or more multivalued attribute separator characters, the string is split into multiple values unless the separator character is preceded by a backslash. Previous behavior was to treat the string as a single value. Separator characters found in exported strings are preceded with the backslash, and are correctly demoted on import. This behavior is unchanged from version 4.0, so data files exported with version 4.0 will still be importable by version 5.0. - To minimize the number of cases where this new handling of multivalued attributes causes problems in user-edited files, multivalued attribute separator characters in single-valued attributes are now ignored. In version 4.0, the value was split at the multivalued attribute separator, and only the first portion was used. In most cases, this would not generate a warning. 7.5 Size of Information Store Appendix A of the Microsoft Exchange Server Concepts and Planning Guide incorrectly states the maximum size of the information store. It is limited to 16 GB, not 16 MB. 8.0 Corrections to Documentation 8.1 What's New Chapter 5 In the "Setting Idle Time-out Connections" section, the default is for idle connections to close after 10 minutes. Chapter 7 In the "Setting Idle Time-out Connections" section, the default is for idle connections to close after 10 minutes. Chapter 8 In the "Testing from a cc:Mail Client" section, the Note requires further explanation. The text states that before testing the connection, you must add the Microsoft Exchange Server site as a cc:Mail post office using the cc:Mail Administrator program. This is true if directory synchronization has not yet occurred or if directory synchronization will never occur. If you plan to use directory synchronization after a post office has been created manually, you must delete the post office entry before running directory synchronization. Directory synchronization will re-create the post office. 8.2 Microsoft Exchange Server Administrator's Guide Before You Begin The "Before You Begin" section incorrectly documents the location of the online documentation. The following online books are available on the Microsoft Exchange Server Documentation Kit compact disc. - Microsoft Exchange Server Installation Guide (in the Install directory) - Microsoft Exchange Server Concepts and Planning Guide (in the Concepts directory) - Microsoft Exchange Server Administrator's Guide (in the Admin directory) - Microsoft Exchange Server Application Designer's Guide (in the Appdsgn directory) - Getting Started Guide (in the Getstart directory) The Microsoft Exchange Server Migration Guide is located on the Microsoft Exchange Server compact disc in the Migrate\Docs directory. In the "Folder Design Cue Cards" section, the third sentence should read: They can be accessed by choosing the Tools menu, choosing Application Design, and then choosing Folder Design Cue Cards. Chapter 2 In the option table in the "Changing the Routing Calculation Schedule" section, the last two items should be deleted. The detailed time increments do not apply to the routing calculation schedule for site addressing. Chapter 9 In the "Setting LAN Postoffice MTA Options" section, the description for the option Do Not Pick Up Mail At This Postoffice requires further explanation. It is true that this option is for sending but not receiving messages from the MS Mail postoffice for which you are configuring the Connector MTA. However, another external program must be running at the destination postoffice to assume the responsibility of distributing the mail on the destination postoffice. Chapter 15 In step 2 of the "Restoring Information After a Catastrophe" section, the run command should be Setup /r. Chapter 16 When performing maintenance on a server, you can temporarily stop monitoring activities on the server. You can put a server monitor in maintenance mode using the Maintenance Status property page on the monitor or the Administrator program command line options. Chapter 16 of the Microsoft Exchange Server Administrator's Guide inaccurately documents the command line switches to use to stop monitors for maintenance. The following command line options are available to stop monitors for maintenance: Option Description =========================================================================== - t r Suspends repairs during the maintenance mode, but sends a notification if a problem is found. - t n Suspends notification during the maintenance mode, but initiates any repairs specified by the monitor. - t nr Suspends both notification and repairs during the maintenance mode. - t Resets the monitor to normal mode. NOTE: Either the hyphen (-) or slash (/) can be used in the command line option. In the "Notification Process" section, it states "Use the Notification property page to specify how to advise administrators when a connection is in a warning or alert state." This section should include that notification is also given when connections have been restored. 8.3 Microsoft Exchange Server Installation Guide Chapter 4 In the "Creating a Client Installation Point or Network Share" section under "To set up a client installation point," the first step should read as follows: From the Eng directory on the Microsoft Exchange Client compact disc, run Setup.exe. 8.4 Microsoft Exchange Server Concepts and Planning Guide Before You Begin The "Microsoft Exchange Server Documentation" section should state that the documentation is accessible from the Help menu in the Administrator program and is also available separately as a printed document from Microsoft. 8.5 Web Access Help Change to Overview Topic for Anonymous Users In the Help Overview for anonymous users, the following sentence: To add the current folder view to your list of favorites (or bookmarks) In your Web browser, first click the symbol for Update Address. The sentence should read: To add the current folder view to your list of favorites (or bookmarks) in your Web browser, first click the symbol for Update Page Address. 8.6 Administrator Program Help In the Idle Time-out property page for POP3 and LDAP, the default is for idle connections to close after 10 minutes.
Additional query words: exfaqold
Keywords: kbusage KB156063