Designing an Active Directory/Exchange 2003 environment using the Exchange Best Practices Analyzer
Best Practices of Active Directory Design
Several years of Exchange Server implementations using Active Directory led to a best practice for implementing them which will be described below.
Interoperability between Exchange Server and Active Directory
The first time Active Directory was needed as a requirement for Exchange was with the release of Microsoft Exchange 2000 Server. In former versions Exchange had its own directory service and that meant we needed to administer our users twice: in Exchange and in our directory service – whatever we were using. With Exchange 2000 Server this was gone, because Exchange now uses Active Directory as its directory service.
Exchange uses Active Directory for most of the things it wants to know and therefore a best practice for server placement needs to be defined. In addition to this there are a lot of things that need to be determined when planning an Exchange Server environment.
Communication between Exchange Server 2003 and Active Directory
Exchange Server 2003 communicates a lot with Active Directory. Nearly all communication information is stored in the configuration partition of Active Directory. And the information on the store of the users’ mailbox is saved as user property.
That means that if a message has to be routed; Exchange Server determines whether the mailbox is on the local server by taking a look at the entries of the global address list (GAL). The GAL is created using the recipient update service (RUS) which has a look at the directory information and creates an entry for all objects that are email enabled. This process runs every minute. The RUS communicates with the global catalog server via GC-LDAP (Port 3268).
If the recipient is not on the local server and the message needs to be routed to another server Exchange recognizes this via the GAL entry. Exchange server then has a look in the configuration partition and determines the way that server connections via connectors are available. This is done via GC-LDAP, too.
If the server recognizes that the recipients SMTP domain is not one it is responsible for, it tries to look for a way of sending the message outbound. This is generally done using the configured SMTP connector. The configuration of the SMTP connector is saved in Active Directory, too.
If incoming messages are for an email enabled group, Exchange connects to the global catalog server to determine the recipients of the message.
These are the most common connections between Exchange and Active Directory. That means it is very important to design an Exchange environment that has good connectivity to a domain controller or better, a global catalog server. This server should be placed near the Exchange server, in the best way directly in its local subnet to make sure a high-speed connection is available.
Determine the number of Global Catalog Servers
As you can see above, Exchange communicates a lot with Active Directory, especially with global catalog servers. That means within your Exchange Server Design you have to take care of where you place your Active Directory Domain Controllers with global catalog.
In addition to this you need to determine the number of Exchange users that can be supported by a global catalog server. Microsoft recommends a number of about 4000 users a global catalog server can support. That means if you have more than this amount of users you must place more than one server with global catalog role on it in your subnet. But generally for high availability reasons a second GC is recommended. That means your environment theoretically can support up to 8000 users at a time. But be careful, if one of your GCs goes down you only have support for up to 4000 users.
What does that mean for your design? Well, define what high availability means to you and your company, define how many users access one Exchange server at a time and then calculate the number of GCs you have to use. But do not forget to place your GCs near your Exchange server ideally within the same subnet.
Best Practices for Exchange Server 2003 Design
After having successfully determined your Active Directory design you now should design your Exchange Servers itself. That means you should define the configuration and some more details.
Determine the number of Exchange Servers
The first piece of information you will need to know is the number of Exchange Servers you need to use for your environment. This is not quite easy to say in general because it depends upon several business specific options (usage, number of employees, etc.). Microsoft itself recommends that you should implement one server for about 8000 users. In general a lot of other reasons (such as high availability) often make you buy a second server much more early.
With Exchange Server 2003 Microsoft has not yet provided a tool for capacity planning, but for Exchange 2000 Server you can find one. Because the internal design and structure of Exchange has not been changed a lot you should be able to use this tool for Exchange Server 2003, too.
Exchange 2000 Server Capacity Planer:
If you have already got a testing environment you might want to use some stress tools to determine the number of servers. If so, these tools may help you:
Exchange Server 2003 LoadSim:
Exchange Server 2003 Jetstress:
Best Practices for Exchange Server Configuration
After having determined the number of servers you have to implement you will need to determine the way you will configure your server. There are different ways and different opinions to do so.
In general your Exchange Server should not be a domain controller itself and should be able to save your databases and transaction log files with reliability. That means you should use RAID1 or RAID5 to be secure against hardware crashes of your hard disk.
If you would like to check your configuration against the recommendations of Microsoft, you should use the Exchange Best Practice Analyzer, a download from the Exchange site. Don’t forget that there are some updates available to improve the tool itself.
Best Practice Analyzer
After a successful installation you can start the tool and it will show you the following dialog:
Figure 1: Configuring the Exchange Scan
While scanning, you will see the following:
Figure 2: During the scan
After a successful scan, you will be able to generate a problem report.
Figure 3: Generating a report for Best Practices
The report itself might look like this example:
Figure 4: Best Practice Report (1)
Figure 5: Best Practice Report (2)
When you are designing your Exchange Server 2003 network infrastructure you should not forget to plan it in advance. Even though Exchange is a standalone product it relies on several features provided by network services (like DNS and especially Active Directory).
And if your implementation plan has some bugs in several parts (like the placements of domain controller and global catalog servers) your Exchange implementation won’t work as you have planned. And if you want to provide a new solution for your employees that does not work as proposed your employees usually won’t accept this new platform anyway.
So for a successful implementation and acceptance of Exchange or any new product, a good design is very important. And if you plan your implementation using the tools provided by Microsoft and other resources you will succeed. One of the best tools that has been published within the last month may be Exchange Best Practice Analyzer. It will give you a chance to improve your configuration and design as best as possible.
If you have still got any questions, please do not hesitate to contact me.