The problem first appeared as an imbalance in the volume of email traffic that each Hub Transport server in one particular site were handling.

This was picked up in some routine performance monitoring. The daily email traffic for each of the five Hub Transport servers in this site for the last 30 days was calculated using message tracking log analysis, and the data used to generate this graph.

Traffic Load Pattern for Hub Transport Servers

The heavy days are week days (Monday to Friday) and the dips are the weekends.

That trend is not surprising, but what did catch my eye was the way SERVER4 is handling twice the traffic as any other server in that site. Each of the other four servers is handling roughly the same amount as each other, but SERVER4 stands out above them all.

How Exchange Hub Transport Servers Load Balance Traffic

This particular site is not internet-facing. In other words it is not responsible for email traffic going in and out of the Exchange organization.

Therefore, the Hub Transport servers in this site are primarily handling messages between mailboxes within that site, or messages to/from other sites (whether for mailboxes in the other sites, or to/from the internet via one of the internet-facing sites).

Hub Transport servers in this scenario do not need any special load balancing configuration applied. Within an Active Directory site, and for email traffic between sites, Exchange performs it’s own form of automatic load balancing.

In effect, the Exchange server will look at the list of available Hub Transport servers for the route an email message needs to take, randomize that list of servers, and then try each of them starting with the first in the list until it finds one that is able to accept the message. Unless there is a fault of some kind it will usually send to the first Hub Transport server in the randomized list.

So while it doesn’t perfectly load balance the traffic, it should do so within a pretty small degree of variation.

Checking for Hub Transport Load Spikes

One of my first thoughts was that perhaps SERVER4 is being hit with a spike of traffic at some period of the day that is causing it to record more email traffic each day. It is entirely possible that some rogue device or application has been hard-coded to directly address SERVER4 for it’s SMTP needs.

I once again used message tracking log analysis of the past 30 days to generate a graph of the average email traffic across each hour of the day.

• Calculate Hourly Email Traffic using Message Tracking Logs and Log Parser

The graph turned out to be unremarkable, no load spikes visible.

Daily email traffic load on the Hub Transport SERVER4

Checking for Top Senders

Since there is no apparent load spike, but the possibility remains that a particular host or application is sending a high volume of email throughout the day, the next angle of attack was to check the top senders (ie remote IP addresses) for email traffic through this server.

• Report Top Sender IP’s on Exchange Server 2010 using Log Parser

The results again were fairly unremarkable. But I also took a few extra moments to run the same message tracking log analysis on the other four Hub Transport servers in the site. This is where things took an interesting turn.

Where SERVER3-5 each showed an expected result for the top senders, SERVER1-2 showed interesting results. Those two servers had plenty of remote IP addresses logging hits on them, but a complete lack of any other Exchange servers in that list.

In other words, it began to appear that SERVER1 and SERVER2 were not handling any Exchange -> Exchange email traffic.

So what was all the email traffic they were logging?

SMTP Relay Traffic

Within this site we make available a DNS alias for applications and devices that need to use an SMTP service to send alerts or reports via email. This DNS alias is load balanced across both SERVER1 and SERVER2.

Now, considering that SERVER1 and SERVER2 should be processing their fair share of normal Exchange traffic, as well as the additional load of SMTP relay from applications and devices, you would expect their daily traffic graphs to be higher than the others in the site.

• Calculate Daily Email Traffic using Message Tracking Logs and Log Parser

Instead, this is what a single day’s email traffic amounts to on each Hub Transport server.

Total Email Traffic per Hub Transport Server

To confirm the suspicion that SERVER1 and SERVER2 were not processing any Exchange -> Exchange traffic at all I analysed the message tracking logs for hits from a sample of Hub Transport servers in other sites. When this data was collated the graph looked like this.

Intra-Org Traffic Per Hub Transport Server

Suspicion confirmed.

SERVER1 and SERVER2 are processing no intra-org email traffic coming in from other sites, and SERVER4 is having to pick up the slack. Although I was curious why the traffic still hadn’t evenly load balanced across the other three Hub Transport servers that was not the primary concern.

The real concern is why is this happening, and how do we fix it?

What is Causing the Intra-Org Email Traffic Imbalance?

