You need to create an additional SMTP virtual server.

Every Exchange 2000 and Exchange Server 2003 server creates a default virtual server instance that is configured to listen on all unassigned IP addresses on port 25. As you create additional virtual servers, you should assign them to specific IP addresses or alternate ports so that they do not interfere with the default virtual server instance. Assigning servers to alternate ports, however, can cause problems with messages passed between virtual server instances using SMTP, such as those between servers in an organization; they will not be able to communicate if one virtual server is on a non-standard port.

While it would be very useful in certain large deployments to be able to create new virtual servers through script, Microsoft gives no documentation or guidance to assist you in this task. This is one of the notable remaining areas in which script support could be increased. On the other hand, Microsoft does not recommend creating multiple virtual servers except under specific conditions, such as dual-homed Exchange servers.

The Introduction for a discussion of how virtual servers fit into the Exchange architecture, MS KB 266686 (How to Configure a SMTP Virtual Server Part 1), and MS KB 268163 (How to Configure a SMTP Virtual Server Part 2)

You need to choose the best type of connector to create a link to another Exchange 2000/2003 routing group, Exchange 5.5 site, or foreign mail system.

The general rule of thumb for choosing connectors is simple: use a RGC unless there is a specific reason to use another connector. Luckily, these reasons are easily listed and remembered:

The advice for creating routing groups applies to connectors as well: create the absolute minimum number that you need. Most Exchange organizations will use at least one SMTP connector for passing traffic to and from the Internet (although they are not required), RGCs for connections to other routing groups, and the occasional X.400 connector for connections with Exchange 5.5 sites. These three connector types are the core connectors in Exchange 2000/2003; they can all be used to fully connect routing groups within the organization, as they will all recognize when they are talking to another routing group within the same organization and transmit all Exchange-specific traffic. These connectors have many common controls and options shown in Table 7-1.

While both RGCs and SMTP connectors use SMTP over TCP/IP, X.400 connectors can use either TCP/IP or X.25 if you have it. No matter which underlying protocol you use for X.400 connectors, you must first install the corresponding X.400 stack on the Exchange server. Because X.400 has always been 8-bit clean, X.400 connectors have traditionally been used by Exchange administrators to route large binary messages without requiring the conversion to the 7-bit ASCII (and corresponding bandwidth increase) used by the Exchange 5.5 SMTP connectors. The X.400 connector is no longer included with Exchange Server 2003 Standard Edition; this means that if you are going to be upgrading from Exchange 5.5 and require an extended period of co-existence, you will need the Enterprise Edition.

Recipe 7.3 for creating an RGC, and Recipe Recipe 7.4 for creating an SMTP connector, MS KB 822941 (How to use SMTP connectors to connect routing groups in Exchange 2003), and MS KB 839594 (Support for the Exchange Connector for Lotus Notes in Exchange Server 2003 Service Pack 1)

You need to create a new RGC.

RGCs are essentially stripped-down SMTP connectors that have been specifically tuned and optimized for the job of passing traffic between routing groups with minimal fuss and muss. You do not have to worry about your connector scope, address spaces, recipient filtering, connection filtering, authentication options, and message queuing; Exchange takes care of all that for you.

As is the case with other connector types, RGCs are one-way. If you want bidirectional traffic flow between routing groups, you should allow Exchange to automatically create RGCs to form the corresponding reverse link.

Microsoft gives no guidance on creating RGCs programmatically. In a sense, this is understandable; script automation tends to be useful for objects that will be created, modified, and deleted on a regular basis. Most organizations will create their administrative and routing group structure, along with associated connectors, during their initial deployment and then make changes only as necessitated by upgrades, migrations, or resource changes.

Connectors are Active Directory objects and can be modified through ADSI once they have been created. They reside in the CN=Connections, CN= <Routing Group>, CN=Routing Groups, CN= <Admin Group>, CN=Administrative Groups, CN= <yourorg>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC= <Domain> container. RGCs are objects of class msExchRoutingGroupConnector, while the msExchConnector class provides the properties common between all connectors. The MSDN web site provides a reference to the specific properties of these classes.

Recipe 7.2 for choosing the correct connector, Recipe 7.4 for creating an SMTP connector, MS KB 267992 (XADM: How to Configure a Routing Group Connector), MS KB 822929 (HOW TO: Use Routing Group Connectors to Connect Routing Groups in Exchange Server 2003), MSDN: msExchConnector, and MSDN: msExchRoutingGroupConnector

You need to create a new SMTP Connector.

The Exchange 2000 SMTP implementation provided a large improvement over the Internet Mail Service SMTP implementation that was included in Exchange 5.5. It solved many interoperability problems that could affect Exchange’s ability to communicate with other SMTP implementations. It also added support for several standard extended SMTP verbs and keywords:

Exchange 2000 does not provide its own SMTP implementation; rather, it extends the SMTP service in IIS. Consequently, you need to be more aware of the tighter integration between Exchange and the underlying Windows operating system, as changes you make to the SMTP service in IIS can affect your Exchange organization. Exchange takes over the default SMTP virtual server unless you configure alternate virtual server instances for it to use; you generally should not need to.

You do not need an SMTP connector to receive and send Internet mail in an out-of-the-box Exchange 2000/2003 organization, although MS KB 294736 gives a list of reasons why you would need one. The default Exchange transport is SMTP and the default SMTP virtual server will accept incoming connections on all interfaces; as long as your DNS MX records point to an Exchange machine and your firewall and IPSec policy settings permit, you can receive SMTP connections. If you do not have an SMTP connector in your organization, or an IMS instance in a mixed-mode organization, then each Exchange server will use the settings of the underlying SMTP virtual server when it receives mail that is not destined to a recipient in your organization’s address space. By default, this means it will perform an MX lookup for the recipient domain in DNS and attempt to send the message directly. If the underlying virtual server is configured to use a smart host, the Exchange server will hand the message to the designated machine.

