Share via

Inside the Exchange 2010 Web Management Interface – Part I

  • Article

It has been a while since my last post, as I was finishing up work on the upcoming Exchange 2010 Web Management Interface, internally known as the “Exchange Control Panel” or simply ECP, so it seems fit to give you a peak of what is inside the hood.

Exchange Control Panel is a web application designed to provide self-service management of Exchange features to end-users and administrators alike.

For the end-user, ECP appears as the OWA Options page, where one goes to customize a number of settings, like Inbox Rules, Out-of-Office and Voice Mail settings – you can see a complete list in this online help topic. ECP is also integrated with Outlook 2010 in the sense that the UI for certain options in Outlook are in fact implemented by the ECP application.

ECP lights up additional options when a user with administrative permissions logs in and presents options such as management of mailboxes, groups and external contacts as well as other scenarios like Reset Passwords, Delivery Reports, configuration of mailbox service plans and user roles, all according to the user’s rights specified by Exchange’s Role Based Access Control (RBAC).

ECP Architecture

ECP is designed as an ASP.net AJAX application, built on top of business logic provided by the Exchange PowerShell cmdlets and using WCF web services and JSON to communicate between the client application and the server application.

The client side of ECP runs in multiple browsers while the server side runs in Windows 2008+IIS7, in an Exchange server setup as a Client Access Server.

ECP uses the same PowerShell cmdlets available in the command line interface, keeping our motto that ‘anything you can do in the UI, you can do in the command line’ . The same set of RBAC permissions controls what a user can do in PowerShell and in the ECP UI.

From a logical point of view, ECP is divided in three parts:

  • Common Infrastructure
    Several pieces that make ECP work are part of a common infrastructure shared with other Exchange applications, like Outlook Web Access (OWA) and Exchange Management Web Service (EMWS). These include things like Live ID authentication, RBAC, PowerShell and more mundane things like tracing, performance counters, event log, etc. Several teams work with this code one way or another.

  • ECP Application Infrastructure
    ECP itself provides an infrastructure of common controls, scripts, services and resources necessary to build Exchange features. There's usually nothing too particular to Exchange itself in this code as one could use it to build other types of applications with it. Infrastructure code can be simple or complex depending on the needs of all features that use it. It eventually stops growing as it meets the requirements of all features. The idea is that only the ECP team deals with this code.

  • Feature Code
    Finally, in ECP there are pages and controls that implement one particular feature of Exchange. This is the part of ECP that grows over time, as more and more features are added to it. The idea is to make writing feature code so easy that we can let component teams write their own feature UI, just like they build their own cmdlets. In most cases, feature UI in ECP boils down to a list view or a form, with web services used as data source.

Physically, ECP code can be divided in four main groups:

  • Server Controls
    Server-side controls written in C# gives us the necessary functionality and abstractions that simplify the creation of markup files. They are part of ECP's Infrastructure.

  • ECP Client Library
    The ECP client-side application is written in Script#, compiled into JavaScript and executed on the browser. For the most part it is all Infrastructure code although complex features have scripts of their own.

  • ECP Web Services
    A set of C# WCF web services with JSON behavior provide the client library with the necessary entry points to invoke cmdlets in the server. Each feature provides its own data contracts and the final web service code, which is implemented with the help of base classes provided by the Infrastructure.

    NOTE: the web services endpoints exposed by ECP are not regarded as public API and serve only the needs of the ECP application – they are not to be used as a general programming endpoint as their requirements can change from version to version. Applications that wish to call Exchange management functions remotely must use Remote PowerShell.

  • UI Markup
    ECP UI is built with ASPX and ASCX markup files, where we define the controls to show, the web service that provides data for the page, client side data-bindings and the RBAC permissions required by each control.

    The markup pages are divided in the following groups:

    • Infrastructure pages provide the main frame and a set of error pages for the application.
    • Feature List View pages, shows a list of objects and their associated commands.
    • Feature Form Pages, shows a form where users can edit the properties of an object.

In most cases feature-specific pages do not require any additional code-behind, since all the heavy lifting is done by the infrastructure controls, either on server code or client code.

 

The following diagram gives us a high level view of how the pieces come together to form ECP:ECP Architecture

The ECP client library and the Microsoft AJAX framework run in the client browser.

Browser requests are handled by IIS and are authenticated with either Windows Live ID, Windows or OWA’s Form Based Authentication, depending if we are in a datacenter or in an enterprise deployment.

After the request is authenticated we build the user session, where we keep track of the user settings and in particular of the user’s permissions. At this point we can authorize the request.

Requests for UI components is handled by the ASPX handler of each page. Feature pages and application wide pages (such as default.aspx and error.aspx) rely on the server controls infrastructure to render the proper HTML and JavaScript to be executed by the browser. RBAC is involved to hide portions of the UI that the user does not have permissions to use, or to make them read-only.

Web service calls are handled by the respective WCF service, exposed by a JSON end-point. Each specific feature provides its own web service with a set of well-known contracts understood by the server controls and the client library. While the contracts are generic, allowing each feature to control exactly what comes in and what goes out in each web service call, all features look and behave the same, allowing a single set of controls to work seamlessly across all features.

The feature web services uses infrastructure code to translate data between WCF data contracts and PowerShell cmdlets, to invoke the respective cmdlets and to return data from PowerShell to the client application to consume. RBAC is involved to restrict access to just the cmdlets and parameters that the user has access.

Once the request reaches cmdlet code the operation is persisted in the system by the appropriate business logic.

 

Summary

  • Exchange 2010 Web Management Interface, aka, Exchange Control Panel is an ASP.Net application running in an Exchange Client Access server.
  • Uses ASP.net to render HTML UI.
  • Uses Script# to compile C# into JavaScript.
  • Client code runs in multiple browsers.
  • Uses WCF+JSON to respond to web service calls from the client application.
  • Uses RBAC to control what users can see or not in the application UI and what cmdlets and parameters can be used in web services.
  • Uses Exchange PowerShell Cmdlets to execute business logic.

In future articles we will look at those individual pieces in more details.