The root cause comes back to the SMTP relay configuration that is in place. SERVER1 and SERVER2 each have an additional Receive Connector configured for SMTP relay.

At the time these were implemented the servers had no additional network interfaces available in them, so the new Receive Connectors are bound to the same interface as the Default Receive Connector.

While this is something you can get away with, it is generally recommended that you dedicate an interface to a relay connector like this for reasons that I’m about to demonstrate.

When two Receive Connectors share the same interface and IP address they use the list of remote IP addresses configured on the connectors to determine which one should handle a particular connection.

Receive Connector remote IP addresses

Generally speaking the most specific match will determine which connector accepts a connection.

The Default Receive Connector specifies a remote IP range that could be described as “everything”.

Remote IP address on Default Receive Connector

When sharing an IP address between the default connector and receive connector it is easy for the server to determine that a connection from a specific IP address that is explicitly listed in the remote IP list of the relay connector should be handled by the relay connector.

The trouble begins when administrators take a short cut and add entire subnets to the remote IP address list on the relay connector. If that subnet also contains other Exchange servers, connections from those Exchange servers will be processed by the relay connector, not by the default connector, because the subnet is considered more specific than the “everything” range that is on the default connector.

A receive connector configured for SMTP relay usage by non-Exchange systems does not have a configuration that Exchange likes when it comes to Exchange -> Exchange communications. So, the connection fails and the Exchange server will attempt to use a different Transport server.

In our case the connections to SERVER1 or SERVER2 were continually failing and SERVER4 was handling the extra load.

How to Fix the Transport Load Imbalance

With the root cause clearly identified the possible solutions were clear. We could either:

1. Configure dedicated IP addresses for the relay connectors so that there is no confusion as to which receive connector the server should use to handle Exchange traffic vs application relay traffic.
2. Remove all of the subnet entries from the remote IP address lists and replace them with only the specific IP addresses that should be permitted to relay.

Because the situation with available network interfaces had not changed we went with option 2, with a note to use dedicated interfaces for relay connectors in future designs.

The outcome is a more balanced load among the Hub Transport servers in the site, now completely in line with expectations and providing better performance and resiliency.

Balanced distribution of traffic across Hub Transport servers

Related posts:

• Report Top Sender IP’s on Exchange Server 2010 using Log Parser
• Generate SMTP Error Statistics using Log Parser and Exchange Server 2010 Protocol Logs
• Calculate Hourly Email Traffic using Message Tracking Logs and Log Parser
• Calculate Daily Email Traffic using Message Tracking Logs and Log Parser
• Reporting Exchange Server 2010 Message Tracking Event IDs with Log Parser

This article The Case of the Hub Transport Server Load Imbalance is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

There are two different log sets that you can use for this:

• Protocol logs
• Message Tracking logs

One of the best ways to describe the difference between these is that protocol logs will capture SMTP connections that may or may not make it all the way in to the Transport pipeline. For example a connection from a spammer that gets blocked by IP filtering will appear in the protocol logs but not the message tracking logs.

The detail captured in a protocol log will look a lot like what you would see if you were manually testing SMTP via telnet on a server.

Message tracking logs will capture messages that get processed through the Transport pipeline, and capture information such as message submission and delivery rather than the SMTP conversation that protocol logging reflects.

Message tracking is also turned on by default and is set per-server, whereas protocol logging is not turned on by default and is set per-connector.

For this demonstration I’ll be using my Edge Transport server simply because it has slightly more interesting data since it receives a lot of connections from the internet.

Get Top Sender IP’s from Protocol Logs with Log Parser

To get the top sender IP’s from the protocol logs we can use this Log Parser query.

SELECT EXTRACT_PREFIX(remote-endpoint,0,':') as IP,
	REVERSEDNS(EXTRACT_PREFIX(remote-endpoint,0,':')) as Name,
	Count(*) as Hits
FROM *.log
WHERE data LIKE '%EHLO%'
GROUP BY IP
ORDER BY Hits DESC

When run from the folder containing the protocol logs (in this case C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive) it looks like this:

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe" "SELECT EXTRACT_PREFIX(remote-endpoint,0,':') as IP,REVERSEDNS(EXTRACT_PREFIX(remote-endpoint,0,':')) as Name,Count(*) as Hits from *.log WHERE data LIKE '%EHLO%' GROUP BY IP ORDER BY Hits DESC" -i:CSV -nSkipLines:4 -rtp:-1

