Microsoft Teams Phones – 2021 Update 1

April 5, 2021 by · 50 Comments 

This article is the first in a series which will focus on each new release of the Microsoft Teams IP Phone client by highlighting any new or changed functionality in each release.  Depending on the depth of a specific new feature or functionality a separate, dedicated article may be posted to cover that topic in greater detail.


Currently Microsoft targets roughly quarterly updates for the array of certified Teams Phones available from multiple Microsoft partners.  While each phone manufacturer manages device firmware releases on their own schedule they all still use the same Teams Android applications provided directly by Microsoft.  The features covered in these articles will be applicable to all phones once each manufacturer has released updates for their devices leveraging the newest

Historically Microsoft has used simple numeric nomenclature for these updates as “Update #4”, “Update #7”, etc. 


Starting with this release though Microsoft is now prepending the update names to include the release year and the numeral will be reset to 1 upon each new calendar year.  So, instead of this new release being referred to simply as “Update #8” it is instead referred to as “2021 Update #1”.  This terminology is not really all that important, but it is what Microsoft uses to refer to each release in their official documentation


Considering that these individual client releases are embedded within each manufacturer’s own device firmware releases then it is less important to track the information above.  The Teams client itself is not updated as an individual application so one only needs to be aware of the firmware releases provided by their phone manufacturer.  Luckily Microsoft makes this easy to manage by providing those officially supported updates directly from within the Teams Admin Center (TAC).  Thus, regardless of what releases and update methodologies may be available from a device’s manufacturer Microsoft will post only the correct firmware package for each device into the TAC, which should be used as the authoritative source.  Understand that this does not mean that the update must only come from the TAC itself, only that if an alternative update method is used then the exact same version that is listed in the TAC is what should be installed.

As the phone manufacturers prepare their latest firmware version for release Microsoft will post an update on their What’s new in Microsoft Teams devices page.  This page does not include the update version nomenclature described above and instead simply refers to the release using the date that the page entry was posted on along with the version number of the Teams Android client, listing any new features and improvements. 


Note that the only portion of the Teams client version which ever changes is the last section of numbers which is comprised of the year, month, and day, then ends with an incremental daily build number (2021022403).  For more details on understanding the Teams client version numbers and updating Teams phones see this previous article.

While the capabilities of this client update are the same across all device manufacturers the specific release dates of actual device firmware may slightly differ for each.  The examples used throughout the remainder of this article leverage Poly phones so the specific release dates and firmware version numbers shown below will be drastically different looking than another partner’s device firmware version.  The Teams client included in all currently supported Teams phones will be the same though as each manufacturer is using the same Teams software provided to them by Microsoft.

Update Details

The 2021 Update #1 release from Microsoft was officially announced on March 26th and the Poly CCX and Trio firmware packages were posted by Microsoft the Teams Admin Center on April 5th.  This brief article posted in the Microsoft Tech Community outlines a few of the new features.

Among the new capabilities outlined by Microsoft the following items related to improvements and changes in the phone’s user interface are as follows:

  • Improved sign in experience including a new tenant provisioning option
  • Multi-cloud sign in options with authentication support for GCC High and GCC DoD clouds
  • Microsoft Whiteboard support with Personal devices (UserSignIn mode)
  • Meeting enhancements including reaction and improved call controls
  • Meeting attendees can no longer add participants to the meeting from the phone
  • Calling forwarding direct to Voicemail
  • Phone numbers shown on-screen in meetings and contacts can now be tapped to place a call
  • New Call Queue settings to allow users to opt out of select call queues

To begin using this release a phone can be updated using the Teams Admin Center to manually push the latest firmware version to a Poly CCX or Trio C60 phone with the version for CCX 400/500/600 models and for the Trio C60.

     image     image

For example, after updating a CCX phone the Settings > About menu shows the Teams Android client version (1449/ and the Settings > Device Settings > About menu reports the same client version as well as additional version information including the Poly UCS firmware version (

image     image

New Sign-In Screen

The first noticeable change on the phone is the redesigned sign-in screen which appears on a device which is not currently signed into Teams.


Previously the Teams IP phone client would default to asking a user to sign-in by entering their credentials directly on the phone but also provide a link to alternatively sign in from a different device by leveraging the web portal.  In the latest Teams client Microsoft has flipped this behavior and now the phone offers the device login method by default, moving the on-phone sign in option to a link on the bottom of the screen.

Remote Sign-In

  • To sign the phone in using the device login approach simply tap the Refresh Code button (if a code is not already displayed) and then from another computer or mobile device go to and enter the code currently displayed on the phone.

image     image

  • Then enter the account credentials for the Teams user that is to be signed into the phone to complete the sign in process and close the browser window.

image     image

The phone will automatically complete the sign-in process.

image     image

on Device

Alternatively the Teams user can sign in directly on the phone by using the following process.

  • On the main sign-in screen tap the “Sign in on this device” link at the bottom of the screen and then enter the account credentials for the Teams user that is to be signed into the phone

image     image

Settings Menu

The Settings menu (the gear icon in the upper-right corner) has also been redesigned to include additional sign-in options.  The individual phone settings have all been nested under the Device Settings option as two new menu items have been added at this level.

image     image

The Provision phone option which is used with the new remote phone provisioning process that Microsoft has recently added.  This option is used to enter a provisioning code provided by an administrator using the Teams Admin Center to assist in remote bulk provisioning of phones.  A separate article covers this new remote provisioning capability.

image     image

The Cloud menu option now allows the phone to selectively sign-in to a supported U.S. Government Community Cloud (GCC).

image     image

Microsoft Whiteboard Support

Larger format phone models with a landscape orientation display (e.g. Poly CCX 600) now support the Microsoft Whiteboard when in used in Personal Mode, meaning that the signed-in user account is configured with the default UserSignIn mode.  This feature is not available for phones in Meeting or Common Area Phone modes.

The Whiteboard automatically appears on the phone when started by another participant in a meeting.  A Whiteboarding session cannot be started from the phone though.


Meeting Participant Controls

When attending a Teams meeting the participant controls have been improved which includes new options to manage audio/video streams and select a reaction, including ‘raise hand’.  In addition meeting attendees can no longer add a new participant to a meeting using the phone. (Only meeting participants can perform that action.)

 image     image     image

Call Forwarding to Voice Mail

When performing a blind call transfer from a Teams phone there is now an option to send the call directly to another Teams user’s voicemail instead of ringing them on any client they may currently be signed into.

image     image     image

Tap to Dial Phone Numbers

When a recognizable phone number is included in a meeting invitation or on a Teams contact then that number is now an interactive link and can be tapped to place a PSTN call to it.

image     image

Contacts Removed from Common Area Phone

In the previous client release contacts were available on a phone when the signed-in user was configured to use the Common Area Phone (CAP) mode.  In this new release Microsoft has apparently removed the People app when in CAP mode which no longer allows access to a contact list on the phone.


There does not seem to be any way to control this behavior though, so while some tenants may approve of this change other may not as it removes the ability to quickly call other Teams users/phone without searching.  The Search option is still available in CAP mode though and can be controlled via the SearchOnCommonAreaPhoneMode parameter in the *-CsIPPhonePolicy PowerShell cmdlets.  (The screenshot above does not show the search button as it was disabled for the user currently signed into the phone.)

Provisioning Microsoft Teams Android Devices

March 31, 2021 by · 20 Comments 

The purpose of this article is two-fold.  Primarily it introduces and explains a new provisioning capability in Microsoft Teams which is applicable to Teams-certified devices across all Android-based categories: Teams Phones, Teams Displays, Teams Panels, and Teams Rooms on Android.  Secondly the overall concept of device provisioning in Teams is explained along with real-world scenarios to provide some additional guidance and clarity.


At the beginning of 2021 Microsoft quietly added a new item to the Microsoft 365 Roadmap entitled Zero Touch provisioning for Teams devices under the Microsoft Teams category (Feature ID: 70675).  The feature description simply states that it will “allow Remote Provisioning of Teams Android devices from Teams Admin Center” with no further details provided other than a targeted release of March 2021.  Given that the title includes the phrase “Zero Touch” many Teams customers were eager to learn more about this.

Then in early March on the heals of the Microsoft Ignite 2021 digital event an article was posted to the Microsoft Teams Blog outlining what was new in Teams which outlined some new management capabilities.  Included in that article was the following statement:

Remote device provisioning

We are simplifying the experience of setting up Teams Android devices remotely from the Teams Admin Center. Remote provisioning eliminates the need to physically handle devices to sign in. Instead, once the MAC address is added in the Teams Admin Center, technicians just need to install the device, connect to the network, and enter a verification code. After that, IT admins can successfully completely the provisioning remotely.

This remote provisioning functionality required two things to occur before it could be used by Microsoft Teams customers.  First Microsoft needed to enable the options in a customer’s Microsoft 365 tenant and then any supported Teams devices required an updated Teams client which supports the new feature.  Late in March Microsoft performed the first step by exposing the Provision new devices action underneath each Android-based device category within the Teams Admin Center for all Microsoft 365 tenants in the commercial public cloud.  The second half of the puzzle requires an updated Teams Android client for each device category, which as of the time this article was posted was only initially available on a handful of phones as documented here.

After spending some time getting familiar with the provisioning process prior to the recent public release a few things have become evident which are worth dissecting further.  Foremost the phrase ‘zero touch’ used in the roadmap is a bit misleading, as this process still requires a person to interact with the device to kick off the provisioning process.  Traditionally ‘zero touch’ in the IP telephony world is meant to indicate a process where a device only simply needs to be powered on and connected to a network. Obviously this still requires someone to physically handle the phone to accomplish those tasks, but nothing is required beyond providing power and network connectivity.  Once online the phone would automatically be provided all the information it requires from the network (e.g. DHCP/DNS) to locate a defined provisioning server to which the phone would receive any applicable configuration information, potential updates, and possibly even registration/authentication details.  The essence is that of a “plug it in and walk away” approach where once the phone is brought online it would automatically proceed to fully functional state where anyone could simply walk up to it and place a call.

Yet, that is not quite the device provisioning experience that Teams has been able to provide, even with this new capability.  It is not ‘zero touch’ by comparison as once the Teams device is connected to power and network it will sit in a signed-out state until someone physically interacts with it.  Previously that interaction could be signing in by simply entering user credentials directly on the device or by using the Microsoft Device Login web portal on a computer.  There is now a third option available on devices running the updated software called Provision Phone.  Selecting this option brings up a dial pad, asking for verification code to be entered.  That code is something which would need to be provided by an administration to the personnel with physical access to the device and is the foundation of this new provisioning process.  Clearly someone is going to need to manually enter these codes on each device, so the level of physical interaction with the device hasn’t really changed.  It is only the type of information that is shared, how it can be communicated, and the order of events which is different.  As will be discussed later in this article the core benefit of this feature mainly applies when provisioning large numbers of phones at one time by extending the current 15 minute window of time required for administrators and on-site personnel to synchronize their tasks out to a full day.

Provisioning Process

The following steps outline the process of defining multiple Teams devices in a tenant and then successfully provisioning and signing one them into Teams.  For this article three different Teams-certified IP phones are added to the tenant: a Poly CCX 500, CCX 600, and Trio C60.  The documented provisioning and registration processes have been performed explicitly on the CCX 600.

The general actions in this process are as follows:

  1. A administrator prepares the device by defining it in their tenant via the unique Media Access Control (MAC) Address.  They then generate a provisioning code and provide it to the personnel with physical access to the device.
  2. The on-site personnel enters the provisioning code directly on the phone in order to provision it to the desired tenant.
  3. The administrator can then sign-in the phone remotely by retrieving the device login code from the now-provisioned phone using the admin center.

Prepare Device

  • Open the Teams Admin Center and navigate to Devices, then select the appropriate category for the Teams device(s) to be provisioned, for example IP phones.
  • On the Actions menu in the upper-right corner select Provision new devices.


The following screen appears providing two new views and two new options.  The initial Waiting on activation tab is where new devices can be identified for the tenant either by manually entering the device MAC address in the administrative console or by uploading a file containing the device MAC address.  Once that process is completed the Waiting for sign in tab can be used to view any devices which can been provisioned into the tenant but not yet signed into Teams.


Note that both options for adding MAC addresses can be used to add a single device or multiple devices so there is no requirement to create and import a CSV file attempting to add multiple devices.  Largely depending on the number of devices to be added only one of the following two steps should be performed.

  • To enter the device information manually select the Add MAC address option and then enter the MAC address of each device along with a descriptive name for site and/or device in the Location field.  When all desired devices have been entered then select Apply.


  • To instead import the device information from a file select the Upload MAC addresses option and then click on the download the template link.  Using any text editor or Microsoft Excel open the downloaded Template_Provisioning.csv file and add the desired MAC address and Location information to the file.  Save the file in CSV format, saving as a new file if desired (e.g. devices.csv).  Then click the Select a File button, browse to the saved CSV file, and select Upload.

image     image

Regardless of which processes above was used both should produce the same results by adding the supplied device information in the Waiting on activation view.


Provision Device

Up to this point the current state of the devices does not matter, so they could all be sitting in boxes waiting to be shipped or deployed.  Or they could be powered up and online, waiting at the initial sign in screen.  If any of these devices are currently signed into the tenant or being used with any other Microsoft 365 tenant then they must be factory reset prior to using this process.  From this point forward though the proverbial clock is ticking as once a verification code has been generated for a device it must be used within 24 hours, otherwise the administrator will need to generate a new verification code.

For this scenario the Poly CCX 600 has been powered on and is sitting at the initial Teams sign-in screen after a factory reset was performed on the phone.

  • Select the desired device (e.g. Home_CCX600) and then click the Generate verification code option at which point the Verification Code field for the selected device will be populated.  (Note the message at the top of the screen indicating that the generated code is only valid for 24 hours.)


Now that the device has been added to the Teams Admin Center and a fresh verification code has been generated the next series of steps will need to be performed directly on the device which should be powered on and waiting at the initial Teams sign-in screen as shown below.


It does not matter if a device login code is currently being shown on the device or if the Refresh code button is being shown instead.  That is the alpha-numeric device login code which is used later for user authentication during the actual sign-in process.  It should not be confused with the numeric verification code used for provisioning the device that was manually generated in the previous step.

  • Tap the gear icon in the upper right corner to bring up the Settings menu and then select Provision phone.


  • Enter the verification code that was previously generated in the TAC for this device (e.g. 697150) and then tap Next.


The device will take several seconds to process the request, as indicated by the pulsing purple line at the bottom of the screen.  Once complete the following screen should appear.


The device will then return to the initial Teams sign-in screen just as it was before, but with one important difference.  The Organization Name of the Microsoft 365 tenant where the device was provisioned is now displayed on the device, indicating that it is now associated specifically with that tenant, although it is still not signed in.


  • In the Teams Admin Center this device should no longer be listed under the Waiting on activation list and would have been moved to the Waiting to sign in list, reporting a Device user status of Signed Out.


Sign In to Teams

At this point there is no further interaction required with the device itself as the administrator will perform the actual sign-in process from a workstation.  Screenshots of the phone will still be included in the following steps for informational purposes, but no intervention is required on the device.

  • Click on the Signed Out link next to the desired device and then wait while the Teams Admin Center attempts to connect to the device to retrieve a device login code and place it into a provisioning state.


During this time the device will display the following screen to prevent anyone from attempting to use the device or sign it in manually.


Once complete the Sign in a user window will automatically refresh to show the login code retrieved from the device.


  • Go to the Device Login portal as instructed and enter the provided device login code (e.g. EV9PGNQN8) and then select Next.  (This alpha-numeric code is not case-sensitive.)


  • Given that the device being signed-in is likely going to be using a different account than that of the administrator then select the Use another account option when prompted to select an account.


  • Enter the credentials of the desired Teams account to be signed-into the selected device.  In this example the CCX 600 will be signed in using a Teams user account which has been configured for the Common Area Phone experience (e.g.

image     image

  • Once authentication has completed successfully the browser window can be closed.


At this point the device will begin the sign-in process and display several different screens as the Company Portal and Teams applications connect to the Microsoft 365 tenant.

image     image

Once the sign-in process is completed the device will automatically go to the home screen, showing the appropriate interface based on the account’s assigned device policy (e.g. Common Area Phone mode).


  • In the Teams Admin Center close the Sign in a user window and (if needed) refresh the Waiting for sign in view.  It should no longer display that device and notice that the provisioning summary indicates that there is one less device in the “Added MAC Addresses” list and no devices are waiting to sign in.


Additional Guidance

As seen in one of the previous steps the Teams Admin Center displays the following message when signing into a phone using the retrieved device login code:

Note: A device that doesn’t have a user logged in can only be signed in as a shared device, like a conference phone or common area devices that are IP phones.  Remote sign in doesn’t support personal user credentials.  All device user accounts must be created in Azure Active Directory.

This statement appears to be more of what Microsoft does and does not support versus what is actually functional.  In Teams there is absolutely no difference between what would be considered ‘personal’ and ‘shared’ user accounts.  As far as the actual user account configuration in Azure (and the assigned Office 365 licensing) these types of accounts are identical.  It is only how IP Phone policies are assigned to these accounts which makes any difference only they sign into a device, which primarily controls the user interface.  The reality though is that provisioning devices with this process which are to be signed into be a regular user would not make any sense as it would require the administrator to know the user’s password, which not a good security practice.  So what this statement is really attempting to convey is that this process is really designed for dealing with shared devices leveraging user accounts which fall more into the ‘service account’ realm where only administrators would know the password.

Another important thing to be aware of is that this process does not do anything special to the signed-in device in terms of managing the active credentials.  For example, if the signed-in account has a password expiration policy enforced then when that password expires phone will require that the new password is entered directly on the device before it can function normally again.  An administrator cannot resolve this scenario remotely other than asking someone with physical access to the phone to perform a factory reset so that the entire provisioning process can be repeated from the very beginning.  This is because the administrator is not using any new functionality built into the Teams Admin Center to actually manage the sign-in process.  They are simply using the device login method which have always been available on Teams Android devices, only now they have a way to retrieve (and reset, if needed) the device login code without requiring someone to physically interact with the device.  This same limitation also seems to apply to devices which have been manually signed out of as they will not return to the ‘Waiting for sign in’ list in the TAC and the provisioning process cannot be attempted again on the device as it was already provisioned into the tenant (as confirmed by seeing the tenant’s Organization Name displayed on the device’s sign-in screen).

This all means that the new process is only addressing initial provisioning needs and does not add any new functionality to the act of signing a device into Teams, nor any ongoing management controls.  This is a one time process which can be used to deploy a device which ideally should leverage a user account configured with a non-expiring password.  If the device is manually signed out by a local administrator or the password expires then a factory reset on the device is required to re-provision it.

Thus, there are essentially now two ways to remotely sign in a Teams device.  Both still require someone to physically interact with the phone at least once beyond simply powering it on, yet neither requires that the person handling the phone needs to know the user credentials.  The difference between the two options really comes down to looking at the process of getting a single device online versus many devices.  The value provided with the process is not really apparent when looking through the lens of getting a single phone signed in, as technically it is more work than using previously available methods.  But, when dealing with deploying potentially hundreds of phones in a location where there is little to no IT staff then what was once slow and difficult is now much easier to coordinate and accomplish.

The following scenarios can be used as general guidance when needing to remote provision a device when the person handling the physical device does not, or should not know the user credentials needed to sign into the phone.  That step will be performed remotely by an administrator and is most commonly used with devices in shared spaces like conference rooms and hoteling spaces.  When a device is used in a personal scenario then typically that person signs in with their own credentials (which inly they should know) and there is no need to perform and remote provisioning.

Remotely Provision Some Devices

In this scenario the personnel with physical access to the device provides a device login code to the remote administrator.

This approach does not leverage any of the new provisioning options and works on any Teams Android-based device.  It is the simplest and fastest when only deploying a few phones at a time and both the on-site personnel and remote administrator are available to interact with each other in near real-time.  (Because the device login code provided on the phone expires after 15 minutes then the administrator has a short window to perform the sign-in process before the on-site personnel needs to revisit the phone to generate a fresh code for the administrator.)

  1. On-site personnel powers on a device from an out-of-the-box or factory reset status and waits for the initial sign-in screen to appear.
  2. They record the sign-in code which is automatically displayed on the device’s screen and provide that code to the administrator.
  3. The administrator uses the Microsoft Device Login portal, enters the provided device code, and then enters the preferred user credentials for that device.
  4. The device signs-in automatically without any additional intervention from the on-site personnel.

Remotely Provision Many Devices

In this scenario the administrator provides a verification code to the personnel with physical access to the device .

This approach leverages the new provisioning options and is ideal when many phones are being deployed at the same time.  Clearly the time-limit in the previous scenario would make it difficult to near-impossible to manage if attempting to setup many devices either in a short time period or sporadically throughout a day.  This is where the new provisioning process helps by breaking up the order the events and (nearly) removing the time limits on coordination between on-site and remote staff.  In this approach though the administrator instead provides codes to the on-site personnel which are valid for up to 24 hours.  Once the on-site personnel uses the provided code to complete their task then the administrator can come back and perform the sign-in process at their convenience, even after 24 hours.

  1. Either the on-site personnel or remote administrator gather/record the MAC address of each device and the administrator enters them into the Teams Admin Center.  This can be performed by manually entering the addresses or by importing them in bulk from a CSV file.
  2. The administrator generates a verification code for each defined device and provides the codes to on-site personnel.
  3. On-site personnel powers on a device from an out-of-the-box or factory reset status and waits for the initial sign-in screen to appear.
  4. They select the Provision Phone menu option and then enter the verification code provided by the administrator for that specific device.  The administrator locates the provisioned device in the Teams Admin Center and retrieves the device login code directly from the phone
  5. The administrator uses the Microsoft Device Login portal, enters the retrieved device code, and then enters the preferred user credentials for that device.
  6. The device signs-in automatically without any additional intervention from the on-site personnel.

Device Pairing in Microsoft Teams

January 13, 2021 by · 16 Comments 

The purpose of this article is to demystify a common misconception with how Microsoft Teams allows various types of clients and devices to communicate between each other when leveraging several different native features.

The most important concept to understand in this article is that there is actually no direct pairing happening between the Teams clients among these scenarios.  Yes, then the title of this article is purposely misleading.  The word “pairing” was specifically included as that term is commonly used for categorizing the behavior of tying multiple devices together.  In Microsoft Teams there are several different scenarios where separate Teams clients and devices can communicate between each other to provide some beneficial feature or capability.  Sometimes these are clients which are both registered to Teams with the same user account while in other scenarios different user accounts are registered to each.  Yet, in Microsoft Teams at no point do any of these client or devices actually “pair” directly with each other, nor communicate directly between each other.

The same basic pattern of communications is utilized throughout all of the scenarios covered in this article.  Notice that in all the diagram below there are no lines of communication depicted directly between the clients and devices.  Each of the components in the diagram all contain their own native Teams client and are actively registered to the Teams service.  It is only through each client’s existing registration to Teams that they will communicate between each other.


All types of communication between clients and/or devices is handled directly by the Teams service in a client-server-client path and individual Teams clients do not establish any level of one-way or two-way communications directly between themselves, except for one specific scenario.  This is during peer-to-peer calls where audio, video, and/or screen sharing is involved.  Although Microsoft Teams is not a SIP-based platform like its OCS/Lync/Skype predecessors it still adheres to the concept of Internet Connectivity Establishment (ICE) to negotiate media streams.  When a Teams client or device places a peer call directly to another Teams client or device then any audio, video, or screen sharing sessions will always attempt to be routed directly between both clients.  This is only possible though when both parties can communicate directly between each other using their local host IP addresses which is limited to internal, routed IP networks and some VPN networks.  If peer-to-peer network communications cannot be successfully established then the Teams service will facilitate the media sessions between them in a client-server-client path by leveraging various media relay components available in the Teams cloud.  Any other Teams capabilities available in peer communications like chat or file sharing are always transmitted over the existing communications path to the Teams service only.  When participating in a Teams meeting though the Teams service directly handles all aspects of communications between all meeting participants, including all media streams.

While this architecture has one major benefit and one major limitation the trade-off is quite beneficial.  The downside is that every client or device must be actively registered to the Teams service as all communications will go through that connection, so these features are only available to native Teams clients.  The upside is that by Teams handling all of these communications scenarios directly then it does not matter how individual clients or devices are connected to an network, just as long as that network provides correct connectivity to the Teams service.  For example, attempting to share content from a smartphone on a guest Wi-Fi network to a meeting room system a few feet away which is connected to a different, secured cooperate network is often not possible when using a technology like AirPlay due to the networking requirement for those two devices to identify each other and setup a direct line of network communications.  Even when attempting to leverage a direct wireless connection like what Miracast provides the communication establishment is still subject to the myriad of personal devices available with different chipsets and radios which may not always function together.  And all of this complexity is further exasperated by the fact that the majority of smartphones only support one of these options so multiple technologies must be included to support the different platforms.  For example, most Android devices support Miracast, yet iOS devices only support AirPlay.

By instead using the existing, established communication path from the client or device to the Teams service then all of those complications are removed from the equation.  Yes, there is some added latency when sending data between two clients in the same proximity via a cloud service, but most of the scenarios are not heavily impacted by network latency.  The benefit of this architecture is significant as a device like a room system connected to a more secure physical network can easily interact with a Teams client connected to a basic guest Wi-Fi network with only access to the Internet.

A hurdle created by using this approach is that the devices still need a way to discover one another so Teams can initiate communications between them.  Moving away from a short range wireless-based approach removes the inherent knowledge of a nearby device.  To address this Microsoft decided to leverage an ubiquitous capability already embedded in most the hardware today which is capable of running a native Teams client: Bluetooth.  Even more important is the fact that only part of the Bluetooth technology is leveraged, leaving out the complicated and oft-unsuccessful pairing process.  Yet, the inclusion of Bluetooth technology as a method of device discovery seems to be one of the major causes for misunderstanding how some of these features work. 

As mentioned earlier the Teams clients or devices using Bluetooth do not establish any lines of communications between each other, which also means they do not utilize a traditional Bluetooth pairing procedures.  Among the scenarios where Bluetooth is involved its only purpose is to assist in the process of identifying to the Teams service which clients to connect together.  That assistance is limited to one party ‘beaconing’ its name so that another party in direct proximity can listen for it.  The listening party then uses that information to tell the Teams service that it wants to communicate with the other device and Teams will then decide if it is possible and/or allowed, and if so will handle the communication.  An analogy for this pattern of communication might be where one person yells their phone number across a room for someone else to hear it.  The second person uses their phone to call the number they heard and then from there the two people only speak to each other across the established phone call.

The multiple scenarios discussed in this article focus on features available when native Teams clients are used in conjunction with various native Teams devices like IP phones and video conferencing systems.  These are all new features designed to take advantage of the Microsoft Teams architecture and may differ in functionality and behavior from similar use-cases when compared to previous platforms like Skype for Business.  Incorrectly assuming that the underlying technology is the same between Skype for Business and Teams for some features is one reason why these new Teams features can be misunderstood.

Also, for the sake of clarification it is worth reiterating the latest branding changes in the native Microsoft Teams video conferencing system platforms.  What was originally referred to as a “Skype Room System” (SRS) and was rebranded to Microsoft Teams Rooms (MTR) a while ago has recently been updated to be called Microsoft Teams Rooms on Windows (MTRoW).  This change made room for the “Teams Collaboration Bars” to join the MTR family with their new identity of Microsoft Teams Rooms on Android (MTRoA).  This distinction is important to understand as some features covered in this article may only apply to one of the MTR categories while other features may apply to both.

Proximity Join

This feature allows supported Teams clients on desktop and mobile devices to easily bring a Microsoft Teams Room device or a conference phone into a Teams meeting that it was not originally invited to.  In the past this would require the meeting organizer or another invited participant to manually forward the meeting invitation to the desired room’s mailbox and then wait a minute or so for it to appear on the device’s calendar before being able to join.  Alternatively Teams allows a participant joining a meeting to manually add a room device into the meeting instead, but the user would typically need to search for and select the desired room form the corporate address book.  Proximity Join takes this one step further by allowing the client to listen via Bluetooth for a beacon being transmitted from a room system or conference phone which may be nearby.  If one is discovered then Teams will place that directly at the top of the rooms list and even suggest directly in the pre-meeting join window that the discovered room be used for this meeting.

This automatic discovery capability was the first feature brought to Teams devices which allowed a personal device to interact with a dedicated meeting device to provide new functionality never before available in Skype for Business.  It is currently available on all MTRoW and MTRoA platforms as well as select conference phones models (like the Poly Trio).  It is not available in desk phone models (like the Poly CCX).

There are multiple names used to describe this overall feature but it was first officially launched on the MTRoW platform as Proximity Detection.  This name refers to the ability for Teams desktop and mobile clients to utilize the Bluetooth radio on their own device to listen for any ‘beacons’ in the immediate area which may be transmitted by a supported Teams device.  For example, a MTRoW device has its Bluetooth Beaconing setting enabled by default which means it will use the embedded Bluetooth radio to transmit its name.


Better Together

More recently Microsoft has begun adding functionality into the Microsoft Teams Phones devices to deliver on a long-standing capability of their previous platforms: Better Together.  This term has been used specifically when referring to improving the user experience when signed into a desktop client application and a desktop phone with the same user account.  Independently both clients are capable of performing many of the same things, but synchronizing some of those actions is what customers are looking for.

This concept originally dates back to Office Communication Server with the first Microsoft UIC phone: the Polycom CX700 (codenamed Tanjay).  This phone (and the identical models manufactured by a few other Microsoft partners) included a USB Type-B port which allowed it to be connected directly to a desktop PC.  While the phone would still register to a server via its network connection the USB connection was used to provide the initial “Better Together” functionality of some basic features like user sign-in assistance, call pickup and a few other standard call controls.  The next generation of Lync Phone Edition devices came along with Lync Server 2010 and utilized the same Better Together architecture via USB.  When Skype for Business arrived though Microsoft had decided to shift away from phones running their own software and instead moved to the 3rd Party Interoperation Program (3PIP) which used partner-developed, officially certified IP phones that initially did not support any Better Together functionality.  Eventually this was added using a completely different architecture as the Skype for Business clients did not include any embedded support for Better Together features.  Thus, some of the certified phone vendors developed their own Windows desktop application which was used to interface with both the Skype client on the PC and a certified desktop phone (like the Polycom VVX) via Ethernet.  This new approach was awkwardly entitled “Better Together over Ethernet” (BToE) and the available feature-set was not always identical between different vendor’s phones.

With the introduction of certified IP phones for Teams Microsoft decided to return to developing and managing their own IP phone application.  This puts almost the entire spectrum of native Teams capabilities available on certified Teams phones into the Microsoft Android-based IP phone client, regardless of which vendor’s phone the client is running on.

Given the theme of this article it should be quite obvious at this point that Microsoft was not going to develop new Better Together functionality using any of the previous models where the client and phone communicated directly between each other.  As depicted in the earlier diagram the Teams phone and Teams client are both signed into Teams using the same user account and any communications between them are handled by the Teams service.  Just as with the Proximity Join feature Microsoft decided to leverage Bluetooth to assist with the initial connection process, but In order to use the provided Better Together feature set the phone is not paired to a PC via the traditional Bluetooth pairing process.  Bluetooth is only used to assist in the connection process within Teams and is not used for any communications between the clients.  This is not Better Together over Bluetooth; it’s simply “Better Together”.

Better Together is enabled by default for all users in a tenant.  This is controlled by the AllowBetterTogether parameter which is included in the Set-CsTeamsIPPhonePolicy PowerShell cmdlet.

The default Global policy in a tenant will have that parameter set to “Enabled”:


For whatever reason Microsoft chose to make this newer parameter type a String instead of Boolean. Typically “on/off’ parameters would be set to values of “$true” or “$false” in PowerShell, but this parameter needs to be set to a literal string of “Enabled” or “Disabled” to control the behavior. 

At the time this article was posted the implementation of Better Together in the most recent Teams release (1449/ only supports connecting a certified Teams phone with embedded Bluetooth with the Windows desktop 64-bit Teams client.  The available functionality is limited to synchronizing the lock state of the phone with the PC and allowing the phone to be selected as an audio/video device when joining Teams meetings. (Support for peer and group calls is currently planned for availability in June of this year.)

Connect Phone

In order to establish a connection between the desktop client and the phone the following steps must be completed.

  • Sign into a Teams desktop client on a Windows PC with Bluetooth enabled.
  • Sign into a supported Teams IP phone using the same user account.  This phone must support Bluetooth (e.g. Polycom CCX 600) and be located in general proximity to the desktop client .
  • On the phone select Connect to a device from the main menu and within a few seconds the name of the nearby Windows PC with the same user signed into the Teams desktop client should appear. 


  • Tap the Connect button on the phone and the following message should appear on the associated Windows desktop client.


  • Click the Connect button on the PC to complete the process.  To view or manage the connected the device go to Settings > Devices in the Teams desktop client and select Manage Devices.


Synchronized Lock/Unlock

The connected phone will automatically lock and unlock its screen when the Windows PC is locked and unlocked.  This basic capability is as straight-forward as it sounds.  If the Phone Lock feature has been enabled on the connected phone then when the Windows PC is locked or unlocked the phone will automatically lock and unlock to mirror the PC’s state.

  • To enable this feature navigate to Settings > Device Settings > Phone Lock from the phone’s main menu and then activate the Enable Phone Lock setting.


  • When prompted enter a new 6-digit device PIN.  This PIN will serve as the unlock code for this phone only and is not associated with any other PINs in Teams.


Be aware that the inactivity value selected for the Phone Lock Timeout setting will not be applicable when the phone is actively connected to a desktop client.  As long as the Windows PC is not locked the phone will remain unlocked.  When the Windows PC is locked then the phone’s lock screen will appear and can either be unlocked manually by swiping up and entering the previously defined PIN or automatically by unlocking the connected PC.

image     image

Meeting Experience

The connected phone can now be selected as an audio device when joining Teams meetings and phone models with a landscape display (e.g. Poly CX600) will also display any screen sharing sessions.


This feature is a bit more complicated to understand as there are a few limitations in the current implementation.  Firstly, it is limited to Teams meetings only so a connected phone cannot be used as the PC’s audio device when placing or receiving peer calls from the Teams desktop client.  Secondly, when selecting the phone as the Audio device in the Teams desktop client it automatically changes the Video device to the phone as well.  This means that the desktop client will not be able to send video while at the same time sending/receiving the audio on the phone. When using a Teams-certified video phone (e.g. Yealink VP59) the phone will send and receive both audio and video streams, but when using an audio-only Teams phone then no video can be sent into the meeting.

The two possible user experiences are as follows:

  • If the connected phone supports video (e.g. Yealink VP59) then the user’s own video and audio will both be sent into the meeting from the phone.  The desktop client will not send or receive any audio.  The desktop client cannot send video, but it will receive video streams from all other meeting participants.  Both the desktop client and phone can display video and screen sharing.  Only landscape-orientation phones support receiving Screen or Windows sharing in Teams while PowerPoint and Whiteboard sharing are not supported on any Teams IP phone.

  • If the connected phone does not support video (e.g. Poly CCX 600) then the user’s own video cannot be seen by others in the meeting.  The desktop client cannot send video, but it will receive video from all other meeting participants.  The phone will handle both sending and receiving audio but will not receive video.  Screen sharing works on landscape phones the same as described in the previous scenario.

Teams Casting

This is an all-new feature which Microsoft plans to deliver soon to both Microsoft Teams Room platforms.  Based on Microsoft’s public roadmap for Teams this feature should be coming to the MTRoW in January and then to the MTRoA in February although it appears that the Teams mobile clients will not support this feature until later this year.

Currently there few details which can be openly shared on this upcoming feature, but the description in the public roadmap offers a sufficient amount of information to get an idea of what it will provide: “For quick ad-hoc sessions that don’t necessarily require setting up a formal meeting, people can use Teams casting to wirelessly connect to a Teams Room, and display content from their mobile phone. Users can broadcast their screen and cast content stored on locally on their device or accessible via Office 365.

This is a capability many Teams customers have been asking about for some time now.  Currently in order to share content up on the screen of a Teams Room System the device (depending on the platform) would need to be included in either a peer call or a meeting with the device attempting to share the content.  This casting feature will allow a native Teams device to simply send the shared screen content to the room system without having to be in a call or meeting with the room system.  If the Teams Room is in currently in a meeting though then the casting feature will function the same, allowing the shared content to be seen both by those in the room and all other participants in the meeting.

The description is a bit misleading though in its use of the phrase “can use Teams casting to wirelessly connect to a Teams Room” as that is technically inaccurate.  The sharing device does not transmit or ‘cast’ the content stream directly to the Teams Room directly.  The device will send the content stream to the Teams service which will in turn direct the stream down to the desired room system.  The word “wireless” was likely used in the description as it also specifically calls out “their mobile phone”, which seems to infer that this feature may only be supported with mobile device platforms like iOS and/or Android and possibly not desktop clients like Windows or Mac. (This is complete speculation based on the wording in the public description.)  There is also no mention of Bluetooth but one may make an educated guess that the Bluetooth beaconing already available in the Teams Room systems might also be used to assist the operator of the sharing device in identifying which room system the Teams service should relay the content to.

(Once this capability is generally available in Microsoft Teams then additional details will be added here.)

Microsoft Teams Rooms on Android Touch Controller

This scenario is different than those above in that it is not something a Teams user would establish themselves or even be aware of.  This is an underlying connection which does not leverage Bluetooth beaconing as device administrators manually establish a connection when deploying a center-of-room touch controller with an MTR on Android device. This scenario is not yet generally available as it leverages functionality in the upcoming redesigned controller interface.  As Microsoft has discussed and demonstrated in several public events they are planning to update the existing touch controller experience on the MTRoA to look and operate nearly identically to the MTRoW.  This was originally planned for release in 2020 but has recently been rescheduled for availability in February 2021.

This is only applicable to Microsoft Teams Rooms on Android devices.  The MTRoW platform has always included a center-of-room touch controller which is simply a touch display connected directly to the core Windows PC via USB.  The MTRoA touch controller (e.g. Poly TC8) is a standalone network-connected device thus it requires a method to discover and communicate with the Teams client running on the MTRoA device (e.g. Poly Studio X30).

Just as with all the other scenarios covered in this article communications between the Teams clients on both the touch controller and the MTRoA device will be handled by the Teams service, and an administrator will facilitate the one-time connection between devices during deployment.

(Once this capability is generally available in Microsoft Teams then additional details will be added here.)

Meeting Lobby Behavior in Microsoft Teams

December 28, 2020 by · 21 Comments 

This article explains how the meeting lobby is applied to different participant types joining a Microsoft Teams meeting from various clients and devices as well as how to control this behavior using various options provided at the tenant, user, and meeting levels.  Also covered is newer behavior available in Microsoft’s Cloud Video Interop (CVI) partner-offered services like Poly’s RealConnect for Microsoft Teams which now allows more flexibility in the lobby experience for different sets of standards-based video teleconferencing (VTC) system.    

Microsoft Teams will define meeting participants in one of two ways: as either Trusted or Untrusted.  There are numerous terms used throughout the Teams configuration options and documentation which in many cases are used interchangeably to denote the same concepts.  Any participant connecting to a meeting where they are actively signed-in to a Teams tenant would be considered as Authenticated, and by default also as Trusted unless the participant is part of an explicitly blocked domain and is not an invited guest to a Team where a meeting may be located.  This includes users signed into any Teams organization across all native clients and devices as well as a specifically-defined VTC joining through a CVI service which supports defining trusted devices. 

Conversely, a meeting participant which is not signed into any Teams tenant is considered by Microsoft Teams as Unauthenticated and thus also as Untrusted. Any VTC connecting through a CVI service which is not treated as trusted by the service will also be defined as untrusted in Teams .  An anonymous participant is always treated as untrusted as by definition is not authenticated and the identity cannot be confirmed.

The two areas where this designation is most important are (1) how the meeting lobby may apply to the participant and (2) if they can participate in a Teams Live Event.  How meeting attendees are handled in terms of the lobby experience comes down to the options applied for the specific meeting that is being joined.  These options are defined by administrator-controlled default global and/or customized user meeting policies, some of which can be overridden by the meeting organizer for individual or reoccurring meetings.

The coloration between these two is easy to understand when one realizes that the inner Live Event meeting is really just a regular Teams meeting yet is lacking any lobby functionality.  Thus, only trusted participants can join using the meeting link meant for the event’s Organizer, Producer and any potential Presenters joining.  An untrusted, anonymous participant can only attend the event via the Attendee link via some of the native Teams clients or any supported web-browser.  When dealing with regular Teams meetings the lobby is always applicable, meaning there is no such concept as a “Teams meeting with no lobby”.  It is the fact that if certain participants are able to automatically bypass the lobby in a meeting then they typically never see the lobby and appear to join the meeting directly from their point-of-view.

Lobby Settings

Teams provides a few options to control lobby behavior which can be found in the Teams Admin Center (TAC) for administrators to control a meeting organizer’s default settings.  A meeting organizer can alter some of these settings directly on the meeting itself in some Teams clients or in Outlook.  The applicable options control which participants are automatically admitted through the lobby, which participant types are allowed to start a meeting (in the event they are the first participant to join), and a setting which specifically allows anonymous PSTN dial-in callers to be treated differently than other anonymous participants.  These options have different names and descriptions depending on if they are being viewed by an administrator in the Teams Admin Center or by a user in the Teams client or Outlook.  The individual settings for each option also slightly differ in wording at the moment but this is likely related to a recent change in which the term ‘guests’ has been added to some descriptions.

The three different meeting options all provide some control over which participants types are allowed directly into a meeting by automatically bypassing the lobby.  Different participants types can be approved for or prevented from bypassing the lobby when they are the first participants to join the meeting.  Also, telephony participants calling into the meeting via the Audio Conferencing dial-in information from the PSTN can be treated differently than other anonymous guests if preferred.

Every participant joining a Teams meeting will fit into one or more of the following categories.

  1. Everyone this includes every single participant regardless of their authentication state or what client/device is being used.  This includes anonymous PSTN callers, people joining as an unauthenticated guest from the Teams web client, untrusted VTCs through a CVI offering, and all actively registered Teams clients and devices across any tenant in the globally commercial Microsoft 365 cloud.  This category is all trusted and untrusted participants.

  2. Trusted Organizations – these are any participants which are actively authenticated and registered to any Microsoft Teams tenant across any variety of clients or supported devices as long as their tenant’s domain is not specifically added to the block list of the meeting organizer’s tenant configuration.  This includes any “guests” from other Teams tenants who are invited members of a Team where the meeting resides.  This category can only include trusted participants.

  3. Same Organization – only those users which are currently signed-in on a supported Teams client or device to the same Microsoft Teams tenant as the meeting’s organizer as well as any invited guests for a Team/Channel meeting.  This also includes any “guests” from other Teams tenants who are invited members of a Team where the meeting resides.  This category can only include trusted participants.

  4. Meeting Organizer – only the meeting organizer themselves, from any client or device they are signed-in Teams with. This category can only include trusted participants.

The following table lists the current names of each lobby option and setting as seen in both the TAC and the meeting options in Teams/Outlook.  As mentioned earlier the wording of both the option and setting names do not match exactly between what is shown in the TAC and what is seen by users in the Teams and Outlook client.

Meeting Policy Meeting Options
Option Setting Option Setting
Let anonymous people start a meeting Off Not Available
Automatically admit people Everyone Who can bypass the lobby? Everyone
Everyone in your organization and federated organizations People in my organization, trusted organizations and guests
Everyone in your organization People in my organization and guests
Organizer Only Only me
Allow dial-in users to bypass the lobby Off Always let callers bypass the lobby Off
On On

Meeting Policies

In the Teams Admin Center, under Meetings > Meeting Policies several default meeting policies will be listed.  The Global (Org-wide default) policy will include the following settings by default:


Without any additional customization every Teams meeting organized by all Teams users a tenant will exhibit the same lobby behavior:

  • Only trusted participants from within their own organization will be allowed to join meetings directly. 
  • All anonymous, untrusted participants will be placed in to the lobby when joining and will need to be manually admitted by another participant currently in the meeting.
  • Only a trusted participant can start the meeting, which in this overall configuration is redundant as all untrusted participants are forced into the lobby regardless.

When modifying any of these settings in an existing global policy or custom user policy the changes may take some time to apply to the applicable users and will impact both newly created Teams meetings and any existing scheduled meetings where the organizer has not modified the meeting option. This means that any unmodified existing meetings which still point to the default setting will change in behavior to match the new default setting based on the user’s policy.

Meeting Options

Some individual meeting settings can be viewed and modified in Outlook using the Meeting Options button available on new and existing meetings.  From within in the Teams client itself these options are only available on an existing meeting as the options menu is not available when creating a new meeting.

At the user-level only two of the the three options shown earlier are available:


As outlined in the earlier table the “Who can bypass the lobby?” setting is the same as the “Automatically admit people” option from a user’s meeting policy, and the “Always let callers bypass the lobby” option coincides with the “Allow dial-in users to bypass the lobby” policy setting.  There is no meeting option available to the user to alter the behavior of anonymous participants being allowed to start a meeting or not; that can only be controlled by an administrator.

When enabling the setting to always let a PSTN caller to bypass the lobby they will also be allowed to start the meeting even if the organizer’s policy is not configured to let anonymous people start a meeting.  Other anonymous users like guests using the Teams web client and untrusted VTCs are not affected by the ‘callers’ option and will only be able to start a meeting if explicitly allowed.

Modifying either of these setting away from their policy-defined values will only apply to the meeting occurrence or series which is being edited.  Any new meetings will continue to default to the settings configured on the meeting policy assigned to the meeting organizer.

Lobby Behavior

The following table outlines the lobby enforcement behavior each type of participant will experience when joining a Microsoft Teams meeting.  The results depends on the lobby options for each individual meeting which are defined by default values derived from the organizer’s assigned meeting policy and any custom changes possibly applied to the meeting itself directly by the organizer.

Meeting Options Meeting Configuration
Who can bypass the lobby? Everyone People in my organization,
trusted organizations,
and guests
People in my organization
and guests
Only Me
Always let callers bypass the lobby Enabled Disabled Enabled Disabled Enabled Disabled
Participant Lobby Enforcement Behavior
Organizer Bypass Bypass Bypass Bypass Bypass Bypass
Same Organization Bypass Bypass Bypass Bypass Bypass Lobby
Teams Guest Bypass Bypass Bypass Bypass Bypass Lobby
Trusted VTC (CVI) Bypass Bypass Bypass Bypass Bypass Bypass**
Trusted Organization Bypass Bypass Bypass Lobby Lobby Lobby
Untrusted Organization Bypass* Lobby Lobby Lobby Lobby Lobby
Untrusted VTC (CVI) Bypass* Lobby Lobby Lobby Lobby Lobby
Anonymous Guest Bypass* Lobby Lobby Lobby Lobby Lobby
PSTN Caller Bypass* Lobby Bypass Lobby Bypass Lobby

    Among the participant types outlined above there are two different types which Teams confusingly categorizes as “guests”.  The Teams Guest represents an authenticated Teams user from another tenant which has specifically been invited as a guest to an existing Team.  These participants are treated the same as other participants from the meeting organizer’s own tenant and would override any existing federation configuration which may have blocked that guest’s domain.
    The Anonymous Guest is an unauthenticated, anonymous user joining a Teams meeting from a web browser without signing into Teams in any tenant.  Teams will identify this attendee as such in the meeting’s participant list by appending “(Guest)” to whatever display name is provided by the participant when joining.

* One caveat to be aware of is when a meeting is set to allow Everyone to bypass the lobby Teams will still treat trusted and untrusted participants differently in one specific case: when the participant is the first attendee into the meeting.  By default, Teams does not allow untrusted participants to start a meeting, so when an anonymous participant is the first attendee into a meeting it will be temporarily held in the meeting lobby.  Once the first trusted participant joins the meeting then any untrusted attendees currently in the lobby are automatically admitted into the meeting.  If a trusted participant is already in the meeting then all untrusted participants will transparently bypass the lobby and go directly into the meeting.

** Currently there is an anomaly where a Trusted VTC joining via a CVI service will automatically bypass the lobby of a meeting configured to allow only the meeting Organizer to do so.  Microsoft plans to fix this so that the Trusted VTC will go into the lobby like other trusted participants currently do.

Poly One Touch Dial Service with Exchange Online

September 3, 2020 by · 34 Comments 

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


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

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


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

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

New Developments

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

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

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

Service Account vs. Application Identity

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

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

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

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


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

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

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

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

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

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

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

Mailbox Configuration

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

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

Configure Resource Mailbox

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

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


Get-CalendarProcessing -Identity | fl Add*,Delete*,Remove*


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

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

Set-CalendarProcessing -Identity -DeleteComments $false

Access Control

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

Configure Group

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

  • Sign in to the Microsoft 365 admin center with the appropriate administrative account and then navigate to Groups > Active Groups.
  • Select Add a Group and then choose Mail-enabled security.


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


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


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

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


  • Open the new group and then select Members > View all and manage members, then select Add Members.
  • Search for resource mailbox used by the first endpoint which will be configured to use the OTD service (e.g.


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


Create Access Policy

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

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

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

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

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

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

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


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

Get-DistributionGroupMember -Identity ‘’


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

Calendar Integration

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

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

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

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

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

Access OTD Portal

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


  • Select Sign in with Microsoft.


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


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

  • Select Accept on the application permission request window.


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

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


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


Connect to Exchange Online

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

  • Select the Connect button in the Office 365 section


  • Choose Connect as Application.


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

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


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

  • Review the request and choose Accept.


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

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


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


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

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


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

Add Secondary Domains

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

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


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

Endpoint Configuration

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

Define a Device

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

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


  • Pick from the provided list the closet appropriate device option for the desired endpoint.  For example, choose RealPresence Group for any modern Poly endpoints like the G7500 or Studio X devices.
  • Enter the email address of the resource mailbox (e.g. for the Calendaring Email field and then enter a descriptive name to identify this endpoint among others in the OTD device list and then select Create.


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

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


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


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

Configure Device

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

  • Connect to the web management interface for the endpoint and then browse to Servers > Calendaring Service.
  • Select Enable Calendaring Service if it is not already enabled.
  • Enter the Email (e.g., User Name (e.g., and Password (e.g. D4k5qzsIJW) information provided by the Generated Credentials step in the previous section.  (The provided Domain value of ‘OTD’ is not needed and can simply be omitted from the configuration.)
  • Enter in the Microsoft Exchange Server field.


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


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


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


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


Microsoft Teams Room Factory Restore Process

August 28, 2020 by · 12 Comments 

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

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

System Preparation

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

Download Deployment Kit

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

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


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

Extract Files

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


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

mkdir c:\temp

cd \temp


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

msiexec /a “c:\users\admin\downloads\SRSDeploymentKit-” /qb TARGETDIR=”c:\temp\”

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

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



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

cd “Skype Room System Deployment Kit”



Run Recovery Tool

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

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

Set-ExecutionPolicy Unrestricted -Force



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


Disable BitLocker

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

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

manage-bde -status


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

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

manage-bde -off C:

Enable Windows Recovery Environment

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

reagentc.exe /enable


Windows Recovery

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

Reset PC

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


  • Select Remove Everything.


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


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


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

  • Select the desired language and keyboard layout.

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


Upgrading Microsoft Teams Desk Phones

May 21, 2020 by · 76 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 · 39 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 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 “” 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 ‘’ 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 ‘’) 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 ‘’ 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 · 157 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 ‘
    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.


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

    Grant-CsTeamsIPPhonePolicy -Identity ‘’ -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.

      Grant-CsTeamsCallingPolicy –Identity ‘’ –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.

        Grant-CsTeamsCallParkPolicy –Identity ‘’ –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 ‘’ | 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.


          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 · 10 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<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.

            Next Page »