Lesson 1: The Administrative Infrastructure of Exchange 2000 Server | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

Recall that the configuration information of Exchange 2000 Server is stored in the configuration naming context (NC) of Active Directory, and that Active Directory replicates this NC to all domain controllers in the forest, regardless of their domain membership. This means that every single domain controller holds a complete replica of the Exchange 2000 organization, which implies that you only need to connect to the domain controller nearest to you to fully manage the organization. Theoretically, you do not have to connect to a particular Exchange 2000 server to manage its resources. In practice, however, it’s slightly different.

This lesson explains how to design the administrative topology of an Exchange 2000 organization. You will read about ways to delegate administration and practical constraints that limit your ability to centralize the management of Exchange 2000 resources. You will also read about the delegation of permissions to mailbox administrators.

After this lesson, you will be able to

Describe the purpose of administrative groups in an Exchange 2000 organization
Grant user account administrators the minimum rights to manage mailbox resources
Design the administrative infrastructure of an Exchange 2000 organization according to theoretical recommendations and practical limitations

Estimated time to complete this lesson: 45 minutes

Understanding the Administrative Design of Exchange 2000 Server

The container in the configuration NC that holds the Exchange 2000 configuration items is known as the Organization object. This container is displayed as the root in the console tree of Exchange System Manager. Underneath it, you find an object called Administrative Groups, which, as its name indicates, contains the various administrative groups of your organization. The administrative groups, in turn, provide access to containers called Servers, which hold the individual server objects. An organization, administrative groups, and servers form the administrative topology of the Exchange 2000 organization (Figure 5.1).

Figure 5.1 - The administrative topology of an Exchange 2000 organization

Note

Microsoft recommends using the name of the Windows 2000 root domain for the Exchange organization object. Administrative group names, on the other hand, may be assigned an abbreviated name, such as AG and a four-character identifier for the geographic location (for example, AGSFCA). However, you may find it more useful to use full names for organization and administrative groups, such as "Coho Vineyard and Winery" and "AG San Francisco California." The names can be 64 characters long but cannot contain these special characters: ~`!@#$%^&*(),_+={}[]|\:;’".?/.

Permission Inheritance

Recall from Chapter 3, "Assessing the Current Network Environment," that permissions are inherited from parent containers to child objects to simplify the task of security management. This implies that an administrator with permissions at the organization level can automatically manage all servers in all administrative groups. On the other hand, if you want to grant an administrator only permissions for a subset of servers, you need to create a separate administrative group, place all those servers in that group, and then grant the administrator the required permissions. All configuration objects underneath the administrative group will then inherit the security settings. Seldom do you have to grant explicit permissions to individual servers.

Note

The members of the Enterprise Admins group and the Domain Admins group of the top-level domain inherit full permissions to the organization object from the root object in the configuration NC. By default, these administrators are able to fully manage the entire Exchange 2000 organization.

Creating Administrative Groups

By default, all servers are added to the same administrative group, called First Administrative Group. If you want to place a server in a different administrative group, you first need to create the group in Exchange System Manager, and then run Setup to add the server. A particular server can only belong to one group, and you can only add a server during Setup. Unfortunately, it is not possible to move servers between administrative groups. Therefore, you must design and establish the administrative topology of your organization prior to installing the servers.

To simplify the user interface in Exchange System Manager, administrative groups are not displayed if only the default group exists. To display this administrative group, you have to right-click the organization object in Exchange System Manager and select Properties. In the Properties dialog box, enable the Display Administrative Groups check box. You need to restart Exchange System Manager to fully activate the changes. When you restart Exchange System Manager, you can find an Administrative Groups container in the console tree. To create additional groups, right-click this container, point to New, and select Administrative Group. You only need to specify a name and then click OK. A new, empty container appears in the console tree.

Delegating Permissions to an Administrative Group

Delegating permissions is the only task you can perform on an administrative group. Right-click the desired container object and then select the Delegate Control command to launch the Exchange Administration Delegation Wizard. This wizard provides similar functionality to the Delegation Of Control Wizard in the Active Directory Users and Computers console.

You can assign the following roles to your Exchange administrators:

Exchange View Only Administrator Can display the Exchange 2000 configuration information in Exchange System Manager.
Exchange Administrator Can manage the configuration of the Exchange 2000 organization but is unable to delegate administrative permissions or change security settings on information store databases, public folder hierarchies, or address lists.
Exchange Full Administrator Can manage the entire configuration of the Exchange 2000 organization including the delegation of administrative permissions and configuration of security settings on information store databases, public folder hierarchies, or address lists.

Note

You need to log on as a user with the Exchange Full Administrator role to the organization to use the Exchange Administration Delegation Wizard. It is good practice to create security groups, delegate administrative permissions to these groups, and manage Exchange administrators through group memberships.

Granting Permissions to Mailbox Administrators

Account administrators are able to manage almost all mailbox settings of their users by default, unless you go through the complex task of specifying permissions for each individual user and mailbox attribute separately, as explained in Chapter 3, "Assessing the Current Network Environment." However, to create, move, or delete mailboxes, account operators require explicit permissions in the Exchange 2000 organization. At minimum, they need Exchange View Only Administrator permissions to become genuine mailbox administrators.

It is important to keep in mind that user accounts are grouped in OUs, whereas mailboxes are Exchange 2000 server resources and are therefore part of administrative groups. This implies that a user can have his or her mailbox on any server in the organization regardless of the user’s OU. For instance, you can move a user easily between OUs, but the mailbox will remain on the original home server. To move the mailbox, you need to right-click the user account, select Exchange Tasks, and then choose Move Mailbox. Keep in mind that it is only possible to move mailboxes across administrative group boundaries in native mode. However, to let your account operators fully manage mailbox resources, you need to grant them, at a minimum, the Exchange View Only Administrator role at the organization level (Figure 5.2).

Figure 5.2 - User accounts and mailbox resources

Note

If you grant an administrator the Exchange View Only Administrator role at an administrative group level using the Delegation Of Control Wizard, the administrator is automatically granted the Read permission at the organization level as well to allow this person to display the organization in the Exchange System Manager console. In other words, there is no straightforward way to restrict Read access to only a particular administrative group without explicitly denying the administrator access to all other groups. If possible, avoid permission denials and grant Exchange View Only Administrator access at the organization level.

Blocking Inherited Permissions

You may be forced to block inherited permissions to a particular administrative group to guarantee that only explicitly appointed administrators have control over a particular group of servers. You can achieve this in two ways: You can stop the permission inheritance by clearing the Allow Inheritable Permissions From Parent To Propagate To This Object check box in the desired administrative group’s Security tab or you can deny the desired group of administrators full control explicitly.

It is not advisable to stop permission inheritance because this can easily lead to a situation in which Exchange 2000 Server services lose access to the configuration information, which would render the system nonoperational. It’s slightly less risky to create an extra security group for this purpose (you may call it Denied Admins or something similar), revoke the Full Control permission to the administrative group for this security group, and then add the desired accounts as members to this group. When denying access permissions, use extreme caution not to affect special groups or system accounts, such as Enterprise Admins, Domain Admins, Everyone, or any other group that contains important accounts. Keep in mind that denied permissions cannot be regranted, and if you deny all administrators or the server services access to the configuration, you will severely impair the Exchange 2000 organization.

Microsoft does not recommend blocking permissions either way. In fact, developers were so concerned about the high risks of damaging the organization that they opted to remove the Security tab from the organization and administrative group objects. You need to enable the Security property page explicitly by adding a DWORD value called ShowSecurityPage to the Registry and set it to 1. If possible, refrain from using the Security tab to manage access rights because it does not prevent you from setting permissions incorrectly.

To display the Security tab, add the ShowSecurityPage value to the following Registry key:

 HKEY_CURRENT_USER \Software \Microsoft  \Exchange  \ExAdmin

Note

Use the Exchange Administration Delegation Wizard to grant administrative permissions to your organization or administrative groups. If you need to work with the Security tab to deny access permissions, use caution, and carefully check the settings in a test lab before configuring the production system.

Centralized vs. Decentralized Administration

Theoretically, it is possible to specify individual administrators for each Exchange 2000 server separately. Obviously, this highly distributed administration model does not scale well to a large number of servers. Do you need 20 administrators to manage 20 servers? For efficient system administration, determine those servers that can be managed together and place them in a single administrative group. The more servers you group together, the more you centralize system administration.

Exchange 2000 Server allows you to structure the system administration according to the following models (Figure 5.3):

Centralized All servers are members of the same administrative group, which is managed by a central board of administrators. Centralized system administration makes it easy to coordinate management efforts.
Decentralized Servers are grouped into separate administrative groups according to physical locations, departments, or server roles and managed as individual units. The advantage of decentralized administration is that locations or departments can gain the ability to handle their server resources autonomously. The downside compared to the centralized model is increased administrative overhead and higher requirements for coordination of system management activities.
Mixed A decentralized approach in which some locations or business divisions are managed according to the centralized model.

Figure 5.3 - Centralized, decentralized, and mixed system administration

Designing an Administrative Topology

Perhaps the quickest way to design an administrative topology for Exchange 2000 Server is to take a piece of paper and sketch the Windows 2000 domain and OU topology. Indicate the root domain and write into each domain and OU the names of the administrators and account operators. As soon as this is accomplished, merge all those units that have the same administrators. The diagram will then show an appropriate administrative topology for your Exchange 2000 organization. At this point, you can refine the administrative infrastructure according to physical locations, business units, or server roles, or you can keep things simple and leave your administrative groups mapped to Windows 2000 domains and OUs. The choice is yours. You can find guidelines for the documentation of domain topologies in Chapter 3, "Assessing the Current Network Environment."

Note

You do not need to fully install Exchange 2000 Server in every Windows 2000 domain. To prepare those domains where you don’t intend to place a server, run Setup in DomainPrep mode. Permissions of a domain and a local administrator are required to run Setup /DomainPrep successfully. The domains must be prepared to allow the Recipient Update service to manage the e-mail addresses for all users.

Root Domain Dependencies

Although the administrative infrastructure of Exchange 2000 Server is not necessarily mapped to the Windows 2000 topology, there are definite dependencies in respect to the root domain. Recall that the members of the root domain’s Enterprise Admins and Domain Admins groups receive full permissions to the entire Exchange 2000 organization by default. Correspondingly, highlight the names of these "super-admins" in your documentation.

Administrators of Subdomains

Administrators of subdomains, on the other hand, require explicit permissions in the Exchange 2000 organization to manage messaging resources. All domain administrators trained in Exchange 2000 are good candidates for Exchange 2000 management. If additional or different persons should assume these positions, add the appropriate names to the circles in your administrative group diagram (and promote them to Domain Admins). Remove the names of all those administrators who will not take up any Exchange 2000 responsibilities, and your document will clearly show the future messaging administrators.

The questions from Table 5.1 can help to outline an appropriate administrative topology for your Exchange 2000 organization.

Table 5.1 Design Questions for Administrative Topologies

Questions	Comments
1.Does the same group of administrators manage the entire Windows 2000 environment, Active Directory, all user accounts, and the messaging environment?	If a single group of administrators manages the entire environment, it is appropriate to add all of them to the Enterprise Admins group and skip the explicit delegation of administrative roles in Exchange 2000 Server.
2.Is it possible to delegate all messaging administration tasks and user account management to the same group of administrators?	If your answer is yes, it is not necessary to separate the administration of servers and mailboxes. An account administrator who happens to be an Exchange Administrator at the organization level can manage the organization as well as mailboxes.
3.Do you need to separate the administration of user accounts from the management of Exchange 2000 Server?	If this is the case, grant your mailbox administrators the Exchange View Only Administrator role at the organization, and delegate the Exchange Administrator role to the appropriate system administrators either at the organization or administrative group level.
4.Do you need to delegate the management of Exchange 2000 servers to different groups of administrators?	If your answer is yes, you need to design an administrative group topology according to the business requirements of your organization (which usually corresponds to the Active Directory topology), and then explicitly delegate the Exchange Administrator role at the administrative group level.

Practical Limits of Unconstrained System Administration

If you follow the Exchange 2000 product documentation, you learn that administrative groups are not tied to the characteristics of the underlying network or domain structure, which implies that you do not need to worry about remote procedure call (RPC) connectivity or slow links when designing the administrative topology. This is a very theoretical assumption and, indeed, a fallacy.

To understand the problem, let’s take a look at Figure 5.4, which displays a critical administrative infrastructure. The IT group in Los Angeles centralized the administration of their entire Exchange 2000 organization without worrying about the network infrastructure and now has problems managing the servers. The connections between Los Angeles, London, and Hong Kong are unreliable and slow and therefore do not reliably support RPCs. As a result, Exchange System Manager cannot directly communicate with all servers and is not fully functional. The administrator is unable to examine message queues or mailbox statistics or to configure public folder settings in the remote locations.

Figure 5.4 - A questionable administrative design

When designing your administrative topologies, keep in mind that Exchange System Manager communicates with more than just Active Directory. This utility also communicates with the System Attendant (SA) service, the Information Store (IS) service, the Simple Mail Transfer Protocol (SMTP) transport engine, and other services. More often than not, this communication takes place over RPCs. Hence, if you plan to centralize system administration, make sure that all server resources are fully accessible via fast and reliable network connections that support RPCs. Bear in mind that the administrative topology of Exchange 2000 Server is not completely independent of the underlying network structure.

More Info: RPCs over Slow and Unreliable Network Links

RPCs enable applications to call functions remotely, as if they were local to the application’s code. Both the RPC-client (such as the Exchange System Manager) and the RPC-server (such as the Exchange 2000 System Attendant service) assume that they are calling local program routines, but, actually, the operating system redirects the call to what is known as the client stub code. The client stub takes the function call and translates the received parameters into data packets for network transmission. The client stub then uses RPC functions of the operating system to transfer the data to the RPC-server. The RPC-server, in turn, has an RPC run-time library at its disposal as well, receives the network request, and passes the data to the server stub code. The server stub translates the data and hands the information over to the actual server procedures (also known as remote procedures). A remote procedure will process the request and then return the resulting data back to the server stub, which returns the data to the client stub, which passes the data back to the PRC-client. To the client, it appears as if a local function call has returned the processing results.

RPCs make interprocess communication (IPC) as easy as calling a function in the local program code, which is why some programmers prefer this form of communication. Yet, RPCs have several disadvantages. For instance, as an application-layer communication mechanism, RPCs use other IPC mechanisms—NetBIOS, named pipes, or Windows Sockets—to establish the communication path, which means that RPCs come with a significant amount of protocol overhead. This overhead prevents RPCs from using network connections in a resource-conscious manner. To put it plainly, RPCs perform poorly over slow links.

Furthermore, and perhaps even more critical, RPCs are synchronous in nature. The execution of the client program halts until the (server) function returns the results. If the network connection between RPC-client and RPC-server is unreliable, the results may never reach the calling RPC-client, and the RPC- client will wait for the results in vain. In other words, the RPC-client routine will hang.

As a general rule, you should avoid RPC-based communication over slow or unreliable network connections, such as dial-up connections over satellite links or Internet links.

Designing an Administrative Topology for Adventure Works

Adventure Works (introduced in Chapter 3) has headquarters in Canada and subsidiaries in the United States, South Africa, and Australia. The company has split its Windows 2000 environment into four domains that correspond to the enter-prise’s four geographical sites and one root domain.

"We planned to implement a single domain environment," said John Y. Chen, "but political issues forced us to strictly separate our resources. Let me say it this way: At least we were able to bring everybody in the same Active Directory forest. South Africa and Australia are absolutely independent of our locations in Canada and the United States, which are likewise strictly separated from each other. I wish we could centralize our administration, but our business situation demands a more diversified approach. Nevertheless, I personally want to have complete control over the entire environment."

Chen documented and reviewed the domain topology of Adventure Works (Figure 3.24) and decided to structure the administration according to Figure 5.5.

Figure 5.5 - The administrative topology of Adventure Works’ Exchange 2000 organization

Activity: Designing an Administrative Topology for Exchange 2000 Server

In this activity, you will design an administrative topology for the Exchange 2000 Server organization of Consolidated Messenger, a company introduced in Chapter 1.

Tip

You can use Figure B.13 in Appendix B as a guide to accomplish this activity.

Scenario: Consolidated Messenger

Consolidated Messenger maintains an environment with one Windows 2000 domain in a single Active Directory forest. All 1500 employees work at the company’s site in Portland, Oregon. Connectivity between servers and workstations is fast and reliable.

"We are in a strange situation," says Gregory J. Erikson, Senior IT Administrator. "Due to a recent merger with Southridge Video, we now have two IT departments that take care of the user community. We were able to migrate Southridge Video’s legacy Windows NT environment and merge it with our Windows 2000 domain. Administrators from both IT departments now have full control over the resources in our domain, however, the new Video department objected to consolidating the messaging administration as well. We insisted on a common messaging platform for the entire enterprise, but had to agree on a long-term separation of the administration."

It is your task to recommend an appropriate administrative topology for Consolidated Messenger’s Exchange 2000 Server organization.

How many administrative groups do you need to implement?
What do you need to accomplish to prevent the administrators from managing each other’s messaging resources?
What should you recommend in addition?

Lesson Summary

Organization object and administrative groups form the administrative topology of Exchange 2000 Server. The organization holds all configuration objects, and administrative groups are used to consolidate server resources for more structured system management. Administrators with permissions at the organization level can automatically manage all servers in all administrative groups. The same applies to members of the Enterprise Admins and Domain Admins groups in the root domain, who inherit the permissions from the root container in the configuration NC. To delegate administration for a subset of servers, you need to create a separate administrative group, place all desired servers in it, and then grant the administrators the required permissions at that level. You can only add a server to an administrative group during Setup.

It is important to keep in mind that user accounts are grouped in OUs, whereas mailboxes are Exchange 2000 server resources and therefore part of administrative groups. This implies that a user can have his or her mailbox on any server in the organization regardless of the user’s OU. For this reason, you must grant your mailbox administrators, at a minimum, the Exchange View Only Administrator role at the organization level.

The more servers you place in a single administrative group, the more you centralize system administration. Centralized administration makes it easy to coordinate management efforts, but there are limitations in regard to the network topology. When designing the administrative topology of your organization, keep in mind that Exchange System Manager needs to communicate with the Exchange 2000 services directly to be fully functional, which requires a reliable network connection. It is not advisable to completely ignore the network dependencies. Although the administrative infrastructure of Exchange 2000 Server is not necessarily mapped to the Windows 2000 topology, it is a good idea to match the infrastructures closely.