3.3 Administrative and routing groups

---

We have already discussed some of the limitations of the Exchange 5.5 administrative model. Microsoft's response in Exchange 2000 and 2003 divides the management and routing responsibility previously held by sites into containers called "administrative groups" and "routing groups." It is still possible to have one person or group perform all administrative tasks for an Exchange server, but it is now feasible to devolve responsibility for different tasks at a far more granular level. The concept of "roles," essentially prepacked selections of permissions needed to perform certain tasks, makes it easy to assign permissions. Exchange 2000 and 2003 define "Exchange Full Administrator," "Exchange Administrator," and "Exchange View Only Administrator" roles.

For brand new organizations, the Exchange installation procedure creates default Administrative Groups and Routing Groups when you install the first Exchange 2000/2003 server. All Exchange servers join these groups until you create new administrative and routing groups. In mixed-mode organizations, Site Replication Services (SRS) are responsible for sharing configuration data about administrative and routing groups with Exchange 5.5 servers, and one server hosts the SRS function in each Exchange 5.5 site.

3.3.1 Defining an administrative group

An administrative group is a collection of Exchange objects that share a common set of permissions. An administrative group usually contains one or more mailbox servers, the policies that apply to the servers, routing groups, public folders, and other objects. If you have a mailbox store in an administrative group, you must also have a public store, and all of the front-end and back-end servers that work together must be in the same administrative group.

As you add objects to an administrative group, they inherit the permissions held by the group. This simplifies management, since you can be sure that the same permissions apply to all objects immediately after they are set on an administrative group. In Exchange 5.5 terms, servers in an administrative group share common settings in much the same way as servers in a site share settings, such as the site addressing defaults.

While administration groups usually hold at least one server, many large organizations deploy special administrative groups to hold a set of Exchange objects and isolate specific management responsibilities. For example, you can define an administrative group to hold all the routing groups in the organization so that only a special set of administrators can work with the routing topology. Another example is to create a special administrative group to hold all the server policies for the organization, which means that you can apply system policies at the level of the organization to make administrators manage the servers in a particular way rather than letting local administrators have full control over the servers. Figure 3.8 shows how you can assemble a set of system policies into a special administrative group that is under the control of central administrators. These policies are then applied to servers (in this case, on a geographical basis) to ensure that all of the servers share common settings.

Figure 3.8: A system policy applied to multiple stores.

In this example, the policy defines that message tracking is enabled on servers that you apply the policy to, that message tracking logs include subject information, and that message tracking logs are kept for seven days. It is clearly easier to build a policy and have it applied centrally than rely on multiple administrators to apply the required policy on every server.

It is reasonably common to find situations where a department wants to control its own computers and is unwilling to permit management by a central IT department. With Exchange 5.5 we can handle this situation by placing the servers belonging to the department into a separate site, and probably a separate Windows NT resource domain. This is an effective technique to protect data for mailboxes belonging to sensitive departments or users such as HR or senior management, but it is easy to create multiple Exchange sites in a single physical location, which results in an increase in the overall complexity of the messaging environment. Remember, every additional site increases the overhead imposed by directory replication and the likelihood that something will go wrong in message routing. The Exchange approach is to create separate administrative groups for special departments or groups of users and place the servers that host the associated mailboxes within the new administrative groups. Access to perform administrative operations on the servers is then delegated to security groups or individual accounts.

Administrative groups exist as containers under the Microsoft Exchange container in the AD configuration NC, and administrators can create empty administrative groups immediately after you install the first server in the organization. This is a useful feature, since it allows you to sketch out the management model for the organization through a set of empty administrative and routing groups that you subsequently populate with server installations. By comparison, while you can plan the shape of an Exchange 5.5 organization, it is more common to build it server by server, because an Exchange 5.5 site cannot exist without any servers.

3.3.2 Moving from sites to administrative groups

