Mastering Microsoft Exchange Server 2007 SP1

We'll start with a bit of review about how Exchange 2007 delivers messages within a single organization. We covered this in Chapter 2, "Exchange Server 2007 Architecture," but we want to ensure that you properly understand it. The message routing architecture is significantly different enough from earlier versions of Exchange 2000/2003 that it deserves additional mention.

There are a couple of important points that you should understand about the basics of Exchange 2007 message routing:

• All messages must go through the Hub Transport server role.

• The Active Directory site architecture is used as a boundary for message routing.

• All Active Directory sites that contain a Mailbox server must also have a Hub Transport server as well as a Client Access server.

One of the nice features of Exchange Serve 2007 is that as long as your Active Directory site architecture has been properly configured, you will not need to worry about message routing architecture design.

Basics of Exchange Message Routing

In previous versions of Exchange, the message routing architecture was based on a structure that was defined by the administrator. For example, in Exchange 2000/2003, the message routing architecture was defined by a collection of servers separated by full-time and reasonably good available bandwidth. This collection of servers is called a routing group. Prior to Exchange 2000, all servers were grouped together in to a single collection of servers called a site.

In Exchange 2000/2003, the administrator could define the routing groups and move servers between routing groups based on their message routing requirements. Messages were then delivered between routing groups using some type of connector. The most common connector for routing groups is a connector called the routing group connector (RGC), which uses SMTP to deliver messages.

Exchange 2007 changes this by relying on the Active Directory site architecture rather than requiring the administrator to create a separate routing infrastructure for their organization. Figure 18.1 shows a simple Active Directory site topology that consists of three Active Directory sites.

Figure 18.1: Sample Active Directory site infrastructure

In Figure 18.1, each Active Directory site has a Mailbox server and a Hub Transport server. The Hub Transport server will always attempt a direct delivery of a message to a Hub Transport server in a remote Active Directory site even if that remote Active Directory site does not have an Active Directory site link directly to it. If you are still running any Exchange 2000/2003 servers, though, they retain their routing group architecture and have routing group connectors to the Exchange 2007 Hub Transport servers.

The Hub Transport server role is at the center of the message routing architecture for messages being delivered internally as well as messages leaving the organization. All messages are processed by the Hub Transport server role regardless of whether they are being delivered locally or remotely. Figure 18.2 shows an example of the Hub Transport setting at the center of the message delivery universe.

Figure 18.2: The Hub Transport is at the center of all message delivery.

The Hub Transport server role handles categorization and delivery for mail that is intended for locally delivery and Mailbox servers in the same Active Directory site. The Hub Transport server uses the messaging API (MAPI) and RPCs to commute with the Mailbox server role. If a message is to be delivered to a Mailbox server in a remote Active Directory site, then the Hub Transport server delivers the message via SMTP; the remote Hub Transport server then delivers the message to the local Mailbox server via RPC.

The Exchange Server 2007 Hub Transport server handles the message categorization. Essentially, the Categorizer is the component that figures out where the message is going next. Messages arrive in the submission queue, and the Categorizer picks up the message and processes it. The following are some of the steps involved in message categorization:

• Expand any distribution lists, if applicable, by querying the global catalog.

• Resolve recipient addresses to determine which recipients are local, remote, or outside of the organization.

• Apply message transport rules to the message.

• Split the message into multiple parts if the message is going to local and has remote recipients; this process is called bifurcation.

• Examine the message sender, recipients, message header, body, and attachments and apply message transport rules that apply to that message.

• Convert the message the appropriate message format (Summary-TNEF, MIME, or UUENCODE) depending on the destination of the message.

• Determine the next "hop" for the message.

• Place the message in to appropriate local or remote delivery queue.

As messages are moved within your organization's infrastructure, they are protected with different types of encryption. The encryption used is either RPC encryption or Transport Layer Security (TLS) encryption. Figure 18.3 shows different paths the message may take and how it is encrypted. We showed this in Chapter 2, but we wanted to review these here.

Figure 18.3: Messages are encrypted during transit.

