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.
Currently there are three different methods to configure the OTD service for access to Exchange Online:
Automatic registration – uses pass-through authentication with the mailbox or impersonation account.
As a Service Account – uses proxy authentication with a dedicated service account through an Azure Enterprise Application.
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.
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.
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.
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 firstname.lastname@example.org | 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 email@example.com -DeleteComments $false
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.
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. firstname.lastname@example.org).
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. email@example.com).
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. firstname.lastname@example.org).
New-ApplicationAccessPolicy -AppId ‘500e702f-0145-4462-b2a6-d00e35b92d45’ -PolicyScopeGroupId ‘email@example.com‘ -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 ‘firstname.lastname@example.org’
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.
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.
- 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.
- 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. email@example.com) 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. firstname.lastname@example.org) 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. email@example.com) 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.
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. firstname.lastname@example.org) 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.
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. email@example.com), User Name (e.g. firstname.lastname@example.org), 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.
35 thoughts on “Poly One Touch Dial Service with Exchange Online”
[…] http://blog.schertz.name/2020/09/poly-one-touch-dial-service-with-exchange-online/ […]
we followed this and all meetings on the device is not showing “Join” button. Device is G5700.
The main reason for that is that the following is not set:
Set-CalendarProcessing -Identity email@example.com -DeleteComments $false
Make sure that is set for the room account. OTD requires the comments in the email to parse the invite correctly.
Thank you very much for this latest write-up. It has helped me a lot in my recent configuration with Polycom RealConnect and OTD services in the simplest way.
I am wondering what kind of possible security issues we will face if we do not use the mail-enabled security group for the room mailboxes.
If you do not define the Application Access Policy and then the Application will grant Poly read access to all calendars in the entire tenant. The OTD service will only attempt to connect to the mailboxes which are specifically setup in the portal for each managed endpoint though. So, it’ll function no differently; you are just providing more access to a Microsoft partner than you need to.
Thanks for your reply, Jeff. That is certainly a security concern for us and we shall configure it to restrict Poly’s access to our tenant. Cheers.
My Application Access Policy does not appear to be working, can still test connectivity successfully to all mailboxes instead of just the one in the room mailbox in the mail security group.
New-ApplicationAccessPolicy -AccessRight RestrictAccess -AppId “500e702f-0145-4462-b2a6-d00e35b92d45” -PolicyScopeGroupId firstname.lastname@example.org -Description “Restrict Poly OTD App to members of security group PolyOneTouchDialAccess.”
The room mailbox is in the email@example.com group, however I can still test connectivity to all mailboxes which is not optimal.
Any tips? I’ve tried disconnecting and reconnecting the O365 integration.
Make sure that you are using a Mail-enabled Security group.
I have my OTD configured with service account model.
However, when i use the proxy account, join button for private meeting is missing. But i can see the join button for private meeting if i register the GS calendar using auto-registration method to OTD. Normal Teams meeting is ok with both method. Do you have any idea why that happen?
I don’t know what might be causing that behavior as it shouldn’t matter which configuration is used. I just validate the Join button works on my X50 which is using the Application model integration I’ve covered in this article.
Hi Jeff, we are having the same issue. private meetings do not show “join” button, they show us as “private meeting”. all other meetings show join button as expected.
We are using O365 method with service account for OTD.
I have checked and RemovePrivateProperty is FALSE and DeleteComments is FALSE for our room mailbox accounts and our service account has reviewer access on all room mailboxes. are we missing anything?
Your configuration appears to be correct but I’m not aware of anything different with a Private Meeting which would prevent the Join button from appear, except for if the service cannot see the meeting body to parse the instructions. This typically happens when the service has nothing to see (DeleteComments=True) or it does not have access to see it (Reviewer permissions required).
Nice article, Jeff. Please pardon my ignorance, but do you need to purchase a special account to use OTD? We tried registering on the OTD.PLCM.VC site and we get this message:
You have not been granted access to One Touch Dial.
Please contact Poly support.
We’ve not been able to make heads or tails of what licenses we need. We purchased an X50 and use it in Teams mode, but were excited to use the Poly mode and take advantage of other services at the same time.
The service is free to use with Poly endpoints, but you’ll need to purchase a ‘$0’ SKU so that your Microsoft tenant can be onboarded. Then you’ll have access to the administration portal to complete the setup I’ve outlined in this article.
Jeff – can you expand on this any further? I am in the same situation as Jonathan – recently purchased an X50 and using it in Teams mode but looking to add dual functionality with Zoom.
Where is the “$0 SKU” purchased or acquired from?
To support joining other platforms like Zoom, WebEx, etc you’ll need to put the X50 into the generic Poly mode and leverage all the standards-based connections for each platform (e.g. WebEx, CRC for Zoom, RealConnect for Microsoft Teams, etc). The Studio in native Teams mode can only join Teams meetings today. The Poly partner who you purchased the X50 from can sell that no-cost OTD SKU to get you setup on the service.
Can we expect the same article but for Exchange on-prem?
OTD integration with Exchange Server has only one possible configuration which requires a service account to be delegates permissions to the individual mailboxes and external Exchange Web Services is published to the Internet. That is already covered in the product documentation: https://otd.plcm.vc/support/docs/calendars/exchange-connect-with-service-account
Just pointing out for anyone following this guide, I found that it can take an hour before the OTD Office365 Connector Test will pass. So if it fails. Don’t stress. As usual with Office365 its a case of shut up and wait 🙂
This guide saved me lot of time. I’ve been getting :3 dots” on the Group Series touch instead “join” button. sure enough, it was the way the mailbox was provisioned. Wasted couple of days Poly support and they had no idea what was wrong
Could you please advise what was wrong exactly and what you did to resolve the issue as I’m having the same issue as you were.
My client is currently using on-prem WFS OTD. Will my client need to move to OTD Cloud for modern authentication?
No need, the OTA App on Workflow Server (WFS) already supports Modern Authentication as of release 1.7.2.
Hi Jeff, can I have more than one OTD Portal per O365 tenant. I have multiple Domains/Companies within multiple O365 tenants.
A single identity can only administer a single OTD tenant, but that tenant can support multiple domains. For example you have an admin account enabled for the Poly Cloud Services portal as “firstname.lastname@example.org”. You can sign into PCS (https://console.plcm.cloud/) and then add all other domains from the same O365 tenant. Resource mailboxes in any of those domains can be used in OTD with the same tenant. And if you have another O365 tenant you’ll need to use an identity in one of that tenant’s domains to administer that PCS/OTD tenancy. The Poly-to-O365 tenancy mapping is 1:1.
Thanks Jeff, will review adding the domains within the PCS. This will work for most of our subsidiary companies, but I have a few companies within the same O365 tenant, that want to manage their own OTD, just wanted to confirm I cannot create more than one OTD per O365 tenant. Many thanks.
Correct. Any other tenants you want to manage will need to provide you with an account in their tenant. You’ll sign into the OTD portal using that account to access their administration settings.
We purchased the Poly Studio X50 + TC8 package for the primary purpose of using the One Touch Dial (ODT) but I hadn’t imagined how complicated it would be. (it looks so simple on Poly’s advertising videos)
Of all the information I have been able to collect on the NET, yours are probably the most relevant.
I am writing to you because it is impossible for us to connect to otd.plcm.vc. “You have not been granted access to One Touch Dial.
Please contact Poly support. ”
I contacted Poly support who explained to me that we must be registered in “white list” to be able to connect, but that requires a license number.
“provide us with the license below
OTD license: ***** or, Realconnect license: ***** ”
We don’t use RealConnect, but I’ve never heard of any OTD license: Poly tells me to check this out with my provider!
Can you give some information ?
Pascal, the Poly OTD service is free to use with any Poly endpoints (like your Studio X50) but it requires a ‘purchase’ of a free $0 license for the OTD Service. This is simply to insure that you are correctly onboarded into the service and it appears this was not included by your reseller. I’ll contact you directly via email to get this sorted out. Once your domain is enabled in our service you can follow the steps in this article to get the Studio X setup and working with any supported meetings (Zoom, WebEx, etc.) but just be aware that without purchasing any RealConnect Service licenses you still cannot join any Microsoft Teams meetings regardless of what is setup with OTD. One Touch Dial simply lets you simply places calls into various meetings services using a calendar invite, but you can only successfully connect that call if the different services allow it.
Thank you for your quick and detailed response …
Correct me if I’m wrong, but it seems difficult to entrust the configuration of a Poly Studio X50 + PolyTC8 + OTD system to a non-IT specialist!
I sold (and we bought it!) The Poly Studio X50 + Poly TC8 solution to our Boss after having compared the possibilities with competing equipment and estimated (largely) the prerequisites and configurations necessary to set it up. .
I was very wrong.
I never imagined having to dive into PowerShell, add a few licenses to our account (teams.rooms!), Connect to 4 polycom sites (lens.poly.com, otd.plcm.vc, console.plcm.cloud, webapp.plcm.vc), modify some parameters in Microsoft-Azure-Enterprise applications, create user groups, a shared calendar, a room account in Exchange 365, recover the free license (13 € HT) from a supplier and create an account based on this license …
Actually, I feel incapable of redoing a setup from scratch after testing everything all over the place.
Your article on OTD has given me a lot of progress, but while I have been able to achieve convincing results, it is not working properly.
I had to install “poly-cloud-relay” from a VM, I no longer have any error messages or configuration alerts, but I only get the user’s appointments connected.
I still cannot retrieve the appointments of the user group (login as a service) or all users (login as an application).
Apart from the RealConnect subscription, will it be necessary to subscribe to an additional service for correct operation in multi-poly mode?
What are the essential prerequisites?
I understand the constraints imposed by security, but why is it so complicated to configure?
I would like to test the current configuration without going through the PolyX50 (it is configured in “TEAMS mode) and it is widely used at the moment)
Thank you for you precious help.
Last thing: I can not understand the principle or the interest of “provisioning” … could you explain it to me?
The Cloud Relay is only for use with Cisco video endpoints, you should not be deploying that VM if you are using a Poly video system. Also the OTD service is only applicable if you are using RealConnect with the Studio X in Poly mode. If you are instead using it in the Microsoft Teams provider mode then there is no need for RealConnect or OTD. It is unclear to me which mode you are attempting to run the Studio in (SIP mode with Interop or Native Teams mode) as you are performing setup steps for both of them, which is not correct.
I started reading your blogs on Poly devices and they are in-depth and provide clear understanding on setup.
I am just wondering, if you could assist here. We have migrated the resource mailbox from exchange on-prem to ExchangeOnline (O365), we are now facing issues with auto-registration with resource mailbox on Poly Group Series 500. We getting a message that “Invalid domain, user name, or password. Please check your credentials and try again.”
I am able to browse to OWA with resource account details and also the calendar test via OTD Portal > Calendars > Office365 > Test is successful.
The resource account works fine on Polycom TRIO device and sync calendar successfully via EWS.
The mailbox is setup as per instructions from Poly knowledge articles.
What could be the reason of it not working on Group series 500? Which area I should check?
It is likely that Basic Authentication has been disabled in Exchange Online in your Microsoft tenant, either by them or your own administrators. You should be using the setup outlined in this article, not the ‘autoregistration’ approach which is not compatible with Modern Authentication.
Hi Jeff, thank for for the detailed information.
Currently we use the application model but have not yet restricted the access to only specific room mailboxes.
In the azure ad sign in logs we have massive sign ins from the OTD application.
It looks like the OTD service will authenticate to graph api every minute for every mailbox.
Is there any chance to reduce the sign ins? I am wondering why they don’t authenticate one time and use this session for all mailboxes and for the next 60 minutes.
We use Azure Sentinel as SIEM solution and we forward the Azure AD Sign In logs to sentinel. Polycom OTD is massively increasing the log volume up to 60GB /month. This will increase the costs in Azure.
The service doesn’t initiate the connection to the mailbox, the endpoints do that. Most of the endpoints will refresh their calendar data every few minutes and when they do the service will access the target mailbox, hence the connections you see in your tenant. There is no way to modify the hardcoded behavior controlling how often the endpoints update their calendars.
I don’t know if it’s possible to change how the app works so reduce repeated authentication but I’d suggest opening a support ticket with Poly to investigate.