Collection: Exchange 2007 Hub Transport Server Role(1)

Hub Transport Role

The Hub Transport role is responsible for all internal mail flow. This role is similar to the bridgehead server in an Exchange 2000/2003 organization. In fact it originally was called the Bridgehead Role until it was changed.

The Hub Transport server, as well as the rest of the server roles, is installed on member server(s) in an Active Directory domain. There is no need for ADAM on this, or any other role aside from the Edge Transport. Because it is a member of an AD domain, all its configuration information is stored in AD and any other Hub Transport servers you install will get their configuration from AD.

Inbound mail is accepted from the Edge Transport and passed on to the user's mailbox and all outbound mail is relayed from the Hub Transport to the Edge Transport and out to the Internet. The Hub Transport and Edge Transport servers are very similar and in fact, one can forgo the Edge Transport server and configure the Hub Transport to accept mail from, and send mail to, the Internet. Hub Transport agents can also be deployed to enforce corporate message policies such as message retention, something that will come as good news to administrators attempting to comply with SarbOx rules.

The Anti-Spam and Anti-virus features of the Edge Transport can be configured on the Hub Transport in order to reduce the number of servers required. It is quite feasible that you may only have one server in your Exchange organization with all the roles installed on it. In this case you cannot have an Edge Transport and all those features will be passed on to the Hub Transport role.

Backing up Transport Servers

Unlike Mailbox Servers, the Hub Transport and Edge Transport roles do not require any special Exchange-aware backup software.  All of the necessary data for recovering a Transport server is contained within:

• Active Directory (for Hub Transport servers, but not Edge Transport servers)
• The Active Directory Application Mode (ADAM) database (for Edge Transport servers)
• The server’s file system
• The server’s System State

Hub Transport servers can be backed up using the built in Backup utility in Windows Server.  At the very least the backup should include the System State and the C:Program FilesMicrosoftExchange ServerTransportRoles location of the file system (and all sub directories).

Recovering Hub Transport Servers

In this scenario the EXCHHUB server has been lost due to hardware failure.  Spare server hardware has been used to reinstall Windows Server 2003 along with the Exchange Server 2007 pre-requisites.  The newly built server has the same name and IP address of EXCHHUB.  Now we can begin the recovery of the Hub Transport server.
First, remove any Edge Subscriptions that existed for the Hub Transport server being recovered.  If you skip this step you may receive a certificate error during the recovery install.

In a command prompt run the following command from the location of the Exchange setup files.

setup /m:RecoverServer /DoNotStartTransport

This runs setup in recovery mode along with an additional instruction to not start the Transport services straight away.  This is so we can restore our mail queue databases and log files from the most recent backup before the server is put back into operation.

Organization Configuration > Hub Transport > Remote Domain Properties > General Page (RTM)

Use the General tab for the remote domain's properties to configure the settings that determine the types of out-of-office messages that are sent to recipients in the remote domain. The type of out-of-office messages that are available in your organization depends on both the Exchange client version and the Exchange server version. The out-of-office message is set on the client and is sent by the server.

An Exchange client that has a mailbox located on a Microsoft Exchange Server 2007 Mailbox server and that accesses their mailbox by using Microsoft Outlook Web Access or Outlook 2007 can configure both internal and external out-of-office messages.

An Exchange client that uses Outlook 2003 or earlier can configure only one type of out-of-office message.

An Exchange client that has a mailbox located on an Exchange 2003 or earlier server can have only one type of out-of-office message sent on their behalf.

Out-of-office message types delivered to this remote domain:

To determine the type of out-of-office message that is returned to users at the remote domain, select one of the following options:

·         Allow none
If you select this option, no out-of-office messages are delivered to the remote domain. 

·         Allow external out-of-office messages only
If you select this option, only out-of-office messages that are configured as external by an Outlook 2007 client or by using Outlook Web Access for a mailbox that is located on an Exchange 2007 Mailbox server are delivered to the remote domain.

