Exchange 2000 Administrative Groups

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 that 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 organizations 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 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.

Administering Exchange 2000

Well, the time has come to actually start administering our new Exchange server. In a moment we will take a look at the default view afforded by the ESM (Exchange System Manager), and we will begin discussing some of the issues involved in managing an Exchange 2000 implementation. I don’t want anyone to think that we are done with installations, because at this point we have just begun. But for now we are going to just sit back and examine our new Exchange installation. One of the best tools to use for this task is the ESM.

The first thing that we should notice is that we won’t be using the Exchange Administrator anymore, at least not in a pure Exchange 2000 implementation. Our new best friend is the ESM (see above) and it looks something like this:


This is a little different from our old Exchange Administrator, and has some “hidden views” to boot, so we want to look at this utility fairly closely. To start with, we can see at the top of the heirarchy is the Organization object, which we called 2000ExTrainers. If you remember, that was the Organization name we declared back when we ran forestprep. Below that we have Global Settings, Recipients, Servers, Connectors, Tools, and Folders. This is the default view, so we will discuss what is inside each one of these containers, and then we will explore the ESM a little further.

What we are looking at here (under Global Settings) are the Internet format settings (where we can configure our MIME types) and the Message Delivery Tab, which allows us to configure incoming and outgoing message size for all messages, as well as Filtering Options for undesireable UCE (Unsolicited Commercial Email). Next up is the Recipients container, which contains recipient policies, address lists, and templates. We will be looking at the address lists in more detail later, when we learn how to create custom address lists, as well as recipient policies, what they are used for, and where we can create and configure them from. We can’t see them yet, but next up would be the Administrative Groups, if we had them set to display. By default, they are hidden, so we won’t see them in our default view. However, later on we will see how to make them visible, and also talk about a couple of different scenarios that affect your ability to either hide or view Administrative Groups. There is also the Server container which will contain all servers in your organization, and a System Policies container which also is not visible by default. In fact, the System Policies container has to be created to be visible, and can only be created by having the Administrative Groups view available. This container has all configured mailbox store, public store, and server policies defined in your Exchange Organization. Next up is the Connectors container which contains your GroupWise, Lotus Notes, X400, SMTP, cc:Mail, MS Mail, and DirSync connector objects. Keep in mind that if you also have routing groups configured and set to display, connectors will also be visible within the corresponding routing group. Finally there is the Tools container which contains the Site Replication Services, allows you to track messages, and gather Monitoring and Status information.

ForestPrep and DomainPrep

Well, as promised last week, we are going to start off this week by finishing our look at Forestprep and Domainprep. After that, we will actually start through an actual installation of Exchange 2000 and see what’s new in the installation program. In case you have forgotten, you might want to look back at last weeks article for a quick review of how to run setup with either of these switches, as well as what each does.

When we were talking about Forestprep, we mentioned that this process was responsible for extending the AD schema for the introduction of the first Exchange server into our organization. The requirement to run Forestprep was to have both Schema admin and Enterprise Admin permissions. But in a smaller organization, you might be all of those things, as well as the Domain Administrator and the local administrator to boot. If this is the case, then you might not want to run forestprep as a separate process, but instead just run the installation program directly. You can do that, of course, but just be aware that the installation program will appear to take a long time to run, and it is because it will be running forestprep in the background. There is no way around extending the schema before introducing the first Exchange server into your Windows 2000 environment; the forestprep switch actually makes over 1800 changes to the schema of AD!! It is simply a question of whether you want to run forestprep by itself, or run it during the installation of the first Exchange 2000 server.

Installing Exchange Server 2000

Before we actually start our Exchange installation though, we need to talk about the rights required to install Exchange 2000 into the network. Exchange 2000 was the first Enterprise application designed by Microsoft to take advantage of the extensibility of the Windows 2000 Active Directory schema. By introducing Exchange into our network, we will now have a directory that understands mailboxes and virtual servers, amongst other things. In order to accomplish this task, we need an account that has the appropriate rights to modify the schema of Active Directory. This requires an account that is a member of both the Schema Administrators and Enterprise Administrators groups. The user must be a member of the local Administrators group as well.

Now this presents a quandry, because in a typical Enterprise environment, the number of users that will be in those first two groups is (or should be) extremely small. It is a quandry because typically, the Exchange Administrator will not be a member of either of those two groups. So how can we extend the schema if we aren’t a member of the appropriate groups? Enter ForestPrep. Running setup with the ForestPrep switch will allow an Enterprise admin to extend the schema of AD, without actually performing an installation of Exchange 2000. By completing this step, the Enterprise Administrator has extended the schema to understand the new object classes and attributes that will be used by Exchange 2000. When they are finished, we will be one step closer to staring the installation of our first Exchange 2000 server.

There are a couple of things to consider when running setup with the ForestPrep switch. We have already covered the rights issue. There is also the issue with spelling. Believe it or not, if you run setup with the ForestPrep switch, and don’t spell ForestPrep correctly, it will launch the full blown installation program and attempt to install Exchange 2000. I will be showing you the screens from ForestPrep later on in this article, and will point out what to look for.