You change this behavior when you add an SMTP connector, with a scope of either the routing group or the entire organization. The scope allows you to fine-tune your specific routing situation and control which routing groups can use a given connector. One scenario when this capability is useful is to ensure that branch offices use their own local Internet connection for SMTP mail instead of routing through the organization’s WAN links to a central link. The connector must be bound to one or more local bridgehead servers within its routing group; each virtual server may be bound separately, permitting you to segregate traffic routing responsibilities through your virtual server definitions. Each SMTP connector must have one or more address spaces defined; the default address space “*” refers to any domains not otherwise defined by membership to the organization or by another connector. Multiple connectors can have the wildcard address space; Exchange servers will use the one that has the lowest routing cost from their location. SMTP connectors can also use DNS-based lookups to intelligently route outbound mail or forward traffic to a smart host. If the configuration of the bound virtual servers and the SMTP connector disagree, the connector wins.

There is no provision for preventing incoming mail through a specific SMTP connector in the Exchange management tools. To prevent a particular Exchange server from receiving incoming connections from the outside world, you will have to apply IPSec policy filters to one or more of the interfaces on the machine (Recipe 10.3 shows how to enable IPSec policies between back- and front-end servers, but you can adapt the same principle to create packet filters), use an external packet filtering firewall, or re-point the DNS MX records to another host record as discussed in Recipe 7.25.

Unlike the Exchange 5.5 Internet Mail Service (IMS), SMTP connectors can be used to connect routing groups without any loss of functionality. Within the same organization, SMTP connectors will pass the extended message properties (as did IMS), make use of full Active Directory-aware Kerberos authentication, and transmit organizational system messages and routing updates. Unlike RGCs, you can restrict the address space that a particular SMTP connector will service, even if it is space within your Active Directory forest. If you do this, ensure that your machines have a valid route to the affected address space or you will be troubleshooting message delivery failures.

Exchange 5.5 allowed you to authenticate SMTP connections using basic (plaintext) authentication; Exchange 2000 expanded this to permit Kerberos and NTLM as well. Although Exchange SMTP authentication follows the appropriate RFCs and interoperates with all compliant clients, it does not support some of the cryptographic authentication methods used by other mail servers, such as DIGEST-MD5 and CRAM-MD5; use of these methods requires the client’s credentials to be stored using a reversible encryption method. Active Directory does permit user accounts to use reversible encryption, but this functionality has not been extended to Exchange to permit the use of these methods. Any mail system (client or server) that wishes to protect its authentication credentials with an Exchange system must support NTLM or Kerberos; in practice, you will usually end up using NTLM authentication, as Kerberos authentication requires both systems to be in the same Kerberos realm or have a cross-realm trust in place.

When you are using SMTP connections to bridge two Exchange organizations (Active Directory forests), you may have issues getting address expansion to work properly when messages are submitted anonymously in one organization and routed into the other. The way to fix this is to create two users, one in each organization, that have Send As permissions (see Recipe 5.21 for more details). These accounts are then used in conjunction with the cross-forest SMTP connectors to authenticate the connection. MS KB 828770 (Resolve Anonymous Senders Functionality in Microsoft Exchange Server 2003) has more details.

SMTP connectors share many characteristics with RGCs (see Recipe Recipe 7.3). There is a distinct lack of guidance for creating SMTP connectors programmatically. Like RGCs, SMTP connector objects reside in the CN=Connections, CN= <Routing Group>, CN=Routing Groups, CN= <Admin Group>, CN=Administrative Groups, CN= <yourorg>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC= <Domain> container. SMTP connectors are objects of class msExchRoutingSMTPConnector. The MSDN web site provides a reference for the specific properties of these classes.

Recipe 7.1 for creating a new virtual server, Recipe 7.2 for choosing the correct connector, Recipe 7.3 for creating an RGC, MS KB 245019 (Transfer Modes and the SMTP Connector), MS KB 265293 (How to configure the SMTP connector in Exchange), MS KB 257569 (How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003), MS KB 294736 (When to create SMTP connectors in Exchange 2000 and later), MS KB 812455 (Definitions of Verbs That Are Used Between 2 Exchange Servers), MS KB 822941 (How to use SMTP connectors to connect routing groups in Exchange 2003), MS KB 828770 (Resolve Anonymous Senders Functionality in Microsoft Exchange 2003), MSDN: msExchConnector, and MSDN: msExchRoutingSMTPConnector

You need a specific connector to accept messages from a specified group of senders.

For Exchange to be able to determine whether a given user is allowed to send messages through a connector, it has to be able to validate that a given message actually comes from a user. Since message headers can be faked, Exchange needs to be able to validate that a message was submitted by a given user. To do this, you need to enable SMTP authentication, so that Exchange can track the required message properties from end-to-end throughout the organization.

Recipe 10.2 for enabling SMTP authentication on SMTP connectors

You need to ensure that large messages only go through specific connectors, usually those with sufficient bandwidth for the traffic.

In Exchange 5.5 the SMTP connector did not support the 8-bit SMTP extensions; any binary attachments that went through the IMS had to undergo a conversion to 7-bit format, causing a notable increase in reported size and bandwidth usage. It was common practice to restrict large messages from traversing the IMS, letting them route through an X.400 connector.

In Exchange 2000, this design feature was changed. SMTP connectors and RGCs can transmit binary attachments using the 8BITMIME and CHUNKING extended SMTP features. A common design feature in many deployments is to create connectors to allow direct traffic between two sites over a low-bandwidth link, restricting it to small messages. A second set of connectors is then used to pass larger messages at regular intervals, or over higher-bandwidth links that use less direct routing. This arrangement is more complicated than the Use different delivery times for oversize messages option on connectors, but can ensure that an organization with redundant routing paths reserves low-bandwidth links for smaller messages while permitting bulky attachments to travel a more roundabout path over higher bandwidth links.

