Upgrading Microsoft Teams Desk Phones

May 21, 2020 by · 20 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 · 20 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 · 26 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 · 27 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 · 59 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.


            Exchange Resource Mailbox Configuration for Meeting Rooms

            August 12, 2019 by · 7 Comments 

            Several previous articles on this blog have outlined the required configuration of Exchange mailboxes for use with native Microsoft meeting room solutions for Microsoft Teams and Skype.  There are also some articles which cover the configuration for mailboxes for use with standards-based video conferencing solutions from Poly and Cisco which support Microsoft Exchange to display and join scheduled Skype and Teams meetings.

            All of these articles share a common and often overlooked configuration setting that is worth spending a little more time on: the DeleteComments parameter as defined on Exchange mailboxes via the Set-CalendarProcessing PowerShell cmdlet.  This parameter must be set to a value of “$false” in order for most conferencing solutions to properly process the various type of meeting invitations.  Yet the default value on this parameter for mailboxes in Exchange is ‘$true‘.


            What this means is that Exchange will delete the entire contents of the message body when it arrives in this destination mailbox.  That can prevent various meeting room solutions from joining the meetings from the calendar.  In these scenarios the resolution is to simply run the Set-CalendarProcessing cmdlet against the affected resource mailbox to disable the DeleteComments parameter.

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

            As this change only applies to inbound messages then a new meeting will need to be created and booked with the updated resource mailbox in order to see any improvement.  Existing meetings in the mailbox’s calendar, individual or reoccurring, would still be missing the previously-stripped information in the body of the message.


            This is a critical configuration parameter which is often times the only thing preventing various meeting room solutions from successfully connecting to Microsoft Teams or Skype meetings.  Issues are typically more prevalent when using standards-based video conferencing systems with Cloud Video Interop (CVI) or other on-premises interoperability solutions, like RealConnect for Clariti, but native endpoints can also sometimes be negatively impacted.

            The root of the issue is that Skype and Teams invitations includes important meeting information that is used by various clients and services differently.  Information can be stored in the body of the invitation, where it can be seen by people and machines alike, and/or in the header of the email where it is hidden away from people, but not machines.  And as meeting invitations are forwarded, both internally and externally between different organizations, some of this information can often be modified or even stripped completely from the message.  This could prevent meeting rooms from joining scheduled meetings.

            One example is in the earlier days of Microsoft Lync many of the native software clients and devices like Lync Phone Edition would provide the single-click join experience by looking for information stored in a specific parameter in the invitation’s header.  But, if that invitation came from a different organization then the ‘Join’ button would not appear on those meetings in the calendar.  This was due to fact that external delivery of that message would usually strip the needed MAPI properties in the header as the sender organization’s SMTP platform typically had Transport Neutral Encapsulation Format (TNEF) disabled.  This was problematic as the workaround was something which must be applied in the sender’s environment, not on the receiving end so asking every other organization to apply these changes is not very scalable.  Microsoft eventually addressed this issue in the various Lync clients by adding support for parsing additional information in the meeting invitations to correctly locate and join the scheduled meeting when the header information was lost.  This was done by simply looking at the body of the message to identify the Skype meeting URL (e.g. https://meet.domain.com/user/ID) that is embedded in the “Join Skype Meeting” link.

            Other solutions are also programmed to look at meeting information that is provided in the body of the message.  Poly Trio is one endpoint example and the Poly One Touch Dial (OTD) service is another.  Retaining the body of the meeting invitation is especially important when dealing with the various CVI solutions as their companion message processing services will look for information which they expect to see in the body.

            To illustrate this take note of just how much different information is provided in the body of a Skype meeting or Teams meeting invitation.  Embedded URLs for native clients, audio conferencing IDs which several third-party solutions can leverage, and video conferencing details provided for accessing the various CVI solutions.


            When a client or device needs to leverage any of the information above it obviously needs to be available in the invite.  Just because it was included in the original invitation though does not necessarily mean that it will still be intact by the time a recipient sees it, which brings the discussion back to the Exchange mailbox configuration.

            Regular user mailboxes (which do not normally include automatic processing rules like resource mailboxes) will typically not have any issues seeing this information, thus when devices are using a regular user account everything seems to work fine.  But when tested with an existing resource mailboxes in an organization is when issue can occur, most often because when the resource mailbox was originally created for a regular conference room there was no device using that mailbox and no additional custom configuration was applied.  The mailbox was only setup to perform standard resource booking duties, and typically no one ever looks at the invitation details in the rooms account, it is only used as a placeholder for reserving the room.  The default behavior in Exchange Server and Exchange Online has always been to trim the amount of unneeded data on every invite sent to a resource mailbox.

            The configuration can be verified by looking at specific Calendar Processing parameters on mailboxes which were created using different methods.  Mailboxes created using basic process like the Room & equipment section of the Microsoft 365 admin center or using “New-Mailbox –Room” in PowerShell will be setup by default to wipe the body of any emails sent to those mailboxes.

            • Use the following Exchange PowerShell cmdlet to review the related parameters on a standard resource mailbox in the organization (e.g. room1@msteams.net).

            Get-CalendarProcessing -Identity “room1@msteams.net” | fl Add*,Delete*,Remove*


            Note that DeleteComments is set to True in the output above.

            But when a resource mailbox is created using the correct process it should have had the DeleteComments parameter specifically disabled, along with a few other required and optional changes.

            • Use the following Exchange PowerShell cmdlet to review the related parameters a customized resource mailbox in the organization (e.g. vtc1@msteams.net).

            Get-CalendarProcessing -Identity “vtc1@msteams.net” | fl Add*,Delete*,Remove*


            Because this second mailbox was created using the suggested approach then meetings sent to it will not have the invitation details removed as DeleteComments is set to False.

            Other recommended settings for resource mailboxes used by meeting devices are covered in the Microsoft documentation, but most of them are optional changes as they apply to features like meeting conflict handling, automated responses, and privacy options which all may vary based on an organization’s requirements.

            Parameter Default Recommended Behavior
            AddOrganizerToSubject True False Would append the meeting organizer’s name to the subject, but both native endpoints and OTD-supported VTCs will already display the organizer’s name in a defined field so this parameter should be disabled.
            DeleteComments True False As previously outlined, this parameter must be disabled for nearly all meeting room platforms to function correctly with all supported invites.
            DeleteSubject True False It is optional in most cases to disable this as the Subject line typically does not include information related to joining the meeting.  In some scenarios if an audio conferencing dial-in number is provided in the subject a system may be programmed to parse those digits and call into the meeting.
            RemovePrivateProperty True False For room systems (and the OTD service) which support hiding sender and/or meeting details from the device’s on-screen calendar for meetings marked as private this parameter must disabled for that feature to function.
            AddAdditionalResponse False True This is an optional setting which enables a custom message to appear in Outlook when including the mailbox in a meeting invitation.
            AdditionalResponse <null> Custom Message If the parameter above is enabled then this parameter should also be defined with a custom text message.

            Poly Trio with Microsoft Teams

            August 6, 2019 by · 178 Comments 

            There are four primary configuration scenarios available for the Poly Trio which support Microsoft Teams and the ideal option for an organization can depend on several factors.  The most important distinction is whether the Trio is deployed standalone as simply a phone or if it is also paired with Visual + or Visual Pro componentry for enabling video conferencing capabilities.

            These four scenarios can generally be categorized as:

            1. Native Mode
            2. Gateway Mode
            3. Hybrid Mode
            4. USB Mode

            The first two scenarios are Audio Only where the Trio is deployed as a standalone phone.  The second two scenarios are applicable to Video-Enabled deployments of the Trio.

            Note that in all but the USB scenario the Trio itself is the registered endpoint and the configuration is performed within the Unified Communications Software (UCS) firmware which runs on the Trio platform.  The Trio performs all call control and can be paired to a variety of supported audio and video components, leveraging one or more registration and meeting platforms.  Alternatively the USB mode simply turns the Trio into a USB audio device which is then connected to and controlled by a separate video-enabled endpoint like a Microsoft Teams Room.

            The configuration steps in each of the following sections assumes that the Trio is in a factory-reset configuration state before starting, so some of these steps may not need to be performed on a currently deployed device.

            Native Mode (Audio Only)

            The first and newest option available is to simply place the Trio into the Microsoft Teams base profile which will automatically reconfigure the phone to launch and utilize the embedded Microsoft Team Android application designed for Teams-qualified IP phones.  This application only provides for audio capabilities with the Trio, so it should only be used with a stand-alone Trio which is used for audio conferencing.  (If any video devices are integrated with the Trio then any connected cameras and display monitors will not function in this mode.)


            Before attempting to use this option the Trio must first be upgraded to at least the 5.9.0 Rev AA firmware release which first introduced this supported capability.

            • Open the Settings menu on the Trio and navigate to Advanced > Administration Settings > Network Configuration > Base Profile and then select the Microsoft Teams option.  (The default password is ‘456’.)  Tap the back arrow and then select Save Config which will immediately reboot the phone.

            image          image

            • After the phone reboots it will display the Microsoft Teams Sign In screen.


            A Company Portal screen may be seen while the client software attempts to connect to the Microsoft Teams services.  When the Microsoft Sign In screen appears it will provide two different user authentication methods: one option to directly enter the credentials into the phone using the soft keyboard and another to utilize the Web Sign In process to enter the credentials in a web page on another computer.


            If it is desired to enter the account credentials directly on the phone then follow this step, otherwise skip to the next step to alternatively use a web browser on another device to enter the account credentials for the phone.

            • Tap on the username field to bring up the on-screen keyboard and then type in the username for the desired Teams user account (e.g. trio@msteams.net) and select Next.
            • Enter the password for the provided account name and then select Sign In.

            image          image

            Alternatively this step can be used to sign into the phone by using a web browser on a computer or other mobile device.

            • Tap the “Sign in from another device” option

            image     image

            • From a web browser on another device or computer go to https://microsoft.com/devicelogin and then enter the alphanumeric code  currently displayed on the Trio (e.g. e5s7p7alx) in the Enter Code field and then click Next.  (As demonstrated in this example the code is not case-sensitive.)
            • If the Pick an account window appears and the desired account appears in the list then select that account.  If not, then select the Use another account option.

            image     image

            • If prompted to sign in then enter the username for the desired Teams user account (e.g. trio@msteams.net) and select Next.  Then enter the password and select Sign In.

            image     image

            Regardless of which sign-in approach was used the remainder of the process is the same, as are the resulting capabilities and experience.  The phone may briefly display the Company Portal page as the Microsoft 365 tenant is located and then the Teams client will appear once completed.

            image          image

            • If prompted to select a login account type select Shared.  (This is the only mode that will be supported on the Trio, so while Personal can be selected it is not recommended, nor supported.)



            The Shared option is meant for common area use-cases like conference rooms where only scheduled meetings on the room’s calendar are displayed, along with the dial pad button used to place an outgoing PSTN call.  The magnifying glass icon in the upper right corner can also be used to search for other Teams users or devices to place outbound peer calls to.


            In the example shown above there are both Teams and Skype for Business scheduled meetings on the Trio’s calendar.  Note that the action button on Teams meetings says ‘Join’ while the button on a Skype meeting (denoted by the Skype for Business logo) says ‘Dial’.  this is a very important distinction to understand as the Teams client does not have any native support for Skype for Business; it does not speak MS-SIP and cannot talk to a Skype for Business platform.  The only way this client can join a Skype meeting is if the meeting organizer is configured for Dial-In Conferencing or is licensed for Audio Conferencing and the meeting invitation includes the necessary PSTN dial-in number(s).  Also, the Teams user registered to the Trio must be enabled with Phone Calling using either Direct Routing or with a Microsoft Phone Calling Plan assigned to it.  In short, the Trio must be able place an outbound call to the PSTN via Microsoft Teams in order to connect to the Skype meeting via basic audio conferencing.

            The Teams presence state for the account can manually be set directly on the phone by tapping the ‘hamburger’ menu in the upper-left corner of the client and selecting the desired presence state.


            For comparison the Personal option can be selected during sign in if prompted, but this mode is more resource-intensive and as previous stated is not supported on the current Trio models. This mode is intended for personal handsets like the upcoming Poly CCX devices and will not only show scheduled Meetings, but also provide additional capabilities in the client applicable to individual users like the history of Calls and Voicemail along with Search and Call Park retrieval options.  From the Calls screen the Make a Call button can be used to either search for other Teams users or bring up a dial pad to place a PSTN call.  The New event button on the Meetings screen allows the user to create a new Teams meeting directly from the phone and then invite other participants.

            image     image     image

            Gateway Mode (Audio Only)

            This configuration uses a single registration into Skype for Business Online which inherently provides a limited set of core functionality into the Microsoft Teams environment.  This is provided by way of a SIP to Teams audio gateway which Microsoft has deployed and manages in their cloud.  The gateway is not something that devices point to directly as it is more of a set of backend connections between the Skype for Business Online and Microsoft Teams environments, allowing for mainly peer calling and meeting-join capabilities for 3PIP-qualified IP phones like the Polycom VVX, Trio, or other third-party qualified phones.  Thus, the simple act of registering the phone to Skype for Business Online provides some inherent connectivity into Microsoft Teams.

            Also of importance is where PSTN connectivity comes from.  If the environment is currently using Enterprise Voice in Skype for Business then all PBX functionality and PSTN connectivity is retained via the registration to Skype for Business.  If (and when) that Enterprise Voice functionality is migrated to Teams, by way of establishing a Direct Route to Teams or utilizing Microsoft Phone Calling Plans, then the Trio (as any 3PIP-qualified phone) will continue to operate the same via the gateway services.  Thus, when moving all users in an environment to “Teams Only” mode and also migrating PSTN connectivity directly into Teams there is no impact to these phones which were already functioning; they simply stay in the same configuration and the gateway masks all of those changes.

            Be aware that while this functionality does rely on Skype for Business Online it will not initially be impacted by the planned retirement of Skype for Business Online on July 31, 2021 as announced by Microsoft.  Microsoft intends to support 3PIP-qualified IP phones via the gateway services for an additional two years, through July 31, 2023 as stated in this FAQ.


            Before registering the phone the desired user account should be set to Teams Only mode for best functionality.  While this is not a requirement to leverage the gateway, but is recommended for proper functionality.  If the account is in a different Teams Upgrade mode, like Islands for example, then peer calling behavior may not function correctly.

            • Click Edit on the Teams Upgrade section and change Coexistence Mode to Teams only and click Save.  (Ignore the setting to ‘Notify the Skype for Business user’ as this only applies to the Microsoft Skype for Business clients and is not relevant for using the account only with a 3PIP-qualified phone.)


            • On the Trio access the Settings menu and navigate to Advanced > Administration Settings > Network Configuration > Base Profile and then select the Skype for Business option.  (The default password is ‘456’.)  Tap the back arrow and then select Save Config which will immediately reboot the phone.

            image          image

            • After the phone reboots tap the Sign In button and select the preferred option for registering to Skype for Business Online using the desired user account.

            image          image


            When the Trio is registered to an account which is homed in Skype for Business Online it will retain all currently supported Skype capabilities as it is still in the Skype Base Profile.  When a specific event occurs (like placing a call from the phone to another user in Teams Only mode) then Skype for Business Online knows to route that call through the gateway services into the Teams environment.  Understand that if a phone is registered with an account homed on a Skype for Business Server which is not part of a Hybrid deployment then this will not function as the gateway service is only accessible via Skype for Business Online connectivity.

            As pointed out above, this is an Audio Only experience with Microsoft Teams as the gateway only supports audio.  Thus, this configuration is also intended specifically for audio-only deployments and should be avoided with video-enabled configurations.  (There is a known issue where video sessions can erroneously be established through this gateway when joining a Teams meeting.  This may not be resolved by Microsoft as the gateway is essentially in a maintenance mode and will likely not have any future feature development.  Microsoft’s focus is the wholesale replacement of devices to new products which will run the native Microsoft Teams client.)

            To provide some insight into how the gateway works simply save a Teams meeting invitation in Outlook as an .html file then open it in any text editor or viewer.  Search for the text “focus:id” and the following OnlineMeetingConfLink section should be seen.


            Note that this looks exactly like a Lync or Skype for Business conference URI, except for the additional teams:2:0!19: string.  The Trio does not look at the actual Teams meeting link embedded in the Join Microsoft Teams Meeting link at the top of the invitation, but will identify these invitations as a ‘Skype Meeting’ by recognizing the conference URI embedded in the message as shown above.

            A native Teams client would join this meeting using the native Teams meeting URL.


            Yet the phone will leverage the ‘legacy’ Skype conference URI in the invitation which looks much different.

            conf:sip:jeff@msteams.net;gruu;opaque=app:conf:focus:id:teams:2:0!19: meeting_NQG2ODNzMTItZTU5Yy95ZTFhLWFmYjgtYjk4MjQ1N2Q0ZmY4-thread.v2! aff3cdcc45514de68bece7f9e07edf61!bc7c5f16c55e417daac0ff6bbfc27f76

            Note that both formats utilize the same unique identifier, indicating that this is the same meeting.  But since the phone registered to Skype for Business cannot leverage the first URL then continues to see this invitation as a Skype meeting and then attempts to connect to the conference URI above.  As far as the phone is concerned though it thinks it is talking to a Skype for Business MCU, but in reality it has been pointed to the gateway (focus:id:teams:2:0!19:) which then handles the rest of the connection to the actual Teams MCU and locates the correct meeting via the provided meeting ID (NQG2ODNz…).

            Hybrid Mode

            The mode is the only option which is supported by Microsoft for interoperability when the Trio is deployed as video-enabled when paired with a Poly Visual Plus (Visual+) or Visual Pro solution.  This is because the Trio will leverage the supported Cloud Video Interop (CVI) approach by joining Microsoft Teams meetings using the Poly RealConnect Service.

            The Hybrid name comes form the fact that the Trio can support multiple concurrent registrations to different SIP-based platforms and yet still join native Teams meetings with video and desktop sharing capabilities.  One basic configuration option is to have a single line registered natively to Skype for Business to retain any existing functionality as well as utilize Enterprise Voice in Skype for PSTN connectivity, but then leverage a second (unregistered) line to join Teams meetings by placing standards-based SIP calls directly into the Azure-based interop service.  Another common option comes into play when another common IP-PBX platform (e.g. Cisco or Avaya) is used in the environment and PSTN connectivity is not provided by Skype or Teams.  This configuration is a true ‘hybrid registration’ option as the Trio will sustain multiple concurrent SIP registrations: one to the PBX platform for voice calling and a second to Skype for Business.  The third line can be used for unregistered calls in to the CVI service or even be actively registered to any standards-based video proxy (e.g. Poly DMA/RPAD, Cisco VCS/VCS-E, etc.) for eventual routing into the video interop service (or alternatively the Poly Clariti-based configuration of RealConnect for Microsoft Teams interop.

            In short, the Hybrid approach is the most flexible as it can be used to connect into any number of IP-based voice platforms and/or meeting solutions.  It is not uncommon to see a Trio configured to support joining meetings scheduled on several different meeting services like Skype for Business, Microsoft Teams, Cisco WebEx, Zoom, etc. all in the same room.


            The example configuration in this article will address a single use-case, showing how register the Trio to Skype for Business and also configure it so that RealConnect will be used to join Teams meetings.  This approach still retains existing Skype for Business functionality, only leveraging the interop service for joining Teams meetings

            Before configuring the Trio itself a set of UCS parameters will need to be prepared to import into the phone.  This is accomplished by creating a custom configuration text file and saving it with a .cfg file extension.  There are several applicable parameters, most of which are required to successfully  place calls into the RealConnect Service from the Trio.  Only a few of the parameters need to be customized, while some of the parameters can be omitted depending on the desired capabilities.

            At minimum the following parameters are required to allow the Trio to place a SIP call into RealConnect by using an additional, unregistered line.  As mentioned above this specific example will configure the Trio to use Line 2 to place these calls, but for a Trio using a different configuration with potentially more than 2 registrations then simply alter the following example to use an available line number.

            Attribute Value
            call.autoOffHook.2.contact 680450644@t.plcm.vc
            call.autoOffHook.2.enabled 1
            call.teluri.showPrompt 0
            dialplan.2.applyToDirectoryDial 1
            dialplan.2.digitmap ^.+@t\.plcm\.vc$
            dialplan.2.digitmap.mode regex
            dialplan.2.digitmap.timeOut 4
            dialplan.digitmap.lineSwitching.enable 1
            exchange.meeting.realConnectProcessing.outboundRegistration 2
            exchange.meeting.realConnectProcessing.skype.enabled 0
            exchange.meeting.realConnectProcessing.teams.enabled 1
            reg.2.address trio
            reg.2.keepalive.sessionTimers 1
            reg.2.label Teams Meeting
            reg.2.server.1.address t.plcm.vc
            reg.2.server.1.register 0
            reg.2.server.1.transport TCPpreferred
            reg.2.srtp.offer 1
            reg.limit 2

            The three highlighted parameter values above must be customized as explained below.

            • Most important is the specific Tenant Key (e.g 680450644) assigned to the Office 365 tenant where the RealConnect Service is used, as this controls which tenant entry queue is called when simply tapping the new line key which will appear on the phone.
            • Also enter the preferred name used to identify the phone in SIP calls (e.g. trio); this name can be pretty much anything unique to the specific device except for the SIP URI of the account already registered to Skype for Business as that would cause a conflict.
            • Finally select the desired label name which will appear under the new Line key button on the Trio’s home screen (e.g. Teams Meeting).

            The following text can be copied into a new file and then saved as with a .cfg file extension for importing into the phone in a later step.

            <?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?>
            < !–Description: Template for configuring a Trio to connect and dial into Teams RealConnect via an unregistered Line 2.  The Lobby will be autodialed when Line Key is selected.–>
            < PHONE_CONFIG>
            <ALL reg.limit=”2″ dialplan.digitmap.lineSwitching.enable=”1″ call.autoOffHook.2.contact=”680450644@t.plcm.vc” call.autoOffHook.2.enabled=”1″ dialplan.2.applyToDirectoryDial=”1″ dialplan.2.digitmap=”^.+@t\.plcm\.vc$” dialplan.2.digitmap.timeOut=”4″ dialplan.2.digitmap.mode=”regex” reg.2.address=”trio” reg.2.keepalive.sessionTimers=”1″ reg.2.label=”Teams Meeting” reg.2.server.1.address=”t.plcm.vc” reg.2.server.1.register=”0″ reg.2.server.1.transport=”TCPpreferred” reg.2.srtp.offer=”1″ exchange.meeting.realConnectProcessing.teams.enabled=”1″ exchange.meeting.realConnectProcessing.outboundRegistration=”2″ call.teluri.showPrompt=”0″ />
            < /PHONE_CONFIG>

            (Note that is configuration is identical to the “Trio-Teams-RealConnect-Line2-unregistered-Template” provided in the Polycom Device Management Service (PDMS).)

            As mentioned above this specific example will configure the Trio to use Line 2 to call the RealConnect Service to join a Teams meeting.  If it is preferred to move this functionality to a different line number for phones with more than a single registration then simply update each call.autoOffHook, dialplan, and reg parameter to change the .2. to the desired line number (e.g. 3).  Also change the the exchange.meeting.realConnectProcessing.outboundRegistration parameter to match the same line number (e.g. 3) and finally set reg.limit parameter value from 2 to match the highest line number in the phone’s specific configuration.

            • On the Trio access the Settings menu and navigate to Advanced > Administration Settings > Network Configuration > Base Profile and then select the Skype for Business option.  Tap the back arrow and then select Save Config which will immediately reboot the phone.

            image          image

            • After the phone reboots tap the Sign In button and select the preferred option for registering to Skype for Business using the desired user account.

            image          image

            The next step is to apply the configuration file to the Trio which can be accomplished in one of several ways.  If using a provisioning server solution with the Trio then that is the preferred approach, but for the purposes of this article the file will be manually imported into a single phone using the local web management administration interface.  The web management interface is not available by default when the Trio is set to the Skype for Business profile, so it may need to manually be enabled.  If it is already enabled on the Trio then skip this step.

            • On the Trio access the Settings menu and navigate to Advanced > Administration Settings > Web Server Configuration, enable Web Server, and then select the desired Web Config Mode (e.g. HTTP/HTTPS).  Tap the back arrow and then select Save Config which will immediately reboot the phone.


            • After the phone has rebooted tap the hamburger menu in the top left corner and look for the device’s IP address as displayed in the menu (e.g.


            • Open a web browser on a workstation and connect to the IP address using either HTTP or HTTPS, based on the previously-configured option(s) (e.g. and then sign in using the Admin account.  (The default password is ‘456’.)


            • Go to the Utilities > Import & Export Configuration menu and then click Choose File under the Import Configuration section.
            • Select the previously created configuration file (e.g. Trio_RealConnect.cfg) and then click Import which should immediately trigger the Trio to reboot.



            After the phone reboots the additional line button (e.g. “Teams Meeting”) should appear on the home screen indicating that the new parameters were successfully imported.  The new “Teams Meeting” line key can be used to simple call directly into the RealConnect Service’s entry queue which will prompt for the specific meeting’s video conferencing ID.  The Meetings button on the home screen will provide a Join button which can be used to connect directly into a scheduled Teams meeting.

            image     image

            USB Mode

            This mode simply turns the Trio into a USB-only audio device for when it will be physically connected to any supported Microsoft system like the Microsoft Teams Room or a Surface Hub.  The Trio no longer performs any registration and is turned into an accessory to perform as a microphone and speaker.


            • On the Trio access the Settings menu and navigate to Advanced > Administration Settings > Network Configuration > Base Profile and then select the Microsoft USB Optimized option.  Tap the back arrow and then select Save Config which will immediately reboot the phone.

            image          image


            Once the phone reboots a very simple interface will appear.  When the connected room system is not in an active call the display is relegated to only showing the Date and Time.  When the connected room system is in a call then the Trio will display a call timer along with Mute and End Call buttons.

            image          image

            Next Page »