Administrative Group Concepts

[Previous] [Next]

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, it is likely that you will 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 administer the local Exchange servers. Another possible arrangement would be for one group to manage all of the routing group functions, another to manage all of the public folder functions, and still another to manage all of the recipient policy functions. With administrative groups, members of the larger Exchange 2000 administration team can specialize in one area of administration, even if your Exchange 2000 organization is worldwide.

An administrative group makes it easier to assign administrative permissions. After you have 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 can be created in an administrative group include the following:

• Policies
• Routing groups
• Public folder trees
• Servers
• Conferencing services
• Chat communities

Choosing an Administrative Model

Essentially, there are three administrative models that you can use to organize your administrative groups: centralized, decentralized, and mixed. For the purposes of our discussion, we'll create a fictitious company called Oaktree, Inc. Oaktree has seven offices on three continents, as shown in Figure 12-1.

Figure 12-1. Oaktree, Inc.

Centralized Administrative Model

In the centralized administrative model, one group maintains complete control over all of 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 Oaktree, Inc.

Figure 12-2. Centralized administrative model.

NOTE

---

The fact that there is a high-speed connection between each of these geographical locations has no impact on the administrative model. All of 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 Oaktree, Inc. 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.

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 2000 Server.

Figure 12-3. Decentralized administrative model.

If you would like to centralize administration for both your Exchange 2000 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 of your Exchange 5.5 servers to Exchange 2000 Server.

NOTE

---

Native mode means that there are no more legacy Exchange servers running on your network. Native mode for Exchange 2000 Server is separate and distinct from native mode for Microsoft Windows 2000. For more information on native mode—what it is and how it works in Exchange 2000 Server—see Chapter 14.

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 2000 organization. However, all other administrative functions remain under the default First Administrative Group and are not 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 of the public folder trees. Figure 12-4 illustrates what this would look like for Oaktree, Inc., 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.