Exchange Server Pro » Hub Transport

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

Paul Cunningham — Sat, 24 Sep 2011 12:43:57 +0000

One of the types of Accepted Domains you can add to an Exchange Server 2007 or 2010 organization is an Internal Relay domain.

For Internal Relay domains the Exchange servers behave like this:

If I have a local recipient within the organization with the SMTP address that the email is addressed to then deliver it to that mailbox. Otherwise, send it outside the organization.

Internal Relay domains are commonly used in shared SMTP namespace scenarios, where two separate mail systems both use the same domain name for email. If you want to know more about this scenario read How to Share an Email Domain Between Two Mail Systems.

The steps for setting up an Internal Relay domain are usually:

Add the domain name to the Accepted Domains for the organization
Create a Send Connector to route the non-local recipients in that domain to another external mail system

However the fact is that it will work just fine if you only do step 1, and let your main Send Connector for the “*” namespace (ie, all external domains) handle the routing outwards from the organization (either via smart host or DNS).

That is, unless you are using Edge Transport servers.

If you are using Edge Transport servers, have configured an Internal Relay domain, and have not configured a specific Send Connector for that namespace, you may see non-delivery messages when internal senders try to send to external recipients of that namespace.

This happens because an infinite loop is created between the Hub Transport and Edge Transport servers.

The Hub Transport is correctly routing emails for non-local recipients in the Internal Relay domain name out of the organization via the Edge Transport servers.
However the Edge Transport servers recognize the Internal Relay domain as being local to the organization, and therefore route the email back into the Hub Transport server (as they would if they’d received an email sent from an external sender and addressed to a recipient of that domain name).

Under those conditions you may see non-delivery reports for emails sent to non-local recipients of the Internal Relay domain.

In the diagnostic information will be the reason, an infinite loop.

#554 5.4.6 Hop count exceeded – possible mail loop ##

You will also see the loop in action in the message headers provided with the NDR.

The solution for this problem is to configure a Send Connector for the organization that is specifically for that Internal Relay domain name, that is a lower cost than the default Send Connector.

On an Exchange 2010 server in your organization (not the Edge Transport server) open the Exchange Management Console and navigate to Organization Configuration/Hub Transport. Select the New Send Connector task in the Actions pane of the console.

Give the Send Connector a name and click Next to continue.

Add the SMTP address space for the Internal Relay domain. Choose a cost that is lower than the default Send Connector that EdgeSync creates, which is a cost of 100 by default. Click Next to continue.

You can choose to route via DNS or a smart host, whichever suits your specific scenario. DNS is probably going to be fine if the MX records for that domain already point to where you want the mail to be routed to. Otherwise a smart host may be required. Click Next to continue.

Set the source server depending on which server you want to send out the emails to that domain. For Internal Relay domains the source server for the Send Connector must be a Hub Transport server, not an Edge Transport server, in order to achieve the desired email routing for all scenarios. This means that the Hub Transport server you choose must be able to make SMTP connections through your firewall to wherever it needs to route the email for the Internal Relay domain.

Finally, click New to complete the wizard and create the new Send Connector.

With the Send Connector in place you should see the correct routing behaviour in each scenario. Outside senders who send to a non-local recipient in the Internal Relay domain will be correctly routed into the Exchange organization first, and then back out the Send Connector from the Hub Transport server. Meanwhile email sent to local recipients of the Internal Relay domain will be delivered locally.

Email sent from internal senders to non-local recipients of the Internal Relay domain will be correctly routed out the Send Connector as well, while email sent to local recipients of the Internal Relay domain will be delivered locally as expected.

This configuration achieves the desired message delivery without infinite loop conditions.

Bottom line is, if you are using Internal Relay domains and also Edge Transport servers you must configure a Send Connector for handling non-local recipients in that domain, or else you will create an infinite loop condition.

Get more Exchange Server tips at ExchangeServerPro.com

How to Migrate a Relay Connector from Exchange Server 2007 to 2010

Paul Cunningham — Sat, 13 Aug 2011 13:09:42 +0000

In most organizations some applications or devices require the ability to relay email through Exchange servers.

The source IP addresses of applications and devices that integrate with Exchange using SMTP will need to be added to a Receive Connector that permits relay. Over time this can built up to quite a long list, which creates a tedious task of re-entering all of those IP addresses when you want to migrate this relay connector role, for example during a migration from Exchange 2007 to Exchange 2010.

