Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.
View products that this article applies to.
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 *:%s@uunet.uu.net.
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 foo-bar@uunet.uu.net.
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.
Keywords: KB156063, kbusage