Exchange Server 2003 Troubleshooting: Transport

Microsoft Confidential


Overview.......................................................................................................3
New Features .............................................................................................4
Routing Link State Algorithm...............................................................................4

ArchiveSink Enhancements..................................................................................5

Lab 1: ArchiveSink ................................................................................................9

Public Folder Affinity...........................................................................................10

DNS Resolver Enhancement .............................................................................. 12

Lab 2: DNS Resolver...........................................................................................17

Domain Address Rewrite....................................................................................18

Lab 3: Domain Address Rewrite........................................................................23

Query Based Distribution Group ....................................................................... 24

Lab 4: Query Based Distribution Groups .........................................................31

Recipient Filtering................................................................................................32

Lab 5: Recipient Filtering ...................................................................................37

Distribution Group Restrictions ......................................................................... 38

Lab 6: Restricted Distribution Groups .............................................................. 41

Security Principle Based Submit and Relay ..................................................... 42

Lab 7: Security Principle Based Submit and Relay......................................... 46

Connection Filtering and RealTime Block List (RBL)......................................49

Lab 8: Connection Filtering and RBL................................................................64

Fault Analysis ...........................................................................................68
Appendix A - Scripts .............................................................................79
Appendix B – Cube Notes ..................................................................81

Exchange Server 2003
Troubleshooting: Transport
Microsoft Confidential
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property.

 2003 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Active Directory, Exchange 2000 Server,
Exchange Server 2003, Outlook, Outlook Express, Outlook Web Access, Windows 2000, and
Windows Server 2003 are either registered trademarks or trademarks of Microsoft Corporation in
the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Microsoft Confidential

Overview

This document is intended to provide Microsoft Exchange administrators with
the information necessary to successfully configure, deploy and troubleshoot
the new features of Microsoft® Exchange Server 2003 SMTP transport. The
module assumes a good knowledge of Exchange 2000 Server SMTP transport.
Microsoft Confidential

New Features



Routing Link State Algorithm
The link state algorithm in Exchange 2003 has been changed to address
conflicting link states that result when network or other transient hardware
problems cause conflicting link state information. This change was
implemented in two parts:


First, the default link state update interval was lengthened to ten minutes
versus the five minute interval of Exchange 2000.

Secondly, each server compares the last link state it received for a given
route to the link state that is to be sent to the Routing Group Master.
• If the last link state update received does not match the link state the
server is prepared to send, the server appends a new update that matches
the last one received and does not change the link state message.
• If the next update interval expires, a link state update is not received; the
server sends a link down status update to the Routing Group Master.

Microsoft Confidential

ArchiveSink Enhancements

ArchiveSink is a diagnostic tool that enables message archiving. The tool has
been enhanced to log all message and recipient details of an e-mail message,
include bcc: recipients, and provide logging.
When ArchiveSink is enabled, the default behavior is to archive all messages
and their recipients, with the exception of bcc: recipients. Each message is
archived to an .eml file that includes message ID, subject, and all recipients on
the “To” and “cc:” lines. When you enable bcc: archiving, an additional .xml
file for each message is generated. The XML file for bcc: contains the same
information produced for other message recipients and includes bcc: recipients.
All messages are in one of two directories in the archive location the
administrator specifies:
•
MAPI Gateway Messages -
This directory holds all messages

submitted by MAPI clients, such as Outlook, and messages submitted
through foreign gateway servers.
•
SMTP Messages
- This directory contains all messages submitted
through the SMTP service.

ArchiveSink uses two transport events, OnMessageSubmission, and
OnPostCategorize.
OnMessageSubmission event
All messages submitted through the Information Store and the SMTP transport
triggers the OnMessageSubmission event. This event is triggered before any
routing or categorizer events. This event is triggered only once per message.
Messages archived for this event contain the prefix filename: ARCH_<random
number>.eml
Microsoft Confidential
When the ArchiveSink is installed, messages are archived for this event by
default. Messages archived for this event contain the prefix filename: ARCH.
So an archived message appears as ARCH_<random number>.eml.
OnPostCategorize event
The OnPostCategorize event captures a message after it is categorized, that is
after the sender and recipients have been located in the directory and any
distribution lists have been expanded. Message archival is not the default
behavior of the OnPostCategorize event; archival is enabled via the registry.
Messages can trigger this event multiple times. Messages archived for this
event contain the prefix filename: ARCH_<random number>_POSTCAT.xml.
The original message is parsed by the categorizer, which generates a new
message for each recipient of the original message. Hence, each message is a
new message destined for a specific domain or server and will trigger the
OnPostCategorize event.

Internet Message Format
Messages are parsed or turned into a unique message for each recipient for
many reasons; for example, recipients are located in another messaging system
or the recipient is a distribution list. The Internet Message Format options
available on Exchange Server 2003 require special content handling for
recipients in foreign domains or smart hosts. Consider the case when all mail
sent to one domain is sent as plain text and to another as MIME. These new
messages also trigger the OnPostCategorize event.
Setup
ArchiveSink is installed via script and configured via script and the registry.
The sink is installed on a per virtual server basis. The sink must be uninstalled
using the same script; ArchiveSink_Setup.vbs.
• ArchiveSink requires restart of IISAdmin service after installation.
• Registry changes require restart of SMTP service.
Copy archivesink_setup.vbs and archivesink.dll files from the location where
you expanded the Web Release of Exchange Server 2003 tools into the
\exchsrvr\bin directory.
The text below demonstrates the command line and usage of the setup script.
Cscript archivesink_setup.vbs [install|uninstall|display]
[Virtual server ID] [archive location]

Run archivesink_setup.vbs with the appropriate switches for the given SMTP
virtual server.
When installation is successful, the script automatically creates registry key
parameters for advanced archiving controls.
Microsoft Confidential

HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\<virtualServer#>\

"Archive System Messages"

"Dump P1"
"Enable MAPI Gateway Messages"
"Enable Message Logging"
"Enable PostCat"
"Enable Precat"
"Enable SMTP Messages"
"MAPI Gateway Messages"
"SMTP Messages"

The sink archives only OnMessageSubmission messages by default. In
addition, system messages are not archived (public folder messages, replication
messages, and so on).
ArchiveSink archives all messages to the path specified in the registry. If this
key is absent, it defaults to the system temp folder. For most computers running
Microsoft® Windows Server™ 2003 computers, the default location is
%windir%\temp.

Universal Naming Convention (UNC) paths are not supported for
the archival location; Distributed file system (DFS) should work.


Optional Settings:

Message Logging = 1: ARCH_RandomNumber.xml file is generated for
each archived message. The XML file includes internet message ID, subject
and all envelope recipients of the message. This is the feature that archives
BCC recipients.

Dump P1 = 1: ARCH_RandomNumber.P1 binary file is generated for each
archived message. This binary file contains the property stream of the e-

mail message and is helpful only for Exchange debugging purposes.
Install the sink on SMTP virtual server 1 and make logs in c:\archivesink
directory:
Cscript archivesink_setup.vbs install 1 c:\archivesink


BCC recipients = All messages that pass through SMTP virtual server 1 will
be archived. However, the BCC recipients will not be logged until the value
of the Enable Message Logging key is changed to 1 in the registry:
a. Click Start, click Run and type RegEdit.
b. Browse to
HKEY__LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Archi
veSink\1 (where 1 represents SMTP virtual server 1).
c. Right-click on the Enable Message Logging key. Then click Modify.
d. Change the value data to 1. Then click OK.
e. Restart the default SMTP virtual server.
f. Display the bindings on SMTP virtual server 1:
Important
Microsoft Confidential
Cscript archivesink_setup.vbs display 1

g. Remove the sink from SMTP virtual server 1:
Cscript archivesink_setup.vbs uninstall 1

Microsoft Confidential

Lab 1: ArchiveSink

Objective:


At the end of this lab students will be able to set up ArchiveSink to archive
all messages and their recipients.

Instructor Notes:
Run the archivesink_setup.vbs script.
Enable the Message Logging registry key that ArchiveSink creates, to turn
on message logging by importing .reg file or manual adding key to registry.
Send messages with Outlook 2003 and Outlook Express to verify that
MAPI, BCC and standard messages are archived.

Exercise 1:
1. Enable archiving for all message types.
2. Send messages with MAPI and SMTP client.
3. Verify that P1, bcc: and standard message types are archived.
4. Have instructor verify your results.




Microsoft Confidential
Public Folder Affinity




The default Public Folder (PF) referral is calculated based on the routing cost.
Exchange Server 2003 introduces the concept of PF Affinity. This new feature
allows the administrator to define which servers will receive client request for
PF content.
The new feature is configured on the Public Folder Referrals tab of the “server”

properties in ESM. The list has two choices; Use Routing Groups or Use
Custom List. When Use Custom List is selected, the administrator may enter
or browse for the servers in the organization and add their cost (preference).
Lower cost represents a greater preference. This gives the administrator the
ability to use costs to prioritize servers in the referral list.
Exchange Server 2003 implements this new feature with two new attributes,
msExchFolderAffinityCustom, msExchFolderAffinityList, and supporting
code. The value of msExchFolderAffinityCustom determines if PF affinity
will be used for PF referrals.

