One of the common issues that appears when integrating a hybrid vision of Hosted Exchange with someones existing infrastructure (so not really Hosted Exchange at all!) is synchronising credentials between the Exchange Server and the local machines or for the more tech savvy the ‘hackiness’ of having disparate forests.

Cross Forest trusts are a possibility and merging one with the other (i.e having the Hosted Exchange solution bound to the existing domain) is another but there are many issues with that (mostly political).

What I intend to do is utilise the ‘Branch office’ concept that Read Only Domain Controllers were designed for to mock up a solution for Hosting the entire AD infrastructure remotely and having R/O DC’s on the customer premises.

What now?

For no other reason than that of satisifying my curiosity I built an entire AD infrastructure hosted at the data center and then had a remote ‘office’ running for a day without a local DC and then the following day with a Read Only Domain Controller sitting there.

There’s nothing new or crazy here other than maybe the fact that most people move bits of their AD infrastructure to the DC when its bandwidth requirements overwhelm their resources. What I’m playing with is the idea of having everything remote and only putting the stuff you need (NAS etc) in the office.

The Test

In the Red Corner we have a full Active Directory and Exchange infrastructure at the DC and then the ‘offices’ were built using a few Terminal Services servers running a respective amounts of users. The idea is to monitor traffic before dropping in a RO DC and then again afterwards.

The Infrastructure

Hosted Infrastructure

The Hosted infrastructure consists of a relatively standard Exchange 2007 deployment (if you follow the guidelines) visible to the world (selected ports only) is an Edge Transport server for handling the initial mail connections and the Client Access Server. Behind those is the Mailbox and Hub Transport (in reality these were on the same box but the diagram wasn’t as symmetrical then!).


The Domain controller is a special case because whilst we have no reason for the Internet at large to talk to it we need the read only Domain Controller at the client site to be able to communicate with it so an IPSEC LAN to LAN VPN was required.

The Results

AD Traffic From the TS to the Remote DC No Local DC

AD Traffic to the Remote DC with Local RODC

OWA Traffic During the Tests

Scripted behavior – so it was the same(ish) on both days

Conclusion

Well it did exactly what I expected it to do so nothing ground breaking there. It was interesting to see the spike just after I logged all the fake users off the Terminal Servers.

R/O DC’s were used because in an ideal world customers shouldn’t have write access to an AD infrastructure that a SysAdmin has an SLA to honor!