When Exchange 2000/2003 operate in mixed mode and some Exchange 5.5 sites still exist in the organization, an administrative group is treated exactly like an Exchange 5.5 site to ensure backward compatibility. Exchange 5.5 has no knowledge of administrative groups, so Exchange 2000/2003 disguise their existence by representing each administrative group back to the Exchange 5.5 servers as a site. When operating in mixed mode, you can only have a single administrative group and a single routing group in each site, whereas when you move to native mode an administrative group can host multiple routing groups. Figure 3.9 illustrates this concept in action. The "NSIS European Messaging Team" site has two servers represented in the organization by an administrative group that includes a routing group with the same name.

Figure 3.9: A site is an administrative group and a routing group.

Apart from checking the properties of an organization, you always know when an organization is operating in mixed mode because ESM provides some graphical clues. First, the folder icon for the site is white if no Exchange 2000/2003 server is present and tan otherwise. Second, the server icon is white for a legacy Exchange server and tan for Exchange 2000 or 2003.

Figure 3.10 illustrates these points. The "North America – West" administrative group contains Exchange 2000/2003 and legacy servers. The icon for the administrative group is tan, while the icons for the servers are either tan (Exchange 2000/2003) or white (legacy). The "Readers Choice" administrative group is composed entirely of legacy servers, so its icon is white, as are the icons for the individual servers. ESM includes the version of Exchange running on a server as one of the server properties displayed when you expand the set of servers in an administrative group (you can also view the server version by selecting a specific server and looking at its properties).

Figure 3.10: Mixed-mode exchange.

An organization remains in mixed mode as long as it contains Exchange 5.5 servers. The first step to start moving away from the fixed structure mandated by mixed mode is to move the organization into native mode. You perform this step by changing the properties of the organization to switch it into native mode, but you cannot proceed until all of the servers are migrated to Exchange 2000 and then to Exchange 2003. Figure 3.11 illustrates the properties of the "Compaq" organization, and the "Change Mode" button is grayed out because the organization is still in mixed mode. Switching to native mode is a one-way operation. You cannot reverse a change to native mode unless you stop operations and restore the Active Directory and every Exchange server to a state prior to the change, something that is not feasible in most situations outside a laboratory.

Figure 3.11: Properties of an organization.

Creating a new administrative group is very straightforward. Open ESM and click on the Administrative Groups node, then select "New…" from the context-sensitive menu. Figure 3.12 illustrates the properties for a new administrative group during creation, while Figure 3.13 shows how ESM lists the current administrative groups.

Figure 3.12: Adding a new administrative group.

Figure 3.13: Displaying administrative groups.

Administrators may have to make some behavioral changes as organizations migrate to the new administrative model. Sites control the set of objects (servers, mailboxes, and so on) that form the site, so an administrator of a site is the only person who can modify objects belonging to the site. The AD uses a multimaster model that does not tie objects to a site. Instead, the owning domain marks the initial administrative boundary, and enterprise administrators (those who have rights across an entire forest) have even greater scope. An Exchange administrator is, therefore, able to make changes to either configuration or user attributes according to his or her Windows permissions rather than any Exchange-specific rights, as is the case with Exchange 5.5.

As an illustration, let us assume that you have two Exchange 5.5 sites in New York and London. Each site has a separate set of administrators, and each operates in a separate Windows NT domain. After upgrading the servers to Exchange 2000/2003, we have two Exchange administration groups in the organization within a common Windows forest. Because the AD makes all objects available for modification, New York administrators are now able to change attributes for users in London. For instance, they could set new mailbox quotas or impose restrictions on the connectors people can now use. Suddenly, you can implement totally distributed management, possibly without administrators being aware of the effects and their new capabilities. I do not view this as a problem, but administrators need to be coached and agree upon a protocol for making changes to objects belonging to other administrative groups. If this does not happen, then problems may arise the first time that a remote administrator changes an object (and a local administrator notices).

3.3.3 No way to change administrative group design

