If you would like to read the first part in this article series please go to Managing Relay connectors in Exchange Server 2007/2010 (Part 1).
Creating the Relay connector
Following the same procedure that we used in the previous article, let’s name this new receive connector as POA-Relay, and bear in mind this name is not related to the DNS which is POARelay.mva.local. Here are the steps that can be used to deploy this new receive connector:
- Open Exchange Management Console
- Expand Server Configuration
- Click on Hub Transport
- Select the desired Hub Transport
- Click on New Receive Connector item located on the Toolbox Actions
- In the Introduction page. Let’s name our connector (POA-Relay), select Custom, and then click Next.
- On the Local Network Settings page, use the same IP address that we used before (10.60.99.165) and in the FQDN of the connect use POARelay.yamana.local to match the same DNS name. (Figure 01)
Figure 01
- On the Remote Network settings page, change the standard that is – all computers to a specific set of computers that can use this connector. I’m going to leave a single server here to start with (at least one IP address must be defined during the creation) and then click Next. (Figure 02)
Figure 02
- On the New Connector page, a summary of all options chosen so far will be displayed, just click New to start the creation process.
- On the Completion page, the cmdlet and the result of the operation will be displayed, and if everything was okay and the Completed status is displayed, click Finish.
Like the previous Receive Connector, let’s load the properties of this new connector and uncheck all options on the Authentication tab and leave only Anonymous users on the Permissions Groups tab.
If you look closely, you will notice that the only difference between this connector and the previous one is that this one is more restrictive; however, the clients that use this connector must be able to send messages to external recipients. In order to allow this we need to assign Active Directory permission (ms-Exch-SMTP-Accept-Any-Recipient) and since we are doing this I would like also to add one to bypass the anti-spam. This way we guarantee that the message will always arrive in the Inbox of the user. The cmdlet is shown below together with the results produced by our environment that are shown in Figure 03.
Get-ReceiveConnector <RelayName> | Add-ADPermission –User “NT Authority\Anonymous Logon” –ExtendedRights ms-Exch-SMTP- Accept-Any-Recipient,ms-exch-bypass-anti-spam
Figure 03
Testing phase…
It is all set now, we have a second adapter just for Relay named SMTP, and we have two new Relay connectors listening on the same IP address. If you still remember the first section of this article where we described a Receive Connector you will remember that so far the only difference is that one is more restrictive than the other. If you connect from a client that is not listed in the Relay connector, you will end-up in the RelayAnonymous which is great, and that is what we are planning to achieve.
The Receive Connectors on the Hub Transport servers that we are working on is shown below in Figure 04.
Figure 04
The initial test is to try to connect from a regular machine and from a machine that is listed in the Relay connector using the name that we created – POARelay. Since I am using Hyper-V, I can test both and capture a screenshot as shown in Figure 05. The window in the background is the Exchange Server itself and when I try to connect I will end up in the RelayAnonymous. However on the machine MVADC01 which is the second server of the same picture we can see that server connected to the other connector POARelay.
Figure 05
The final test is to try to relay to an internal recipient on both, and the expected result should be positive. Now, when we try to send to an external address on both, we should be able to succeed only on the client that is connecting to POARelay.mva.local. On the client connected to POA-RelayAnonymous.mva.local the result will be a 550 5.7.1 Unable to relay as shown in the Figure 06.
Figure 06
Troubleshooting the Relay connectors
Just by using a different FQDN on the connector you will notice that any connection issue you may have may be fixed quite easily. However, in some cases you need to go deeper, to find why it is not working and to troubleshoot these new Relay connectors there are a couple of good strategies: logs at the connector level or message tracking.
If you opted for the first one, we just need to change the connector logging level to Verbose (Figure 07) and try the connection from the client side, after that we just need to check the logs generated by this process (by default they are located in the %Exchange Installation Folder%\TransportRoles\Logs\ProtocolLog\SMTPReceive).
Figure 07
My second suggestion to find out what is going on with your mail traffic being generated by your Relay Connector is using the Tracking Log Explorer, which can be found under Toolbox in the Exchange Management Console.
We can start with a simple search for the information in a time range and when the message is sent through a Receive Connector, the EventID of that specific message will be received. On the ConnectorID column (Figure 08) we will be able to see which connector received the message. If we keep looking, we will find out where the message went after that.
Figure 08
Advanced options for Relay Connectors…
If you have a more complex scenario on your hands, you may be asking a couple of questions such as, how to implement what we have discussed in these articles in your environment.
- Load Balancer, how does it work?
That is a straightforward process. You should configure on all remaining servers that are part of your Load Balancer the same say that we have done in these series (additional adapter, static IP and connectors). However, in the Load Balancer level your pool will be using the new IPs that we configured for Relay. Depending on your configuration you may have to configure the VIP (Virtual IP assigned on the Load Balancer) on the Receive Connector, and the DNS should point to that IP instead of a server IP. - Is there a way to automate the IPs to be added to the Relay connector?
Besides regular PowerShell scripts I would suggest System Center Orchestrator for that, just create a workbook and assign to your help desk users and the workbook would have a simple PowerShell to add the information on all servers required in a consistent way. You can also take advantage and receive e-mail notification as part of your workflow. - How about SMTP authentication?
It’s not a big deal, we deployed the solution in this article series as simple as possible, however you can go ahead and configure authentication on any of the connectors. A good example is to enable Windows Authentication and Exchange Users in the RelayAnonymous connector. You can test that if you don’t authenticate you can’t send messages to the external world, however if you do authenticate then you should be fine.
Conclusion
Again, this article series it is not going to be the silver bullet for all relay connector issues, otherwise Microsoft Team would’ve come up with something on their official documentation. However, it’s a good start to give you some ideas how you can address some Relay issues in your organization.
If you would like to read the first part in this article series please go to Managing Relay connectors in Exchange Server 2007/2010 (Part 1).