However if you’d prefer a faster way of doing this you can effectively clone the remote IP address configuration from the existing Receive Connector to the new one by using the Exchange Management Shell.

On an Exchange 2010 server launch the Exchange Management Shell.

The first step is to retrieve the list of remote IP addresses from the existing receive connector by running the following command. This is a single line command, and you should replace the server name and connector name to suit your environment.

[PS] C:\>$ips = (Get-ReceiveConnector "HO-EX2007-HT1\Relay HO-EX2007-HT1").RemoteIPRanges

Next run the following command to create the new relay connector on the Exchange 2010 Hub Transport server with the same remote IP range. Again this is a single line command, and you should replace the server name and connector name to suit your environment.

[PS] C:\>New-ReceiveConnector -Name "Relay HO-EX2010-CAHT1" –Server HO-EX2010-CAHT1” -Usage Custom -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers -Bindings 0.0.0.0:25 -RemoteIPRanges $ips

Identity                                Bindings                           Enabled
--------                                --------                           -------
HO-EX2010-CAHT1\Relay HO-EX2010-CAHT1   {0.0.0.0:25}                       True

With that simple two step process the new relay connector has been created on the Exchange 2010 Hub Transport server with the same remote IP range as the original one.

Get more Exchange Server tips at ExchangeServerPro.com

Review of CodeTwo Exchange Rules Pro

Paul Cunningham — Sun, 31 Jul 2011 10:53:50 +0000

CodeTwo Exchange Rules Pro is an email management program for Exchange Server 2007/2010 that provides many useful features and enhancements for Exchange environments.

To understand how CodeTwo Exchange Rules Pro works think of it like an add-on for the Transport Rules feature of Exchange Server 2010/2007.

There are a whole lot of things you can do with Transport Rules. But the problem is that Transport Rules are pretty awkward to work with due to the very basic configuration wizard in the Exchange Management Console.

Basically CodeTwo Exchange Rules Pro takes the capabilities of Transport Rules and makes them easier to work with, enhances them in highly useful ways, and even adds a few new capabilities to the mix.

Each rule that you configure in Exchange Rules Pro has the following attributes:

Conditions – the criteria that trigger the rule, such as email to or from particular users, or containing certain keywords.

Actions – the action that you want the rule to take, such as adding a disclaimer, removing profanity, or responding with a pre-configured message.

Exceptions – any specific criteria that the rule should not apply to.

Options – extra details such as whether to continue processing additional rules after this one, or specific time ranges that the rule applies to.

With such fine-grain controls over rules it is pretty easy to configure rules for just about any business scenario I can think of.

Installing CodeTwo Exchange Rules Pro

I installed CodeTwo Exchange Rules Pro on a Windows Server 2008 R2 server running Exchange Server 2010 SP1. The Exchange Server was installed with the typical server roles of Mailbox, Client Access, and Hub Transport.

The installation was very quick and simple. It will restart the Transport services on the server, so you just need to be aware of that and perhaps schedule your installation for outside of business hours.

When the install is finished the administration console opens and you’ll see a series of pre-configured example rules (that are disabled) to help you get started.

Features of CodeTwo Exchange Rules Pro

Although there is a long list of features for CodeTwo Exchange Rules Pro in this review I’ll focus on just a few of the ones I found the most interesting.

Email Disclaimers

Disclaimers are one of the most useful features of CodeTwo Exchange Rules Pro. Almost every customer I work with would like to standardize their corporate email signatures, but find that the built-in Transport Rules are too cumbersome to deal with and don’t make it easy to create good looking disclaimers.

CodeTwo Exchange Rules Pro solves this problem with it’s easy to use HTML editor for email disclaimers. A simple WYSIWYG interface lets you create very attractive email disclaimers without having to know any HTML code. You can add dynamic fields such as Active Directory user attributes, and even use the photos stored in Active Directory as part of the email signature you create.

The HTML editor includes a library with a few dozen sample disclaimers, including disclaimers designed to appear at the top, side and bottom of email messages. I would bet that there is a sample design in the library that would suit almost any business, with just the simple step of swapping out the place holder logo for your own company logo.

There is also an image library with useful graphics for situations such as customer support autoresponders and legal disclaimers.

As you’re configuring rules you can use the handy Rule Tester to see whether they are working as you want them to before you apply them to your production users.