This will give you output similar to this:

IP              Name                                    Hits
--------------- --------------------------------------- ----
83.222.31.220   v8622.vps.masterhost.ru                 52
204.13.248.72   mho-02-ewr.mailhop.org                  12
50.78.250.97    dcmail.designercabinetry.com            9
10.1.1.21       ho-ex2010-mb1.exchangeserverpro.net     8
64.61.92.26     static-64-61-92-26.isp.broadviewnet.net 7
217.108.179.228 mailhost.el-internationale.com          7
69.60.118.117   mail1.ambr.com.br                       4
10.1.1.22       ho-ex2010-mb2.exchangeserverpro.net     4
95.154.196.147  95.154.196.147                          4
118.22.2.202    pc2.land-ho-unet.ocn.ne.jp              3
187.108.193.223 cloud.newmediahost.com.br               2
109.169.77.169  109.169.77.169                          2
59.106.64.208   ns1.uranaikan.info                      2
204.13.248.71   mho-01-ewr.mailhop.org                  2
78.129.222.16   78.129.222.16                           2
199.119.76.15   mail.seoauditions.com                   1

Statistics:
-----------
Elements processed: 3359
Elements output:    16
Execution time:     17.41 seconds

This part of the query string is important to note:

WHERE data LIKE '%EHLO%'

This means that only those log entries where the EHLO occurred will be counted in the stats that Log Parser outputs. If you leave it out you’ll see a “Hit” for every log entry a remote IP generated. Depending on how “chatty” that particular SMTP conversation was it may skew the results a little. However since we’re looking more for indicative numbers rather than precise numbers it doesn’t matter which way you choose to go (at least not to me).

Get Top Sender IP’s from Message Tracking Logs with Log Parser

For message tracking logs the syntax is a little different because the field names in the log files are different.

SELECT client-ip as IP,
	REVERSEDNS(client-ip) as Name,
	Count(*) as Hits
FROM *.log
WHERE (event-id='RECEIVE')
GROUP BY IP
ORDER BY Hits DESC

When run from the folder containing the message tracking logs (in this case C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking) it will look like this:

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe" "SELECT client-ip as IP,REVERSEDNS(client-ip) as Name,Count(*) as Hits from *.log WHERE (event-id='RECEIVE') GROUP BY IP ORDER BY Hits DESC" -i:CSV -nSkipLines:4 -rtp:-1

If you get too much output you can limit it to the top X results by modifying the query slightly:

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe" "SELECT TOP 20 client-ip as IP,REVERSEDNS(client-ip) as Name,Count(*) as Hits from *.log WHERE (event-id='RECEIVE') GROUP BY IP ORDER BY Hits DESC" -i:CSV -nSkipLines:4 -rtp:-1

This will give you output similar to this:

IP              Name                                 Hits
--------------- ------------------------------------ ----
204.93.210.179  mariajunco.com                       32
10.1.1.22       ho-ex2010-mb2.exchangeserverpro.net  23
216.151.172.180 hosted.airvm.net                     22
10.1.1.21       ho-ex2010-mb1.exchangeserverpro.net  22
83.142.48.139   83.142.48.139                        17
67.215.235.199  67.215.235.199.static.quadranet.com  13
109.169.76.124  109.169.76.124                       10
109.169.55.146  109.169.55.146                       10
109.169.62.15   109.169.62.15                        10
109.169.60.137  109.169.60.137                       9
173.254.208.113 173.254.208.113.static.quadranet.com 9
59.106.64.208   ns1.uranaikan.info                   8
72.11.150.131   72.11.150.131.static.quadranet.com   7
109.169.73.116  109.169.73.116                       7
109.169.55.135  109.169.55.135                       7
189.39.9.214    mail3.ibcbrasil.com.br               5
204.13.248.72   mho-02-ewr.mailhop.org               5
109.169.87.100  109.169.87.100                       4
109.169.84.105  109.169.84.105                       4
169.232.46.177  out-58.smtp.ucla.edu                 3

