Exchange administrative tools and Active Directory: Not as close as they once were

When Exchange became the first front-line server application to embrace Active Directory with the release of Exchange 2000, Microsoft provided the functionality to allow administrators to work with the Exchange-specific attributes for mail-enabled objects through the then brand-new AD Users and Computers console. When the Exchange management tools are installed on a server, three tabs are added to AD Users and Computers to display attributes grouped under Exchange General, Exchange Advanced, and Exchange Features. The integration eased the movement from the older Exchange 5.5 administration model and hid some of the perceived complexity of dealing with Active Directory.

Up to and including Exchange 2003, you were able to create, modify, or delete Exchange mailboxes, distribution groups, and contacts from AD Users and Computers because the installation of the Exchange management tools adds the components such asmaildsmx.dll to the system to enable the display specifiers that expose the Exchange attributes and tasks in the console. It was also possible to make the Exchange tabs available to AD Users and Computers without installing the full set of the Exchange management tools.

Microsoft removed the ability to manage Exchange recipients in AD Users and Computers in Exchange 2007, largely because of the advent of PowerShell and the decision to consolidate Exchange business logic in the set of PowerShell cmdlets that are called by the Exchange management tools. AD Users and Computers doesn’t use PowerShell, so it made sense to remove its ability to create or delete recipients, even if this decision infuriated many administrators at the time because they now needed to use two tools to work with mail-enabled objects.

The demand to support a clear separation between Active Directory management and Exchange management is another reason why Exchange disappeared from AD Users and Computers. Small deployments probably have one or two people who do everything and the notion of separating responsibilities for managing Active Directory and Exchange doesn’t have much value. Things are more complex in large enterprises and that’s why Microsoft supports a split permissions model in Exchange 2010 and Exchange 2013 that is, in turn, based on Role Based Access Control (RBAC). A split permissions model is relatively uncommon but is extraordinarily useful to those who need to use it.

Apart from the last lingering vestige in the form of the much-reduced Exchange Toolbox, Exchange 2013 does not use MMC. Instead, the browser-based Exchange Administration Center (EAC) takes center stage for both on-premises and Exchange Online deployments.

Given the influence of cloud services over much of software engineering today, a transition to browser-based tools was inevitable. I didn’t like EAC very much when I first started to use it but now consider it to be as good as EMC in most respects and better in some. Sure, EAC still misses out some of my favorite EMC features like the PowerShell learning tools, but you don’t need to install any software to use EAC as it runs on just about any browser-capable device that can support a modern version of IE, Chrome, Firefox, or Safari. EAC is also quicker at dealing with large numbers of mailboxes and other objects than EMC ever was and includes new useful functionality like Administrator Alerts.