Unlike Exchange Server 5.5, which defines both administrative and routing boundaries at the site, Exchange 2000 Server divides the two boundaries into administrative groups and routing groups. Dividing these two functions gives you greater flexibility for administration than that offered by Exchange Server 5.5. In this Daily Drill Down, I’ll take a look at how you can implement administrative groups to take advantage of their benefits for configuration control and administrative delegation.
Understanding administrative groups
The introduction of Active Directory (AD) in Windows 2000 Server considerably broadens your options for control over security and change control; because Exchange 2000 Server integrates with AD, those options extend to Exchange 2000 Server. One such option is the use of administrative groups to structure an administrative topology for your enterprise and define Exchange Server administrative roles for individuals and groups. While administrative groups are not generally necessary for larger organizations, they can be a key element of your Exchange administrative plan.
Administrative groups are really nothing more than AD containers tailored for Exchange Server administration. As with other AD containers, you can apply ACLs to administrative groups and define permissions that determine the actions that groups and individual users can take in the container. When you place objects in the container, those objects assume by inheritance the permissions applied to the administrative group. An administrative group can contain the following objects:
- Policies: These enable you to apply a set of configuration properties to one or more Exchange objects. For example, you might use policies to define the properties for a selection of message stores or public folder stores on a given server. Then, rather than make configuration changes to individual stores, you simply change the policy to apply the change to all stores to which the policy is applied.
- Routing groups: These enable you to define the way in which servers in your enterprise exchange data. You use routing groups to define connection topology between servers, specifying connection costs and other properties to manage Exchange network traffic.
- Public folder trees: A public folder tree is an object in the AD that defines the folder hierarchy. You associate public folder trees with public folder stores.
- Servers: The Servers branch displays servers and their contents, such as protocols and stores.
- Conferencing services: These objects define conferencing services administered by the group.
- Chat communities: A chat community stores channels, bans, classes, and other properties associated with the chat service.
The primary reasons for using administrative groups is to assign permissions that define administrative rights for users and groups. You can use one of three logical administrative models to structure Exchange administration in your enterprise: centralized, decentralized, and mixed.
In a centralized administrative model, the number of administrative groups is small; generally, a single group maintains administrative control over all of the Exchange servers in the enterprise. In some cases, you might create a small number of additional administrative groups to delegate authority to your core administrative personnel.
In a decentralized administrative model, you delegate administrative control to administrative groups at each physical site. If your company has 10 locations, for example, you might create 10 administrative groups, one for each location. Exchange administrators at each location would be responsible for administering their own server(s). The groups might be structured around geographical lines, departmental lines, company lines (where multiple companies fall under a common umbrella), or other logical identities.
In a mixed administrative model, you retain centralized administrative control over some aspects of your Exchange servers and delegate other administrative aspects to groups based on their function or locale. For example, you might maintain administrative control over the majority of your Exchange servers and functions thereof, but use one or more administrative groups to delegate control over policies. If the majority of your organization’s divisions were located in one country but you had a handful of others in other countries, you might maintain centralized control over all administrative functions in the primary country and delegate control to administrative groups individually in each of the other countries.
The existence of Exchange Server 5.5 in the enterprise can force you to use a decentralized administrative model. Exchange 2000 Server creates separate administrative groups if your organization includes multiple Exchange Server 5.5 sites when you migrate from Exchange Server 5.5 to Exchange 2000 Server. Each Exchange Server 5.5 site exists as a separate administrative group. You can achieve centralized administration by migrating all Exchange Server 5.5 servers to Exchange 2000 Server. Once you’re running Exchange 2000 Server in native mode (all Exchange 2000 servers and no Exchange 5.5 servers), you’ll be able to restructure the administrative groups, as you desire. Note that Exchange native mode and Windows 2000 Server native mode are two separate issues.
As you’re planning your migration strategy, take into consideration your enterprise network topology, bandwidth, reliability of connections, and departmental and other organizational structures. Then, decide how best to delegate administrative control over various aspects of Exchange Server management. With that information in hand, you’ll be ready to begin creating administrative groups and designing your administrative structure.
Overview of permissions
As you begin working with permissions to define administrative rights in your Exchange 2000 Server administrative groups, keep in mind that you use the native Windows 2000 permissions in AD to configure permissions in administrative groups. You can assign permissions at the container level (administrative group), on subcontainers, and on the objects within each subcontainer or administrative level. The permissions you apply to an object pass to its child objects by inheritance.
For example, if you assign permissions to an administrative group, the objects in the group receive those permissions by inheritance. While you can change permissions at the object class level, in most cases you’ll want to assign permissions at the parent level, instead. In general, the only time to set object class permissions separately is when you need to define permissions at the child level that are different from the parent. In these situations, you should examine the reasons for the difference in permissions to determine if you instead really need a different administrative group.
As you’re structuring your administrative groups and assigning permissions, consider the role that the different existing administrative groups can or should play in your Exchange Server administration. The Enterprise Admins group has full control over administrative groups by default, and Domain Admins have extensive—but not full—control over the groups, as well. If you want to limit the actions that Domain Admins can perform in managing Exchange Servers, create a separate Exchange Admins group, assign the group full control in the appropriate administrative groups, and modify the permissions on the groups to limit the Domain Admins’ permissions in the administrative groups. Do the same for any other groups that would otherwise have permissions in the administrative groups. To restrict these other groups, manually modify the permissions on the administrative groups and change their inheritance to prevent the default permissions from flowing to the groups.
Because Exchange 2000 Server provides extended permissions, you should configure permissions for Exchange Server through the Exchange System Manager rather than through the other MMC consoles that enable you to manage AD. Within the System Manager, you can apply permissions for some objects directly while others only receive permissions through inheritance.
Creating administrative groups
You create Exchange administrative groups through the Exchange System Manager. By default, the System Manager doesn’t show administrative groups. So you need to configure it to do so before creating new groups. Open the System Manager, right-click the organization, and choose Properties. On the General page, select the Display Administrative Groups option and click OK. Although System Manager raises a dialog indicating that you need to restart the System Manager to see the groups, it has been my experience that the groups appear without restarting. If you don’t see the Administrative Groups branch in the left pane, shut down and restart the System Manager.
To create a new administrative group, right-click the Administrative Groups branch and choose New, Administrative Group. System Manager raises a simple two-tab property sheet in which you specify the name for the administrative group on the General page and optional administrative notes on the Details page. Enter the name (and notes if desired), and then click OK to create the group, which should then appear as a folder under the Administrative Groups branch.
At this point all you have is an empty container. Before you begin adding objects to the group, you should consider setting permissions on the group. If you haven’t already created the security group(s) that will have administrative authority over the administrative group, create the group now and add users to the group as desired. Then, in the Exchange System Manager, right-click the administrative group and choose Delegate Control to start the Exchange Administration Delegation Wizard. Click Next at the first page and then click Add. In the Delegate Control dialog box, click Browse and select the security group to which you want to delegate control. Back in the Delegate Control dialog box, select the role the group will play. You can select one of the following three roles:
- Exchange Administrator: This role means the group can fully administer Exchange system information but not modify permissions.
- Exchange Full Administrator: This role means the group can fully administer Exchange system information and modify permissions.
- Exchange View Only Administrator: The group can only view Exchange configuration information but not modify it or modify permissions.
Add any other groups as desired and configure their roles, then click Next, and then click Finish.
When you’re delegating control, keep in mind the level from which you launch the Administration Delegation Wizard determines where the selected groups have control. If you launch the wizard from the organization level, the specified groups will have the specified permissions across the organization rather than at the administrative group level. For that reason, you should make sure you select the administrative group when launching the wizard to apply the delegation at the group level instead.
Creating administrative containers
After you create an administrative group, the next logical step is to create the containers for objects that the group will administer. To create the containers, open the Exchange System Manager and expand the Administrative Groups branch. Right-click the administrative group in which you want to create the container and choose New, followed by the container type you want to create. Keep in mind that you’re only creating a container, not an Exchange object. So you’ll also need to add objects to the newly created container.
To create objects in the container, right-click the container and choose New, followed by the type of object to create. For example, right-click a system policies container, choose New, and select a type of policy to create. Or right-click a folders container, choose New, and select the option to create a new public folder tree. After you create objects, you can set properties for them as needed.
Microsoft has improved many aspects of Exchange with the release of Exchange 2000. One of the nicest new features is Exchange’s use of administrative groups. In this Daily Drill Down, I’ve shown you what administrative groups are and how to use them.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.