There is also the option to have CodeTwo Exchange Rules Pro automatically update the sent items in user mailboxes so that they look the same as after they have been processed by rules. There is a real benefit to your users being able to see exactly the same email message in their sent items that the recipients received, complete with all of the changes made by rules.

Auto-Responders

I’ve been asked many times in the past whether Exchange can be configured to automatically respond to certain emails with a pre-configured message. The usual scenarios for this are for example a marketing team who wants to promote an email address that people can send a message to requesting an information pack, or a jobs inbox that needs to automatically acknowledge each job application email that it receives.

There are various ways to achieve some of this using Outlook rules but they usually require an Outlook client logged in somewhere to actually process the rules.

Exchange Rules Pro makes this possible with auto-response rules that can be configured centrally on the server and work regardless of whether a user is logged on or not.

Removing Profanity

This scenario has come up a few times as well, the problem of staff having to deal with profanity in emails. They’re all grownups, and aren’t too sensitive to the occasional bad word, but a few contact centers that I’ve worked with receive a constant stream of abusive email for various reasons.

Believe it or not, this has actually resulted in some lawsuits because of the working conditions that it creates for staff.

Once again CodeTwo Exchange Rules Pro solves this problem with a handy content filter. This feature comes with a series of pre-configured dictionaries, including an obscene language dictionary. But rather than just block emails with bad language in them, the program can be configured to replace those words with some harmless text, allowing the email to be dealt with by staff without them having to read the profanity.

Time Ranges

The last feature I’ll describe in this review is the Time Range settings. These can be applied to every rule you create so that they will only apply at certain times of day, or for certain days.

Being able to pre-configure a rule to start and stop at specific times takes a lot of pressure off the IT staff and removes human error from the equation.

I know a lot of customers who will enjoy this feature for situations such as:

Adding short-term marketing campaign information to disclaimers
Automatically turning on and off the Christmas office closure message
Replying to overnight support emails with details of the standard support hours

Summary

It is pretty clear that CodeTwo Exchange Rules Pro solves a lot of common business problems, and adds several enhancements and ease of administration to the standard Transport Rules capabilities of Exchange Server 2007/2010.

It’s nice to see such a useful product comes at a reasonable price as well. Licensing is user-based, not –server-based, and a small business of less than 50 staff only has to pay $330 USD for the software and $67 USD for each year of support.

I recommend checking out CodeTwo Exchange Rules Pro for yourself by downloading the trial here, or by watching the demonstration videos on the CodeTwo Youtube channel.

Click to Show Screenshot Gallery »

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2007/2010 Transport Rule Logging

Paul Cunningham — Sat, 25 Jun 2011 02:00:34 +0000

The Transport Rule feature of Exchange 2007 and 2010 Hub and Edge Transport servers is very useful. One of the questions I was asked recently is whether or not there is a log file that can be checked to see how many “hits” a transport rule has.

This won’t suit all transport rules, for example if you’re using them to apply disclaimers that is probably not something you want to be constantly logging.

But for scenarios such as data leak prevention logging may be more appropriate.

Fortunately Exchange 2007 and 2010 do both allow transport rules to be logged, simply by adding “log an event with message” as an Action in the configuration of the rule.

Configure the message to say something relevant to the transport rule.

Every time the rule conditions are met and the server takes the configured action an event log entry will also be logged.

Those event log entries can then be reported on by running a script or scraped with your network monitoring system.

Get more Exchange Server tips at ExchangeServerPro.com

Installing an Exchange 2007 Hub Transport Server on Windows Server 2008

Paul Cunningham — Sat, 28 May 2011 12:00:28 +0000

The Exchange Server 2007 Hub Transport server role is responsible for transmitting all email messages between recipients inside and outside of the organization. Every email message sent or received will traverse at least one Hub Transport server, even messages sent between mailboxes that reside in the same mailbox database.

Outlook clients do not send mail directly to the Hub Transport server via SMTP. The Mailbox server submits sent messages to the Hub Transport server instead. However non-MAPI clients and devices such as network printers and POP/IMAP users do send mail via the Hub Transport server using SMTP.

This tutorial demonstrates how to install an Exchange Server 2007 Hub Transport server on Windows Server 2008. It is assumed that you have already extended the Active Directory schema for Exchange 2007.

