Overview

Deem integrates with Microsoft Exchange 2013 and 2016 using both forms-based and standard login authentication. It requires an Outlook Web Access (OWA) server. Travel and other services integrate with Exchange by logging in as a limited rights delegate account through the OWA interface using WebDav (Web-based Distributed Authoring and Versioning) over the SSL protocol, or using Exchange Web Services. As a result, calendar events are automatically added to the user's calendar as the user books travel, and contact information appears for quickly selecting an invitee or recipient of a service.

The following diagram illustrates how this integration works:

All communication is performed over SSL, ensuring that messages are not viewed or tampered with in transit. This is the same interface that is used and exposed for Outlook Web Access, and hence leverages the native security of that platform.

Deem uses a minimal permissions delegate account when performing groupware operations. This account only has permissions to create, update, and delete Deem-related calendar entries. This ensures that the user’s credentials are not required and never exposed. These credentials can be input directly by customer IT staff, and are encrypted both by the application, as well as the database to ensure secure storage. The delegate requires minimally invasive “Author Access” to user calendars. This allows for create, edit, and delete permissions only for calendar items that are authored by the delegate, not for other items. In addition, the delegate gets “Reviewer” read-only access for contact lookups. The delegate account can't update any user credentials.

Enabling Enterprise Groupware with Exchange

Note: Enterprise Groupware with Microsoft Exchange is a Premium Service and requires a separate agreement with Deem to be in place before configuration can take place. If you are unsure if your agency has this service included in your reseller agreement with Deem, please enter a support case (see Entering a Support Case for instructions).

Choose Exchange Web Services as the server type for Exchange 2007 or newer, or Microsoft Exchange (WebDav) as the server type for Exchange 2007 or older. Users access Exchange through their Outlook client application. This integration method offers calendar updates and can also be optionally configured for contact queries.

For instructions on setting up Microsoft Exchange integration, see Microsoft Exchange Setup.

Frequently Asked Questions (FAQs)

Our security protocols do not allow for the installation of 3rd party applications to be installed on our hardware. Can the permissions be applied without the use of the 3rd party application?

We do not provide support for any other means of applying the delegate permissions; therefore it is recommended that the Delegate Utility be utilized when applying the delegate permissions to the end users. You are however free to use your own method, as long as all of the appropriate permissions are set.

With regards to the "delegate account", does this account require any special permissions?

The delegate account is a permanent account, and is just a regular mail account (e.g. not an admin or with any other special powers). The delegate account must be able to send e-mail as well as receive e-mail from an external source. Make sure that the delegate account has a non-expiring password.

We have multiple Exchange servers. Is calendar/contact integration able to work with multiple Exchange servers?

Yes, however we need to have a means to differentiate the users on each Exchange server. Please work with your Deem integration manager to ensure the users can be differentiated.

If a calendar event fails to write to a user's calendar, is there a retry mechanism present?

A mechanism is in place that makes three additional attempts to write to the user's calendar. If there is a failure, the system calculates the delay between the moment of failure and the start time for the event. If this delay is greater than 36 hours, a retry is scheduled for 24 hours after the moment of failure. If the delay is less than or equal to 36 hours, the retry is scheduled for half of the difference between the moment of failure and the start time for the event, up to a maximum of 18 hours after the moment of failure. If the retry fails, the system calculates the delay between the moment of the retry failure and the start time for the event, and uses the same algorithm to schedule another retry. If the second retry fails, the system uses the same calculation and algorithm to schedule a third retry. Each actual retry occurs soon after the schedule for the retry.