Device Pairing in Microsoft Teams

January 13, 2021 by · 3 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.

image

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.

image

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”:

image

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/1.0.94.2020111101) 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. 

image

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

image

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

image

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.

image

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

image

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.

image

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 · 2 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
On
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:

image

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:

image

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

Background

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

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

image

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

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

New Developments

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

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

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

Service Account vs. Application Identity

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

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

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

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

Topologies

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

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

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

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

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

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


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

Mailbox Configuration

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

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

Configure Resource Mailbox

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

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

image

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

image

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

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

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

Access Control

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

Configure Group

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

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

image

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

image

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

image

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

image

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

image

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.

image

Create Access Policy

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

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

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

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

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

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

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

image

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

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

image

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.

image

  • Select Sign in with Microsoft.

image

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

image

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.

image

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.

image

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.

image

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

image

  • Choose Connect as Application.

image

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.

image

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

  • Review the request and choose Accept.

image

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.

image

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

image

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

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

image

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.

image

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.

image

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

image

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

image

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

image

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

Configure Device

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

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

image

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

image

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

image

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

image

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.

image

Microsoft Teams Room Factory Restore Process

August 28, 2020 by · 5 Comments 

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

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

System Preparation

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

Download Deployment Kit

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

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

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

image

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

Extract Files

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

image

  • 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

image

  • 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-4.5.35.0.msi” /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.

dir

image

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

cd “Skype Room System Deployment Kit”

dir

image

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

.\RecoveryTool.ps1

image

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

image

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

image

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

image

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

systemreset

  • Select Remove Everything.

image

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

image

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

image

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.

image

Upgrading Microsoft Teams Desk Phones

May 21, 2020 by · 43 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.

Background

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.

image

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/1.0.94.2019110802) and the Calling Version (e.g. 2019.41.01.2).

image

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.

image

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.

image

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

image

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.

image

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

image

    •   Select Firmware and hit then click Update.

image

(Note that in the screenshots above the Current version is reported as ‘null’.  This is a bug in the older CCX 5.9.12.1122 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 5.9.13.0306 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.

image

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.

image

image

image

image

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

image

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

image

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

RealConnect for Teams Topologies

May 18, 2020 by · 25 Comments 

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

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

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

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

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

Background

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.

image

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.

image

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.


Architecture

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.

image

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.

image

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.

image

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

RealConnect Access Suite

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

image

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

RealConnect for Clariti

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

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

image

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

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

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

image

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


Video Experience

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

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

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

RealConnect Service

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

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

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

image

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.

image

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.

image

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.


Licensing

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.

image

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

Background

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.

image

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.

image

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

image

    Configure Phone Policies

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

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

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

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

    Get-CsTeamsIPPhonePolicy

    image

    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

    image

    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.

    image

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

    image

    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.

    image

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

    image

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

    User Setup

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

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

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

    Create User Account

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

    image

    • Select Common Area Phone license from the Licenses section.

    image

    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. 

    image

    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.

    image

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

    image

    Assign User Policies

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

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

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

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

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

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

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

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

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

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

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

        image

        Sign In

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

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

        image

          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.

            image

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

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

            Sign Out

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

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

            image     image

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

            image     image

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

            image     image

            Enterprise Application Consent Requests in Azure

            April 6, 2020 by · 8 Comments 

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

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

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

            Background

            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.

            image

            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.

            image

            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.

            image

            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.

            image

            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.

            image

            Manual Consent

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

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

            https://login.microsoftonline.com/common/adminconsent?client_id=500e702f-0145-4462-b2a6-d00e35b92d45

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

            image

            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.

            image

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

            image

            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.

            image

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

            image

            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.

            image

            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.

            image

            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.

            image

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

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

            RealConnect Usage Reporting

            January 26, 2020 by · 6 Comments 

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

            image

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

            Accessing the Portal

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

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

            Activate Initial Account

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

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

            image

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

            image

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

            Dashboard

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

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

            Call Summary

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

            image

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

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

            Call Concurrency

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

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

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

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

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

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

            image

            Devices

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

            image

            Conferences

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

            image

            Customization

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

            image

            Calls

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

            Summary

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

            Map

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

            image

            List

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

            image

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

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

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

            image

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

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

            image

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

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

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

            image

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

            Additional Examples

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

            License Overage

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

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

            image

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

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

            image

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

            image

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

            image

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

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

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

            image

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

            License Overage with Soft Ceiling

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

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

            image

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

            Managing Microsoft Teams Phone Policies

            November 2, 2019 by · 32 Comments 

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

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

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

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

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

            Investigating the New Cmdlets

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

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

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

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

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

            The results should look like the following:

            image

            The five new cmdlets could logically be grouped as:

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

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

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

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

            Get-CsTeamsIPPhonePolicy

            image

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

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

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

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

            Set-CsTeamsIPPhonePolicy -SignInMode “NotARealParameterValue”

            image

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

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

            Set-CsTeamsIPPhonePolicy -SearchOnCommonAreaPhoneMode “NotARealParameterValue”

            image

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

            Sign In Mode

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

            UserSignIn

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

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

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

            Calls

            image

            Calendar

            image

            Voicemail

            image

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

            MeetingSignIn

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

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

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

            image

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

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

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

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

            image     image

            CommonAreaPhoneSignIn

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

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

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

            image

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

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

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

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

            image     image

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

            Set-CsTeamsIPPhonePolicy -Identity CAP -SearchOnCommonAreaPhoneMode Enabled

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

            image     image

            Review Configuration

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

            Get-CsTeamsIPPhonePolicy

            image

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

            Get-CsOnlineUser | ft UserPrincipalName, TeamsIPPhonePolicy

            image

            Next Page »