As messages are transmitted via MAPI over RPC between Mailbox servers and Hub Transport servers, RPC encryption is automatically used. When a message is transmitted from one Hub Transport server to another, the Hub Transport servers transport the message using SMTP, they authenticate using Kerberos, and the data stream is encrypted using TLS. When messages are transmitted from a Hub Transport server to an Edge Transport server, SMTP is used for message transfer, mutual authentication using certificates is used for authentication, and messages can be encrypted using TLS. Optionally, an organization that is sending messages to another organization also using Edge Transport services can configure authenticated connections and TLS encryption to these remote organizations.

Send and Receive Connectors

In Exchange 2000/2003, each Exchange server had one or more SMTP virtual servers. These SMTP virtual servers received inbound mail from other servers, from outside of the organization, or from POP3/IMAP4 clients. The SMTP virtual server could be configured to host an SMTP connector for delivering messages to external SMTP hosts or it could host a routing group connector (RGC) for delivering messages to remote Exchange 2000/2003 routing groups.

Exchange Server 2007 has replaced the SMTP virtual servers and SMTP connectors with Send connectors and Receive connectors.

Receive Connectors

The Receive connector is the point where inbound SMTP mail is received on the Hub Transport server. Receive connectors do not deliver outbound mail (unlike the Exchange 2000/2003 SMTP virtual server). Each Hub Transport server automatically has two Receive connectors. These are the Default connector and the Client connector. Figure 18.4 shows the Exchange Management Console and the Server Configuration work center. In the Hub Transport subcontainer, you can see each server that hosts the Hub Transport role. The Receive connectors for server HNLEX03 are shown.

Figure 18.4: Receive connectors for an Exchange 2007 server

The properties of the Client HNLEX03 Receive connector are shown in Figure 18.4, specifically the Network property page of the Receive connector is shown. Notice that the Client Receive connector listens on port number 587, not port 25. The Client Receive connector is intended for receiving mail from non-MAPI client such as POP3 and IMAP4 clients. You would, of course, have to change the non-MAPI client's outbound SMTP port in order to use this connector.

The Default Receive connector is used to receive inbound SMTP mail from other Exchange 2007 Hub Transport servers in the organization. In Figure 18.5, the Permissions Groups properties of the Default HNLEX03 Receive connector are shown. These are the default permissions for the Default Receive connector.

Figure 18.5: Default Receive connector permissions

The point we are making is that the Default Receive connector does not accept connections from anonymous users. This means that you cannot use it to receive e-mail from the Internet even though the Receive connector is listening on port 25. We will come back to this later when we cover receiving e-mail from the outside.

You can also view the properties of a Receive connector using the Get-ReceiveConnector cmdlet. Here is an example that receives all the properties of the Default HNLEX03 Receive connector:

C:\>Get-ReceiveConnector "Default HNLEX03" | FL AuthMechanism : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer Banner : BinaryMimeEnabled : True Bindings : {0.0.0.0:25} ChunkingEnabled : True DefaultDomain : DeliveryStatusNotificationEnabled : True EightBitMimeEnabled : True DomainSecureEnabled : False EnhancedStatusCodesEnabled : True Fqdn : HNLEX03.volcanosurfboards.com Comment : Enabled : True ConnectionTimeout : 00:10:00 ConnectionInactivityTimeout : 00:05:00 MessageRateLimit : unlimited MaxInboundConnection : 5000 MaxInboundConnectionPerSource : unlimited MaxInboundConnectionPercentagePerSource : 100 MaxHeaderSize : 64KB MaxHopCount : 30 MaxLocalHopCount : 3 MaxLogonFailures : 3 MaxMessageSize : 10MB MaxProtocolErrors : 5 MaxRecipientsPerMessage : 5000 PermissionGroups : ExchangeUsers, ExchangeServers, ExchangeLegacyServers PipeliningEnabled : True ProtocolLoggingLevel : Verbose RemoteIPRanges : {0.0.0.0-255.255.255.255} RequireEHLODomain : False RequireTLS : False Server : HNLEX03 SizeEnabled : EnabledWithoutValue TarpitInterval : 00:00:05 AdminDisplayName : ExchangeVersion : 0.1 (8.0.535.0) Name : Default HNLEX03 DistinguishedName : CN=Default HNLEX03,CN=SMTP Receive Connectors,CN=Protocols,CN=HNLEX03,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Volcano Surfboards,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=volcanosurfboards,DC=com Identity : HNLEX03\Default HNLEX03 Guid : ObjectCategory : volcanosurfboards.com/Configuration/ Schema/ms-Exch-Smtp-Receive-Connector ObjectClass : {top, msExchSmtpReceiveConnector} WhenChanged : 12/27/2006 9:13:54 AM WhenCreated : 11/18/2006 10:36:04 AM OriginatingServer : HNLDC01.volcanosurfboards.com IsValid : True

