Chapter 08: Building Administrative and Routing Groups (Part1)

Overview

In Exchange Server 2003, there are two ways to organize servers: according to the physical routing needs of your organization and according to administrative needs. Routing groups are physical groupings of Exchange servers that have full-time, full-mesh, reliable connections between each server and every other server in the group. Administrative groups are Exchange servers and other Active Directory objects that are logically grouped together for the purposes of administration and permissions management.

Note

In previous versions of Exchange Server 5.5, a single construct called the Exchange site was used to group servers for routing and administrative purposes. Routing groups are the closest to what these sites were in that they define a routing boundary for a physical group of servers. If you are coming from an Exchange 5.5 or earlier background, you can think of the routing group as the successor to the site and administrative groups, as a logical administrative layer imposed on top of the routing infrastructure.

This chapter covers the configuration and management of both administrative and routing groups. It begins by examining the different models for using multiple administrative groups and how using multiple groups is affected if you are running a mixed-mode organization—one in which previous versions of Exchange Server 5.5 coexist with Exchange Server 2003 (or Exchange 2000 Server). Next, this chapter looks at the process of creating and maintaining administrative groups. From there, the chapter turns to routing groups, examining the reasons an organization might benefit from using multiple routing groups and showing the actual process of creating new groups and linking them to one another using various types of connectors.

Creating and Configuring Administrative Groups

An administrative group is a collection of Active Directory objects that are grouped together for the purpose of permissions management. Administrative groups are logical, which means that you can design them to fit your needs—geographical boundaries, departmental divisions, different groups of Exchange administrators, or different Exchange functions. For example, one group of Exchange administrators might be responsible for managing the messaging and routing backbone of the organization, another might be responsible for managing public folders, and still another might be responsible for managing connectivity with a legacy messaging system. You could create an administrative group for each that contains only the objects the administrator needs.

The basic idea behind administrative groups is that they make it easier to assign permissions to groups of objects. Once you set permissions on an administrative group, any object moved to that group automatically inherits those permissions. You will learn more about assigning permissions in Chapter 10, “Administration and Maintenance.”

An administrative group can hold the following types of objects:

• Servers

• Routing groups

• Public folder trees

• System policies

Mixed Mode versus Native Mode

Before you get started dividing up everything into administrative groups, it is important to understand that there are some differences in how they are handled, depending on whether the Exchange organization is running in mixed mode or native mode. Mixed mode allows Exchange Server 2003 and Exchange 2000 servers and servers running earlier versions of Exchange, such as Exchange Server 5.5, to coexist in the same organization. It allows this interoperability between versions by limiting functionality to features that the different versions share.

Limitations of mixed mode include the following:

• Each Exchange 5.5 site in the organization is mapped directly to a single administrative group and a single routing group, and vice versa. This limits your ability to use administrative and routing groups in the way that best fits the needs of your organization.

• You can move mailboxes only between servers that are in the same administrative group.

• Routing groups can contain only servers that are part of the administrative group that is defined with the routing group.

  Note

  The Exchange Server 2003 native mode of operation is slightly different than the native mode of operation in Exchange 2000 Server. Native mode in Exchange Server 2003 allows for Exchange Server 2003 and Exchange 2000 Server to be used within the organization. Wherever you see native mode in Exchange Server 2003, this means that Exchange Server 2003 and Exchange 2000 Server computers can be used.

When you first install Exchange Server 2003, it defaults to running in mixed mode. If the entire organization will be running only Exchange Server 2003 servers and you do not plan to use any previous versions, you can switch to native mode. Native mode means you have a pure Exchange Server 2003 organization, which allows you to take full advantage of Exchange 2000 Server functionality. Be careful, though: If you change the operation mode of an Exchange Server 2003 organization from mixed mode to native mode, you cannot reverse this change, and the organization will no longer be interoperable with earlier versions of Exchange, such as Exchange Server 5.5.

Native mode offers the following benefits:

• A server can belong to an administrative group, but it does not have to belong to one of the routing groups within that administrative group.

• Administrative groups do not have to contain any routing groups.

• A single administrative group can contain all routing groups within the organization.

• You can move mailboxes between any servers in the organization.

  Note

  You can learn more about mixed-mode operations and managing the coexistence of Exchange Server 2003 and Exchange 5.5 in Chapter 11, “Connecting to Exchange 5.5.” From this point on, this chapter assumes that you are running Exchange Server 2003 in native mode and that all of the functionality of running in native mode is available.

Exercise 8.1 outlines the steps for switching an Exchange organization from mixed mode to native mode.

EXERCISE 8.1: Switching an Exchange Organization to Native Mode

---

1. Click Start > Programs > Microsoft Exchange, and then select System Manager.

2. In the left-hand pane, find the object for the organization that you want to switch to native mode. If you are running only one organization, this object is at the top of the pane.

3. Right-click the organization object and choose Properties from the context menu.

4. The Organization Mode field displays whether your organization is currently in mixed or native mode. Click the Change Mode button.

5. A warning appears stating that once you change to native mode, you cannot change back. Click OK to make the change.

6. You are returned to the organization object property pages, as seen below. Notice that the Organization Mode field now identifies the organization as being in native mode and that the Change Mode button is no longer available. Click OK to return to System Manager.