Recipe 7.1 for creating SMTP virtual servers, Recipe 7.3 for RGCs, and Recipe Recipe 7.4 for SMTP connectors

You need to create a new routing group in your Exchange organization.

The division between routing groups and administrative groups is one of the most powerful differences between Exchange 5.5 and Exchange 2000/2003. Routing groups are members of an administrative group; your administrative groups can have zero, one, or more routing groups. You will have least one routing group in your organization, placed in the First Administrative Group during installation. They have absolutely no correlation with the underlying site structure of your Active Directory forest.

What is a routing group? Very simply, it is a group of Exchange servers that have sufficient local bandwidth between them to allow them to form a full mesh connection. Each member server in a routing group will send all traffic destined to other members directly; if it cannot connect, it will queue the messages for a later attempt. It will not attempt to pass them to any other server as an intermediate relay. An Exchange routing group provides similar routing functionality as an Exchange 5.5 site.

The only practical consideration when deciding how many routing groups you need is whether message flow is helped or harmed by creating them. There are a lot of guidelines and thumbnail calculations floating around, but the only real rule is to create as few routing groups as you can get away with. You may want to look at your network map and make note of busy routers and WAN links; these are the first places to look at your Exchange bandwidth and see if there are bottlenecks that routing groups will help relieve.

Properly used, routing groups give you an immense amount of flexibility in controlling message flow within your organization. You won’t see that full power until you have made the switch to native mode; mixed-mode Exchange organizations make some fundamental assumptions about the relationship between administrative and routing groups in the name of backward compatibility, leading to the following limitations:

After installation, neither administrative nor routing groups are displayed in the Exchange System Manager. You can easily toggle them as shown in the first part of the GUI solution.

By default, the first member server in a routing group is selected as the Routing Group Master (RGM). The RGM is responsible for sending and receiving routing updates to other routing groups and propagating the updated routing table to the other member servers. See Recipe 7.9 for more information on RGMs.

Routing groups can be renamed at any time. Depending on your Active Directory topology it may take some time before the updated name is replicated throughout your organization, but the servers will still know which routing group they belong to as the change propagates. Mail routing will likewise be unaffected.

Unfortunately, Microsoft did not in its wisdom create or expose any interfaces for management of routing groups for easy scripting. Routing groups are Active Directory containers, though, so you can view them using ADSIEdit or LDP by binding to the Configuration NC and maneuvering to the CN=Routing Groups, CN= <Admin Group>, CN=Administrative Groups, CN= <yourorg>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC= <Domain> container. The key attributes that control routing group membership are displayed in Table 7-2.

While scripted creation of routing groups using ADSI is undocumented, it is not difficult either. Each administrative group has a Routing Groups container that holds any routing groups belonging to that administrative group. Each routing group (msExchRoutingGroup object) not only lists any member servers using the properties show in Table 7-2, but also has an additional container object, Connections, to hold any connectors that are located in the routing group.

The VBScript solution presets DNs to the parent Routing Groups container and the new routing groups. It uses standard ADSI scripting to connect to the Routing Groups container and create a new msExchRoutingGroup object. It then creates the Connections container, a msExchConnectors object, within the new routing group and tweaks the adminDisplayName property. If you fail to create the Connections container, it will be automatically created for you if you view the contents of the routing group in ESM. When ESM auto-creates the missing container, however, it does not populate the adminDisplayName property as it does when you create a new routing group using the regular interface. Be safe and create the container in your scripts; you are assured of it being there when other tasks require it.

Be aware this method is not supported by Microsoft. Since routing group structures tend to be fairly static and changes are one-time events, you can probably get by with using ESM to create your routing groups.

Recipe 7.8 for deleting routing groups, Recipe Recipe 7.9 for designating an RGM, Recipe 7.10 for moving server between routing groups, and Chapter 5, “Configuring Your Routing Topology,” of the Exchange Server 2003 Transport and Routing Guide:

You need to remove a routing group in your Exchange organization.

Deleting a routing group is simpler than creating it, although you do need to ensure that you have moved all member servers to other routing groups. You will not be able to move a server from routing group if it hosts any connectors to or from that routing group.

Scripting this task is not documented but is a simple application of basic ADSI scripting methods. There is a caveat: because it uses the DeleteObject(0) method, which recursively deletes the object and any objects it contains, you need to first verify two items of information:

The scripted solution performs these checks for you to ensure that deleting the routing group object will not cause problems. Since this is a two-part test, we use a simple Boolean variable and set it to False if we fail a test.

Testing for member servers is relatively easy: we merely need to check for the existence of the msExchRoutingGroupMembersBL property on the routing group object. This property is a backlink to the msExchHomeRoutingGroup properties on the server objects. Active Directory maintains the backlinks automatically; when all the servers are moved out of the routing group, the backlink property is removed from the routing group object. We use the GetInfo method to pull the object’s attributes into the local cache, then iterate through them with the Item method to check the current attribute’s Name property. If we find a match, we have failed the test.

The second test is just as simple, although this time we merely need to check to see if the Connections container in the routing group object is empty or not. We do this with a simple For Each loop; if the loop runs at all, it means we have one or more objects in the container. We print out the names of the objects and set the Boolean variable to False.

Recipe 7.7 for creating routing groups, Recipe 7.9 for setting the RGM, Recipe 7.10 for moving server between routing groups, Recipe 5.5 Deleting an OU” of Active Directory Cookbook (O’Reilly), and Chapter 5, “Configuring Your Routing Topology,” of the Exchange Server 2003 Transport and Routing Guide:

You need to specify a new Routing Group Master server in the routing group.

When you install the first server in a routing group, it is automatically configured to be the RGM, which is signaled in Active Directory by populating the msExchRoutingMasterDN attribute on the server. The RGM is responsible for collecting the state of all servers and connectors within the routing group on a regular basis and sending updates to other routing groups by means of the X-LINK2STATE SMTP extension over SMTP and Routing Group Connectors, and specially crafted messages over X.400 connectors.

When it receives updates from other routing groups, it propagates them to the rest of the members using the link-state protocol over TCP port 691. Each server in the organization thus keeps its own copy of the entire link-state map for the organization; they use the Dijkstra algorithm (popularized in the Open Shortest Path First, or OSPF, TCP/IP routing protocol) to dynamically determine the best route for outgoing messages. While this can be computationally intensive in a large, dynamic organization, the link-state algorithm prevents the routing loops that could plague the Exchange 5.5 Gateway Address Routing Table (GWART). The GWART used a distance vector protocol for routing calculations; this protocol is known to have certain circumstances under which it will generate loops. Using the link-state algorithm, Exchange 2000/2003 servers will never generate loops, even if they cannot transmit mail over the most efficient route.

If the RGM cannot be reached, each server is able to continue routing messages but will not receive further updates on links external to their routing group. As the quality of their link-state map degrades, messages may take less-than-optimal routes; member servers cannot share link updates and must discover failures individually. You can check the application log for transport events 958 (RGM no longer exists) or 961 (Member server fails to authenticate with the RGM) to see if there are failures between your RGM and member servers.

Scripting this is fairly straightforward, even though it is a not a well-documented process. The msExchRoutingMasterDN attribute on the routing group object in Active Directory controls which server is the RGM; it contains the DN of server with the master role.

Recipe 7.7 for creating routing groups, Recipe 7.8 for deleting routing them, Recipe Recipe 7.10 for moving servers between routing groups, and Chapter 5, “Message Routing Architecture,” of the Exchange Server 2003 Technical Reference Guide:

You wish to move an Exchange server to a different routing group.

Remember that an Exchange 2000/2003 routing group is simply a group of Exchange servers with sufficient stable local bandwidth and low enough connection latency to permit each member server to send all traffic directly to other members. Any traffic destined outside the routing group, whether to another server in a different routing group in the same Exchange organization or to a foreign server, must be routed through the appropriate connector.

Given the typical Exchange 2000/2003 deployment, there is a good chance that most Exchange administrators will need to change their routing group configuration at some point. Three common reasons for needing to change routing group membership include but are not limited to:

Changing a server’s routing group membership using ESM is simple; it is literally a drag-and-drop operation. It is just as easy to do with a script, even though there are no ready examples of the process in the MSDN documentation. MS KB 830828 gives the necessary hint: routing group membership is controlled by the msExchHomeRoutingGroup attribute on the server object in Active Directory. If you change this attribute, Active Directory will automatically update the msExchRoutingGroupMembersBL on the source and destination routing group objects to reflect the respective deletion and addition.

Our script constructs two strings: the full DN of the server to move and the full DN of the routing group it will be joining. We then perform a standard ADSI task: bind to the desired object (the Exchange server) and update the msExchHomeRoutingGroup property with the new value. Note that you can move servers into a routing group that belongs to a different administrative group if your organization is in native mode. The server’s administrative group membership does not change when you do this.

Your production scripts should check to ensure that the target routing group has the msExchRoutingMasterDN attribute set after the server has been moved. Moving a server into an empty routing group will not set this value automatically, which would result in the server not receiving routing updates. You should also set a new RGM for the existing routing group before you move that server. Recipe 7.9 shows you how to set this value.

Recipe 7.7 for creating routing groups, Recipe 7.8 for deleting them, Recipe 7.9 for setting the RGM, and MS KB 830828 (How to Manually Re-Create a Routing Group After the Routing Group Is Accidentally Removed)

You wish to examine your Exchange organization’s routing structure: routing groups, connectors, addresses spaces, and limitations.

WinRoute is a freely downloadable Exchange tool that is designed to retrieve and display all information that pertains to message routing. This allows you to troubleshoot message routing issues more easily in organizations with complicated routing topologies. It displays the relevant information on your organization, routing groups, servers, and connectors in a tree view. The included documentation is brief, but covers what you will see in the display and how to use the minimal features of the program.

WinRoute does not have, nor does it need, a lot of functionality or automation. By its very nature, troubleshooting is not easily automated; what WinRoute does admirably is pull your organizational data and display it in a manner that allows you to see how a specific server sees the routing table. This tool will not help you learn about routing groups, connectors, and the minutia of Exchange message routing if you do not already know the basics; it will help you learn how it applies to your configuration by seeing exactly how your servers are configured and how that information is replicating throughout your organization.

The WinRoute tool download page:

You need to list the SMTP queues associated with a specific virtual server instance on your Exchange server.

To get a good understanding of traffic flow through Exchange, you need to understand queues and links. Each Exchange SMTP virtual server (or X.400 stack for the MTA transport) has its own set of queues, which are a set of folders on an NTFS partition. Each queue holds messages destined for a single DNS domain; messages addressed to recipients in the 3sharp.com and redmond.3sharp.com domains are placed in two different queues.

Links are virtual memory structures that represent the next system a message must be sent to. Each link is associated with zero or more queues. While it may sound odd that links can have no queues, not all links are transient in an Exchange organization; routing group connectors and smart hosts provide dedicated links to next-hop systems and the links to them exist even when there is no traffic to route through them. Conversely, a link can have more than one associated queue, such as when the remote server is published in DNS as the MX host for multiple domains.

