This article provides the latest best practice configuration of the Poly One Touch Dial (OTD) Service when used with resource mailboxes stored in Exchange Online.  It does not matter if the room mailboxes are used by Poly or Cisco video conferencing systems as while the actual endpoint configuration may differ slightly, the initial access configuration and calendar integration for the service is the same for all supported device capable of displaying a Join button for scheduled meetings.

Background

Currently there are three different methods to configure the OTD service for access to Exchange Online:

1. Automatic registration – uses pass-through authentication with the mailbox or impersonation account.
2. As a Service Account – uses proxy authentication with a dedicated service account through an Azure Enterprise Application.
3. As an Application – uses proxy authentication with the application’s own identity through the same Azure Enterprise Application.

Previous guidance was to use the automatic registration approach with most Poly endpoints or the dedicated service account model with supported Cisco endpoints.  The third option uses the identity of the Enterprise Application but this model was seldom deployed due to the excessive scope of mailbox access that is requested.

This article flips all of this completely around as the previously most common configuration scenario will soon become defunct and what used to be the least attractive model now becomes the configuration of choice thanks to some new access control capabilities from Microsoft.

New Developments

While most of the behavior of the OTD service explained across the articles linked above is unchanged there are two important events which have now shifted best practices to a different configuration method when leveraging Exchange Online.

1. The automatic registration model for Poly endpoints using pass-through authentication leverages Basic Authentication in Exchange Web Services. While this model is commonly used due to its simplicity and is still functional at the time this article was written it will cease to be viable due to Microsoft’s planned deprecation of Basic Authentication from Exchange Online.  Both the service account and application access models already support Modern Authentication due to the use of the same Microsoft Graph-based Azure enterprise application.  Thus, it will be required to shift any existing OTD configurations using pass-through authentication over to the service account or application identity models before those events occur.  It is highly recommended to no longer use automatic registration in any new deployments.  Any organization setting up the OTD service with Exchange Online for the first time now should use the application identity model outlined in this article. 

2. The configuration method shown later in this article is not entirely new as it leverages the same Enterprise Application access model which has been available since the launch of the OTD service, but as mentioned above this approach was never recommended. The application in this model requests read access to all calendars for an organization which are stored in Exchange Online.  That is much too large of an access scope for most organizations to approve.  Normally the service account model would simply be used instead, but it is more complicated to setup and burdensome to maintain by comparison.  Earlier this year Microsoft introduced the ability to control the scope of mailbox access in Exchange Online to approved application by providing new access policies.  This additional granularity now allows an organization to easily limit access to specific mailboxes instead of all mailboxes, making this approach a preferred alternative to managing service accounts and individual mailbox permissions.

Service Account vs. Application Identity

These changes do not mean that the service account model is no longer viable though. In most cases is perfectly fine to utilize a service account to control permissions instead of the application access model.  The same effective amount of access required by the OTD service can be granted using either model and the end result will be no different.  So, while the level of permissions (read access to only calendar data) is the same in both models it is the object scope of those permissions (which mailbox calendars can be accessed) that is up to the organization to control.

In fact both of these models actually utilize the same third-party Enterprise Application, but it is only how the access is applied which differs.  In the service account model the application presents the stored credentials of an assigned service account when connecting to Exchange Online, meaning that the app only has access to the Exchange resources that the service account has been granted permissions to by an administrator.  In the applications access model though the app is using its own identity to connect to Exchange Online and will by default have rights to every object which is applicable to the granted permission(s).  Because the application only asks for read permissions to calendar data then that is all that Exchange Online will allow it to access, but the scope of access by default includes every single mailbox in Exchange Online.  This is where the new application access policy is used to further limit the scope of access to only the mailboxes allowed by the administrator.

When approving the Enterprise Application permissions request for the service account method only user consent permissions are required as the app will operate within the context of the service account, which is a regular Azure AD user account.  (If user-level app consent permissions have been disabled in the M365 tenant then there are alternative methods to completing this for the service account configuration.)  Alternatively, if approving the permissions request for the application method this will require admin consent duties which are only available to the Global Admin role or a few other application-level admin roles.

