The Legacy Exchange 5.5 Federation

The following scenario plays out one of the most common histories we see in the Exchange 5.5 design of federated environments. In fact, we can probably blame the flexibilty of Exchange 5.5 for the majority of federations that exist today because it made possible the creation of large email directories without a need for trusts or centralized ownership. I've worked with multiple customers over the years who went through something like the following experience.

As the typical organization progressed in the various local area networks in the early and mid nineties, a majority of the departments selected Microsoft software for their standardization. By 1996 most agencies had NT 4.0 networks in a master domain model, where the user accounts resided in one domain and several resource domains were created (with two-way trusts) for various line of business applications. 

Nearly every in the federation had implemented Exchange 5.5 as their email system, operating in the master NT 4.0 domain. Sometime around 1994, the central information services agency (who historically controlled the mainframe) came up with the concept of a shared Global Address list across all agencies, hence planting the seeds for an enterprise model. 

To accomplish this, however, the information services department required a solution that provided every other agency complete autonomy, control, and security, since no trusts between master domains would occur as part of this effort.

As a result, an SMTP-based replication hub was established by central IT. Each agency would build its own site in Exchange 5.5 (in its own NT 4.0 domain) and establish an SMTP-based directory replication connector to the Hub Site. In all, tens or even hundreds of agencies participated in this hub and spoke model. Each agency's 5.5 Organization had the same name, but was essentially independent of every other site (differing service accounts used, different permission models, etc.). Email was not routed inbound or outbound from a central authority. No trusts, Exchange site links, or other common infrastrutures were shared. Each agency maintained its own DNS namespace and all user-to-user messages were sent via DNS and MX records. 

Public folders were basically administered locally at the agency sites, but some agencies did occasionally share replication scopes for certain folders. 

For years, the environment provided the one thing that everyone wanted, a common GAL. However, it was fraught with problems. Simple mistakes made in one agency replicated throughout the organization and affected everyone. Containment of viruses was nearly impossible, as it required the coordination of upwards of 100+ email administrators and several hundred supporting staff. 

As a result of problems (particularly related to viruses), several agencies began deploying firewalls between themselves and other agencies. This was ironic because in order for the mail hub to function as designed, the ports being used to deliver viruses (port 25 at the time) had to stay open for replication and mail flow to work. The further irony is that all agencies were often behind a global firewall that protected everyone from the general Internet. So, in spite of their efforts to come together as an enterprise, steps were being taken by everyone to prevent the enterprise model from being full functional.

By 2000, almost every agency had a firewall between itself and other agencies. To ensure "security" firewall rule lists were expansive, often requiring IT staff at agencies to justify every address/port combination and making general connectivity for collaboration across agencies nearly impossible.

The problems of this design became quckly apparent around the turn of the century. Under Exchange 2000, the directory no longer resided in Exchange, but rather was part of Active Directory. The Active Directory forest boundary became the Exchange organizational boundary, leaving the state with two choices, go their separate ways on Exchange (meta directories were not as often spoke of then) or bring together their domain environment under a single, common enterprise forest.

Thus, the desire for maintaining a common global address list becomes the driving force in an Active Directory design for a single forest. What's most interesting about this, however, is that a common GAL was one of the few benefits actually touted by Microsoft as a benefit. We were more focused on discussing the benefits of a single enterprise (improved collaboration, larger directory structures, single sign-on). This brief reflection on many customers' histories, however, shows that maybe we missed a larger opportunity that existed in many of our federated customer accounts.

Comments

• Anonymous
  February 22, 2005
  You just explained our actual topology on the European theater.
  
  PS. We are still having some in-brief meetings for One-Net migration ;-)
  
  /R
  
  Benji
• Anonymous
  March 09, 2005
  The ramifications that the one Org, one Forest model that AD/Exch has unleashed was a horrible mistake and all to prove that having an AD aware application was such a huge benefit. Ugh!
  
  The flexibility of the 5.5 model was a huge enabler of that platform and facilitated its spread. Coupling domains and messaging into a single entity sure seems compelling and would seem to decrease complexity, but is the case where the end state diagram looks nice but the trip getting there is a nightmare.
  
  Enjoyed your commentary and found it to be ringing true a few too many times.