Cry Exchange How To...

---

Setup Exchange as a Backup Email Server for another site

---

Exchange can be configured to act as a Backup Email Server for another site. The role of a backup email server is to receive email when your primary exchange server is down - you can see a more lengthy description of a backup mail server here.

These notes cover how to configure Exchange to act as a backup email server for another site. By "another site" I mean one which is in a totally unrelated domain. If the two sites share the same active directory domain then setting up an Exchange server as an Edge Transport or giving more than one server the Hub Transport role would probably be a better solution.

Before setting up a backup email server it is worth considering whether you need one. Should your server be down then any sender should automatically retry the send later. It is only after repeated unsuccessful delivery attempts (typically no longer than 2 days) that a non delivery message is returned to the sender. So a backup email server should be unnecessary if you only anticipate short periods of unavailability. If you are likely to have a server outage lasting a day or more then a backup email server is advisable to avoid the risk of emails bouncing back to the sender.

There are three steps involved in using Exchange 2007 as a backup email server, with one of these being optional:

1. Configure the backup email server to accept emails for the domain
2. Configure retry timeouts and create a new send connector for this domain (optional)
3. Update the MX records so other email servers know about the backup

These steps are covered in detail below.

Configure the backup email server to accept emails for the domain

These steps configure the backup email Exchange server to queue up emails destined for the primary email server, until requested by the primary.

On the backup email server:

1. Open Exchange Management Console.
2. Navigate to Microsoft Exchange > Server Configuration > Hub Transport
3. Open the "Accepted Domain" tab.
4. Click on "New Accepted Domain ..." this will open up the "New Accepted Domain" dialog.
5. The name for the "New Accepted Domain" doesn't strictly matter, but I would suggest naming it to describe its purpose so something like "Backup Email for DOMAIN" (where "DOMAIN" is the name of the email domain that you are setting up the backup for). So for me, I entered the name "Backup email for cryer.co.uk".
6. For the "Accepted domain" you should enter the domain name that you are setting up the backup for. So for me, I entered the accepted domain "cryer.co.uk".
7. You have three options on this dialog for how email shoudl be handled: "Authorative domain", "Internal Relay Domain" or "External Relay Domain". Since we are setting up a backup server for a domain which is external to our organisation the option required is "External Relay Domain".
8. Click [New], and the new accepted domain will be created. You will then need to click [Finish] to close the dialog.

At this point the server will accept emails to the external domain, and any emails received will be immediatly relayed to the external domain.

Configure message expiration and create a new send connector for this domain (optional)

When sending emails should the destination server be unavailable then Exchange will retry sending later, until eventually failing and generating a non-delivery (NDR) report. The default setting for Exchange is that it will retry for 2 days before generating a non-delivery report.

The implications of this are simply that if you want the backup email server to hold emails for longer than 2 days then you need to adjust the "Message expiration" setting in Exchange.

In most instances the 2 day (48 hour) retry limit is reasonable. In my case I was setting up a backup email server because power to the building was to be cut over the weekend to allow work to be carried out. I was going to shut the servers down at the end of the working day on the Friday and power them back up at the beginning of the working day on the Monday, which meant I had 63 hours of down time. This is easily long enough for some emails to be bounced with a non delivery report. Since I wanted to avoid this I needed to increase the expiration window.

Unfortunatly this setting is global to the server. It would be nice to be able to change the expiration setting just for emails for which the server was acting as a backup. But Exchange 2007 doesn't support this. So be aware that any changes will affect all email delivery on the server.

To increase the "Message expiration" from the default of 2 days to 3 days:

1. Open Exchange Management Console.
2. Navigate to Microsoft Exchange > Server Configuration > Hub  Transport
3. The server should be listed in the top pane, double click it to open its properties.
4. On the "Limits" tab, under "Message expiration" change the "Maximum time since submission (days) to 3 (or what ever number of days you require, the default is 2).
5. Whilst it isn't necessary, since I was working around a planned outage I also changed the "Notify sender when message is delayed more than (hours)" setting from the default of 4 to 64 - so long enough to cover my planned outage. This is something which I changed back after my planned outage was over. Normally I'd recommend leaving it at the default, but I didn't want to unnecessarily alarm anyone.
6. Click [OK]. This will save the settings.

