1999 seems such a long time ago now, but that's when many of us first faced the need to deploy Active Directory (AD). For many companies, the need arose because Microsoft replaced the Exchange Directory Store (DS), used for Exchange 4.0 to 5.5, with Active Directory in Exchange 2000. The DS was very much like AD. Both have their heritage in the X.500 directory standards (but are not X.500-compliant directories) and both use Jet databases as their underlying repository. Indeed, it can be argued that the DS provided an excellent testing ground for AD before AD was launched.
Because of the change from the DS, the planning for Exchange “Platinum” involved complications such as the deployment of Windows 2000 to replace Windows NT 4 and implementation of the Active Directory Connector (ADC) to link the DS with AD. Add in a touch of Y2K madness. It was a fun time.
AD has remained a critical component for Exchange for over fifteen years. The good news is that we have lost the fear that once existed of AD replication, largely because of better networks and better software. We fear schema updates less too. Enormous planning seemed to be needed whenever an application like Exchange needed to extend the AD schema to accommodate new objects or attributes. I think this was due to the combination of a lack of AD knowledge and concerns about fragile AD replication. Today, every cumulative update for Exchange 2013 and Exchange 2016 seems to involve a schema update (to accommodate things like RBAC changes) and we don’t bat an eyelid.
AD is important to Exchange for two major reasons. First, Exchange stores the majority of its configuration data in AD. This sentence should read “all of its configuration data” but Exchange persists in holding some information in the system registry, perhaps because it’s faster to access, but probably due to a certain lethargy in updating code so that all configuration data is held in AD.
Using a single repository for configuration settings seems to make sense, apart that is from server-specific information such as the watermark used to capture the state of installations. To be fair to Microsoft, much more of Exchange’s configuration is stored in AD than ever before, so I hope that this trend continues.
Exchange also uses AD as its source of information about user accounts, groups, and contacts. I guess that this is the use that comes to mind most readily as it’s the obvious progression from the old DS to AD.
One thing that hasn’t changed is the need to do careful planning for AD before you begin a green-field Exchange deployment. Correcting AD errors, like suddenly finding that you want to change the name of the domain (for example, from Contoso to Fabrikam) or the Exchange organization is not supported. There’s a good reason for this – every single AD object has a distinguished name (going back to X.500) that contains the organization. Thus, renaming a domain or an organization requires massive upheaval within AD with the added complication that all of the changes have to be replicated to every domain controller.
Renaming core components is something that might work perfectly in a small lab environment where you have a few domain controllers connected by a high-speed network. It’s quite another matter when you face a world-wide deployment composed of radically different links from gigabit connections down to pieces of string. So the Exchange development group has taken the logical and reasonable position that you should get your planning right before deploying AD and then Exchange. If you mess up, you have to start over.
Microsoft has a utility called LegacyDN that could be used to rename an Exchange 2000 or Exchange 2003 organization, but note the caveat that says “We support using the Legacydn.exe tool only in a lab environment. The tool works only in an environment that uses a single domain controller.” In other words, you could possibly use LegacyDN to fix things in a small organization if you realize that you had made a mistake soon after installing the first server. Microsoft also provides the “domain fixup tool (XDR-Fixup)” for Exchange 2003 for use when using the Active Directory domain rename feature, again cautioning that “It is extremely important and highly recommended that you test the domain rename operation before you perform it in a production environment.”
Only DNS domain renames were possible. It has never been possible to rename the NetBIOS name for a domain. And of course, it might be possible to adjust everything so that Exchange would be happy with what it read from AD, but you could never guarantee that renaming a domain wouldn’t screw up other applications or third-party utilities.
In any case, you can’t use these tools against Exchange 2007, Exchange 2010, Exchange 2013, or Exchange 2016. They belong to a time when everything was so much simpler than it is with today’s rather more complicated servers, largely because so many links connect different objects, such as databases to Database Availability Groups.
But who cares about renames anyway? After all, even the company name changes due to a merger or acquisition, AD is something that hums away in the background and is never seen by users. Administrators might fret that their organization has a funky name, but users won’t care as long as they can log in and authenticate and that their email address is representative of the company.
If you wanted to, you could have an AD deployment called “FuzzbagWhallop” (an excellent name) but then assign User Principal Names (and SMTP addresses) to user accounts via email address policies for @NiceDomain.com or whatever domain you need to use. Everyone wins.
Unless Microsoft makes a huge and fundamental change in its technical strategy for Windows, you can assume that Exchange and Active Directory will continue to work in tandem. The partnership has been pretty good for the last sixteen years. Who knows what might happen in the next.
Follow Tony @12Knocksinna