Installing Exchange 2007 Hub Transport Server Pre-Requisites on Windows Server 2008

On Windows Server 2008 the pre-requisite roles and features for the Exchange 2007 Hub Transport server role can be installed using ServerManagerCmd.exe.

Launch an elevated command prompt and run the following command.

ServerManagerCmd -i PowerShell Web-Metabase Web-Lgcy-Mgmt-Console

Next download the Windows Installer 4.5 file from Microsoft and install it on the server. The Windows6.0-KB942288-v2-x64.msu file is the correct one for a 64-bit Windows Server 2008 server.

A restart will be required before you move on to the next step.

Installing the Exchange 2007 Hub Transport Server Role

To install the Exchange 2007 Hub Transport server role download the Exchange Server 2007 SP3 setup files from Microsoft and extract them to a folder on the server’s hard disk.

Launch an elevated command prompt and run the following command.

setup /m:install /r:h,t

Welcome to Microsoft Exchange Server 2007 Unattended Setup

Preparing Exchange Setup

The following server roles will be installed
    Management Tools
    Hub Transport Role

Performing Microsoft Exchange Server Prerequisite Check

    Hub Transport Role Checks        ......................... COMPLETED

Configuring Microsoft Exchange Server

    Copying Exchange files           ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Hub Transport Server Role        ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to tak
e effect. Please reboot this server prior to placing it into production.

Reboot the server before proceeding to apply the latest updates and configure the server for your environment.

Install and Register the Office Filter Pack IFilters

An optional step is to install the Office Filter Pack and register the IFilters so that Exchange Server 2007 can index those file types.

You can install either the Office 2007 Filter Pack or the Office 2010 Filter Pack (which includes the Office 2007 IFilters). After you install the filter pack the IFilters need to be registered.

You can find the instructions and the script to register the IFilters here. Copy the script into Notepad and save it as Exchange_reg.vbs.

The script creates a registry file for you in the same folder.

Double-click the reg file to import it into the registry of the Hub Transport server (make sure you do this while you’re logged onto the Hub Transport server itself).

Although the script tells you to restart the Microsoft Exchange Search service, that service does not exist on Hub Transport servers so you can ignore it.

Get more Exchange Server tips at ExchangeServerPro.com

Resolving Anonymous Mail to the GAL with Exchange Server 2010

Paul Cunningham — Wed, 13 Apr 2011 12:36:07 +0000

It is fairly common in Exchange Server 2010 environments for there to be applications or devices that send email to users. These are usually configured to relay email messages using an SMTP connection to a Hub Transport server. They almost never authenticate their SMTP session, so are considered anonymous senders by Exchange 2010.

In this scenario you may encounter an issue where the emails that end users receive show the SMTP address of the sender instead of the more friendly display name configured on the user mailbox that has that SMTP address.

For example an email from a scanner device will appear like this.

This will occur if the Receive Connector on the Hub Transport server is accepting anonymous email. Receive Connectors are not configured this way by default but many Exchange administrators enable it because it is the simplest way to allow applications or devices to send emails to internal recipients.

To enable Exchange Server 2010 to resolve the anonymous emails you need to configure the Authentication settings for the Receive Connector to enable the Externally Secured option.

However this is not possible for the Default Receive Connector due to the other Authentication settings that are already enabled.

Instead what you can do is create a relay connector for Exchange Server 2010 following the instructions here. Whether you restrict it to certain sender IP’s or allow your entire private network to use the relay connector is up to you.

Emails sent from devices using the new Receive Connector will resolve the name correctly from the GAL now.

Get more Exchange Server tips at ExchangeServerPro.com

How to Publish POP3 Client Settings to Users with Exchange 2010 SP1

Paul Cunningham — Fri, 18 Mar 2011 12:37:06 +0000

When you are deploying POP3 for Exchange Server 2010 it is useful to have a way to publish the correct server settings that users should configure their email client to use. Exchange Server 2010 SP1 has a neat way of publishing this information in the Exchange Control Panel (in OWA).

The first thing you’ll need to know is the POP and SMTP server settings that you want clients to use. In this example we’ll use these server names:

pop.exchangeserverpro.net
smtp.exchangeserverpro.net

These names will both need public DNS records created on your DNS servers. The POP3 server name (pop.exchangeserverpro.net in this case) should also have a valid SSL certificate installed and enabled for POP with a matching name so that you can use secure POP3 access.

