Chapter 12: Using Administrative and Routing Groups

In versions of Microsoft Exchange Server prior to Exchange 2000 Server, both the routing boundaries and the administrative boundaries were defined by the concept of a site. In Exchange Server 2003, these two functions are broken out into administrative groups and routing groups. Administrative groups are purely logical and are used to group individual administrative roles together to fit a company’s organizational criteria. A routing group is a collection of Exchange servers that enjoy permanent, high-bandwidth connectivity. Routing groups are most often based on the physical topology of your network. In this chapter, you will learn how to define and manage administrative groups and routing groups in Exchange Server 2003.

Administrative Group Concepts

Administrative groups are used to define the administrative topology for large companies with many locations, departments, divisions, Exchange servers, and Exchange administrators. They are logical in nature, which means that you can define a group based on geography, department, division, or function. For instance, if your company has 14 offices in 14 countries, you will likely have one or more Exchange servers in each location, with an Exchange administrator in each location as well. It might be best, in this scenario, to create an administrative group for each of your 14 locations so that the local Exchange administrator can manage the local Exchange servers. Another possible arrangement would be for one group to manage all the routing group functions, another to manage all the public folder functions, and still another to manage all the system policy functions. With administrative groups, members of the larger Exchange administration team can specialize in one area of administration, even if your Exchange organization is worldwide.

An administrative group makes it easier to assign administrative permissions. After you set the permissions for the administrative group object, any objects that are created or moved into the object will inherit its permissions. Hence, it is easiest to set permissions for an administrative group first and then to create objects inside the group and have them inherit the group’s permissions. As always, it’s best to set permissions at the highest object level and then have those permissions flow down the object hierarchy. Objects that you can create in an administrative group include the following:

• Servers

• Routing groups

• Public folder trees

• System policies

Choosing an Administrative Model

Essentially, you can use one of three administrative models to organize your administrative groups: centralized, decentralized, and mixed. For the purposes of our discussion, we’ll create a fictitious company called Trains By Dave. Trains By Dave has seven offices in three regions, as shown in Figure 12-1.

Figure 12-1: Trains By Dave.

Centralized Administrative Model

In the centralized administrative model, one group maintains complete control over all the Exchange servers. You might have only one group or a few tightly controlled groups for administrative purposes. Your routing group topology does not need to be the same as the administrative topology, which means that you can have multiple routing groups that reflect your physical topology while maintaining centralized administrative control in one administrative group. Figure 12-2 illustrates how this would work for Trains By Dave.

Figure 12-2: Centralized administrative model.

Note

The fact that a high-speed connection exists between each of these geographical locations has no impact on the administrative model. All the servers could be in the same administrative group, even if there was only an 8-Kbps connection between each location.

Decentralized Administrative Model

In the decentralized administrative model, each location has its own team of Exchange administrators and allows them administrative control over any objects placed inside their administrative group. These groups are often based on geographical locations or on the departmental needs of the company. Each of these groups can contain policies, servers, public folder trees, and other objects specific to the group. Figure 12-3 illustrates how this would work for Trains By Dave. We would set up an administrative group for each of the three continents and have a group of Exchange administrators, each of whom manages the Exchange servers in his or her own geographical area.

Figure 12-3: Decentralized administrative model.

If you are migrating from Exchange Server 5.5 and you had multiple sites in your Exchange 5.5 organization, you will be forced into using a decentralized model of administration during the migration. Each Exchange 5.5 site will be created as a separate administrative group in Exchange Server 2003.

If you would like to centralize administration for both your Exchange 2003 servers and your Exchange 5.5 servers, you’ll need to set permissions on the administrative groups that limit administration of that group to those whom you specify. This action won’t really incorporate the Exchange 5.5 servers into one administrative group, but it will limit administration to one group of administrators. The only way to really achieve the centralized model described previously is to migrate all your Exchange 5.5 servers to Exchange Server 2003.

Note

Native mode means that no more legacy Exchange servers are running on your network (that is, all servers run Exchange 2000 Server or Exchange Server 2003). Native mode for Exchange Server 2003 is separate and distinct from native mode for Microsoft Windows 2000 or the higher functional levels of Windows Server 2003. For more information about native mode—what it is and how it works in Exchange Server 2003—see Chapter 16, “Coexisting with Previous Versions of Exchange.”

Mixed Administrative Model

The mixed administrative model is best for restricting certain administrative functions to certain people while not creating specializations for every administrative function. In this model, you create administrative groups by function rather than by geographical location or departmental boundaries. For instance, you might create an administrative group whose only child object is policies. In this scenario, you can restrict to a handful of people the ability to create new policies or alter existing policies for your Exchange organization. However, all other administrative functions could remain under the default First Administrative Group and not be placed in their own administrative group.

You can also use this model to combine specialized administrative functions and geographical considerations into one administrative model. For instance, you might create an administrative group to manage the routing groups, a second group to manage policies, a third group for the Atlantic division, a fourth group for the European group, and a fifth group to manage all the public folder trees. Figure 12-4 illustrates what this would look like for Trains By Dave, retaining a decentralized model for day-to-day administration but centralizing the public folder trees into one administrative group and the policies into another administrative group.

Figure 12-4: Mixed administrative model.