With few exceptions, you will usually not need to create additional Receive connectors, nor will you need to make many changes to the existing Receive connectors that are used internally.

Send Connectors

Although Receive connectors are configured for each server, Send connectors are organizational connectors that you can assign to a number of different Hub Transport servers. Each server also has an implicit Send connector, but that connector is used only for transferring mail to other Hub Transport servers. The implicit Send connector does not show up either in the Exchange Management Console (EMC) or when you use the Exchange Management Shell (EMS), and there are not properties that can be set for the implicit Send connector. Send connectors are managed in the EMC under the Hub Transport subcontainer of the Organization Configuration work center. Figure 18.6 shows the Send Connectors tab in the results pane.

Figure 18.6: Managing Send connectors

Figure 18.6 also shows the Source Server properties of a Send connector. The Source Server property page is where you designate which Hub Transport servers will deliver messages for this particular Send connector. When you assign more than one Hub Transport server as a source server, the outbound messaging load will be load-balanced between the source servers. You can view the properties of this Send connector also using the EMS cmdlet Get-SendConnector; here is an example:

Get-SendConnector "E2K7 Send Connector to Internet" | FL AddressSpaces : {smtp:*;1} AuthenticationCredential : Comment : ConnectedDomains : {} ConnectionInactivityTimeOut : 00:10:00 DNSRoutingEnabled : False DomainSecureEnabled : False Enabled : True ForceHELO : False Fqdn : mail.somorita.com HomeMTA : Microsoft MTA HomeMtaServerId : HNLEX03 Identity : E2K7 Send Connector to Internet IgnoreSTARTTLS : False IsScopedConnector : False IsSmtpConnector : True LinkedReceiveConnector : MaxMessageSize : 10MB Name : E2K7 Send Connector to Internet Port : 25 ProtocolLoggingLevel : None RequireTLS : False SmartHostAuthMechanism : None SmartHosts : {smtp-server.hawaii.rr.com} SmartHostsString : smtp-server.hawaii.rr.com SourceIPAddress : 0.0.0.0 SourceRoutingGroup : Exchange Routing Group (DWBGZMFD01QNBJR) SourceTransportServers : {HNLEX04, HNLEX03} UseExternalDNSServersEnabled : False

Since Exchange Server 2007 does not have a default SMTP connector for outbound mail, you will need to create at least one Send connector. Most organizations will need to create only a single Send connector; this connector will be used to send mail to the Internet, to an Edge Transport server, or to an SMTP smarthost system that will deliver mail to the Internet on behalf of the Exchange server.

Now we'll go through an example of creating a Send connector that will be responsible for sending mail to the Internet. In the Hub Transport subcontainer of the Organization Configuration work center, make sure the Send Connectors tab is highlighted, and then click the New Send Connector task on the Actions pane. This launches the New SMTP Send Connector Wizard shown in Figure 18.7. On the Introduction page, you must provide the name of the connector and specify the intended use of the connector.

Figure 18.7: Introduction page of the New SMTP Send Connector Wizard

The wizard will allow you to create four types (intended use options) of Send connectors, but these are just predefined configurations and you can always change the properties of the connector you create later. The four types of Send connectors you can create are as follows:

• The Custom Send connector type allows you to manually configure all of the configuration settings at some point after the connector is created.

• The Internal Send connector type allows you to configure a connector that connects to other Hub Transport servers in your organization. Since all internal mail routing is automatic, you will usually not need to create an internal send connector.

• The Internet Send connector type is used to send mail to the Internet using DNS MX records.

• The Partner Send connector type creates a connector that will be used to send mail to specific Internet domains and will use certificate authentication and TLS encryption.