If the msExchFolderAffinityCustom attribute is not set or has a value of 0,
PF referral behaves the same as Exchange 2000.

If the attribute is present and contains a value of 1, the new server attribute
msExchFolderAffinityList list is parsed for the cost of each of the selected
servers; the list is the server GUID. Then servers not listed as preferred
servers are assigned an infinite cost. This ensures that servers in the list with
lesser cost will be the target of the referral.

If the selected server is unavailable, the referral will be passed to the next
server in the list until the list is exhausted. At this time, the referral will fail
and the client will receive an error.

Microsoft Confidential

When a message destined to a PF is generated, the first Exchange server
processing the message will determine the PF server to which the message will
be delivered. This target PF server has to have the PF hierarchy in place but not
necessarily a replica of the PF. This determination is performed once by the
originating Exchange server, and then the message will be routed just like a

normal mail message with the target server address as the recipient address.
This is crucial as there will be no reroute due to the recipient address equaling
the PF server; and therefore the destination cannot be changed.
Exchange Transport has no knowledge of which servers have a complete PF
hierarchy. Transport has been engineered to make a calculated assessment of
when the PF hierarchy will be present. Exchange Server 2003 and Exchange
2000 SP4 transport first selects servers from TLH list, PF servers list, whose
history is more than two days. Next, server selection proceeds based on
topology; local server, then servers in same routing group, then servers in same
Adminstrative Groups (AG) and then servers in other administrative groups.
The rationale is that a server older than two days will most likely have the PF
hierarchy in place. So if you install a new PF server, it is highly unlikely PF
messages will flow to that server until two days have passed. If a message
reaches a server with the hierarchy in place, and there is no replica of the folder,
the store will attempt referral based on routing or affinity in Exchange Server
2003. If there is no hierarchy, the messages will remain in local retry on the
server with the incomplete PF hierarchy and the store will not attempt reroute
after the PF hierarchy is complete.
Replication of PF hierarchy is via normal e-mail messages. If transport
between PF servers is disrupted for more than two days, PF messages may
become stuck in the local retry queue on the new PF server. Another possible
reason is that the hierarchy is simply too big and two days are not enough.
Organizations with a large PF hierarchy can mitigate the possibility of the latter
by changing the value of the following registry parameter to increase the time
delay before the server is considered as having public folders.
"HKLM\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters
\IgnorePFTimeLimit"
dWORD: days to exclude new servers from receipt of PF messages

The IIS Admin service will need to be restarted for this registry
change to take place; reference knowledge base 328870


Note
Microsoft Confidential
DNS Resolver Enhancement




Exchange 2000 SMTP Domain Name Server (DNS) resolver allows for
specifying DNS servers that are different from those that are being used by the
operating system. This functionality allows the operating system to maintain
connectivity with the internal DNS infrastructure, while the SMTP DNS
resolver can connect to external DNS servers for resource records required for
locating hosts outside the internal network. While this capability is ideal for
configuring Exchange 2000 based Internet mail delivery, using this
functionality has some shortcomings.
Issue
To resolve domains on the Internet, the Windows 2000 SMTP server called
code in the DNS resolver event. The Windows 2000 DNS resolver sink
resolved the hosts using the alternate DNS servers, and returned the list of IP
addresses for mail exchangers resource records) to the SMTP virtual server.
The shortcomings were a result of the existing design of the Windows 2000
DNS resolver.

It was slow because the Windows 2000 DNS resolver event is synchronous.
This can manifest as outbound mail queue backlog on heavy volume
servers.


The Exchange 2000 DNS resolver sink does not track the DNS server state;
an unresponsive DNS server will cause a delay each time it is queried,
unlike Windows Server 2003 SMTP which has code to track which servers
are unresponsive.

The Exchange 2000 DNS resolver sink does not load balance equal priority
mail exchanger records.
Microsoft Confidential