Tracking links and queues through the Exchange System Manager Queue Viewer can be somewhat confusing; what ESM calls queues are actually links. It uses the Queue API to provide a unified management interface for the links and queues on the server, presenting them without distinguishing precisely what is a link and what is a queue. WMI always makes the difference explicit. There are a default set of SMTP system queues and links that are always present. They are shown in Table 7-3 along with their corresponding WMI properties and ESM queue names.

To get an accurate view of the queues and links, you need to use WMI scripting. Exchange 2000 provides two classes through the ExchangeQueueProvider provider; these classes, ExchangeLink and ExchangeQueue, provide read-only access to the status of all links and queues on the server. Exchange Server 2003 supplies additional WMI providers and classes that allow you to easily choose between SMTP and X.400 queues and links and manage them. These new classes are shown in Table 7-4.

For day-to-day management and monitoring of the SMTP queues, you will only need to deal with the Exchange_SMTPLink and Exchange_SMTPQueue classes. As demonstrated by the script above, using these classes together to obtain queue information is not difficult. A simple WMI Query Language (WQL) query, constrained by the physical server name and (if desired) virtual server instance, enumerates your existing links. You can then pull the LinkID and LinkName properties to use as a constraint against a second WQL query for the associated queues.

MSDN: Exchange_Link, MSDN: Exchange_Queue, MSDN: Exchange_SMTPLink, MSDN: Exchange_SMTPQueue, MSDN: Exchange_X400Link, MSDN: Exchange_X400Queue, Recipe 7.13 for listing messages in a queue, and Recipe 7.14 for deleting messages from a queue

You need to enumerate the contents of a queue, or examine a specific message in a queue.

Enumerating the messages in a queue using ESM Queue Viewer is difficult; the Queue Viewer, as mentioned in Recipe 7.12, uses the Queue API to provide a unified view of links and queues. Each link represents the next physical hop for a message, so if your Exchange server is performing its own SMTP deliveries to the Internet, you will have one link for each discrete MX host. Depending on your traffic patterns and who you are sending messages to, you may find that each destination has its own link, giving you the effect of having a separate queue. If your Exchange server is handing mail off to a smarthost, however, you will see a single link for that smarthost in the Queue Viewer display; that link actually contains all of the queues that may exist. You cannot find any information in the Queue Viewer to determine which actual queue a given message is in, even when using the advanced search and filter facilities.

In Exchange 2000, you do not have a scripting interface to enumerate messages in queues. Exchange Server 2003 provides several new WMI classes that give you the ability to determine the precise queue that holds a specific message, shown in Table 7-5.

The VBScript solution shows how to use these classes in combination with the classes shown in Recipe 7.12 to enumerate the contents of a script. We start by connecting to the Exchange WMI namespace and retrieving a list of the Exchange_SMTPQueue objects on the server. You need to find a way to filter this list down to the specific queue that you are interested in; in our script, we check the QueueName property against a string we know ahead of time (the destination’s domain name). Once we have the right queue, we retrieve the collection of messages in the queue using a WQL query to select against the server, virtual server instance, link, and queue. We then work through those messages using a For Each loop and examine the properties we are interested in.

When you create the WQL query string to filter your Exchange_SMTPQueue objects, you should use at a minimum all of the following properties:

Note that the script pulls all of the properties (except for ProtocolName) from the retrieved queue object for inclusion in the WQL query. You can use presupplied strings for most of these properties, but be careful when doing so with the LinkID and QueueID properties. Since queues and links are generated as needed, their IDs are dynamically generated; queue IDs are regenerated whenever Exchange attempts to retry delivery of the messages in that queue. Using static strings can easily cause you to be searching against the wrong information and turning up an empty result set.

At the time of this writing, the sample script for the Exchange_QueuedMessage class on the MSDN Exchange WMI reference demonstrates the use of the Count property with a collection of Exchange_QueuedMessage objects. This is an error; this class does not have the Count property available for collections.

Recipe 7.0, Recipe 7.12 for enumerating queues, and Recipe Recipe 7.14 for deleting messages from queues, MS KB 823489 (How to Use Queue Viewer to Troubleshoot Mail Flow Issues), MSDN: Exchange_QueuedMessage, MSDN: Exchange_QueuedSMTPMessage, and MSDN: Exchange_QueuedX400Message

You need to delete messages from a queue on your Exchange virtual server.

This recipe is an extension of Recipe 7.13. When you use ESM to delete messages, you go into the Queue Viewer, select your queue, search for your messages, select one or more of them, and select one of the two deletion options from the right-click context menu: Delete (with NDR) and Delete (no NDR). As their names imply, one will generate an NDR, the other won’t.

This same simplicity exists in the Exchange Server 2003 WMI classes. While the Exchange_QueuedMessage class provides all of the properties needed for both SMTP and X.400 messages, the Exchange_QueuedSMTPMessage and Exchange_QueuedX400Message classes extend those properties with four methods, shown in Table 7-6.

The script uses essentially the same code and methodology as Recipe Recipe 7.13. The only difference is that we add the specific MessageID property to the WQL query so that it returns only the specific message we wish to delete. We then use the DeleteNoNDR method to remove the message from the queue.

Both etiquette and codified RFC best practices (particularly section 6.1 of RFC 2821) say you should always generate an NDR when deleting a message, especially when it originates outside of your organization. This common wisdom is not always correct; the DeleteNoNDR method is useful more and more in these days of NDR spam attacks. If you are accepting mail for nonexistent recipients and generating NDRs, instead of refusing to accept them to begin with, then your SMTP queues are likely filling up with NDRs to forged senders, making your server contribute to the spam problem. If you are cleaning out stale messages of this sort in your queues, use the DeleteNoNDR method.

Recipe 7.12 for enumerating the queues, and Recipe 7.13 for listing the messages in a queue, MSDN: Exchange_QueuedMessage, MSDN: Exchange_QueuedSMTPMessage, and MSDN: Exchange_QueuedX400Message