On the Address Space page of the wizard, you can specify the SMTP domains to which this Send connector will deliver e-mail. Since this connector is going to send mail to the Internet, we will use an address space of * in this example.

On the Network Settings property page, you can configure smarthost if you want mail to be delivered to another SMTP host for external delivery, such as with an Edge Transport server, or you can specify Use Domain Name System (DNS) "MX" Records to Route Mail Automatically. If you use DNS for mail delivery, then this Send connector will be responsible for all outbound mail delivery.

The Source Server page allows you to specify the Hub Transport servers that will deliver mail for this Send connector. If you have more than one Hub Transport server, we recommend you use additional Hub Transport servers for redundancy.

Once you click the New button on the New Connector page, the EMC will execute the command necessary to create the new Send connector. The following is the EMS command that was executed:

New-SendConnector -Name 'Internet Connector' -Usage 'Internet' -AddressSpaces 'smtp:*;1' -DNSRoutingEnabled $true -UseExternalDNSServersEnabled $false -SourceTransportServers 'HNLEX03','HNLEX04'

Once you have created the connector, you should make one additional configuration option. On the General property page (shown in Figure 18.8) of the Send connector, enter the public name of the FQDN for this server, such as mail.somorita.com.

Figure 18.8: General properties of a Send connector

This name is the name that the Send connector uses in the EHLO or HELO command when it connects to a remote SMTP system. If you don't specify an FQDN for the connector to use, the connector will use the default FQDN for the server. Often this is an internal name that is not recognized on the Internet. Some Internet hosts will reject a connection if the name cannot be resolved.

Connectivity to Exchange 2000/2003

When you install Exchange 2007 in an existing Exchange 2003 organization, to allow coexistence and facilitate routing, Setup creates an administrative group, a routing group, and a Windows security group for backward compatibility. These groups are as follows:

• Setup creates an administrative group for the Exchange 2007 servers to be housed in. This administrative group is called Exchange Administrative Group (FYDIBOHF23SPDLT). All Exchange 2007 servers will be in this administrative group; do not move them out of this administrative group.

• Setup creates a routing group called Exchange Routing Group (DWBGZMFD01QNBJR). All Exchange 2007 servers will be in this routing group and you must not move them out of this routing group.

• Setup creates an Active Directory universal security group called ExchangeLegacyInterop. The ExchangeLegacyInterop has permissions that allow Exchange 2003 and Exchange 2007 servers to send messages between each other.

The new administrative and routing groups are not visible within the Exchange 2007 Management Console, but you can see them using the Exchange 2000/2003 System Manager console (see Figure 18.9).

Figure 18.9: Viewing the Exchange 2007 administrative and routing group

If you are installing Exchange Server 2007 into an existing Exchange 2000/2003 environment, during the installation of the first Exchange 2007 Hub Transport server role, you are prompted for an Exchange 2000/2003 server to use as a bridgehead. The setup program will create a routing group connector from the Exchange Routing Group (DWBGZMFD01QNBJR) routing group to the specified server in the remote routing group.

For example, say an organization has two routing groups, the New York Routing Group and the San Francisco Routing group. Each routing group has two Exchange 2003 servers that function as bridgehead servers for the routing group connector that connects the New York and San Francisco routing groups, as illustrated in Figure 18.10.

Figure 18.10: Message routing between Exchange 2003 and Exchange 2007

When the first Exchange 2007 server is installed, the Exchange Routing Group (DWBGZMFD01QNBJR) routing group is created and the setup program prompts the installer for a remote Exchange 2003 server to use as a bridgehead. In this example, we are choosing one of the servers in the San Francisco routing group.

The setup program creates a routing group connector from the Exchange 2007 routing group to the San Francisco routing group. A single local bridgehead and a single remote bridgehead are defined. An identical routing group connector is created from the San Francisco routing group to the Exchange 2007 routing group. Figure 18.11 shows the properties of one of these routing group connectors using the Exchange 2003 System Manager console.

Figure 18.11: Properties of a routing group connector

If you have multiple routing groups and multiple bridgehead servers, you will want to correct a couple of issues. First, there is no redundancy between the Exchange 2003 servers and the Exchange 2007 servers. If either the Hub Transport server or the Exchange 2003 bridgehead server that is being used for the routing group connector fails, then messaging between the Exchange 2003 and Exchange 2007 mailboxes will halt.