The sink did not maintain the state of external DNS servers. If several external
DNS servers are used by Exchange 2000 DNS sink and some of these DNS
servers are not responsive, they are not removed from the consideration for
subsequent queries and the priority/sequence of DNS server selection does not
change. This causes unnecessary lookup delays and excessive network traffic.
When multiple mail exchanger records with the same cost are
available for a particular domain, an Exchange 2000 SMTP virtual
server configured to use the DNS sink tries them in the same order
each time the connection is established. The order matches the order of
the hosts as returned by the response to the DNS query. As a result,
only the host referenced by the first mail exchanger record is tried, and
100% of mail goes through it. Hosts referenced by other mail
exchanger records are used only in the event the first host becomes
unresponsive.
If several hosts referenced by the first mail exchanger records are not available
there is approximately a 23 second time penalty/per host for Transmission
Control Protocol (TCP) connection timeout. Coupled with the fact that mail
exchanger records are tried in the same sequential order for each connection
within the SMTP queue, an unnecessary delay occurs when unavailable mail
exchangers are tried.

There are no performance counters for Exchange DNS resolver sink, and the
Exchange DNS resolver sink does not update the DNS query/sec on the SMTP
virtual server object in performance monitor.
Solution
Exchange Server 2003 running on a computer with Windows Server 2003 will
enhance DNS based Internet mail delivery to achieve load balancing, better
performance characteristics and better tolerance to network unavailability and
external DNS server responsiveness. This behavioral change will address the
issues described above.
Development achieved this goal by unifying the code paths and expanding the
Windows Server 2003 DNS event to return the DNS server list from the
Exchange Server 2003 DNS resolver sink in lieu of the default global DNS
server list if the SMTP virtual server is configured to use external DNS servers
for mail delivery.
The new DNS resolver sink in Exchange Server 2003 exposes both the old and
the new interface. The new interface only checks to see if the domain to be
resolved is an external domain, and if so, returns a DNS server list to the
Windows Server 2003 DNS event. However, it is important to remember that
the behavior for Exchange Server 2003 installed on computer running Windows
2000 Server is the same as that of Exchange 2000 installed on a computer
running Windows 2000 Server.
Microsoft Confidential
DNSDiag – a new diagnostic tool
Summary:
This tool is used to troubleshoot problems with DNS resolution for SMTP. It
simulates SMTPSVC’s internal code path and prints diagnostic messages that
indicate how the resolution is proceeding. The tool must be run on the machine
where the DNS problems are occurring.
Program return codes:
These are set as the ERRORLEVEL for usage in batch files:


0 - The name was resolved successfully to one or more IP addresses.

1 - The name could not be resolved due to an unspecified error.

2 - The name does not exist. The error was returned by an authoritative DNS
server for the domain.

3 - The name could not be located in DNS. This is not an error from the
authoritative DNS server.

4 - A loopback was detected.
Usage Notes:
DNSDiag <hostname> [d] [options]
<hostname> - Hostname to query for.

This may not be the same as the display name of the queue (in ESM,
if Exchange is installed). It should be the fully qualified domain name of the
target for the queue seeing the DNS errors.

d - This is a special option to run in debug/verbose mode. There is a lot
of output, and the most important messages (the ones that normally
appear when this mode is not turned on) are highlighted in a different
color.
Options are:

v <VSID> - If running on a computer with an Exchange DMZ, you can
specify the VSI# of the VSI to simulate DNS for that SMTP VS. Then this
tool will read the external DNS server list for that VSI and query that server
list for <hostname> when <hostname> is an "external" host. If <hostname>

is the name of an Exchange computer, the query is generated against the
default DNS servers for the local computer.

s <server list> - DNS servers to use, if you want to specify a specific set of
servers. If this option is not specified, the default DNS servers on the local
computer are used as specified by v. This option is incompatible with v.

p <protocol> - Transmission Control Protocol (TCP) or User Datagram
Protocol (UDP). TCP generates a TCP only query. UDP generates a UDP
only query. DEF generates a default query that will initially query a server
with UDP, and then if that query results in a truncated reply, it will be
retried with TCP. If this option is not specified, the protocol configured in
the metabase for \smtpsvc\UseTcpDns is used. This option is incompatible
with the v option.

a All the DNS servers obtained (either through the registry, active directory,
or s option) are tried in sequence and the results of querying each are
displayed.
Note
Microsoft Confidential

EEEEE
C:\> DNSDiag fe.concsi.lab –d –a –v 1

Running in debug/verbose mode.
The DNS flags are not explicitly set in the metabase, assuming
default flags 0x00000000
These are the local IP addresses (server bindings)
192.168.1.10
Microsoft Exchange is installed on this machine.