Checking the Client Access server in this example I can see that the X509 certificate name configured for POP3 is not the correct one I want.

[PS] C:\>Get-PopSettings | fl x*

X509CertificateName : esp-ho-ex2010a

To change it we can use the Set-POPSettings cmdlet.

[PS] C:\>Set-PopSettings -X509CertificateName pop.exchangeserverpro.net

Next we need to look at the SMTP server. On the Hub Transport server there are two Receive Connectors configured by default.

[PS] C:\>Get-ReceiveConnector

Identity                                Bindings                                Enabled
--------                                --------                                -------
ESP-HO-EX2010A\Client ESP-HO-EX2010A    {:::587, 0.0.0.0:587}                   True
ESP-HO-EX2010A\Default ESP-HO-EX2010A   {:::25, 0.0.0.0:25}                     True

It might seem logical to use the “Default ” connector because it is bound to TCP port 25 (SMTP). However is actually the “Client ” connector that is intended for this use. Here is what TechNet says about these two Receive Connectors.

Client Servername – This Receive connector accepts SMTP connections from all non-MAPI clients, such as POP and IMAP.

Default Servername – This Receive connector accepts connections from other Hub Transport servers and any Edge Transport servers you have.

The “Client ” Receive Connector is bound to TCP port 587. It is also configured by default to respond to new connections with the FQDN of the server itself.

[PS] C:\>Get-ReceiveConnector "Client ESP-HO-EX2010A" | fl fqdn

Fqdn : esp-ho-ex2010a.exchangeserverpro.net

We can change that to the desired name using the Set-ReceiveConnector cmdlet.

[PS] C:\>Set-ReceiveConnector "Client ESP-HO-EX2010A" -Fqdn smtp.exchangeserverpro.net

Now that all of the information has been gathered and the correct settings applied we can publish the information to users in Exchange Control Panel. This is what a user would normally see in ECP.

When they click on the link there are no settings displayed by default.

We can see that no external connection settings have been configured to be published.

[PS] C:\>Get-PopSettings | fl external*

ExternalConnectionSettings : {}

[PS] C:\>Get-ReceiveConnector "Client ESP-HO-EX2010A" | fl adv*

AdvertiseClientSettings : False

To publish the settings to this location we can run the following commands.

[PS] C:\>Set-PopSettings -ExternalConnectionSettings {pop.exchangeserverpro.net:995:ssl}

In the example above the port and security settings from the previous article on securing POP3 for Exchange 2010 have been used.

[PS] C:\>Set-ReceiveConnector "Client ESP-HO-EX2010A" -AdvertiseClientSettings $true

To apply the change reset IIS on the Client Access server.

[PS] C:\>iisreset

Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

Now when we return to the Exchange Control Panel the users can see the published settings.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 Hub Transport Server Backup and Recovery

Paul Cunningham — Wed, 25 Aug 2010 09:00:23 +0000

The Exchange Server 2010 Hub Transport Server role is responsible for all email flow within the organization. Every email between two recipients, whether they are both internal mailboxes or one is an external mailbox, will traverse at least one Hub Transport server. This even includes emails between two mailboxes stored on the same database.

In addition to the delivery of email the Hub Transport server also applies transport rules, performs journaling, and can optionally provide message hygiene services as well.

What Needs to be Backed Up on Hub Transport Servers?

To plan for backup and recovery of the Hub Transport server you first need to understand where the server stores its configuration and data.

Active Directory – most of the Hub Transport server configuration information is stored in Active Directory. However there are a few exceptions to that.

System State – the system state contains information such as SSL certificates installed on the server, and service startup and dependency settings in the registry, which will be important if they have been modified from the defaults. The system state will also include information about any other applications or agents installed on the Hub Transport server, such as antivirus and anti-spam products.

File System – the file system contains the transport queues and some of their ESE settings, log files such as message tracking logs and protocol logs, and customizations made to the local transport configuration. The file system will also include the program files for any additional applications or agents installed on the server.

Planning the Hub Transport Server Backup

When you are planning the Hub Transport server backup strategy there are different approaches you can take depending on your requirements.

Backing up Everything

A full system backup of the server, along with a working Active Directory, encompasses all of the required information for a recovery. However this backup takes the longest and will consume the most backup storage.