Second, you will want to verify that all messages from New York to the Exchange 2007 mailbox servers (and vice versa) will be sent through the San Francisco Exchange 2003 bridgehead servers.

You need to correct both of these issues using the Exchange Management Shell and the routing group cmdlets. The following are the cmdlets you can use for managing routing groups between Exchange 2000/2003 and Exchange 2007:

Let's start with some basics since this is all done from the EMS. First let's use the Get-RoutingGroupConnector with no parameters and retrieve a list of the routing group connectors. Here is an example:

Get-RoutingGroupConnector Name SourceRoutingGroup TargetRoutingGroup ---- ------------------ ------------------ HNLEX03 to HNLEX01 Exchange Routing Group... First Routing Group HNLEX03 to HNLEX01 First Routing Group Exchange Routing Group

The SourceRoutingGroup and TargetRoutingGroup columns have been truncated to fit better into the page in case you were wondering where the full name of the Exchange 2007 routing group is. Now let's retrieve all the properties of the HNLEX03:

Get-RoutingGroupConnector "HNLEX03 to HNLEX01" | FL TargetRoutingGroup : Exchange Routing Group (DWBGZMFD01QNBJR) Cost : 1 TargetTransportServers : {HNLEX03} ExchangeLegacyDN : /o=Volcano Surfboards/ou=First Administrative Group/cn=Configuration/cn=Connections/cn=HNLEX03 to HNLEX01 PublicFolderReferralsEnabled : True SourceRoutingGroup : First Routing Group SourceTransportServers : {HNLEX01} HomeMTA : Microsoft MTA HomeMtaServerId : HNLEX0 MinAdminVersion : -2147453113 AdminDisplayName : ExchangeVersion : 0.1 (8.0.535.0) Name : HNLEX03 to HNLEX01 DistinguishedName : CN=HNLEX03 to HNLEX01, CN=Connections,CN=First Routing Group,CN=Routing Groups,CN=First Administrative Group,CN=Administrative Groups,CN=Volcano Surfboards,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=volcanosurfboards,DC=com Identity : HNLEX03 to HNLEX01 Guid : ObjectCategory : volcanosurfboards.com/Configuration/Schema/ ms-Exch-Routing-Group-Connector ObjectClass : {top, msExchConnector, msExchRoutingGroupConnector} WhenChanged : 11/19/2006 6:38:35 PM WhenCreated : 11/19/2006 6:38:35 PM OriginatingServer : HNLDC01.volcanosurfboards.com IsValid : True

If you wanted to add HNLEX04 as an additional target bridgehead server, you would use the Set-RoutingGroupConnector cmdlet. But this is going to be a bit of a trick since the display names of the routing group connectors are identical, so you need to retrieve just the connector that connects from the Exchange 2000/2003 routing group to the Exchange 2007 routing group. Here is an example using the Where cmdlet:

Get-RoutingGroupConnector | Where {$_.TargetRoutingGroup -eq "Exchange Routing Group (DWBGZMFD01QNBJR)"} Name SourceRoutingGroup TargetRoutingGroup ---- ------------------ ------------------ HNLEX03 to HNLEX01 First Routing Group Exchange Routing Group

You can pipe the results of that cmdlet to the Set-RoutingGroupConnector cmdlet. Here is an example:

Get-RoutingGroupConnector | Where {$_.TargetRoutingGroup -eq "Exchange Routing Group (DWBGZMFD01QNBJR)"} | Set-RoutingGroupConnector -TargetTransportServers HNLEX03,HNLEX04

Now you verify that this change has been made. Here a command that will list the relevant properties of that routing group connector:

Get-RoutingGroupConnector | Where {$_.TargetRoutingGroup -eq "Exchange Routing Group (DWBGZMFD01QNBJR)"} | FL Name,TargetRoutingGroup,SourceRoutingGroup,*transport* Name : HNLEX03 to HNLEX01 TargetRoutingGroup : Exchange Routing Group (DWBGZMFD01QNBJR) SourceRoutingGroup : First Routing Group TargetTransportServers : {HNLEX04, HNLEX03} SourceTransportServers : {HNLEX01}