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 to 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 admins 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 mutliple 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.