If a server failed and needed to be recovered from a full backup any undelivered messages still in the transport queue would be lost. But it is impractical to backup the entire server multiple times a day just to protect the transport queue databases from data loss.

Depending on the Exchange environment and the backup infrastructure in place a full server recovery may take longer than simply rebuilding the server from scratch.

Backing up the Minimum

To save on backup storage and minimize the backup time frame the minimum data on the Hub Transport server can be backed up. For most environments this would mean only backing up the transport queue databases and the log files on the file system.

Because these would be relatively fast to back up this type of backup could be performed multiple times per day to minimize the risk of losing undelivered messages. This concern would mostly apply to high volume email environments where the transport queues are regularly backlogged. Of course in those cases some attention should be paid to whatever performance bottleneck is causing the backlog, if it is something within the control of that organization to fix.

Backing up Nothing

A perfectly feasible backup strategy for the Hub Transport server is to back up nothing at all. This would be practical if:

there are multiple, redundant Hub Transport servers deployed
the transport queues are not frequently backlogged
the organization does not wish to retain any log files from the Hub Transport servers

If all those conditions are true then it may not be necessary to back up the Hub Transport servers at all.

Backing Up and Restoring Hub Transport Servers

For the purposes of this demonstration I’ve configured a Hub Transport server with an additional Receive Connector.

Message tracking logs are also enabled.

Recovering a Hub Transport Server

As mentioned earlier most of the critical Hub Transport server configuration is stored in Active Directory. When a Hub Transport server has failed you can recover the server using the following process.

Install a new server to host the Hub Transport server role
Configure the server with the same name and IP address as the failed server, and join it to the domain
Install the Exchange Server 2010 pre-requisites
Perform an installation of Exchange Server 2010 using Recovery Mode

To run setup in Recovery Mode use the following command to launch Exchange Server 2010 set from an elevated command prompt.

C:\Admin\Exchange 2010>setup /m:recoverserver

Setup performs a server recovery instead of a normal installation.

Welcome to Microsoft Exchange Server 2010 Unattended Setup

By continuing the installation process, you agree to the license terms of
Microsoft Exchange Server 2010. If you don't accept these license terms,
please cancel the installation. To review these license terms, please go to

http://go.microsoft.com/fwlink/?LinkId=150127&clcid=0x409/

...............
No key presses were detected.  Setup will continue.
Preparing Exchange Setup

    Copying Setup Files              ......................... COMPLETED

The following server roles will be recovered
    Hub Transport Role
    Management Tools

Performing Microsoft Exchange Server Prerequisite Check

    Hub Transport Role Checks        ......................... COMPLETED
 This computer requires the 2007 Office System Converter: Microsoft Filter Pack.
 Please install the software from http://go.microsoft.com/fwlink/?LinkId=123380.

Configuring Microsoft Exchange Server

    Preparing Setup                  ......................... COMPLETED
    Stopping Services                ......................... COMPLETED
    Copying Exchange Files           ......................... COMPLETED
    Restoring Services               ......................... COMPLETED
    Hub Transport Server Role        ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Finalizing Setup.                ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to tak
e effect. Please reboot this server prior to placing it into production.

Restart the server as prompted. When the server has finished restarting you can verify that configurations such as the additional Receive Connector and the message tracking log configuration have been recovered with the server.

However the log files themselves are not restored during a Recovery Mode install of Exchange Server 2010.

Neither are additional applications or agents that were previously installed ont he server. For the Hub Transport server one notable item would the Microsoft Office Filter Pack.

Therefore the server is not fully recovered until all of those items, along with any further customizations to the server, have been manually applied.

Full System Backup/Restore for Hub Transport Servers

For this demonstration I used Windows Server Backup to take a full system backup of the Hub Transport server to use for bare metal restore.

This backup can take a while depending on your backup infrastructure and the amount of data involved. However it simplifies the restore process because it restores the full system including log files, customizations, and additional applications.

The full restore brings the server back to an operational state ready for production, however it is a point in time recovery and will not include log file entries or mail items that were still in the transport queue since that point in time.

Recovering Hub Transport Servers with Minimal Backups

When the minimal backup strategy is used in conjunction with server recovery it allows you to make use of an effective hybrid approach to Hub Transport server recovery.

In this approach you combine the two techniques:

fast, frequent backups of the transport queues and message tracking log files at regular intervals throughout the day
restoration using Recovery Mode with and the latest backup files