·         Allow external out-of-office messages, and out-of-office messages set by Outlook 2003 or earlier clients or sent by Exchange Server 2003 or earlier servers
If you select this option, out-of-office messages that are configured as external by an Outlook 2007 client or by using Outlook Web Access for a mailbox that is located on an Exchange 2007 Mailbox server are delivered to the remote domain. Out-of-office messages that are set by Outlook 2003 or earlier clients, regardless of the server version of their mailbox store, are delivered to the remote domain. Out-of-office messages that are sent by Exchange 2003 or earlier servers, regardless of the client version that is used to set the out-of-office message, are delivered to the remote domain.

·         Allow internal out-of-office messages, and out-of-office messages set by Outlook 2003 or earlier clients or sent by Exchange Server 2003 or earlier servers
If you select this option, out-of-office messages that are configured as internal by an Outlook 2007 client or by using Outlook Web Access for a mailbox that is located on an Exchange 2007 Mailbox server are delivered to the remote domain. Out-of-office messages that are set by Outlook 2003 or earlier clients, regardless of the server version of their mailbox store, are delivered to the remote domain. Out-of-office messages that are sent by Exchange 2003 or earlier servers, regardless of the client version that used to set the out-of-office message, are delivered to the remote domain.

Exchange 2007 SMTP Namespace Sharing and Different Relay Domain Types

In this article I will show you how to share your Exchange Server 2007 SMTP namespace with another messaging system. SMTP namespace sharing might be necessary when merging is required or if you want to share the SMTP namespace with a foreign system. I will also show you how to create internal and external mail relay domains.  

Let us assume for this article that you have two different Exchange organizations which are running Exchange Server 2007. These two organizations find together through a merger or acquisition and would like to share the SMTP namespace for a undefined period of time until both messaging systems are migrated to a single Exchange Server 2007 organization. The other part of this article deals with the configuration of internal and external mail relay domains and we assume that one Exchange organization is responsible for e-mail delivery to both domains (A.DOM and B.DOM).

Accepted Domains

When you create new accepted domains in Exchange Server 2007, you have to choose between the following domain types:

• Authoritative domain
• Internal relay domain
• External relay domain

An accepted domain is any SMTP namespace for which your Exchange Server 2007 organization is responsible for and for which you will send and receive e-mail. Microsoft calls this process “authoritative”. You have to create authoritative domains in the Exchange Management Console or with the Exchange Management Shell.

Configuring Accepted Domains

Accepted domains are configured in the organization settings of the Exchange Management Console (EMC) which requires Exchange Organization administrator rights. Accepted domains will be created for the entire Exchange organization on Hub Transport Servers or Edge Transport Servers. If you have implemented the Edge Transport server role, Microsoft recommends that you synchronize the accepted domains from your internal Exchange organization with Edge Sync so you only have to create accepted domains once. Every newly created accepted domain will be copied on to the Edge Transport server.

Authoritative domain

Exchange Server 2007 creates a new accepted domain during the installation of the first Hub Transport Server. The authoritative domain will be created with the internal Active Directory domain name and not with the registered SMTP domain name used on Internet for sending and receiving e-mail. For example: If your internal Active Directory domain name is A.DOM and the registered SMTP domain name is A.COM, the accepted authoritative domain that will be created is A.DOM and you have to create an additional accepted authoritative SMTP domain for the registered SMTP domain.

Note: If you have an Exchange Server 2007 with the Edge server role installed, no accepted domains will be created automatically. You have to create authoritative domains manually or you have to synchronize these accepted domains from your internal Exchange organization with Edge sync.

SMTP namespace sharing

SMTP namespace sharing in Exchange Server 2007 is easier than previous versions of Exchange Server. All you have to do is to create a new accepted domain from type internal relay domain for the SMTP namespace that you want to share. As a second step you have to create an SMTP connector with the address space of the internal SMTP domain. The destination e-mail server must be a Hub Transport Server. The destination e-mail system is then responsible for generating NDRs (Non Delivery Reports).

                                               Figure 1: SMTP namespace sharing

As you can see in the above picture, Exchange accepts messages from A.DOM (the MX record points to the SMTP gateway). A Microsoft Edge Transport server forwards e-mails to the internal Hub Transport Server which in turn tries to deliver e-mails to the recipients. If the recipient is not local, Exchange will look for an SMTP connector with a corresponding address space (if the domain exists as an internal relay domain) and relays the message to this domain.

Relay Domains

If Exchange Server 2007 is not authoritative for a specific domain but the DNS MX record points to the Exchange Server organization’s Hub Transport or Edge Transport server, the sending e-mail server relays e-mails to the Exchange organization. If the SMTP domain is not part of an authoritative domain, the sending server tries to relay through the Exchange server. Exchange Server 2007 accepts this message and relays it to an external e-mail domain or an internal relay domain.

Internal Relay Domain

If you configure an internal relay domain you will forward all e-mails which do not have a corresponding mailbox in the Exchange organization but which are contacts in that Exchange organization. The contacts have an e-mail address for the other messaging system. E-mail from Internet is relayed for this domain through Hub Transport servers in this Exchange organization.

If your organization has two forests with Exchange Server 2007 installed and you want to share e-mails or you want to enable SMTP message flow between these Exchange organizations you must use a system that synchronizes e-mail addresses between these forests. For example you can use IIFP (Identity Integration Feature Pack), a Microsoft solution which is free of charge or IIFPs big brother MIIS (Microsoft Identity Integration Server). E-mail messages from Internet that are addressed to recipients in internal relay domains are received and processed by Edge Transport server (if implemented) and then relayed to the Hub Transport servers in the same Exchange organization. The Hub Transport server which is responsible for e-mail message routing, routes the message to a Hub Transport server in the other Exchange organization. All you have to do is create a send connector at the Exchange organization that routes messages to the destination Exchange organization and an accepted domain from Internal relay type.

Figure 2: Internal relay domain

External Relay Domain

The external relay domain is a bit different than the internal relay domain. When you configure an external relay domain, messages are relayed to an e-mail server outside your Exchange organization. Messages addressed to an external relay domain are relayed through an Exchange Server 2007 Edge Transport Server. This scenario is quite simple. The external relay domain’s MX (Mail Exchanger) record is configured to route e-mail to the Exchange 2007 organization. Exchange Server accepts e-mail messages for this domain name and will route messages to this domain through an SMTP send connector that you must configure. The send connector relays the message to the external relay domain.

                                                  Figure 3: External relay domain

How to use Transport Rules in Exchange Server 2007

Introduction

The upcoming release of Exchange Server, Exchange Server 2007, has an important difference with older versions of the product; it is now possible to create transport rules at organization level that allow us to control the internal and/or external flow of messages in an Exchange Organization in an easy and flexible way.

With the Transport Rules feature, we are now able to easily create rules, such as: disclaimer for the organization, apply security on messages between users, and filter message content based on strings located within it.

Within this article I will discuss how to work with transport rules on Exchange Server 2007 - all rules have been created at organization level on the Hub Transport role.

We can create rules at the Exchange Organization level and they can be configured to work with internal and external traffic.

How do Transport Rules work?

There are three stages in creating a transport rule: conditions, actions and exceptions. These stages are shown during the process of creation within the “New Transport Rule Wizard”. The phases for creation of the rules are shown in Figure 1.

All messages flow through the Hub transport role. It permits a single location to administer the whole exchange organization.

                       Figure 1: Flow chart to create transport rules on Exchange Server 2007

We are going to visualize in the examples below, the combination of conditions, actions and exceptions that we can use in order to get the best possible message control.

Each created rule receives a Priority; these rules vary from low priority (0) to high priority. If a message belongs to 3 (three) separate rules, all rules will be applied on the message always respecting the priority of the rules.

The rules can be edited, disabled or removed. When they are disabled, they do not lose their priorities but they are not included in the evaluation process.

Working with Transport Rules (Scenario)

Transport Rules are very flexible and we can use a lot of options while we create them. I will now show a small example about transport rules; within the example we will use all phases (Condition, Action and Exception). (Figure 1)

I will create a simulated scenario to deploy a transport rule. In this Exchange Organization we have two users: Anderson Patricio and John Rodas. We must validate that no messages can be sent between them, except messages with a subject including the words: Personal or Life. With this feature, we can get internal traffic protection; avoiding that vital information leaves the organization or is exchanged between users, depending on your own criteria.

Let’s go... Creating an Ethical Wall between users…

This scenario is called Ethical Wall, because we can protect the message flow between users and groups based on transport rules

To create our first rule, we will need to click on Hub Transport expanding the Organization Configuration node in the left pane of the Exchange Management Console, then click on the Transport Rules Tab and finally clicking on New Transport Rule on the Action Pane, as can be seen in Figure 2 below.

                   Figure 2: Creating a transport rule on the Exchange Management Console

In the New Transport Rule Wizard, we should fill out the Name and Description and make sure that ‘Enable Rule’ is selected. After that click Next. (Figure 3) 

                                   Figure 3: Wizard welcome screen to create transport rules

Conditions: We can define from who or to a message is going, based on string or message fields or some address inside the fields (To:, From: or Cc). In this example mark From People and you can see in Step 2 the construction of the rule, like the Rules and Alerts in Outlook.

During step 2 click on the ‘people’ link to select the users for this rule. (Figure 4)

                         Figure 4: Conditions – Specifying “from people” on the transport rule

In the new window, we can choose the users that will be affected by this rule, click Add, select user(s) and click OK. The result is shown in the figure below, Figure 5.

                               Figure 5: Selection of users in the “From People” condition

We’ve just selected the user Anderson Patricio in the “from people” condition. After that, we will need to tick “sent to people” and select the “target” user for this rule. In this case, we will choose John Rodas and select him as we did in the previous example. (Figure 6)

Note: 
When we have more than one item ticked in conditions, we have a logical 'AND', so it means that the transport rule will be processed only if all the conditions are valid. If not, the rule will not be executed.

                                  Figure 6: Conditions - Our condition has been established

In the New Transport Rule Wizard page, tick “send bounce message to sender” as shown in Figure 7. With this option selected, when a user (in this example, Anderson Patricio) sends a message to the selected user (in this example John Rodas), the sender (Anderson) will receive a predefined bounce message. (Figure 8)

                        Figure 7: Actions - Defining an Action to conditions specified before

To customize the message that will be displayed in the return message, we will need to click the link “Delivery not authorized, message refused” in Step 2 and then customize the content for the bounce message. (Figure 8)

                     Figure 8: Editing the text of action “send bounce message to sender”

Now, we have completed the Conditions and Actions; it can be reviewed in Figure 9.

                      Figure 9: The conditions and actions phases have been done, click Next

Exceptions: In this case all messages from Anderson Patricio to John Rodas will be blocked, except those e-mail messages including the words Personal and Life in the subject. To do so, tick “except if with specific words in the subject” and then click on the link in Step 2 and add your exception words on the next screen. After that, we can see the result of configured Exception (Figure 10).

                Figure 10: Exceptions – Defining the exceptions in the Transport Rule

On this page, we can review the configured options in the wizard, as shown in Figure 11. We must click Create.

                     Figure 11: Configuration Summary on New Transport Rule Wizard

The below shows the final screenshot for the rule creation wizard using a cmdlet. With a cmdlet we can create the same rule using the Windows PowerShell Console or a wsh administrative script. Click Finish. (Figure 12)

                    Figure 12: Final screen showing the cmdlet used to create this rule.

After clicking on the Finish button, the rules will show up on the Exchange Management Console.

We can select the rule and all the possible actions are also enabled in Action Panel. There are now some actions to assign to this rule: Disable rule, Edit and Remove. (Figure 13)

                                                    Figure 13: Visualizing the created rule

Ok, it’s done! Now we will see the résumé of our transport rule:

Name	Blocking suspicious messages from Anderson Patricio to John Rodas
Condition	From Anderson Patricio AND To John Rodas
Action	Send bounce message
Except	except if word personal or  life in subject

Let’s test the configured rule!

The first test is to send an email from Anderson Patricio to John Rodas (Figure 14). 

Figure 14: User Anderson Patricio is writing to John Rodas about some important information

Our rule will block this kind of email message, and the sender (Anderson Patricio) will get a pre-defined action “set bounce message to sender” (Figure 15). If the sender receives the message below, our Condition and Action configuration is working.

Figure 15: Sender receives the message with the Action of the rule. Pay attention to the message, it has our modification (by MsExchange.org administrator)

The second test is to validate the rule about exceptions. The sender (Anderson Patricio) is going to send another e-mail message but it will have the word Personal in the subject of the message. (Figure 16)

                                      Figure 16: Sending a message to validate Exception

This email has an allowed word in the subject, so the receiver (John Rodas) got the message. We can now validate all the phases of the rule (Conditions, Actions and Exceptions). (Figure 17)

                                        Figure 17: The allowed message is received by user

Configuring Exchange 2007 Hub Transport role to receive Internet mail

Although they are very similar, because the Edge Transport and Hub Transport servers were designed specifically for the role that they play, they have different default settings. For example, the Edge Transport role is configured by default to accept Internet mail, whereas the Hub Transport role is configured to be as secure as possible and does not accept mail from unauthenticated (un-trusted) sources. Because of this, we often get asked if there are options for the customer that cannot or chooses not to run an Edge Transport server.

A brief word about putting an Exchange server directly on the Internet

Historically, Exchange servers should not be directly on the Internet – in no small part because Exchange needs direct access to Active Directory. In the case of the Client Access Server (CAS) protocols (HTTPS, IMAP, POP), the recommendation is for the server to sit behind a reverse proxy/port forwarding firewall like ISA server (now known as ForeFront Threat Management Gateway) that can detect and block attacks. In the case of SMTP, the suggested solution is the Edge Transport role, because it has all the functionality of Exchange (unlike other active SMTP filtering solutions) but still has the isolation options of being completely disjoined from the rest of the Active Directory forest. Whether you chose the Edge Transport or Hub Transport role to receive Internet mail, the server can and should be placed behind a firewall, though active SMTP filtering is not required.

For the customers with only one server, it is suggested to consider a hygiene service such as Exchange Hosted Services (now known as ForeFront Online Protection for Exchange) or perhaps the ISP can offer such a service.

That said, a common configuration for a single Exchange server is to have Exchange sitting directly behind a NAT firewall or reverse proxy like ISA. There is obviously a certain amount of additional risk associated with this approach, but for many smaller customers, the risk is acceptable.

For more information on this topic and the various options available, see "How to Configure Connectors for Internet Mail Flow".

What features will I be missing by doing this?

The five main feature sets that will be missing are:

• Deploy in Perimeter: Edge can be deployed in a perimeter network; specifically, it does not need to be domain-joined (but it can be), which provides greater security. Hub transport requires a connection to Active Directory.
• Isolation: In particular, the SMTP stream from the Internet tends to be full of spam – over 70% of traffic in most cases. By separating this from your internal traffic, you can insure that internal servers are not busy processing and filtering spam. Internal servers are then free to perform routing, compliance, and other mailbox to mailbox operations. This is particularly important if internal email is mission critical.
• Edge Transport rules agent: Instead you get the Hub Transport rules agent. Hub Transport rules are largely for compliance whereas Edge Transport rules are largely for hygiene. For more information about this topic, see "Overview of Transport Rules" (for Exchange 2010, see Understanding Transport Rules).
• Attachment Filtering agent: The hub transport rules do have some attachment options, but the ability to scan the incoming MIME stream for malicious attachment types and reject at the protocol layer is not one of those features; this agent is not installed or supported on Hub Transport servers. However, anti-virus products like Microsoft Forefront Protection for Exchange often provide this functionality.
• Address Rewriting agents: Address rewriting is generally used by larger corporations that will have Edge Transport servers and/or additional software that can perform this functionality.