Querying domain controller for configuration.
The domain controller server which will be used for reading
configuration data is DC.concsi.lab
Connecting to DC.concsi.lab over port 389
configurationNamingContext is "CN=Configuration,DC=re,DC=pro"
This will be used as the Base DN for all directory searches.
Checking if the target server fe.concsi.lab is an Exchange
server
Searching for an Exchange Server object for fe.concsi.lab on
the domain controller
LDAP search returned some results, examining them.
Examining next object for attributes we are interested in.
Successfully read the distinguishedName attribute on the
Exchange Server object. The value of the attribute is
CN=FE,CN=Servers,CN=First Administrative
Group,CN=Administrative Groups,CN=GLS,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=re,DC=pro
The search returned the following 6 values for the
networkName attribute for the Exchange Server object for
fe.concsi.lab
Attempting to match the TCP/IP networkName of the Exchange
Server object returned from the domain controller against the
FQDN we are searching for
0> networkName: ncacn_vns_spp:FE...match failed
1> networkName: netbios:FE...match failed
2> networkName: ncacn_np:FE...match failed
3> networkName: ncacn_spx:FE...match failed
4> networkName: ncacn_ip_tcp:FE.concsi.lab...match succeeded
fe.concsi.lab is an Exchange Server in the Org.
fe.concsi.lab is in the Exchange Org. Global DNS servers will

be used.
Using the default DNS servers configured for this computer.
192.168.1.2

Querying DNS server: 192.168.1.2
Created Async Query:

QNAME = fe.concsi.lab
Type = MX (0xf)
Flags = UDP default, TCP on truncation (0x0)
Protocol = UDP
DNS Servers: (DNS cache will not be used)192.168.1.2

Connecting to DNS server 192.168.1.2 over UDP/IP.
Connected to DNS 192.168.1.2 over UDP/IP.
Response received from DNS server.
Received DNS Response:
Microsoft Confidential

Error: 9501
Description: No records could be located for this name
These records were received:
concsi.lab SOA (SOA records are not used by us)

Querying via DNSAPI:

QNAME = fe.concsi.lab
Type = A (0x1)
Flags = DNS_QUERY_TREAT_AS_FQDN, (0x1000)
Protocol = Default UDP, TCP on truncation

Servers: (DNS cache will be used)
Default DNS servers on box.
Received DNS Response:

Error: 0
Description: Success
These records were received:
FE.concsi.lab A 192.168.1.11
FE.concsi.lab A 192.168.1.10

No CNAME records in reply.
Checking reply for A record for fe.concsi.lab
2 A record(s) found for fe.concsi.lab
Local host's IP is one of the target IPs.
Discarding all equally or less preferred IP addresses.
DNS configuration error (loopback), messages will be NDRed.
Local host's IP address is the most preferred mail exchanger
record.
Shutting down ATQ
Shutting down IISRTL
Exit code: 4

Example: fe.concsi.lab is the SMTP server

DSN logging
Delivery Status Notification (DSN) is the SMTP nomenclature for system
transport notifications. NDR, or non-deliverable, has become synonymous with
DSN in the Exchange world. DSN error codes were cryptic in Exchange 2000.
Exchange Server 2003 addresses this by adding a new category, "NDR", to the
transport diagnostic logging.

All NDR related events, their causes and proposed resolutions may be found at
This new
logging category, combined with the enhanced transport logging new to
Exchange Server 2003, provides message status from start to finish.

Note
Microsoft Confidential

Lab 2: DNS Resolver
Objective:

At the end of this lab students will be able to run the DNSDIAG.EXE tool.

Instructor Notes/Answer :
Students will examine output of dnsdiag for the concsi.lab domain.
Students will find the utility fails until they either add
%windir%\system32\inetsrv to the path or copy isatq.dll to the directory
with dnsdiag.exe.

Exercise 1:
Determine and correct the problem with the execution of dnsdiag.exe by
examining the output of dnsdiag.exe for the concsi.lab domain.


Microsoft Confidential
Domain Address Rewrite


When companies merge, Exchange is often integrated into a heterogeneous
messaging environment. Often there is a requirement that all mail destined to

external domains reflect the same source domain.
Exchange Server 2003 introduces this functionality by rewriting the domain
address in both P1 and P2 message envelopes. This functionality has existed in
sendmail for some years and may have blocked Exchange penetration of this
market to some degree.
Explanation of Concept
CompanyA merges with CompanyB. The decision is made to have all
outbound mail reflect the domain of CompanyA.
A contact for each user in CompanyB is added to the directory with a Primary
SMTP address that corresponds to the domain of CompanyA. The target
address domain will correspond to the domain of CompanyB.
Servers in CompanyB are configured to forward all outbound mail to one of the
SMTP bridgehead servers in CompanyA that has been configured for domain
address rewrite.
MX B.com <-smtp-> domain rewrite enabled MX
MX A.com <-smtp-> INTERNET

UserB has address:


UserB is a contact in OrgA called UserB.
UserB has target address

, the primary ‘SMTP’ proxy address
is

.
UserB in OrgB sends mail to and a friend on the Internet.
Introduction
Microsoft Confidential

The From has


The mail is forwarded to a domain address rewrite enabled bridgehead in
A.com.
The bridgehead looks up the recipients in the From:, To: and CC: of the
message.
If the recipients are in the bridgehead’s directory, the addresses are rewritten to
match their primary SMTP address;

is changed to

The SMTP bridgehead for A.com sends the mail to the recipient domain on the
Internet.
The friend on the Internet gets the e-mail. The From: field will show

; the domain has been rewritten.
When the friend at C.com replies, the mail will be directed to one of the mail
exchangers for A.com.
The mail exchanger for A.com will route the message for

to a
mail exchanger for B.com because the target address of the contact for

is

.

will receive the message.

Conditions for Address Rewrite
Domain address rewrite requires the following conditions to succeed.

The SMTP virtual server heuristic value must have been incremented by 1
by using either exarcfg.exe or a manual edit.

The message must be submitted via a SMTP virtual server meaning another
mailer or mail client with the SMTP send function, such as Outlook
Express.

There must be a contact with a target address matching the sender’s From:,
address of the message and a primary SMTP address matching the domain
of the SMTP bridgehead enabled for domain rewrite.

The message must be destined for a domain external to the directory of the
address rewrite enabled SMTP bridgehead. There can be no contact in the
directory with a primary SMTP address reflecting the domain of the rewrite
enabled SMTP bridgehead and a target address of the actual sending
domain.
Mail originating within the Exchange organization that has enabled domain
rewrite does not need to be modified for delivery to the intranet or Internet.

The exception is mail submitted via Outlook Express or any other SMTP
client. Netscape®, will undergo address rewrite on that bridgehead
server.

Internal process
Address Rewrite happens only for external SMTP mail going out to the
Internet, with the exception of mail submitted via a POP client as noted above.
Address rewrite operations entail:

Note
Microsoft Confidential

pushing the message to store.

invalidating the existing MIME and forcing MIME to MAPI conversion to
occur, which then causes the address rewrite.
• As a consequence, the message is converted to MAPI and the content
format must be rendered to MIME before being sent to the Internet.
• Transport does the rendering for the message based on the matching
Internet Message Format (IMF) of the receiving domain. If the recipient
is a contact and the contact has its own personal content settings, they
will be used (personal content settings override IMF settings).
• Transport is not RFC 822 content aware. If there is no address rewrite
required, the above operations occur. So, if there are From: and To:
addresses that do not need to be rewritten, the message is still converted
even though:
• they do not have equivalent contacts OR mailboxes for them in the
rewrite domain.
• their addresses already match their PRIMARY SMTP proxies in the
rewrite domain.
In short, all externally submitted SMTP mail will go through this address
rewrite conversion process.
Address rewrite happens only once for optimization purposes. If the mail passes
through other bridgehead servers with address rewrite feature enabled, the
process or domain rewrite does not occur.
Example:
ServerA in domain mycompany.com is relaying mail for
systemX.com.
System X:

FROM:
TO:
CC:

UserX and UserY are contacts in the directory of ServerA. ServerA has
address rewrite enabled. The P1 and P2 envelope of mail destined for the
Internet is rewritten to match the Primary SMTP Address of the contacts
representing userX and userY; and

.
When this feature is enabled, mail destined outside the organization will be
pushed into the store. The addresses in the Sender, From, ReplyTo,
ReturnReceiptTo, DispositionNotificationTo, To, and Cc headers are resolved
to the directory.
Transport then uses IMAIL to again render the message content, headers and
primary addresses associated with the resolved objects from the various headers
to build the outbound Internet content.
Since the entire body has been rendered again, standard content conversion
rules are applied: contact settings, XEXCH50 settings, and domain IMF
settings. The resolve P2 setting is set to always resolve the sender's address to
the directory for outbound mail that will be rendered again due to address
rewrite. This guarantees the sender's address is rewritten and does not depend
on the resolve anonymous email setting on the first SMTP VSI to receive the
Microsoft Confidential

mail. This applies only to mail leaving the organization, not mail destined for
internal delivery.
Other Factors
Address rewriting is not applied to mail sent by MAPI or DAV clients within
the same organization where the SMTP virtual server performing rewrite exists.

Neither is address rewrite applied to mail that is destined to a recipient within
the same messaging organization as the address rewriting SMTP VSI; the case
where mail is sent from

to
Primary addresses used for rewrites are based on existing directory objects in
the forest of the VSI doing the rewrite. This feature is controlled by
PR_INTERNET_ADDRESSING_OPTIONS in the inbound property row.
PR_INTERNET_ADDRESSING_OPTIONS was not previously used as an
inbound conversion parameter.
This option forces the store to resolve addresses in all address headers that
IMAIL parses and set MAPI counterparts in store. Thus, Internet content
rendered from the constructed MAPI message will contain the associated
primary addresses.
SMTP mail relayed to recipients in remote domains when Address Rewrite is
enabled should receive the correct content type on SMTP submissions with P2
address headers rewritten to contain primary addresses. Addresses that are not
in the directory should remain unchanged.
OMA push messages that are submitted via a SMTP virtual server with this
feature enabled should receive the message without character set corruption or
loss of the plain text body part.
S/MIME messages should arrive with message body intact and no duplicate
headers, but the P2 address headers will be rewritten. Some clients may warn
that the address on the message does not match the address in the certificate
used to sign the message. This is expected and will be documented as a known
issue.
In cases where different Exchange organizations are merged, it is a simple issue
to change the primary SMTP proxy address and retain the old SMTP proxy as a
secondary. The same holds true for some other mail systems; Lotus® Notes™,
for example.

Contacts are often used to represent the other organization’s personnel. This
simplifies routing between the different Exchange organizations and enables
Outlook and Outlook Web Access to automatically resolve the recipients in the
To, and cc to the corresponding user in either organization. The net result is the
alias will be resolved to the correct Display Name in the mail message.
Clients like Outlook Express can readily change their “reply to” address. There
is no need to do this for internal mail, because mailers can be configured to
send mail for specific namespace to the proper internal host.
Configuring Domain Address Rewrite
Address Rewrite is disabled by default and currently there is no UI in ESM.
EXARCF.exe is the command line tool that enables, disables or displays the
status of the domain address rewrite feature for a SMTP virtual server. This
tool will be part of the Exchange Server 2003 Support Tools Web Release.
EXARCFG can be run from any domain computer which can access the
directory.
Microsoft Confidential
The following command line enables address rewrite on the first SMTP virtual
server on FQDNrewriteServer:
exafcfg s:FQDNRewriteServer v:1

Help is displayed by typing EXARCFG with no arguments.

exarcfg [l] [e] [d] [s:] [v:] [/?]

[l] - lists the current settings per server/VSI. Lists the settings for all the
servers in the domain unless a specific server is specified with the s: option.