Statistics:
-----------
Elements processed: 1018
Elements output:    20
Execution time:     74.03 seconds (00:01:14.03)

You can use this information in a lot of situations such as when investigating load issues, or planning to decommission servers

Related posts:

• The Case of the Hub Transport Server Load Imbalance
• Generate SMTP Error Statistics using Log Parser and Exchange Server 2010 Protocol Logs
• Calculate Hourly Email Traffic using Message Tracking Logs and Log Parser
• Calculate Daily Email Traffic using Message Tracking Logs and Log Parser
• Reporting Exchange Server 2010 Message Tracking Event IDs with Log Parser

This article Report Top Sender IP’s on Exchange Server 2010 using Log Parser is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

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:

1. Add the domain name to the Accepted Domains for the organization
2. 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.

1. 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.
2. 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.

Related posts:

• Exchange 2007/2010 Transport Rule Logging
• Report Top Sender IP’s on Exchange Server 2010 using Log Parser
• How to Migrate a Relay Connector from Exchange Server 2007 to 2010
• Review of CodeTwo Exchange Rules Pro
• Exchange Server 2007/2010: How to Change the Primary Email Domain

This article Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010 is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

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.

Related posts:

• Using Test-ServiceHealth for Exchange Server Health Checks
• How to List all Users Who Have Access to Other Exchange Mailboxes
• Exchange 2007/2010: How to Clone a Mailbox Database Configuration
• Exchange 2007/2010 Public Folder Store in an Inconsistent State
• PowerShell: Configuring Settings on Multiple Exchange Mailbox Databases

This article How to Migrate a Relay Connector from Exchange Server 2007 to 2010 is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

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 »

Related posts:

• Exchange 2007/2010 Transport Rule Logging
• Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010
• How to Migrate a Relay Connector from Exchange Server 2007 to 2010
• How to Share an Email Domain Between Two Mail Systems
• Block Users Sending to Specific Domains with Exchange Server 2010

This article Review of CodeTwo Exchange Rules Pro is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

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.

Related posts:

• Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010
• Review of CodeTwo Exchange Rules Pro
• Report Top Sender IP’s on Exchange Server 2010 using Log Parser
• How to Migrate a Relay Connector from Exchange Server 2007 to 2010
• Poll: Do You Run an Edge Transport Server?

This article Exchange 2007/2010 Transport Rule Logging is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

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.

Related posts:

• Installing an Exchange 2007 Mailbox Server on Windows Server 2008
• Installing Exchange Server 2007
• Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010
• How to Migrate a Relay Connector from Exchange Server 2007 to 2010
• Review of CodeTwo Exchange Rules Pro

This article Installing an Exchange 2007 Hub Transport Server on Windows Server 2008 is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

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.

Related posts:

• How to Migrate a Relay Connector from Exchange Server 2007 to 2010
• How to Configure a Relay Connector for Exchange Server 2010
• The Case of the Hub Transport Server Load Imbalance
• Generate SMTP Error Statistics using Log Parser and Exchange Server 2010 Protocol Logs
• Report Top Sender IP’s on Exchange Server 2010 using Log Parser

This article Resolving Anonymous Mail to the GAL with Exchange Server 2010 is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

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.

Related posts:

• How to Configure Windows Live Mail for Exchange 2010 POP3
• How to Enable or Disable POP3 Access for Exchange 2010 Mailboxes
• How to Configure a Relay Connector for Exchange Server 2010
• How to Add Remote IP Addresses to Existing Receive Connectors
• The Case of the Hub Transport Server Load Imbalance

This article How to Publish POP3 Client Settings to Users with Exchange 2010 SP1 is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

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.

1. Install a new server to host the Hub Transport server role
2. Configure the server with the same name and IP address as the failed server, and join it to the domain
3. Install the Exchange Server 2010 pre-requisites
4. 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.

Related posts:

• Exchange Server 2010 Mailbox Server Backup and Recovery
• Exchange Server 2010 Client Access Server Backup and Recovery
• Exchange 2010 Edge Transport Server Backup and Recovery
• Introduction to Exchange Server 2010 Backup and Recovery
• Exchange 2010 Mailbox Database Backup and Restore with Windows Server Backup

This article Exchange 2010 Hub Transport Server Backup and Recovery is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com