The beta versions of Exchange 2000 included the ability to move servers by a simple drag-and-drop movement between administrative groups. However, while the feature worked, there were some problems behind the scenes and Microsoft removed the option to move servers before Exchange 2000 shipped. At the same time, Microsoft also removed the ability to rename administrative groups. In both cases, Microsoft was worried that replication latency might cause problems if the changes were not replicated quickly to all of the servers in an organization and cause potential problems within the organization. For example, consider the case when an administrator drags a server from one administrative group to another only to change his or her mind and reverse the action. The administrator then decides to move the server to a different administrative group, so we have three movements in quick succession with clear potential for confusion if these operations do not replicate quickly and precisely throughout the organization.

Another possible reason for mixed-mode organizations is that the site name (or administrative group name) forms part of the LegacyExchangeDN attribute that Exchange maintains for its AD objects to track their heritage prior to Exchange 2000. If you change the administrative group name, then you affect the value of the LegacyExchangeDN, and therefore conceivably lead to a situation where servers and other objects cannot make the necessary links within the organization. Taking away the ability to move and rename simplified Microsoft's design headaches and ensured backward compatibility, but it made the overall Exchange architecture very static and posed a new set of difficulties for system administrators.

The bottom line is that Exchange currently includes no method to move servers between administrative groups. If you make a mistake in placing servers in administrative groups, the only thing you can do is to create a new server and install it into the correct administrative group, and then move all the mailboxes across to the new server. You can then "clean up" by removing the server that caused the problem. This process is manual, network intensive, and time consuming and demonstrates the need to be as accurate as possible in the administrative group design first time round. Given the potential impact on the AD, it is highly unlikely that Microsoft will deliver the equivalent of the Exchange 5.5 "Move Server Wizard" tool in the near future.

3.3.4 Moving to native mode

Organizations commonly spend extended periods operating in mixed mode. It takes time to coordinate server upgrades across extended enterprises, especially when you depend on what might be a separate effort to deploy Windows and establish the necessary infrastructure for Exchange. As an example, Compaq began to deploy Exchange 2000 in the middle of 2000 and only managed to move into native mode in September 2002. At that point, Compaq was the world's largest Exchange 2000 organization with over 110,000 mailboxes, so you can expect to move from mixed to native mode sooner, but it does illustrate how slowly some migrations move. Of course, because HP had acquired Compaq, a new challenge emerged, as the Compaq Exchange 2000 organization started to cooperate and integrate with HP's Exchange 5.5 organization, and then to upgrade to Exchange 2003.

If you have a distributed organization with multiple administrative groups, you probably have multiple ADCs and connection agreements. Ensuring that you can move to native mode takes a certain amount of planning. Here are the basic steps.

• Gradually shut down and remove legacy Exchange 5.5 servers, taking care to remove any special components (public folder replicas, connectors, and roles such as OAB generation) from the server before removing it from the organization.

• Stop ADC replication.

• Remove any obsolete connectors.

• Remove SRS databases.

• Remove ADC services on any server that hosts an ADC.

• Check that no Exchange 5.5 servers exist in the organization and then switch to native mode.

Check for any problems after each stage. For example, ensure that messages route successfully, that directory synchronization proceeds normally, that you can add and remove users, that no server disappears from the Exchange organization, and so on. When you are happy that everything is ready, switch to native mode—but remember that this is a one-way trip and a massive restore exercise is required to move back, so perhaps wait one more day just to be sure before switching.

After you have moved into native mode, you may have further opportunities to clean up parts of your infrastructure, including:

• Removing any NT resource domains previously used to host Exchange servers

• Removing old Exchange administrative accounts and groups, including the service account that you used to run Exchange services

• Decommissioning and removing older versions of Exchange add-on software such as fax connectors, if you have replaced this software with newer versions

The aim is always to reduce complexity in your infrastructure by consolidating services onto a smaller number of servers. No migration to a new version of Exchange should result in an increase in servers unless the increase is temporary, such as the case when you acquire a set of servers from another company through a merger or acquisition. You can usefully deploy older servers released through consolidation as test servers or to take on less demanding tasks. For example, you can use old mailbox servers to host connectors or to test Exchange 2003.

3.3.5 The move to LocalSystem

