Managing Relay connectors in Exchange Server 2007/2010 (Part 1)

If you would like to read the next part in this article series please go to Managing Relay connectors in Exchange Server 2007/2010 (Part 2).

I’m aware that this topic was brought up several times along the years, however, it is still a hot topic in many forums. The idea of this article is not to create the string theory for Relay connector but give you some perspective and perhaps save you some deployment time. Each environment is unique and you may have to change here and there to make it work.

Nowadays as companies grow, everybody wants to do relay in Exchange which is okay, and I’m talking about ERP System, SharePoint, SCOM, DPM, UPS, Fax, printers you name it! Sometimes you as administrator don’t want to be bothered and spend your time to allow a simple relay for a fax machine, right? Also, you may not want a first level IT guy playing around with your Receive Connectors, another possibility is that you may have a complex environment with Load Balancers. So, if you change a receive connector on a server you must be sure that the same change applies on all other servers of the Load Balancing pool to avoid weird issues.

What is my approach? Stop spending time managing Receive Connectors. Let’s create a standard for them and let the operations team do the work on them. My suggestion is to create two connectors – RelayAnonymous and Relay. The first one will allow applications/users/devices to relay only to internal recipients, which means that they are not going to send messages to external recipients when using this connector; The second connector will be restrictive and devices/applications that can use this one will be able to send messages to external recipients outside of your organization. The trick here is to make sure that both are using the same IP to make sure that there is no difference from the user perspective using our relay solution.

In order to accomplish the goal of this article we need a server with at least 2 network interfaces, an additional one that will have the IP used by both Receive Connectors.

By doing that, what are the advantages for you and your organization? From the top of my head I can list a couple, as follows:

• Consistency, a single name will be used as Relay and all devices/applications will use that for SMTP traffic
• Easy changes in future upgrades. In a case of a server change or an Exchange upgrade you just need to move your DNS record to the new server and you have all applications/devices already configured.
• The RelayAnonymous won’t require manual administration and it won’t create tickets to your help desk system, just tell the user to use Relay on your configuration and you should be good.
• Control for external recipients. We do not want any users sending tons of messages to external recipients or even worse an infected machine blacklisting your entire domain for sending virus to the internet. For this type of scenario, the Relay connector will be useful.

Before we start doing the techy stuff, let’s do a review of what a Receive Connector is. A Receive Connector is unique and at least one of these three variables (Figure 01) must be different: IP Listener, Remote IPs and Port. In this article, we are going to make sure that our new Receive Connectors are different by changing just the Remote IPs. We will keep the same IP Listener and Port for the two new Receive Connectors.

Figure 01

Configuring the pre-requisites to support our Relay strategy…

Since the Relay is going to be used only internally, let’s open our DNS Manager on a Domain Controller and on the zone being used by Active Directory we are going to create a new entry named POARelay pointing out to the IP address that will be used only for that matter (the IP address on the second adapter), as shown in Figure 02.

Figure 02

The second step of our journey is to have a second adapter configured on the Hub Transport Server, as shown in Figure 03. For the sake of simplicity we are going to label that adapter as SMTP.

Figure 03

The network binding on the Operating System must use LAN as primary adapter and our SMTP adapter as secondary. We can manage the binding order by hitting the left Alt button and then Advanced, and finally Advanced Settings. The order should be like the one shown in Figure 04.

Figure 04

This new adapter must be configured with a static IP address, and the regular File and Printer Sharing for Microsoft Networks, Client for Microsoft Networks and QoS Packet Scheduler should be removed from the adapter properties. One last thing, make sure that Register this connection’s addresses in DNS is unchecked for our new SMTP adapter, as shown in Figure 05.

Figure 05

Awesome! We do have a static IP for our new adapter, we can ping POARelay, and we have name resolution in place!

Our scenario…

You may have guessed already some of the information that we gave away during the previous section but to make sure that we are all on the same page, we have the following list with the key settings of our scenario for this article series:

• 2 (two) Hub Transport Servers: MVAEX01 and MVAEX02
• The Active Directory FQDN is mva.local
• The static IP assigned to the SMTP adapter on MVAEX01 is 10.60.99.165
• Our environment is brand new with no special configuration. We deployed using standard settings during the installation process.
• We do not have a Load Balancer but we will tackle this topic in a bit.
• Why MVA domain anyways? Well, I’m working on an Exchange MVA in Portuguese and that was the LAB 🙂

The server that we will be working on for now is MVAEX01, and it has the two default Receive Connectors and just to keep our environment cleaner, let’s go ahead and delete the Client <ServerName> connector because we are not going to be using it, as shown in Figure 06.

Figure 06

Creating the RelayAnonymous connector…

The first step towards our proposed solution is to create the RelayAnonymous connector. Since my environment will have several sites in a near future, I decided to plan ahead and label the new receive connector with a prefix to identify its location. So, the name used here will be POA-RelayAnonymous (where POA is the Porto Alegre city where my servers are located).

These are the steps to create and configure the POA-RelayAnonymous connector, as follows:

1. Open Exchange Management Console
2. Expand Server Configuration
3. Click on Hub Transport
4. Select the desired Hub Transport
5. Click on New Receive Connector item located on the Toolbox Actions
6. On the Introduction page, name our connector and select Custom, then click Next. (Figure 07)

Figure 07

7. On the Local Network Settings page is where the magic happens. We are going to listen on a single IP address (the one that we associated to the second adapter – our case is 10.60.99.165) and finally to save us time during any future troubleshooting let’s use the string POA-RelayAnonymous.mva.local in the FQDN of the connector. Click Next (Figure 08).

Figure 08

8. On the Remote Network Settings page, leave the default settings and click Next (Figure 09).

Figure 09

9. On the New Connector page, a summary of all options chosen so far will be displayed, just click New to start the creation process.
10. On the Completion page, cmdlet and result of the operation will be displayed, and if everything was okay and the Completed status displayed via a green icon, then click Finish.

Now, that we have a new Receive Connector, double click it and in the Permissions groups tab, select Anonymous users, as shown in Figure 10.

Figure 10

Finally, click on Authentication taband uncheck all options, as shown in Figure 11.

Figure 11

We now have the first Receive Connector created. We can test it by using telnet POARelay 25 (you can be more specific and type in telnet POARelay.mva.local 25) but since the A record was created in the AD FQDN both should be fine.

In the first line of the connection, we will see the FQDN that we specified in the connector that in our case is POA-RelayAnonymous.mva.local, which helps us to identify which Receive Connector the client is connecting to. This will be useful when we have our second Receive Connector in place.

Since we are connected to our new Receive Connector, we are going to run a couple of tests. In order to make it easier for the reader who is not aware of the SMTP verbs in a regular message communication among servers we used the table below to show where we are in each command.

 Table 1

The entire communication is also shown in Figure 12, where the text marked in yellow was what I typed in during the message transfer. A good result was that the user wasn’t able to send a message to an external recipient. This process can be seen when I try to send a message to [email protected] (that domain is not part of our organization) and the Exchange Server replies to me 550 5.7.1 Unable to relay which is perfect!

Figure 12

Conclusion

In this first article we created our first Receive Connector, tested it and now we are ready to create the second and final Receive Connector. Then we start doing more tests and discuss a little bit about more complex scenarios: Load Balancer, SMTP Authentication and troubleshooting the new relay environment.

If you would like to read the next part in this article series please go to Managing Relay connectors in Exchange Server 2007/2010 (Part 2).