Recipe7.7.Creating a Routing Group

Recipe 7.7. Creating a Routing Group

Problem

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

Solution

Using a graphical user interface

Open the Exchange System Manager (Exchange System Manager.msc).
Ensure that you have enabled viewing of administrative and routing groups (see Recipe 7.3).
Expand the organization Administrative Groups target administrative group.
If the Routing Groups container does not exist, right-click on the administrative group container and select New Routing Groups Container.
Right-click the Routing Groups container and select New Routing Group.

<ExchangeServerName>" ' e.g., red-exch02 ' Name of the administrative group the routing group will be in strAdminGroup = "<SourceAG>" ' e.g., SeattleAG ' Name of the new routing group to create strRoutingGroup = "<TargetRG>" ' e.g., RedmondRG ' Name of the Exchange organization strExchangeOrg = "<ExchangeOrg>" ' e.g., ExampleOrg ' ------ END CONFIGURATION --------- strConfigDN = GetObject("LDAP://RootDSE").Get("configurationNamingContext") ' The path of the routing group container strRGContainerDN = "LDAP://CN=Routing Groups,CN=" & strAdminGroup &_ ",CN=Administrative Groups,CN=" & strExchangeOrg &_ ",CN=Microsoft Exchange,CN=Services," & strConfigDN ' The path of the new routing group strRoutingGroupDN = "LDAP://CN=" & strRoutingGroup &_ ",CN=Routing Groups,CN=" & strAdminGroup &_ ",CN=Administrative Groups,CN=" & strExchangeOrg &_ ",CN=Microsoft Exchange,CN=Services," & strConfigDN ' Create the routing group Set objRGContainer = GetObject(strRGContainerDN) Set objRoutingGroup = objRGContainer.Create("msExchRoutingGroup", "CN=" &_ strRoutingGroup) ' Create the Connectors container in the new routing group Set objConnectionsContainer = objRoutingGroup.Create("msExchConnectors", _ "CN=Connections") objConnectionsContainer.Put "adminDisplayName", "Connections" objConnectionsContainer.SetInfo Wscript.Echo "Created routing group: " & strRoutingGroup & VbCrLF

Discussion

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:

Each Exchange 5.5 site will be represented within the Exchange 2000/2003 organization by a paired administrative group and routing group. Even if you add new administrative groups that only contain Exchange 2000/2003 servers, they will be created as 1:1 pairings so they can be properly represented to the Exchange 5.5 servers.
Exchange will ignore multiple routing groups within an administrative group; it will only use the first one.
Servers can only be members of the routing group within their administrative group. In native mode, routing group memberships can cross administrative group boundaries, allowing you to easily separate routing administration from recipient and mailbox administration.

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.

Table 7-2. Active Directory attributes that control RG membership
Object	Attribute	Purpose
`msExchRoutingGroup (CN=<Routing Group>,CN=Routing Groups, CN=<Admin Group>, CN=Administrative Groups, CN=<yourorg>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<Domain> )`	`msExchRoutingGroupMembersBL`	Backlink to DNs of servers whose SMTP transport instances are member of this RG. You should not need to edit this property directly.
`msExchRoutingGroupMembersDN`	List of DNs of servers whose MTA (X.400) instances are members of this RG.
`msExchRoutingMasterDN`	DN of the member server that holds the RGM role.
`msExchExchangeServer (CN=<server>, CN=Servers, CN=<Admin Group>, CN=Administrative Groups, CN=<yourorg>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<Domain> )`	`msExchHomeRoutingGroup`	DN of the RG this server's SMTP transport instances belong to.
`msExchHomeRoutingGroupDNBL`	Backlink to the DN of the RG this server's MTA (X.400) instance belongs to. Only populated if the server has an X.400 connector. You should not need to edit this property directly.

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.