Exchange Server 2013 : Mail Apps for Outlook and the Outlook Web App

An exciting new feature in Exchange 2013 is mail apps for Outlook, which replaces both add-ins for Outlook and OWA web forms. This feature allows you to build customized applications with a consistent user interface across Outlook and OWA. This was very difficult to achieve in previous versions of Exchange. Currently, this feature is still in its infancy, so there is a limited subset of functionality at RTM. However, as service packs are released, the feature set is expected to grow toward parity with what is available via Outlook add-ins today. Outlook mail apps are only supported in Outlook 2013 and the Exchange 2013 Outlook Web App. For older versions of Outlook you still need to use Office add-ins to provide customization. If you currently have a custom Office add-in for Outlook, this will still be supported in Outlook 2013. However, any custom Outlook web forms that you have in Exchange 2007 or Exchange 2010 will need to be migrated to a mail app to run with the Exchange 2013 OWA.

How Mail Apps Work

Mail apps display within a special application box in the currently viewed Outlook item, such as an email message, meeting request, meeting response, meeting cancellation, or appointment. Figure 1 shows the Bing Maps app displayed within a message in OWA.

FIGURE 1 The Bing Maps app showing in-line with a message in OWA

This app is activated when an address is detected within a message. A mail app can be identified and activated based on certain strings, referred to as entities, in the subject and body of the current Outlook 2013 or OWA item. These entities can include addresses, contacts, email addresses, meeting suggestions, phone numbers, task suggestions, and URLs.

Mail apps can call third-party web services, as shown in Figure 1, which uses the Bing Maps web service. They can also use EWS to access more information on the current item or other items that are stored within an Exchange mailbox. Mail apps have activation rules that control when they are displayed in messages. For IT professionals, you can think of these activation rules like the Inbox rules that have been around in Exchange since its inception. An activation rule can mean that an app is shown only when mail is received from certain users, with specific text in the subject or body, or is of a particular item type.

Mail apps are built on top of the new Office apps customization framework introduced in Office 2013. Apps can be published to the Office store, Exchange catalog, or other web server. If they are published to the Office store, they can be sold or provided free to a worldwide audience. A permissions framework controls what an app can do, and certain applications can be installed and enabled only by administrators. The ability for users to install and enable third-party mail apps can also be controlled via policies.

A mail app consists of an HTML web page and its associated JavaScript files that are hosted inside the email client. Three email clients offer support for mail apps in Exchange: Outlook 2013, Outlook Web App (OWA), and the Outlook Mobile Web App (Exchange 2013 only). How mail apps execute at runtime differs, depending on the email client you're using. For example, with the Outlook desktop client, the app web page is hosted “out of process” inside a web browser control. Out of process means that the app doesn't run within the Outlook process space. Instead, it runs within a web browser control inside Outlook's apps for the Office runtime process. The advantage of doing it this way is that it provides security and performance isolation for the app's code, which stops a malfunctioning app that affects the operation of Outlook. The app for Office runtime translates the JavaScript API calls and events from the mail app's code into native calls, and it is also responsible for rendering the app's output inside any Exchange item that meets the app's activation criteria. How the application renders and the size of the application box are also controllable using the application's manifest file.

A mail app is installed using the XML manifest file for that particular app, which defines various settings for the mail app. The XML manifest for a mail app contains the following information:

• A unique GUID that identifies the application and the app's display and icon names.
• Details of the application provider and version number.
• Activation rules that determine under what conditions the apps will be shown.
• Scopes of support for the application and the location of the app's HTML file for different platform types. This lets you have separate application files and size settings depending on platform type, that is, desktop, tablet, or mobile form factors.
• The permissions that the mail app requires.

All of the files associated with a mail app need to be hosted on a web server that is accessible by the Exchange 2013 CAS role server.

JavaScript API for Office

One of the critical components for mail apps is the JavaScript API for Office, which includes objects, methods, properties, events, and enumerations that can be used in mail apps in Outlook 2013. A mail app's HTML file should reference this file from the Microsoft Content Delivery Network (CDN), accessible at

Or you can host this file along with your application. For example, your mail application's HTML file would include the following line to load the Office JavaScript API:

Permission Levels in Mail Apps

A three-tiered permission model is used within mail apps that determines what resources a particular mail app can access, what the app is capable of doing, and under what conditions the app will execute. The permission level is configured in the application's manifest file, and if it's not specified, the Restricted permission level is applied. Table 1 outlines the three permission levels.

TABLE 1: Mail app permission levels

Using Exchange Web Services within Mail Apps

To use Exchange Web Services within a mail app, the application must first request the ReadWriteMailbox permission in the application's manifest file. To make an EWS request, the makeEWSRequestAsync method of the Mailbox class in the JavaScript API for Office is used. As the name implies, the request is made asynchronously and a callback is used to deal with the results. Currently, only a subset of the available EWS operations can be used within mail apps. If you try to use a restricted operation, an error will be returned. Table 2 lists the available EWS operations in mail apps.

TABLE 2: EWS operations available in mail apps

Getting Started with a Mail App

The Exchange development center hosts a number of mail app samples to get you started. As a primer, we suggest, “How to: Create your first mail app for Outlook by using a text editor,” which can be found at: http://msdn.microsoft.com/en-us/library/fp161148.aspx. This takes you through a fully working example of a mail app.

Installing a Mail App

Installing your mail app is a rather straightforward process. Depending on the permissions required by the application, mail apps can be installed by the user via EAC in Outlook or OWA. Apps that require readItem or ReadWriteMailbox permissions need to be installed by an administrator via the EAC or the EMS using the New-App cmdlet, as shown here:

Mail apps can also be installed from the Microsoft store by users, but these apps can only specify the Restricted permission set.