Managing Microsoft Teams Phone Policies

November 2, 2019 by · 1 Comment 

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

Poly Group Series with Microsoft Teams

October 4, 2019 by · 10 Comments 

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

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

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

The valid configuration scenarios fall into two categories:

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

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

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

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

Calendar Configuration

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

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

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

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

image

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

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

image

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


Scenario 1 – Interop

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

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

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

H.323 Configuration

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

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

image

SIP Configuration

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

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

image

Dialing Preference

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

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

image

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

image

One Touch Dial Configuration

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

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

image

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

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

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

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


Scenario 2 – Mixed Mode

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

SIP Configuration

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

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

image

H.323 Configuration

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

image

Dialing Preference

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

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

image

One Touch Dial Configuration

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

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

image

Adding One Touch Dial Administrators

September 25, 2019 by · Leave a Comment 

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

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

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

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

Configuration

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

image

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

image

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

image

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

image

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

Confirmation

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

image

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

image

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

image

Exchange Resource Mailbox Configuration for Meeting Rooms

August 12, 2019 by · Leave a Comment 

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

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

image

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

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

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

Background

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

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

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

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

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

image

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

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

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

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

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

image

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

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

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

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

image

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

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

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

Poly Trio with Microsoft Teams

August 6, 2019 by · 49 Comments 

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

These four scenarios can generally be categorized as:

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

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

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

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

Native Mode (Audio Only)

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

Configuration

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

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

image          image

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

image

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

image

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

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

  • Enter the password for the provided account name and then select Sign In.

image          image

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

  • Tap the “Sign in from another device” option

image     image

  • From a web browser on another device or computer go to https://microsoft.com/devicelogin and then enter the alphanumeric code  currently displayed on the Trio (e.g. e5s7p7alx) in the Enter Code field and then click Next.  (As demonstrated in this example the code is not case-sensitive.)

  • If the Pick an account window appears and the desired account appears in the list then select that account.  If not, then select the Use another account option.

image     image

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

image     image

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

image          image

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

image

Behavior

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

image

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

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

image 

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

image     image     image

Gateway Mode (Audio Only)

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

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

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

Configuration

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

  • Open the Microsoft Teams admin center (https://admin.teams.microsoft.com) and in the Users section select the desired account.

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

image

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

image          image

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

    image          image

    Behavior

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

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

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

    image

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

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

    https://teams.microsoft.com/l/meetup-join/19%3ameeting_NQG2ODNzMTItZTU5Yy95ZTFhLWFmYjgtYjk4MjQ1N2Q0ZmY4%40thread.v2/0?context=%7b%22Tid%22%3a%22bc7c5f16-c55e-417d-aac0-ff6bbfc27f76%22%2c%22Oid%22%3a%22aff3cdcc-4551-4de6-8bec-e7f9e07edf61%22%7d

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

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

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

    Hybrid Mode

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

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

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

    Configuration

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

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

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

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

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

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

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

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

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

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

    image          image

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

    image          image

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

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

    image

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

    image

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

    image

    • Go to the Utilities > Import & Export Configuration menu and then click Choose File under the Import Configuration section.

    • Select the previously created configuration file (e.g. Trio_RealConnect.cfg) and then click Import which should immediately trigger the Trio to reboot.

    image

    Behavior

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

    image     image

    USB Mode

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

    Configuration

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

    image          image

    Behavior

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

    image          image

    Customizing Microsoft Teams Meeting Invitations

    July 31, 2019 by · 12 Comments 

    This brief article covers the customization of meeting invitations for Microsoft Teams for two different purposes.  One is focused on reviewing the same basic branding options which were previously made available in Skype for Business and have recently come to Microsoft Teams, while the other is related to the additional invitation details which are part of the Microsoft Cloud Video Interop (CVI) solution.

    Organization Information

    A feature that has been available since Lync Server was the ability to perform some limited customization of what automatically appears in Lync or Skype meeting invitations created in Outlook.  These options were limited to simply adding a small image file, typically used for adding a company logo, providing one or two additional URLs which would appear as links for users to find additional help or legal information, and adding basic text to a footer to contain any additional instructions.

    This capability has recently been brought to Microsoft Teams by way of the Microsoft Teams Admin Center.  To globally configure any of these options for all users in the tenant simply follow these steps.

    image

    • Under the Email invitation section configure any or all of the desired fields.

    image

    The Logo URL field should be populated with a publicly available link to a .JPG or .PNG image file that is no larger than 188×30 pixels. The file itself is not embedded in the invitation, only an HTML link is added which will load the source image if it is accessible on the client reviewing the invitation.

    The Legal URL and Help URL fields can optionally be populated with any URL, although the link titles will only appear as ‘Legal’ and ‘Help’ in the actual invitation.

    The Footer can contain only standard, unformatted text and is limited to 255 characters.  This text will appear in the invitation exactly as entered, so if HTML code was used, for example, then that would appear as raw HTML code in the invite as well.

    • Once customization is complete click the Preview button to see an example of what the meeting invitation will look like.

    image

    Note that the formatting in the preview will not look exactly as it will in a real invitation and the logo image is not currently displayed here either.  Also, if Cloud Video Interop is enabled on the tenant the additional VTC meeting information does not appear in the preview.

    • Once the desired results are seen then click the Save button at the bottom of the page to apply the changes to the tenant.

    In order to see the final results simply schedule a new Teams meeting invitation using any of the supported clients, although it may take several hours after saving the changes before they begin to appear in new invitations.  As this change only applies to new invitations then obviously any previously scheduled Teams meetings created by any users in the tenant will remain unchanged.

    Cloud Video Interop Details

    Another minor, yet important detail which can be customized in Microsoft Teams meeting invitations is the hostname provided in the video conferencing device details provided by the Cloud Video Interop service.  By default when a tenant enables CVI for Microsoft Teams they would typically be using the hostname provided by the specific Microsoft partner solution which was opted for. For example, the Poly RealConnect Service utilizes the hostname "t.plcm.vc" to route all calls from standards-based endpoints to the Poly services resident in various Azure datacenters worldwide.

    Users who are enabled for this service will have additional information provided in their Teams meeting invitations specifically designed to allow standards-based video endpoints to join.  This information appears under the "Join with a video conferencing device" section, as seen below.

    image

    Note that the standard configuration utilizes the CVI provider’s domain highlighted above, but if desired this can be customized to use any hostname which is part of an owned domain namespace.

    A custom hostname can either be configured during the initial CVI configuration steps or after the solution has already been enabled.

    Configure DNS

    Before making any changes to the Microsoft Teams configuration a new custom hostname must be selected, configured, and allowed to replicate through DNS servers.

    • Select a new hostname in the desired domain (e.g. video.msteams.net).

    • Connect to the administration portal or application for the DNS provider or service which currently manages DNS records for the selected domain (e.g. msteams.net) and create a new DNS Alias (CNAME) record for the desired hostname which points to ‘t.plcm.vc‘.

    image

    Wait for some time to pass and then check to see if the new record has replicated throughout the Internet sufficiently.  Public DNS servers like Google (8.8.8.8) or Cloudflare (1.1.1.1) can give a good indication of replication status.

    • To check if the new DNS record is available open a command prompt and run the following nslookup command.

    nslookup video.msteams.net 8.8.8.8

    image

    Once the new record has replicated then a successful resolution should look like the results shown above, where the ‘t.plcm.vc‘ record is listed as an alias.  Now the custom hostname is ready to be added to the Teams invitations.

    Configure Meeting Invitation

    Now that the desired DNS record has been configured and replicated sufficiently the meeting invite creation process can be updated to leverage this new hostname.  Again, this change will only apply to newly created meetings so any previously scheduled Teams meetings will still display the originally configured hostname.

      • Open Windows PowerShell and connect to the Skype for Business Online PowerShell module using the following cmdlets, replacing the highlighted portion with the username of an administrative account in the target Office 365 tenant.  Enter the account password when prompted.

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

    image

    Get-CsVideoInteropServiceProvider

    image

    In this example the Polycom provider was already configured in the tenant and is using the default hostname. 

    In the following command the configuration will be changed to replace the existing ‘t.plcm.vc‘ hostname with the customized ‘video.msteams.net‘ hostname.

    Set-CsVideoInteropServiceProvider -Identity "Polycom" -TenantKey "680450644@video.msteams.net" -InstructionUri "https://dialin.plcm.vc/teams/?key=680450644&conf={ConfId}&domain=video.msteams.net"

    The Identity parameter should match the identity shown in the previous cmdlet for the currently selected service provider.

    The TenantKey parameter needs to include the same numeric string shown in the existing configuration, with only the hostname changing to the desired string.  Any incorrect changes to the tenant key will render CVI unfunctional for newly scheduled meetings.

    The InstructionUri parameter also needs to be updated to include an additional value for the domain which is leveraged by the Poly One Touch Dial app and service in order to identify the target FQDN in Teams meetings.

    If this was a new CVI configuration then simply use the guidance above when initially running the New-CsVideoInteropServiceProvider cmdlet.

    Once sufficient replication time has elapsed (typically within 8 hours) then the new hostname should begin to appear in new Teams meeting invitations.  The example invitation shown here includes both the custom organization details outlined earlier in this article and the custom CVI hostname.

    image

    RealConnect for Clariti

    March 15, 2019 by · 15 Comments 

    Several previous articles on this blog have gone into details on the Polycom RealConnect video interoperability solution for Lync and Skype for Business meetings.  Most recently this article attempted to clarify all the different models available to various Polycom video infrastructure and Microsoft Skype for Business deployments across on-premises installations, cloud offerings, and hybrids of both.

    As a refresher the entire Polycom RealConnect solution falls into two main categories: RealConnect for Clariti and the RealConnect Service.  This article will focus on the available models which leverage a traditional on-premises deployment of standards-based infrastructure included in the Polycom RealPresence Clariti licensing model.

    Two recent advances have occurred in the RealConnect solution set:

    1. The expansion of RealConnect to include support for Microsoft Teams meetings.  This compatibility was initially launched last year in the RealConnect Service to support connecting standards-based Video TeleConferencing (VTC) endpoints into Microsoft Teams meetings, and is now also available in the RealConnect for Clariti model which allows on-premises video meetings to be cascaded into Microsoft Teams meetings.

    2. The introduction of an simplified deployment model for supporting Skype for Business Online meetings in RealConnect for Clariti.  Previously in order to support Skype for Business Online meetings the Polycom infrastructure components required that at minimum a single Lync or Skype for Business Front End server/pool and a single Edge server/pool remained on-premises.  That is no longer the case via the introduction of a light-weight, stateless application which now allows for all components of Lync or Skype for Business to be removed.

    Infrastructure

    The core Polycom Server infrastructure components which are provided within the Clariti licensing model have been covered in a previous article, so refer to it for a deeper understanding of the overall solution and what each server is and does.  As a brief summary though, the Polycom Servers used throughout some or all of the RealConnect for Clariti architectures are as follows:

    • Distributed Media Appliance (DMA) is a core component which, for the purposes of RealConnect, primarily handles the signaling between each component and an on-premises Lync or Skype for Business Server Front End server or pool.  The DMA also provides for VTC endpoint registration and manages the Polycom Multipoint Control Unit (MCU).

    • Collaboration Server (RMX) is the aforementioned MCU which supports both standards-based and Microsoft-specific media codecs.  In some models it performs the transcoding duties between the standards-based media and the Microsoft media streams coming from and going to the Lync/SfB MCU.

    • ContentConnect Solution (CCS) is an additional software-only MCU that was created solely to transcode content sharing sessions between standards-based protocols like H.239 and Binary Floor Control Protocol (BCFP) into Microsoft’s sharing protocols like Video-Based Screen Sharing (VBSS) and Remote Desktop Protocol (RDP).

    There are also two additional Polycom Servers which are not included as part of the Clariti licensing.

    • Workflow Server (WS) is an application server which can host several different Polycom application-based solutions.  For RealConnect this server has two potential purposes: primarily performing Skype meeting discovery tasks as well as hosting the optional One Touch Dial (OTD) application for VTCs.  Installation and configuration of this server is provided via paid professional services engagements.

    • Cloud Relay (CR) is similar to the Workflow Server except that is a lightweight, freely available virtual server image which, once imported into a VMware or Hyper-V host, is used to connect to Polycom and/or Microsoft services in Azure.  This server can be utilized for multiple capabilities in RealConnect alone, as well as for other Polycom services, like some endpoint management tasks unrelated to RealConnect.  For the purpose of RealConnect for Clariti though it is used to house a Microsoft SIP adapter which handles signaling communications between the DMA/RMX/CCS components and Skype for Business Online.

    Topologies

    There are currently 4 different topologies available wit RealConnect for Clariti which provide the RealConnect experience for Microsoft meeting platforms: Skype for Business Server, Skype for Business Hybrid, Skype for Business Online, and Microsoft Teams.

    image

    Skype for Business Server

    This is the original deployment model for RealConnect, first introduced with Lync Server 2013, and continues to be supported today through Skype for Business Server.  This solution is based on the core video infrastructure running on DMA, RMX, and CCS which performs the necessary translation between standards-based and Skype for Business protocols and codecs.

    image

    The basic call flow for the first VTC attempting to call into a Skype meeting hosted on the Skype for Business Server is as follows:

    1. A VTC that is registered (via SIP or H.323) to the DMA places a call to the numeric Audio Conferencing ID included in the Skype meeting (e.g. 789456) over the endpoint’s preferred dialing protocol.

    2. The DMA parses its preconfigured Dialing Rules and through a process of elimination determines that dialed string (e.g. 789456) is not another registered endpoint or a statically defined traditional Virtual Meeting Room (VMR) and then attempts to check with any configured external SIP peers.

    3. Using Microsoft SIP over a secure TLS outbound connection via an established Trusted Application Pool configuration with the Skype for Business Front End server the DMA asks if there is a Skype meeting with that Audio Conferencing ID.  If one exists then the server responds to the DMA with the Skype Meeting URL (e.g. https://meet.msteams.net/jschertz/ABCD1234).

    4. The DMA then dynamically creates a new VMR using the conferencing ID (e.g. 789456) on the RMX and then directs the VTC to establish media with the RMX.  These media sessions are utilizing standards-based protocols and codecs like Advanced Video Coding (AVC), various audio codecs, and potentially content sharing sessions over H.239 or Binary Floor Control Protocol (BFCP).

    5. The DMA also instructs the RMX to place an outbound call from that same VMR into the resolved Skype for Business meeting.  The RMX establishes a native Microsoft media session with the Audio Video Multipoint Control Unit (AVMCU) running the Skype for Business Front End server.  These media sessions can utilize Scalable Video Coding (SVC) via the X-H264UC protocol, RealTime Video (RTV), and a host of common audio codecs.

    6. The DMA similarly instructs the CCS to establish a connection to the Application Sharing Multipoint Control Unit (ASMCU) on the Skype for Business Front End server.  The media sessions can support SVC desktop sharing over Video-Based Screen Sharing (VBSS) and Remote Desktop Protocol (RDP).

    At this point the cascaded RealConnect meeting has been established and any additional VTCs attempting to join the same meeting will be connected directly to the active VMR.

    Skype for Business Hybrid

    Once on-premises deployments of Lync and Skype for Business Server began connecting to Lync and Skype for Business Online tenants an updated solution was required to support RealConnect for meetings hosted by users homed online.  Supporting these split-domain hybrid environments required a wholesale change in the way that Lync/Skype Meetings were discovered and connected to as compared to when simply working with only an on-premises deployment.

    The Polycom Workflow Server was thus introduced to tackle this new workflow which would provide a solution for supporting meetings scheduled by not only server-homed Lync/Skype users but also any online-homed users which had been migrated to the cloud.  Whereas in the Skype for Business Server model the DMA dynamically performs the meeting discovery when the VTC places the call, in this model the meeting discovery happens prior to the call being placed.  In fact, the Workflow Server handles this after the meeting is scheduled, but before any endpoints attempt to connect.  Thus, when a Skype meeting is scheduled by a client that meeting invitation must pass through Workflow Server in order for RealConnect to be available for that meeting.  Typically this is not an issue as a meeting room needs to be invited to leverage the One Touch Dial workflow.  But in order to insure that an unscheduled VTC can join, even when manually dialing a provided audio conferencing ID in the meeting then there are two basic methods available.  Either by instructing users to always invite a special, dedicated resource mailbox to all Skype meetings (crude, yet effective) or by defining an Exchange Transport Rule (supported in both Exchange Server or Exchange Online) which identifies Skype meetings and automatically sends a copy of the message to a single dedicated resource mailbox (more elegant).  In either approach the Workflow Server is configured to monitor that mailbox and thus will be aware of every Skype meeting scheduled in the organization, where it will scrub the email for the meeting URL and then proactively provide it to the DMA.

    image

    Thus, the basic call flow for the first VTC joining a meeting hosted in Skype for Business Online is similar to the previous model, except for the fundamental difference in the initial Skype meeting discovery process.

    1. A Skype meeting is scheduled in the environment and the invitation is seen by Workflow Server within a matter of minutes.  Workflow Server identifies the embedded Skype Meeting URL and then either records the existing Audio Conference ID or dynamically creates a unique ID (if the Skype meeting invite does not include any Audio Conferencing details) which is used only for the DMA to generate a new VMR number.

    2. The Workflow Server takes this information and then sends it to the DMA, essentially instructing it to create a static VMR using the provided ID and Skype Meeting URL.

    3. Now, when a DMA-registered VTC attempts to join this Skype meeting the DMA will recognize that the call matches a VMR already defined in its own database which includes the destination Skype Meeting URL.

    4. From this point on the remainder of the call setup is nearly identical to what happens in the Skype for Business Server model explained earlier.  The only difference is that now outbound media sessions for online meetings can cascading directly to MCU resources in Skype for Business Online.  Meetings hosted by the on-premises MCU for server-hosted users are still cascaded in the same fashion as in the previous section, and in either case the same transcoding workloads are still all occurring on the Polycom Servers on-premises.

    Skype for Business Online

    Providing the RealConnect solution for environment using only Skype for Business Online requires the most on-premises Polycom components of any of the RealConnect modes.  This is because not only is the heavy lifting still all being performed by Clariti itself (communicating directly to Microsoft components via MS-SIP and transcoding audio, video, and content sharing media streams), but now in the absence of any on-premises Lync/Skype for Business Server the Polycom Server components require something local to communicate with via Microsoft SIP.

    The core components of DMA, RMX, and CCS perform the same roles as in the previous topologies.  The Workflow Server is still required here as it is in the hybrid topology to handle Skype meeting discovery and population into the DMA database.  The main difference is that the Cloud Relay (CR) server is now added to host a Microsoft SIP gateway and provide the needed communication link between the Polycom Servers and Skype for Business Online.

    Previously the Polycom Servers would each communicate using Microsoft-SIP directly to the local Lync/Skype for Business Front End Server/Pool via the standard Trusted Application model.  Recently that architecture has changed to allow the removal of all on-premises Skype for Business servers.  The Cloud Relay allows this by hosting a small Microsoft SIP adapter which the Polycom Servers instead communicate with as a bridge to Skype for Business Online.  Note that this is only signaling traffic and no media traverses the Cloud Relay.  Media will go directly from the RMX and CCS to MCU resources in Skype for Business Online, typically across the public Internet, into the Microsoft Azure Cloud.  The Cloud Relay provides additional assistance here by also using its default connectivity to resident Polycom Services in Azure (which are a core part of the separate RealConnect Service, but incur no additional licensing cost here) in order to leverage media-establishment by way of ICE/STUN/TURN components.  Again, this communication is limited to signaling, meaning that ICE instructions are provided by the service but the actual media communications are directed toward the Skype for Business Online Edge services in the cloud.

    image

    Microsoft Teams

    Providing a solution into Microsoft Teams meetings with RealConnect for Clariti is the simplest and lightest (in terms of required on-premises components) of any model to-date.  This is because the bulk of the work has been shifted to the cloud, adjacent to the Microsoft Teams services.  Whereas for Skype meetings the Polycom infrastructure is dealing with all the translation and transcoding on-premises, that workload is all handled for Teams meetings by the Polycom RealConnect Service in the Azure cloud.  The main reason for this difference is that the CVI solution provided by Microsoft requires partners to use components resident in Azure that communicate directly into Teams, which Microsoft provides in the way of SDKs and bots.  So, in this model the Clariti components are simply cascading standards-based calls up into the RealConnect service in Azure, which in turn handles the signaling translation and media transcoding workloads with Teams.

    As can be inferred from the following diagram the overall call flow is equally simplified from the Skype for Business models discussed earlier.  The only technical requirement in this topology is that the DMA is running at least version 10.0.0.2 which includes new Dial Rule functionality for cascading into Teams meetings.  None of the other Polycom Servers shown in the previous diagrams are required for supporting Teams meetings.

    image

    In regards to the call flow The primary difference between Skype and Teams here is that Polycom Servers do not need to perform and meeting discovery, as the Teams meeting invitations already include all the necessary standards-based details.  This information is provided in the original Teams meeting as described in this article.

    1. A VTC places a call to the SIP or H.323 address provided in the Teams meeting invitation (e.g. 123456.321654987@t.plcm.vc).

    2. The DMA parses its preconfigured Dialing Rules and finds a match for the destination domain of "*.plcm.vc" on a specific dial rule.  It then dynamically creates a new VMR using the Video Conferencing ID extracted from the dial string (e.g. 321654987) and then directs the VTC to establish the call with the RMX.

    3. The DMA also places an outbound, standards-based SIP or H.323 call to the original dial string (e.g. 123456.321654987@t.plcm.vc) which is the Polycom RealConnect Service.  It then instructs the RMX to establish outbound media connections from the local VMR (321654987) to the target meeting in the cloud, using standards-based media protocols and codecs.

    4. The single cascade between the VMR on the RMX and an MCU in the RealConnect Service is then relayed in the Microsoft Teams meeting through the CVI gateway services to provide audio, video, and any screen sharing media between platforms.

    Once the cascade has been established then any additional VTCs calling into the same meeting will be directed to connect to the active VMR on the RMX.

    Realistically though most organizations will need to support RealConnect for both Skype and Teams meetings for some time to come.  This means that multiple models would be used in conjunction, one of the Skype models depending on the type of Skype deployment, and the Teams model.  Due the fact that the architectures are completely different, yet both leverage the core Clariti components of DMA and RMX then a single deployment can easily support any of the Skype and Teams scenarios simultaneously.  What this also means for all deployments is that over time as Skype meetings are replaced by Teams meetings then the overall footprint of Polycom infrastructure components can systematically be removed as they are no longer needed.

    Licensing

    As Skype for Business Meetings are handled completely by Clariti then licensing is already included in the Clariti model.  But for supporting Teams meetings where some of the work is performed by the cloud service then an additional concurrent-use licensing fee is required.  These low-lost licenses are supplementary to the base Clariti concurrent licenses and would be acquired at a 2:1 ratio.  Meaning if an organization was licensed for 10 Clariti concurrent licenses, then no more than 5 of the additional service licenses would be purchased.  This one-half calculation comes from the fact a single Teams meeting being joined by a single VTC will consume two Clariti concurrent licenses to stand up the call.  One license is used to connect the VTC to the RMX, and a second license to consumed to cascade that VMR on the RMX to the RealConnect Service.

    For example, take an environment with 10 Clariti licenses and 5 VTCs.  If all VTCs were to connect to five different Teams meetings at the same point in time the RMX would be at full capacity by the 5th meeting (5 VTCs + 5 cascades = 10 Clariti licenses consumed), which is the high-water mark. Because a maximum of 5 meetings can be cascaded into the RealConnect service, then 5 RealConnect for Clariti service licenses are required at most for this environment.

    image

    Yet in the event that all 5 VTCs were to join the same Teams meeting then the RMX would only be using 6 Clariti licenses (5 VTCs + 1 cascade = 6) and only a single RealConnect for Clariti service license would be consumed.

    image

    Verifying Users Enabled for CVI

    March 13, 2019 by · Leave a Comment 

    This brief article includes a few tips on how to verify which Office 365 user account have been enabled to use a partner-provided Cloud Video Interop (CVI) solution, like the Polycom RealConnect Service.

    When initially configuring an Office 365 tenant for CVI one of the final steps is to enable user accounts for the service.  The steps to do so though are different between Skype for Business and Microsoft Teams.

    Note that in order to perform the PowerShell commands shown in this article one or more PowerShell Online modules will need to be setup on the workstation, if not already configured.  One potentially confusing concept in this article to pay extra attention to is that in order to check the Teams configuration the Skype for Business Online PowerShell Module is used (this module contains both Skype and Teams cmdlets), yet to check the Skype configuration the Azure Active Directory (v1) module is used.  This is because Teams uses a simple user setting via a policy while Skype leverages Office 365 add-on licenses.

    Microsoft Teams

    To enable the service for users on their own scheduled Microsoft Teams meetings the configuration is straightforward.  A simple PowerShell cmdlet would have been used to enable either individual users or the entire tenant globally.

    • Open Windows PowerShell and connect to the Skype for Business Online PowerShell module using the following cmdlets, but replacing the highlighted portion with the username of an administrative account in the target Office 365 tenant.  Enter the account password when prompted.

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

    image

    Verify Service Configuration

    Get-CsVideoInteropServiceProvider

    image

    Verify User Configuration

    The preferred methodology for initially enabling users with RealConnect for Teams is to grant a policy to specific user accounts versus enabling the entire tenant wholesale.  This approach is more common with initial testing and is often used with a small amount of select accounts.

    The Get-CsTeamsVideoInteropServicePolicy cmdlet can then be used to identify if the preferred provider has been enabled globally for all users or not.

    • As the service must be turned on in a tenant this can be confirmed by validating that the ProviderName parameter on the global policy is assigned to the default setting of DefaultProvider.

    Get-CsTeamsVideoInteropServicePolicy

    image

    Note that the DefaultProvider value in the Global policy above is the ProviderName for the ServiceProviderDisabled option.

    • Alternatively if the cmdlet results return one of the provider names (e.g. Polycom) then this indicates that the service has been enabled for every user in the organization, at the global level.

    Get-CsTeamsVideoInteropServicePolicy

    image

    Note that the DefaultProvider value in the Global policy above is the ProviderName for the Polycom option.  In this case the environment has previously been configured to enable RealConnect for Teams with all user’s scheduled Teams meetings.

    But for environments still using the default disabled policy setting then individual user accounts would need to have been enabled.  In order to identify these account the Get-CsOnlineUser cmdlet results can filtered to output only accounts which have the TeamsVideoInteropServicePolicy parameter set to the desired value. 

    • Enter the following command to list only users which are enabled for the Polycom RealConnect Service for Microsoft Teams.

    Get-CsOnlineUser -Filter {TeamsVideoInteropServicePolicy -eq "PolycomServiceProviderEnabled"} | Select-Object DisplayName, UserPrincipalName, TeamsVideoInteropServicePolicy

    image

    In this example the Polycom service is being used, so the value to search for is ‘PolycomServiceProviderEnabled‘.  Currently other possible parameter values are ‘BlueJeansServiceProviderEnabled‘, ‘PexipServiceProviderEnabled‘, or ‘ServiceProviderDisabled‘.

    • Alternately, this cmdlet can be used to list all accounts in the tenant regardless of the policy parameter value.

    Get-CsOnlineUser | Select-Object DisplayName, UserPrincipalName, TeamsVideoInteropServicePolicy

    image

    In the event that the TeamsVideoInteropServicePolicy has been previously set to a specific provider globally, then the individual user’s policy setting will operate in the standard policy relationship.  This means that any users with no value currently on their parameter will use the Global policy setting, but if the user’s parameter is set to a different value then the user-specific value will take precedence over a different, globally assigned value.

    CVI User Status TeamsVideoInteropServicePolicy
    Tenant User
    Disabled ServiceProviderDisabled null (or) ServiceProviderDisabled
    Enabled ServiceProviderDisabled <PartnerName>ServiceProviderEnabled
    Enabled <PartnerName>ServiceProviderEnabled null (or) <PartnerName>ServiceProviderEnabled
    Disabled <PartnerName>ServiceProviderEnabled ServiceProviderDisabled

    In the event that the tenant is globally enabled yet it is desired to return to the default configuration to instead manage user enablement individually then this is a simple procedure.

    • Execute the following cmdlet to return the global policy the ServiceProviderDisabled setting.

    Grant-CsTeamsVideoInteropServicePolicy -PolicyName ServiceProviderDisabled

    Skype for Business

    Unlike Microsoft Teams there is no option to simply globally enable the service on all users in a tenant for Skype meetings.  User configuration in Skype for Business is handled by assigning an Office 365 add-on license entitled "Skype for Business Video Interop for Skype for Business".

    image

    Because this solution is user-license based then enough licenses must be provided in the tenant and they must all be manually assigned to existing user accounts, as well as added to new user accounts as they are created in the environment.

    License entitlement is performed automatically through the Cloud Solutions Provider relationship with the partner and one license will automatically be added to the tenant for every existing qualifying user license that exists in the tenant (e.g. Business Essentials, Enterprise E5, etc).  For example, the tenant used in this article currently contains 20 Enterprise E1 licenses and 4 Enterprise E3 licenses, hence the total of 24 Video Interop licenses.

    image

    Given that Microsoft licenses are the components which enable the service for users then it is trivial to list all users in the tenant via PowerShell which are assigned a specific license.

    • Open Windows PowerShell and connect to the Azure Active Directory PowerShell module using the Connect-MsolService cmdlet.  When prompted enter the credentials of an administrative account for the Office 365 tenant.

    Connect-MsolService

    image

    • Enter the following command to parse all user accounts and list only those with an assigned license containing the string ‘Video’.

    Get-MsolUser | Where-Object {($_.licenses).AccountSkuId -match "Video"} |ft UserPrincipalName,DisplayName,Licenses

    image

    The output above lists any user accounts currently assigned a VIDEO_INTEROP license.

    RealConnect Service Network Communications Explained

    March 5, 2019 by · 12 Comments 

    Multiple recent articles covering Cloud Video Interop for Microsoft Skype for Business and Teams meetings have introduced several Polycom services which are all resident in Microsoft’s Azure cloud.  When leveraging these services it may not be clear as to exactly where they are hosted and what are the best practices for connecting to them effectively and securely.   This article will outline the related services and where they reside with generic firewall guidance.

    Service Overview

    The core interoperability service addresses a simple, singular purpose: to receive inbound calls over either SIP or H.323 protocols from any standards-based Video TeleConferencing (VTC) system capable of communicating with Microsoft Azure datacenters, and then connect those calls into a Skype for Business or Microsoft Teams Multipoint Control Unit (MCU).  This traffic can be routed over the Internet or optionally via an established and correctly configured Express Route connection.  The service is comprised of several different pools of resources covering a variety of tasks, but the primary concepts are the perimeter load balancers which handle the initial inbound calls and the multiple pools of transcoding gateways which will handle the actual video calls.

    In reality the RealConnect service today is actually two side-by-side solutions which are essentially identical in both deployment and overall operation.  Because of the vast difference in the Skype for Business and Microsoft Teams platforms it is not possible to use the exact same set of cloud resources to provide video interoperability into both types of meetings.  Thus two separate solutions are provided within the same service offering: one to provide interoperability into Skype Meetings hosted by Skype for Business Online and Skype for Business Server and another to provide interoperability into Microsoft Teams meetings.

    Basic Architecture

    The following diagrams are over-simplistic representations of the services as they are intended to highlight just a few simple concepts: communication routing and call redirection.  The RealConnect Service only answers calls from endpoints using standards-based signaling protocols SIP and H.323 negotiates media session over standards-based media codecs like H.264 Advanced Video Coding (AVC) and H.239 or BFCP content sharing, for example.

    Skype for Business only deals with its native clients and devices which speak the Microsoft implementation of SIP signaling (MS-SIP) and handle Microsoft implementations of media codecs like H.264 SVC (X-H264UC), RealTime Video (RTV), Remote Desktop Sharing (RDP) and Video-based Screen Sharing (VBSS).

    • Communications between the RealConnect service gateways and Skype for Business Online are contained within the Microsoft Azure datacenter network.

    image

    • Communications between the RealConnect service gateways and Skype for Business Server deployments are between the Azure datacenters and location of the Skype for Business Front End servers, using deployed Edge servers if applicable.

    image

    The Microsoft Teams platform directly handles a simpler list of native clients, devices, and protocols.  While SIP has been replaced by MNP24 as the primary signaling protocol, some of the same media codecs have been borrowed from Skype for Business like SVC for video and VBSS for desktop and application sharing.

    image

    A regional load-balanced IP address serves as the ingress for a call.  The gateways handle the majority of the heavy lifting by performing actual translation and transcoding between the various standards-based systems and the Skype for Business and Microsoft Teams systems.

    1. The initial call from a VTC is first routed to a load balancer in the the logically closest datacenter based on latency at the time of the call.

    2. The load balancer immediately responses to the inbound call by redirecting the VTC at an available gateway in the same datacenter, if available.  If the pools in the same datacenter are not able to handle the call (e.g. offline or at-capacity) then an available pool in the next closest datacenter will be offered.

    3. Once the call is established on a dedicated gateway in Azure that gateway will then communicate with the Skype or Teams platform to join the meeting and handle translation and transcoding of the signaling and media.

    For the service to be reachable by VTCs which are typically located within an enterprise network behind one or more firewalls then outbound traffic over specific ports must be allowed to reach the various load balancers and gateways deployed world-wide.  Given this inherent level of availability and resiliency it is important to allow outbound traffic to all locations.  If traffic is only allowed to geographically-close datacenters then in the event of a partial service outage a call redirected to another datacenter may be blocked.

    Locations

    At the time this article was posted there are four worldwide Azure regions which host the RealConnect Service. There are separate sets of load balancers and gateways specific to connecting into Skype for Business meetings than for connecting into Microsoft Teams meetings, but both sets are deployed side-by-side in the the same Azure datacenters today.

    1. The South Central US datacenter, also referred to as ussouth, located in Texas.
    2. The West US 2 datacenter, also referred to as uswest2, located in Washington.
    3. The West Europe datacenter, also referred to as europewest, located in Netherlands.
    4. The Australia Southeast datacenter, also referred to as australiasoutheast, located in Victoria.

    As pointed out earlier, the initial connection into the service will be directed to the best available resource at the time.  This determination is made by measuring latency and then providing a DNS response pointing to the appropriate load balancer.  The Azure Speed Test site can be used as a handy reference for displaying live network latency statistics from a specific location to any of these datacenters.  At this point in time the South Central US location will likely be where any calls placed from this location will be directed to, but with an average latency that close then it could be either of the U.S. locations at any given time.

    image

    Connectivity

    As previously stated, the RealConnect service currently exists as two side-by-side deployments to handle calls into either a Skype for Business or Microsoft Teams meeting.  There is no mixing of these conferencing platforms and each is driven by unique Outlook meeting invitations.  So what is essentially a single service includes separate ingress points for Skype and Teams purposes.  This can be demonstrated by performing simple nslookup commands on the three different Fully Qualified Domain Names (FQDN) used today: v.plcm.vc, h.plcm.vc, and t.plcm.vc.

    • Perform a nslookup against the FQDN used to join Skype for Business Online meetings: v.plcm.vc

    C:\>nslookup v.plcm.vc
    Server:   UnKnown
    Address:  192.168.1.1

    Non-authoritative answer:
    Name:     jazz-prod-scus.plcm.vc
    Address:  13.85.8.48
    Aliases:  v.plcm.vc
               prod-plcm.trafficmanager.net

    • Perform a nslookup against the FQDN used to join Skype for Business Server meetings: h.plcm.vc

    C:\>nslookup h.plcm.vc
    Server:   UnKnown
    Address:  192.168.1.1

    Non-authoritative answer:
    Name:     jazz-prod-scus.plcm.vc
    Address:  13.85.8.48
    Aliases:  h.plcm.vc
              prod-plcm.trafficmanager.net

    • Perform a nslookup against the FQDN used to join Microsoft Teams meetings: t.plcm.vc

    C:\>nslookup t.plcm.vc
    Server:   UnKnown
    Address:  192.168.1.1

    Non-authoritative answer:
    Name:     teams-prod-scus.plcm.vc
    Address:  23.100.126.112
    Aliases:  t.plcm.vc
               prod-plcm-teams.trafficmanager.net

    These results indicate that the Skype for Business platforms (Online and Server) use the same destination IP, while Teams uses a different IP.  This underscores the two separate deployments in the same service: one for Skype meetings and one for Teams meetings.

    Note that the resolved IP addresses may not match those shown above as these lookups were run a computer in central North America.  Attempts to resolve these FQDNs in other parts of the world will likely return different results, indicating the global nature of the services availability.

    Network Communications

    In an environment configured to allow the required standards-based traffic outbound to any destination on the Internet this service will function as designed without any additional configuration.  The availability and resiliency are automatic.  But in many enterprise networks some or all of the required firewall ports may not be opened, and thus an understanding of what traffic needs to go where can help when configuring firewall policies

    Ports and Protocols

    The requirements listed in the following table are from the RealConnect service documentation, but have been reformatted and labeled to clearly show which ranges are required if only needing to support outbound calls over one standards-based protocol.  To support calls on both signaling protocols simply allow traffic outbound to all of the following destination ports.

    image

    If planning to only support one protocol then note the overlap in the center of the table where SIP and H.323 calls will share the same range or ports for most, but not all potential media session.  For H.323 calls all outbound media (audio, video, and H.239 content sharing) will utilize destination ports in the 20002-30001 UDP range.  For SIP calls that same port range can be used for audio and video, but content sharing using Binary Floor Control Protocol (BFCP) will need to be able to reach destination ports in the service over the 15001-16000 UDP range.

    Destinations

    Now that the types of traffic and destination ports are known the next obvious step is where to allow this traffic traverse.  The simple option is to allow this traffic outbound from any trusted network to the public Internet.  Doing this will allow calls to always reach the service, regardless of the resolved and referred addresses.  But more commonly enterprise networks are not this open and require defined subnetworks or small ranges of IP addresses to be configured on firewalls.

    Polycom has provided a simple way to query for the active IP addresses utilized by the service in the event that outbound traffic cannot be allowed from an enterprise network out to to any destination on the Internet.  Instead of adding the several hundred different subnetworks used in the global Azure datacenter network a list of about 20 IP address can be configured.  Given that these services are spread out over a large area and Azure datacenters contain hundreds of discontiguous subnets it is not really worth the effort of defining the subnetwork as almost every IP address at this moment is in a different subnet.

    Make sure to actually perform the nslookup commands as guided and use the real-time results.  Do not use the actual list of IP addresses shown in this article as some will likely change and new addresses may be added as the service grows.  The examples below will not be updated to reflect future changes.

    If the RealConnect service will be used for joining both Skype for Business and Team meetings then all IPs for both deployments in the service should be configured as allowed destinations in a firewall policy.    (The following results has been colored-coded to indicate which portion of the service each belongs to for illustrative purposes.)

    • To locate all IP addresses in all regions used for Skype for Business and Microsoft Teams solutions simply perform an nslookup against edge-global.plcm.vc

    C:\>nslookup edge-global.plcm.vc
    Server:   UnKnown
    Address:  192.168.1.1

    Non-authoritative answer:
    Name:     
    edge-global.plcm.vc
    Addresses: 104.45.16.73
                13.77.5.248          
               40.127.74.66
               23.101.236.249
               104.214.224.168
               23.100.126.112
               40.91.214.133          
               13.85.8.48
               40.127.71.243
               52.191.165.159
               13.66.242.170
               40.124.6.108
               52.171.141.90
               13.66.206.244
               13.77.56.231
               23.101.74.190
               104.40.177.169
               13.66.192.127          
               40.127.69.62
               52.178.95.62
               104.215.77.58
               13.70.181.113
               13.80.96.87
               13.77.175.139
               13.65.254.254
               52.178.95.48          
               52.246.253.13

    The response above is essentially a concatenated list of both deployments.  Alternatively firewall access lists can be limited to allow outbound traffic to only the IP addresses associated with the desired conferencing platform.  The following FQDNs can be used to identify the Skype half of the service from the Teams half.

    • If only Skype for Business meetings will be supported, then use only the subset of IP addresses returned for edge-sfb.plcm.vc.

    C:\>nslookup edge-sfb.plcm.vc
    Server:   UnKnown
    Address:  192.168.1.1

    Non-authoritative answer:
    Name:     
    edge-sfb.plcm.vc
    Addresses: 52.178.95.48
               104.40.177.169
               13.66.192.127
               52.246.253.13
               52.178.95.62
               13.65.254.254
               23.101.236.249          
               40.91.214.133
               13.85.8.48
               13.66.242.170
               13.77.5.248
               52.171.141.90
                13.70.181.113

    • If only Microsoft Teams meetings will be supported, then use only the subset of IP addresses returned for edge-teams.plcm.vc.

    C:\>nslookup edge-teams.plcm.vc
    Server:   UnKnown
    Address:  192.168.1.1

    Non-authoritative answer:
    Name:     
    edge-teams.plcm.vc
    Addresses: 13.80.96.87
               23.101.74.190
               13.77.56.231
               13.77.175.139
                104.45.16.73          
               40.127.74.66
                40.127.69.62
               52.191.165.159
               23.100.126.112
               40.127.71.243
               104.214.224.168
               40.124.6.108
               13.66.206.244          
                104.215.77.58

    Any firewall policies created to control traffic via destination cannot actual use any FQDNs outlined in this article, only the actual IP addresses (or their subnets) can be used.  There are two different reasons for this:

    1. The FQDNs used to place calls (e.g. *.plcm.vc) are only leveraged in the initial call to reach the regional load balancer.  As mentioned earlier and demonstrated in the next section the call redirection process will attempt a connection to a referred IP address which would not match a rule configured for only the domain name.  The gateways in the service do not even have defined FQDNs, and would not matter if they did as the redirection process does not leverage DNS.

    2. The FQDNs used to list the IP addresses (e.g. edge-*.plcm.vc) are only for reference and no calls are ever placed using these.  Thus adding them to a firewall policy would serve no functional purpose. 

    Additionally it is common for firewall configurations to not allow the use of domain names for egress traffic, either by solution limitation or corporate policy.  This mainly has to do with the insecurity inherent in DNS where the name resolution process can easily be spoofed.

    Example Call

    This section will walk through placing a SIP call from a VTC (Polycom Group Series 500) to a Microsoft Teams meeting in order to demonstrate the call handling.  Additionally the behavior will be dissected to explain what is happening in each step.  The following SIP messages are trimmed down to only show the pertinent information, and the test call was placed over TCP for easy access to the logs.  Normally these calls would be placed over TLS in ensure that the signaling traffic is encrypted over the Internet.

    • A SIP call is placed to 000000.116058723@t.plcm.vc which is used to join the Teams meeting call directly.  This was placed manually but is the exact same dial string used when selecting the ‘Join’ button on the calendar invite.

    • The endpoint will resolve the domain t.plcm.vc using DNS and receive an IP address from Azure Traffic Manager based on the Performance Traffic-Routing method.  This measures the latency between the endpoint and each Azure datacenter hosting Polycom RealConnect services to determine the best location to route the call.

    C:\>nslookup t.plcm.vc
    Server:   UnKnown
    Address:  192.168.1.1

    Non-authoritative answer:
    Name:     teams-prod-scus.plcm.vc
    Address:  23.100.126.112
    Aliases:  t.plcm.vc
              prod-plcm-teams.trafficmanager.net

    The endpoint in this example is located in Chicago and the returned IP address of 23.100.126.112 would likely be from a US-based Azure datacenter, but it does not have to be.  To determine which datacenter the call is being directed to there are few clues in the response.  Firstly, the DNS A Name record returned for that IP address includes “scus” which is short-hand for South Central United States, which incidentally was the site with the lowest recorded latency shown earlier in this article.

    This is an assumption though based on the name, so it would be better to confirm by reviewing the latest version of the Microsoft Azure Datacenter IP Ranges documentation.  By downloading the XML file and searching for a match against that IP there is currently only one possible subnet which could contain that IP address: 23.100.120.0/21.  (For addresses with multiple matches a simple subnet calculator can be used to determine the correct subnet for the desired IP address.)  In the XML file the 23.100.120.0/21 subnet is listed under the ussouth region, indicating which region that IP address is currently assigned.  (Microsoft updates this documentation often as the subnets and locations do change over time, so it is possible that the IP address in this example does not appear in the same region at some point in the future.)

    • Now that the endpoint has a destination address to connect to it will establish an outbound TCP connection to the resolved IP address and if successful will send a SIP INVITE message sent to the SIP address.  (The SDP information included in the invitation denotes the internal IP address of the endpoint.)

    |>>- SEND OVER [TCP] MSG -> NET   2217 bytes  to 23.100.126.112[:5060] sock 101——–>>|
    INVITE sip:680450644.114347572@t.plcm.vc SIP/2.0
    Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166153661-1012
    Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,COMET,OPTIONS,SUBSCRIBE,NOTIFY,MESSAGE,REFER,REGISTER,UPDATE
    From: sip:192.168.1.163;tag=plcm_1166153715-1012;epid=82170146F81DCV
    To: <sip:680450644.114347572@t.plcm.vc>
    Call-ID: 1166153290-1012
    CSeq: 1 INVITE
    User-Agent:PolycomRealPresenceGroup500/6.2.0
    Content-Type: application/sdp
    o=GroupSeries 1140207171 0 IN IP4 192.168.1.163
    c=IN IP4 192.168.1.163

      • The endpoint receives an informational 100 TRYING response from the server.  Note the external public IP (22.33.44.55) of the endpoint network address translation has been changed in this article to hide the actual public IP used during the call..

    |<<- RECV OVER [TCP] MSG <- NET   301 bytes  from 23.100.126.112[:5060] sock 101 ——–<<|
    SIP/2.0 100 Trying
    CSeq: 1 INVITE
    Call-ID: 1166153290-1012
    From: <sip:192.168.1.163>;tag=plcm_1166153715-1012;epid=82170146F81DCV
    To: <sip:680450644.114347572@t.plcm.vc>
    Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166153661-1012;received=22.33.44.55;rport=38955

    • The endpoint also receives a redirection from the server in the form of a 302 MOVED TEMPORARILY response.  This instructs the endpoint to place a new call to the address provided in the Contact field.

    |<<- RECV OVER [TCP] MSG <- NET   452 bytes  from 23.100.126.112[:5060] sock 101 ——–<<|
    SIP/2.0 302 Moved Temporarily
    CSeq: 1 INVITE
    Call-ID: 1166153290-1012
    From: <sip:192.168.1.163>;tag=plcm_1166153715-1012;epid=82170146F81DCV
    To: <sip:680450644.114347572@t.plcm.vc>;tag=3c2129ac
    Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166153661-1012;received=22.33.44.55;rport=38955
    Contact: <sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58:5060;transport=tcp>;expires=15

    As seen above, the new call has an updated SIP address including a new destination located at 104.215.77.58.  What has happened here is that the initial call resolved to the single load-balanced IP address for the entire region (in this case ussouth).  Once the call is accepted the load balancer will redirect the endpoint to another load-balanced IP address which sits in front of the pool of gateways.  Thus the initial call is connecting to a server which only handles SIP and H.323 signaling protocols.  Note that while in most cases the referred address will be in the same datacenter as the original connection, it is possible for the endpoint to be redirected to a different data center to complete the call.  This could occur in the event of a partial service outage, for example.  This is why it is important to configure premises firewalls to correctly handle outbound VTC traffic for both signaling and media communications to all possible destinations in all available datacenters, and not just those in the same region as the endpoints are located.

    • The endpoint transmits an Acknowledgement (ACK) message to let the server know that it received and understood the redirection command.  This will be the last SIP message to use the current Call-ID value.

    ACK sip:680450644.114347572@t.plcm.vc SIP/2.0
    Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166153661-1012
    From: sip:192.168.1.163;tag=plcm_1166153715-1012;epid=82170146F81DCV
    To: <sip:680450644.114347572@t.plcm.vc>;tag=3c2129ac
    Call-ID: 1166153290-1012
    CSeq: 1 ACK

    • At this point the endpoint opens a new TCP connection to the referred IP address and sends a new SIP INVITE with a new SIP address, complete with a new Call-ID value.  It is important to note that the new call is using an IP address instead of the domain name in the original call.  This underscores the need to define any destination hosts via IP and not by domain names in firewall policies.

    |>>- SEND OVER [TCP] MSG -> NET   2293 bytes  to 104.215.77.58[:5060] sock 101——–>>|
    INVITE sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58 SIP/2.0
    Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166557684-1012
    From: sip:192.168.1.163;tag=plcm_1166557738-1012;epid=82170146F81DCV
    To: <sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58>
    Call-ID: 1166557282-1012
    CSeq: 1 INVITE
    User-Agent:PolycomRealPresenceGroup500/6.2.0
    o=GroupSeries 1873749625 0 IN IP4 192.168.1.163
    c=IN IP4 192.168.1.163

    • The endpoint receives a standard 180 RINGING response from the server.  (Depending on factors like latency and loads a 100 TRYING message may also be received prior to the Ringing response.)

    |<<- RECV OVER [TCP] MSG <- NET   568 bytes  from 104.215.77.58[:5060] sock 101 ——–<<|
    SIP/2.0 180 Ringing
    To: <sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58>;tag=8B02E52E-20DFDF35
    Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166557684-1012;received=22.33.44.55;rport=33779
    CSeq: 1 INVITE
    Call-ID: 1166557282-1012
    From: <sip:192.168.1.163>;tag=plcm_1166557738-1012;epid=82170146F81DCV
    User-Agent: Polycom Teams Gateway_00/master-85176_8032-2111-2142-6362-9349-7552-48

    Note that the User-Agent field is now included in responses from the server, indicating that this is call into the Microsoft Teams service. (Calls into the Skype for Business service will be identified with “Polycom/Polycom Soft MCU” as the User-Agent value.)

    • The endpoint receives a 200 OK message from the server along with the server’s SDP information to begin establishing the media sessions.

    |<<- RECV OVER [TCP] MSG <- NET   2114 bytes  from 104.215.77.58[:5060] sock 101 ——–<<|
    SIP/2.0 200 OK
    To: <sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58>;tag=8B02E52E-20DFDF35
    Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166557684-1012;received=22.33.44.55;rport=33779
    CSeq: 1 INVITE
    Call-ID: 1166557282-1012
    From: <sip:192.168.1.163>;tag=plcm_1166557738-1012;epid=82170146F81DCV
    Content-Type: application/sdp
    User-Agent: Polycom Teams Gateway_00/master-85176_8032-2111-2142-6362-9349-7552-48
    o=- 1551111425 1551111425 IN IP4 172.30.0.24
    s=Polycom Teams Gateway
    c=IN IP4 104.215.77.58

    At this point it is common to see additional ACK, INVITE, TRYING, RINGING, and OK messages as the call negotiates.  Sometimes this can occur quickly and other times a handful of seemingly redundant messages will flow between the endpoint and server as call and media negotiations are attempted, but the initial redirection will always occur first.

    Creating Microsoft Teams Rooms Accounts

    February 3, 2019 by · 51 Comments 

    This article revisits the topic of creating accounts which are used by Microsoft Teams Rooms (MTR), formerly known as the Skype Room System (SRS) v2 platform.  The guidance in this article is applicable to creating online accounts for any natively supported device, from Polycom VVX and Trio phones, to the various Skype Room System offerings from Logitech, Crestron, Polycom, HP, and others.

    The directions in this article are performed with an Office 365 tenant utilizing Exchange Online, Skype for Business Online, and Microsoft Teams.  For Server or Hybrid scenarios where the account and/or mailbox is stored on-premises a slightly different process will need to be utilized which is essentially the same as what has been used since the advent of the original Lync Room System platform.

    Account Configuration

    The majority of the configuration is performed in PowerShell in order to create and modify the account.  While the account configuration for meeting room devices is unique, these are still at the core an Active Directory User Object which has been mailbox-enabled in Exchange as a Room type of resource mailbox.  These are not new concepts and the underlying configuration has followed this arrangement for a long time.

    Connect PowerShell

    For more details on using Windows PowerShell to connect to and manage the various Office 365 services online refer to this previous article.  The installation steps in that article must be first be to prepare a Windows workstation with the proper software and modules to connect to each online service remotely via PowerShell.  Once that installation has been completed, or if it has previously been taken care of on the workstation then continue on with the following steps.

    • Search for and launch the previously installed Microsoft Exchange Online Powershell Module.

    image

    • Execute each of the following cmdlets to connect to each service required to complete the account configuration.  Enter the credentials of an account with administrative rights to the Office 365 tenant when prompted by each service.  (Note that all five lines below can be copied and pasted into the PowerShell window at once.)

    Connect-EXOPSSession
    Connect-MsolService
    Import-Module SkypeOnlineConnector
    $skype = New-CsOnlineSession
    Import-PSSession $skype

    image

    Select Account License

    When creating a new account via PowerShell the desired location and licensing information will need to be provided.  If this information is already known then this step can be skipped.

    • Execute the following Get-MsolAccountSku cmdlet to list all available licenses in the current tenant.

    Get-MsolAccountSku

    image

    Record the desired AccountSkuId parameter value (e.g. jschertz:ENTERPRISEPREMIUM) for the desired primary license to be assigned to the room system account.  As discussed in past articles the license assigned to this account will need to include at minimum Skype for Business Online Plan 2 and/or Microsoft Teams, but often Business Premium or Enterprise plans are used.  In December 2018 Microsoft introduced a new Meeting Room Office 365 license subscription specifically for devices, so these licenses are ideal for devices like Microsoft Teams Rooms.

    In this article the Meeting Room license (e.g. jschertz:MEETING_ROOM) will be used.  Also take note that this tenant includes Calling Plan add-on licenses (jschertz:MCOPSTN2) which will be assigned to the account.  This is an optional step but provides additional functionality to the room systems by allowing PSTN calls to and from the room.  Because the new Meeting Room license

    Define Variables

    In order to streamline this process by allowing for a simple copy/paste of most cmdlets then the next step is to define a host of variables which will be used throughout the various steps.  Enter the following lines to set the variables to the desired value for each item.

    • Set the desired identity (User Principal Name (UPN), SMTP address, SIP URI, etc.) of the new account as the $newRoom variable.
    • Select an appropriate display name for the account as the $name variable.
    • Define a new, valid password as the $pwd variable.
    • Enter the desired license name which was discovered in the previous section as the $license variable.
    • Enter the valid 2-letter country code for the appropriate location where this account will be used as the $location variable.

    $newRoom="mtr@msteams.net"
    $name="Microsoft Teams Room"
    $pwd="Password!23"
    $license="jschertz:MEETING_ROOM"
    $location="US"

    image

    Create New Account

    This step will create a new account in Azure Active Directory and simultaneously mailbox-enable the account in Exchange Online as a Room resource mailbox.  It also sets the password defined in the previous section and then enables the account for authentication.

    • Run the following New-Mailbox cmdlet to create the new account.

    New-Mailbox -MicrosoftOnlineServicesID $newRoom -Name $name -Room -RoomMailboxPassword (ConvertTo-SecureString -String $pwd -AsPlainText -Force) -EnableRoomMailboxAccount $true

    image

    It is recommended to wait about 30 seconds after the mailbox has successfully been created before attempting to run the commands in the next section, otherwise errors may occur.

    Configure Account

    The following steps will be used to configure the additional requisite and recommended options on the account and mailbox.

    • After waiting 30 seconds run the following Set-MsolUser cmdlet to disable password expiration and set the UsageLocation.

    Set-MsolUser -UserPrincipalName $newRoom -PasswordNeverExpires $true -UsageLocation $location

    image

    • Run the following Set-MsolUserLicense cmdlet to assign the appropriate Office 365 license to the new account.

    Set-MsolUserLicense -UserPrincipalName $newRoom -AddLicenses $license

    image

    • Run the following Set-Mailbox cmdlet to set the Outlook MailTip which appears when sending meeting invitations to the room mailbox.

    Set-Mailbox -Identity $newRoom -MailTip "This room is equipped to support Teams and Skype Meetings"

    image

    • Run the following Set-CalendarProcessing cmdlet to configure how meeting invitations are processed by Exchange for this mailbox. 

    Set-CalendarProcessing -Identity $newRoom -AutomateProcessing AutoAccept -AddOrganizerToSubject $false -RemovePrivateProperty $false -DeleteComments $false -DeleteSubject $false -AddAdditionalResponse $true -AdditionalResponse "Your meeting is now scheduled and if it was enabled as a Teams or Skype Meeting will provide a seamless click-to-join experience from the conference room." 

    image

    It is especially important that the -DeleteComments and -DeleteSubject settings are applied correctly, otherwise invitations may appear on the meeting room device but without the "Join" button needed to connect to the meeting.  These two parameters are set to $true by default when creating a room mailbox through normal methods, thus they must be manually set to $false as shown here.

    Enable Meeting Room

    These steps are required to enable the account for use with Skype for Business and/or Microsoft Teams.  It is recommended to wait at least 5 minutes after initially creating the account before attempting to enable the account as a meeting room in Skype for Business Online, due to replication intervals.  Sometimes it can take even longer (have seen up to 15 minutes) before this step will successfully complete.

    • Run the following Get-CsOnlineUser cmdlet to list the assigned SIP registrar(s) for all Skype-enabled accounts in the tenant.

    Get-CsOnlineUser |ft RegistrarPool

    image

    The results above indicate that all accounts in the tenant are in the same pool (e.g. sippoolblu2a05.infra.lync.com). 

    • After waiting several minutes run the following Enable-CsMeetingRoom cmdlet, replacing the RegistrarPool value with the FQDN returned in the previous step to enable the new room account.

    Enable-CsMeetingRoom -Identity $newRoom -SipAddressType "EmailAddress" -RegistrarPool "sippoolblu2a05.infra.lync.com"

    image

    If the previous cmdlet returns an error of "Management object not found for identity" then the account enablement has not yet been completed in the cloud.  Wait a few more minutes before attempting to run this cmdlet again.

    Configure Enterprise Voice

    If the room account will also require PBX and PSTN capabilities then the following steps can be used to enable the account appropriately.  For Microsoft Teams either Direct Routing or Calling Plans can be utilized to provide PSTN services to the account.  The tenant in this example currently has an available Calling Plan license which will be used for this purpose.

    • Run the following Set-CsMeetingRoom cmdlet to enable the account for Enterprise Voice

    Set-CsMeetingRoom -Identity $newRoom -EnterpriseVoiceEnabled $true

    image

    • Assign the appropriate Microsoft Calling Plan license (.e.g MCOPSTN2) to the room account using the following cmdlet.

    Set-MsolUserLicense -UserPrincipalName $newRoom –AddLicenses "jschertz:MCOPSTN2"

    image

    At this point the account configuration is complete and can be used with a meeting room device.

    Device Configuration

    For the purposes of this article the Polycom + HP SRS Microsoft Teams Room solution will be used to test the account configuration, but these instructions are identical for any of they qualified solutions available today from various Microsoft partners.

    The account information can be added to a Microsoft Teams Room device either during the initial setup process by simply booting up the device and following the setup screens, or by selecting the Settings icon in the lower-right corner of the control interface’s default screen.

    • If performing first-time setup then accept the Microsoft Software License Terms and select Next.

    image

    After accepting the license, or if performing the configuration on a previously configured system, then the User Account screen will appear.

    image

    • In the Skype sign-in address field enter the identity selected for the room account which was created (e.g. mtr@msteams.net) and then complete the Password fields.

    image

    The Exchange address field will have automatically populated with the same value entered above and should not be changed given the account configured for this unit has the same value for its account name, SIP URI, and SMTP address.

    The Domain\username (optional) field should be left blank.  This field is only needed in the event that the account’s SIP URI does not match the account’s UPN and/or legacy account name.  In those situations this field should be used to provide UPN (username@domain.com) or the legacy account name (DOMAIN\username).

    • In the Supported meeting mode menu select the Skype for Business and Microsoft Teams (default) option.

    The Supported meeting mode setting is a newer setting which was added last year once support for Microsoft Teams was introduced to the product.  This setting essentially controls which meeting platform(s) can be used as well as which will be used as the default.  The available options are:

    1. Skype for Business only
    2. Skype for Business and Microsoft Teams (default)
    3. Skype for Business (default) and Microsoft Teams

    This platform currently defaults to the Skype for Business only option which means that calls and meetings with Microsoft Teams users will not work and the interface will not provide a "Join" button for any Microsoft Teams meetings seen on the device’s calendar.  To enable support for Microsoft Teams meetings then either of the other two settings must be selected.  The difference in the other two options is that while they both support joining Skype and Teams meeting invitations the "(default)" portion in the name indicates which platform will be used when the New Meeting and Dial Pad options on the home interface.

    The Bluetooth Beaconing setting is also enabled by default, although at the time of posting this article that capability has not yet been made generally available to Microsoft Teams users.  While the beaconing setting and functionality has been appearing in the Microsoft Teams Room software for several release at the point the pairing functionally is not yet available in the desktop or mobile Microsoft Teams clients.  This capability is due to be available soon though so it can be left in the default On state.

    • Once the User Account configuration is correct then select Next and advance through the remaining screens by modifying any desired Features or Theming options, or select Save and Exit if simply reconfiguring the account on an existing system.

    The system will return to its ready state and the interface should appear similar to the following image.  Note that until the new account is invited to a meeting the interface will not show any calendaring information along the left-hand side.

    image

    This new account was immediately invited to both a scheduled Skype Meeting as a Teams Meeting as indicated by the small Skype and Teams icons on associated calendar entry.

    Also, because the account in this example was enabled with a base license which includes a Phone System add-on license as well as the proper Enterprise Voice configuration then the Dial Pad option is shown.  The New Meeting option will trigger the creation of a new Microsoft Teams meeting when inviting another participant based on the previous selection of Skype for Business and Microsoft Teams (default) as the Supported Meeting mode setting.

    Next Page »