Lately I've been hearing more about a situation that once would have been impossible: knitting together two different Microsoft Exchange Server organizations into a seamless whole. This situation could be required because of a company merger or acquisition, or because a separate forest was originally created for security or management reasons. Combining Exchange Server organizations can be a fascinating problem because there are lots of nuances to it, ranging from cross-forest user authentication to moving mailboxes from one forest to another to all the issues surrounding running Exchange in a hybrid mix of on-premises and hosted services. I've been doing a bit of research on some of the lesser-known corners of cross-forest operations and consolidation, so this column is a report on some of what I've learned.
One of the advances in Exchange Server 2010, of course, is its ability to provide cross-forest calendar data, including availability information. This feature, known as federated delegation, lets you set up and control sharing of calendar data between Exchange organizations. It's straightforward to set up and almost completely transparent to end users—plug in the email address of an external federated user when scheduling a meeting in Outlook or OWA, and poof! You see the user's calendar information.
However, this ability requires that you establish a trust relationship with the Microsoft Federation Gateway (MFG), a hosted service that acts as a federation clearinghouse. The MFG provides a central trusted point of contact for different organizations to connect to. What if you don't want to use the MFG? Say you want to establish a federated delegation relationship with an Exchange organization belonging to a company your employer just bought. The short answer: Too bad. You have to use the MFG. (The longer answer: You can possibly use Exchange's calendar sharing and publishing features to provide a degree of calendar sharing, but this method might not meet your business requirements.)
Another major Exchange 2010 feature is its set of compliance and retention capabilities, including multi-mailbox search and litigation hold. It's important to realize that these capabilities do not work across Exchange forests, with one exception: They can be used in hybrid environments if you're using Office 365 in combination with on-premises Exchange 2010. I haven't seen an official statement of supportability for these features when used with hosted Exchange 2010 offerings from other providers, though. If you need to perform discovery searches or use litigation hold (or other retention-related features), keep in mind that you'll need all the mailboxes to be in the same forest, or you'll need to recreate the discovery and retention settings and behaviors in each forest manually (and don’t forget about transport rules!).
Finally, what if you want to replicate free/busy information that you've currently got stored in public folders? If you're running Exchange 2007 or Exchange 2003 with legacy versions of Outlook, this situation certainly describes you. Microsoft has a venerable tool known as IORepl (more properly known as the Microsoft Exchange Server Inter-Organization Replication tool) that was commonly used to perform this operation between Exchange 2003 organizations. However, until the release of Exchange 2010 SP1, IORepl wasn't supported for use with Exchange 2010. Although it's now supported, many Exchange 2003 customers aren't aware of it, which is why I'm mentioning it. IORepl is useful in a certain set of narrowly defined circumstances, but if you need it, there's nothing else that can really take its place. You can download this tool from the Microsoft Download Center.
Speaking of taking something's place: Did anyone else notice that the recent Gmail outage that affected upwards of half a million mailboxes was resolved in part by restoring mailbox data from a tape backup? Could you do that if your organization needed it? Did you also notice the subsequent Google Calendar outage? Food for thought.
