Understanding the New Administrative Architecture

The Exchange 2003 administrative architecture has many shortcomings. The most noticeable is that automating or scripting most administrative tasks is difficult, to say the least. An administrator may need to understand two or more scripting interfaces or application programming interfaces (APIs), such as Active Directory Services Interface (ADSI), Collaborative Data Objects (CDOs), CDO for Exchange, CDO for Exchange Management, Exchange Windows Management Instrumentation (WMI) classes, and others.

While the Exchange 2000/2003 Exchange System Manager (ESM) console (shown in Figure 7.1) is not the most difficult interface to use in the world, administrators frequently complain that it is difficult to actually find the objects that might need to be configured and the tasks that can be performed against each object.

Figure 7.1: Exchange System Manager console for Exchange 2000/2003

A common complaint among Exchange administrators is that the ESM interface objects are often buried seven or eight levels deep in the ESM hierarchy. Administrators also complain that leaf objects appear in the tree pane and tree objects appear in the results pane of the interface.

While some of the configuration tasks are performed directly against the Active Directory and can be duplicated with an ADSI script, other tasks are performed against the Registry, Exchange components, the file system, or indirectly against Internet Information Server (IIS) components. Thus, many of the tasks that are performed in the ESM become extremely difficult to automate or script.

The need for a better and more consistent interface for managing Exchange server objects, Exchange tasks, and mail recipients had to be developed. The management interface had to be capable of managing a combination of Active Directory objects (Exchange configuration and recipient information), Registry settings, file system components, IIS components, Windows services, and Exchange components. The new interface had to provide a consistent interface for managing Exchange and allow for easier scripting and command-line management.

About the same time the Exchange team started working on a new management interface, the Windows team was designing a new shell and scripting interface for Windows. This shell (originally code named Monad) is called the Windows PowerShell. The PowerShell is a completely redesigned command-line interface (CLI) for Windows that may eventually replace the traditional command prompt that we are all used to.

The Exchange team decided to provide access to the Exchange management functions through the Windows PowerShell. All objects that would need to be manipulated by an Exchange server administrator were defined (such as mailboxes, mailbox databases, distribution groups, etc.) and then the actions that might be taken against these objects were defined (such as enable, set, get, mount, test, etc.).

From the objects that would need to be manipulated, and the actions that would need to be performed on these objects, a series of tasks (or actions) were defined. This is the underlying Exchange administrative model as shown in Figure 7.2.

Figure 7.2: Exchange 2007 administrative architecture

Exchange tasks are given access to differing types of data and components relating to Exchange through the Exchange Management API. These tasks, or cmdlets (pronounced "command-lets"), can be accessed via the Windows PowerShell and the Exchange Management Shell (EMS) or through the Exchange Management Console (EMC). EMC interacts with the EMS tasks through the WinForms and PowerShell data providers. All of the EMS tasks are exposed as .NET classes and could also be accessed and used through applications written with the .NET Framework.