Receive connector configuration

While there are seemingly limitless ways to configure your receive connectors, I am suggesting the route that involves the least number of steps and can be done completely within the Exchange Management Console (EMC). For more information, check out Receive Connectors

  (or for Exchange 2010). 

Figure 1: Adding the Anonymous users permissions group to the Default receive connector

To find receive connectors in the EMC, navigate to Server Configuration -> Hub Transport. Then select your server and you'll see the Receive Connectors tab below.

The "Default" receive connector on a Hub is configured for other Exchange servers to authenticate, but it doesn't accept anonymous email by default. The easiest way to address this is to add the Anonymous users permissions group to this connector:

Note: In Exchange Server 2007 Beta 2, this step had to be performed from the Exchange Management Shell.

If you fail to do this step, people that send you email will probably get an NDR with the error 530 5.7.1 Client was not authenticated.

Send connector configuration

In order to send email, you need to configure a send connector. This is done in the Exchange Management Console under Organization Configuration -> Hub Transport, then select Send Connectors.

The simplest method is to create one of type "Internet": 

                                               Figure 3: Creating a SMTP sends connector

If you've installed Exchange 2007 into an existing environment with 2003, then you probably already have a Send Connector (SMTP Connector) and you just need to verify the settings. If the connector is on your 2003 server, you can only view the settings from the Exchange 2007 Management Console. All changes will need to be made through from the Exchange 2003 System Manager (look for "SMTP Connectors"). For example, if you only have a connector on the 2003 machine, then all outbound mail will go through the 2003 server. If you have one on the 2003 and one on the 2007 server, then mail will go through the closest connector. If you delete the one on 2003 and have one on the 2007 server, then all outgoing mail will pass through the 2007 server.

In order for all outbound mail to pass through the connector, the address space of the connector should be * (type "smtp"): 

                  Figure 4: Configuring the Address Space on a SMTP send connector

The network tab allows you to specify whether you'll use a smart host (perhaps an SMTP server at your ISP) to relay your messages, or if you'll handle the delivery yourself (using DNS).

The source server specifies which Exchange server or servers in your organization will be responsible for sending Internet email.

Setting up an SPF record for your domain is also a good idea, especially if you relay messages off of your ISP.

Anti-spam configuration

Because Hub Transport servers only need to perform anti-spam functions when there is no Edge Transport server to perform this function, this is another feature that is not enabled by default. Adding this functionality to your Hub Transport servers is a pretty simple process. First, launch the Exchange Management Shell. In the Scripts folder that was created, you will find a PowerShell script to install the Anti-spam agents. After you run this command, you will need to restart your transport service, and restart the Exchange Management Console. 

Figure 5: Installing antispam agents on a Hub Transport server

Once you complete these steps, you will see the Anti-spam tab enabled in the Exchange Management Console. 

                               Figure 6: Antispam agents installed on a Hub Transport server

Please note that if you previously had any Exchange 2003 settings for anti-spam, you will need to migrate your settings over to Exchange 2007.

Useful customizations

Because your server is sitting directly on the Internet, you may want to change the advertised FQDN that is sent in HELO/EHLO commands in SMTP. The UI for both send and receive connectors allows you to configure this.

Because you will not be using Edge Server, you have no need for the Microsoft Exchange EdgeSync service. You can set this service to disabled to prevent it from starting and using system resources.

Final steps

The final step is to 1) make sure that your MX record is correct and 2) that your firewall is letting the connection inbound to port 25. I can't tell you exactly what to do, but usually the easiest method if you already have a mail server is to either reuse that server's IP, or update the firewall rule to point to the new Exchange 2007 server's internal IP.

Use the Mail Flow Analyzer to assist you with troubleshooting issues that may arise. Additionally, there are at least two web sites that can help you diagnose DNS and SMTP receives problems: