Poly One Touch Dial Service with Exchange Online

September 3, 2020 by · 12 Comments 

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:

  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.


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.


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.


  • 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.


Microsoft Teams Room Factory Restore Process

August 28, 2020 by · 2 Comments 

The process outlined in this article can be used to reset a Microsoft Teams Room (MTR) system to a factory default configuration.  This would be the preferred method to use on a system which may have any customization beyond the base MTR application settings which need to be removed.  For example, a system which was joined to an Active Directory domain, or had custom policy settings defined or pushed, or had any third-party software applications installed.  Completion of this process will reset the Windows OS installation, retaining the existing MTR client application version and returning the system to the initial out-of-the-box experience which begins with the MTR application setup wizard.

At a high level the steps include retrieving the latest Microsoft Teams Room software deployment kit from Microsoft, executing a PowerShell script to prep the system for recovery, and then initiating the standard Windows 10 reset process.

System Preparation

The first step involves acquiring the latest Microsoft Teams Rooms recovery script by downloading and extracting the most recent MTR deployment kit.  This portion can be performed from any Windows computer or even directly on the MTR itself.  If a different computer is used then simply copy the extracted files over to the MTR using a USB drive or network share.  The example used in this article will perform this directly on the MTR to avoid the need copy the files from another computer.  While not necessary it may be helpful to temporarily connect a USB keyboard to the MTR to make it easier to type or copy/paste the commands provided in these steps.

Download Deployment Kit

  • On the MTR console select the More > Settings menu and enter the local administrator password when prompted.  (The default password is “sfb”.)
  • Select the Windows Settings option, choose Administrator when prompted for which user to sign in as, and then enter the administrator password again.
  • Download the latest version of the MTR software deployment kit from Microsoft using the following direct link.

  • https://go.microsoft.com/fwlink/?linkid=851168

    • Select Save when prompted for what to do with the file to save it to the default Downloads folder.


Note that the deployment kit package is still referred to using the previous Skype Room System branding (e.g. SRSDeploymentKit-

Extract Files

  • Select Start and search for ‘powershell’ and then in the Windows PowerShell app result select Run as Administrator.


  • Choose Yes from the User Access Control prompt.
  • Enter the following two commands to create a temporary directory on the MTR to extract and run the recovery tool from.

mkdir c:\temp
cd \temp


  • Enter the following msiexec command to extract the individual files from the downloaded package into the new directory. 

msiexec /a ‘c:\users\admin\downloads\SRSDeploymentKit-’ /qb TARGETDIR=’c:\temp\

Note that this command must use complete, absolute file path names for the source and destination; relative paths cannot be used. Also the source and target directories cannot be the same as this process will extract the individual package files as well as copy the original package to the target directory, so if the file already exists in the target directory then the command will fail.

  • List the working directory to confirm that the extraction process completed successfully.  The package should have been copied to the target directory and a subdirectory named “Skype Room System Deployment Kit” created with the extracted files.



  • Change to the new subdirectory and list the contents to confirm the RecoveryTool.ps1 script exists.

cd ‘Skype Room System Deployment Kit’


Run Recovery Tool

The PowerShell execution policy may need to be modified in order for PowerShell to allow the recovery script to be executed.

  • Enter the following commands to change the execution policy and run the recovery script.

Set-ExecutionPolicy Unrestricted -Force


  • When prompted to “Please choose an option” enter 2 to perform the Reset option and then wait for the script to complete.


Disable BitLocker

By default BitLocker disk encryption should already be disabled on an MTR system, but if it was enabled at some point by an administrator or policy then it must be disabled and the disk fully decrypted before resetting Windows.

  • Run the following manage-bde command to verify that BitLocker disk encryption is not currently enabled on the MTR.

manage-bde -status


If the Protection Status is reported as Protection Off and the disk is Fully Decrypted then skip this step.

  • If Bitlocker is enabled and/or he disk is encrypted at all then use the manage-bde command to disable BitLocker and then wait for the disk decryption process to complete before moving to the next step.

manage-bde -off C:

Enable Windows Recovery Environment

  • Run the following REAgentC command to enable the Windows Recovery Environment (RE).

reagentc.exe /enable


Windows Recovery

Now that the MTR has been properly prepared for a system reset the final step is to begin the built-in Windows recovery process.

Reset PC

  • Begin the Windows reset process by entering the ‘systemreset’ command in PowerShell. (Or alternatively navigate to the Start > Settings > Update & Security > Recovery menu and select Get Started.)


  • Select Remove Everything.


  • If prompted to clean the drive select Just remove my files.


  • Confirm the selected options and select Reset to begin the process.


The entire reset process can take around 30 minutes and will reboot several times before stopping at the language selection menu of the Windows setup process.

  • Select the desired language and keyboard layout.

At this point at least one more reboot will occur and reset process will finally be completed, ending at the initial MTR client setup wizard.


Upgrading Microsoft Teams Desk Phones

May 21, 2020 by · 27 Comments 

This article outlines the currently available options to upgrade a certified Microsoft Teams IP Phone device to the latest firmware version as provided by Microsoft.  The concepts and processes are generally the same for all certified IP phones provided by the various Microsoft partners.  The example screen captures and documented upgrade process in this article was performed using a Poly CCX 500 phone.


Microsoft Teams-certified desk phones and conference phones utilize a fairly new approach that is a mixture of different approaches used across several generations of IP phones from Office Communications Server to Lync to Skype for Business.

Initially Microsoft designed and owned both the hardware design and software for the very first handset model which came out for Office Communications Server 2007 which was manufactured and sold directly by a few select Microsoft partners.  The Polycom CX700 is an example of this phone, commonly referred to by its original development codename of “Tanjay”.

In 2010 with the release of Lync Server Microsoft handed over the hardware design to the partners and simply kept the entire software stack.  This second generation of phones saw additional partners getting into the game and vastly different looking devices produced by all.  Yet they all collectively behaved the same as they all ran the same Microsoft-owned and maintained firmware comprised of Windows CE and a special Lync client packaged together as Lync Phone Edition.  The Polycom CX600 is probably the most recognizable model among all devices in this family which used the development codename of ‘Aries’.

Then, as Lync Server turned into Skype for Business Server a larger shift in the IP phone ecosystem occurred.  Microsoft moved completely away from having any direct involvement in the development of the software and turned everything over to the partners.  For the first time the hardware, firmware, and user interface were all completely within the manufacturer’s hands to design, maintain, and even distribute.  Thus, the 3rd Party Interoperability Program (3PIP) was born and Microsoft published various sets of qualification specifications which outlined what a device needed to be officially support for Skype for Business.  Some new Microsoft partners became involved (while others departed) in this era which arguably provided simultaneously both the greatest flexibility and most complex options for desk phones in a Microsoft UC platform.  The ability for these devices to support multiple SIP platforms provided capabilities not previously available with phones which only spoke Microsoft-specific protocols.  The Polycom VVX and Trio families are ubiquitous examples of the 3PIP generation.

When Microsoft Teams, a solution not built on traditional SIP protocols, inherited the telephony capabilities of Skype for Business it was time to look at the landscape of IP phones yet again.  Microsoft opted to leverage the existing Android client for Teams by creating a unique branch of that client designed specifically for IP phones.  The phone vendors handle the hardware and firmware, but Microsoft provides the client software specific to Teams which delivers identical capabilities and user experiences across phones from all certified partners.

New Features

Microsoft announces new features and capabilities in Teams on the What’s New in Microsoft Teams support page which includes a section specifically for Desk Phones.  For example here is the latest update at the time this article was posted.


The date provided (April 23, 2020) is when new these new features and functionality was publicly released in Teams.  Like other Teams clients and devices the availability of these features are tied to combination of the software version and the deployment ‘ring’ assigned to a tenant and/or user.  Even if the features have been enabled for the tenant a phone signs in with it must still be running a Teams app version of at minimum what is listed.  Note that the version number of the Teams app includes a build date (20200319) which indicates that this specific feature set has undergone about a month of testing with phone partners and select customers in through Microsoft’s Technology Adoption Program (TAP).

As will be demonstrated in this article the Teams client version actually packaged into the firmware update by the phone vendor may not exactly match the version reported above as it may include a newer build of the Teams client.  The version recorded above is essentially the minimum version needed to support the announced capabilities, but if newer versions are available then those may be selected by the vendor.  For this reason slightly different client versions may be observed on what is currently available between different manufacturer’s phones, yet all should contain the same set of published capabilities.

Device Software

While the base firmware of devices from the different manufactures will differ each will include the same additional components developed by Microsoft.  Each of these is a unique Android Package Kit (APK) which perform different functions.  The primary component is the Teams application itself.  The additional components are used to handle functionality outside of the core Teams client like when communicating with the Teams device management services, Intune/Endpoint Manager services, or locally with the phone’s operating system and hardware.  As Microsoft owns most of these agents they are all packaged by the phone vendor into a specific firmware release.  (While a mechanism does exist to allow these components to be updated individually that is not something which has occurred yet; so far only full firmware packages provided by the phone’s vendor to Microsoft have been published into the device update repository.)

The version number of the Teams client can be viewed directly on the phone whether the Teams client is currently signed in or not.  When not signed in the ‘gear’ icon in the upper right access the limited settings menu.  If a user is signed into the phone then either swiping from the left side of the screen or tapping the hamburger menu displays the Settings menu.

    • Open the main menu and then select Settings > About.

image   image

The Teams client displays both the main client Version (e.g. 1449/ and the Calling Version (e.g. 2019.41.01.2).


The version numbers for the device firmware and additional Teams components are provided in a different menu location though which can be found under the Device Settings menu.  This is a vendor-specific menu which may look different across various phone lines and models as this menu is managed by the device manufacturer.

    • Open the main menu and then select Settings > Device Settings > About.

image   image   image

The Poly device menu as shown below reports network addresses, the current Firmware Version, and the current version of each additional Teams software component including the primary Teams client app.


Device Management

While individual phone vendors provide their own distribution points and update processes for phones they will all be able to update software directly from Microsoft via the Teams Admin Center (TAC), regardless of manufacturer.  Currently Microsoft provides administrators a method to manually upgrade one or more phones using the admin center, but automatic updates are not yet enabled in Teams.

When an update is available for a specific device model it will be reflected in the device management section of the admin center in both the phone list view and when looking at the Software Health section of individual devices.  In the main phones listing the “1 Update Available” status is a selectable link which can be used to easily update a single phone, or the checkbox field on the far-left can be used to select multiple devices and then use the Update action at the top.


With multiple devices selected the desired update packages can be chosen and either scheduled or immediately updated.


The update service will not differentiate between upgrading or downgrading as it only performs a version check to see if what is reported on phone is the same as what version Microsoft currently has published in Teams.  Thus if a different version is available for the device then an available update will be reported regardless of whether the published components are newer or older than what the device is currently running.

Upgrade Process

The remainder of this article will walk through the steps of upgrading a single phone.  In this example the CCX 500 handset on older 5.9.12 firmware will be upgraded to the newer 5.9.13 release which Microsoft published to the Teams firmware repository on May 12, 2020.

Push Firmware

    • Open the Teams Admin Center and under Devices > Phones locate a phone with an available update shown in the Action field.


    • Either click the link under the Action field to skip directly to the Update Status menu or click on the link under the the Teams user field to view the Software Health screen and then click the See available updates link on the Firmware option.


    •   Select Firmware and hit then click Update.


(Note that in the screenshots above the Current version is reported as ‘null’.  This is a bug in the older CCX firmware release where the device would not report the current firmware version on the phone correctly to the Teams Admin Center.  This bug has been fixed in the newer release and future updates will correctly display both the current and new versions in the TAC.)

While the software package is downloading and the update process is happening the Teams client will quietly indicate that by continually scrolling a purple bar across the screen from left to right.


In addition to the Teams client hinting at the update process occurring in the background the Poly CCX firmware goes one step further and actually reports device update status messages at the bottom of the screen.  The messages will report the initial start of the process as well as briefly appear on screen for every 10% the process advances until it is complete.





When the upgrade process is done the phone will display a final message that the “Software upgrade is successful” and will automatically reboot.  (The Teams client does not yet include a mechanism to delay this reboot based on device activity.  So, if a user is actively in a call or actively using the phone while the update is being applied then it will reboot upon completion of the background upgrade process.  For this reason it is not recommended to perform upgrades from the TAC during business hours or anytime when the phones may be in use.)

Verify Update

Once the phone has rebooted the new version information can be reviewed to verify that the update was successfully applied.

    • Using the information outlined earlier the Teams client version can be viewed from Settings > About while the more detailed list of versions can be found under Settings > Device Settings > About.

image     image

Note the new firmware version is reported above as and the Teams Version shows a build date of 20200408, which is newer than the minimum build date referenced earlier in the Microsoft features documentation.

After the phone has applied the new firmware not all of the new features will be available.  For example in this release the Manage Delegates menu will appear under Settings as does the new Ringtone options under the Calling menu.

image     image

But the main Calls screen will look no different than before with no Favorites in sight.  Currently there is a limitation in the Teams client where if the update was applied while a account is signed into the phone then the user must manually be signed out and back in to the Teams client in order to fully pickup all the new changes.  (This Teams client behavior will be addressed by Microsoft in a future update.)

Alternatively resetting a phone to factory settings will accomplish the same goal in addition to giving the phone a fresh start with the new firmware, purging any potentially corrupt configuration or cached data on the phone.  This is not a requirement after upgrading at all, but just as a general best practice if any issues occur after firmware updates on devices then performing a factory reset should always be one of the first troubleshooting steps to perform.

Thus, choose to either sign back into the phone or perform a factory reset, there is no need to perform both actions.

Sign Out

Perform only one of the following procedures, whichever is preferred and or applicable to the specific phone.

    • For signed-in users assigned the standard User experience open the Settings menu and select Sign out.
    • For signed-in users assigned a Meeting or Common Area Phone experience open the Settings menu, select Device Settings, then Admin Only, enter the device’s admin password, and then choose Sign out.

Factory Reset

Or as explained earlier simply perform a factory reset on the phone which will erase the current configuration on the phone including any signed-in user credentials.  (A factory reset on any Poly phone does not revert the firmware version so the newly installed version will remain intact.)

A factory reset can be invoked directly on the phone using one of these three options depending on the current state of the phone.

    • If the phone is not currently signed in then tap the gear icon on the Sign in screen to access the Phone Settings menu, select Admin Only, enter the device’s admin password, select Debug, and then choose Reset to Factory Defaults.
    • If the phone is currently sign in then open the Settings menu, select Device Settings, then Admin Only, enter the device’s admin password, select Debug, and then choose Reset to Factory Defaults.
    • A special process can be performed during device power-on to trigger a factory reset which may be needed if the phone is currently in an unresponsive state.

Once the factory reset has completed following the Out of the Box (OOTB) wizard to select the desired language and Microsoft Teams phone base profile to return to the Sign in screen.

Sign In

Whichever process was used the phone should have returned to the Teams client in the default Sign in state.


    • Sign in to the phone with a username, phone number, or from another device.

Now the new Calls view can be seen with the Favorites and Recent call lists screens aligned side-by-side.  Either tapping the tabs at the top or swiping left/right will switch between them.

image     image

    • If preferred the user can enable dark mode on the phone by opening the Settings menu and selecting Dark theme.  The Teams app will need to restart if the theme is changed.

image     image

At this point the phone status should be updated in the Teams Admin Center to reflect the new version.

    • In the Teams Admin Center navigate to Device > Phones and then from the All phones list locate and select the phone which was just upgraded.  The Health section will be displayed by default and should reflect the newly installed version and shown below.


If the phone Status is displayed as Offline or if the older version information is still showing then click Refresh details.  If that does not work and the Last seen timestamp is also stale then it is likely the phone just has not yet checked in with the device management services to report new details.  After several minutes it should automatically update and reflect the correct software information from the device.

RealConnect for Teams Topologies

May 18, 2020 by · 25 Comments 

While this blog already contains several articles discussing Poly’s RealConnect solution many organizations with existing Poly video infrastructure deployments want to understand which RealConnect for Microsoft Teams topology may be best.  The purpose of this article is to explain the differences between the available topologies so that an informed decision can be made.  Some of this content has already been covered in various older articles, but this serves as an opportunity to present the latest information in a single cohesive story leveraging best practices derived from real-world planning and deployments.

The main areas where differences reside between the topologies are categorized as: architecture, video experience, and licensing.  While the overall user experience is nearly identical between all scenarios there are a few distinct differences which can often sway the decision one way or the other, while other differences could collectively impact the cost to deploy and/or use the solution.

Often the first and only criteria though is simply based on selecting a cloud-only solution which provides little to no on-premises footprint, thus making the decision very easy.  But when cost, complexity, and overall experience might outweigh that elementary approach then understanding the nuances among the supported topologies is fundamental to arriving at the ideal solution.  Alternatively it may seem desirable to leverage existing Poly video infrastructure which could currently be used for traditional video meetings or even RealConnect with Skype for Business, but certain limitations in that approach may make the cloud-only route more attractive to some.

As many of the following scenarios are simply minor configuration differences among overall identical deployments then it can be fairly trivial to change models later on.  Even multiple topologies could be utilized concurrently in the same environment if desired, so migrating or transitioning between different topologies can also be figured into the overall planning.

Some initial advice is to maybe not get too caught up in heading towards the most complex approach solely to try and mimic every single use case which may exist today.  Designing 80% of the solution based on 20% or less of common use can often lead to a cyclical approach with no clear winner, so given the state of world today and how quickly people have been able to adapt to forced changes in work behavior this can also serve as an opportunity to shed some of those antiquated behaviors and deliver a simpler overall solution.


A traditional video endpoint, also referred to as a VTC (VideoTeleCommunications) system by definition only supports standards-based SIP and/or H.323 protocols and cannot communicate directly with Microsoft Teams.  For these systems to interoperate with Microsoft Teams the only available method is to leverage Microsoft’s partner-based Cloud Video Interop (CVI) offerings to join a scheduled Teams meeting.  The RealConnect Service is Poly’s CVI offering which is hosted entirely in Microsoft Azure and is utilized in all of the available RealConnect topologies discussed here.  Thus, the service can either used by itself as a cloud-only solution or it can be used in conjunction with an on-premises Poly video infrastructure deployment which may or may not contain a traditional Multipoint Control Unit (MCU), commonly referred to as a bridge.  There is no way for a VTC endpoint or a Poly bridge to connect directly into Microsoft Teams; both must utilize the CVI service to do so.

Because the service is required for all possible scenarios then the initial onboarding and repeated meeting scheduling experience is the same across the board.  Once the service is enabled for a Microsoft 365 tenant then enabled Teams users will begin to see additional video conferencing details when creating new Teams meeting invitations.


Throughout this article the example above will be used to illustrate how calls would be placed from a VTC endpoint to join this meeting via the provided details.  Every meeting scheduled by any user in the same Teams organization will always use the same Tenant Key (e.g. 12345678) while ever single scheduled meeting will always use a unique VTC Conference ID (e.g. 1177958860).  (Note that the Audio Conferencing ID is different as these IDs are used by different services which are not compatible.)  How this information can be leveraged to place calls can vary depending on the chosen topology.

In summary, the following three Poly offerings provide different options to leverage RealConnect for Microsoft Teams:

  1. RealConnect Service – Endpoint calls go directly into the service via standard firewalls.
  2. RealConnect for Clariti Endpoint calls go to an on-premises Poly video bridge, which in turn connects into the service.
  3. RealConnect Access Suite – Endpoint calls go directly into the service via a Poly firewall traversal solution.


The first two options are quite straightforward as all endpoint calls will land directly into the cloud service.  The difference between them is that if existing enterprise firewalls cannot or should not route traffic from internal VTC endpoints to the Internet then the RealConnect Access Suite (RCAS) can be deployed on-premises to provide call routing and firewall traversal services as well as endpoint registration and management capabilities.  The important components historically provided with RCAS are the Distributed Media Application (DMA) for call routing and the RealPresence Access Director (RPAD) for firewall traversal.  More recently that has been updated to leverage only the DMA product for both server instances, one as the DMA Core and the other as the DMA Edge (which replaces the older RPAD product).  Understand that RCAS is not a requirement to leverage the service as existing firewalls can typically be configured to successfully support the required traffic.  Or other existing standards-based video routing platforms like Cisco VCS or Cisco Call Manager could also be used. (Note that older Polycom Video Border Proxy (VBP) products are not supported with the RealConnect Service.)

The RealConnect for Clariti option includes a deployment of the same routing and traversal components provided in RCAS but brings also brings a video MCU (or bridge) into the topology in the form of the RealPresence Collaboration Server (RPCS), previously know as the RMX.  This bridge provides the ability to land some or all VTC endpoint calls into the same traditional Virtual Meeting Room (VMR) where the bridge will also then place its own outbound call up to the RealConnect Service to complete the connection into a Teams meeting.  Additional control over the VTC side of the Teams meeting is offered here, but this can come with both a literal and figurative cost.

Also mentioned in this article is the Poly One Touch Dial (OTD) Service which is complementary to RealConnect in that it can be used to provide a proper dial strings to VTCs capable of displaying a ‘Join’ button on calendar entries.  While the OTD Service is a cloud only, Azure-hosted service there is also an on-premises version of OTD provided via Poly Workflow Server which is often used, but not required, with Clariti deployments.

The concepts discussed in this article are not overly complex but are commonly misunderstood as a whole when a few precise details are omitted. The overall experience is largely identical between all models of RealConnect, even among the scenarios available to Skype for Business platforms.  A Teams meeting must always be scheduled for any scenario, the invitation formatting is the same, and the user workflow is unchanged from a regular Teams workflow.  Users reserve room resources as usual and when they enter the room they simply hit a ‘join’ button on the available room control interface to join the scheduled meeting.  This is where the differences begin though as the call routing, licensing cost, and video experience are reflective of the selected topology.


There are only small variations in the overall architectures between the RealConnect for Teams deployment options outlined above, and as stated all scenarios will still traverse the RealConnect Service.  The main difference is whether VTCs are calling directly into the cloud or instead calling into a bridge hosted internally.  The most important factor here though is the number of concurrent meetings these endpoints are joining.  On the surface it seems like providing a bridge on-premises for all endpoints to call into would drastically reduce the amount of sessions, and thus total bandwidth utilization, egressing a corporate network out to the Internet. But remember that an outbound session still needs to be established from that internal bridge out into the RealConnect Service in order to connect into the Teams meeting.  This means that the true value (in terms of bandwidth management) of using a local bridge is based not on the number of VTCs in use but the number of unique meetings these VTCs are joining at one time.

If meetings typically are comprised of a single conference room joining a meeting with several individual attendees joining from desktop and mobile devices then for every meeting like this that is running at the same time on the bridge a connection to the cloud service needs to be established.  The math here is simple, if 3 VTCs are in use at one given time and they are all joining 3 different Teams meetings then the local bridge will need to establish 3 connections into the RealConnect Service.  There is no real bandwidth saving here as the 3 endpoints could simply be calling directly into the service.


Alternatively though if a typical meeting consists of multiple conference rooms joining the same Teams meeting alongside native Teams participants then this imbalance starts to favor the RealConnect for Clariti models.  Thus, if the 3 VTCs are all joining the same Teams meeting then the bridge only needs to establish a single connection out to the service to reach that one Teams meeting.  This scenario can drastically reduce the number of egress connections to the Internet depending on the amount of concurrent meetings.


The real-world problem here though is that meaningful data may not be available to attempt to make an informed decision on this behavior alone.  Additionally meeting participation might vary so vastly over time that selecting one scenario over the other would not offer any measurable advantage if the two cases essentially balance each other out.  If some meetings have multiple VTCs but most have only a single VTC then it is usually simpler to just leverage the service directly, or leave this decision up to the other categories covered here.

The order the following topologies are presented is deliberate as they will progress from the easiest to acquire and use while offering the least flexibility in management and control to more complex yet flexible solutions.  Keep in mind though that there will be trade-offs with each approach so perceived advantages in one may lead to something seen as undesirables in another.

RealConnect Service

This is the CVI service managed by Poly and hosted in Microsoft Azure which VTCs call directly into in order to join a scheduled Teams meeting.  The service is comprised of several regional load balancers which receives a SIP or H.323 calls from a VTC (or from an MCU in the case of the Clariti models) and then intelligently directs that call into one of several virtual gateways in the best available pool of resources also hosted in Azure.  The gateway then utilizes a Teams bot to connect to the Teams meeting and handles bi-directional transcoding of audio, video, and content sharing streams.


The service does not include endpoint registration or device management as it simply accepts calls placed to various dial strings in the t.plcm.vc domain.  Standard network firewalls can typically be configured to allow SIP and/or H.323 traffic outbound into the service over defined ports.  In this basic approach the OTD service is typically leveraged to allow supported endpoints to call directly into meetings from scheduled meetings on the device’s calendar.  Alternatively meetings can be joined directly (or indirectly via an entry queue) by manually entering a dial string .  One way to improve the manual dialing experience on legacy endpoints which do not support Exchange calendaring (like Lifesize or Tandberg) is to create a speed dial entry on endpoints or in an endpoint directory which calls directly into the RealConnect Service entry queue specific to the tenant.  Using the example Tenant Key of 12345678 an organization could create a speed dial for “12345678@t.plcm.vc” which would allow users to simply call that entry and then upon connection would enter the unique VTC conference ID provided in the specific Teams invitation.

RealConnect Access Suite

RCAS is a licensing model which provides nearly the same video infrastructure components as Poly Clariti, except without any bridge to host meetings.  This is meant for environments where there is a need for endpoint device management and call routing/traversal when using external meeting services, like the RealConnect Service.


Endpoint calling behavior and bandwidth utilization into the service is no different other than video-specific routing components can now be utilized to assist calls in reaching the service in azure across the Internet.  One additional benefit that RCAS provides is that with endpoint registration comes the ability to define dial rules to further simplify manual dialing for rooms where calendaring is not available.  A standard dialing prefix (e.g. ‘6’) could be defined to mask the longer Tenant Key and required destination hostname or IP Address so that users could manually join a meeting by dialing the prefix followed by the unique video conference ID for the meeting.  For example dialing 61177958860 on the endpoint would be identified by the DMA by the leading ‘6’ as a prefix to match the defined rule, and then it would parse the remainder of the string out as the actual VTC conference ID.  The rule would essentially take a dial string of ‘61177958860’ and replace it with ‘12345678.1177958860@t.plcm.vc’ and then route the call accordingly.

RealConnect for Clariti

There are two different deployment models of RealConnect for Clariti which are nearly identical but a minor configuration change impacts how some calls are routed differently between them.  There is the more common Consolidated Model which treats all VTC calls the same regardless of their origin and the Split Model which effectively splits VTC calls between the bridge and the service depending on their registration or DNS behavior.

This Consolidated Model leverages both the service and an on-premises deployment of Poly video infrastructure components similar to RCAS yet with the addition of a bridge.  The configuration directs all endpoint calls to the bridge which then automatically establishes a single cascade connection per Teams meeting into the service.  This handles all VTC calls the same regardless of where they are located or registration status.


Note that while the solution name includes ‘Clariti’ that does mean that Clariti-licensed deployment is a requirement . Older procurement models of the RealPresence Platform are supported as are both hardware appliances and virtual server deployments of the infrastructure components.  The actual requirement is an infrastructure deployment which includes at least one DMA, one RPCS (or supported RMX), and an RPAD or DMA Edge all running prerequisite firmware versions.  This configuration leverages a custom hostname in the Teams invitation (instead of the default ‘t.plcm.vc’) which directs all endpoints calls via DNS to Clariti and never to the service.  Registered endpoint calls will be handled via dial rules configuration on the DMA and unregistered endpoint calls will be directed to the DMA or RPAD based on DNS resolution responses.  Only the bridge cascade is ever directed into the service.  Both SIP and H.323 can be supported simultaneously for endpoint calls, but the cascade call from the bridge into the service is only possible over H.323.

Note that local entry queues are not supported when using Clariti thus the full dial string is required when placing the call in order to establish the cascade from the bridge to the target Teams meeting.  The entry queue behavior is only available to endpoints which call directly into the service, which is not possible in this configuration.

Meanwhile, the Split Model is functionally identical to the previous and leverages almost the exact same configuration, but that single change means that calls from unregistered endpoints will no longer be directed to the bridge and will instead go directly to the service.


Where the Consolidated model uses a custom hostname the Split model retains the default ‘t.plcm.vc’ hostname in the Teams meeting invitation so that DNS responses will point directly to the service.  Endpoints which are registered to the Clariti deployment, internal or external alike, will not use DNS as the call is simply sent to the registrar which is configured to use the bridge for these calls.  This model allows and organization to insure that any endpoints belonging to other parties would connect directly into the RealConnect Service when joining their Teams meeting without ever touching their own network or internal video infrastructure.

Video Experience

Throughout the entire RealConnect workflow, from scheduling to meeting completion, the user experience is essentially identical across all models with one notable exception: the video layout. The audio experience is identical between all models as you can always hear everyone who is speaking, and the content sharing is no different as everyone can see the shared desktop or application provided by a single attendee at a time.

The number of concurrent video participants shown at one time and specifically who is shown at any given time is driven by a variety of factors.  Most importantly understand that Microsoft Teams does not currently give preference to attendees with their video camera enabled over those who are not sharing their video.  The only selection logic is based on audio activity. If an attendee is speaking then they are the current focus of the meeting and will be put into the current layout (if they are not already in it) regardless of whether their camera is enabled at the time or not.  This behavior is no different from Skype for Business, or Lync, or any of the Microsoft UC platforms.  This is why a video layout can often be heavily populated with tiles simply showing the user’s photo, or if no photo is available for their account then a plain circle with their initials, yet other participants who do have their video enabled are not currently being shown as they have not spoken recently enough and have been pushed down the list of most recent speakers.

The maximum number of attendees shown at one time is currently in flux.  Within Microsoft Teams it has always been a maximum of 4 participants across nearly every native client, but at the time this article was posted Microsoft has been rapidly working on increasing this limitation, driven primarily by the rise in Teams usage due to the COVID-19 pandemic.  Many Microsoft 365 tenants are already experiencing the updated layouts now which provide up to 9 participants at a time.  This new feature is something that Microsoft has been working on for some time and while the clients are just now being updated the backend services have supported sending up to 9 streams for some time.  That meant that Poly was able to expand the RealConnect Service to provide a 3×3 layout of up to 9 participants back at the beginning of the year.  The behavior when RealConnect for Clariti is involved is much more nuanced as the number of concurrent participants shown on either side of the meeting can vary based the configured mode.  The diagrams used in this article leverage the new maximum of 9 on both sides.

RealConnect Service

The video layout experience is simple and consistent when endpoints are calling directly into the RealConnect Service.  Every VTC call into the service is allocated their own gateway which means that each VTC appears as a unique participant in the meeting.  The roster entry for that endpoint will display the configured System Name on the endpoint, which can vary between SIP and H.323 configurations in some VTCs.  The endpoint can be muted or removed from the meeting like any other attendee.

This approach means that the Teams meeting service will be receiving inbound video streams from every endpoint coming through the service, so there is absolutely no difference in which video streams are seen between native Teams endpoints and VTC endpoints.  The RealConnect Service already supports showing up to 9 participants at one time and at the time this article was posted Microsoft is currently in the middle of rolling out the same maximum of 9 in many native Teams clients.  Nothing is different from the normal Teams experience here and the last 9 active speakers will be displayed to any and all participants capable of receiving that many streams.

In the example diagram below a total of 10 participants are in the same Teams meeting. Of those ten are 6 participants using any variety of native Teams clients, 1 native Teams device (like a Microsoft Teams Room solution), and 3 standards-based VTCs coming in through the RealConnect Service.  The video layouts below for one VTC and one Teams client illustrate viewing the exact same attendees, other than themselves of course.


There is an important difference to understand between the two though.  The native Teams client is actually receiving nine different Scalable Video Coding (SVC) streams while the VTC is receiving a single Advanced Video Coding (AVC) video stream.  This means that the native Teams clients and devices can control the layouts locally as well as pin individual participants who may not even be active speakers.  Conversely, the RealConnect Service controls the video tile layout and simply sends that entire image to the VTC.  The VTC cannot control who is seen nor modify the arrangement of video tiles.

RealConnect Access Suite

The behavior when using RCAS is identical to what is shown above as the service is still handling all calls and there is no additional bridge involved.

RealConnect for Clariti

The video experience for both VTCs and Teams clients is different with RealConnect for Clariti.  The addition of the on-premises bridge means that there are effectively two separate MCUs handling different participants in the same Teams meeting.  As outlined in the architecture discussion earlier the native Teams clients and devices continue to communicate directly with the Teams meeting services and behave no differently themselves.  But VTCs which are connected to the on-premises Poly bridge will receive a traditional virtual meeting room layout as managed by the Clariti platform.  The cascade established between the bridge and Teams via the RealConnect Service will only send and receive a single video stream of the active speakers from both MCUs.  The Teams participant list will also only show a single participant entry for this cascade.

Stating with the Consolidated Model the diagram below indicates the red VTC as the active speaker among the three rooms connected directly to the bridge, while the green Teams client is the active speaker among those connected directly to the Teams meeting service.  The bridge will only ever send a single video participant, thus only the red VTC will be seen by an Teams participants.

While there is no change from the service-only model in how the Teams participants operate themselves they will only be able to see a single VTC participant as the bridge only sends one at a time, automatically switching to the current active speaker across the cascade.  As the red VTC is the current active speaker then that is what the Teams participants see.

Meanwhile the VTCs connected to the bridge will see every other local participant, which could be even more than 9 if enough VTCs are connected and the bridge’s local layout configuration allows.  But no more than 1 participant from the Teams side will ever be seen by the VTCs as the RealConnect Service only sends a single video participant from Teams across the cascade down the bridge.  The local bridge will add that video tile to the overall layout which it manages.


If the Split Model of RealConnect for Clariti is used then it would be possible to have a mixture of both experiences.  The VTCs connected to the local bridge would adhere to the same behavior just described above but other VTCs landing directly on the service would operate as explained in the previous section applicable to the service.

In this diagram the red VTC is connected to the bridge while the blue VTC is connected directly to the service.  The Teams participants will still only see the active speaker from those connected to the bridge, but the blue VTC is now connected directly to the service and thus can also be seen at the same time by the Teams participants.


While this Split Model is more commonly selected for how calls are routed a use case where the video layout experience may be important is when dealing with multi-codec immersive telepresence systems.  In this scenario it may be desired to send regular VTCs directly to the service but route calls from the immersive rooms to a bridge so that those rooms can benefit from multi-stream stitching to provide views not available in the service.


There are many different license SKUs (Stock Keeping Units) available today which can vary by region, quantity, or subscription durations.  All of the available RealConnect licenses are measured by concurrent use which means none of the licenses described below are assigned to individual endpoints, they are applied to the service or servers. These licenses are only consumed during active calls, so the number of endpoints in use (and in one case the number of different meetings) at the same time dictate how many licenses are needed, not how many VTCs may exist in an organization.

The various applicable licenses can be divided into different categories:

  • [A] Service Endpoint Licenses – used by the service and applied to inbound calls from an endpoint.
  • [B] RCAS Licenses – used by RCAS to allow outbound call traversal from an endpoint.
  • [C] Clariti Licenses – used by Clariti to allocate bridge resources for inbound endpoint calls and outbound bridge calls.
  • [D] Service Cascading Licenses – used by the service and applied to inbound calls from a bridge.


Each potential calling scenario is depicted in the diagram above which can be used as a visual aid to understanding how multiple license types would be needed in certain deployments.

RealConnect Service

As usual the cloud-only approach is the simplest, requiring only enough concurrent-use licenses (category ‘A’) to support the maximum number of VTCs calling into the service at one time.  The number of Teams meetings occurring at the same time is irrelevant, so if 10 endpoints are calling into 10 different Teams meetings or 10 endpoints are all calling into the same Teams meeting the service still handles 10 total calls.  Calls in this scenario only consume a single license for each endpoint.

The licenses SKUs which fall into this category all include the text “RealConnect Service for MSFT Teams Video Interop” and “Concurrent VTC” in their descriptions.

RealConnect Access Suite

If RCAS has been deployed to assist with calls from endpoints into the service then two license types are now required.  The RCAS solution operates on concurrent call traversal licenses, so every endpoint call that needs to route through RCAS to reach its intended destination requires an RCAS license (category ‘B’).  In this case because the call is ultimately headed to the RealConnect Service in order to join a Teams meeting then an endpoint license for the service (‘A’) is also required.  Thus, each call from an endpoint joining a Teams meeting will consume 2 licenses: one traversal license and one service license.

The license SKUs which fall into this category all include the text “RealConnect Access Suite – Concurrent User License” in their descriptions.

RealConnect for Clariti

A Poly Clariti deployment is licensed on concurrent use of bridge resources so there is no licensing cost applied to call traversal here like with RCAS.  In this scenario any VTC which lands on the bridge requires a Clariti license (category ‘C’), as well as any outbound calls placed by the bridge.  As outlined in the earlier architecture discussion this scenario involves the bridge placing an outbound call into the RealConnect Service in order to cascade the separate MCUs.  When a call comes into the service from a Poly bridge in this scenario then it consumes a much lower-cost license than when an endpoint calls into the service.  Because the actual endpoints are already consuming Clariti licenses then a different license for the service was created to specifically address meeting cascade connections from the Clariti bridge.  For each unique Teams meeting that Clariti needs to cascade into at one time a cascading license (category ‘D’) is required.  The first VTC call into a Teams meeting consumes 3 licenses (2 for Clariti and 1 for the service), but when any additional VTCs joins the same Teams meeting then only a single Clariti license is consumed per additional VTC.

There is a single SKU (4870-09900-660) for the additional cascading license described as “RealConnect Service for MSFT Teams Video Interop. Concurrent Subscription for Clariti“.

This topology is much more nuanced in potential license utilization due to multiple factors which could be at play at the same time.  To best plan for how many licenses of each category might be used it is important to understand two different behaviors.

First, the number of concurrent Teams meetings has a direct impact on consumption of additional Clariti licenses and service cascading licenses.

The total number of different licenses consumed at one time will depend on both the number of endpoints in use as well as the number of unique Teams meetings the endpoints are joining.  When a single VTC joins a Teams meeting that call will consume 2 Clariti licenses (‘C’) and 1 service cascading license (‘D’).  If another VTC joins the same Teams meeting then that endpoint only consumes 1 additional Clariti license (‘C’) because the cascade from the bridge to that specific Teams meeting has already been established by the first endpoint so there is no need for the bridge to place an additional outbound call using up more Clariti and service licenses.

But, if another VTC joins a different Teams meeting which does not currently have any other VTCs in it then that call would trigger the establishment of another call from the bridge into the service to cascade a different VMR on the bridge into that second Teams meeting.  What this means is that the number of cascading licenses (‘D’) consumed depends on the number of concurrent Teams meetings.  The general guidance covered at the end of this previous article simply states to acquire half the number of Clariti licenses (‘C’) in a properly sized environment as cascading licenses (‘D’).  Meaning if a deployment has 60 Clariti licenses then it is not possible to ever utilize more than 30 cascading licenses given that a single VTC in a Teams meeting consumes 2 Clariti licenses (1 for the endpoint, 1 for the cascade).

Second, the RealConnect for Clariti Split Model allows some endpoint calls directly into the service which introduces the need to acquire both endpoint and cascading licenses for the service.

While an exact number of service cascading licenses can be decided based on internal Clariti sizing the number of additional service endpoint licenses needed is more of an moving target.  It really comes down to balancing any unregistered external corporate endpoints with the possibility of any invited external party attempting to join from their own standards-based video system.

Common Area Phones in Microsoft Teams

April 29, 2020 by · 62 Comments 

The deployment and administrative experience for a Common Area Phone (CAP) across Microsoft’s UC platform has changed over the years as it has matured from an on-premises software release with Lync to hybrid offerings of Skype for Business only to eventually be replaced by the cloud-only Microsoft Teams solution.  Generally the ideal of a common area phone is just that: a phone located in a shared space which only needs to provide the ability to place phones calls to other users and/or phone numbers.  These are not meeting devices.

Thus a core trait of the common area phone scenario is providing basic calling capabilities and not much of anything else.  Essentially the requirement is just for ‘dial tone’ to facilitate placing outbound calls to other users in the same organization, other organizations, PSTN numbers, and/or emergency services.  Common spaces typically don’t have calls coming into them as usually no one would know who is in that space at a given time, less anyone at all.  These are phones which may be located in areas like break rooms, front lobbies, shared spaces, warehouses, factory floors, etc.  They are not tied to a specific person and thus features like contacts, voice mail, or a calendar are not really applicable.  Often the baseline requirement is for a phone that will always be registered so that emergency services can be dialed without issue or delay.  Then depending on the configuration and licensing of the account assigned to the phone various additional features could be made available, like searching for other users or placing non-emergency calls to local or even international numbers.

Throughout the Microsoft UC journey the common area phones have had a very deliberate distinction that there is no mailbox available to them.  This is the main reason that they should not be deployed in a typical conference room as without a mailbox there is no calendar, and without a calendar there is no way to invite that device to a scheduled meeting.  It would still be possible to manually dial into a meeting if the invitation includes an audio conferencing number, but the invite would still not be viewable on the phone itself to see the dial-in information.  In general common area phones should simply not be deployed in a space where users would need to join meetings.  Devices in those spaces should instead use a meeting room account configuration.


Back when IP phones were first introduced with Office Communications Server a common area phone option was not yet available.  No account configuration was provided nor any phone models designed specifically for that use-case.  When Lync Server 2010 was released Microsoft added a special account configuration to allow basic calling features on a phone without the unneeded overhead and licensing costs associated with voice mail or other mailbox-related features included with a regular user account.  This configuration leveraged an Active Directory Contact object which could not utilize traditional authentication methods, nor could they be mailbox-enabled. Thus Microsoft created PIN Authentication for Lync Server to provide a way to sign into a phone using contact objects.  At the same time Polycom also released an IP handset designed specifically for the CAP scenario: the CX500.  This phone was slightly smaller than the standard phone designed for regular users and did not come with the USB-B port required to leverage the ‘Better Together’ pairing capability with a PC which allowed for basic user authentication.  This limitation meant that only PIN Authentication could be used on the phone.

The same capabilities and behavior were included in Lync Server 2013 and Skype for Business Server 2015 so there was no change to how common area phones worked with on-premises deployments.  There was a shift in the device options though as newer phones came to market leveraging Microsoft’s 3rd Party Interoperability Program (3PIP) and there were no longer any models built only for CAP use-cases by any of the partners.  The idea was that all phones in their product families could be signed in using any of the supported authentication models so in essence any phone could be a common area phone or an executive desktop phones.  Typically the lowest-cost handset, like the Polycom VVX200, would be selected to pull CAP duties.

A completely different approach was used for common area phones with Skype for Business Online though.  The method used for on-premises server deployments required a specific DHCP configuration for PIN Authentication to function which meant that common area phones could only be located on internal corporate networks or across site-to-site VPNs.  That authentication model could not apply to the cloud so a new solution was created for Skype for Business Online called Web Sign-In.  This addressed the main benefit of PIN Authentication in that it allowed users to sign into a phone without entering their user credentials (username and password) directly into the phone.  With PIN Authentication a user simply entered their phone number or extension and their PIN directly onto the phone via the keypad.  In contrast the Web Sign-In model a provides a login option on the phone which displays a unique code and instructions to go to a specific website on any other device like their computer or smartphone.  There they would enter their own credentials (if not already signed-in on that workstation) as well as a one-time use code provided on the phone’s screen.

Because capabilities in Skype for Business Online are based on Office 365 licenses more than the actual account configuration itself then Microsoft also added a new Common Area Phone license option which should be assigned to a regular user account; there is no special CAP contact user configuration available in the cloud like there was in the server platform.  This new license provides a more cost-effective option than purchasing the Skype for Business Online Plan 2 standalone license in addition to a Phone System (formerly Cloud PBX) add-on license. It is also much cheaper than using an Enterprise license on a phone which does not need 99% of what an E1 or E3 license includes. Note that there is no Exchange license provided which continues the theme of no mailbox-related capabilities for a CAP account.


With Microsoft Teams the same approach and the exact same Common Area Phone license is used.  Unlike with a Meeting Room license, Intune is not included and would need to be purchased as a separate add-in if these devices would need to also be managed from Microsoft Endpoint Manager.  (An Intune license is not required to manage devices from directly within the Teams Admin Center.)

Based on all of the detail provided thus far then the most important concept to understand here is what actually defines a Common Area Phone in Microsoft Teams?  The answer is multifaceted as it is not just a specific phone model, or user account type, or even the license applied to the account.  Minimally what makes a Common Area Phone is a phone policy assigned to a user account which drives the user experience on the device itself.

To illustrate this primary difference the three possible user experiences the phones can provide today are shown here.

  • The first is the default User mode which provides Calls, Calendar, and Voicemail screens used by regular user accounts.
  • The second is the Meeting mode which limits the phone to the calendar view, yet still allows for placing calls.
  • The third is the Common Area Phone mode which only provides phone calling features.

image      image      image

Note that any user account can be placed into a CAP experience by applying the appropriate policy, but if a user account assigned a Common Area Phone license is left to use either the default user mode or configured with the Meeting mode then the phone will display various errors due to lack of mailbox availability.

Thus, using a Microsoft-supported user account configuration, granting the correct phone policy, assigning a cost-effective license, and optionally limiting calling features are what really makes for a proper Common Area Phone deployment.

The remainder of this article will walk through configuring a Microsoft 365 tenant and then creating single user account to enable the Common Area Phone experience on a native Microsoft Teams phone.  Note that this is applicable to both Desk Phones and Conference Phones.

Tenant Setup

Before setting up a user account the tenant must have available licenses and an IP phone policy configured to enable the CAP phone interface.  The Microsoft 365 Admin Center and Teams Admin Center (commonly referred to as the ‘TAC’) are utilized throughout the configuration steps whenever possible, only reverting to using PowerShell for actions which are not currently available in any online admin center.  All PowerShell cmdlets used in this article are currently included in the Skype for Business Online PowerShell module.  (Nearly all of the steps shown in this article could be performed using PowerShell cmdlets if desired.)

Acquire Licenses

While the Common Area Phone license is ideal here, as explained earlier, it is not a requirement.  Any license(s) which include(s) Microsoft Teams and Phone System are sufficient.

If the Microsoft 365 tenant already includes the desired licensing then skip to the next section to begin configuring a user account.

  • In the Microsoft 365 admin center browse to Billing > Purchase services and then search for ‘Common Area Phone’ which should then appear under the Collaboration and communication section.
  • Select the Common Area Phone plan and then choose from either the Buy or Get free trial (if available) options.


  • Complete the ordering process for whichever option was selected and then go to Billing > Licenses to verify that the new licenses have been applied to the tenant.  (Normally this should apply immediately to the tenant but it can take a few minutes before seeing them listed.)


    Configure Phone Policies

    Simply assigning a Common Area Phone license to a user account will not apply the Common Area Phone experience as licenses only control what online services and features are available to the account.  A custom IP phone policy must be setup in the tenant and then assigned to this user account in order to control the user experience on any phone it signs into.  These policies are currently only configurable via PowerShell and are assigned to user accounts (not to devices) at the global level (by default) or the user level.

    Import-Module SkypeOnlineConnector      
    $sfbo = New-CsOnlineSession –UserName ‘admin@domain.com
    Import-PSSession $sfbo

    First determine if a common area phone sign-in policy has already been created in the tenant.

    • Execute the Get-CsTeamsIPPhonePolicy cmdlet to list any policies currently defined in the tenant.



    The example results above show the default configuration for M365 tenants and is likely what will be seen if this is the first time going through this process.  Over time new parameters may appear in this policy as Microsoft adds more capabilities into Teams.  For example, the Hotdesking parameters seen in the output above did not exist at the time this screenshot was captured for a previous article.

    If a custom user policy with the SignInMode set to CommonAreaPhoneSignIn already exists in the tenant then skip this next step as there would likely be no need to create another policy.  If an appropriate custom policy does not yet exist though then one should be created as it is not advisable to change the existing global policy’s SignInMode parameter.  Doing so would lead to all users in the entire tenant by default being forced into the same limited CAP experience on any Teams IP Phones.

    • Create a new policy using the New-CsTeamsIPPhonePolicy cmdlet which enables the CommonAreaPhoneSignIn behavior.

    New-CsTeamsIPPhonePolicy -Identity ‘CAP’ -Description ‘Common Area Phone User Policy’ -SignInMode CommonAreaPhoneSignIn


    There are additional parameters on this policy which can be customized if desired.  If common area phones are to be placed in spaces where non-employees may have access to them then it might not be ideal for them to be able to search for other users in the environment by name.  Or a phone might need to always be signed in with a specific user and phone number and never as a different user, so the hotdesking option should be hidden.  In Skype for Business some of these options existed and some could be controlled, but typically only at the global level.  With user-based phone policies available in Teams it is now possible to create multiple policies with different parameter configurations for a much more granular level of control.  For example, one policy could be created with CAP and search enabled for phones located in internal office spaces while another with only CAP enabled and with search disabled for phones in unsecure locations.

    As an optional example this step will disable user search by removing the Search icon from the CAP interface.

    • Edit the phone policy created above using the Set-CsTeamsIPPhonePolicy cmdlet to change the default search behavior.

    Set-CsTeamsIPPhonePolicy -Identity ‘CAP’ -SearchOnCommonAreaPhoneMode ‘Disabled’

    Configure Call Park

    A feature available by default to any phone sign-in modes is the ability to retrieve a parked phone call.  Yet in order for that behavior to actually function the Call Park service must first be enabled in the tenant as it is disabled by default.

    • To enable call parking go to the Teams Admin Center, browse to Voice > Call park policies and edit the Global (Org-wide default) policy.


    • Turn on the Allow call park setting and click Save.


    As discussed earlier with the phone policies it may not be desired to change the global default behavior on the call park policy, so a custom policy could be created here instead.  If that route is taken then make sure to assign that policy to the user account in the next section.

    Configure Calling Policies

    Another area worth reviewing is controlling calling policies for common area phone users to prevent unwanted behavior when a phone is not assigned to a specific person.


    • Enter a name for the policy (e.g. CAP), add a description if desired, select the preferred options, and then save the policy.


    Note that the options selected above are simply used as an example and are not necessarily indicative of an exact configuration applicable to a Common Area Phone.

    User Setup

    Now that the tenant has been configured a user account must be created and/or configured.  For the purposes of this article a new user account will be created.  If an existing account in the tenant is to be used instead then make sure that it is a user account and not a resource account.

    If a Common Area Phone license is assigned to a user account which previously was assigned a user license that included Exchange Online (like an Enterprise E1 license) then their mailbox will be automatically disabled, triggering that account to be removed form the Global Address List and preventing access to the mailbox, calendar, etc.  The mailbox is not deleted, it is just disabled.  If the assigned license is reverted back to something which includes Exchange Online then the Exchange configuration will be restored as will access to the mailbox and its previous contents.

    If a Common Area Phone license is assigned to a resource account then the mailbox will not be affected as resource mailboxes are allowed to be mailbox-enabled with no additional Exchange licensing.  While it is technically possible to assign a Common Area Phone license to a resource account this is not supported by Microsoft.  Their guidance is to use a Meeting Room (or an equivalent) license instead if the device requires use of an Exchange Online mailbox.

    Create User Account

    • Create a new user account in the tenant (e.g. cap@msteams.net).


    • Select Common Area Phone license from the Licenses section.


    Under the Apps section select Common Area Phone in the ‘Show apps for:’ menu to confirm which services are currently included in the Common Area Phone license. 


    Assign Phone Number

    Technically this step is optional as PSTN calling is not required for a Common Area Phone to function as it still could be used to only place internal calls to other users and/or numbers within the same organization.  But given that is a fairly limited use-case then most likely PSTN connectivity will be included for a Common Area Phone.

    The two possible options for PSTN connectivity in Microsoft Teams are Direct Routing and Calling Plans.  The configuration steps for these differ but the individual processes are no different than when used to assign numbers to regular user accounts, so proceed to do so with the method which is applicable to the tenant at hand.  As an example this article will use Microsoft Calling Plans in the following steps.

    • Add an available calling plan license (e.g. Microsoft 365 Domestic and International Calling Plan) to the account.


    • In the Teams Admin Center, browse to Voice > Phone Numbers, select the user account, and then click Edit under the Account > General Information section.
    • Assign an available Phone Number and Emergency Location then click Apply.


    Assign User Policies

    Now that the account has been created the next step is to assign the IP phone policy created earlier so that the desired Common Area Phone user experience is provided when this user signs into any phone.  Without performing this step the user would leverage the global IP phone policy configuration which by default uses the standard user experience.  For this user with a Common Area Phone license that would mean that the phone would display the additional calendar and voicemail tabs but with error messages on them.

    • Using PowerShell run the Grant-CsTeamsIPPhonePolicy cmdlet to assign the CAP phone policy to the new CAP account (e.g. cap@msteams.net)

    Grant-CsTeamsIPPhonePolicy -Identity ‘cap@msteams.net’ -PolicyName ‘CAP’

      If a custom Calling policy was created in the previous section then that should also be applied to the user.

      • Using PowerShell run the Grant-CsTeamsCallingPolicy cmdlet to assign the CAP calling policy to the new CAP account (e.g. cap@msteams.net)

      Grant-CsTeamsCallingPolicy –Identity ‘cap@msteams.net’ –PolicyName ‘CAP’

        If a custom Call Park policy was created in the previous section then that should also be applied to the user.  (In this article the default Call Park policy was leveraged so this step was omitted in the example configuration.)

        • Using PowerShell run the Grant-CsTeamsCallParkPolicy cmdlet to assign the custom call park policy to the new CAP account (e.g. cap@msteams.net)

        Grant-CsTeamsCallParkPolicy –Identity ‘cap@msteams.net’ –PolicyName ‘CAP’

        • To confirm the policy assignment(s) use the Get-CsOnlineUser cmdlet to view the account configuration.  (It may take a few minutes before the changes applied above will be reflected.)

        Get-CsOnlineUser -Identity ‘cap@msteams.net’ | fl Teams*Policy


        Sign In

        Now that the environment and first user account are configured the account can be logged into a Teams phone to see the resulting user experience.  A Poly CCX 500 IP phone was used in the following example.  Be aware that if the previous configuration was just completed then it may be required to wait several minutes before signing into the phone as all of the new policies and settings may still need to completely replicate throughout Microsoft Teams. 

        • Sign into a phone using the configured account (e.g. cap@msteams.net)


          Once the process completes and any welcome screens are dismissed then the primary user interface will be displayed which should reflect the Common Area Phone interface outlined at the beginning of this article.


            If the expected results do not appear then sign out and back into the phone again after additional time has passed.

            Note that the main screen shown above only shows the Call Park button and does not include the magnifying glass icon for the Search feature which was disabled in this example configuration on the IP phone policy currently assigned to this user account. 

            Sign Out

            To prevent a phone from simply being signed out by anyone and thus losing the ability to place calls the Sign Out option is hidden in an area only accessible by administrators.  (This behavior is true for both Common Area Phone and Meeting interfaces.)

            • Tap the Hamburger menu icon in the upper left corner and then select Settings.

            image     image

            • Select Device Settings > Admin Only and then enter the device’s administrator password.

            image     image

            • From the Admin Only menu select Sign Out and confirm the action.

            image     image

            Enterprise Application Consent Requests in Azure

            April 6, 2020 by · 8 Comments 

            A increasingly frequent experience for Microsoft 365 administrators and users leveraging various third-party solutions is the need to approve some sort of permissions request presented to them as Enterprise Applications (also know as Service Principals) while navigating a workflow.  A common example of this is when attempting to sign into a third-party website which leverages the Microsoft Identity platform for user authentication. Another growing scenario is related to how devices like phones and conferencing systems can connect to and access data in Microsoft 365 tenants.

            For readers of this blog this may already be somewhat familiar as Microsoft has been moving many aspects of their cloud to use Microsoft Graph and OAuth 2.0 authentication models. This now applies to many of the millions of IP phones and video conferencing systems in deployment today which can communicate directly to services like Exchange Online and Skype for Business Online.  (Most of the newest Teams devices already use native Microsoft clients and software which do not require additional enterprise applications.)

            As these applications can have different needs there are potentially different methods which can be used to approve these requests for consent to information and identities.  This article is meant to define some of the basics, explore various workflows, and highlight a relatively new option for handling a potentially growing amount of requests in an environment.


            As explained in this Microsoft article the overall consent experience can provide slightly different consent prompts.  For example take a look at the requests provided by the same application to two different users in the same tenant .

            image     image

            The highlighted difference in the requests above reflects the fact that the user on the left is assigned an administrator role with specific elevated rights pertaining to enterprise application management and the user on the right is a regular user account without those rights.  In short, the first user is allowed to consent to applications either on their behalf or on behalf of the entire organization while the second user can only provide consent on their own behalf.

              • If the administrator on the left simply chooses to accept the request as is and leaves the consent checkbox blank then the resulting consent would be the same as the only option the user on the right has.  This is referred to as User Consent.
              • If the administrator instead chooses to click the consent checkbox and then accept the request then this is known as Admin Consent and will mean that the app is now essentially pre-approved for all users in the tenant.

            When admin consent is provided then no other users in the tenant will be prompted to provide consent when they use a workflow which utilizes that application.  If several users in the tenant need to follow a workflow which requires this app then this may be the preferred approach.  Most third-party applications function fine in either model with the only difference being how many users are requested to provide consent.

            Some applications may require tenant-wide permissions though to operate and thus only the admin consent model is applicable.  In that case then only an application administrator would have the ability to accept it.  The consent option would also be omitted from the request window as it is not optional in that case.  A regular user attempting to approve the same app would instead receive a message stating that the app requires administrator approval.  The examples below show a request provided to an administrator (with the consent option suppressed) versus a regular user being informed that only an administrator can approve this app.

            image     image

            Controlling Consent

            The experience explained above is the default behavior in a Microsoft 365 tenant due to the fact that all users are allowed to consent to permissions requests on their own behalf.  But an administrator can change the default behavior by choosing to disable the ability for regular user accounts to consent to any enterprise applications, regardless of the scope of required consent.

              • To confirm the current configuration in a tenant sign into the Azure Portal as an administrator and then go to the Enterprise Applications > User settings section.
              • Note the status of the “Users can consent to apps accessing company data on their behalf” setting.  As seen in the example below this tenant has chosen to change the default behavior by disabling user consent.


            When user accounts are unable to provide consent to approve enterprise applications, even apps which only require consent only on behalf of the user, they will see the following message with no option to accept the request themselves.


            Providing Consent

            For tenants with this configuration there are a few different options available to approve consent requests depending on the desired outcome.

            Assign Admin Role

            If only a specific user or users will need to routinely approve applications in the tenant then it may be ideal for a global administrator to delegate the task of approving applications to them.  Other than Global admins there are currently three additional administrative roles which allow a user to provide consent to enterprise applications.

              1. Application adminFull access to enterprise applications, application registrations, and application proxy settings.
              2. Cloud application adminFull access to enterprise applications and application registrations. No application proxy.
              3. Application developer – Create application registrations and consent to app access on their own behalf.

            The first two roles above are application administrators and can approve requests with admin consent and user consent, while the last role simply allows the account to approve requests using user consent.  As the Application developer role provides the minimum set of rights from the options above it is likely ideal for simply just approving requests that regular users cannot.

              • Highlight the user account, select Manage roles, select Admin center access, expand Show all by category, and then enable the preferred role under the Identity category.  In this example the Application developer role will be assigned.


            The ability to consent to app requests only on their own behalf (which was previously available to all users with the original default configuration) is now provided to this user via the assigned Application developer role.  Thus when prompted for consent in the future this user will only be able to accept the request for permissions to actions as them and their accessible data.


            Once approved the Enterprise Applications section in the Azure portal can be used to locate and manage all apps in the tenant.  The Permissions section under a specific app will show whether and app was approved using admin or user consent.  The Granted by column includes a link which lists any user(s) in the tenant which have approved individual requests for this specific app.


            Manual Consent

            For regular user accounts which should not be granted any administrative rights in the tenant then an administrator will need to approve the requests on their behalf.  There are a few different approaches which can be used for an administrator to manually provide consent to a specific third-party application request.

              • When the user attempts to install the application an administrator could connect to their workstation remotely and then use the “Have an admin account?” link in the request to provide administrative credentials to approve it.
              • An administrator could simply follow the same workflow as the user on their own workstation to reach the request window, either while signed in with an appropriate administrator account or by using the Have an admin account? link to enter administrator account credentials if signed in with a regular user account.
              • An administrator can use a link which points directly to the consent prompt, which can often be provided by the third-party application’s vendor, in the format of https://login.microsoftonline.com/common/adminconsent?client_id=<ApplicationID>.  For example to approve the Poly One Touch Dial Service third-party application the direct URL would be:


            Admin Consent Requests

            Somewhat recently Microsoft has added an alternative workflow which simplifies the process for users and administrators alike. This configuration creates a reviewal workflow that lets users submit consent requests which administrators can then review offline and then decide to approve or deny. This new feature is functional today, although technically still in ‘Preview’ mode at the time this article was posted.

              • To enable the admin consent review workflow sign into the Azure Portal as an administrator and then go to Enterprise Applications > User settings.
              • Select Yes for the “Users can request admin consent to apps they are unable to consent to”.


            In order to save this change at least one user needs to be selected as a reviewer.

              • Click the Select admin consent request reviewers link next to the “Select users to review admin consent” setting.

            Only show users in the tenant which are assigned an admin role required to approve applications (Global, Application, or Cloud Application admin roles) will appear in the prepopulated list or search results.  This insures that only users who can actually approve requests can be selected to review requests.

              • Click the desired admin account(s) from the list to add them to the Selected administrators list and then click the Select button at the bottom.


              • If desired, modify the remaining settings to control the behavior of notification, reminder expiration, or consent request expiration, and then click Save at the top to commit these changes to the tenant.


            Now when a regular user account is presented with a consent request it will look different than any examples shown before.  Instead of receiving a message that the regular users is not allowed to approve requests they now will be able to enter a note and submit a request for an administrator to review.


            Once submitted the user is informed that an administrator has been notified to review the request.


            Any administrators currently selected as request reviewers will receive an email notification explaining the request along with a link to the Azure portal to review the request in more detail.


            Using either the link in the email or by browsing to Enterprise Applications > Admin consent requests in the Azure portal any pending requests can be reviewed and handled as needed by approved administrators.


            In the example above a request for the Poly One Touch Dial Service application appears in the list.  Highlighting the application in the list will display additional details as well as which user account submitted the request along with the provided justification from the user.


            The administrator has 4 options available to them at this point:

              1. Select Review permissions and consent which will place them into the admin consent approval workflow to accept the application.
              2. Select Block which will add the application to the directory but in a disabled status which also prevents any future consent requests .
              3. Select Deny which will deny the exiting request yet still allow any user to resubmit requests for the same application.
              4. Do nothing and ignore the request.  After the defined expiration (30 days by default) the request will be removed from the list.

            RealConnect Usage Reporting

            January 26, 2020 by · 6 Comments 

            In September of last year Poly released a new reporting capability, RealConnect Tenant Report, which is available to all RealConnect Service customers.  It includes a customizable dashboard of tiles which provide critical usage stats, helpful charts and graphs to indicate things like historical concurrency numbers or average call duration, and the ability to view and export individual call details.


            The data included in this reporting portal is only gathered from calls placed by standards-based SIP and H.323 endpoints to the RealConnect Service, which in turn bridges the call into a Microsoft Teams or Skype for Business meeting.  Details related to native Microsoft clients and devices, as well as PSTN attendees in these same meetings can be found in Microsoft reporting tools like the Microsoft Teams activity reports.

            Accessing the Portal

            While the back-end reporting system is part of the primary Poly Cloud Services (PCS) administration portal, the RealConnect Tenant Report portal was previously only accessible by going directly to: https://rc-reports.plcm.vc.  Recently though the various Poly service portals have been more closely integrated and the reporting portal is now available from within the primary administration portal: https://console.plcm.cloud. This provides a single sign on and single entry point to access the various administration and management utilities for the RealConnect Service as well as some other Poly cloud service offerings.

            In order to access the reports an account must be granted permissions first.  By default a primary contact email address would have been provided to Poly during the original order of RealConnect licenses.  That contact would have automatically been sent an invitation email to activate their account.

            Activate Initial Account

            This portion can be skipped if access to PCS has already been activated for the initial administrator.  If not, then locate the email entitled Welcome to Polycom Cloud Service Administration which would have been sent from the address cloud-service-team@polycom around the time of the initial RealConnect license order.  The Activate Your Account button in the message body can be used to activate the account.  (The “No account? Create one” link on the PCS portal is not applicable here and cannot be used to request an account.  If an the account is unknown or the invitation email cannot be located then contact Poly for additional assistance accessing your tenant.)

            The initial administrator account can be used to access the reporting portal, but the minimum requirements are the User Role called Device Operator.  To grant reporting access to other users in your organization simply adding a new user in the PCS portal under Administration > Users and grant the Device Operator role.  The user will automatically receive an invitation email to the provided email account.


            The RealConnect Report tile on the Poly Cloud Services home page can be used to access the reporting portal.


            If that tile does not appear as a choice in the menu then simply go to https://rc-reports.plcm.vc to access the site directly.


            The portal menu is comprised of two main sections: Dashboard and Calls.  (The RealConnect Invite Add-In menu can be ignored as it has nothing to do with the reporting portal and is simply a download link for a scheduling plug-in available for the service.  This may be relocated to a different Poly website at some point.)

            Once signed into the portal the main Dashboard page will appear which by default display information based on the last 7 days of activity.  The drop-down menu in the upper left corner of the dashboard can be used to select the displayed time frame among the following options: Today, 24 Hours, Week, Month, Three Months, Six Months, and Year.

            Call Summary

            Among the available widgets the most helpful when starting to troubleshooting call connection failures can be the Call End Reason and Active Calls Over Time chart.


            On the Call End Reasons pie chart the value “VTC ended call” should be the most common event, which simply indicates that something other than the service ended the call.  This most often is someone in the conference room simply hanging up the call, but this result could also include unintended disconnections caused by either the endpoint or transversal solutions like video registrars and corporate firewalls.  Other common values are “Failed getting meeting info” which could represent an incorrectly formatted call string, or “Meeting not found” which is usually when someone enters an incorrect or expired VTC conference ID in the call string or when prompted at the service’s entry queue.

            The Active Calls Over Time graph shows two sets of overlaid data points: “Total Joined” which is an aggregate number of all successful endpoint connections across all meetings for the data point on the graph, and “Max Concurrent” which is the maximum level of concurrent connections allowed into the service for all of the tenant’s meetings which may be active at that time.  Clicking on the name of either value in the legend will hide/show that data line on the graph, which is helpful in rescaling the Call Count axis on the chart to better view one value over the other.

            Call Concurrency

            As the service is licensed on call concurrency then understanding how calls are accepted and rejected due to license availability is critical.

            There are 3 important metrics to understand which are related to call acceptance behavior during maximum concurrency events:

            • License Overage: The total number of calls attempted during a time when all available concurrency licenses are already in use.
            • Rejected Calls: The total number of calls rejected for lack of an available license at that time.
            • Surged Calls: The total number of calls which were allowed to join the meeting in spite of license capacity being reached.

            The first two items are self-explanatory but Surged Calls warrants some additional detail.  The RealConnect Service includes a feature called “Soft Ceiling” which means that when a tenant’s license capacity has been reached the service will still allow calls to connect for up to an additional 50% of the existing license capacity.  Thus, if a tenant has purchased 50 licenses then their true ‘hard ceiling is actually 75 concurrent calls (50+25).  In this example allowed call attempts while the current concurrency count is between 50 and 75 will be recorded as Surged Calls.  And call attempts placed when above 75 will be rejected and recorded as Rejected Calls.

            The one caveat to be aware of though is that this soft ceiling feature is only available for customers with 6 or more RealConnect licenses activated in their tenant.  Free trials of 5 concurrent licenses or customer receiving or purchasing 5 licenses or fewer will not have a soft ceiling, meaning the maximum call concurrency will be equal to the number of licenses owned.  In this example calls placed while the tenant is a maximum concurrency will be rejected and recorded as Rejected Calls.

            The data points on the chart indicate a scope of time, from as little as 1 hour (when viewing data for only a day) to as much as an entire day (when viewing data for a year).  This explains why a single plot point on the chart can indicate a Max Concurrent value of 4 when the Total Joined value on the same vertical axis can read as 24 and yet no surged or rejected calls are reported.  In a data set for as little as an hour it is possible for several meetings to have occurred with multiple endpoints joining and then hanging up, all without ever reaching maximum concurrency and triggering a license overage event.



            The Devices Pie and Devices Bar charts include categories for each manufacturer based on the names provides in the User Agent strings, which most often identifies the endpoint itself but could actually be based on the type of on-premises video infrastructure used to route the call to the service (e.g. Polycom or Cisco).



            The Top Conferences and Call Duration charts provide a glance at the most attended meetings and how those meetings stack up against all other meetings in terms of duration.  Note that Call Duration is not a measurement of the length of the overall Skype or Teams meeting, but simply the length of time a VTC stays connected for each call into the service.  The example data below indicates that the majority of calls are roughly 30 minutes to one hour long.



            Any of the several widgets on the dashboard can be hidden or rearranged by clicking the Edit button at the top of the dashboard view.  For example another column can be created by dragging widgets like License Overage, Rejected Calls, and Surged Calls up from the bottom of the view.  Placing these next to the Active Calls Over Time graph makes it easy to see this information without scrolling the screen up and down.



            The Calls menu includes additional views into the available call data with a summary page that is very similar to the dashboard view, a graphical map which displays where calls are originating from, and an exportable list of individual call attempts which can be used for additional troubleshooting.  All of these views, like the dashboard, can be toggled between the available time frame options from a day to a year.


            This view is similar to the dashboard as it provides a simple view for quickly scanning general statistics.  It contains a fixed subset of the total available widgets though so it is a bit redundant to the dashboard.


            An interactive map provides geographical totals indicating the source location of calls placed in the selected time frame.  For congested areas the bubbles can be clicked to zoon the map in for a closer look at the region.



            Other than the dashboard this is where most time will likely be spent in the portal: looking at individual call detail records. The default view displays every call, successful or not, which has been attempted into join either a Skype for Business or Teams meeting hosted by that tenant.  Calls placed into either the entry queue (<TenantKey>@*.plcm.vc) or directly into a meeting (<TenantKey>.<ConfID>@*.plcm.vc) and recorded here if the tenant’s key matches the key provided in the call string.  Calls using an incorrect Tenant Key would not be matched to this tenant and thus would not appear in the tenant’s own reports.


            • Regardless of the selected time frame the most recent 100 records from the call log will be displayed by default.  Scrolling down to the bottom of the page will load more records into memory and display them on the page, or the LOAD ALL button can be used to load the entire list of call records for the selected time frame.  Once the desired set of records are loaded they can be exported into JSON and CSV formats for easier viewing in external applications.

            The example above includes various types of common End Reason results which are covered in the next section.  What should be obvious from the list above though is that the tenant’s licensing appears to have expired sometime after the last successful call on 1-24-2020.

            To see additional Call Details information for a specific call in the list click simply the chain link icon in the first column of the table in the desired record.  This call did not complete successfully due to a lack of valid licenses in the tenant (either missing or expired) as described in the callFailed section.


            The remainder of the call records includes additional information like dial string used in the call attempt, the protocol used (SIP vs. H.323), source location details, timestamps, call end times, the reason the call was ended, and more.

            Call quality statistics are also provided in the record but only if the call was successfully connected into a meeting and stayed connected for at least one minute.  This data is included in the VTC section and is broken down into additional sections based on media type and direction.  The applicable categories include audioIn, audioOut, contentIn, contentOut, videoIn, and videoOut.


            As the RealConnect service is the source of this data (not the endpoint) then the directions indicated are from the point-of-view of the service.  Thus, “In” statistics are what the service sees coming in, meaning these are streams from the endpoint to the service.  “Out” statistics are what the service is sending out, thus streams from the service to the endpoint.  As stated earlier this data is only representing the call path between the VTC and the service; any signaling or media statistics related to communications between the service and the Microsoft Skype or Teams platforms as well as those native clients is not included in this portal.

            Of all the metrics available in the call data arguably the most important are the packet loss values, given that this service resides in the Microsoft Azure cloud and it most likely reached via the public Internet for most calls.  For this reason the call record also includes a chart summarizing Packet Loss Per Minute at the bottom of the page.

            This example shows a call which lasted just over one hour that experienced only 11 lost packets, and all occurrences were recorded on the blue ‘”To RealConnect” line.


            By reviewing the VTC details in this call a total of 1,365,861 packets were reported as sent/received across both audio and video session.  The 11 lost packets all occurred in the videoIn session, meaning they only occurred on the video stream coming from the VTC up to the service.

            Additional Examples

            Beyond the basic examples shown above there are some other common scenarios which can be identified by reviewing the data on the dashboard or looking deeper into call detail records.

            License Overage

            In the this example a tenant has reported that some, but not all of their call attempts into the RealConnect Service are being rejected.

            Looking at the Active Calls Over Time graph in the default Week view on the dashboard page the data points appears to indicate that this tenant may only contain 2 concurrent licenses.


            Clicking on the Total Joined legend item will hide that data from the graph, resulting in a focused view on the remaining data: Max Concurrent.  Note that all data points indicate a Call Count value of either 1 or 2.

            Additionally the following values displayed towards the bottom of the dashboard can be used to understand overage behavior that occurred during this time window.  Based on the definitions provided earlier in this article the data below shows that all call attempts which occurred when the tenant was already at license capacity were rejected.  If any additional calls had been allowed while at license capacity then the Surged Calls value would not be zero.


            As all signs seem to point to only 2 licenses being available for this tenant then the way to confirm that is to have a Global Administrator for the Office 365 tenant sign into the RealConnect Service’s provisioning portal to view the current licensing status.


            In this tenant’s case it may be advisable to add additional RealConnect licenses to address the need for more than 2 conference rooms to use the service at the same time.  By switching to a larger data scope like the Three Month view additional historical data can be used to help determine what the appropriate suggested licensing count might be.


            In this example it is clear that this tenant needs to add some additional licenses, but to determine how many licenses requires a closer look at the data.  The Calls > List menu can be filtered by call events to view ever rejected call.

            • From the navigation menu select Calls > List and then click the Show Filter button.
            • Under the License Use drop down menu select All Overages and then click Apply Filter.

            By reviewing the individual calls it can be determined if the 64 overage events in this 3 month time period are indicative of the several conference rooms trying to join the same meeting or different meetings at the same time, or are instead largely represented by repeated failed attempts from the same conference room to join a single meeting.


            This data can further be exported into CSV and imported in something like Microsoft Excel to perform additional queries and reporting on to further scrutinize the data for patterns.  Something worth noting in the data shown above is that the From field shows the same value in all of these entries.  This could indicate that it is the same system placing all of these calls, but given that the value is specifically ‘Teams.Trio’ it is more likely that these are different room systems.  The default value for the reg.X.address parameter provided in several configuration templates for the Poly Trio is ‘Teams.Trio’, so one cannot easily decide if these calls are from one or many different Trio installations.  To avoid this it is recommended to define a unique name on each Trio to help determine the source of calls into the RealConnect Service.

            License Overage with Soft Ceiling

            Here is another tenant in a similar scenario of placing calls while at license concurrency but is successfully leveraging the Soft Ceiling feature.

            The Active Calls Over Time graph is displayed over a Six Month period, with only the Max Concurrent data visible.


            Based on what was explained in the previous example the scenario here shows the majority of maximum concurrent events approaching and eventually exceeding the 100 mark, with a few notable exceptions: peaking sometime in December followed immediately by a massive dip in utilization which occurred during the holidays.  The tenant in this example is actually licensed for 100 concurrent connections, and as shown by the graph and the zero value for Rejected Calls they are appropriately sized and currently leveraging the Soft Ceiling feature by staying under the allowed 150 maximum connections.  Based on the historical growth though additional licenses will likely need to be added to prevent any calls from being rejected.

            Managing Microsoft Teams Phone Policies

            November 2, 2019 by · 32 Comments 

            As Microsoft and their certified device partners gear up to bring more native Microsoft Teams IP Phones to the market the management and customization of the device experience is also being expanded upon.  This article introduces the current capabilities of a new PowerShell cmdlet created specifically to manage the user experience of these devices.

            For some time the Set-CsIPPhonePolicy cmdlet has been available in the Skype for Business Online PowerShell module, which initially only applied to Lync Phone Edition, but was later also used with 3PIP-qualified devices (like VVX phones).  That cmdlet only controls a single globally-applicable set of parameters though, so it was not possible to create different sets of behaviors which could be applied to different groupings of phones.

            With Microsoft Teams a new cmdlet named Set-CsTeamsIPPhonePolicy has been introduced, which is still included in the Skype for Business Online PowerShell module alongside all other Teams platform administrative cmdlets.  At the time of posting this article Microsoft has not yet published any official documentation for this cmdlet, but the functionality is already present in Office 365 tenants.

            The most obvious change between the Skype IP Phone functionality and the what now exists for Teams devices is there is also a New-CsTeamsIPPhonePolicy cmdlet which allows the creation of custom policies in addition to the default global policy (which can be modified if desired).  This addresses a long overdue customer request to assign unique parameter values to different categories of phones, be it by location, department, use-case, etc.  Alongside this cmdlet is the requisite Grant-CsTeamsIPPhonePolicy cmdlet which is used to assign

            Currently there is a very limited set of parameters available to actually control phone behavior, but the groundwork has been laid to start defining unique policies and then assigning these polices to user accounts to control their IP phone experiences.

            Investigating the New Cmdlets

            To take a closer look at this new capability launch PowerShell and import the Skype for Business Online module (if installed) as outlined in numerous articles like this.  Then list out the available cmdlets in the imported module that match the ‘TeamsIPPhone’ naming scheme.

            • Launch PowerShell and connect to Skype for Business Online using an account which sufficient administrative rights in the desired tenant.

            Import-Module SkypeOnlineConnector
            $sfbo = New-CsOnlineSession -UserName jeff@msteams.net
            Import-PSSession $sfbo

            • Enter the following command to list all available cmdlets matching the desired string.  Take note that the name of the module is dynamic and will be unique for every imported session, so use the name shown after successfully importing the Skype module (e.g. tmp_iwwu1ido.jpc).

            Get-Command -Module tmp_iwwu1ido.jpc | Where-Object {$_.Name -like “*TeamsIPPhone*”}

            The results should look like the following:


            The five new cmdlets could logically be grouped as:

            • [Get|Set]-CsTeamsIPPhonePolicy – used to review and modify the parameters of an existing global or user policy.
            • [New|Remove]-CsTeamsIPPhonePolicy – used to create and delete user policies.
            • Grant-CsTeamsIPPhonePolicy – used to assign users to a specific user policy which will override the Global policy’s behavior.

            Notice that there is no companion cmdlet for the ‘Grant-’ cmdlet.  This is because, like all other Skype and Teams policy-related cmdlets, the process to remove a user from an assigned user policy is simply to run the same cmdlet again, but instead assign the user to a $null policy.  Users can only be assigned to user policies and cannot explicitly be assigned to a global policy; assigning them to a null policy will return them to the default behavior of adhering to the global policy.

            The next step into investigating the configuration would be to take a look at the default Global policy.

            • Run the Get-CsTeamsIPPhonePolicy cmdlet to list all defined policies and their current settings.



            The default configuration in all Office 365 tenants should simply return a single Global policy with the parameters shown above.  As previously mentioned, the list of configurable parameters in these policies are currently quite limited.  In fact, at the time this article was written there are only two behaviors which can be controlled: the primary client experience via the sign in mode, and the inclusion of the Search function on Common Area Phones.

            As best practices typically dictate it is generically recommended to leave the default global parameters as they are and create new user policies to customize any behavior.  Be aware that the only available policy types here are global and user, so if there is a behavior which would be deemed desirable for all users then it would be easier to manage this change at the global level then having to manually add every new user account in the tenant to a specific user policy.  This would likely become more applicable if/when future parameters are added here that make sense to modify at a tenant-wide level, as the available settings are not really good candidates for a tenant-wide change.

            Now that some parameter values have been discovered the piece to uncover is what are the possible configuration options for these settings?  A simple way to find that out in PowerShell is to attempt to set a parameter to an obviously invalid value and when the cmdlet fails the error response will return the list of accepted values.

            • Run the Set-CsTeamsIPPhonePolicy cmdlet using a bogus value (e.g. NotARealParameterValue) for the SignInMode parameter

            Set-CsTeamsIPPhonePolicy -SignInMode “NotARealParameterValue”


            This invalid command has returned a list of possible values for the parameter which includes UserSignIn, CommonAreaPhoneSignIn, and MeetingSignIn.

            • Run the same command as above, but against the SearchOnCommonAreaPhoneMode parameter.

            Set-CsTeamsIPPhonePolicy -SearchOnCommonAreaPhoneMode “NotARealParameterValue”


            This parameter is a simple ‘on/off’ switch as the only possible values are Enabled or Disabled.

            Sign In Mode

            What the SignInMode parameter controls is essentially the overall user experience on the Teams device Android client.  There are three different options which provide three unique interfaces targeted at three specific, common use-cases: regular users, shared meeting rooms, and common areas.  The available parameter values are as follows:


            The UserSignIn setting provides the full client experience which is typically targeted for regular phone users.  Unless any changes are applied to the tenant using the cmdlets and guidance in this article then all user accounts signing into all Teams IP phones will receive this experience as the default global policy is set to this value.

            The latest phone software no longer prompts the user during sign-in to select if they want a Personal or Shared experience (as outlined in a past article).  The account type which is signing into the phone does not matter, so whether it is a user mailbox or room mailbox or if it has been enabled in Skype for Business using the CsMeetingRoom cmdlet set is irrelevant.  Additionally, the type of Office 365 license applied to the account has no effect here either.  Thus, an account configured as a room mailbox and assigned a Common Area Phone license (which is a bad idea for other reasons) will still show the full client experience when signing into a Teams phone in this example tenant based on the fact that only the single global policy exists which is set to UserSignIn mode.  In short, the overall client experience is controlled only by this PowerShell policy, and nothing else.

            This mode provides the full client experience which includes the Calls, Calendar, and Voicemail screens, the Search button, the Call Park button, and the New Meeting/New Call buttons, as shown in the following screenshots from a Poly CCX 600 phone.







            Note that the screenshots above are using the Dark Theme option, which is not the default appearance. Once a user signs into a phone then they can enable Dark Theme directly from within the client’s Settings menu; this is not a setting which is currently controllable by an administrator.


            This setting is meant to be used on phones which are located in conference rooms where the primary use case is joining scheduled meetings.  In order to utilize this mode on a phone a new user policy must be created so that it can be assigned to the user account which will be signed into the phone.

            • Using the New-CsTeamsIPPohnePolicy cmdlet create a new user policy and configure the sign in mode for meeting devices.

            New-CsTeamsIPPhonePolicy -Identity “MR” -Description “Meeting Room Phone User Policy” -SignInMode MeetingSignIn


            • Assign the new meeting room policy to the desired user account.

            Grant-CsTeamsIPPhonePolicy -PolicyName “MR” -Identity “trio8500@msteams.net”

            When logging into a Teams phone using this account the interface will default to showing only the Calendar view, and the Dial button if the account is Enterprise Voice enabled with the requisite Phone System licensing.  Some of the available options in the client are hidden from the user, like the Sign Out menu item has been relocated to the Settings > Device Settings > Admin Only menu which is password-protected.  The Search button is still available, but the Call Park button has been removed.

            The following screenshots where taken from a Poly Trio 8500 using the account which was added to the Meeting Room policy in the previous steps.  For comparison’s sake images from both the default theme and dark theme are shown below.

            image     image


            This setting provides to most restrictive user experience intended for phones in common areas which may even be placed in public area.  In order to utilize this mode on a phone another new user policy should be created so that it can be assigned to other user accounts.

            • Using the New-CsTeamsIPPohnePolicy cmdlet create a new user policy and configure the sign in mode for common area devices.

            New-CsTeamsIPPhonePolicy -Identity “CAP” -Description “Common Area Phone User Policy” -SignInMode CommonAreaPhoneSignIn –SearchOnCommonAreaPhoneMode Disabled


            The SearchOnCommonAreaPhoneMode parameter can be set to either Enabled or Disabled, whichever is preferred.

            • Assign the new common area policy to the desired user account.

            Grant-CsTeamsIPPhonePolicy -PolicyName “CAP” -Identity “ccx400@msteams.net”

            When logging into a Teams phone using this account the only the dial pad will be displayed along with the Call Park button. The Search function can selective be hidden or shown via the other setting in the policy.

            image     image

            • To allow the Search function to be used on Common Area Phones simply modify the newly created user policy to enable that feature.

            Set-CsTeamsIPPhonePolicy -Identity CAP -SearchOnCommonAreaPhoneMode Enabled

            Once the policy change is picked up by the phone it should display the Search button.

            image     image

            Review Configuration

            • To view the existing policy configuration simply run the Get-CsTeamsIPPhonePolicy cmdlet to list all defined policies and their current parameter values.



            • To quickly check which users have been assigned to a user policy run the following command to list all users in the tenant, showing only the User Principal Name (UPN) and TeamsIPPhonePolicy parameters.  (Users with no value set for the phone policy will adhere to the Global policy.)

            Get-CsOnlineUser | ft UserPrincipalName, TeamsIPPhonePolicy


            Poly Group Series with Microsoft Teams

            October 4, 2019 by · 68 Comments 

            This article covers how to successfully configure a Poly Group Series to connect to Microsoft Teams meetings.  While several different options, both native and interoperable, were recently outlined for the Poly Trio the Group Series approach is much simpler.  This is due to the facts that (a) there are no applicable audio-only scenarios as the Group Series is not a SIP-based phone at its core, and (b) there are no native Teams options for the Group Series as it does not run Android or Windows, and thus cannot directly run either of the device apps provided by Microsoft to their device partners.

            This means that there is only a single path to Microsoft Teams for the Group Series: an interoperability service like RealConnect.  Thus, the few potential configuration scenarios have more to do with Skype for Business connectivity than Teams.

            This article is only applicable to a standalone Group Series deployment. If a Group Series unit has been integrated with a Trio, meaning it is deployed as a Visual Pro, then the aforementioned Trio article should be used as guidance.  In this scenario the registration and call control is handled by the Trio, not the Group Series/Visual Pro.

            The valid configuration scenarios fall into two categories:

            1. Interop Only – Both Teams and Skype meetings are joined via the interoperability model by using the RealConnect Service.
            2. Mixed Mode – While the RealConnect Service must be used for Teams meetings, Skype meetings will instead connect natively.

            The first option provides for the most configuration flexibility as the Group Series supports both H.323 and SIP, so either protocol can be used to join Teams meetings via the available interoperability solutions: RealConnect for Clariti or the RealConnect Service.

            When Skype for Business meetings also need to be supported though, then there are two different options which could impact which protocols are available to use for connecting into Teams meetings.  Essentially, if Skype meetings will be joined natively, then SIP is occupied by the registration to a Skype for Business Server, or Skype for Business Online.  Only H.323 remains available to join Teams, as an attempt to call into an interoperability service for Teams using a SIP dial string would fail as the SIP registrar is Skype and would not understand that call, nor be able to route it correctly.  If RealConnect will be leveraged for joining both Skype and Teams meetings then either SIP or H.323 can be used.

            The configuration examples provided in this article will leverage a single Microsoft Office 365 tenant with accounts enabled and homed in Skype for Business Online and Exchange Online.  Additional configuration in the management portal for the OTD service (which is not covered in this article) is required when using room mailboxes homed on an Exchange Server deployment.

            Calendar Configuration

            The Calendaring Service configuration will be the same across all of these scenarios as, unlike the Trio, the Group Series does not natively support the ability to recognize RealConnect meeting invitations across all possible formats.  This is what the One Touch Dial (OTD) service is designed to address, for multiple different endpoint types.

            In many cases the Group Series may already be configured to point to Exchange Online, especially when the system is natively registered to Skype for Business.  If the resource mailbox leveraged by the Group Series has been enabled for authentication, or if a service account has been delegated permissions to the mailbox then those credentials would be included in the calendaring configuration.  In these cases only a single change is needed to the configuration: pointing the system to the Poly One Touch Dial service instead of directly to Exchange Online.

            Also make sure to confirm that the Exchange mailbox is correctly configured, as outlined in this article, paying close attention to the DeleteComments parameter.  It is common for a previously created resource mailbox to be left in its default state which would prevent the endpoint from displaying a functional Join button on Skype and Teams invitations.

            • Connect to the IP address of the Group Series in a browser (e.g. to access the web management interface.
            • Navigate to the Admin Settings > Servers > Calendaring Service menu and, if not already enabled, select Enable Calendaring Service.
            • Enter the primary SMTP address of the resource (or user) mailbox intended for use with the Group Series (e.g. group@msteams.net).
            • Leave the Domain field blank and then in the User Name field enter the User Principal Name of the account with appropriate permissions to the mailbox.  This would either be the mailbox’s own identity (e.g. group@msteams.net) or a service account which has been delegated at least ‘Reviewer’ rights to the ‘Calendar’ folder of that mailbox.  Enter the Password for the provided user account.
            • Ignoring the Auto Discover option manually enter the address of the Poly One Touch Dial service (otd.plcm.vc) in the Microsoft Exchange Server field and then click Save.


            After applying the changes the Registration Status will initially report Not Connected, but within 30 seconds or so it should update to Registered.

            • Once connected to the mailbox check the calendar display on the Group Series monitor and/or touch panel to confirm that any scheduled Skype or Teams meetings appear and are showing a Join button.


            At this point the Group Series is ready to attempt a call using One Touch Dial, but the remaining configuration options will dictate how those call attempts are actually handled.

            Scenario 1 – Interop

            The ability to actually connect the call after it has been placed falls primarily on network connectivity which can vary across different infrastructure or cloud service arrangements.  The system could either be unregistered or registered to one or more video infrastructure platforms (Poly RealPresence, Cisco VCS, etc) or cloud services.

            Given that a variety of options exist this article will only cover one: using a standalone Group Series along with the RealConnect Service.  No standards-based registrars will come into play, and the communications path to the service in Azure is available by traversing a standard firewall which allows outbound traffic to Azure over the required ports and protocols to successfully reach the service.

            In this scenario either or both SIP and H.323 can be enabled and used for placing calls into the RealConnect Service.

            H.323 Configuration

            Perform the following steps to enable H.323 for outbound calling, if desired.

            • Navigate to the Admin Settings > Network > IP Network menu and then expand the H.323 section.
            • Select Enable IP H.323.
            • Enter the name which will be used to identify the system in Skype and Teams meetings in the H.323 Name field (e.g. Jeff Schertz GS500).
            • Leave the H.323 Extension (E.164) field blank. (It is not required for calls into the service, but it can be populated for other H.323 use cases if desired.)
            • Set Use Gatekeeper to Off (unless an H.323 registrar is available) and then click Save.


            SIP Configuration

            Perform the following steps to enable SIP for outbound calling, if desired.  The majority of the settings will typically apply to whether or not a standards-based SIP registrar is available for use, or if unregistered calls are preferred over a specific transport protocol.  The system’s default Auto configuration options can be used, but in the example below the configuration is specifically set to utilize unregistered, secure TLS communications.

            • Navigate to the Admin Settings > Network > IP Network menu and then expand the SIP section.
            • Select Enable SIP.
            • Select Specify for the SIP Server Configuration option and then select TLS as the Transport Protocol.
            • Leave the BFCP transport preference set to Prefer UDP (as this is the better option for content sharing media than TCP).
            • Leave the Registrar Server Type to Unknown and then leaving the remaining fields blank click Save.


            Dialing Preference

            This configuration controls which protocol is used by default when joining a meeting by using the Join button on the calendar or when using the Place a Call option on the Group Series user interface with the remote control or a touch device.

            If a call is placed using the Manual Dial option on the Place a Call menu in the web management interface then a drop-down menu can be used to override the automatic behavior (which follows the defined dialing order preference) and use the selected protocol when the call is placed.


            • Navigate to the Admin Settings > Network > Dialing Preference menu and then expand the Dialing Options section.
            • Select the preferred protocol in the Video Dialing Order Preference 1 field (e.g. SIP).


            One Touch Dial Configuration

            The configuration of the OTD service behavior for the current tenant should be verified to validate the desired behavior of the Group Series when receiving meeting invitations which includes additional information for using the RealConnect Service.

            • Sign in to the OTD administration portal (https://otd.plcm.vc) and then go to the Settings menu.
            • Verify that the appropriate Poly RealConnect options are enabled under the Recognize Meeting Invitations sections.


            The configuration above will trigger the Group Series to utilize the RealConnect Service for all Skype and Teams meetings which include the pertinent info for RealConnect.

            The first setting will tell OTD to look for information provided in a Skype invitation under the “Join with a video conferencing device” section, and if that information exists then to parse the dialing information (Tenant Key, Conference ID, and v.plcm.vc FQDN) to assemble the correct dial string and insert those instructions as a token into the invitation before relying the message back to the endpoint.  The Group Series will ignore any of the original information embedded in the invitation and use the token provided specifically by OTD.

            The second setting does the same as above, but will look specifically for the string “<ConfID>@h.plcm.vc” in the administrator-defined footer of the meeting invitation as well as the Audio Conference ID provided in the body.

            The third setting functions identically to the first, except that the provided hostname in a Teams meeting invitation does not necessarily need to be t.plcm.vc, which is the common default.  If a custom hostname (e.g. video.msteams.net) is configured correctly then the service will parse that information to assemble the correct dial string.

            Scenario 2 – Mixed Mode

            This scenario leverages the RealConnect Service to join Teams meetings, yet still connects directly to Skype for Business Server or Online meetings natively.  The SIP configuration must be used to natively register to the preferred Skype for Business platform, leaving only H.323 as a viable option for connecting to the RealConnect Service to join Teams meetings.

            SIP Configuration

            In the event that the Group Series has not already been integrated with Skype for Business, then previous articles includes more detail on registering a Group Series to Skype for Business Server or Online.

            In this example the same account (group@msteams.net) which was used for the mailbox is also enabled for Skype for Business Online.


            H.323 Configuration

            The H.323 configuration shown here is the identical configuration as what was provided earlier in the Interop scenario.


            Dialing Preference

            This step is critical to perform compared to the previous scenario where it did not really matter which protocol was used (assuming sufficient network connectivity was available for both).  Because SIP is occupied in this scenario for the Skype for Business registration then the preferred dialing option must be set to H.323 for RealConnect calls to be routed correctly.

            • Navigate to the Admin Settings > Network > Dialing Preference menu and then expand the Dialing Options section.
            • Set the Video Dialing Order Preference 1 to IP H.323.


            One Touch Dial Configuration

            Of equal importance is to properly configure the OTD portal to allow Skype meetings to use the native SIP registration path.  Because the Group Series is unable to ignore the token provided in the invitation processed by OTD, then if any Skype Meetings contain details to join from a video conferencing device this will force the call to go to RealConnect, and not use the desired native SIP registration path to Skype for Business.  To resolve this OTD must be configured to ignore Skype meeting invites and not process them.  Doing so will relay the message unedited, allowing the Group Series to recognize and use the embedded Skype Meeting URL for the ‘Join’ button action.

            • Sign in to the OTD administration portal (https://otd.plcm.vc) and then go to the Settings menu.
            • Disable one or both of the Poly RealConnect with Skype for Business options under the Recognize Meeting Invitations section.


            Adding One Touch Dial Administrators

            September 25, 2019 by · 2 Comments 

            This brief article outlines how to provide administrative access for additional user accounts to the management portal for the Poly One Touch Dial (OTD) Service.  Typically when initially onboarding the service for a tenant one or more Microsoft online identities can be provided with the order, and these identities are enabled as administrators for the organization during the order processing stage.  Yet, often after an environment has been enrolled in the service additional administrators may need to be added.  Previously this required contacting Poly support to request additional accounts to be enabled as administrators in the One Touch Dial portal for their tenant, but this is now something which can be performed directly by an existing tenant administrator.

            Understand that in order to perform this task for the OTD service portal the configuration is actually present in a different, central portal.  To recap there are currently up to three different management portals which might be used to manage a RealConnect Service tenant:

            1. Poly Cloud Services portal – https://console.plcm.cloud
            2. Poly One Touch Dial portal – https://otd.plcm.vc
            3. Poly RealConnect Service portal – https://webapp.plcm.vc

            In this article the first portal (Cloud Services) will be used to enable administrators for the second (OTD).  (The third portal is not used, and is only referenced here for posterity.)


            • Sign in to the Poly Cloud Services portal using the credentials of a local account or (if already integrated) a Microsoft Office 365 account which has already been granted access to this portal.


            • Select the Administration tile from the home page and then select Users from the navigation menu.


            • Click the Add button and then enter the Email Address of an existing account in the same organization which needs to be granted access to the OTD portal.  Select the OTD Admin user role and leave the Sign In Account setting at Enterprise Only, then click Save.


            • Confirm that the new user account appears in the user list and includes the appropriate permission.


            At this point the configuration has been applied, but may take a few minutes before the OTD service updates its own database to reflect the changes.


            • After a couple of minutes open the One Touch Dial portal and click the Sign In button.
            • Select Sign in with Microsoft and then either enter or select the desired account when prompted by Microsoft.


            • If the previous configuration steps were performed correctly and ample time has passed, then the OTD dashboard view should appear once signed in with the new user.


            • If the configuration was unsuccessful, then the following error will be displayed for an authenticated account which has not been properly assigned as an administrator for any organization.


            Next Page »