To do this you run Exchange Server 2010 setup in Recovery Mode as demonstrated earlier but with an additional command line switch.

C:\Admin\Exchange 2010>setup /m:RecoverServer /DoNotStartTransport

The /DoNotStartTransport switch stops setup from starting the Microsoft Exchange Transport service when it finishes installation.

This allows you the opportunity to restore the most recent transport queue database and message tracking log files onto the server before it is put back into production use.

With this recovery model you will still need to reinstall additional applications or agents as with the previous Recovery Mode technique.

Summary

As you can see there are pros and cons to each backup strategy for the Hub Transport server role in Exchange Server 2010. For many organizations the full system backup/restore will be the simplest choice, though it will consume the most backup storage and takes longer to back up. For high volume environments or those with strict auditing and retention requirements the frequent backups of the transport queue database and log files may be the preferred approach instead.

Get more Exchange Server tips at ExchangeServerPro.com

How to Configure a Relay Connector for Exchange Server 2010

Paul Cunningham — Thu, 19 Aug 2010 09:00:59 +0000

In most Exchange Server 2010 environments there will be the need to allow relaying for certain hosts, devices or applications to send email via the Exchange server. This is common with multi-function devices such as network attached printer/scanners, or applications such as backup software that send email reports.

SMTP communication is handled by the Hub Transport server in an Exchange organization. The transport service listens for SMTP connections on it’s default Receive Connector. However, this connector is secured by default to not allow anonymous connections (ie, the type of connection most non-Exchange systems will be making).

You can see this in effect if you telnet to the server on port 25 and try to initiate unauthenticated SMTP communications.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 19:42:27 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: somebody@hotmail.com
530 5.7.1 Client was not authenticated

For some Hub Transport servers that are internet-facing, anonymous connections may already be enabled. In those cases relay would still be denied but will behave differently than the first example.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:01:44 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: somebody@hotmail.com
250 2.1.0 Sender OK
rcpt to: somebody@gmail.com
550 5.7.1 Unable to relay

You’ll note that relay is denied if I try to send from an @hotmail.com address to an @gmail.com address, because neither is a valid domain for the Exchange organization. But with Anonymous Users enabled on the Receive Connector I can send from an @hotmail.com address to a valid local address.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:05:54 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: somebody@hotmail.com
250 2.1.0 Sender OK
rcpt to: alan.reid@exchangeserverpro.local
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
test
.
250 2.6.0  [In
ternalId=2] Queued mail for delivery

However if I try to relay out to an external recipient, the Exchange server does not allow it.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:11:27 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: backups@exchangeserverpro.net
250 2.1.0 Sender OK
rcpt to: alerts@managedserviceprovider.com
550 5.7.1 Unable to relay

To permit a non-Exchange server to relay mail we can create a new Receive Connector on the Hub Transport server. Launch the Exchange Management Console and navigate to Server Management, and then Hub Transport. Select the Hub Transport server you wish to create the new Receive Connector on, and from the Actions pane of the console choose New Receive Connector.

Give the new connector a name such as “Relay ” and click Next to continue.

You can leave the local network settings as is, or optionally you can use a dedicated IP address for this connector if one has already been allocated to the server. Using dedicated IP addresses for each connector is sometimes required if you need to create connectors with different authentication settings, but for a general relay connector it is not necessary to change it.

Highlight the default IP range in the remote network settings and click the red X to delete it.

Now click the Add button and enter the IP address of the server you want to allow to relay through the Exchange server. Click OK to add it and then Next to continue.

Click the New button to complete the wizard.

The Receive Connector has now been created but is not yet ready to allow the server to relay through it. Go back to the Exchange Management Console, right-click the newly created Receive Connector and choose properties.

Select the Permission Groups tab and tick the Exchange Servers box.

Select the Authentication Tab and tick the Externally Secured box.

Apply the changes and the Receive Connector is now ready for the server to relay through.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:31:00 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: backups@exchangeserverpro.net
250 2.1.0 Sender OK
rcpt to: alerts@managedserviceprovider.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
test
.
250 2.6.0 <924bab1e-0f07-4054-8700-d121577993b4@EX3.exchangeserverpro.local> [In
ternalId=3] Queued mail for delivery

