Using AD and Exchange as a routing and re-branding solution

  • Article

Recently one of my customers came to me with a requirement that looked pretty daunting. Basically they had 14 separate e-mail infrastructures, not all of them Microsoft Exchange, and what they wanted to do was to re-brand incoming and outgoing e-mail to use 4 new SMTP address formats – essentially setting up 4 new organisations who could receive mail with the new address format and also re-branding outgoing mail with the new addresses. The catch was that:

  • The existing mail infrastructures couldn’t be touched
  • The existing SMTP formats had to be preserved and remain functional

The e-mails for all of the organisations all came through a central network hub. The customer also had an existing LDAP directory which held the e-mail address details for their disparate user base. So we needed to come up with a solution that could facilitate this, all within tight timescales. The solution we implemented used Microsoft Active Directory and Exchange 2003, coupled with some smarts around vbscripts and ADSI. I’m pleased to report that everything worked as planned and the solution went live within the customer’s timeframe – so how did we do it?

We implemented a central Active Directory and Exchange 2003 infrastructure, consisting of 2 domain controllers and 4 Exchange 2003 servers and routed all incoming e-mails for the new address format through it. We used vbscripts and ADSI to interface between Active Directory and the LDAP directory to create contact objects within AD to represent the 18000 users in the 14 infrastructures, each with a new, unique SMTP address. Each contact object had the following characteristics as shown in the following screenshots:

  • A target address which matched their existing SMTP address
  • A primary SMTP address which matched their new SMTP address

This mix of addresses was combined with recipient policies in Exchange 2003 which made the Exchange organisation authoritative for the new address and also allowed it to accept mail for the old address. This is known as sharing an SMTP address space within Exchange 2003. The consequence of this was that:

  1. Mail would arrive into the organisation from the customers SMTP gateway addressed to Joe.Bloggs@newaddress.com. Exchange would accept this as it is authoritative for the address space.
  2. AD would be queried for a recipient in the organisation. Whilst it couldn’t find a mailbox it could find the contact object.
  3. The mail would be re-addressed to the contacts target address and sent back to the customers SMTP gateway, which would then delivered the mail to the user.

Two Exchange 2003 were used to route the incoming mail, load balanced using DNS round robin and set up as bridgehead servers in an SMTP connector. This gave us resilience and allowed each of the 18000 users to receive mail to their new address.

The next challenge we faced was how to re-brand the outgoing mail with the new address. Bear in mind that we couldn’t actually modify the addresses of users in the connected infrastructures. To do this we used our remaining 2 Exchange servers, set them up as bridgehead servers in a separate SMTP connector and load balanced incoming mail delivery using DNS round robin. We then instructed the administrators in all the infrastructures to route their outgoing mail though the load balanced IP address for these servers. Then we implemented a little known feature of Exchange 2003 called Address Re-write (also available in Exchange 2007).

With address re-write enabled, when a mail is submitted to Exchange 2003 Active Directory is referenced for a contact object with a target address which matches the sender. If a matching contact is found the contacts Primary SMTP address is used to re-stamp the FROM: field of the mail so that it appears to come from that address. So, with the contacts that we had in place for the incoming mail we now had a re-branding solution for outgoing mail also. This gave us a full end–to-end solution. Mail sent into the existing mail addresses would continue to function since it wasn’t routed through our solution. This enabled us to meet the customer’s requirement that this would continue to be the case.

By scheduling our vbscripts on a regular basis to provision and de-provision the contact objects in AD we could make sure that everything was up to date from an email point of view. The following diagram gives a high level view of the entire solution.

You can learn more about sharing SMTP address spaces with Exchange 2003 at the following knowledgebase articles:

https://support.microsoft.com/kb/321721/

https://support.microsoft.com/kb/260973

You can learn more about Address Re-Write and how it was applied to this solution at the following link:

https://technet.microsoft.com/en-us/library/aa997194.aspx