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 · 9 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 · 5 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 · 13 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 · 10 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 · 35 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.

    Polycom OTD Service with Cisco Endpoints

    January 26, 2019 by · 5 Comments 

    This article about the Polycom One Touch Dial (OTD) service is another in a series which covers Polycom’s RealConnect service, a Microsoft Azure-based video interoperability service for Skype for Business and Microsoft Teams meetings.

    Before performing any configuration steps in this article it is recommended to first review the Polycom One Touch Dial Service article to gain an understanding of how the services work and why the configuration differs between Polycom and Cisco endpoints.

    Exchange Configuration

    This section will walk through creating a new service account, followed by the initial OTD service portal configuration.  Then a Cloud Relay server will need to be deployed (covered in a separate article) and a single Cisco endpoint added to the OTD portal.  By contrast this configuration is more involved than the basic configuration for Polycom endpoints due to the Cisco endpoint not acting like a native Exchange calendaring client.

    Prepare PowerShell

    The following environment preparation steps are performed using Windows PowerShell to connect to multiple online modules.  The workstation used to perform these commands may need to have some initial setup steps performed to access these modules.  Only the Exchange Online PowerShell and MSOnline modules needs to be installed to support the cmdlets in this article.

    • Follow the steps in the Managing Office 365 with PowerShell article and then connect to both Exchange Online and the MSOnline modules as instructed.  (There is no need to connect to the AzureAD or Skype for Business modules.)

    Connect-EXOPSSession
    Connect-MsolService

    image

    Create Mailbox

    This step may not be required as typically a mailbox already exists for a conferencing room space that is represented in Outlook to book as a resource.  If a new mailbox needs to be created for a specific VTC then the following steps can be used to create an Exchange Room Mailbox using PowerShell.

    For this article a new resource mailbox will be created for use with a single Cisco endpoint.

    • Run the following New-Mailbox command to create a new resource mailbox of Room type, updating the red text with the desired unique ID, Alias, Name, and Password.

    New-Mailbox -MicrosoftOnlineServicesID vtc2@msteams.net -Alias "vtc2" -Name "VTC 2 (Cisco)" -Room -EnableRoomMailboxAccount $true -RoomMailboxPassword (ConvertTo-SecureString -String "P@s5w04d" -AsPlainText -Force)

    image

    If a replication failure warning appears it can safely be ignored as it is just reporting that the new mailbox will take some time to be created and replicated within Exchange Online.  The following configuration steps can be performed immediately.

    If needed, repeat this process to create a room mailbox for every Cisco VTC which will be used with OTD service.

    Configure Mailbox

    With either the new mailbox created above or an existing mailbox the following commands will ensure that the mailbox is correctly configured.  Depending on how existing resource mailboxes were created these parameters may already be set correctly, but sometimes the existing settings will purge the meeting invitation contents to save on mailbox storage.  Without that data included in the room’s copy of the invite then OTD has no information to process and then no ‘Join’ button would appear on the invited VTC.

    • Run the following Set-CalendarProcessing command against the new mailbox as identified by the Identity parameter.  Leave all other parameters at the documented vales, aside from the -AdditionalResponse setting which can be customized to include any message.

    Set-CalendarProcessing -Identity vtc2@msteams.net -AutomateProcessing AutoAccept -AddOrganizerToSubject $false -AllowConflicts $false -DeleteComments $false -DeleteSubject $false -RemovePrivateProperty $false -AddAdditionalResponse $true -AdditionalResponse "This room is enabled for One Touch Dial with Polycom RealConnect"

    image

    If needed, repeat this process for every room mailbox (new or existing) that is (or will be) associated with a supported VTC to leverage OTD.

    Create Service Account

    For environments leveraging Exchange Online this account will require an appropriate Office 365 license.  At minimum an Exchange Online Kiosk license is the lowest-cost option that provides the necessary mailbox, but any Exchange Online, Business, or Enterprise license is more than adequate.  This service account must have a mailbox even though its own mailbox is never actually used throughout the OTD process.  Exchange can only delegate mailbox permission to other mailbox-enabled accounts, hence the need for a license.

    • Using the same process as outlined in the first section connect to both Exchange Online and the MSOnline PowerShell modules and then execute the Get-MsolAccountSku cmdlet to list all available license options currently applied to the Office 365 tenant.

    Get-MsolAccountSku

    image

    The example tenant in this article has available Enterprise E5 licenses (ENTERPRISEPREMIUM), which is clearly overkill for this requirement.  As suggested above a less expensive option of Exchange Online Kiosk (EXCHANGEDESKLESS) can be used instead. 

    • Run the following New-MsolUser command to create a new user account which will be used by the OTD service to connect to Exchange over Exchange Web Services.  Update the red text in the example below with the desired Display Name, User Principal Name, Usage Location (appropriate two-letter country code), License Assignment, and Password.

    New-MsolUser -DisplayName "OTD Service Account" -UserPrincipalName "otd@msteams.net" -UsageLocation "US" -LicenseAssignment "jschertz:EXCHANGEDESKLESS" -Password "P@s5w04d" -PasswordNeverExpires $true -ForceChangePassword $false

    image

    Delegate Mailbox Permissions

    In order to use the new service account to access each and every resource mailbox it will need to be delegated the appropriate permissions to each mailbox.  The only rights this account requires is Read access to just the Calendar folder in each mailbox.

    • Run the Add-MailboxPermission command by providing the Identity of the desired source mailbox, as well as the User Principal Name of the newly created service account.

    Add-MailboxFolderPermission -Identity "vtc2@msteams.net:\Calendar” -User “otd@msteams.net” -AccessRights “Reviewer”

    image 

    If needed, repeat this process to delegate permissions for each room mailbox’s Calendar to the single service account.

    Verify Mailbox Permissions

    Once all mailboxes are configured the following optional cmdlet can be used to report which mailboxes in the entire organization the service account has access to.

    Run the following command to query every mailbox in the organization to verify if the service account has the needed Reviewer permissions to the Calendar folders of the room mailbox.

    Get-Mailbox | ForEach-Object {Get-MailboxFolderPermission $_":\Calendar" -User "otd@msteams.net" -ErrorAction SilentlyContinue |ft Identity,FolderName,User,AccessRights}

    image

    Cloud Relay Deployment

    As the Cloud Relay server is used by various services and it not meant only for providing One Touch Dial to Cisco endpoints located on private networks then this portion warrants a separate, complete article.

    • Refer to the Polycom Cloud Relay article to complete the installation and successful pairing of at least one Cloud Relay virtual server in the same routable private network as where the desired Cisco VTC is located.

    Service Provisioning

    This section covers the service-side configuration for connecting the OTD service to the target Exchange environment.

    Configure One Touch Dial Service

    To begin the provisioning process the Polycom One Touch Dial portal will need to be utilized.  As explained in the first article of this series the overall RealConnect service order/trial process would have included providing the email address of an administrative contact.  That supplied email address will have been specifically enabled by Polycom to access the OTP portal for the specific tenant enabled for the service.

    image

    • Click the Sign in with Microsoft button and then enter the credentials of the account which was originally whitelisted for access to the OTD portal (e.g. jeff@msteams.net).

    image

    The first time that an authorized user signs into the portal a prompt will appear requesting permission for the Polycom app to sign in on behalf of and read the user’s profile information and data.

    • Review the requested permissions and then click the Accept button.  (If the "Consent on behalf of your organization" option appears it can be ignored as each user account authorized for the OTD portal will receive this same one-time prompt.  If desired, an administrator can select this option now and other accounts will not receive this prompt when they first sign in.  The behavior of the service is not impacted either way.)

    image

    If this is the first time the portal has been accessed it may report that no devices have been configured.

    image

    Endpoint Configuration

    Now that the OTD service has been connected to the Exchange environment with the service account the first Cisco VTC can be configured.

    • Connect to the Cisco endpoint’s web management interface and verify that XMLAPI Mode is enabled.  This is required in order for the service to push the meeting invitations directly to the VTC.

    image

    • Return to the One Touch Dial portal, select the Devices menu, and then click on the Connect a Device button.

    image

    • Select the desired Cisco device option from the list (e.g. C SX DX EX MX Models).

    image

    • In the General Information section enter a descriptive Name for the device (e.g. VTC2).
    • In the Calendaring section enter the VTC’s associated resource mailbox in the Calendaring Email field (e.g. vtc2@msteams.net).

    • In the Connection section select the appropriate configuration option.  If the Cisco VTC is assigned a public IP address and is directly reachable from the Internet (an unlikely and not recommended scenario) then select the Directly to Polycom One Touch Dial option.  For the typical use-case of the VTC being located on an internal network with a private IP address select the Via Polycom Cloud Relay option and enter the IP address of the Cisco endpoint (e.g. 172.31.16.76).

    • In the Credentials section enter an administrator username and password for the Cisco endpoint (e.g. admin).

    image

    • Click Connect to save the configuration and then note the reported status will likely initially show as Pending.

    image

    • Select the Devices menu and wait for the status to update to Connected.

    image

    At this point the Cisco VTC should show any meetings which have been scheduled on the room mailbox.  The Join button will be displayed prior to the scheduled meeting and trigger a call to the RealConnect service to join a Skype or Teams meeting.

    image

    Polycom Cloud Relay

    December 1, 2018 by · 10 Comments 

    This article is the third in a series which covers Polycom’s RealConnect service, a Microsoft Azure-based video interoperability service for Skype for Business and Microsoft Teams meetings.

    1. RealConnect Service for Skype and Teams – introduces the overall solution and the steps to activate the service for use with Skype for Business Online meetings and/or Teams meetings.  (A future article will cover the additional configuration steps required to support Skype for Business Server or Hybrid deployments with the service.)
           
    2. Polycom One Touch Dial Service – explains what this ancillary service is, how it works, and provides detailed configuration steps for using it with Polycom VTCs.  (A future article will cover the configuration for Cisco VTCs.)      
           
    3. Polycom Cloud Relay – outlines the purpose of this component, how it works, and then walks through the steps for deploying a Cloud Relay virtual server on-premises.  This on-premises server is an optional component to the RealConnect service, only needing to be deployed when using Skype for Business Server and/or supporting Cisco endpoints with the One Touch Dial service.

    The Polycom Cloud Relay is a relatively new component which was born out of the need to provide a lightweight server to handle various supportive tasks for multiple cloud services needs.  Essentially, when moving a solution or workflow from an on-premises server into a hosted service across the public Internet some capabilities may not be able to function entirely in the cloud.  To address this sometimes an on-premises relay may be required to facilitate some forms of communication.

    This server’s primary function is to sit inside enterprise firewalls and open secure outbound connections to various Polycom services running in Microsoft Azure datacenters, meanwhile relaying messages from the cloud over to certain local resources.  The Cloud Relay thus must sit on the private internal network like most other internal servers and not in a perimeter network to perform its duties.  This component is a lightweight virtual machine based on Cent OS which is provided free of charge to Polycom customers in both VMware (.OVA)  and HyperV (.VHD) formats.  By itself the server is useless as it must be paired with a customer tenant utilizing one or more licensed Polycom services.

    Background

    Understand that the Cloud Relay in and of itself really does nothing other than ‘phone home’ and wait for instructions.  When it is first brought online and configured on the local network it will then immediately attempt to connect to a handful of hardcoded Fully Qualified Domain Names (FQDNs) which point to several services running across multiple Azure datacenters.  If these connections are successfully established then the new relay will then sit indefinitely in a holding pen, waiting to be manually integrated into a specific Polycom cloud tenant.  Once this pairing step is completed by an administrator then the correct relay will be permanently linked to that tenant and begin pulling down any provisioned services which have already configured in the tenant.  This includes the automatic download of any apps associated to the configuration, which are essentially docked into the Cloud Relay.

    So in short, this relay is something that is simply brought online the first time using the local console and then from that point forward all management and configuration is performed through the appropriate Polycom cloud portal.  Configuration changes and even software updates to the individual apps are all automatic.  Currently the Cloud Relay itself is not updated so when new versions of the server image are released it would require the deployment of a new image, or replacement of the existing.  But the majority of the various Polycom service offering’s features and functionality comes from the individual apps which are automatically updated as stated.

    Once these apps have been pushed down to the relay then it can start to perform its duties, whatever those may be.  Currently the Cloud Relay is used to perform several functions, most of which are applicable to the RealConnect service, but not all.  For example the Polycom Device Management Service (PDMS) cloud offering leverages the Cloud Relay for some optional device management capabilities.  But as this series of CVI articles is focused on the RealConnect service then the two applicable roles that the Cloud Relay serves is:

    1. To relay meeting invitations originating from Exchange Online or Exchange Server resource mailboxes that the Polycom One Touch Dial service needs to process and deliver to Cisco endpoints.  Obviously if a Cisco VTC is sitting on an internal private network then it would not be possible to open a connection from the cloud directly to that endpoint without establishing a 1:1 static NAT through a corporate firewall, which is a poor and an unused practice.  So the Cloud Relay is used to receive that invitation from the cloud service and then establish a local connection directly to the Cisco endpoint to relay the message.
    2. To relay signaling messages from the Polycom RealConnect service to an on-premises Skype for Business Front End Server/Pool to establish the required connectivity to support RealConnect meetings in the cloud.  This communications path is used by the cloud service to identify and locate the proper Skype Meeting URI for a given scheduled Skype meeting.  The cloud service will then establish a media cascade to the meeting running on the Skype for Business Server through the normal media route via the Skype Edge Server/Pool.  Note that the Cloud Relay only relays signaling, absolutely no media traverses the relay so the processing and bandwidth requirements are very little.

    For high-availability and redundancy multiple relays can be deployed and integrated with the same tenant.  The majority of communications are from the cloud to the relay so resiliency is inherent and failover is automatic as the service will communicate to all available relays.  For the few scenarios where any messages originate from a customer’s network the redundancy behavior can be controlled by the local configurations options like Round Robin DNS, Geo-DNS, or DNS Load Balancing.

    Workflow

    While the Cloud Relay is handling multiple functions the main portion of its communications are always the same.  It will attempt to securely open several outbound connections to Polycom services in Azure, all over two ports: 443 and 5671.  In many environments outbound access to the Internet over 443 is open from any trusted network to untrusted networks and the majority of the traffic transverses here.  But the less-common Advanced Messaging Queueing Protocol (AMQP) traffic leveraged by the Microsoft Azure Service Bus over port 5671 can often be blocked by corporate firewalls and will need to be allowed outbound.

    image

    Communications from the Cloud Relay to the various Polycom Services are based on establishing secure connections to hardcoded FQDNs which, based on geography, will be directed to the nearest Azure datacenter where the services happen to be resident.

    As outlined in the official documentation the Cloud Relay will resolve and then attempt to connect to the following FQDNs via TCP over port 443:

    • api-global.plcm.cloud
    • api-orion.plcm.cloud
    • logging.plcm.vc
    • aquadevacr-plcm365.azurecr.io

    Additionally the Cloud Relay will need to establish connectivity to the Azure Service Bus via TCP over port 5671:

    • servicebus.plcm.vc

    All of these connections are established outbound and no ports need to be opened for inbound connections.  (The official documentation does reference opening TCP 22 inbound from the Internet but that is only for remote SSH connectivity in the event that Polycom support needs to connect directly to the Cloud Relay console during a support call.  Do not actually open this port during deployment.)

    The role of the Cloud Relay is to provide a  two-way communication path with the cloud services by opening the outbound connection and then keeping that connection open for the cloud to send information down as needed.  In the event that outbound connections to the Internet are limited by firewall policy then there are two configuration options typically leveraged. Firstly the FQDNs above can be entered into firewall policies to allow the outbound traffic.  But often domain names are not allowed in firewall policies and only IP addresses and subnetworks may be allowed via defined IT policies.  As service in Azure can sometimes change IP address or subnetworks it is recommended to subscribe to service alerts in the case that any IP addresses will be changed in future upgrades or maintenance routines.

    With the prerequisite communications to the cloud successfully established the Cloud Relay will download the configuration and apps needed to further establish local communications with any on-premises Skype for Business Servers, Cisco VTCs, or (in the case of PDMS) Polycom IP phones like the VVX and Trio.

    • For communications with a Skype for Business Front End Server/Pool the Cloud Relay will need to be able to open a connection over TLS 5061 using an assigned server certificate .  The additional configuration for this outside of the prerequisite Cloud Relay deployment is covered in a separate article in this series, which is mentioned at the top of this article.
    • For communications with a Cisco VTC the Cloud Relay will need to be able to open a connection to the Cisco device over port 443 (or 80).  This additional configuration is also provided in a separate article describe at the start of this article.

    The remainder of this article will walk through the deployment of a single Cloud Relay into an existing VMware ESXi server.


    Management Portal

    Before attempting to deploy the Cloud Relay it is necessary to access the associated Polycom management portal, if that has not already been done.  This article assumes that the portal has not yet been accessed for the tenant, so if it already has then simply skip to the next section.

    The Cloud Relay is managed inside of the Polycom Cloud Service Administration portal which is a web portal hosted in Azure.  After purchasing licenses or requesting a trial license the administrative contact email provided in the order will have automatically been sent two emails.  One email includes the license number for the order (which was covered in this article) and the other email includes instructions to activate the account’s access to the management portal.

    • Locate the email originally sent by cloud-service-team@polycom.com entitled "Welcome to Polycom Cloud Service Administration".

    image

    • Click the Activate Your Account button in the body of the email.

    image

    Unless this link is utilized shortly after first receiving the email the invitation will likely have expired by now.  If that is the case this connection attempt will have triggered a new automated email to be sent with a fresh activation link, as explained in the following screenshot.

    image

    • Return to the same account’s mailbox and look for a new email from the same sender and with the same subject line.  Click the Activate Your Account link in this new message.
    • This time the Activate Account screen should appear asking to define a password for this account. Enter the name associated with the email address, create a new password, and then click Submit.

    image

    This has created a new Enterprise administrator account locally within the Polycom management portal’s database.  It is recommended to add at least one additional administrator account, but instead of creating more local accounts it is recommended to enable authentication with Office 365.

    • Enter the new password which was just created and click Sign In.

    image

    • Select the Administration section at the portal’s home screen.

    image

    • From the navigation menu select Authentication Providers and then click the Office 365 option under Built-In Authentication Providers.

    image

    • Click Enable under the Create Provider section.

    image

    The Office 365 option will now be shown in color to indicate that it has been enabled.

    image

    • From the navigation menu select Users.

    image

    Note that the current administrator’s Sign In Account is shown as "Enterprise and Local".  This indicates that if that local account matches the User Principal Name of a valid Office 365 account then that account can also be used now to sign into the portal.  Essentially there are two separate accounts with the same name available to use: one that is stored in the service’s own database (Local) and one that is available via Office 365 authentication (Enterprise).  This is important to understand that if the two accounts have the same password then signing into the portal may seem transparent, but if different passwords are used then it could be confusing.  This is why it is recommended to simply use Office 365 authentication from this point forward, both for the original account and any others which are added.

    The following steps are optional and can be skipped over if adding a second administrator account is not desired.

    • Click Add to add another existing Office 365 account in the tenant as an administrator.

    image

    • Enter the desired user’s User Principal Name (e.g. steve@msteams.net) and select the appropriate User Role options.  Having a spare full administrator account is recommended, so select all roles, but leave the Sign In Account set to Enterprise Only and then click Save.

    image

    At this point access to the management portal has been enabled and secured.  After deploying the Cloud Relay server this portal will be used again to complete the configuration.

    Deploy Cloud Relay

    The next series of steps will include downloading the Cloud Relay software from the Polycom Support site, importing the virtual machine in ESXi, and then configuring the Cloud Relay.  As mentioned earlier this Cloud Relay will be setup on a VMware ESXi server, but these steps may differ based on the virtual server platform and version.  As this section will be familiar to anyone accustomed to managing virtual server systems then the directions in this section will be brief.

    Download Software

    • Go to the Polycom Cloud Relay support page and download the current version of the desired software (e.g. OVA Image for HyperV).

    image

    • Save the file locally on the same workstation where the ESXi management console will be opened.

    Import Virtual Machine

    • Connect to the ESXi server using the web management console and sign in.
    • Select Virtual Machines from the Navigator and then click Create/Register VM.
    • Select the option to Deploy a virtual Machine from an OVF or OVA file.
    • Enter a name for the virtual machine (e.g. CloudRelay1) and then click the select files option and locate the .OVA file previously downloaded to the local computer (e.g. polycom-cloud-relay-1.1.2-64805.ova).
    • Select the desired Datastore, Network Mapping, and Disk Provisioning options.
    • Review the selections and then click Finish to start the process of uploading the OVA file and establishing the virtual machine.

    Configure Virtual Machine

    • Once the import process has completed successfully select the new virtual machine in the management console and verify that it has been started.  If not, start the VM.
    • Open the Console and then login into the Cloud Relay using the default username ‘polycom‘ and password ‘polycom‘.

    The OS will require that a new password is created.  Pay close attention to the prompts as the existing password will be requested again before asking for the new password.

    • Re-enter the default password of ‘polycom‘ one more time and then enter a new password and confirm the new password.

    image

    • Accept the End User License Agreement to advance to the management console’s main menu.

    image

    • Select the Configure menu.

    image

    • Choose the Configure Network menu and then select the eth0 interface.
    • Select Static address setup and then enter the appropriate IP Address, Network Mask, and Default Gateway and then select OK.

    image

    • Once the network server finishes restarting verify the correct settings are displayed onscreen and then select Change Host Name and enter the desired host name for the Cloud Relay (e.g. cloudrelay1).

    image

    • Select Configure DNS and enter the appropriate DNS settings for the local network.

    image

    • Select Configure NTP and enter the appropriate NTP settings for the local network.

    image

    • Exit to the main menu and select Tools.

    image

    • Select the Connectivity option.

    image

    • Review the connectivity test results to verify that each individual test results in a SUCCESS status and no errors are reported.

    image

    Note that the 61% value shown in the screenshot above does not mean that only 61% of the tests passed successfully.  This is simply the ASCII interface indicating that only 61% of the results are currently shown on the screen.

    • Use the down-arrow to scroll through the remainder of the results.

    image

    As mentioned earlier in the article pass special attention to the last connectivity check to the service bus (polycom-nimbus.servicebus.windows.net) over port 5671 which might be blocked by a firewall.  If all tests have passed successfully then move on to the next step, otherwise check any local DNS configuration or firewall policies to resolve any outbound connectivity issues to the Azure datacenter.

    Integrate Cloud Relay

      • Return to the main menu and select the Integrate option.

    image

    The cloud connector services will be started and then a Registration Code will be displayed on the screen.  Record this code and play close attention as due to the console font the zeros (0) and eights (8) can look similar.  For example, the following code is 03777724 but at first glance almost appears to start with an 8.

    image

    image

      Because the Office 365 authentication integration was configured in the first section of this article there is now a new sign-in option available.

      image 

      • Click the Sign in with Microsoft Office 365 button and, if prompted, select Accept on the permissions request from Polycom Cloud Service Authentication app.

      image

      • Select the Register Devices section.

      image

      • Select the Cloud Relay option and then click Add.

      image

      • In the Registration Code field enter the code provided by the Cloud Relay in the earlier step (e.g. 03777724) and then enter the Device Name (e.g. CloudRelay1) and then click Save.

      image

      The Cloud Relay should now appear in the list, but notice that the Status icon will initially be displayed in gray.

      image

      Wait for a few second and if the deployment was performed correctly then the status should automatically update to a green icon to indicate a successful pairing of the Cloud Relay to this tenant.

      image

      • Return to the Cloud Relay console and select the Application Status option from the main menu.

      image

      At this point the individual components should all be listed as running with no errors reported.

      image

      Additionally the Tools > Application Logs menu can be used to view diagnostic logs for the various components.

      image

      Now that a Cloud Relay has successfully been deployed any additional configuration to support One Touch Dial for Cisco endpoints or RealConnect with Skype for Business Server can be completed.

      Polycom One Touch Dial Service

      November 28, 2018 by · 38 Comments 

      This article is the second in a series which covers Polycom’s RealConnect service, a Microsoft Azure-based video interoperability service for Skype for Business and Microsoft Teams meetings.

      1. RealConnect Service for Skype and Teams – introduces the overall solution and the steps to activate the service for use with Skype for Business Online meetings and/or Teams meetings.  (A future article will cover the additional configuration steps required to support Skype for Business Server or Hybrid deployments with the service.)
             
      2. Polycom One Touch Dial Service – explains what this ancillary service is, how it works, and provides detailed configuration steps for using it with Polycom VTCs.  (A future article will cover the configuration for Cisco VTCs.)      
             
      3. Polycom Cloud Relay – outlines the purpose of this component, how it works, and then walks through the steps for deploying a Cloud Relay virtual server on-premises.  This on-premises server is an optional component to the RealConnect service, only needing to be deployed when using Skype for Business Server and/or supporting Cisco endpoints with the One Touch Dial service.

      The specific term "One Touch Dial" (or its initialism "OTD") is not new.  It has been used for several years to describe various concepts throughout Polycom solutions: a workflow, an action, a server, an application, and now a service.  To offer some clarity, OTD started as an application which provided a simple meeting joining experience to Polycom and Cisco VTCs for on-premises RealConnect meetings.  This application is one of several custom applications which runs on an a dedicated on-premises server called the Polycom Workflow Server.  This server is used only with the traditional RealConnect deployment model which utilizes on-premises Polycom MCUs.

      More recently the OTD functionality was put into Microsoft Azure for use with the RealConnect service.  Yet, not 100% of what OTD does can be put into the cloud.  The on-premises version of OTD essentially operates as both a Microsoft Exchange Web Services (EWS) proxy and an emulator of the Cisco Telepresence Management Suite (TMS), at a Calendaring level only.  Each of those roles are needed to support both Polycom and Cisco endpoints.  Polycom endpoints (like the Group Series, HDX, Trio, etc) all operate as native EWS clients and will automatically retrieve meeting invitations by routinely polling the appropriate Exchange Server or Exchange Online, which is essentially a ‘pull’ operation.  So regardless of the location of the endpoint it is easy for these devices to open a new connection to a server over HTTPS 443.

      On the other hand, Cisco endpoints that natively support One Button To Push (OBTP) do not operate using the same approach.  These endpoints are effectively dumb and rely on another server (TMS) to retrieve meeting invitation emails on their behalf, which are then relayed to the endpoint.  Given that this ‘push’ operation can not typically be performed from an Internet-based service down to a host sitting on a private network behind firewalls then the relay would need to also exist within the same routed internal network. Thus, the Polycom Cloud Relay is utilized as this relay.  Meaning that while most of the operation of the original OTD application was placed into Azure as a service, the TMS emulator portion is provided as an applet which resides on the on-premises Cloud Relay virtual server.

      Workflow Explained

      This simple diagram depicts how the OTD service works for both types of supported endpoints.

      image

      The OTD service acts as an EWS proxy and will fetch the mailbox contents on behalf of the endpoint.  This middle-man step is required as OTD’s primary function is to scan the invitation, looking for RealConnect-enabled meeting invitations.  When am applicable Skype for Business or Teams meeting invitation is found then it reformats the outgoing copy to match what the associated endpoint expects to see to enable the ‘Join’ button to appear and operate correctly on the endpoint.  As the required formatting is different between Polycom and Cisco endpoints then OTD will handle this accordingly.

      • Polycom VTCs communicate directly with the OTD service currently hosted in Microsoft Azure, so when the endpoint performs a routine mailbox check it will connect to the OTD service to trigger the process.  OTD processes the messages and then passes it on to the Polycom endpoint.  To the endpoint this process is transparent and looks like a regular EWS message exchange.
      • Cisco VTCs do not initiate this process though; the environment configuration drives this.  The OTD service itself will monitor mailboxes associated with Cisco endpoints and routinely check for new messages. If any are found then it will push the message down to the Cloud Relay (which has previously established an ongoing secure two-way connection to the OTD service) and then the Cloud Relay will act as a TMS Calendaring service and relay the message to the target Cisco VTC over the local network.  The connection from the relay to the VTC is first attempted securely via HTTPS, but if connectivity over TCP 443 is not available then it will failback to attempting to connect via HTTP over TCP 80.

      Note that while the diagram above depicts Exchange Online as the mailbox location the OTD service also supports on-premises Exchange Server environments.  As long as Exchange Web Services has been published externally in a deployment then the service can leverage the external EWS FQDN to connect to the server and access the required mailboxes.

      image

      Thus the OTD service can be used with Exchange Server, Hybrid, or Online topologies.  For the articles in this series a standard Microsoft Office 365 tenant is being used so Exchange Online mailboxes will be leveraged for all configuration steps.

      Overview

      There are several different configuration options available to provide One Touch Dial capabilities to Skype for Business Server, Online, and Teams meetings which are enabled for RealConnect.  Polycom endpoints support multiple options, but to support Cisco endpoints there is only one possible configuration.

      Pass-Through Authentication

      Polycom endpoints can by default simply leverage pass-through authentication via the OTD service to access the requested mailbox in Exchange.  The required credentials are stored on the endpoint and are used to authenticate through the OTD service (as a proxy) into Exchange. Pass-through authentication can be used with the actual mailbox account’s credentials or a shared service account if desired.

      This method of using the mailbox’s own credentials on the endpoint configuration is the easiest and requires no configuration in the OTD portal, but it may not be possible in environments where resource mailboxes are disabled in Active Directory.  An alternative approach is to utilize a service account to authenticate to Exchange in the event that the resource mailboxes themselves are not enabled for authentication, which is common (and the default) behavior for Exchange resource mailboxes.  The service account model can be configured to use either pass-through or proxy authentication models.

      • With pass-through authentication a single service account is created and then delegated permissions to all applicable resource mailboxes.  The service account credentials are entered in each endpoint alongside the SMTP address of the desired resource mailbox for a given endpoint. The same service credentials are used on every endpoint for accessing each unique resource mailbox.

      image_thumb[16]

      Proxy Authentication

      The OTD service must first be configured to leverage this model as a service account is used alongside manual endpoint configuration in the portal.  To provide One Touch Dial to any supported Cisco endpoints this option is required; pass-through authentication is not applicable.  Polycom endpoints can also use this option if the credentials of the service account are to be known and managed only by IT staff with access to the OTD portal while a different set of local credentials which are known by support staff will be used on the endpoints themselves.  This is a less common approach but does offer flexibility in larger deployments with separate teams managing different components of the overall solution.

      • For proxy authentication the same service account is created and then delegated permissions to all applicable resource mailboxes but is instead stored directly in the OTD portal configuration.  Then unique credentials are manually generated in the OTD portal for each newly configured device, to be used for that endpoint’s local configuration.  The OTD service will act as an authentication proxy, using the local set of credentials for connections from endpoint to the OTD service, and the service account for all communications between itself and Exchange.

      image_thumb[19]

      This remainder of this article covers the multiple configuration options available to Polycom VTCs. A separate article outlines the configuration for Cisco VTCs which require additional steps and as well as the deployment of a Cloud Relay server on-premises.


      There are two general configuration models available for One Touch Dial:

      1. The first is a standard configuration which leverages autodiscovery to locate resource mailboxes stored in Exchange Online that have been correctly configured to allow authentication using their own credentials.  This approach does not require any configuration on the One Touch Dial portal.  As stated, this model only works with Exchange Online mailboxes.  For Exchange Hybrid environments as long as the VTC’s mailbox is stored in Exchange Online this configuration can be used.
      2. The second, more complex configuration option is required when accessing room mailboxes stored on an Exchange Server as a service account will be required alongside configuration of the One Touch Dial portal to connect to the external Exchange Web Services using that service account.  This model is also required when using the proxy authentication model with Exchange Online mailboxes.

      Standard Configuration

      This section will walk through creating or validating the required Exchange mailbox and then configuring a single Polycom Group Series endpoint to leverage the OTD service.  For this method to be viable the resource mailbox (new or existing) will need to be hosted in Exchange Online and enabled for authentication.  If that is not possible or not allowed by enterprise policies then skip to the next section covering the Service Account Configuration methods.

      As explained earlier, there is no need to first sign in to the One Touch Dial portal and perform any service configuration steps when using Polycom endpoints.  The service will automatically leverage Exchange Autodiscover to locate the source mailbox in Exchange Online.

      Prepare PowerShell

      The following environment preparation steps are performed using Windows PowerShell to connect to multiple online modules.  The workstation used to perform these commands may need to have some initial setup steps performed to access these modules.  Only the Exchange Online PowerShell and MSOnline modules needs to be installed to support the cmdlets in this article.

      • Follow the steps in the Managing Office 365 with PowerShell article and then connect to both Exchange Online and the MSOnline modules as instructed.  (There is no need to connect to the AzureAD or Skype for Business modules.)

      image

      Create Mailbox

      This step may not be required as typically a mailbox already exists for a conferencing room space that is represented in Outlook to book as a resource.  If a new mailbox needs to be created for a specific VTC then the following steps can be used to create an Exchange Room Mailbox using PowerShell.

      For this article a new resource mailbox will be created for use with a single Polycom Group Series endpoint.

      • Run the following New-Mailbox command to create a new resource mailbox of Room type, updating the red text with the desired unique ID, Alias, Name, and Password.

      New-Mailbox -MicrosoftOnlineServicesID "vtc1@msteams.net" -Alias "vtc1" -Name "VTC 1 (Polycom)" -Room -EnableRoomMailboxAccount $true -RoomMailboxPassword (ConvertTo-SecureString -String "P@s5w04d" -AsPlainText -Force)

      image

      If a replication failure warning appears it can safely be ignored as it is just reporting that the new mailbox will take some time to be created and replicated within Exchange Online.  The following configuration steps can be performed immediately.

      If needed, repeat this process to create a room mailbox for every Polycom endpoint which will be used with OTD service.

      Configure Mailbox

      Using either the new mailbox created above or an existing mailbox the following commands will ensure that the mailbox is correctly configured.  Depending on how existing resource mailboxes were created these parameters may already be set correctly, but sometimes the existing settings will purge the meeting invitation contents to save on mailbox storage.  Without that data included in the room’s copy of the invite then OTD has no information to process and then no ‘Join’ button would appear on the invited VTC.

      • Run the following Set-CalendarProcessing command against the new mailbox as identified by the Identity parameter.  Leave all other parameters at the documented vales, aside from the -AdditionalResponse setting which can be customized to include any message.

      Set-CalendarProcessing -Identity "vtc1@msteams.net" -AutomateProcessing AutoAccept -AddOrganizerToSubject $false -AllowConflicts $false -DeleteComments $false -DeleteSubject $false -RemovePrivateProperty $false -AddAdditionalResponse $true -AdditionalResponse "This room is enabled for One Touch Dial with Polycom RealConnect"

      image

      If needed, repeat this process for every room mailbox (new or existing) that is (or will be) associated with a supported VTC to leverage OTD.

      Configure Endpoint

      The following steps are used to perform the calendar setup directly on the Polycom Group Series with the newly created and configured resource mailbox.

      • Connect to the web management interface on the Group Series endpoint and then navigate to the Admin Settings > Calendaring Service menu.
      • If not already enabled click the checkbox next to Enable Calendar Service.

      • Enter the Email address (e.g. vtc1@msteams.net), User Name (e.g. vtc1@msteams.net), and Password for the desired resource mailbox.  (Leave the Domain field blank as the User Principal Name format is used in the User Name field which already includes the domain name.)

      image

      • In the Microsoft Exchange Server field enter the Polycom One Touch Dial service FQDN of otd.plcm.vc and then click Save.

      image

      After saving the configuration the Registration Status will typically read either Not Connected or Registration Failed for up to 30 seconds while it is attempting to sign-in via Exchange Web Services.  Once successful the status will automatically update to Registered.

      image

      If the mailbox has been invited to any scheduled meetings then the connected endpoint will now display those invitations on the calendar.

      image

      Furthermore, If any of those meetings are Skype for Business or Teams meetings scheduled by a user enabled for the RealConnect service then the Join button will be displayed, providing the simple One Touch Dial experience used to connect the endpoint directly into the scheduled meeting.  The following Call Statistics details from the Group Series show a successful H.323 video call into the RealConnect for Microsoft Teams service (as denoted by the t.plcm.vc domain name in the call string).

      image

      At this point the standard setup is complete for any Polycom endpoints which are not natively registered to Skype for Business.  In fact the Group Series used in this article was reset to factory defaults just prior to this configuration and the meeting was successfully joined simply by placing an H.323 video call after configuring the calendar.


      Service Account Configurations

      The configuration above simply uses the service’s default capabilities to automatically locate the source mailbox in Exchange Online via standard autodiscover processes.  The mailbox credentials are stored on the endpoint and provided to the OTD service which uses pass-through authentication to connect to the mailbox and then process the invite.  The same automatic process can be used with a service account, given that pass-through authentication is utilized (Option 1).  Yet for proxy authentication (Option 2) some additional configuration is required to create new sets of credentials for each device as well as connect OTD to the Exchange organization and store the service account credentials.

      Create Service Account

      Both options outlined above can utilize the same single service account (e.g. otd@msteams.net), so perform these steps to create the new account and delegate permissions to the resource mailboxes accordingly for either option.

      This service account must have a mailbox even though its own mailbox is never actually used throughout the OTD process.  Exchange can only delegate mailbox permission to other mailbox-enabled accounts, hence the need for the license.

      • Using the same process as outlined in the first section connect to both Exchange Online and the MSOnline PowerShell modules and then execute the Get-MsolAccountSku cmdlet to list all available license options currently applied to the Office 365 tenant.

      Get-MsolAccountSku

      image

      The example tenant in this article has available Enterprise E5 licenses (ENTERPRISEPREMIUM), which is clearly overkill for this requirement.  As suggested above a less expensive option of Exchange Online Kiosk (EXCHANGEDESKLESS) can be used instead.  (As seen above the single Kiosk license in this tenant has already been assigned to another user, so for the purposes of this article one of the free E5 licenses will be used.)

      • Run the following New-MsolUser command to create a new user account which will be used by the OTD service to connect to Exchange over Exchange Web Services.  Update the red text in the example below with the desired Display Name, User Principal Name, Usage Location (appropriate two-letter country code), License Assignment, and Password.

      New-MsolUser -DisplayName "OTD Service Account" -UserPrincipalName "otd@msteams.net" -UsageLocation "US" -LicenseAssignment "jschertz:ENTERPRISEPREMIUM" -Password "P@s5w04d" -PasswordNeverExpires $true -ForceChangePassword $false

      image

      Delegate Mailbox Permissions

      In order to use the new service account to access each and every resource mailbox it will need to be delegated the appropriate permissions to each mailbox.  The only rights this account requires is Read access to just the Calendar folder in each mailbox.

      • Run the Add-MailboxPermission command by providing the Identity of the desired source mailbox, as well as the User Principal Name of the newly created service account.

      Add-MailboxFolderPermission -Identity "vtc1@msteams.net:\Calendar” -User “otd@msteams.net” -AccessRights “Reviewer”

      image

      If needed, repeat this process to delegate permissions for each room mailbox’s Calendar to the single service account.

      Verify Mailbox Permissions

      Once all mailboxes are configured the following optional cmdlet can be used to report which mailboxes in the entire organization the service account has access to.

      Run the following command to query every mailbox in the organization to see all mailboxes the target account has been assigned permissions to.

      Get-Mailbox | ForEach-Object {Get-MailboxFolderPermission $_":\Calendar" -User "otd@msteams.net" -ErrorAction SilentlyContinue |ft Identity,FolderName,User,AccessRights}

      image

      This completes the requisite environment configuration and now the One Touch Dial Service can be setup and enabled.

      Option 1: Pass-through Authentication

      The first option available to use the service account requires no additional configuration.  Simply use the service account’s username and password in the endpoint’s calendar configuration while still pointing to the desired.

      • Connect to the web management interface on the Group Series endpoint and then navigate to the Admin Settings > Calendaring Service menu.
      • Enter the Email address of the associated resource mailbox (e.g. vtc1@msteams.net), but provide the service account’s User Name (e.g. otd@msteams.net), and Password for the desired resource mailbox.  (Leave the Domain field blank as the User Principal Name format should be used in the User Name field which already includes the domain name.)

      • In the Microsoft Exchange Server field enter the Polycom One Touch Dial service FQDN of otd.plcm.vc and then click Save.

      image

      After saving the configuration the Registration Status will typically read either Not Connected or Registration Failed for up to 30 seconds while it is attempting to sign-in via Exchange Web Services.  Once successful the status will automatically update to Registered.

      • Check the endpoint’s calendar to verify any previously scheduled meetings are now displayed, and if any are a Skype for Business or Microsoft Teams meeting created by a RealConnect-licensed scheduler then a Join button should also appear.

      image

      In the example above a daily reoccurring Teams Meetings has been scheduled and the VTC1 mailbox was previously invited.

      • Select the Join button on the Group Series to connect to the scheduled meeting.

      As this example meeting is a Team Meeting hosted in a tenant where the lobby bypass for VTCs has been enabled then the call connected directly into the empty meeting.  Reviewing the call statistics shows the standards-based call (in this case SIP) matches the information shown in the original invitation.

      image

      Option 2: Proxy Authentication

      The second option here will require additional configuration.  The OTD service portal will be leveraged to store the service account credentials as well as define a second set of credentials to be used on the endpoint.  This approach uses two separate accounts for adhering to any IT policies related to knowledge of service account credentials being delineated among different teams. Essentially and administrator can configure the overall solution while help desk personnel can be given only the local credentials which will only function through the proxy.  They cannot be used to access the source mailbox directly in Exchange.

      image

      • Click the Sign in with Microsoft button and then enter the credentials of the account which was enabled for access (e.g. jeff@msteams.net).

      image

      The first time that an authorized user signs into the portal a prompt will appear requesting permission for the Polycom app to sign in on behalf of and read the user’s profile information and data.

      • Review the requested permissions and then click the Accept button.  (If the "Consent on behalf of your organization" option appears it can be ignored as each user account authorized for the OTD portal will receive this same one-time prompt.  If desired, an administrator can select this option now and other accounts will not be prompted when they first sign in.  The behavior of the service is not impacted either way.)

      image

      • Click on the Calendars section and then click Connect next to the appropriate Exchange option.  (Office 365 is used for connectivity to resource mailboxes hosted in Exchange Online and Exchange is used for connectivity to Exchange Server deployments.  As this article is utilizing Exchange Online mailboxes then the Office 365 option will be selected.)

      image

      • Select Connect with Service Account.  (It is not recommended to utilize the Application approach given that permissions to more than just what was specifically delegated would be granted to the OTD service in the selected tenant.)

      image

      When the Connect with Service Account option is selected a Microsoft login window will appear.  This authentication prompt is used to store the service account credentials into the OTD portal so it is important to enter the correct information here.

      • Enter the username and password of the service account which was created earlier (e.g. otd@msteams.net) aa

      image     image

      • Review the requested permissions and then click the Accept button.

      image

      If successful the connection status for Office 365 will display the name of the account currently being used to communicate with Exchange Online.

      image

      • Select Devices from the navigation menu and then click the Connect a Device button.

      image

      • Select the appropriate endpoint; in this example click the RealPresence Group Series button.
      • In the Calendaring Email field enter the email address of the resource mailbox for the desired endpoint (eg. vtc1@msteams.net), enter a descriptive name in the Name field (e.g. VTC1), and then click Create.

      image

      The next window will display a set of automatically generated credentials to use on the associated endpoint to authenticate to the OTD service with.  The username is randomly selected and cannot be changed or customized.  The password can be reset in a later step if desired.

      • Click on the Copy to Clipboard button and then paste the details into a new text file for later use.

      image

        • Connect to the web management interface on the Group Series endpoint and then navigate to the Admin Settings > Calendaring Service menu.
        • In both the Email and User Name fields enter the email address created by the portal in the previous step (e.g. gsaoclxiohed@otd.plcm.vc).

        • Leave the Domain field blank as it is not used for this configuration.

        • Enter the password as provided in the previous step (e.g. Is1ofyLAv1).

        • In the Microsoft Exchange Server field enter the Polycom One Touch Dial service FQDN of otd.plcm.vc and then click Save.

      image

      After saving the configuration the Registration Status will typically read either Not Connected or Registration Failed for up to 30 seconds while it is attempting to sign-in via Exchange Web Services.  Once successful the status will automatically update to Registered.

      Next Page »