Because the remote IP range has been secured to that single IP address, any other servers on different IP addresses still won’t be able to relay through the Exchange Server. From any other IP address not included in the remote IP range on the Receive Connector relay will be denied.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:46:06 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.2]
mail from: backups@exchangeserverpro.net
250 2.1.0 Sender OK
rcpt to: alerts@managedserviceprovider.com
550 5.7.1 Unable to relay

You can later add more IP addresses, IP ranges, subnets, or even add multiple IP addresses to the Receive Connector using a script if necessary.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 Setup Fails when MSExchangeTransport Service Won’t Start

Paul Cunningham — Thu, 12 Aug 2010 09:00:48 +0000

Installation of Exchange Server 2010 may fail when the Microsoft Exchange Transport Service (MSExchangeTransport) is unable to start.

In this case the server was being installed with multiple roles. When the Hub Transport role could not install the remaining roles were cancelled by setup.

Looking in the event log the following event was found.

Log Name: Application
Source: MSExchangeTransport
Date: 12/08/2010 2:43:02 PM
Event ID: 5023
Task Category: Routing
Level: Error
Keywords: Classic
User: N/A
Computer: SERVER
Description:
A transient configuration error was detected while the routing configuration was loading. Exception details: Unable to determine the local Active

Directory site : Microsoft.Exchange.Transport.Categorizer.TransientRoutingException: Unable to determine the local Active Directory site
at Microsoft.Exchange.Transport.Categorizer.AdSiteRelayMap.ValidateConfig(ExchangeTopology topology, ExEventLog eventLogger, DateTime timestamp)
at Microsoft.Exchange.Transport.Categorizer.RoutingTables.ValidateConfig(RawRoutingConfigData rawConfigData)
at Microsoft.Exchange.Transport.Categorizer.RoutingTables.PopulateTables(RawRoutingConfigData rawConfigData)

A few minutes prior this event was logged.

Log Name: Application
Source: MSExchange ADAccess
Date: 12/08/2010 2:39:54 PM
Event ID: 2501
Task Category: General
Level: Error
Keywords: Classic
User: N/A
Computer: SERVER
Description:
Process MSEXCHANGEADTOPOLOGY (PID=2660). The site monitor API was unable to verify the site name for this Exchange computer – Call=HrSearch Error code=80040a01. Make sure that Exchange server is correctly registered on the DNS server.

When checking the DNS record for the server it was found that two DNS records had been registered. Because the server is also being deployed as a Client Access server in an NLB cluster it has two interfaces. Both interfaces were enabled for DNS registration.

The problem was resolved with the following steps:

Disabling DNS registration for the NLB adapter
Restarting the server (the server was in a “pending restart” state from the first installation attempt)
Removing Exchange Server 2010 via the Control Panel
Reinstalling Exchange Server 2010 with the desired roles

The reinstall was successful now that DNS registration was disabled and only one DNS record existed for the server.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » Hub Transport

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

Related posts:

How to Migrate a Relay Connector from Exchange Server 2007 to 2010

Related posts:

Review of CodeTwo Exchange Rules Pro

Installing CodeTwo Exchange Rules Pro

Features of CodeTwo Exchange Rules Pro

Email Disclaimers

Auto-Responders

Removing Profanity

Time Ranges

Summary

Related posts:

Exchange 2007/2010 Transport Rule Logging

Related posts:

Installing an Exchange 2007 Hub Transport Server on Windows Server 2008

Installing Exchange 2007 Hub Transport Server Pre-Requisites on Windows Server 2008

Installing the Exchange 2007 Hub Transport Server Role

Install and Register the Office Filter Pack IFilters

Related posts:

Resolving Anonymous Mail to the GAL with Exchange Server 2010

Related posts:

How to Publish POP3 Client Settings to Users with Exchange 2010 SP1

Related posts:

Exchange 2010 Hub Transport Server Backup and Recovery

What Needs to be Backed Up on Hub Transport Servers?

Planning the Hub Transport Server Backup

Backing up Everything

Backing up the Minimum

Backing up Nothing

Backing Up and Restoring Hub Transport Servers

Recovering a Hub Transport Server

Full System Backup/Restore for Hub Transport Servers

Recovering Hub Transport Servers with Minimal Backups

Summary

Related posts:

How to Configure a Relay Connector for Exchange Server 2010

Related posts:

Exchange 2010 Setup Fails when MSExchangeTransport Service Won’t Start

Related posts: