Since the early beta testing of Exchange 2000, Microsoft has stressed that Exchange 2000 would be tightly integrated with Windows 2000 Active Directory. There’s more to this integration than meets the eye, however. In this Daily Drill Down, I’ll explain some other ways that Exchange 2000 is integrated with Windows. I’ll also explain how and why Exchange Server benefits from this symbiotic relationship, starting with Exchange 2000’s integration with Active Directory.
Active Directory integration
Why did Microsoft integrate Exchange 2000 so tightly with Windows 2000 Active Directory? If you’ve ever worked with earlier versions of Exchange, you know that these versions contained their own directory service. The old Exchange directory service existed in the form of a database file called Dir.edb. The purpose of this directory was to organize the various Exchange objects, such as mailboxes, connectors, public folders, and distribution lists.
There were a couple of problems with using a stand-alone directory service, though. First, it created a lot of extra work for administrators, because they had to enter a lot of information—such as contact information—twice. The biggest problem with using a stand-alone directory, though, was that if the database became corrupted (which happens more often than you might think), Exchange was totally crippled. I’ve personally spent countless nights manually reconstructing directory service databases.
Still another issue was efficiency. Because Exchange and Windows were basically two separate products that existed on the same machine, Exchange 5.5 was inherently inefficient. A lot of memory, hard disk space, and processing power were wasted by juggling duplicate information rather than working from a single, unified copy.
Windows NT was desperately in need of a directory in order to fix some key problems with NT’s domain structure. Microsoft had a directory in its earlier versions of Exchange, but it was problematic for the reasons I’ve stated. To kill two birds with one stone, when Microsoft developed Windows 2000, it ported Exchange’s directory service to Windows 2000.
Because Active Directory is distributed among domain controllers, there’s a degree of fault tolerance built in. For example, suppose one of your Exchange servers were to crash and you had to reformat the server and completely start from scratch. In such a situation, when you got Windows back online, the other domain controllers in the domain would begin replicating the contents of Active Directory to the domain controller that you’re rebuilding.
Sure, there are still issues involved in restoring the other Exchange databases and there are also situations in which you’d also want to restore that server’s individual copy of Active Directory, but generally speaking, it’s comforting to know that Windows and Exchange are designed to automatically rebuild the directory information in the event of a critical failure. This is in contrast to earlier versions of Exchange and Windows NT, where recovery from a critical failure would be much more difficult.
While increased fault tolerance and central object management are certainly among the best benefits of integrating Exchange 2000 with Active Directory, there are other benefits as well. One is that the integration simplifies security management.
The reason is that Exchange 2000 looks to Active Directory for security information. Therefore, if you make a security change that’s traditionally only applied to Windows, it can affect Exchange as well.
For example, suppose that you make a change to a group’s membership. Both Exchange and Windows look to the same System Access Control List (SACL) for security information, and therefore, both Exchange and Windows are aware of the group’s membership change. Exchange depends very heavily on Windows 2000 security groups, and the fact that you can change a group’s membership and affect Windows 2000 and Exchange 2000 is significant.
Many organizations that use Exchange 5.5 create distribution lists based on departments. For example, an Exchange 5.5 server might contain a distribution list for the finance department, one for the marketing department, one for the systems department, and so on. Every time one of these departments gets a new employee, the distribution lists have to be updated to include that employee.
Now consider that most Windows NT domains use group-based security. For example, you might have a security group for marketing, finance, systems, etc. These security groups traditionally control access to applications and data that everyone within a given department needs to access. As with the distribution lists, security groups must also be updated every time a new employee joins a department.
This means that an administrator may have to update two identical groups every time a new employee joins a department. Exchange 2000 solves this problem by eliminating distribution lists in their previous form. Instead of having separate distribution lists, Exchange 2000 uses Windows 2000 security groups as distribution lists.
Information lookup efficiency
As you may recall, when you looked up information in the Exchange 5.5 directory, Exchange 5.5 used NSPI (Named Service Provider Interface) for the lookup. Another advantage to integrating Exchange 2000 with Active Directory is that Exchange 2000 uses LDAP (Lightweight Directory Access Protocol) to access directory information. LDAP is the same protocol used for every other Active Directory query. Using a single unified protocol means that looking up information in Exchange 2000 is more efficient than looking up comparable information in Exchange 5.5.
In this article, I’ve discussed some ways that Exchange 2000 is integrated with Windows 2000. I also explained how Exchange benefits from this integration.