You want to move the SMTP queues for a specified virtual server from their default location to a new disk or partition.

Exchange keeps a separate set of queue directories for each SMTP virtual server, so this is an operation you must perform for each virtual server whose queue files you wish to relocate. Moving them, especially the default virtual server, can cause a big performance increase, especially if you move them onto a dedicated drive and off the system volume. This is especially important for bridgeheads, systems acting as edge routers, or other high-traffic machines. You also do not want to locate the queue folders on the same drive as any of your storage group log files.

See Recipe 7.12 for a discussion of the various queues.

Recipe 7.0 for general background on the SMTP services, MS KB 318230 (How to change the Exchange 2000 SMTP Mailroot directory location), MS KB 822933 (How to change the Exchange 2003 SMTP Mailroot folder location), and the Optimizing Storage for Exchange Server 2003 guide (http://www.microsoft.com/downloads/details.aspx?FamilyID=C6084D20-9730-4FFC-805D-B957327604C6&displaylang=en)

You need to delete messages from the badmail folder of your Exchange virtual server.

When Exchange encounters a fatal error during a delivery attempt, it generates an NDR for the original sender and attempts to deliver it. NDRs are messages like any other and work through the same link and queue system. In time, NDRs themselves may prove to be undeliverable. When that happens, Exchange moves the original message to the badmail folder, which is, by default, located underneath the root mail queue folder for the virtual server instance (see Recipe 7.15 for more information on queue folders).

Over time, the badmail directory can fill up and eventually cause space issues. You should check this directory on a regular basis and move or delete messages from it. Microsoft provides the BadmailAdminTool for download from their Exchange Tools download web site. It works with both Exchange 2000 and Exchange Server 2003. You can get it at http://www.microsoft.com/downloads/details.aspx?familyid=782aaf0f-6239-40ad-adda-97863d852ff7&displaylang=en.

The BadmailAdminTool provides the parameters shown in Table 7-7.

There are other methods of dealing with the badmail folder: The “Dealing with Badmail” entry (http://hellomate.typepad.com/exchange/2003/07/dealing_with_ba.html) on the MS Exchange Blog gives a short description of the badmail folder and provides an alternate script, the Badmail Report Tool. The Badmail Report Tool provides a weekly report of the contents of the badmail folder via email. You can download it from http://hellomate.typepad.com/exchange/badmailreport.zip.

As of Exchange Server 2003 SP1, the badmail folder is disabled out of the box, but you can re-enable it with selected registry tweaks per MS KB 884068.

Recipe 7.15 for more information on queue folders, and MS KB 884068 (The Badmail folder is disabled in Exchange Server 2003 SP1)

You have another mail system within your organization that must share the same SMTP domain namespace with Exchange and you need them to coexist.

Conceptually, sharing a domain between Exchange and another mail system is easy:

The devil is in the details, as always. MS KB 315591 provides two methods for configuring Exchange as the nonauthoritative system; we have summarized the first method, which provides domain-by-domain control, in our recipe. The second method shares all domains for which the Exchange server is configured to handle mail and is not covered in this recipe.

There is a per-domain setting for each domain specified in a recipient policy that determines whether Exchange is authoritative for the domain. By default, this setting is enabled. The first hurdle to jump is that Exchange must be authoritative for the primary address in the default recipient policy.

Steps 2-8 of the recipe create a new primary address (@local) on the default recipient policy, for which Exchange is authoritative.

Steps 9-11 configure Exchange as nonauthoritative on the shared domain.

Steps 12-14 are optional and permit your users to retain their primary email addresses in the shared domain.

Steps 15-17 permit Exchange to relay unresolved messages to the authoritative mail system.

“Supporting Two SMTP Mail Domains and Sharing an SMTP Mail Domain with Another System” in Chapter 6, “Deployment Scenarios for Internet Connectivity,” of the Exchange Server 2003 Transport and Routing Guide on the TechNet web site, MS KB 315591 (XCON: Authoritative and non-authoritative domains in Exchange 2000), MS KB 319759 (XADM: How to configure Exchange 2000 Server to forward messages to a foreign messaging system that shares the same SMTP domain name space), and MS KB 321721 (XCON: Sharing SMTP Address Spaces in Exchange 2000 Server and Exchange Server 2003)

You want the recipients in your Exchange organization to be able to accept mail for an additional domain without having to configure separate secondary addresses for each recipient.

This is a straightforward task. By default, your Exchange recipients have a single SMTP domain associated with them (their Active Directory domain). By modifying the default recipient policy or creating a new recipient policy, you can add additional SMTP domains to all recipients, allowing your users to share a common domain namespace. This is commonly used to set an organization’s recipients to use the parent domain when Active Directory has been configured in a subdomain. However, it will trigger a rebuild of your offline address lists, which may, in turn, cause a spike in synchronization traffic to your clients.

Although you can easily find the recipient policy information in Active Directory by looking in the CN= <Policy Name> ,CN=Recipient Policies,CN= <organization> , CN=Microsoft Exchange,CN=Services DN of your domain’s Configuration naming context, you should only make changes to it via ESM. The Recipient Update Service will do the work of applying the change policies to your existing recipients.

MS KB 268838 (Configuring Exchange to Receive Mail from Multiple Domains)

You need to configure which systems are allowed to relay mail through your Exchange server.

One of the big improvements in Exchange 2000 and Exchange Server 2003 is that it no longer is an open relay out of the box. Controlling relaying is an important feature because there are times when you need to allow a subset of accounts or users to relay messages through the server. You can control relaying at the level of both the SMTP virtual server and the SMTP connector.

Controlling relaying at the SMTP connector allows you to specify rules for an entire group of bridgehead servers at once. The relay permissions on an SMTP connector apply to all address spaces handled by the connector, so if you have multiple address spaces listed and need to permit relaying for only one of them, you will need to move that address space to a new SMTP connector (see Recipe 7.4 for details). The connector relay settings override the relay settings for any associated SMTP virtual servers.

Setting the relay options on the virtual server allows you to enable or disable authenticated relay. Any authenticated user account will be able to relay through the virtual server; because this setting is enabled by default, spammers have taken to locating Exchange servers and running password attacks on known and likely accounts using SMTP authentication. See Recipe 11.2 for more details on this attack, how to detect it, and how to prevent it. Unless you absolutely need to allow authenticated user relay, disable this setting on every Internet-facing virtual server.

Recipe 7.1 for creating new SMTP virtual servers, Recipe 7.4 for creating new SMTP connectors, and Recipe 10.2 for SMTP authentication

You need to filter incoming messages based on the recipient.

There are two main uses for recipient filtering: preventing external senders from sending mail to particular mail-enabled recipients and preventing mail for nonexistent recipients from ever entering your Exchange organization. Recipient filtering is an organization-wide setting; any restrictions you create will be propagated to all servers and apply for every anonymously submitted inbound message submission to the organization. Exchange returns the “550 5.7.1 Requested action not taken; mailbox not available” error when a message is submitted to a filtered recipient.

MS KB 823866 (How to configure connection filtering to use Realtime Block Lists (RBLs) and how to configure recipient filtering in Exchange 2003)

You need to maintain the connection restriction, relay restriction, and global accept/deny lists on your Exchange servers.

The ExIPSecurity tool is a freely available Visual Basic script and COM object that gives you programmatic access to the connection, relay, and global accept/deny restriction lists. The connection and relay restriction functions work on both Exchange 2000 and Exchange 20003; the global accept and deny lists are specific to Exchange Server 2003. Since the command-line tool is actually VBscript, this recipe does not include an example of directly invoking the COM object; you can look directly at the tool and included documentation to see working examples of how to use this COM object in your own scripts.

Using this tool, you can iterate through lists of servers provided by other recipes in the book (such as the VBScript Active Directory query in Recipe 2.14) and maintain consistent settings for your per-virtual server connection restriction lists and relay restrictions. This tool provides quite a few options but the included documentation includes many examples to help you figure out how to put it to use in your organization.

Download the SMTP Internet Protocol Restriction and Accept/Deny List Configuration Tool with documentation from the Microsoft Download Center:

and MS KB 810913 (XGEN: Programmatic Modification of SMTP Virtual Server Access and Relay Control)

You wish to use a DNS-based block list (DNSBL) to help filter and reject incoming spam.

DNSBL support is a new feature in Exchange Server 2003 that can have tremendous impact on reducing the amount of spam that enters your organization. There are literally hundreds of blocklists being run around the world; before using any of them, do some research to find out their purpose, listing criteria, delisting criteria, and maintenance policies. Some return multiple result codes to allow you to combine queries for multiple lists into one aggregated zone and still know which source list caused the hit. As an example, on such a list a return value of 127.0.0.1 might signify that the host was added to the list by one source, while 127.0.0.2 was from a second source.

DNSBLs can produce a performance hit on busy systems; they are making one DNS query for every configured DNSBL for every incoming SMTP connection, subject to normal DNS caching. If these queries are to servers outside of your network and over your WAN, the delay could add up (as could the bandwidth). It is generally best to use as few DNSBLs as possible.

You should always program an exception for RFC-required role accounts such as postmaster@domain and abuse@domain (see Recipe 7.24 for details) so that external senders who are trying to send mail through to your users can contact you. You might also consider putting up a web site that explains which block lists you use and ways to request whitelisting and referring to that page’s URL in a custom error message.

Depending on the number of block lists you query and your traffic volume, you may want to look into the possibility of creating your own DNSBL and feeding by concatenating the data from several block lists together. Doing so has many benefits:

Recipe 10.7 has more details on creating a custom DNSBL.

Recipe 10.7 for creating a custom DNSBL, Chapter 10 of the Exchange Server 2003 Transport and Routing Guide, Chapter 8 of Secure Messaging with Microsoft Exchange Server 2003 (Microsoft Press), and MS KB 823866 (How to configure connection filtering to use Realtime Block Lists and how to configure recipient filtering in Exchange 2003)

You need to associate MIME types with specific extensions, define default message format settings, or adjust them on a per-domain basis, throughout your Exchange organization.

Global format options are shared throughout the Exchange organization, meaning that you can easily change them as needed in the GUI and not need to worry about propagating them to all of your servers using scripts.

The first process in this recipe shows how straightforward it is to add a new MIME type/file extension association. Editing and removing them are just as simple.

Controlling message formatting settings on a domain-by-domain basis is a bit more interesting. You can control whether to use MIME or UUEncode (MIME is the default and should be unless you have a specific reason to change it), whether the MIME message body will be text or HTML (or both), and which character sets to use for MIME and non-MIME messages.

The advanced properties give you control over whether to use Exchange rich text and word wrapping. They also control a multitude of autoresponse behaviors, shown in Table 7-8.

MS KB 821750 (How to configure Internet email message formats at the user and the domain levels in Exchange Server 2003)

You have a role account such as “postmaster” for which you need to accept messages.

This problem is actually pretty simple to solve; in fact, it is so simple to solve that there are at least four different ways to solve it:

There is at least one role account every email installation must have to be RFC-compliant, as well as one more that is strongly recommended if you intend to be a good network neighbor in dealing with any email abuse issues that may originate from your organization:

In addition, there are many others you probably should make sure are valid, such as the responsible email address listed in your external DNS zone file (commonly hostmaster), webmaster for issues regarding your web site, info for business queries, and more. RFC 2142, “Mailbox Names for Common Services, Roles, and Functions” provides a proposed standard for these role addresses and when they should be deployed; you can view the RFC at http://www.rfc-editor.org/rfc/rfc2142.txt.

Recipe 5.1 for creating mailbox-enabled users, Recipe 5.4 for creating mail-enabled groups, Recipes Recipe 5.14 and Recipe 5.23 for mailbox delegations, Recipe 5.28 for changing attributes on user objects, and Recipe 9.8 for mail-enabled public folders

You need to ensure that you have your external DNS properly configured to allow inbound SMTP traffic to your Exchange organization. In addition, you would like to avoid the kind of configuration errors that might cause your outgoing SMTP traffic to be rejected by other hosts.

Run the following commands from the command line for each server or cluster you intend to receive or send mail outside of your firewall. For outbound hosts, make sure to use the actual external IP address that will be used by your firewall, NAT device, or other SMTP proxy:

               > nslookup 
               <server FQDN> <DNS server hostname or IP address>

> nslookup red-exch01.redmond.3sharp.com ns1.msp.eschelon.com
  Server:  ns1.msp.eschelon.com
  Address:  209.150.200.10

  Name:    red-exch01.redmond.3sharp.com
  Address:  64.65.179.146

> nslookup 
               <server IP address> <DNS server hostname or IP address>

> nslookup 64.65.179.146 ns1.msp.eschelon.com
  Server:  ns1.msp.eschelon.com
  Address:  209.150.200.10

  Name:    red-exch01.redmond.3sharp.com
  Address:  64.65.179.146

> nslookup -q=MX 
               <domain> <DNS server hostname or IP address>

> nslookup -q=MX 3sharp.com ns1.msp.eschelon.com
  Server:  ns1.msp.eschelon.com
  Address:  209.150.200.10

  3sharp.com      MX preference = 10, mail exchanger = exchange.robichaux.net
  3sharp.com      MX preference = 20, mail exchanger = relay.salmark.net
  3sharp.com      MX preference = 30, mail exchanger = relay.thorcom.net
  3sharp.com      nameserver = ns1.msp.eschelon.com
  3sharp.com      nameserver = ns.mazin.net
  ns1.msp.eschelon.com    internet address = 209.150.200.10

Ensure that the reported FQDN and IP address for the server match. You must use the FQDN to avoid a NetBIOS lookup and you must supply a DNS server that has the same view of the DNS domain as the rest of the Internet.

Even though Exchange 2000 and Exchange Server 2003 are thoroughly based around SMTP, Active Directory, and DNS, you do not have to worry about the same DNS configuration issues inside your organization as administrators of other native SMTP mail transports do. Active Directory (and therefore Exchange) is certainly critically reliant on a stable and well-configured DNS deployment, but almost all of the routing information Exchange needs comes from Active Directory, not DNS. It only uses DNS to locate domain controllers and global catalog servers via SRV records; it does not use MX records inside the organization.

;  Database file fqdn.tld.dns for fqdn.tld zone.
;
@                       IN  SOA ns.fqdn.tld. hostmaster.fqdn.tld. (
                         32           ; serial number
                         900          ; refresh
                         600          ; retry
                         86400        ; expire
                         3600       ) ; default TTL
;
; Zone NS records
;
@                       NS     ns.fqdn.tld.
;
;  Zone records
;
@                       MX     10 bridge01.fqdn.tld.
@                       MX     20 bridge02.fqdn.tld.
;
bridge01                A      192.168.0.20
bridge01                MX     10 bridge01.fqdn.tld.
bridge01                MX     20 bridge02.fqdn.tld.
;
bridge02                A      192.168.0.30
bridge02                MX     10 bridge01.fqdn.tld.
bridge02                MX     20 bridge02.fqdn.tld.
;
exchfe01                A      192.168.0.40
exchfe01                MX     10 bridge01.fqdn.tld.
exchfe01                MX     20 bridge02.fqdn.tld.
;
exchfe02                A      192.168.0.50
exchfe02                MX     10 bridge01.fqdn.tld.
exchfe02                MX     20 bridge02.fqdn.tld.
;
mail                    CNAME  exchfe01.fqdn.tld.
mail                    CNAME  exchfe02.fqdn.tld.

$ORIGIN 0.168.192.in-addr.arpa.
20                      PTR    bridge01.fqdn.tld.

DNS on Windows Server 2003 (O’Reilly), Chapter 4, “Configuring DNS,” of the Exchange Server 2003 Deployment Guide on the Microsoft TechNet web site, and MS KB 153001 (XFOR: DNS MX Records and CNAMEs)

You need to manually test your Exchange server’s SMTP functionality by injecting a test message.

Using the Windows telnet client:

Knowing how to manually inject SMTP test messages is a valuable troubleshooting skill that can save you a lot of time and energy. Often, you need to send a quick message through a particular server or to test a specific mailbox. It is easy to script the creation of messages using CDO (although CDO is outside the scope of this book), but you may not always have your script with you.

The SMTP conversation recorded in this recipe is the simplest one that involves actual transmission of a message, yet it allows you to validate the following information:

If you have the ability to test from a special IP address you set aside, you can even test the connection filtering if you need to. If your client IP address is in the filter, you should be denied connection.

If you make a typo during an SMTP command or email address and correct it using the backspace key, you will probably need to re-enter the command. When entering email addresses manually, be sure always to wrap them in angle brackets:

The brackets tell the SMTP address parser code that it is dealing with a raw address, which is a type of quoting specified in the RFCs. It tells the parser that this is to be treated just as an email address and reduces the likelihood of parsing errors. Raw addresses will also transit from SMTP to X.400 without translation or expansion if they are routed through your system.

When entering the message body, you should use at least the following headers, although they are not required:

Exchange will automatically create other appropriate headers.

RFC 2821 (Simple Mail Transfer Protocol) for a description of SMTP and RFC 2822 (Internet Message Format) for a description of the Internet message format