[e] - enables address rewrite. Default, no options specified, it enables the
feature for the default VS (#1).


[s] - specifies which server in the organization has been selected to enable
address rewrite. The server name must be specified as a FQDN. This is a
required option when using options [e] and [d].

[v] - allows specifying which VS needs to be enabled for address rewrite.
By default the value is 1 (the default virtual server).

[d] - disables address rewrite. The option [s] is required, since a server has
to be specified. If there is no [v], the tool will disable the address rewrite
from all the VSI on the specified server. If a VSI number is specified [v],
then the feature will only be disabled on the specified VSI number.

[/?] - Provides the list of options and a short help (prints this message). The
command with no options will default to this option.

Manual configuration of domain address rewrite is provided to clarify exactly
what is changed and where in the SMTP virtual server object in the directory.
1. Using the directory tool of your choice, connect to the Configuration
context in the directory.
2. Browse to the Exchange server that will be the domain rewrite bridgehead.
DC=com,DC=domain,CN=Configuration,CN=Services,CN=Microsoft
Exchange, CN=netbios_doman,CN=Administrative Groups,CN=First
Administrative Group,CN=Servers,CN=FE,CN=Protocols,CN=SMTP,
CN=n; where “n” is the virtual server that will configured to rewrite
domain.
3. Increase the value of the "heuristics" attribute of the SMTP virtual server by
1 (one). Note: The default SMTP VSI will have a value of 131072; increase
to 131073. Additional SMTP virtual servers will have a heuristics value of
0 (zero); change to 1 (one).

Microsoft Confidential

Lab 3: Domain Address Rewrite
Objective:

At the end of this lab students will be able to set up domain address rewrite.

Instructor Notes/ Answer:
Add internal.lab as alias for Student workstation; student-n … Add a
record to DNS server or configure SMTP connector to forward to IP
address of host machine.
Add a SMTP connector for internal.lab to the FE server; mbx-fe.
Add a SMTP connector for Microsoft.com to the FE server; mbx-fe.
Configure the FE server for open relay; clear the box for allow only hosts
and clients that successfully authenticate and change the relay restrictions
on IIS to all except the list below.
Add a contact to the directory with primary SMTP address of

and target address of
Use Outlook Express to send via mbx-mbx-fe.concsi.lab with reply address
of

, email address of
Send a message to your

.
Use queue viewer in ESM to inspect the message in the microsoft queue
and verify that the from address is

Exercise 1:
1. Add the internal.lab domain as an alias to the SMTP domain for the SMTP
service running on your host.
2. Configure SMTP connector to route mail to your host machine for the
internal.lab domain.
3. Configure a SMTP connector to route mail to Microsoft com (we do not
expect mail to be delivered, but rather queue for delivery).
4. Configure the FE server for open relay.
5. Configure a contact that will provide address rewrite for


to

.
6. Use Outlook Express to send a message from

to

(this message will queue on the SMTP connector
and you may use queue viewer to inspect for address rewrite).
7. Verify address rewrite.


Microsoft Confidential
Query Based Distribution Group


A Query Based Distribution Group (QDG) is a new type of distribution group
introduced in Exchange Server 2003.
Query Based Distribution Groups:


CAN have restrictions; you may restrict who can send to the QDG.

CAN expand on a dedicated server (if desired).

CAN be used for Exchange 200n users and contact based recipients.

CAN be used for Universal Distribution Group Message Restrictions.

CAN be nested – Universal Distribution Group is recommended.


CANNOT be security principals.

CANNOT be used in an Exchange mixed mode environment; no 4.0/5.x
servers.

CANNOT use an external directory service for LDAP query; replicate the
external objects to AD.
A Query Based Distribution Group provides the same functionality as a
standard distribution group, but uses an LDAP query, based on RFC2254
LDAP filter rules to dynamically build membership in the distribution group in
lieu of specifying static user membership.
A mailing list for all users with mailboxes on a particular server or particular
storage group or database is readily constructed using a QDG. Imagine the time
savings of this method versus manually adding the users to a standard
distribution group using ESM or even programmatically. If the user account
resides on the server, they will receive the mail.
Microsoft Confidential

QDG allows for a much lower administrative cost given the dynamic nature of
the distribution group. However, a QDG carries a higher performance cost for
queries whose outcome produces a large number of results. This cost is in terms
of server resources such as high CPU and increased working set, because each
message to the QDG has a corresponding LDAP query executed against Active
Directory to determine its membership. Naturally you cannot view the
membership of a Query Based Distribution Group in the global address list,
because it is dynamically generated each time mail is sent. However, you can
preview the result of the query in Active Directory Users and
Computers(ADUC)
When a message is submitted to a Query Based Distribution Group, Exchange
treats the message slightly differently than messages destined for other
recipients.
1. E-mail is submitted through the Exchange store driver or SMTP to the
submission queue.
2. The categorizer, a transport component responsible for address resolution,
determines that the recipient is a Query Based Distribution Group.
3. The categorizer sends the LDAP query request to the global catalog server.
4. The global catalog server executes the query and returns the set of addresses
that match the query.
5. After receiving the complete set of addresses matching the query, the
categorizer generates a recipient list containing all the users. Note that the
categorizer must have the complete set of recipients before it can submit the
e-mail to routing; if an error occurs during the expansion of the Query
Based Distribution Group to its individual recipients, the categorizer must
start the process over.
6. After the categorizer sends the complete, expanded list of recipients to
routing, the standard message delivery process continues and e-mail is
delivered to the users’ mailboxes.

The process is slightly different if a dedicated expansion server, a single server
responsible only for expanding distribution groups, is used for Query Based
Distribution Groups. In this case, rather than sending a query to the global
catalog server for expansion in Step 4, the e-mail is first routed to the dedicated
expansion server. After the message arrives at the expansion server, the
expansion takes place and the delivery follows the same process described
above.
You must use an Exchange Server 2003 version of Exchange System Manager
and Active Directory® Users and Computers to create a Query Based
Distribution Group. You cannot create Query Based Distribution Group without
upgrading your administration console.
ESM simplifies the task of making a Query Based Distribution Group. We
recommend all administrative consoles be upgraded to Exchange Server 2003
ESM before deploying Query Based Distribution Groups.

1. Click Start, point to All Programs, point to Microsoft Exchange, and then
click Active Directory Users and Computers.