ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
by Michael Bell
www.2000trainers.com
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.
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.
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.
