Software

Planning an administrative model for Exchange 2000

Even Superman would have a hard time administering a full-blown Exchange environment. With a little advance planning of your administrative model, you can make sure you don't need a superhero to help you out of a mess later. Brien Posey shows you how.

Any time you’re thinking of setting up Exchange 2000 in an enterprise environment, it goes without saying that there’s going to be a lot of planning involved in the process. One of the first things you should plan is your administrative model. Designing the administrative model basically involves deciding how each Exchange 2000 server will communicate with the other Exchange 2000 servers, how clients will access the servers, and most important, who will take care of each server. In this Daily Drill Down, I’ll explain how to go about creating an Exchange 2000 administrative model for your organization.

Before you begin
I mentioned earlier that one of the primary considerations when designing an Exchange 2000 administrative model was deciding who would care for each of the Exchange 2000 servers. As you make these decisions, you should keep in mind that Exchange 2000 is tied to Windows 2000 much more closely than Exchange 5.5 was tied to Windows NT. While it’s still possible for someone to administer an Exchange 2000 server without doing much to care for Windows 2000, I recommend having the person who’s taking care of the Exchange 2000 administration take care of any administrative tasks that are related to Windows 2000 as well.

The reason for this is that all of your Exchange 2000 servers may not be located in the same place. I once had a job in which some of our servers were as far apart as 600 miles. Although I had someone taking care of the basic administrative tasks in each location, I had to drive out to the location every time Windows or Exchange had an error. Needless to say, all of this driving took time away from the tasks I needed to be working on. Therefore, if your network is spread out geographically, I highly recommend giving your Exchange administrator in each location as much Windows training as possible.

Now that I’m done ranting, let’s get down to business. You can use one of three main administrative models with Exchange 2000: centralized administration, distributed administration, or a combination of centralized and distributed administration. Of course, each of these methods has advantages and disadvantages associated with it. In the sections that follow, I’ll discuss each of these administrative methods in detail.

Preliminary planning
Before I go into the various administrative methods, it’s important to do some planning first. By knowing a little bit about your network’s configuration, it’s possible to see immediately that some options will work out better for your situation than other options. Some types of administration may be bad ideas and may be impossible based on your network’s design.

The first factor you should take into consideration is any existing Exchange servers and clients. This Daily Drill Down assumes you’re building a messaging system from the ground up, but if you already have some Exchange servers in place, you’ll certainly want to take that into account. You’ll need to look at such factors as where the servers are located, who’s taking care of them, and how they are linked together.

Next, take a good look at your network infrastructure. If your Exchange organization is going to be spread out geographically, you’ll need to know what type of connection is available between offices. More important, though, you’ll need to know the connection’s speed and whether the connection is reliable. This information is very important because you don’t want to make a decision to administer everything from your office if the connection to the remote offices is too slow or too unreliable to handle the administrative traffic.

Routing groups
Routing Groups are an important concept in designing an administrative model. It would be easy to dedicate this entire Daily Drill Down to routing groups. Because I don’t have that kind of space, though, I’ll briefly describe the purpose and limitations of routing groups.

Routing groups define which servers may communicate directly with one another. In small organizations, it’s usually better to have a single routing group. However, if your organization is spread out geographically, you might consider having a separate routing group for each office. The idea behind doing so is to keep a lot of the Exchange-related traffic from flowing across a slow WAN link. Servers belonging to a common routing group must belong to a common Active Directory forest, have persistent network connectivity, and have no network link that’s slower than 128 Kbps. Of course, 128 Kbps will be too slow if you’re sending a lot of traffic across the link, so you should plan accordingly.

Administrative groups
Another concept you need to be familiar with is administrative groups. An administrative group is nothing more than a group that defines who has what administrative permissions within an Exchange 2000 environment.

For example, if you have 20 offices in 20 different cities and each office has its own IT staff, you might assign a separate administrative group to each office so that each office can manage its own Exchange servers. If, on the other hand, you have people dedicated to specific tasks, you could create an administrative group for performing such tasks as administering public folders or mailboxes. This would make it possible for a single group of people to manage public folders or mailboxes anywhere among the 20 cities. For a detailed description of what administrative groups are and how they work, see the Daily Drill Down titled “Using Exchange 2000 administrative groups.”

Centralized administration
As the name implies, centralized administration refers to an administrative arrangement in which all of the Exchange 2000 servers are controlled and administered from the corporate headquarters (or from some other centrally located office). As I suggested earlier, centralized administration works best when there’s a reliable, high-speed connection between each office. This isn’t an absolute requirement, but I personally wouldn’t even consider doing central administration unless the connections between the offices were fast and reliable.

There are a couple of different ways of doing centralized administration. The method that’s best for you depends a lot on the client machine’s capabilities. One way of doing centralized administration is to place every Exchange server in the organization in the central office. You can then have the clients use a Web browser to access their mailboxes. This method works best if you have limited bandwidth and clients that may not have enough hardware resources to run full-blown copies of Outlook 2000.

The other method of centralized administration is for clients that require more than just access to a mailbox. In this arrangement, you can implement what’s known as a front-end/back-end configuration. In a front-end/back-end configuration, all of the mailboxes (and other Exchange resources) exist on servers at the main office. These servers are known as the back-end servers because they contain the databases and because the clients will never access these servers directly.

The next step in the process is to set up some Exchange servers at the branch offices and replicate the Exchange resources (mailboxes, etc.) that are stored at the main office to the servers at the remote locations. While the initial setup process is kind of a pain, this method makes client access and the administrative tasks a breeze. The reason for this is that any time you replicate mailboxes to multiple servers in a front-end/back-end configuration, the client doesn’t actually have to know where the mailbox is located because Exchange provides a unified namespace to all of the mailboxes.

In plain English, this means you can replicate every mailbox to every server if you want. This feature was originally designed for load balancing. For example, if you’ve replicated all of the mailboxes to three different servers, you could assign some of the users to server 1, some of the users to server 2, and the rest to server 3. This arrangement prevents too much strain on any one server.

However, the fact that Exchange provides a unified namespace means that you don’t have to manually assign users to separate servers. Exchange will take care of distributing the load among the available servers automatically. So what does load balancing have to do with centralized administration? When it comes to centralized administration, replicating mailboxes makes it possible for users to access their mailboxes from a local server, while keeping the actual mailbox at the main office for easy administration.

In this type of arrangement, it’s usually best to create a separate routing group for each office. You can then join the offices through the use of dedicated connector servers. Finally, you can use a single administrative group to ensure that the corporate office has the ability to administer the entire organization.

Distributed administration
A distributed administration model is designed for those situations in which you already have technical support staff at each branch who can handle all the administrative chores related to Exchange 2000. In this situation, you’ll probably want to assign a separate administrative group to the servers within each branch. However, keep in mind that moving servers between administrative groups is a difficult task. Therefore, before you start creating administrative groups, do some serious planning because making a server part of an administrative group is a semipermanent operation.

As far as routing groups go, I still recommend giving each branch its own routing group. The big difference in routing from the central administration model to this model is that although each routing group should still have a dedicated connection server, you’re not just going to be connecting each group to the corporate office.

Keep in mind that when we were talking about centralized administration, each routing group had to be tied solely to the corporate office because that’s where the actual mailboxes and other Exchange resources resided. However, in the distributed administration model, each office will maintain its own mailboxes.

Therefore, since it won’t cause problems to connect each branch office to other branch offices, I recommend connecting every office to every other office. If you like, you can associate a cost with each connector so that slow links are seldom used. However, the idea behind connecting all of the offices in this manner is to provide multiple routes that mail flow can use. If one route becomes unavailable, mail flow can still continue because you’ve created backup routes.

A combination of centralized and distributed administration
The idea behind using a combination of centralized administration and distributed administration is to get the best of both worlds. For example, if you have administrative staff at each office, it’s possible to delegate some control of the Exchange servers in their office to them, while still maintaining the ability to have total control from the corporate office.

It’s difficult to discuss the specific logistics behind implementing such an arrangement because every organization’s needs will be different. However, for a situation such as the one I just described, it may be best to use a routing model similar to the one I explained for distributed administration. From there, you can create multiple administrative groups based on your needs. Just remember that it’s nearly impossible to move servers from one administrative group to another. Therefore, plan your administrative groups and your organizational structure carefully.

Conclusion
In this Daily Drill Down, I’ve explained the importance of carefully planning your Exchange 2000 administrative model. As I did, I discussed the three different administrative methods you can use to get the job done.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
0 comments

Editor's Picks