Chapter 3: Exchange Basics

---

3.1 The organization

Some messaging systems come together as a loose federation of servers. In such an arrangement, servers do not necessarily know about the other servers and must connect through central routers, perhaps by reference to a directory. Other systems, such as Exchange, use a far tighter arrangement. Exchange organizes servers into a single hierarchy called the organization and then divides the organization into administrative groups, all of which exist at the same level within the hierarchy. The concept and overall structure of the organization has not changed much since Microsoft introduced it in Exchange 4.0, except that the major organizational subunit is now administrative groups rather than sites.

Because all configuration data is in a single AD container, there can only be one Exchange organization per AD forest. The administrative group is core to Exchange and provides the foundation for management through permissions and policies.

As explained in Chapter 2, the AD holds details of the Exchange organization in the "Microsoft Exchange" container in the configuration NC (Figure 3.1), which the AD replicates to every domain controller in the forest. Therefore, every domain controller contains knowledge of every Exchange server in the forest, including the routing topology that connects all the servers.

Figure 3.1: Contents of the Microsoft Exchange AD container.

You can have up to 1,000 Exchange servers in an organization. The limit is not hard coded as such but results from the fact that the default page size for results returned by the AD for directory queries can hold 1,000 entries. The limit exists for Exchange 2000 and Exchange 2003. You can argue that this limit restricts the usefulness of Exchange, but then you might struggle to define exactly where the restriction is important. The vast majority of deployments cover 200 servers or less, and there is growing focus on reducing the number of servers in use through aggressive consolidation projects that take advantage of increased server and storage capabilities. Thus, while a small minority of projects might consider deploying more than 1,000 servers, the limit does not affect the majority.

3.1.1 Back to the past-Exchange sites

Best practice has long been for system designers to seek LAN-quality connectivity before attempting to combine Exchange servers. Early deployments (1996-1997) often struggled with the bandwidth requirement and resulted in organizations built from many sites, each of which had a small number of servers. Designers often centered sites on cities or countries to follow network connections. Generally, the more management units that exist in an organization, the harder it is for administrators to manage the organization. More messaging connectors are required to link the sites together and message routing is more complex. Each site increases the amount of directory replication traffic and it is easier for replication problems to occur. In addition, it is not easy to move mailboxes between sites, so larger sites allow greater flexibility in balancing mailboxes across servers.

As these lessons became better known and network costs started to decrease, companies consolidated and deployed larger sites. The Move Server Wizard is available from Exchange 5.5 SP3 onward to move servers from one site to another and you can use this tool to restructure an organization into a smaller number of sites. Moving to a smaller number of sites reduces replication and routing complexity and generally eases the strain on the network. However, while administration is generally easier and message routing is more consistent in large sites, the lack of granularity for management operations is a problem. Essentially, once you grant an account the necessary permissions to perform administrative tasks within a site, the account can manage all of the servers, connectors, and mailboxes within the site. This is not a problem with small sites, since a small number of administrators usually manage these sites, all of whom know the environment well, but it is an issue in the largest implementations, where sites might span entire continents. For instance, in a site that includes servers from every country in Europe, an administrator in France might take an action that affects the ability of a server in Norway to route messages. The French administrator might not even realize that a problem has occurred unless he or she monitors the operation of the Norwegian server. A greater degree of granularity would restrict the French administrator to operations affecting the local server.

Even though the site concept delivers a low degree of administrative granularity, it has proven effective in practice. There is no doubt that the site model served the first generation of Exchange well. It is easy to forget that Microsoft designed Exchange 4.0 when most NT servers had decidedly modest hardware configurations, and an initial goal of the Exchange 4.0 release was to move users off Microsoft Mail post offices, most of which served very small user communities. With small systems, it makes eminent sense to keep administration as easy and straightforward as possible, and the site model does this very well. Nevertheless, as corporate deployments of Exchange increased in size and scope, it became obvious that the site model had run out of steam, and Microsoft needed to make fundamental architectural changes to create a management model suitable for both large and small enterprises. Its solution moves away from the fixed nature of the site model to a more flexible model of administrative groups and routing groups. Some more flexibility is still needed, because neither Exchange 2000 nor 2003 has yet delivered the full promise originally anticipated, but the current administrative model is still better than Exchange 5.5.

3.1.2 Naming the organization

When Exchange first appeared, giving the organization an appropriate name seemed to be a very important item, largely because of the connection between the organization name and the internal X.400 addresses used for message routing. In addition, it was impossible to change the organization name after installation. Over time, administrators realized that users do not see the organization name and that email addresses do not have to relate to the organization name, so the fear of choosing an inappropriate name disappeared. Exchange 5.5 and Exchange 2000 still demand that you enter the final name for an organization when you install the first server (Exchange 5.5) or run ForestPrep (Exchange 2000). Exchange 2003 is more flexible, and you do not have to state the organization name when you run ForestPrep. If you do not know the final name, Exchange uses a dummy placeholder name instead (a GUID) so that you can instantiate the organization and not have to decide on the final name until the time comes to deploy the first server.

Given that we are in an era of rebranding, acquisitions, and mergers, it makes sense to avoid using the company's current name for the organization. In fact, some Exchange designers go so far as to use a generic name such as "Exchange," "Messaging," or "Email" instead. A generic name avoids problems when the company decides to change its name, or when another company acquires it. In any case, the salient fact is that only administrators see the organization name, so they are the only people who worry about it.

---