The password of the site service account caused all manner of problems for Exchange 5.5 (and earlier) deployments. Because Exchange 5.5 uses its own directory, it needs a method to authenticate its own services to Windows when those services start. Windows runs the set of Exchange services (MTA, Information Store, and on so) under the security context of the service account. The password of the account is held in two places—the Windows SAM (or Active Directory) and the Exchange directory—and an option is available to update the password so that it is changed in both places. Unfortunately, if an administrator changes the password through Windows, synchronization does not occur and Windows detects the mismatch the next time it attempts to start Exchange. Exchange now avoids this problem by running its services under the security context of the LocalSystem account.

Most administrators understand the potential problems with the Exchange 5.5 service account and respond appropriately to avoid those problems. They have encountered all the common problems such as password mismatches, and solutions exist to help rescue the unwary. So, why did Microsoft elect to make changes in this area for Exchange 2000?

Microsoft decided to move from the service account to LocalSystem for three major reasons. First, Microsoft wanted to make Exchange easier to install and manage. Removing the requirement to select an account eliminated an opportunity to make a mistake. You cannot trust some administrators to set up or select a service account correctly, and some administrators use accounts in such a way that compromises system security.

Second, using LocalSystem to log on to Exchange services (Figure 3.14) creates a more secure Exchange server. Microsoft designed the LocalSystem account for system activities and protected it against interactive access. By contrast, the service account is a regular Windows account that anyone can log on to if he or she knows the password and then uses the elevated permissions held by the account to work with restricted data. Remember that if you can log on to the service account, you can access anyone's mailbox on a server. If you can access mailboxes, you can read anyone's mail or even send messages using other people's mailboxes. The use of LocalSystem has removed this opportunity for administrators to access mailboxes. Administrators can still break into someone's mailbox if they really want to, but it takes more work in an Exchange 2000/2003 environment.

Figure 3.14: Information Store service logs on as LocalSystem.

Third, LocalSystem has no password to manage. Windows automatically changes the password for the LocalSystem account every seven days. The resulting password is more secure than the values administrators typically generate, because Windows selects random passwords.

The problems of synchronizing passwords between the SAM and the DS have now disappeared. The Exchange engineers might have chosen to continue using a dedicated service account, but using LocalSystem reduces the number of things you need to manage to operate Exchange successfully. With LocalSystem, the account is part of Windows, which manages the account automatically. Therefore, an Exchange administrator only needs to know that the set of Exchange services runs under the LocalSystem account.

The change to LocalSystem makes installation easier, too. With LocalSystem in place, administrators only have to think about a service account when Exchange runs in mixed-mode organizations that include legacy (pre-Exchange 2000) servers. Here, SRS has to know about the service account before it can successfully mimic the Exchange 5.5 DS to newer Exchange server.

3.3.6 Routing groups

By definition, a routing group is a collection of well-connected Exchange servers that are able to make point-to-point connections to each other. In many respects, this is very similar to the definition commonly used for Exchange 5.5 sites. Routing groups define the message topology—how messages are going to move between Exchange servers and out of the organization—if required. Routing groups are subservient to administrative groups, since Exchange arranges every routing group in the organizational hierarchy under an administrative group. This is a logical arrangement. servers belong to administrative groups and routing is a function performed by servers. Note that Exchange is flexible enough to permit a server to exist in a routing group different from its administrative group, again because the management model separates responsibility for server management and the routing topology. Routing groups are merely a convenient way to collect servers together into a message routing topology so that they can perform common routing operations, as we will see shortly.

Before we discuss administrative groups in detail and review how routing groups fit into the picture, it may be worthwhile to set down some simple definitions:

• Administrative groups manage objects, including servers.

• Routing groups manage the routing topology.

• Neither is exactly equivalent to an Exchange 5.5 site.

• Routing groups are subordinate to administrative groups and are always created inside administrative groups.

• A single administrative group can hold all the routing groups in an organization, with other administrative groups used to manage server components and operations.

• Routing groups connect together in the routing topology with a variety of connectors, including the routing group connector, SMTP connector, and X.400 connector.

