Infralin's (not so) Frequently Asked Questions on Exchange 2000

© Gijsbert van der Linden ()
    Infralin Consultancy (http://www.infralin.com)
    Last updated: 29-1-2007

The findings included in this document are based on Exchanged 2000 with Service Pack 1 and  2 as well as Exchange 2003.

 

How do the recipient policies influence the allocation of E-mail addresses to recipients?

A recipient receives the E-mail addresses defined by the recipient policy that complies with the filter rules on the recipient policies. If multiple recipient policies comply, only the one with the highest priority is applied.

If an E-mail address is added to a recipient policy that recipient policy can be re-applied, adding that E-mail address to each related recipient.

If an E-mail address is removed from the recipient policy (by disabling the E-mail address, by removing the E-mail address from the recipient policy or by removing the whole recipient policy), the E-mail address is not removed from the recipients however. This has to be done manually (or via a script).

The primary SMTP address of a contact is not influenced by the recipient policy. It is set by the target address of the contact. The primary SMTP address of the recipient policy is, for a contact, treated as yet another secondary (proxy) SMTP address.

How do the recipient policies influence the routing of messages?

If an E-mail domain is mentioned in a recipient policy and if the responsibility flag is set on that name, Exchange will accept incoming messages to this domain and deliver the messages locally. This behavior is irrespective of the routing settings. Even if routing is enabled for this domain, no external forwarding will take place.

The responsibility flag on the primary address on the Default Recipient Policy should remain set. It is grayed by default, but you could disable it by first making another address the primary, clearing the flag and make it responsible again. Doing so results in unreliable behavior though. You could change the address of the primary address on the default recipient policy of course.

When you change the primary SMTP address of the default recipient policy you should restart the server. Some settings do not seem to become active before that.

If you share an E-mail domain with another system you should specify another unique E-mail domain as the primary address in the default recipient policy and create an additional recipient policy with a higher priority to generate the required E-mail addresses for recipients.

An E-mail domain can be mentioned in multiple Recipient Policies. The setting of the responsibility flag can be different on each Recipient Policy. If the responsibility flag is set in any of them, than this Exchange Organization is considered responsible for all mail delivery to this address, even though other occurrences of the name do not have the responsibility flag set. 

If a domain is not mentioned in a recipient policy or has not set the responsibility flag on any occurrence in the recipient policies, mail can still be delivered to recipients, but in that case routing for that domain should be enabled (on an SMTP connector). This routing is in this case even required for the delivery of mail from one mailbox to another within the same server.

The peculiarities described here around the default recipient policy have, as far as I know, not been documented by Microsoft. Apparently they are related to a bug in Exchange 2000 (tested with SP1 and 2). So be aware that future service packs might operate slightly differently.

What is the role of an SMTP Connector?

An SMTP Connector can be seen as the routing definition for an SMTP Virtual Server. It is primarily focused on outgoing traffic. Each connector defines a set of domains, the address space. For these domains messages are routed through the SMTP Virtual Server(s) indicated as Local bridgeheads.

If you select the option " Forward all mail through this connector to the following smart hosts" you can specify a smart host where the SMTP Virtual Servers will deliver all outgoing E-mails for the domains specified in the address space.

If you select the option "Use DNS to route to each address space on this connector" the SMTP Virtual Server actually uses the configuration defined on the SMTP Virtual Server itself. If the SMTP Virtual Server is configured not to use DNS, selecting this option actually does not involve the use of DNS, in spite of its title.

If you set the flag "Allow messages to be relayed to these domains" Exchange will relay both incoming and outgoing messages to either the core Exchange system or to another E-mail system. If the domain is mentioned in any recipient policy with the responsibility flag set, no routing to other systems takes place however, in spite of this setting on the SMTP Connector.

How does the SMTP Virtual Server handle incoming E-mails?

The SMTP Virtual Server is a process that handles the sending and receiving of SMTP messages. 

It listens on the specified port number (default 25) and IP addresses (default all) for incoming messages. For domains mentioned in any recipient policy with the responsibility flag set, the SMTP virtual server will deliver the messages to the core Exchange system. For domains for which routing has been enables the SMTP Virtual Server will first try to deliver the messages to a recipient within the Exchange organization. If that fails the message will be forwarded externally.

Routing can either be enabled per domain (on the SMTP connector) or per originating computer (in the Access / Relay window of the SMTP Virtual Server).

How does the SMTP Virtual Server handle outgoing E-mails?

Outgoing messages, whether they originate from within the Exchange core system or whether they are relayed, can be forwarded to a smart host or resolved through MX records in DNS.

If a smart host has been defined on an SMTP Connector, all messages for the domains specified in the address space of that SMTP Connector will be delivered to that smart host, irrespective of the settings on the SMTP Virtual Server.

If the DNS option has been chosen on the SMTP Connector, the host to which the messages are delivered is governed by the settings in the Delivery/Advanced window of the SMTP Virtual Server itself.

If the smart host entry in this window is left blank, the regular DNS settings on the Network properties of the computer are used to resolve the E-mail domain name through the MX records in DNS. 

If the smart host entry is filled, all messages handled by this SMTP Virtual Server will be delivered to that host.

If on top of that the "Attempt direct delivery before sending to smart host" flag is set, first the regular DNS system is tried. If that DNS system returns a "Name does not exist" response, the message is sent to the smart host (this feature can be used very well in an Intranet / Internet environment; if the E-mail domain is not resolved through the internal DNS system, the message is forwarded to the Firewall).

If on top of that one or more DNS servers are defined in the Configure window, those DNS servers are used to resolve the E-mail domain names, instead of the DNS servers defined in the network properties of the computer.

If multiple DNS servers are defined, either on the network properties of the computer or in the Configure windows of the SMTP Virtual Server, the first DNS server is tried first. If that DNS does not respond at all, the second DNS server is tried. If a DNS server responds with a "Name does not exist" message, no other DNS servers are tried (see also the FAQ on IP Networking).

This means that this feature cannot be used to resolve names through the internal DNS server first and, if it is not found there, through the external DNS server. If this is required two SMTP (virtual) servers could be used in a row.

How does the SMTP Virtual Server cope with hosts that are not available?

If a message is sent to a host resolved through a DNS server and that host is not available, the SMTP Virtual Server keeps on trying to send the message as configured on the Delivery tab of the SMTP Virtual Server. This is irrespective of whether the host was resolved through a name in a smart host entry pointing to an A record or through the resolving of an E-mail domain name pointing to an MX record.

If none of the configured DNS servers on either the network configuration or in the Configure window mentioned above respond at all, the SMTP Virtual Server will keep on trying to access one of the configured DNS servers.

If a DNS server responds with a name not known response and if no other options are available to send the message, a non-delivery message will be generated right away (this can only be caused by a configuration error, not because a server is not available).

If however a message is send to a smart host indicated by its IP address between brackets, and the smart host does not respond, a non-delivery message is generated right away.

This means that if a single smart host is used that smart host should always be configured through a DNS entry!

How to use Contacts to relay E-mail messages?

A contact is a recipient with only an SMTP address entry and without a mailbox. It points to a mailbox in another E-mail system.

Contacts can be entered manually, but are typically replicated from another E-mail system through utilities like the Active Directory Connector (ADC) or the Replicate utility.

Each contact should have a Target Address. This is the E-mail address of the contact in his home E-mail system.

Each contact could have, in addition to its target address, 1 or more secondary (proxy) addresses.

If a message is sent by a user of the Exchange system to a contact, that message will be sent to the target address of the contact (assuming Exchange is properly configured to handle outgoing messages for that E-mail domain).

If the SMTP domain used by a contact is mentioned in the recipient policies with the responsibility flag set, or if routing is enabled for that domain, the Exchange system can also receive messages for a contact. These messages are then resend to the target address of the contact.

If one sets up a contact with a target and one or more secondary addresses, one can this way translate the envelope address of a message from one of the secondary addresses to the target address.

If the contact has only a single (target) address, Exchange still tries to resend this message, assuming again that the conditions for incoming and outgoing E-mails are met. In this case the responsibility flag for the domain name used in the address should be cleared and routing for that domain enabled (see FAQ on recipient policies). 

How to setup a Windows 2000 system in a shared E-mail domain environment?

This scenario is typically used when migrating users from an Exchange 5.5 Organization to another (native-mode) Exchange 2000 organization, while keeping the same SMTP addresses. In this description the shared E-mail domain name is assumed to be "company.com".

  • Change the primary SMTP address of the Default recipient policy into something unique for this Organization, e.g. "@<organization-name>.company.com ".

  • Add a new E-mail address to the Default recipient policy with the following settings:

    • Type: SMTP

    • Address: @company.com

    • Unmark the responsibility checkbox

  • Mark the checkbox in front of the just created row.

  • Do not update all related recipient addresses.

  • Add a new recipient policy with the name company.com

  • Modify the Filter rules and leave all recipient categories marked.

  • On the E-mail addresses tab make the @company.com entry the primary and delete the @<organization-name>.company.com entry.

  • Edit the @company.com entry and unmark the responsibility checkbox.

  • Again do not update all related recipient addresses.

  • Configure the Default SMTP Virtual Server as follows:

    • In the Access / Relay window select the option "Only the list below" and leave the list empty (this is the default).

    • In the Delivery / Advanced window set the smart host to the DNS name of the external gateway (if there is any) and mark the checkbox "Attempt direct delivery" (if you use MX records in your DNS).

  • Configure the Default SMTP Connector as follows:

    • On the General tab:

      • Select the option "Use DNS ..." (=default).

      • Select under "Local bridgehead" the Default SMTP Virtual Server just configured.

    • On the Address Space tab:

      • Set the address space to: SMTP;*;1 (=default).

      • Unmark the checkbox "Allow messages to be relayed to these domains" (=default).

  • Add a second SMTP connector with the name company.com:

    • On the General tab:

      • Select the option "Forward all mail through this connector to the following smart host".

      • Enter the fully qualified DNS name of the SMTP gateway of the other system as smart host.

      • Select under "Local bridgehead" the Default SMTP Virtual Server just configured.

    • On the Address Space tab:

      • Create a new entry: SMTP;company.com;1

      • Mark the checkbox "Allow messages to be relayed to these domains".

The other (Exchange 5.5) system should of course also be configured to send outgoing messages for company.com to this Exchange system. This will be covered in a separate FAQ.

What is the role of the Legacy Exchange Distinguished Name?

The Legacy Exchange Distinguished Name attribute (Ldap name: LegacyExchangeDN, abbreviation used in the article: LEDN) is used by Exchange 2000 as the primary key relating Exchange objects and Outlook profiles to objects in the Global Address List / Active Directory. Exchange does not make use of the GUID of the AD object, nor the Active Directory Distinguished Name (DN) or the Security Identifier (SID) as used by some other systems.

The LEDN is normally generated by the RUS (Recipient Update Serice) process of Exchange using the following syntax: 

    /o=<Exchange Organization>/ou=<Exchange Administrative Group>/cn=Recipients/cn=<Alias>

When the Alias (Ldap attribute name: mailnickname) is not unique a suffix is generated (be ware that in the current version of Exchange 2000 this generation of a suffix does not always function properly, especially if two entries with the same Alias are created within a short time interval of each other).

The LEDN attribute can not be seen and updated through the normal administrative user interface. The LEDN attribute can be updated through LDAP tools like LDP and ADSI Edit.

The following scenarios clarify how the LEDN is used by Exchange.

  • Replies to E-mails from another internal user

When a message is received from another user in the same Exchange Organization (Forest), the From address is identified through the LEDN of the sender. This results in the following behavior:

  • When the SMTP address of the sender changes, a reply is still delivered correctly.

  • When the sending user is removed and a new user is created with the same SMTP address a reply cannot be delivered.

  • When the sending user is removed and a new user is created with the same LEDN a reply will be sent to this new user.

  • Replies to E-mails from a Contact entry

When a message is received from a user in another Exchange Organization, but with a Contact entry in this Exchange Organization, both the LEDN of the Contact entry and the SMTP address of the sender are stored,  preferring the the LEDN over the SMTP address. This results in the following behavior:

  • When the Contact entry of the sender is removed a reply is still delivered correctly (on the basis of the SMTP address).

  • When the Contact entry is removed and two other Contact entries are created, one with the same LEDN but a different SMTP address and the other with the same SMTP address but a different LEDN, replies will be delivered through the Contact entry with the same LEDN,  so using a different SMTP address as the original sender.

  • Distribution Lists

In Distribution Lists entries that exist in the GAL/AD are stored with both their LEDN and SMTP address, preferring the LEDN over the SMTP address. This means that:

  • When a Contact is included in a Distribution List and that Contact is removed from the own GAL/AD, a message to the Distribution Lists is still delivered (on the basis of the SMTP address of the entry in the Distribution List).

  • When a User is included in a Distribution List and that User is removed from the GAL/AD and two new User entries are created, one with the same LEDN but a different SMTP address and the other with the same SMTP address but a different LEDN, a message to that Distribution List will be delivered to the User with the same LEDN,  so using a different SMTP address as the original entry.

  • Outlook Profiles

In an Outlook profile the LEDN of the User account is stored and used to link the profile with the GAL/AD entry. This means that:

  • When the LEDN of that account is changed the profile cannot be used anymore.

  • When the User account is removed and a new User account is created with the same LEDN, the profile will use that new account.

Notice that when the Userid of an account is changed an existing profile for that account can still be used. In the Logon window the new Userid has to be specified of course.

 

When is a Recipient Policy actually applied?

In this note it is assumed that the Recipient Policy generates the E-mail address from the mailnickname (= alias) attribute. If other attributes are used, the same applies to these other attributes.

·        When a new account is created the E-mail address is generated using the recipient policy, irrespective of the conditions described below.

·        When the mailnickname is changed, the recipient policy might not generate a new E-mail address as a result of this, even though the “Automatically update E-mail addresses based on recipient policy” flag has been set for that account.

·        When "Apply now" is activated on a recipient policy the recipient policy is executed for all accounts conforming to the recipient policy's filter.

·        When, after the recipient policy has been "Applied now" once, the mailnickname is changed, the E-mail address is updated automatically. So "Apply from now on" might have been a better name for this option.

·        This behavior is broken again after any update of the recipient policy (also changing the priority is seen as an update). So after updating the recipient policy without applying it again, the recipient policy is again not applied on accounts of which the mailnickname is changed.

 

This leads to the recommendation to always keep the Alias/mailnickname attribute in sync with the E-mail address. This could be achieved by using the following procedure when creating new and updating existing accounts:

When creating a new account

·        Enter in the Alias (= mailnickname) field <GivenName>.<LastName> (using the applicable Recipient Policy this will generate the correct E-mail address).

When updating the primary E-mail address of an existing account:

·        Do not update the "E-mail" field (under the "General" tab) and "E-mail addresses" (under the "E-mail Addresses" tab) directly, unless in very special situations and you understand what you are doing.

·        Instead change the "Alias" field (under the "Exchange General" tab) and have the recipient policies generate the new E-mail address (just like with new accounts). This might take some minutes.

This procedure assures that the alias/mailnickname is kept in sync with the E-mail address, preventing issues when the recipient policy is re-applied (accidentaly or not) and automatically stores the old (primary) E-mail address as secondary SMTP address.

It assumes that the recipient policies are kept "active" by applying a recipient policy after changing that recipient policy (which is not expected to happen often of course).

One might be tempted to use the givenname (firstname) and surname (lastname) attributes in the recipient policy to generate the E-mail addresses. When these attributes contain special characters (like umlaut) and when Exchange servers are used in different countries this could easily lead to issues with the same recipient policy generating different E-mail addresses in each Exchange server, leading to continuously updating each others results

How to see the contents of the system public folders?

Open the following URL in Internet Explorer: http://<Exchange server>/public/non_ipm_subtree/

How to change the definition for the Default Global Address List?

In some cases there might be a need to change the Ldap definition of the Default Global Address List, e.g. to avoid the inclusion of entries in the Offline Address Book if that is associated with the Default Global Address List.
To do so: