The fifth installment of the 'Learn Exchange Server 2000 in 15 Minutes a Week' series introduces a new construct in Exchange 2000: Administrative Groups. Administrative Groups are collections of Exchange 2000 objects grouped together for the purposes of managing permissions.
by Michael Bell
As promised last week, we are going to spend this week taking a look at Administrative Groups. This is a new construct in Exchange 2000, although the idea is the same as it was in previous versions. By that I mean Administrative Groups are collections of Exchange 2000 objects that are grouped together for the purposes of managing permissions. Administrative Groups can include routing groups, public folder trees, policies, chat networks, conferencing services, servers and monitors. This allows for administrative delegation across your Exchange organization, something that you might require depending on the size of your Exchange implementation. This is a key to Administrative Groups, because if you are the only Administrator in your company, or you only have two or three Exchange servers, you might not need to define additional Administrative Groups. However, if your company consists of many locations, departments, divisions, or Exchange servers, then you might have a need for multiple Administrative Groups.
Another key point to consider is the fact that Administrative Groups are logical in nature. By this I mean that you can base your Administrative Groups on any aspect of your Organization that works for you. As I mentioned before, it can be function, department, geography, or the number of servers. How you divide your organization's administration will be entirely up to you. For example, if you had 30 locations around the globe, and a local administrator in each location, you could create an Administrative Group to reflect the 30 different locations, granting each Administrator control over the Exchange resources for that, and only that, specific location. In other companies, you might see a more centralized administrative approach. This might dictate that individual Exchange functionality would be controlled by different groups. For example, one group might be in charge of Routing Groups, another group would manage Recipient Policies, and still another would handle Conferencing Services across the company. The choices are many and varied.
Having said that, we should look at HOW permissions flow in Exchange 2000, because as I have mentioned before, things have changed a bit since Exchange 5.5. First thing that we have to take into account with Exchange 2000 is the tight integration between Exchange and Windows 2000. Exchange no longer maintains its own configuration database, instead storing its information in the Configuration partition of Active Directory. If you will remember from some of the basic Windows 2000 books and classes, Windows 2000 is broken down into three separate partitions. There is the Schema partition, the Domain Naming Partition, and the Configuration Partition. It is this last one where our information is stored, and here is where we should take a look at permissions. But first I want to look back at our Administrative Groups.
The first thing I want to show is the view from ESM (Exchange System Manager) when we have selected to view the Administrative Groups. Once again, in order to display Administrative Groups, we go to the Organization object in ESM, right-click and select Properties, and then put a check in the box to display Administrative Groups. What we should see, given a default installation, should look like this:
Next up, we create a second Administrative Group, to show you how permissions might work (and flow) in a company with distributed administration. We right click on the Administrative Groups, select New, Administrative Group, provide a name, and voila! Our new Administrative Group, Tampa has been created.
Now at this point, there is nothing in Tampa. It is simply a container, awaiting the day when we, the noble Exchange Admins, find it worthy of our Exchange servers and place the servers, along with public folder trees, and recipient policies amongst other things, into the administrative group. What we as Exchange Administrators have to be aware of is that once we have defined multiple Administrative Groups in our organization, this will become part of the installation procedure in that we will have to select which Administrative Group we want a particular server to belong to during installation. Another thing to note is that by default, you won't have the option of creating a Servers Container under the new Administrative Group.
You also won't be able to move servers from the Default First Administrative Group into any other Administrative Groups that you later create. And that brings up another issue. Some people will want to create administrative groups prior to installing any Exchange Servers into their organization. This is possible after you have run the
Forest Prep and Domain Prep utilities in your Windows 2000 forest. Open an mmc, Select the ESM, and then follow the instructions listed above to create a new (or several new) Administrative Group. You can even rename the default Administrative Group to something other than First Administrative Group, but to do so requires going into the Configuration partition, which we will be looking at later.
As I mentioned in the last paragraph, the creation of a new Administrative Group (Tampa, in our example) does not display a Servers container by default. However, that does not mean that one has not been created. If you open up Active Directory Sites and Services and select View, Show Services
Node, you should see the following:
As you can see, the Servers container was created, but not displayed by default in the ESM. After we have installed the first server into a particular Administrative Group, then we should see the Servers container displayed. Now, let's get back to the Administrative Groups and permissions. I had mentioned permission flow, and how that was an important consideration in managing your Exchange 2000 implementation, so I want to look at assigning permissions to my two Administrative Groups through ESM. After that, we will open up ADSI Edit, a Resource Kit utility, and take a look at the Configuration Partition and the information that it contains. Here we will see how permissions flow into our Exchange organization, and hopefully this will give us a better idea of how we want to set up permissions in a distributed administrative environment.
First off, though, I want to get the First Administrative Group name more in order with my organization's administrative model, which happens to be location-based. The Tampa Administrative Group is fine, but I want the First Administrative Group to reflect our Boston location. I will open up ADSI Edit and connect to the Configuration container by right-clicking on the ADSIEdit object, and selecting Connect To: The screen I see should look like the following:
Next, under naming context I would select Configuration Container and then select OK. My screen should look something like this; (Please note, I also have selected to view the Domain Naming Partition in this graphic; if you have not selected anything other than the Configuration Partition, you will only see one node listed under ADSI Edit).
Now all we need to do is expand out the configuration container, and you should be able to see where our Exchange Organization falls in this grand scheme:
As you can see, our Exchange 2000 Organization, 2000EXTrainers, is listed on the left hand side, and over on the right we can see the container for Administrative Groups. What I am going to do now is expand the Administrative Groups, First Administrative Group, and rename that object to fit our location-based administration scheme. It is a simple right-click on the First Administrative Group, followed by selecting rename, and voila, I now have a Boston Administrative Group.
At this point, the only thing that I have changed is the name of the default Administrative Group from "First Administrative Group" to "Boston". As I mentioned earlier, this fits my administrative scheme better, because I have the two locations and Exchange administrators in both. Now what I want to do is setup permissions on my Administrative Groups so that only the Exchange Administrators from the respective group will have permissions only for their Administrative Group. The first thing that I do to accomplish this task is run the Exchange Delegation of Control Wizard by right-clicking on the Exchange Organization Object and selecting Delegation of Control Wizard.
I use the Wizard to provide my two administrative groups, TampaExadmin and BostonExadmin, Read rights to the entire Exchange organization. This is necessary so that they can actually see the containers that they will be administering. Then, I expanded ADSI Edit, Configuration Container, and gave each group Full Control to their respective Administrative Group. To do this, I opened up the Configuration container, opened up the Services container, opened up the Microsoft Exchange Container, and opened up the Administrative Groups Container. I right-clicked first on Boston Administrative Group, went to properties, and then selected the Advanced Tab. I went to Add Users or Groups, selected the BostonExadmins group, and granted them Full Control Permission to that Administrative Group and everything below it. I then repeated the process on the Tampa Administrative Group for the appropriate group object. The following graphic should help to demonstrate:
To demonstrate just exactly what effect this will have, I have added one user to the TampaExadmins group, and one user to the BostonExadmins group. I added my personal account to the TampaExadmins group, and will log on to the Exchange Server to demonstrate how the rights inheritance occurs. In this case, what you should see is that although I can view the properties of the Boston Administrative Group, I can't make any changes.
In this instance, I was trying to create a new storage group in Boston, but as I don't have Administrative permissions in that group, I get an access denied error message when I attempt to create the new object. Depending on the needs of the organization, I could even go so far as to remove the Tampa admin's ability to view the Boston configuration and vice versa; again, it just depends on your administrative needs. Hopefully, this helps to emphasize the point about how permissions flow through Exchange; how you can set up multiple administrative groups in Exchange, and finally, how permissions are set and flow through the Configuration partition.
This last one is important, because as we can see from the second to last graphic, the Enterprise Admins and Domain Admins have considerable rights flowing into the Exchange Organization from the Configuration partition. Again, depending on the organization, this might be undesirable, so you would want to go in and either remove the respective groups permissions to the Exchange Organization, or you might simply want to reassign what they will be allowed to do at that level in the tree. Again, it will be your call to make based on the needs of your organization.
That about wraps it up for Administrative Groups. I know that I had mentioned last week that we would talk about Routing Groups as well, but apparently I lied to you. I will try not to make a habit of that, but as you can see, Administrative Groups are a robust feature of Exchange 2000, and I wanted to give you a full accounting of what they are for, and how you can use them. Next week we are going to take a look at how we mailbox-enable user accounts in Exchange 2000, and some of the different tasks that we can accomplish with Active Directory Users and Computers. Until then, cya.