If you are using a smart host for your email delivery then you should create a new send connector. Otherwise the message expiration timeout you have just set will be ignored - because it only applies to the delivery of your email to your smart host and not delivery to the destination server. If you are not using a smart host then you do not need to create a new send connector.

To create a new send connector:

1. Open Exchange Management Console.
2. Navigate to Microsoft Exchange > Server Configuration > Hub Transport
3. Open the "Send Connectors" tab.
4. Click [New Send Connector...], this will open a "New SMTP Send Connector" dialog.
5. The name of the new send connector doesn't really matter, but I suggest using a obvious descriptive name. I used "Send connector for cryer.co.uk"
6. For the intended use select either "Custom" or "Internet". I used "Internet".
7. Click [Next >] which takes you to the "Address space" dialog.
8. Click [+Add] and then enter the domain name for the domain that this server is acting as the backup for and for which this send connector will send emails. I used "cryer.co.uk", and since I don't have any mail enabled subdomains I left "Include all subdomains" unchecked.. Leave the "Cost" at 1. Click [OK].
9. Leave "Scoped send connector" unchecked (although I don't think it should matter).
10. Click [Next >] which will take you to the "Network settrings" dialog.
11. Select "Use domain name system (DNS) MX record to route mail automatically." Leave "Use the External DNS lookup settings on the transport server" unchecked (although I don't think it should matter).
12. Click [Next>] which will take you to the "Source Server" dialog.
13. The local exchange server should already be listed, so no action is required on this dialog.
14. Click [Next>] which will take you to the "New Connector" dialog.
15. The "New Connector" dialog simply shows you a summary of everything you have entered. CLick [New] to finish and create the new send connector.

We want to be sure that the new send connector is being used instead of the default/original send connector. Since the new send connector was created with a "Cost" of 1, edit the existing send connector and ensure that the Cost associated with it is greated than 1:

1. Double click on the original send connector (if you previously had more than one send connector then you will need to review each of them). This should open its properties.
2. On the "Address Space" tab where there is an entry with type "smtp" and address "*" ensure that the cost associated with this is at least 2.

This ensures that your new send connector is used for emails sent to the domain and your original send connector is used for everything else.

If for all other email you are using a smart-host then it is likely that the reason for this is that your IP address is one a block list. Some block lists include ranges of IP addresses and in some cases it can be easier to use a smart host than to try to get removed. So test that you can successfully deliver an email via this new smart connector (use telnet to send the email as that way you can be sure it is being sent via the backup). If the email is not delivered and you get back a non delivery report saying that the server rejected it then you will need to white-list the IP address of your backup server in the destination exchange server. In Exchange 2007 and 2010 this is under Exchange Management Console > Server Configuration > Hub Transport > Anti-Spam > IP Allow List > Allowed Addresses.

Update the MX records so other email servers know about the backup

Email servers known where to send emails by looking up MX records for your email domain. Before you update the MX records for your domain it would be wise to test that the backup email server is working. A simple test is to send an email directly to the backup email server and then check that it is queued up and ultimately delivered to your primary email server. A simple way of ending an email via the backup server is to use telnet to send the email.

You will need to do the following or ask your domain name registrar to do it for you:

What you need to do is to add a new MX Record, to point to the DNS name of your backup email server and with a slightly higher priority than that of your primary email server.

You can view that MX records for your server by typing the following at the command line:

nslookup -type=mx cryer.co.uk

simply substitute your domain name for cryer.co.uk in the above example.

Note:

• Be aware that changes to DNS records can take up to a day to propagate through the internet, so it may take up to a day for other servers to pick up the change.
• The new MX record should have a higher numeric priority than the original MX record because sending email servers should use the record with the lowest priority.
• Backup email servers can be very attractive to spammers. For example, sending email to a backup email server bypasses most measures for preventing the server from being used for RNDR spam attacks. For this reason it may be prudent only to have live the MX record for the backup email server when you know it will be required - remember that most emails will remain queued by sending servers for up to two days before a non-delivery report is generated.

---

These notes have been tested with Exchange Server 2007.