Administering Office Add-ins within Exchange 2013 and Exchange 2016

I recently worked with a developer to deploy an Office add-in within an Exchange 2013 on-premises environment. This project highlighted a capability of Exchange and Outlook that is a huge shift in the way mail add-ins are developed, deployed, and maintained. Let's take a look at the key components of Exchange 2013 that support this capability.

Office Add-in Primer for Exchange Administrators

Office Add-ins, formerly termed apps for Office, is a platform that allows developers to use web-based tools to build apps that are displayed within the Outlook Reading Pane or inspector window. This function is native to Exchange 2013 and Exchange 2016. As an Exchange administrator, you have granular control over its use within the environment.

You can use the Exchange Management Shell (EMS) to display the relevant configuration settings.

Get-OrganizationConfig | Format-List AppsForOfficeEnabled

You will see that this functionality is enabled by default. Setting AppsForOfficeEnabled to $false will prevent new apps from being published by the user or Exchange administrator.

The Get-App cmdlet is a quick and easy way to list all apps that are available within your Exchange environment.

Get-App | Format-Table DisplayName,AppID,AppVersion,Enabled,DefaultStateForUser -Autosize

All native apps are enabled by default; this means the Exchange server will advertise them to the Outlook client. Whether they are displayed or not is determined by the configuration of the add-in. Outlook will only activate a contextual add-in if the activation conditions are met. For example, the Suggested Meetings add-in will only activate when Outlook detects a message that includes a reference to an event or meeting. Let’s say I receive an e-mail from a colleague that includes the text, "I would like to meet with you tomorrow after 3PM" .  This event would trigger the Suggested Meetings mail app to appear within the inspector window.

Office Add-In Components

Native apps are made available to your Exchange user community with no administrative effort, they just work! However, you can incorporate 3rd-party add-ins that extend the capability of messaging related applications. You can also publish add-ins that have been developed by your company's software development staff.  Add-ins that integrate with Outlook are referred to as mail apps.

The basic components of an Office add-in are an XML manifest file and a webpage. The manifest defines the basic logic of the add-in and points to the webpage that implements the app UI and custom logic. The Exchange server is responsible for storing and advertising the manifest XML file for mail apps. The Get-App cmdlet displays the settings from the manifest XML file. A snippet of the Suggesting Meetings mail app manifest is included below.

Get-App -Identity bc13b9d0-5ba2-446a-956b-c583bdc94d5e | FL DisplayName,Description,ManifestXML

I’ve omitted sections of the manifest to make the data a little easier to read. The key takeaways are the cmdlet syntax and some of the data points, such as DisplayName, Permissions, and Rule configuration. A full description of the Office Add-ins XML manifest can be found at the Office Dev Center.

The manifest only needs to be published once for your organization. The published XML data is stored in the SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} arbitration mailbox by default. Use the following cmdlet syntax to confirm your environment is using the default mailbox for storage of the manifests.

Get-Mailbox -Arbitration | Where-Object {$_.PersistedCapabilities -like "OrganizationCapabilityClientExtensions"} | Format-List Name,PersistedCapabilities

Hopefully this information helps with your understanding of how Exchange enables the advertisement of Office add-ins. Outlook 2013 and newer clients are programmed to automatically read the manifests on startup. As users view or compose items in Outlook, their operations are checked against the activation conditions of the mail app. Outlook displays the app when the conditions are met. Mail apps can also be set to mandatory, which means they are always displayed by the client.

David Craig, Office PFE, recently published an article titled Developing an On-premises Web Add-in. I recommend bouncing over to his blog if you are interested in learning how to code Office apps for on-premises scenarios.