The practical differences between the two models is that the application model is simpler to initially setup and offers a much nicer method of adding or removing permissions to desired room mailboxes.  The service account model requires the use of Exchange Online PowerShell cmdlets to manually delegate mailbox folder permissions each time a new VTC resource mailbox is added.  Yet, in the application identity model a mail-enabled security group can be created (or a compatible existing group used) to add each room mailbox to.  Then an access policy is created to restrict access to only the members of this specific group.

Topologies

Understand that the changes described above only impact an environment using Exchange Online for room mailbox storage.  In Exchange Server or Exchange Hybrid deployments the original configuration guidance is unaffected.

When deciding which calendar integration option(s) to configure it is important to understand that the OTD service only accesses the resource mailbox used by the specific endpoint.  It does not matter where user mailboxes are stored as it is irrelevant as to who is scheduling meetings.  This means that the service only needs to connect to the Exchange environment where room mailboxes are stored.  For example, look at an Exchange Hybrid deployment where all room mailboxes tied to a physical video conferencing system are stored in Exchange Online, yet the rest of the organization’s user mailboxes were all located on an Exchange Server or even scattered across both Exchange Server and Exchange Online. In this scenario the OTD service still only needs to be connected to Exchange Online.

Thus, the guidance for which type of OTD calendar integration to use is not directly based on the Exchange architecture in place, but instead where the desired resource mailboxes are collectively stored.

• All rooms stored in Exchange Online – use the application identity model with Office 365 calendar integration.
• All rooms stored in Exchange Server – use the service account model with Exchange calendar integration.
• All rooms stored in Exchange Hybrid – use the service account model with both the Office 365 and Exchange calendar integrations*.

Remember, if the organization is leveraging an Exchange Hybrid deployment but all room mailboxes tied to a VTC are stored in only one Exchange location then that is the only location that OTD needs to be be configured for, meaning that most deployments will leverage one of the first two models.  In the example of a migration from Exchange Server to Exchange Online a typical configuration may start with a dual service account configuration for Hybrid and then once all room mailboxes have been moved to the cloud the Exchange Server integration can be removed.  And then, if desired the Exchange Online integration could be disconnected and reconnected to transition from the service account to application model for simplified future management.

* Supporting an Exchange Hybrid topology with the OTD service where VTC resource mailboxes are stored across both Exchange Server and Exchange Online requires a special configuration using two separate service accounts leveraging two different domain namespaces.  This configuration may be covered in a future blog article.  An alternative deployment option would be to leverage the OTD service for room mailboxes stored online and the on-premises Poly Workflow Server (WFS) for room mailboxes stored on Exchange Server.  The WFS option is also required for Exchange Server deployments which do not publish Exchange Web Services externally to the Internet.

The remainder of this article outlines the step-by-step procedure to configure permissions in Exchange Online, configure the OTD service, and then setup a single Poly video endpoint to use the service for calendaring.

Mailbox Configuration

When the OTD service is being introduced into an organization there are typically one of two scenarios involved, both of which have in common the fact that the resource mailbox already exists.  One scenario is that a new endpoint has been put into a physical room which already had an Exchange resource mailbox created for the simple purposes of booking the room in Outlook.  The other scenario is that the endpoint was already deployed and configured in the room and is already using the resource mailbox for calendaring purposes of some sort.  Yet in either scenario the Exchange calendar processing rules may not be correctly configured to work with the OTD service, or any conferencing service for that matter.  In the event that a new resource mailbox is created specifically for an endpoint the same problem often arises as the default calendar processing rules in Exchange are not compatible with how the meeting invitation needs to be handled for most conferencing platforms.

To avoid problems from the beginning make sure to review the configuration requirements outlined in the article Exchange Resource Mailbox Configuration for Meeting Rooms, paying special attention to the DeleteComments parameter.  If the Join button does not appear for a supported meeting invite on an endpoint which is seemingly configured correctly for the OTD service then the overwhelmingly most common reason for this is that the resource mailbox is still configured to delete the body of all email messages it receives.  This causes the critical meeting details to be missing from the invite and when the OTD service inspects the meeting invitation to finds nothing to process.

Configure Resource Mailbox

The configuration used in this article leverages an existing resource mailbox.

• Connect to Exchange Online PowerShell, ideally using the new v2 module.

• Use the Get-CalenderProcessing cmdlet to check the current configuration of the desired resource mailbox .

Get-CalendarProcessing -Identity x50@msteams.net | fl Add*,Delete*,Remove*

Note that the resource mailbox in this example is properly configured including the critical DeleteComments parameter being set to False.

• If though this happens to still be set to the default value of True then use the following command to resolve this.

Set-CalendarProcessing -Identity x50@msteams.net -DeleteComments $false

Access Control

As explained earlier the new application access policies available in Exchange Online offer an opportunity to vastly limit the scope of objects that the OTD service can access.  It is recommended to create this access policy before approving the application’s permissions request.  It can also be performed afterwards, but just be aware at when doing so there could be a brief period of time that the application technically has access to all online mailboxes in the tenant.

Configure Group

Before creating the access policy a mail-enabled security group must first be setup.  If one already exists in the organization which happens to include the desired resource mailboxes as members then this section can be skipped.

• Sign in to the Microsoft 365 admin center with the appropriate administrative account and then navigate to Groups > Active Groups.

• Select Add a Group and then choose Mail-enabled security.

• Enter the desired Name (e.g. VTC Mailboxes) and Description for this new group.

• Enter the desired email alias in the Group email address field and select the preferred SMTP domain from the drop down list (e.g. vtc_mailboxes@msteams.net).

It is highly unlikely that external SMTP senders should be able to send messages to this group so the checkbox under Communication should be left blank.

• Once complete refresh the Active Groups list to verify the new group.  (It can take several minutes before it may appear.)

• Open the new group and then select Members > View all and manage members, then select Add Members.

• Search for resource mailbox used by the first endpoint which will be configured to use the OTD service (e.g. x50@msteams.net).

If desired add any other room resource mailboxes to this group which are associated with any video endpoints which may also need to leverage the OTD service.  In this example two additional mailboxes have been added as members to the new group.

Create Access Policy

The New-ApplicationAccessPolicy cmdlet is a newer Exchange Online PowerShell cmdlet which will be used to define the policy used to control access to the not-yet approved enterprise application.  Before running the new cmdlet though it would be prudent to take a closer look at the required settings and behavior.

AppID – The value used for this parameter needs to match the globally unique Application ID assigned to the enterprise application which is to be restricted.  (The Polycom One Touch Dial Service application’s ID is “500e702f-0145-4462-b2a6-d00e35b92d45”.)

PolicyScopeGroupId – One of several different unique identifiers can be used for this parameter to define which mail-enabled security group the policy will use for access control.  Currently supported string values include: Name, Distinguished Name, Display Name, Email address, and GUID.

AccessRight – This parameter controls the behavior of the policy essentially allowing the associated group to either be used as a whitelist (RestrictAccess) or a blacklist (DenyAccess).  In most cases the number of room mailboxes would be a small amount of the overall mailboxes in an organization, thus a whitelist approach would most commonly be used.

Description – an optional descriptive field used to identify to administrators the intended purpose of this access policy.

• Use the following command to create the new application access policy to restrict access allowed for the Poly app to only the members of the desired group (e.g. vtc_mailboxes@msteams.net).

New-ApplicationAccessPolicy -AppId ‘500e702f-0145-4462-b2a6-d00e35b92d45’ -PolicyScopeGroupId ‘vtc_mailboxes@msteams.net‘ -AccessRight RestrictAccess -Description "Restrict Poly OTD Service app to only members of the VTC Mailboxes group"

• The following command can be used to double-check the current membership of the provided group.

Get-DistributionGroupMember -Identity ‘vtc_mailboxes@msteams.net’

Now when the application permissions are granted in the following section then the only mailboxes it will be able to access are those listed above.

Calendar Integration

Now that the Exchange Online environment has been successfully prepared the OTD service configuration can begin, which starts with signing into the OTD administration portal and integrating the service into Exchange Online.

The steps in this section include application permissions requests for two different enterprise applications leveraged by the OTD service, as documented here.

1. Polycom One Touch Dial Portal – This application is used to authenticate an Azure AD user account for access to the OTD administration portal.  This app is only used for management of the service and is not used by the service for any other functionality.  When connecting to the OTD administration portal a request prompt will automatically appear for this app unless it has already been approved either by the individual user signing in or by an administrator on behalf of the entire organization.

2. Polycom One Touch Dial Service – This application is what is actually used by the service to connect to Exchange Online and request access to mailbox calendar data.  The permissions request prompt for this app will occur during the one-time calendar integration process and can only be approved by a user with either the Global Admin role assigned or another administrative role capable of providing consent to approve application request (Application Admin, Cloud Application Admin, and Application Developer roles).  (This is the same exact application used by the service account model, yet with a slightly different level of permissions requested.)

If desired it is supported to remove the Portal application from Azure AD after the OTD configuration is complete, understanding that access to the OTD administration portal will not be possible until the application is re-approved.  But, the Service app cannot be removed from the tenant otherwise the OTD service will lose all granted permissions to the tenant and will no longer be able to function.

Access OTD Portal

In order to provide access to the OTD portal a single administrator account would have been enabled by Poly based on the primary contact email address provided when purchasing or trialing an applicable service.  If additional users in the same Microsoft tenant need to be added as administrators for the OTD service then this article covers the steps to accomplish that.  Any valid Microsoft user account in the same tenant can be assigned OTD admin rights, there is no requirement for the user account to have any elevated rights in the actual Microsoft tenant.

• In a web browser go to https://otd.plcm.vc and then select Sign In.

• Select Sign in with Microsoft.

• Sign in with a valid Microsoft 365 user account (e.g. jeff@msteams.net) which has been granted administrative access to the OTD service as described earlier.

In order to sign-in to the OTD administration portal using a Microsoft account the Polycom One Touch Dial Portal enterprise application needs to first be approved by the user. 

• Select Accept on the application permission request window.

If the user also happens to have sufficient administrative rights in the Microsoft tenant to consent to these requests on behalf of the organization then the request may also display that option.  This is not necessary to select that checkbox and doing so would simply suppress this prompt from appearing for any other users in the tenant who may also later sign into the OTD administration portal.

Once successfully signed-in the Dashboard view should appear with a welcome message.

If the account has not been enabled by Poly as an OTD administrator then the following message will appear stating “You have not been granted access to One Touch Dial.  Please contact Poly support.”  If unable to connect with any account then contact support to resolve this issue.

Connect to Exchange Online

With access to the OTD administration portal the first configuration step is to integrate the service with Exchange Online.

• Select the Connect button in the Office 365 section

• Choose Connect as Application.

Note the highlighted text above stating that using the Application method “Requires a global admin of the tenant to complete” the process.  This does not mean that the user account signed into the OTD portal needs to be a global admin, only that a global admin (or another account with the sufficient admin role assigned) is available at this step to enter admin credentials to approve the pending application permissions request.

• Select or enter the account credentials of a user with the Global or Application admin role.

At this point a permissions request will appear for the Polycom One Touch Dial Service application.

• Review the request and choose Accept.

Note that the permissions requested include the right to “read calendars in all mailboxes”.  This is the level of permissions the app was written to request and it is unaware that a policy already exists which effectively reduces the scope of that permission.  So, understand that even though that is what the request states and ultimately is being approved, the defined application access policy overrides the functional behavior to limit access to only the desired mailboxes.

After accepting the request the portal should refresh and report the current integration status for the Office 365 option as “Configured as an application” along with options to Test or Reconnect the integration.

• Select the Test link and then enter the email address of a mailbox which is currently a member of the group used earlier to configure the application access policy (e.g. x50@msteams.net) and then click the Test button.

The test results above should complete successfully, indicating that the OTD service has the sufficient read permissions to the calendar folder of the mailbox.  To further validate the configuration attempt to connect to a mailbox which is not currently a member of the allowed security group.

• Change the email address to a valid mailbox in the Exchange Online tenant which is not a member of the assigned group (e.g. jeff@msteams.net) and then click the Test button again.

As shown above the test should fail as the application is not allowed to connect to mailboxes which are not members of the configured group.

Add Secondary Domains

An important behavior to understand is that by default only a single domain namespace is enabled in OTD per tenant, which would be the domain provided when ordering licenses for the service or another companion service (like RealConnect).

The single namespace used for the tenant will typically match the domain of the primary contact which was enabled as an OTD administrator.

If a resource mailbox is using an SMTP address in a secondary domain which is still part of the same Microsoft tenant then it would be necessary to import that (and any other required) domain names into the OTD configuration.  This configuration cannot currently be performed in the OTD administration portal though. It is handled by signing into the separate Poly Cloud Services (PCS) administration portal and manually importing the domain(s) directly from the Microsoft tenant.  This process is outlined here in the official OTD service documentation.

Endpoint Configuration

The previous steps are all part of the initial one-time setup for the OTD service and typically will not need to be revisited.  With the base configuration completed the remainder of this article covers the procedure which would be used every time a new Poly video endpoint is configured to use the service. 

Define a Device

Each endpoint, be it Poly or Cisco, will need to first be defined as a device using the OTD administration portal.  As mentioned above this article only illustrates the process used with a Poly endpoint which all contain Exchange Web Service (EWS) client behavior.  This means that Poly endpoints are configured to request their calendar data directly from an EWS host based on their own programmed polling intervals.  Cisco endpoints are not capable of performing this client-server request though.  They do not connect to the calendar source as they are programmed to expect that information to be routinely pushed down to them by a Cisco TelePresence Management Suite (TMS) server.  The OTD Service emulates TMS in order to provide the scheduled meeting information via the proper One Button To Push (OBTP) solution that is native to many Cisco video endpoints.  Configuration of a Cisco endpoint is covered here in the official OTD service documentation and in most cases also requires the additional deployment of a Cloud Relay.

• Select Devices from the OTD administration portal navigation menu and then choose Connect a Device.

• Pick from the provided list the closet appropriate device option for the desired endpoint.  For example, choose RealPresence Group for any modern Poly endpoints like the G7500 or Studio X devices.

• Enter the email address of the resource mailbox (e.g. x50@msteams.net) for the Calendaring Email field and then enter a descriptive name to identify this endpoint among others in the OTD device list and then select Create.

At this point OTD will present a set of automatically generated credentials which need to be used by the endpoint to authenticate directly to the OTD service.

• Copy the credentials to the clipboard and then store them in a temporary file or workspace to be used with the endpoint configuration and then click Finish.  (Once this window is closed the password cannot be viewed again so a new password would need to be generated.)

The new device should now be listed with a status of Pending.

This concludes the configuration of the OTD service as well as staging the first endpoint.  All that remains is to go to the device itself and point it to the OTD service for calendaring.

Configure Device

This step will differ slightly depending on the brand and model of the video system, but the overall configuration uses the same concepts.  The specific steps shown here will be identical on any modern Poly endpoint as the G7500 and Studio X devices run the same PolyVideo OS platform.  Configuration of a Polycom Group Series will look very similar, following the exact same configuration.  (Note that in most cases it is not recommended to use the OTD Service with Poly Trio devices as these already have their own native support for parsing various meeting invitations.)

• Connect to the web management interface for the endpoint and then browse to Servers > Calendaring Service.

• Select Enable Calendaring Service if it is not already enabled.

• Enter the Email (e.g. zlcteeyhivwh@otd.plcm.vc), User Name (e.g. zlcteeyhivwh@otd.plcm.vc), and Password (e.g. D4k5qzsIJW) information provided by the Generated Credentials step in the previous section.  (The provided Domain value of ‘OTD’ is not needed and can simply be omitted from the configuration.)

• Enter otd.plcm.vc in the Microsoft Exchange Server field.

• Select Save to begin the registration process which should complete successfully after a few seconds and report the status as Registered.

• Return to the Devices section of the OTD administration portal to verify that the device status is reported as Connected.

• Select the pencil icon to view additional status information and options for the device.

With the configuration complete the first device should now be able to display upcoming meeting invitations along with a functional ‘Join’ button for the myriad of supported standards-based conferencing platforms.