Now that we have set down some principles, let us see what they might mean in practice.

3.3.7 Routing group design

The default approach for a brand new Exchange organization is to simplify administration, so ESM does not display routing groups. Hiding the presence of routing groups is by design. There are many Exchange 5.5 servers deployed in single-site or even single-server organizations (the version provided with BackOffice Small Business Server is an obvious example), and the administrators of these systems have no need to plumb the depths of routing group complexity. Routing groups are a great way for corporate administrators to decide how to route messages across a distributed enterprise, but that is a business problem entirely different from the one that faces small companies that have one or two servers.

The division of functions between administrative and routing groups is much more flexible and powerful than the equivalent scenario in Exchange 5.5. Routing groups operate under the context or within administrative groups, so you can use a single administrative group to manage multiple routing groups. This allows routing groups to span multiple administrative groups and provides another level of flexibility in terms of management granularity. As an example, Figure 3.15 shows multiple routing groups operating within the single "Routing Administrative Group." Only the administrators who have permission over the special routing administrative group can make changes that might affect routing. This is a convenient way to isolate the management and control of the routing topology from the day-to-day operations otherwise required for servers.

Figure 3.15: Multiple routing groups operating within an administrative group.

Companies that have different teams assigned to manage mailbox servers and connector servers in an Exchange 5.5 organization often place the connector servers in their own site to create a security and administrative boundary. Creating a specific administrative group that only holds routing groups creates a similar management context for Exchange 2000/2003.

As an example of this concept in operation, look at the organization illustrated in Figure 3.16. Each country has a separate local administration team to take care of its Exchange servers, so we create an administrative group for each country and install servers according to their location. The "France" administrative group contains seven servers and the "Ireland" administrative group has just one. However, servers from both the France and Ireland administrative groups also appear in the "Routing Administrative Group," where they are members of routing groups based on the network links that connect the servers together.

Figure 3.16: Separating routing into a specific administrative group.

In this case, a hub and spoke design network is in place and enough bandwidth is available to support the necessary point-to-point connectivity within a routing group, so we can place the Irish server (QEMEA-ES1) in the "Europe (HUB)" routing group. If we install other servers in the Ireland administrative group, we can create a separate Ireland routing group and connect it into the hub with a routing group connector, using QEMEAES1 as the bridgehead server. Of course, the extra servers in the Ireland administrative group could also join the hub routing group, but the point of having a hub routing group is for it to act as a hub for the messaging network—not to create a convenient dumping ground for lots of servers. In Exchange 5.5 terms, such a design is often referred to as a "strong hub" and is created by placing a server from each physical location into a hub site. It is also interesting to note that the hub design so favored by Exchange 5.5 eliminates some of the benefits of the current Link State Routing model.

An alternative, and equally appropriate, design in many cases would be to create a separate Ireland routing group (similar to those for other countries, such as Germany and the United Kingdom), and use a routing group connector between Ireland and the Europe HUB routing group. In either case, appropriate delegations allow local administrators to perform mailbox operations and maintenance, with a separate central or corporate set of administrators to handle routing operations. This technique enforces a clear separation between server administration and the routing topology and illustrates the flexibility that is now available to system designers.

While the scenario that we have just discussed will be common in large deployments, at the other end of the spectrum it is entirely possible to have every Exchange server in an organization placed into a single routing and administrative group, which would be equivalent to installing all servers into a single Exchange 5.5 site. Outside small enterprises, this is an unlikely scenario, and it is much more common that medium to large enterprises will opt for multiple routing and administrative groups. Best practice is to seek to reduce the number of routing groups when you upgrade an organization to Exchange 2000/2003, because the more flexible and powerful Routing Engine now available enables simpler but more resilient routing topologies.

Microsoft recommends that you deploy no more than 250 routing groups inside an Exchange organization. Every routing group, server, and connector increases the amount of data that servers send to each other to update the link state table. Sending large amounts of updated information between servers will not affect you if network links are fast, but may influence matters across low-bandwidth connections.

---