In Exchange 2000 Server, Microsoft replaces Exchange Server sites with new structures called administrative groups and routing groups. Although this change might take some time to get used to, it adds granularity, reduces the likelihood of administrative errors, simplifies routing, and increases flexibility. The extent to which you experience the benefits of administrative and routing groups depends on the stage of your migration to Exchange 2000.
Changing Needs
An initial goal of the Exchange Server 4.0 release was to migrate users from Microsoft Mail (MS Mail) post offices, most of which served very small user communities. Exchange 2000 has different goals.
Exchange Server has gathered an installed base of approximately 35 million clients. Commonly, large corporate email systems use numerous servers to host thousands of mailboxes, yet many corporations want to consolidate user populations to achieve economy of scale. Microsoft clearly understands the enterprise market's needs (and also wants to move Exchange Server into other markets, such as the ISP or application service provider—ASP—space), so Exchange 2000 addresses many of the earlier versions' architectural restrictions. For example, Exchange 2000 partitions the Information Store (IS) into multiple databases and offers front-end and back-end configurations that support server farms when connecting to Internet clients (i.e., IMAP, POP, or WWW Distributed Authoring and Versioning—WebDAV). Base OS features, such as 4-way clustering in Windows 2000 Datacenter Server (Datacenter), present many new options to help system designers build large Exchange 2000 servers.
The first server to support 10,000 real-life (as opposed to simulated) mailboxes is on the horizon—a fact that highlights another problem: Although Exchange Server 5.5's site model simplifies administration and works well for small organizations, it can be inefficient for large-scale or widely distributed deployments. Free administrative rein is convenient until you want some granularity. If you authorize a person to use the Microsoft Exchange Administrator program, that person can perform any administrative, routing, or security task. A huge gap exists between the skills that administrators need to perform different operations (e.g., changing a user's phone number vs. altering checkpoint settings for an X.400 connector), but Exchange Server 5.5 offers no means of defining administrative access according to skill level. Some companies put mailbox servers and connector servers in separate sites to isolate and protect connectors from inexperienced administrators' errors: The company can give one set of permissions to administrators who handle mailbox operations and another set of permissions to administrators who handle connectors.
Also, Exchange Server 5.5's organizational structure and message routing are extremely inflexible. For example, to move a server from one site or organization to another, you must run the Move Server Wizard—a procedure that can require many days of preparation (and recovery) and many hours of execution. In an environment in which companies constantly split up and amalgamate, such a time-consuming feature is a bad idea. Routing suffers from the inflexible nature of the Gateway Address Routing Table (GWART), which works well if the connectors that transport messages are reliable and constantly available but performs poorly when connectors fail. In such a situation, the Message Transfer Agent (MTA) would ideally detect problems and immediately reroute messages through the most efficient alternative route. Unfortunately, the MTA can't make effective rerouting decisions because the GWART is static and reflects a limited view (i.e., the network's state when the Routing Information Daemon—RID—master generated the GWART).
Aside from solving Exchange Server 5.5's scalability limitations, Exchange 2000 makes these granularity and flexibility problems obsolete. You can use administrative and routing groups to refine administrative and routing access to servers within an organization and to easily move servers from one group to another.
Site Primer
Most Exchange Server administrators know the definition of a site: a collection of connected servers that forms a full-mesh high-speed network. Sites provide administrative, routing, and security boundaries for Exchange Server 5.5 organizations. For administrative purposes, a site's servers share a common configuration and directory. Exchange Administrator lets anyone with administrative permissions for a site perform any administrative task on any server in that site.
For routing purposes, each site has one server that acts as the RID master and builds the GWART each night and each time someone changes a connector. (You can also use Exchange Administrator to rebuild the GWART: Select a server's MTA object, then click Recalculate Routing.) Exchange Server 5.5 replicates the GWART to all the site's servers, then the MTA uses the GWART to make message-routing decisions. Sites simplify routing—each server knows about every other server in its site, and they all share the site's installed connectors—unless you restrict the connectors' scope to specific servers or subsites. (The GWART considers connector scope when it determines the valid paths for a message, and Exchange Server 5.5 uses a server's location property to define the subsite to which the server belongs.)
For security purposes, site-owned objects typically inherit permissions from the site object. Unless you experiment with permissions to restrict administrative access to specific servers or other objects, someone with administrative permission for a site can work with any object in the site.
Introducing Administrative and Routing Groups
In Exchange Server 5.5's decentralized management model, each site exerts control over the servers that it contains. Exchange 2000 implements a similar model but replaces sites with a combination of administrative and routing groups. Microsoft defines an administrative group as a set of Active Directory (AD) objects that simplifies permission management. In practice, an administrative group is a set of servers that you use to manage permissions and administration according to a common policy. After you create an administrative group and assign permissions for it, any object that you add to the group automatically inherits those permissions. As Screen 1 shows, administrative groups can contain objects such as servers, policies, public folder trees, conferencing services, and routing groups.
Routing groups manage message routing only. The permissions that you assign to routing groups are unrelated to the permissions that you assign to the servers and other objects in an administrative group. A routing group is a set of servers that have point-to-point persistent connectivity and share a common view of routing. A routing group is similar to an Exchange Server 5.5 site, with two major differences: First, the servers in a routing group don't perform directory replication; second, Exchange 2000 uses SMTP rather than remote procedure calls (RPCs) to make connections between a routing group's servers. (In Exchange Server 5.5, you must group servers into sites according to the network's ability to carry RPCs in a reliable and robust manner.)
Seeing Is Believing
To help you visualize how administrative groups and routing groups offer increased granularity, let's look at the example Exchange 2000 organization that Screen 2, page 162, shows. The organization defines administrative groups for different countries in the organization and one administrative group, called Routing Administrative Group, to serve as a container for the organization's routing topology. Look at the three expanded administrative groups. The first group, France, contains two servers; the second group, Ireland, contains one server. The third group, Routing Administrative Group, contains three routing groups, so this organization has three major message routing centers—Americas, Asia Pacific, and Europe (HUB). As Screen 2 shows, the Europe (HUB) routing group includes servers from the France and Ireland administrative groups, so these servers share a common routing scheme.
You can assign a local administrative team to each administrative group and delegate permissions to let each team perform day-to-day mailbox server administration (e.g., create a new storage group, manage the full text index for a mailbox store, view messages queued for a connector) for that group's servers. The administrative groups' management operations are different from the routing groups' management operations, so you can assign day-to-day server management to one set of administrators and routing topology management (e.g., adding and maintaining the Exchange 2000 connectors, allocating servers to the appropriate routing group) to another set of administrators.
This example showcases Exchange 2000's granular management model. In many large companies, configuring and maintaining message routing is a specialized task that only a small group of people can undertake. Creating location-specific administrative groups to handle server management and isolating routing management into a separate administrative group is a great way to build a robust management infrastructure for midsize and large enterprises. Each team has an appropriate set of permissions, and neither team interferes with the other's work. Small enterprises can probably use a simpler administrative group structure, but Exchange 2000 still adds flexibility. For example, to move servers between routing groups, you can simply drag a group from the source routing group's Members folder to the target routing group's Members folder.
Managing Permissions
Even experienced systems administrators who have worked with Exchange Server since its earliest days will need to get accustomed to all the changes in the way Exchange 2000 handles permission delegation. Exchange Server 5.5 must implement a set of permissions to control access to directory objects (including configuration data, servers, and connectors), but Exchange 2000 uses standard Windows 2000 (Win2K) ACLs to secure objects such as servers and connectors. Using AD instead of the Directory Store is also a big change. A simple mistake in permissions can expose a server to unauthorized access, so Microsoft provides a Delegation Wizard to help you correctly set permissions. To invoke the wizard, right-click an administrative group and select Delegation Wizard from the context-sensitive menu. As Screen 3 shows, the program asks you to select users or groups to which you want to delegate an administrative role (i.e., a collection of permissions that enables fulfillment of a certain scope of tasks). If you delegate permissions at the organization level, all child administrative groups inherit those permissions. For administrative access to Exchange Server objects, Exchange 2000 includes a set of roles. You can customize the permission set that you allocate to a role, but you can't save and reuse customized roles. Exchange 2000 provides the following hard-coded roles:
- Exchange Administrator—permits access to perform administrative tasks such as mounting or dismounting a database
- Exchange Full—permits full administrative access, including the ability to change permissions
- Exchange View Only—permits access only to view the Exchange Server organization's configuration, including the contents of queues, mailbox quotas, and the status of full text indexes
Message Routing
From a design perspective, routing groups are much more flexible than sites. If your first organizational design isn't effective, you can move servers until messages flow smoothly across the company.
Remember that servers in an Exchange 2000 routing group don't perform directory replication. Instead, Exchange 2000 servers access Win2K AD on a Global Catalog (GC) server for tasks such as determining the server that owns a mailbox or finding information about connectors. The GC holds information about all the objects in the forest, including the Exchange 2000 servers' configuration data, such as the servers and connectors that are in each routing group and the paths that messages take between routing groups. Traffic between servers in a routing group decreases greatly when compared with traffic between servers in a site because directory replication, which automatically occurs every 5 minutes within Exchange Server 5.5 sites, is unnecessary. You must offset this traffic reduction against AD replication, which uses a mechanism similar to directory replication. However, whereas every Exchange 5.5 server participates in directory replication, not every Exchange 2000 server has a copy of AD, so well-designed Exchange 2000 infrastructures can generate less replication traffic than their Exchange Server 5.5 equivalents. Routing is possible only if servers can contact a GC, and you must replicate any Exchange 2000 configuration change to all GCs in the forest before the change can be completely effective. Clearly, if your AD replication topology encounters problems (perhaps because of poorly configured DNS), the data won't replicate in a timely or effective manner. Such replication problems can affect routing.
As I also mentioned earlier, Exchange 2000 servers within a routing group communicate over SMTP. Exchange 2000 introduces an SMTP-based transport and routing engine that replaces Exchange Server 5.5's X.400-based MTA. (The MTA is still available and can handle any connector, such as fax connectors, that you can build with the Microsoft Exchange Development Kit—EDK—but the new routing engine usurps the MTA's message routing role. For more information about Exchange 2000 routing, see "Exchange 2000 and SMTP," March 2000.) SMTP connections consume approximately the same bandwidth as RPCs but can connect across lower-latency links; therefore, in network terms, a routing group's boundaries can be wider than a site's boundaries.
Restructuring Groups
In Exchange Server 5.5, moving a server to a different site or organization is difficult and time-consuming because Exchange Server 5.5 identifies every object by a distinguished name (DN), which includes organization and site details, in the Directory Store. To move a server, you must change every DN associated with the server—a task that was nearly impossible until Microsoft introduced the Move Server Wizard in Exchange Server 5.5 Service Pack 2 (SP2).
Exchange 2000 servers also have DNs. But AD uses globally unique IDs (GUIDs), rather than DNs, as unique keys to objects. A GUID is a 128-bit number that Exchange 2000 allocates to an object when it creates the object. A GUID never changes, no matter how many times you move the object within the AD hierarchy. Moving a server from one administrative group to another or from one routing group to another is simply a matter of adjusting DNs to fit into a new location in the AD hierarchy—you can perform the task in a few seconds. Because groups are just AD containers, you can even create empty groups to sketch out an organizational structure. This useful feature lets you create a skeleton design in which administrators can install their servers. And if you install servers in the wrong place, Exchange 2000's flexibility lets you quickly move them to the proper groups.
Making the Switch: A Work in Progress
Introducing the first Exchange 2000 server into an existing organization puts the organization into mixed mode, meaning that both Exchange 2000 servers and earlier Exchange servers are present. Mixed-mode organizations must accommodate the needs of legacy servers, which can't cope with administrative groups and routing groups, so Exchange 2000 views each legacy site as a combination of an administrative group and a routing group. Conversely, Exchange Server 5.5 views each server's administrative and routing group as one site. (Remember that a mixed-mode organization represents a site as a combination of an administration group and a routing group.) Exchange 2000 uses the Active Directory Connector (ADC) and an Exchange 2000 component called Site Replication Services (SRS) to exchange configuration information between AD and the legacy Exchange Server Directory Store and to show the respective groups and sites to each server. Exchange Server uses only RPCs to send messages to legacy servers in mixed-mode organizations, so you can't take full advantage of Exchange 2000's flexibility. In mixed mode, you can move servers between routing groups but not between administrative groups, and you can't move mailboxes between servers in different administrative groups.
When you upgrade or remove the final legacy Exchange server, you can switch the organization into Exchange 2000's native mode. You can't reverse this one-way operation. You can change the mode from the organization's Properties dialog box, as Screen 4 shows. From the Properties dialog box, you can also select the Display administrative groups check box, which tells the Exchange System Manager Microsoft Management Console (MMC) snap-in to display administrative group details. (Small and midsized companies that want to apply one set of permissions and policies to all servers in the Exchange Server organization don't need to create multiple administrative groups, so Exchange 2000 hides administrative groups by default.) Flexibility becomes the keyword after you move the organization to native mode. After you change to native mode and have a pure SMTP environment, you can restructure the organization to reduce the number of routing groups and route messages more effectively than you can in mixed mode. For example, you can put all servers into one administrative group to implement a common organizational management structure. If you later decide against your centralized administrative group, you can divide it into several administrative groups and easily distribute the servers between them. At the same time, you can divide the same servers among routing groups according to the network topology. If you built your Exchange Server 5.5 organization with the requirement that servers in a site must be able to connect over 128Kbps links, your organization might base sites around network hubs. The base level for intrarouting group connectivity will probably have much lower bandwidth and latency, so you might collapse multiple sites into each routing group and thereby reduce organizational complexity.
Devil in the Details
Exchange 2000 is so different from earlier versions of Exchange Server that you might feel you need to relearn everything you thought you knew. But when you understand administrative groups and routing groups, you'll see the power that this new architecture provides. Examine how you can apply administrative groups and routing groups to your organization, and be prepared to go through several iterations before you arrive at an optimal design. As we say in Ireland, "The devil is in the details." Thankfully, administrative groups and routing groups make Exchange 2000 so flexible that designers don't need to sweat the details quite so often.
\[Editor's Note: The information presented in this article is based on Exchange 2000 Release Candidate 1 (RC1). Details might change in the final Exchange 2000 version.\]