---

Using Multiple Administrative Groups

For most small to medium-size companies, where there is a single Exchange manager or a single management team, there is usually no reason to use more than one administrative group. In larger companies, it often makes sense to divide up the administration of the Exchange organization by location, department, or administrative duties.

There are three basic administrative models: centralized, decentralized, and mixed. It is important, both in the real world and for the exam, to know how these three models work.

Centralized Administrative Model

In the centralized model, one administrator or group of administrators maintains complete control over an entire Exchange organization. However, this does not necessarily mean that only one administrative group is defined. You might choose to create a few groups just to make it easier to assign permissions. Your routing topology does not need to match the administrative topology, of course. You may create many routing groups within a single administrative group.

Decentralized Administrative Model

The decentralized model is typically used to define administrative boundaries along real geographical or departmental boundaries. Each location would have its own administrators and its own administrative group. For example, a company with branch locations in three different cities would likely have administrators in each city. According to the decentralized model, an administrative group would be created for each location. Again, routing topology does not need to match administrative topology. You could create multiple routing groups within each administrative group. You could also have a routing group that spans multiple administrative groups or an administrative group that spans multiple routing groups.

Mixed Administrative Model

The mixed model is really a catchall model for any other ways you can think of to use administrative groups. It is useful for when you do not necessarily want the tight control of the centralized model and the strict geographic division of the decentralized model is not appropriate. Here are two examples of when the mixed administrative model is useful:

• You might want to keep most administration under the control of a single administrative group but restrict certain types of administration to certain administrators. For example, you might leave the default First Administrative Group intact for general Exchange management but create a special administrative group that holds all system policies. This way, only specific administrators could create and manage policies.

• You might want to combine geographic boundaries and functional boundaries. For example, assume that your company has its main location in one city and a branch location in another. You might want to leave the First Administrative Group intact for general management of the main location. You might then want to create an administrative group specifically for the branch location, another group for policy management, and another for public folder management.

Creating Administrative Groups

By default, Exchange Server 2003 is configured with a single administrative group named First Administrative Group. Also by default, this administrative group is hidden from view in System Manager, as shown in Figure 8.1. After all, why add a layer of complexity to the administration program by displaying administrative grouping when there is only one group?

Figure 8.1: By default, administrative groups are not shown in System Manager.

To enable viewing of administrative groups, open the property pages for the organization object. Select the Display Routing Groups and Display Administrative Groups options on the General property page, and click OK to apply the new settings. You are informed that you must shut down and restart System Manager to see the changes. After you bring System Manager back up, it looks something like the view shown in Figure 8.2.

Figure 8.2: System Manager showing administrative and routing groups

If you compare this view to the one shown in Figure 8.1, you’ll notice that the Servers, Routing Groups, and Folders containers have all been moved to show which administrative group they belong to—in this case, the US Administrative Group. All functionality remains the same, except that now you can create new administrative groups and arrange most resources among them however you like. Exercise 8.2 outlines the steps for creating a new administrative group.

EXERCISE 8.2: Creating a New Administrative Group

---

1. Click Start > Programs > Microsoft Exchange, and then select System Manager.

2. Expand the organization object in which you want to create a new administrative group.

3. Right-click the Administrative Groups container and select the New Administrative Group command from the context menu. This opens the property pages for the new group.

4. On the General page, seen below, enter a name for the new administrative group that identifies its purpose.

   

5. Optionally, you can switch to the Details page and enter some text that describes the purpose of the new group.

6. Click OK to return to System Manager. The new administrative group is displayed in the Administrative Groups container.

---

Once you have created a new administrative group, the first thing you’ll want to do is assign the appropriate permissions to the group. By doing this first, you ensure that new objects created inside the group inherit those permissions. Permissions are covered in Chapter 10.

Once permissions have been assigned, it is time to structure the new administrative group. The first thing you must do is create one or more containers inside the group. Do this by right-clicking the group and selecting a new container type from the context menu. The types of containers you can create include the following:

• Routing Groups containers

• Public Folders containers

• Policy containers

Figure 8.3 shows the new administrative group we created previously, now populated with a Routing Groups container and a System Policies container.

Figure 8.3: Creating containers inside a new administrative group

Once you have created the subcontainers for the administrative group and defined the new group’s structure, you then have two options for filling up that structure with objects:

• You can create new objects within those subcontainers using the methods discussed throughout this book. For example, you can create a new public folder tree in a Folders container; the method for this is covered in Chapter 6, “Using Public Folders.” Creating new objects works in exactly the same way that creating objects in the default administrative group works. (Routing groups are discussed later in this chapter, and policies in Chapter 10.)

• You can drag objects from other administrative groups and drop them into the corresponding folders inside the new administrative group. For example, once you create a Routing Groups subcontainer in the new administrative group, you could drag routing groups from other administrative groups to the new administrative group. You can also drag the servers themselves between routing groups in the new administrative group. However, you cannot move servers between administrative groups.

There is one other item to be aware of regarding administrative groups. When you install Exchange servers into an organization after creating additional routing groups, the setup program lets you choose in which administrative group and routing group the server should be placed. This option never appears during setup if there is only one administrative group.