Media Port Range Behavior on Polycom Devices

November 8, 2017 by · 5 Comments 

An older, now partially outdated article covered in depth how to configure Quality of Service (QoS) on Polycom VVX phones for use with Lync Server.  Much of the guidance in that article is still applicable and even extends to newer Trio conference phones as well as the newer Skype for Business Server and Online platforms.

What has changed since that article was published was how the Polycom UCS-based devices leverage defined media port ranges.  Previously this had to be handled out-of-band by either manually configuring the phones or using a provisioning server to perform the configuration in bulk.  That configuration required discovering the static media ports ranges defined in the Lync/SfB server platform and then duplicating as close as possible the same configuration on the phones. That manual configuration is typically no longer necessary as more recent firmware releases for the VVX and Trio have added support for picking up and configuring the media port ranges automatically.  During registration to Lync or Skype for Business any defined ranges which have always been passed in-band in the client provisioning information are now properly parsed and applied to the phone configuration.

But there was still an important limitation to that behavior as while the phones could automatically use that information they could not use all of it.  At the time the firmware did not yet support defining separate source port ranges for audio, video, and content sharing streams.  As the vast majority of these devices in the field are VVX IP phones which only support audio communications with Lync/SfB then this gap was not a major issue though.  The media port range for audio ports defined in an environment was correctly utilized by the phones without additional configuration and thus any QoS management of that traffic worked identically between SfB clients and VVX phones.

Yet with the growth of Trio phone deployments with the Visual+ component which added video and content sharing streams meant this gap needed to be addressed.  In later firmware releases this was in fact dealt with by introducing a new set of parameters which allowed the phones to define source listening ports in up to three different ranges to separate the audio, video, and content sharing media channels.  Additionally other compatible video conferencing platforms like the Polycom Group Series also need to be factored in to these environments.  This article will review the behavior and any configuration (if applicable) for each of these family of devices.

With the server platforms if no static media port ranges have been defined then the phones will operate with in their factory default port ranges.  All devices registering directly to Skype for Business Online will be configured with the same globally-defined client port ranges that Microsoft controls for online clients.  Understand that although Microsoft has recently simplified the required port ranges for Skype for Business online clients this does not change the client’s listening port configuration.  Those changes are focused on outbound media connections from internal clients to Microsoft’s data centers.  Yet for environments which may include firewalls separating even some internal networks then peer-to-peer media communications between these clients still needs to be allowed for no differently than has always been the case in Office Communicator, Lync, and Skype for Business.

As mentioned above server platforms can range from no configuration to any variety of custom port ranges, while the Office 365 offering uses a very specific set of defined port ranges.  The examples shown throughout this article will leverage Skype for Business Online which currently assigns the following dedicated port ranges for each media type to registered clients and devices. 

Media Type Port Range
Port Range
Audio 50000 50019
Video 50020 50039
Application Sharing 50040 50059

The configuration above is provided in the <provisionGroup name="ServerConfiguration" > section of provisioning data sent to a registering client.  This following details can be captured by a SIP trace run during the SfB client registration process or by looking through Lync-UccApi-*.UccApilog files found in the workstation’s Tracing folder.





As of the recent September release of 5.5.2 the Trio will both utilize the in-band port configuration received during SfB registration and also takes advantage of new parameters specifically for content sharing traffic so that it is no longer sharing the same port range with video streams as was the case in earlier releases.

There are a few ways to validate the current configuration of a Trio that has already been registered to a Lync or Skype for Business platform.  As stated earlier the devices used in this article are registered to Skype for Business Online so the media port configuration seen will match the table shown above.  The simplest way to see the configuration is to utilize the phone’s embedded web management UI to export the current configuration to a text file and then search for the specific parameters which store this information.

Enable Web Management UI

To perform the steps below it may be required to first enable the web UI on the device as it would have been disabled by default when set to the Skype for Business base profile.

  • Using the Trio touch interface navigate to the Settings > Advanced > Administration Settings > Web Server Configuration menu.  (When prompted for a password the default is ‘456‘.)

  • Turn on the Web Server setting and then select the desired Web Config Mode (e.g. HTTP/HTTPS).

  • Tap the Back arrow and select Save Config.  And changes applied above will trigger an immediate reboot of the phone.

Export Configuration

Once the phone has rebooted the web UI can be used to export the current configuration to a text file.

  • Using the Trio touch interface tap the hamburger menu in the upper left corner to easily find the device’s current IP address.

  • Using a web browser connect to the device IP address using either http or https (whichever options were enabled in the previous steps) and enter the same Admin password as before (default is ‘456‘).

  • Browse to the Utilities > Import & Export Configuration menu and then expand the Export Configuration section.

  • Leave the default selection of All Configuration (except Device Settings) and then click the Export button.


  • Save and open the downloaded Export_all.cfg file in any text editor, or an XML editor of choice if available.  Scan through the results or search for the string "port.rtp.lync" to locate the desired parameters.


As seen above the Trio utilizes the following six parameters to store the configuration provisioned by the registrar.





Query Configuration

Another way to locate this information is by connecting to the phone via Telnet and looking up the parameters by name to see not only the provisioned values but also the device’s factory default values.  This is a more advanced process and may be of interest to some readers for future reference and requires prior knowledge of the specific parameter names.

The phone’s embedded Telnet server is disabled by default so it must be enabled first by importing a configuration parameter into the phone.  Obviously this process also requires that the web management UI is enabled as shown above.  Also be aware that enabling the Telnet server on the phone is a static setting and will stay enabled though reboots, requiring either a factory reset or being manually turned back off.

  • Create a new text file named "enable_telnet.cfg" in any text editor and paste the following text into a single line in the file.

<telnet diags.telnetd.enabled="1"></telnet>


  • Using the web UI browse to the Utilities > Import & Export Configuration menu and then click the Choose File button under the Import Configuration section.

  • Browse for the newly created enable_telnet.cfg file and then select Import.  The results should be reported as "Configuration file imported successfully".


  • Connect to the device IP address using any Telnet client over port 1023. 

telnet 1023


  • When prompted for credentials enter the default admin username of ‘Polycom‘ and password of ‘456‘.

  • At the Admin> prompt enter the command cfgParamName followed by the name of valid configuration parameter. For example "cfgParamName reg.1.address" would return the SIP address of the currently registered user.

cfgParamName reg.1.address


In the results shown above there are several values returned for a specific parameter.  Most importantly valDefault shows the factory default setting for any parameter, which would be null for this type of parameter.  The valWeb value is what was used to store the registered user’s SIP address and this was because the phone was originally registered using the Skype for Business SignIn option in the web UI.

  • Using the cfgParamName command the various media port parameters can be queried to find both the default and current settings.

cfgParamName tcpIpApp.port.rtp.lync.audioPortRangeStart
cfgParamName tcpIpApp.port.rtp.lync.audioPortRangeEnd

cfgParamName tcpIpApp.port.rtp.lync.videoPortRangeStart
cfgParamName tcpIpApp.port.rtp.lync.videoPortRangeEnd

cfgParamName tcpIpApp.port.rtp.lync.contentPortRangeStart
cfgParamName tcpIpApp.port.rtp.lync.contentPortRangeEnd


Notice that while the factory default values shown above as still stored in valDefault the custom values for these parameters are instead stored in valPpsSip which indicates the custom settings originally came from a SIP provisioning process; in this case during registration to SfB Online.

As mentioned earlier it may be desired to disable the Telnet server on the phone once completed.  Follow these steps to reverse that configuration.

  • Create a new text file named "disable_telnet.cfg" in any text editor and paste the following text into a single line in the file.

<telnet diags.telnetd.enabled="0"></telnet>


  • Import this file into the phone using the same process shown earlier in this section.


To validate that the configuration discovered above in the various processes is actually functional the following Wireshark traces were captured during a peer to peer call between a Skype for Business 2016 Windows client and the Trio 8800 with video enabled and the SfB client actively sharing its desktop to the Trio.  Both endpoints were located on the same internal network so any media streams traveled directly between each host’s local IP.  Traffic flows shown below are all from the SfB client ( to the Trio ( as the port configuration this article is focused on is applicable to how the Trio opens up listening ports intended for inbound connections from the other endpoint.

The audio stream seen below was sent from the SfB client over UDP to port 50004 on the Trio which is in-between 50000 ad 50019.


Meanwhile the video stream from the SfB client was directly to UDP 50038 on Trio, correctly falling within the 50020-50039 range.


Lastly the the shared desktop of the SfB client was sent to the Trio over TCP to port 50049 which is also within the new content sharing range of 50040-50059.  Note that the application sharing session was utilizing Remote Desktop Protocol (RDP) which only supports TCP transmission.



As both the VVX and Trio device families are based on the same core Unified Communications Software (UCS) platform then the behavior here is the same.  Any configuration, as explained above, is no longer required as it is all automatic now when registering to Lync Server, Skype for Business Server, or even Skype for Business Online.  That being said the actual configuration utilizes slightly different parameters based on the fact that the VVX line does not support content sharing as it is only a phone.  While video calling is not yet supported with Skype for Business clients it is functional directly between SfB-registered VVX phones in peer calls only, thus correct utilization of the video port range is still important.

Using the same instructions shown above in the Trio section the configuration can be exported or queried on the VVX phone.  Note that the standard Telnet port of 23 is used on the VVX phone, where the Trio uses port 1023 as shown in the examples above.

Using the configuration export process the following parameters were found on the VVX phone registered to the same SfB Online tenant. 



Note that the parameter names here are different than on the Trio.  Firstly the Trio parameters include the additional *.lync.* text in the names and secondly the audio port parameters on the VVX are entitled ‘media‘ instead of ‘audio‘.

Using the Telnet process the two parameter sets query results are as follows:

cfgParamName tcpIpApp.port.rtp.mediaPortRangeStart
cfgParamName tcpIpApp.port.rtp.mediaPortRangeEnd

cfgParamName tcpIpApp.port.rtp.videoPortRangeStart
cfgParamName tcpIpApp.port.rtp.videoPortRangeEnd


This time the valDefault values differ from what was seen on the Trio, indicating different factory default port ranges between the phone families, yet the active port ranges have been provisioned correctly as seen in valPpsSip.

Outside of these configuration differences the registered VVX phone will now function identically a Trio registered to the same environment for audio (and video) streams.

The following table can be used as a quick reference for the defined UCS parameters between VVX and Trio phones.

Media Type Trio VVX
Audio tcpIpApp.port.rtp.lync.audioPortRangeStart
Video tcpIpApp.port.rtp.lync.videoPortRangeStart
Application Sharing tcpIpApp.port.rtp.lync.contentPortRangeStart

Group Series

The Polycom Group Series platform does not currently behave like the phones.  While the Group Series does support native registration to Lync Server 2013, Skype for Business Server 2015, and Skype for Business Online platforms it does not utilize the in-band provisioning settings for media port ranges.  Additionally the Group does not currently separate audio, video, and content streams into different port ranges, although it does allow for some limited customization to approximate the desired configuration.

An allowed custom configuration supports defining a starting port for two separate media port ranges for TCP and UDP traffic, which can overlap if desired.  The port range for TCP traffic is hardcoded to 11 contiguous ports with 61 contiguous ports allowed for UDP traffic.  As the Group currently supports an array of audio and video protocols with Lync/SfB then the audio and video communications will typically be over UDP, unless negotiation fails and the fallback to TCP process is used for these streams.  Also as the Group currently supports only the RDP protocol for content sharing then all supported inbound content sharing streams will arrive over TCP.

This leaves a dilemma for the administrator to address. While the smaller TCP port range can easily be assigned within the larger 20 port ranges typically used in Skype for Business the much larger UDP range will extend beyond that range and potentially up into other ranges.  For example if the Group is configured with a starting port of 50000 it will automatically set 50061 as the ending port.  This means that inbound media streams from SfB clients could potentially travel over any of the defined 50000-50059 range used in Skype for Business Online, resulting in possibilities like video traffic landing in the audio queue, or vice versa.

Now for SfB Online this may not actually be a problem as all meeting traffic will be destined for the Internet and thus attempting to place that traffic in QoS queues internally will more or less be moot once that traffic hits the Internet.  But for Server deployments where the majority of media streams are staying on-premises then it is suggested to look at the overall QoS and media port configuration and potentially adjust the ranges to work better with the current Group Series behavior.  Or it may be desired to treat these dedicated conference rooms differently and thus place traffic destined for those devices in different ranges and queues altogether.

Manual Configuration

The example configuration used here would put the TCP ports up in the Application Sharing range based on the assumption that all inbound TCP media will be RDP traffic and UDP will successfully be leveraged for all audio and video traffic.  But because the UDP ports could contain audio or video then it may be ideal to select a different media port range that is not in use by SfB and then configure the additional range for QoS as desired.

  • Connect to the IP address of the Group Series endpoint using a web browser.

  • Navigate to the Admin Settings > Network > IP Network menu and then expand the Firewall section.

  • Enable the Fixed Ports setting.

  • Set the desired starting port in TCP Ports (e.g. 50000) and the desired starting port in UDP Ports (e.g. 49938).  (Starting ports must be even integers.)

  • Click Save to apply the configuration changes.

Fixed Ports = On
TCP Ports = 50040-50051
UDP Ports = 49938-49999


This example configuration will put all UDP media outside the current SfB ranges, creating a new range of 49938-49999 which can be assigned to whatever QoS queue is desired.

Note that this only impact inbound media sessions to the Group Series.  outbound media sessions will travel over the proper media port ranges as the far-end (clients and servers) will be advertising their listening ports correctly within the SfB configuration.


When capturing the traffic between an SfB client ( and a Group Series ( with both cameras turned of it is easy to isolate the audio traffic.  In the capture below the audio traffic sent from the SfB client to the Group Series arrives on port 49944 via UDP.  This port falls within the defined UDP range above of 49938-49999.


By muting the microphone and turning on the outbound video from the SfB client the majority of the capture will now show the video traffic.  the following series of packets show UDP traffic from the SfB client destined to the Group Series over port 49948.  This port also falls within the same defined UDP range above of 49938-49999.  On the surface there is no definitive way to determine this video traffic is any different than the previous audio traffic, other than possibly using the packet size as an indicator (224 vs. 1193).


Lastly a desktop sharing session was started from the SfB client after stopping the video and muting the microphone.  The most active results at this point were TCP packets sent from the client to the Group Series destined for port 50043.  This port is in the preferred range for application sharing traffic of 50040-50051 as previously defined for TCP traffic.


Note that throughout these captures the SfB client is still correctly sending from and receiving to the port ranges defined in Skype for Business.

Q4 2017 Skype and Teams UG Meetings

November 4, 2017 by · Leave a Comment 

The next round of quarterly Skype and Teams Users Group meetings has been announced and scheduled starting this month.


Latest News

Please welcome members to our newest group in Tampa Bay, Florida.  Also note that the group has expanded the name to include Teams which will clearly be an integrate part of Microsoft’s UV story after the resent announcements at the Ignite conference.

Event Details

This quarter’s events will be conducted in our familiar two-session format:

Session 1: Microsoft Ignite Recap – In this session, we will get you up to speed on all the important announcements that occurred at Microsoft Ignite 2017.  This will include announcements from all our sponsors and Microsoft.  If you missed anything, this is your chance to catch up!

Session 2: The Future of Intelligent Communication – Learn about Microsoft’s vision for Intelligent Communications and how we will bring together the learnings and experiences of SFB communications into Teams Collaborations.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.

For a full schedule of regional events the Skype and Teams Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..

Chicago Event

Our local member Anthony Caragol will be assuming host responsibilities for the suburban Chicago location this quarter.  We will continue the current plan of alternating locations each quarter but are setting the stage to potentially host events next year in both locations to better serve the greater Chicagoland region.

Food will be ready at 5:30pm so come early if you can to spend time socializing with the group before the presentations begin at 6:00pm.

Date Location Address
Thursday, November 30th         
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago Suburban Event Microsoft Midwest District Office
3025 Highland Pkwy., Suite 300
Downers Grove, IL 6051

Understanding Office 365 Licensing for Meeting Devices

August 21, 2017 by · 18 Comments 

The purpose of this article is to explain what type of Office 365 licenses can or should be used with any of the various phones and meeting devices qualified by Microsoft for Skype for Business Online.  These products can natively register to Skype for Business Online using resource accounts which must be assigned the correct licensing.  This covers equipment like the many different IP Phones from five different partners or the several different Meeting Room platforms like the older Lync Room Systems, newer Skype Room Systems, or even the recently qualified Polycom Group Series to name a few.

The guidance covered in this article is not necessarily applicable to desk phones which are assigned to a specific user, as those users would already have an assigned Office 365 license which applies to any client and devices they sign into with their own credentials.  It is the meeting room solutions and other similar shared resources like conference room phones or common area phones which utilize their own dedicated account which are the focus of this article.


As with any device that is registering to Skype for Business Online, be it a phone or video system, a licensed Office 365 account is required.  This can be a standard Skype for Business user or a special Meeting Room account.  Generally it is a best practice to use the Meeting Room account which affords the registered device some unique capabilities and behaviors, but it is not a requirement.  This previous article focusing on Online Meeting Room Accounts covers in detail the different configuration options and guidance around each type.

Once an account is created for the device then a valid Office 356 license needs to be allocated to it before it can be used to register a device.  Typically an empty meeting room might already have an Exchange Online Room Mailbox configured for it which incurs no cost and consumes no license in Office 365, but that is only for room reservation capabilities.  Once that meeting room is equipped with a dedicated Skype for Business device then a Skype for Business license must be assigned to that account, which is not free.

This means that the devices need only to be concerned with the Skype for Business Online portion of licensing.  The Exchange Online portion of the device’s account is still only a Room Mailbox, so then there is no need for Exchange Online plans to be assigned.  That being said many of the Office 365 licensing plans already include Exchange Online licensing so unless dealing with a standalone plans this point is moot.

Office 365 Plans

For those unfamiliar with the various Office 365 licensing plans the following is a list of the current plans which provide Skype for Business Online services in them.  The items in red are the default recommended options in each class and the reasoning for each is explained below.

Standalone Plans

  • Skype for Business Online Plan 1
  • Skype for Business Online Plan 2

Business Plans

  • Business Essentials
  • Business Premium

Enterprise Plans

  • Enterprise E1
  • Enterprise E3
  • Enterprise E5

The absolute minimum Office 365 license required for a device would be a standalone Skype for Business Online Plan 1 license.  But that plan is not recommended based on its limitation of only being able to join other meetings and not create ad-hoc or scheduled meetings.  On the surface this may not seem like a problem as users would not be sending meeting invitations from device’s account, they create or schedule meetings using their own Skype for Business account.  But what about when a user walks into a conference room that is not booked and simply wants to start an ad-hoc meeting?  Or what about adding new participants into an active meeting from the device itself?  Scenarios like those are covered under the Meeting Scheduler capabilities which are included in the standalone Skype for Business Online Plan 2 tier, hence this being the recommended minimum Office 365 license. 

But most Office 365 subscribers today are typically not using the a la carte style standalone plans and are instead leveraging a Business or Enterprise plan.  All of the Business and Enterprise plans listed above automatically include Skype for Business Online Plan 2 in them, as illustrated by the following example showing an Enterprise E3 license expanded to list some of the includes services.


Note the Skype for Business Online (Plan 2) option listed above.  Because all Business and Enterprise plans with Skype for Business leverage Plan 2 capabilities then any of these are sufficient to support joining scheduled meeting and creating ad-hoc meetings as explained earlier. This also illustrates why it is usually incorrect to assign a redundant standalone Skype for Business Online Plan license to an account which is already assigned one of the supported Business or Enterprise plans.

Now, when only a handful of shared devices are deployed in an environment it can be less administrative work to simply assign licenses to these accounts which are already available in the tenant.  Yet from a a cost-savings standpoint it can be overkill to assign a license which may include many additional features that the device is not capable of leveraging and never would be.

For example some of the plans listed above include licenses for Office applications which device do not need.  The reason that Business Essentials is recommended over Business Premium is that the more costly Premium license allows the account to install the Office suite software on multiple workstations, but a device-only account would never be used for that.  This same reasoning is why Enterprise E1 is generically recommended over the more costly E3 and E5 licenses as, like Business Essentials, it does not include the Office suite of applications.

That being said there are other arguments for using Enterprise licensing due to bundled add-on licenses.  In fact there are scenarios where even Business licenses are not valid and would need to be transitioned to Enterprise licenses.  These reasons will be explored in the next section.

Skype for Business Add-On Licenses

Some of the following value-add licensing options can provide additional capabilities to the solution depending on what the device is and needs to do.

Currently the available add-on licenses for Skype for Business Online are:

    • PSTN Conferencing: The Dial-In Conferencing services for joining meetings from a PSTN phone.
    • Cloud PBX: Traditional PBX functionality and support for integration with a traditional PBX system.
    • PSTN Calling: PSTN connectivity hosted directly by Microsoft Office 365.

Here is one area where Microsoft does have some official guidance available online when dealing with licensing Skype for Business devices.  This Office support article includes both details on the various Skype for Business add-on licenses as well as how they are applicable to the newer Skype Room System v2 platform.  Taking that one step further the various Skype Room System scenarios covered in the article can be extrapolated to any device.  Again this is not specific to a single conferencing product, any meeting device follows the same requirement and guidance.

That article includes a table which granularly lists various in-room scenarios and which licenses are required to perform those specific tasks.  As already mentioned there are differences between joining meetings and creating meetings from within the conference room itself.  The information on that support article may be a bit confusing to understand at first glance so the important information has been reworded for simplicity’s sake in the table below.

Standalone Business Enterprise
Join a
Skype for Business Online Plan 1 Business Essentials
Business Premium
Enterprise E1/E3/E5
Initiate an
Skype for Business Online Plan 2 Business Essentials
Business Premium
Enterprise E1/E3/E5
Invite PSTN
via dial-out
Skype for Business Online Plan 2
+ PSTN Conferencing
N/A Enterprise E1/E3 + PSTN Conferencing
Enterprise E5
Assign an
Enterprise Voice
phone number
to the device
Skype for Business Online Plan 2
+ Cloud PBX
+ PSTN Calling
N/A Enterprise E1/E3 +Cloud PBX + PSTN Calling
Enterprise E5 + PSTN Calling

The table above outlines how, for example, a video conferencing system may only need to be licensed for the basic ability to join meetings, but if it or a conference phone needs to also support the typical use-cases of placing PSTN calls or adding PSTN participants into a live Skype for Business meeting then additional licensing may be required.

  • The first two scenarios are already covered in the Meeting Scheduling capabilities included in any plan equivalent to Skype for Business Online Plan 2.  This underscores why using Plan 1 is not ideal as the second scenario is a common task performed in Skype for Business meetings.

  • The third scenario introduces the need for a PSTN participants to be invited on-demand to the meeting.  As mentioned earlier these meetings are typically scheduled by regular users who may already be granted a PSTN Conferencing licensing and the PSTN dial-in conferencing information would have been included in the original meeting invitation.  Thus, a PSTN caller can use that information to manually dial into a conference as usual.  But this third scenario in the table above is something different: it is the ability for someone in the conference room that is already connected to a meeting to use the device itself to manually add a new participant to the meeting, but using a PSTN phone number to call out to that desired attendee.  This action is performed on the device but the phone call actually comes directly from the Skype for Business Online service (not the meeting room device).  The callee is then brought directly into the meeting when answering the call on their PSTN phone.  Assigning a PSTN Conferencing add-on license to a supported plan, or using an Enterprise E5 license will provide this capability.

  • The fourth scenario is not related to Skype for Business meetings at all.  This is simply the ability to assigned a PSTN phone number directly to the device so that it can place and receive peer-to-peer calls to and from the PSTN.  Including Cloud PBX is the step, followed by either getting a PSTN Calling plan directly from Microsoft or connecting to a traditional PBX with PSTN connectivity. 

Important details to further understand the guidance in this table are that (1) the Enterprise E5 plan already includes the PSTN Conferencing and Cloud PBX licenses and (2) that while all three add-on licenses can be used with Standalone and Enterprise plans they cannot be used with any of the Business plans.

So, if an account with a Business plan needs to leverage some Skype for Business PSTN features there are two potential paths. The recommended option is to simply transition to an Enterprise license for that account.  An alternative might be to instead purchase a standalone Skype for Business Online Plan 2 license and assign it to a account which already has Business Essentials or Premium, further allowing the additional of the add-on licenses.  But that is redundant, as pointed out earlier in this article, as well as more expensive.  For example a Business Essentials license and a Skype for Business Online Plan 2 licenses together cost more than the single Enterprise E1 license does.  In short, if any PBX or PSTN capabilities are required in the environment then an E1 license, plus the desired add-on licenses is the recommended path.  In most cases the Business plans will not be applicable for this reason.


Please understand that Microsoft licensing can be very fluid and change over time so the comments in this article are not indicative of any official support statements from Microsoft or any partners.  The information is simply guidance meant to assist the community with successfully navigating what can be a confusing topic so that meeting devices like IP phones or video conferencing systems can be properly deployed.  As these comments are based on my own understanding of the topic gathered from navigating several different sources of information then some or all of this may be at some point rendered inaccurate or invalid.

Q3 2017 SkypeUG Meetings

August 10, 2017 by · Leave a Comment 

The next round of quarterly Skype for Business Users Group meetings has been announced and scheduled starting this month.


Latest News

Please welcome members to our newest group in Spokane, Washington.

Event Details

This quarter’s events will be conducted in our familiar two-session format:

The first session will cover Microsoft Teams with an In-Depth Demonstration (Chat, A/V, & Meetings). Our second session will focus on Hybrid Architectures & Related Migration Strategies.  We’ll also have a preview of Microsoft Ignite.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.

For a full schedule of regional events the Skype for Business Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..

Chicago Event

As usual I will be hosting the Chicago event which will be held in downtown Microsoft office this quarter.  We will continue with the current plan to alternate locations each quarter between the downtown and suburban Microsoft offices.

Food will be ready at 5:30pm so come early if you can to spend time socializing with the group before the presentations begin at 6:00pm.

Date Location Address
Thursday,August 31st         
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago Users Group Microsoft Technology Center
200 East Randolph Drive, Suite 200
Chicago, Illinois, 60601

Polycom UCS 5.6 for VVX Phones

July 31, 2017 by · 52 Comments 

The latest release of the Polycom VVX 5.6 UCS firmware is now available for Lync and Skype for Business (SfB) environments. This release includes some minor enhancements alongside a few major changes in look and behavior.

For additional assistance with updating phones the following articles are provided as references.

  • Perform a Factory Reset – This is an optional, but recommended step when working with individual test devices for validating new firmware in an established deployment.

  • Deploy Software – Once testing is complete then this firmware can be added to the Lync or Skype for Business Device Update service for on-premises deployments.

  • Online Updates – For Skype for Business Online customers this update automatically be published once it has passed qualification.  Use this article to control this behavior if automatic updates are not desired.

Upgrading a Phone

This section will cover the basic steps to upgrade a single phone using the Polycom-hosted public server to directly download and apply the firmware to the phone.  In order to perform this process the phone’s internal web server must be enabled.  Depending on the selected Base Profile the web server may need to be manually enabled.

Set Base Profile

As explained in many earlier VVX articles the phone must be set to the proper Base Profile when registering to various SIP platforms.  Depending on the original purchasing SKU and/or current status of the phone it will be set to one of two options by default: Generic or Lync.  (Note that “Lync” base profile was renamed to “Skype” in version 5.5.1, but they function the same.)  When a VVX phone is set to Generic then the Web Configuration Utility will be enabled by default, but as this phone is or will be used with Lync/SfB environments it is best to set or confirm this parameter before doing anything else.

  • From any screen simply depress and hold the the following Multiple Key Combo (MKC) of: 1, 4, 9.

  • When prompted after 3 seconds enter the Admin password. (The default is “456”).

  • If the current value is set to Generic then select Skype and the phone will immediately reboot.  If Skype was already selected then simply hit the Home button to exit the menu.


Enable Web Configuration Utility

Back when UCS 5.3 was released a new default behavior was defined for the Lync base profile which automatically disabled the embedded web server.  This can be re-enabled on the VVX phone for testing or administration purposes if so desired.  To perform many of the steps in this article it must be enabled now.

  • Press the Home key and navigate to the following menu: Settings > Advanced > Administration Settings > Web Server Configuration.

  • If not already configured then the Web Server parameter to Enabled and Web Config Mode to HTTP/HTTPS.  (If a secure connection is required then set this to HTTPS Only).


  • Select the back arrow and choose Save Config to apply the changes and reboot the phone.

  • After the phone has rebooted press and hold (for 3 seconds) the following keys: 1, 4, 7.  This handy MKC brings up the Phone Details menu which can be used to quickly find useful information like the device’s assigned IP address or current firmware version.


  • Using a web browser connect to the IP address of the phone. (e.g.

  • Enter the Admin password (default is “456”) and verify that the Home page successfully loads.


Update Firmware

This phone must have access to the Internet in order to connect to the public hosted Polycom update server and perform the update described in this section.

  • Using the Web Configuration Utility browse to the Utilities > Software Upgrade menu and make sure that Polycom Hosted Server is selected as the Server Type.

  • Click Check for Updates which should be followed by a response of “Successfully fetched available software from the Polycom Hosted server.”

  • Select the desired firmware version number (e.g. and then click Install.  The currently installed version will be displayed in blue with older versions in red and newer versions in green.


  • Confirm the action to reboot the phone and trigger the update.  Once the phone completes the update process it will return to whatever registration state it was in before the update. 

The following sections outline any Skype for Business related enhancements from previous firmware versions which may change the phone’s behavior or user experience.

Updated User Interface

While the UCS interface was just updated on some phone models in the previous 5.5.1 release there has been additional user interface customization within the Skype Base Profile to fall even more in-line with overall Skype for Business clients and devices interfaces.  Where the previous version added a more Skype-like look to the VVX 5xx/6xx models this newer version goes one step further by adopting a darker theme used on the latest native Skype for Business devices like Skype Room System and the Polycom Trio,



Unlike the previous release this updated interface is now also applicable to the VVX 4xx models.

image    image

Dial Plan Normalization

The topic of normalizing dial strings in UCS has historically been a complicated subject.  Way back in the original 4.x software release attempts were made to perform client-side normalization by downloading and applying the various normalization patterns and rules provided by the registered Lync Server.  This proved to be problematic due to the different ways that Lync and UCS handled Regular Expression (RegEx) strings.  On one side UCS did not at that time properly handle all characters allowed in standard RegEx patterns, and on the other hand several Lync deployments were found using non-standard patterns. 

The approach several years ago was to change the default behavior of the phone to leverage server-side normalization by simply sending an unnormalized dial string directly to the server as-dialed.  This resolved most issues but was a trade-off as it limited some other capabilities.  The ability to control the normalization behavior has long been available by modifying the value of the UCS configuration parameter reg.1.applyServerDigitMapLocally which has held different default values over time.

As of UCS 5.6 extended support for RegEx characters and patterns has been introduced and, when in Skype profile, this parameter has once again been enabled by default to reflect the updated recommendation of using client-side normalization with VVX phones.  If an existing deployment is already controlling this parameter via any of the different provisioning server models then obviously the phone behavior will not change.  But if the parameter has been left at the default setting and has not been modified through any other methods then the act of upgrading a phone running 5.5 or earlier firmware will alter its normalization behavior.  The phone will no longer send dial strings to the server and will instead perform client-side normalization.  Due to this change it is highly recommended to test 5.6 out on a single phone first to validate that all Lync or Skype for Business dial plans are properly handled by.

In addition to the primary parameter discussed above some additional parameters have also been adjusted with default values.  The following table lists all of these which are applicable to dial plan normalization behavior.

Parameter Name UCS 5.5.x UCS 5.6
reg.1.applyServerDigitMapLocally 0 1
dialplan.1.conflictMatchHandling 1 1
dialplan.1.impossibleMatchHandling 3 3
dialplan.1.applyToDirectoryDial 0 1
dialplan.1.applyToCallListDial 1 0
dialplan.1.applyToRemoteDialing 0 1
dialplan.1.applyToPstnDialing 0 1
dialplan.1.applyToForward 0 1

New Configuration Parameters

In addition to the changes above there are a few new parameters available for controlling new capabilities.  The dialplan.TranslationInAutoComp parameter allows for auto-completion results to be shown as dialing options when entering a string of digits. This functions when client-side normalization is enabled as the phone will be able to perform these normalization checks in real-time.

The dialplan.NUM_REPLACE_1.Additionale911dialstrings parameter listed below adds support to VVX phones for handling multiple Emergency Services numbers as is supported by Skype for Business.  The configuration of additional numbers is performed server-side using the New-CsEmergencyNumber PowerShell cmdlet as covered on this TechNet page and then the phones will pull the additional configuration information down in-band during registration and store it in this new parameter.

If client-side normalization is enabled as discussed above then the phone can now provide on-demand dialing options in real-time as digits are being entered into the phone.  To customize the timeout before call is automatically placed the dialplan.1.lyncDigitmap.timeOut parameter can be altered.

Parameter Name Values Description
dialplan.TranslationInAutoComp 1
Controls whether to display translated string in Auto-Comp list. If enabled the translated number will be shown in the autocomplete list.
dialplan.NUM_REPLACE_1.Additionale911dialstrings Used to configure additional emergency dial strings.
dialplan.1.lyncDigitmap.timeOut 4
Controls timeout value for static and off hook dialing scenarios.
This parameter replaces the obsolete parameter dialplan.userDial.timeOut
feature.webSignIn.enabled 1
Allows an administrator to disable and hide the Web Sign-in option on the phone.*
feature.webSecurityBanner.enabled 0

Allows the additional of a security message banner to be displayed when accessing the phone’s web management user interface.*
Used to store the text displayed as a security banner enabled in the parameter listed in the row above. Supports up to 2000 characters.*
up.configureDeviceLockAuthList EmergencyNumberAtTop
Controls the ordering of any configured Authorized and Emergency numbers displayed while the phone is locked.*
up.hideSystemIpAddress Nowhere
Can be used to hide the phone’s IP address from the various locations that it is displayed.*

*Additional important parameters added in the previous 5.5.2 release have been included in this list for posterity.

Device Lock

When device locking is enabled the phones are now simpler to unlock than in previous versions.  The digits can immediately be typed into the phone and it will be read as the unlock code, not a phone number to dial as before.  To place a call while locked (if allowed) the phone icon can be selected, the speakerphone button pressed, or the handset lifted.

Device locking behavior has also been improved when using Better Together over Ethernet (BToE) mode with the latest BToE 3.6 software release. The device will now only lock/unlock when the paired workstation is locked/unlocked, and not if the pairing status changes between active/inactive.

Support for user photos has also been added to the lock screen in UCS alongside displaying the signed-in user’s name.  The currently registered user’s photo will be shown on the lock screen of VVX 5xx/6xx models, as shown below, but only if the photo is stored in Exchange or made available via HTTP.  Photos stored only in Active Directory are not accessible by UCS.


Another new UCS feature (one which was not available on the older Lync Phone Edition devices) is the ability to unlock the phone directly with the signed-in user’s password.  In the event that a user forgets the device unlock PIN the phone can still be unlocked with the account’s password by tapping the "?" padlock icon above to access the screen shown below.


Unlocking the phone with this method will immediately prompt the user to create a new device PIN.

One Touch Meeting Join

Borrowing functionality already brought to the Polycom Trio the VVX can now more easily join Lync or Skype for Business meeting available on the phone’s calendar which were sent by third parties.  In the past receiving an Outlook invitation for an online meeting from a user outside of the same Microsoft Exchange environment may not trigger the creation of a Join button, or may create the Join button but selecting it only dials the PSTN Conferencing dial-in number.  Typically only meetings sent by users in the same organization would allow this one touch join capability, but if filtering of Transport Neutral Encapsulation Format (TNEF) was manually disabled between email organizations then the Join button would function as desired.

This one-off approach of enabling some level of customized SMTP formatting support between organizations is not scalable so several Skype for Business clients and devices have been shedding this requirement for the past year.  At this point most of all the clients and devices available are now able to properly parse the body of the invitation to find the meeting information and no longer rely on header information that may have been stripped from the email during transit.

The example shown below is a Skype for Business meeting sent from an on-premises user in organization A to a Skype for Business Online user in organization B.  The Join button also still appears in the meeting reminder alert.



Call Delegation

A few call transfer improvements have been made to the workflow for delegate call handling in Boss/Admin scenarios.

  • The Resume soft key now is only displayed when a transferred call is returned to the delegate’s phone.

  • Putting the handset back into the cradle will no longer end the transferred call as it will be placed on hold.

  • If a transferred call is returned to a delegate then the delegate’s phone will play an alert tone.

  • If a transferred call is not answered the call is automatically resumed on the delegate’s phone.

Busy Options

In the Skype for Business Server July 2016 Cumulative Update Microsoft added additional calling features for handling inbound calls to clients which are already in a call.  These Busy Options are now supported by VVX which includes Busy on Busy and Voicemail on Busy.  As the two names indicate the configuration applied to the phone’s registered user account will trigger either a busy signal or an immediate forward to voice mail on incoming calls when the callee is already in a call or conference.

Siren7 Codec Support

As UCS does not support the RTAudio (RTA) codec then one scenario where there has historically been a bit of a gap is when a VVX phone joins a Lync or Skype for Business conference running on the AVMCU.  The standard Microsoft soft clients will typically leverage RTA as a means to provide wideband audio in a low-bandwidth capable codec, but the VVX phones will be default negotiate G.722.  While the audio quality of G.722 is excellent in these scenarios the average bandwidth utilization can be higher when compared with RTA.  (Note that the VVX 201 model does not support Siren7).

By adding support for SIREN7 in UCS the phone’s now have another option available that Lync and Skype AVMCUs also support.  The codec is not enabled by default and must be added to the "In Use" codec priority list on the phone.  While this can be enabled using the standard provisioning parameters it is also very easy to enable using the phone’s embedded web browser.

  • Using the UCS web management interface browse to Settings > Codec Priorities

  • Under the Audio Codec Priority section In the Unused field highlight the Siren7 (16 kbps) entry and then add it to the In Use field on the right.  Move the new codec to the desired order for the intended results.  In this example the codec was moved to the top to perform testing but should not necessarily be placed that high in the order.


  • To test the change select Meet Now from the home screen on the VVX to start a new online meeting and establish an audio session with the Skype for Business server.

  • Press the Home key and then navigate to Settings > Status > Diagnostics > Media Statistics to display the following window and verify the codec currently in use.


Set Logging Levels

This feature was actually added back in the UCS 5.5.2 release.  It allows the phone to read the in-band logging level configuration defined in a Lync Server or Skype for Business Server on-premises deployment controlled by the Set-CsUCPhoneConfiguration cmdlet.  The cmdlet LoggingLevel parameter can be set to Off, Low, Medium, or High values.

The following table lists the individual component logging values in the phone that are configured in conjunction with each of the four possible values in the server parameter.

Feature Off Low Medium High
ICE 4 4 0 0
ICE 4 4 0 0
TICKT 4 4 0 0
SIP 4 4 2 0
EC 4 4 2 2
APP1 4 4 2 2
SO 4 4 2 2
AFE 5 5 2 2
PPS 4 4 1 1
PGUI 4 4 2 2
BTOE 4 4 2 2
ServiceAuth 2 2 2 2
ServiceDevicePair 4 4 2 2
ServiceProxy 4 2 2 2
ServiceWad 2 2 2 2

Discovering the Skype for Business Registrar

May 30, 2017 by · 6 Comments 

This brief article walks through some common steps which can be used to locate the Fully Qualified Domain Name (FQDN) of a Lync or Skype for Business registrar from either on-premises or online environments.  (This content was originally to be part of another article but was split into a separate post for easier reference.)

This can be used as a reference for other articles on this site as a common step performed when troubleshooting device registrations to Skype for Business is to manually configure the endpoint.  To do this one must know the proper FQDN of the desired Microsoft SIP registrar.  Not all of the natively interoperable voice and video solutions supported with Lync and Skype for Business today leverage the newer Lyncdiscover web service model and may still need to automatically discover the SIP registrar directly.  The configuration that supports these is still used by most clients but was the only available method supported in legacy clients like Lync 2010 and devices like Lync Phone Edition.

On-Premises and Hybrid Deployments

This section focuses on Lync Server and Skype for Business Server deployments where on-premises Front End pools and Edge Server pools are deployed.  Some of these environments may also be configured in the Hybrid model with a split-domain configuration connected to an Office 365 tenant.  Either way there are multiple potential registrars that client would be directed to connect to depending on the client’s network location at the time, as well as VPN connectivity is applicable.

DNS Resolution

The Lync/SfB registrar pool FQDN will be needed for the desired user account .  The following steps can be used to validate if the appropriate DNS records exists for the SIP domain to support legacy discovery processes.

  • From a internal workstation located inside the corporate network use the Command Prompt or PowerShell to enter the following nslookup commands to search for any Service, Host, or Alias records specifically pointing to an internal registrar (e.g. Front End Pool).

PS C:\> nslookup -q=srv

Non-authoritative answer:      SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   =   internet address =   internet address =   internet address =

PS C:\> nslookup

Non-authoritative answer:

PS C:\> nslookup

Non-authoritative answer:

  • From an external workstation located outside the internal network use these nslookup commands to search for any Service, Host, or Alias records specifically pointing to an external registrar (e.g. Edge Pool).

PS C:\> nslookup -q=srv

Non-authoritative answer: SRV service location:
          priority       = 10
          weight         = 100
          port           = 443
          svr hostname   =

PS C:\> nslookup

Non-authoritative answer:

PS C:\> nslookup

Non-authoritative answer:

Note that not all of these records will typically return results.  The sipinternal and sipexternal records are rarely used, but the basic sip record is commonly configured internally for legacy devices as is often added during the server certificate creation.  It is also very commonly used as the external Edge FQDN for external clients and federation.

If none of the lookups performed above are successful then the environment being used has not been configured to support any of the legacy autodiscovery lookup records, which is not entirely uncommon these days.  At this point a specific registrar name can be found using the desktop client instead.

Client Information

  • Sign in to a Windows Lync or Skype for Business client.  After the client has completed the sign in process hold down the the CTRL key and right-click the client icon in the System Tray.

  • Select the now-visible Configuration Information menu item.


  • Look for the Skype for Business Server entry and take note of the FQDN displayed.

The following example shows an internally connected client as denoted by an Inside User Status value of TRUE.  The connected Skype for Business Server is displayed as the internal Front End pool FQDN (e.g.


Be aware that in some instances this may instead display the user’s specific home server FQDN instead of the entire pool FQDN (which is shown in the example above) when registered to an internal Front End pool.  In multiple server pools the use of an individual server FQDN to manually register a device or client would not allow for any High Availability redundancy, so make sure to keep in mind that while this approach is fine for testing it is best to retrieve the pool FQDN from the IT administrator if it cannot easily be located programmatically.  (In deployments leveraging Standard Edition Front End Servers then this is moot.)

This second example is from an externally connected client as denoted by an Inside User Status value of FALSE.  The connected Skype for Business Server is displayed as the external Edge pool FQDN (e.g.


When registered to an Edge pool the actual home Front End server FQDN is not shown and only the external Edge FQDN is displayed.  Thus for external registration this value is perfectly fine for production use as it does not circumvent any High Availability capabilities which may be provided by the external pool.

Skype for Business Online

This section applies only to pure Skype for Business Online tenants where there are no on-premises Skype for Business servers deployed.

For all users hosted on Skype for Business Online there is a single defined FQDN

  • From any workstation use these nslookup commands to search for the Service and Host/Alias records which point directly to the Skype for Business Online pools in Office 365.

PS C:\> nslookup -q=srv

Non-authoritative answer: SRV service location:
          priority       = 100
          weight         = 1 
          port           = 443
          svr hostname   =

PS C:\> nslookup

Non-authoritative answer:

This process shows the common FQDN used for all registration attempts to Skype for Business Online.  This single FQDN should be used be all devices or client connecting to a Skype for Business Online account from any location.  Leveraging this FQDN insures the best connectivity.

Alternatively the Skype for Business Configuration Information can be reviewed using the process shown in the previous section. Because the FQDN is simply a geographically balanced DNS record the actual server name shown will be that of whichever registrar pool the user’s account is homed on.


Polycom Group Series with Skype for Business Server

May 10, 2017 by · 105 Comments 

Earlier this year the Polycom RealPresence Group Series video conferencing platform received official qualification for use with on-premises Lync Server 2013 and Skype for Business Server 2015 deployments.  Note that this does not yet include Skype for Business Online which is a separate qualification process that is nearing completion.  When support for direct registration to Skype for Business Online accounts in Office 365 is achieved then look for a newer article covering that simple configuration.


For anyone familiar with these devices or the previous generation HDX platform then much of the configuration outlined in this article may look familiar.  These devices are commonly referred to by a host of various names, like “Standards-Based Video Systems” or “Endpoints”, or more simply a VTC (VideoTeleConfering systems).  Another common nickname is “codec” in reference to one of the unit’s primary functions as a media encoder/decoder.

Whatever they are called though the general idea is that the systems only work within other standards-based SIP and H.323 video conferencing platforms.  While this is true of most legacy systems from manufacturers like Cisco/Tandberg, LifeSize, and even older Polycom units to name the most common of them, the more recent generations of Polycom VTCs also have supported direct, native registration to Microsoft’s SIP-based communications platforms like Office Communications Server, Lync Server, and most recently Skype for Business Server.  Specifically the older HDX models were originally supported with OCS 2007 all the way up to Lync Server 2013.  The newer Group Series platform was supported originally on Lync Server 2010 and now with Lync Server 2013 and Skype for Business Server 2015.

It is important to understand that for Skype for Business Server environments the Group Series can be involved in one of two ways.  Either natively, as this article discusses, or via an interoperability solution like RealConnect which was outlined in this article from a few years ago.  Also keep an eye out for an upcoming article on the new interoperability service provided in Skype for Business Online known as RealConnect for Office 365, or more generically as Cloud Video Interop (CVI).

When the Group Series system is leveraging the native support model it will register as a Skype for Business account and do most of the things one would expect a registered client to do: support presence states, peer calling, join Skype Meetings directly to the AVMCU, etc.  But when coming through an interoperability solution the VTC is only able to call into Skype Meetings, there is no presence or peer calling support as the VTCs are not able to actually register to the Skype for Business environment.

Prerequisite Configuration

One of the most important concepts to understand when dealing with solutions like the Group Series or VVX phones which support multiple different platforms is that entering information as basic as user credentials may not always be entirely straightforward.  As explained in this previous article Windows user credentials can be used in different formats which do not always use the same names, depending on how the account was originally setup.  As more organizations move to Office 365 then the opportunities are reduced for scenarios where SMTP and SIP addresses do not match a User Principal Name (UPN).  But knowing and not just guessing the proper format to enter a set of user credentials is paramount.  This is the single most common problem seen in the field with failures to successfully register anything to Lync or Skype for Business.

When dealing with on-premises Lync and Skype for Business deployments typically both the legacy NetBIOS format as well as the newer UPN format can be used.  That being said it has long been a recommended practice to use the UPN format when possible as moving away from older methods help prepare for scenarios in which these methods no longer are applicable, as in dealing with a standard Office 365 tenancy.  So, while both formats may work in a given environment the guidance seen throughout this (and all recent articles on this blog) focuses on using the UPN format throughout all examples.

The Group Series firmware contains an embedded web server which can be used to remotely administer the device, also similar to VVX and Trio phones.  Most configuration steps shown throughout this article can be accessed using the on-screen menu system and supplied remote control, or by using the Administration menu on a RealPresence Touch (RPT) control panel.  For continuity all configuration steps outlined in this article use the web interface.

One of the unique aspects of the Group Series platform (which was carried over from the HDX) is that the configuration for SIP registration and calendaring registration is separate.  Comparatively every other native Lync or Skype for Business client or endpoint uses the same single set of credentials to access both Lync/SfB and Exchange services.

Firmware Update

Qualification and official support for on-premises Lync Server 2013 and Skype for Business Server 2015 requires the use of at least the 6.1.0 version of the RealPresence Group Series software.  The most recent firmware can be downloaded directly from the Polycom Support site from any of the available models listed here.  The firmware package is identical between the 300, 310, 500, and 700 models.  Note that the RealPresence Medialign packages are powered by a standard Group Series 500 and thus uses the same firmware.  The RealPresence Centro product, although also powered by Group Series technology, uses a unique firmware version and thus is not officially qualified with SfB.

Updating the device firmware can easily be performed from either the web interface or by using a USB flash drive.  The latest Administrator Guide can be referenced for detailed steps on each of the available formats.  Also be aware that when upgrading to any major release a new license key will need to be generated which is provided as part of the product’s purchased maintenance agreement.  What denotes a ‘major’ upgrade is any version in which either the first or second digit in the version number has been incremented.  So while moving from version 6.0.0 to 6.0.1 is a minor upgrade and does not require a new license key upgrading from 6.0.1 to 6.1.0 is a major upgrade and will require an upgrade license key, just as would an upgrade from 5.1.4 to 6.0.0.

  • To perform a system firmware upgrade over the Internet using the hosted Polycom server simply connect to the Group Series IP address (e.g. from a web browser via HTTPS on any computer with local network access to it.


  • Navigate to the Admin Settings > General Settings > Software Updates menu. Alternatively simply type “update” in the Search bar above the menu to quickly jump to the Software Updates menu.


  • Under the Software Server section click Check for Software Updates.


  • If a newer software version is available then the following screen will appear. 


Compare the Current Software Version to the New Software Version to determine if an upgrade license key is required.  As this example is going from 6.1.0 to 6.1.1 then a key is not required and the Group Series will not prompt for one to be entered.

  • Click Start Update to begin the upgrade process.

The browser window can be left open during the upgrade to keep track of the initial progress.  The Group Series will reboot itself several time and the entire upgrade process will take about 45 minutes to complete.  Progress throughout can also be seen on the codec’s main monitor as shown in the image below.


Once the upgrade has finished and the codec has returned to the main home screen the following configuration steps can be performed.

Options Key

Various additional value added capabilities of the Group Series platform are unlocked in the software by the use of special Options Keys.  These keys can be provided by the Polycom reseller when the associated add-on license has been purchased.  All of the native Microsoft capabilities of a Group Series codec are included in the Skype for Business Interoperability License.  This license was originally referred to as the “RTV Options Key” and then later the “Lync Interoperability License”.  Even though it is now referred to as “Skype for Business” it is the same options key and used for registration to both Lync 2013 and Skype for Business 2015 server platforms.

Technically this license is not required in order to perform a successful registration to a Lync or Skype for Business server.  Yet without the Options Key installed usage will be limited to peer to peer audio calls only, based on the few industry standard audio codecs that the Group Series has in common with various Lync and SfB clients.  The rest of the native capabilities hinge on support for multiple Microsoft protocols and codecs like X-H264UC, RTV, CCCP, RDP, and so on.  Without the Options Key applied no video calls or content sharing sessions can be established, and Skype for Business meetings cannot be joined. So in essence the Options Key is required to get any meaningful usage out of the system with Lync or Skype for Business.

But why allow the system to register without the options key enabled in the first place, yet limiting the functionality so much?  This is a common question and to understand the reasoning behind the behavior a brief history lesson is in order.  This options key was originally introduced in the Polycom HDX platform back in 2011 and was simply called the Real-Time Video (RTV) options key. And that was all that it provided at the time: the ability to support RTV video streams with other Office Communicator or Lync 2010 clients.  Without that license then peer-to-peer video calls with those older Microsoft Windows clients still worked as they both supported the standard H.263 video codec, limited to CIF resolution.  So at that point in time the RTV options key was truly ‘optional’ as it was simply a value-add, providing for an improved video experience by adding support for additional resolutions including up to 720 high definition.

Then Lync 2013 came along and changed everything by dropping support for the legacy H.263 video codec in the Windows clients, leaving RTV support, and adding the new X-H264UC implementation of SVC video.  This meant that an HDX could not negotiate a video session with a Lync 2013 client, unless it had the RTV options key installed as otherwise there would be no common video codecs between the two endpoints.  This change made the options key pretty much mandatory and no longer an optional purchase as deployments upgraded to Lync 2013.

Eventually additional capabilities were added to the platform by way of including more protocols and codecs from the Microsoft platform.  Support for the Centralized Conference Control Protocol (CCCP) was added to allow the HDX to allow it directly join Lync Meetings hosted on the AVMCU.  The support for CCCP was embedded into the RTV options key, but the key was not yet renamed.  Then the HDX platform was replaced by the newer Group Series platform which carried over the same options key behavior.  Soon additional features were added to this options key for the Group Series only, like support for the X-H264UC video codec.  The options key was then aptly renamed to the more descriptive Lync Interoperability License as it was now handling a lot more than just support for the legacy RTV codec.  Even more recently this was further updated to Skype for Business Interoperability License on the Group Series, but regardless of the name used the Group Series still supports both Lync 2013 and Skype for Business 2015 servers and clients.

Given the changes over time to incorporate the various, now required, protocols and codecs then it is clear why this options key is no longer optional.  The ability to register to a Lync or Skype for Business server has not been changed so that it cannot register without the license though.  So when performing tests if only a peer call can be established with a Lync/SfB client and only the audio works then this is a red flag that the options key is most likely missing from the system.  Understand that a call between two Group Series registered to Lync/SfB will work across all modalities (audio, video, content sharing) even if one or both do not include the options key because they will negotiate those streams over more preferred standards-based codecs (like H.264-High Profile for video or H.239 for content sharing).

To enable all supported features retrieve the Options Key from the purchased licensing paperwork and apply it to the codec.

  • Using the web management interface navigate to the Admin Settings > General Settings > Options menu, or simply search for “options” and then select the Options result. 

  • Enter the appropriate options key and then click Save to apply.  The Skype for Business Interoperability License should then show a checkmark icon next to it to indicate that it is successfully installed and the features are enabled.


Note that the example codec shown used in this article currently has a few additional licenses enabled, some of which may not be applicable to Skype for Business but can still be used with H.323 calls.

  • The Multipoint Video Conferencing option is used to enable an on-board software MCU which can only be used on standard SIP or H.323 calls.  When registered to Lync or SfB any multiparty calling scenarios are always escalated to and handled by the Lync/SfB server and this onboard MCU capability is automatically disabled during those calls anyway.

  • The Telepresence Interoperability Protocol (TIP) option is only applicable to standards-based calls involved with a certain type of Cisco endpoint family. 

  • The Advanced Video 1080p license is applicable to any platform, including Lync/SfB, and is required if attempting to send or receive RTV or SVC video streams above 720p resolution.

SIP Registration

Another uncommon facet of the Group Series codec is that it can support two separate concurrent signaling platform registrations; one via SIP and the other via H.323.  Only the SIP registration capability is applicable for use with Lync and Skype for Business .  If the system is simultaneously registered to some H.323 platform this does not adversely affect its capabilities as a native Lync/SfB endpoint but some additional attention should be paid to things like which registration ‘arm’ is used by default when manually placing outbound calls.  It would not be successful to attempt calling another standards-based system by sending a SIP dial string to a Lync or Skype for Business registrar, for example.

The Lync or Skype for Business account being used to register the Group Series can be either a standard user account or a meeting room account, as explained in detail by this recent blog article.

Automatic Discovery

To configure the Group Series to register with a Lync or Skype for Business server it is recommended to use the automatic settings by default which are outlined below.  In the event that registration is not successful then manually configuring additional settings can help troubleshoot any automatic discovery issues which may be preventing the registration.  Currently the Group Series firmware performs the legacy discovery process that leverages DNS SRV and A records pointing directly to the registrar which was commonly used by Lync 2010 and older clients (like Lync Phone Edition for example).  Support for the newer Lyncdiscover process will be introduced in a future update.

  • Using the web management interface navigate to the Admin Settings > Network > IP Network menu, or simply search for “sip” and then select the SIP result. 

  • Expand the SIP section click Enable SIP if it is not already enabled.

  • Leave SIP Server Configuration set to the default value of Auto.

  • Leave BFCP Transport Preference set to the default of Prefer UDP.

  • In the Sign-In Address field enter the SIP URI of the desired Lync or Skype for Business user account (e.g. 

  • In the User Name field enter the User Principal Name (UPN) of the same account (e.g.  In most deployments the user account’s SIP URI and UPN are identical, but is not always be the case.  This field also supports the legacy NetBIOS format of “DOMAIN\username” but it is a best practice to utilize the modern UPN format.

  • Click the Password box to expand the Enter Password and Confirm Password fields.  Enter the user account’s password in each field.

  • Leave the Proxy Server field blank as auto discovery process will be used to locate the proper registrar.

  • Select Microsoft from the pull-down menu in the Registrar Server Type menu.

  • Finally click Save to attempt to sign-in.

The Registration Status will always immediately report “Registration Failed” as the sign-in process is still happening, but within 30 seconds or less the registration should complete and change to  “Registered”.

Automatic Configuration Example


Manual Configuration

If initial registration attempts fails then manually pointing the Group Series directly to the desired registrar is one of the first troubleshooting steps which can help identify potential automatic discovery issues which may be causing the problem.

The Lync/SfB registrar pool FQDN will be needed for the desired user account .  Follow the steps outlined in this article to identify the appropriate SIP registrar FQDN to use with the Group Series.  Make sure to note if the targeted registrar is an internal Front End server or an external Edge Server as the Group Series configuration will differ slightly.  On an internal network registering to a Lync or Skype for Business Front End pool the destination listening port will be TCP (TLS) 5061, where as an externally placed system attempting registration to an Edge pool will need to be configured to connect over TCP (TLS) 443.

The behavior of the Group series when specifying the registrar manually is to attempt connections by default to the well know service ports for SIP communications.  If either by automatic discovery or manual configuration when a TCP connection is attempted it will use port 5060, or for TLS communications port 5061.  In the event that a different port needs to be contacted then the port number needs to be entered after the registrar FQDN using a colon separator, as in

To manually configure the Group Series to register to a Lync or Skype for Business server then use the same steps as attempted above in the Automatic Discovery section, but perform the following alterations:

  • Change the SIP Server Configuration to Specify.

  • Change the Transport Protocol to TLS.  (This is not mandatory as TLS will still eventually be used when set to Auto but setting it specifically to TLS simply removes one more discovery step that is performed during registration.)

  • In the Registrar Server field enter the FQDN of the Lync or Skype for Business Server or Pool.  If this is an internal Front End Server/Pool then enter only the FQDN (e.g. but if this is an Edge Server or Pool then enter the FQDN as well as the destination listening port (e.g.

  • The Proxy Server field should be left blank.  Registration can still work if the exact same value as the Registrar Server field is entered but this is redundant and normally should not be populated.  Unlike some standard SIP platforms the Microsoft SIP platform contains the proxy and registrar services in the same server roles.  (This field is not used for pointing to an outbound web proxy server, that is configured in a different section.)

  • Set the Registrar Server Type to Microsoft.
  • Click Save to start the registration process.

As before the Registration Status will immediately be reported as “Registration Failed” as the sign-in process starts but within 30 seconds or less the registration should hopefully change to  “Registered”.

Manual Configuration Example


If registration is now successful then it can be assumed that the Group Series was either unable to find the desired legacy DNS lookup records or was possibly not able to handle potential redirection scenarios in a hybrid deployment configuration.  At this point it is suggested to reach out to product support channels for further assistance.

Directory Servers

Now that the SIP registration process has been successful using one of the approaches above the next step is to insure that the Directory Server integration is complete.  Just like with SIP the Microsoft platform differs from traditional SIP platforms in terms of address books and directories.  The Group Series needs to manually be configured to used the Microsoft Address Book Service, although other LDAP or Global Directory Services (GDS) could be utilized in place of the Microsoft address book if desired.

    • Using the web management interface navigate to the Admin Settings > Servers > Directory Servers menu, or simply search for “directory” and then select the Directory Servers result. 

    • Change the Server Type to Microsoft.

    • In the Domain Name field enter the SIP domain for the the currently registered user’s environment (e.g.

    • Click Save to connect to the Address Book service.

The Registration Status will  initially continue to be displayed as “Registration Failed” but within 30 seconds or less the status should update to  “Registered”.


Once configured to use the Microsoft directory service option then the Group Series will adhere to the in-band AddressBookAvailability configuration as controlled by the Set-CsClientPolicy cmdlet in Lync and Skype for Business.  When the parameter is set to either FileDownloadOnly or WebSearchOnly then the Group Series will utilize only the option allowed by the defined policy.

If the default WebSearchAndFileDownload value is configured then the Group Series will use the Address Book file download model by retrieving the address book files from the server via HTTPS.  These are the same files that the standard Lync and Skype for Business clients download to respond to searches immediately by using a cached copy (galcontacts.db) of the entire Skype for Business Address Book.

Yet in environments with a large amount of data stored in the address book files these can reach a size too large (roughly more than 2MB)or contain too many entries (approximately more than 20,000) for the Group Series to successfully download, expand, and store in memory.  In the events where this happens the Group Series will then automatically fall back to leveraging the Address Book Web Query (ABWQ) service and then all directory searches performed on the Group Series will immediately be forwarded to the ABWQ service for the server to perform and return any results.

Calendar Registration

The final registration step is to configure the Calendaring Service to connect to the registered account’s Exchange mailbox.  Any version of Exchange which includes Exchange Web Services is supported with the Group Series, which includes all versions of Exchange Server 2007 through 2016 as well as Exchange Online.  Note that while official support for Skype for Business Online is not yet available the Group Series has supported connecting to Exchange Online mailboxes for several releases now.

  • Using the web management interface navigate to the Admin Settings > Servers > Calendaring Service menu, or simply search for “calendar” and then select the Calendaring Service result. 

  • Check Enable Calendaring Service if it is not already enabled.

  • In the Email field enter the primary SMTP address of the desired mailbox (e.g.  This is typically the same as the currently registered Skype for Business user account, as shown in this example, but it can be a completely different user or resource mailbox if desired.

  • Leave the Domain field blank.

  • In the User Name field enter the User Principal Name (e.g. of the account which has at least reviewer permissions to the mailbox supplied in the Email field above.  Again this is typically the same account as used for SIP registration but this could be a different account in the event that a delegated-rights ‘service’ account is to be used to access the mailbox instead of the mailbox’s primary AD user account itself.

  • In the Password field enter the password associated with the provided user account in the previous field.

  • Verify that the Auto Discover Using parameter is set to E-mail Address and then click the Auto Discover button.

At this point the Microsoft Exchange Server field should automatically be populated with the FQDN of the appropriate Exchange Server for the supplied mailbox.  Depending on the location of the mailbox the value will either be an Exchange Server FQDN (if the mailbox is stored on an on-premises Exchange Server) or (if the mailbox is stored in Exchange Online).

  • Leave the Secure Connection Protocol set to Automatic.

  • The remaining fields are optional and can either be left at the default value or customized as desired to control Meeting Reminder and Private Meeting behaviors.

  • Click Save to attempt to register to Exchange and access calendaring information stored in the targeted mailbox.

The Registration Status will  initially continue to de displayed as “Not Connected” but within 30 seconds or less the status should update to  “Registered”.



To validate that the Group Series is successfully working with Skype for Business a number of tests can be attempted to confirm several capabilities in addition to simply checking the System Status for general health.

System Status

  • Using the web management interface navigate to the Diagnostics > System > System Status menu, or simply search for “status” and then select the System Status result.

The three sections to focus on are the Microsoft Server (for the Directory Server), the SIP Registrar Server, and the Calendaring Service.  Verify that all three services are green and do not report any errors.


Peer Calls

To initially validate that the registration was indeed successful a simple test is to check the advertised presence of the registered Group Series and then start a video call with it.

  • Open the Skype for Business client on a workstation and look for the Group Series user by either searching the directory or directly typing in the account’s SIP URI.


  • Start a Video Call to the Group Series to test a peer call scenario and then answer the incoming call on the Group Series.


  • While the call is still established return to the web management interface for the Group series and note the additional call control buttons which are now displayed across the top of the window.


  • Click the Call Statistics button to bring up the following menu displaying some technical details on the current call.


In a peer call a pair of audio channels and video channels are displayed.  Outbound streams are denoted by Tx (Transmit) and inbound streams are labeled as Rx (Receive).

Note that based on the default Skype for Business window size the Group Series is sending (VIDEO TX) 640p video at around 800 Kbps using SVC.  (The Group Series will report the Microsoft-specific implementation of SVC (X-H264UC) generically as SVC-HP.)  Because this Group Series unit includes the 1080p options key and the Skype for Business Windows workstation in the call is a quad-core PC capable of encoding 1080p video then the codec is also receiving (VIDEO RX) a 1080p video stream from the SfB client.

  • Manually resize the Skype for Business client’s video session window to the smallest possible dimensions on the receiving workstation.


  • Refresh the Call Statistics on the Group Series and check the statistics reported for the Video Tx line again and notice that Group Series is now sending lower resolution video to the SfB client at around only 375 Kbps.


  • Now maximize the SfB video window on the workstation as shown below.


  • Refresh the Call Statistics again and note that the codec should no be sending a much higher resolution video stream then either of the previous arrangements. Based on the screen resolution and size of the window on this specific workstation the SfB client is now asking the Group to send a 720p high definition video stream at around 2.5 Mbps.


  • Increase the SfB video window one more time by selecting the Full Screen View option (the little opposing diagonal arrows in the upper right hand corner of the window.  This will increase the video window to the largest possible size.  The inclusion of the Skype logo watermark is an indicator that the full screen view has been enabled.


  • Refresh the Call Statistics again to see that now the SfB workstation has requested the maximum supported 1080p high definition video resolution at around 4 Mbps to be sent by the Group Series.  On less powerful workstations this would be limited to 720p, or if the Group Series is not licensed to support 1080p video streams.


  • From the SfB client select the Share Your Desktop option to add an RDP application sharing session to the existing video call.

  • Refresh the Call Statistics one last time to see the inclusion of the inbound content sharing session (CONTENT RX)


Skype Meetings

This take this one step further the Group Series can join a Skype Meeting hosted on a Lync or Skype for Business Server AVMCU.  If calendaring has not been enabled on this codec then to join a meeting the unit must be invited by another SfB participant currently in a scheduled or Meet Now meeting.

If calendaring has been enabled then using either the remote control, a paired RPT panel, or a supported touch screen select the Join button displayed inside any Skype Meeting invitation which has been sent to the Group Series account’s mailbox.  The Group Series will automatically dial the Conference URI to join the Skype Meeting.  Once in the meeting various features like presenter muting will operate in the same fashion as it does on native Skype clients.

Additional Settings

This section covers various optional configuration settings which may be applicable to the Lync or Skype for Business environment.

Touch Control Panel

If a RealPresence Touch (RPT) control panel is to be used with the Group Series the capability must first be enabled and then the RPT can alternatively be configured to use a Skype for Business-specific user interface instead of the default interface.

  • Using the web management interface navigate to the Admin Settings > General Settings > Pairing  menu, or simply search for “pair” and then select the Pairing result. 

  • Check Enable Polycom Touch Device if it is not already enabled.

  • From the RPT itself select Manually Pair and enter the IP address of the Group Series and initiate the pairing process.

Once pairing is successful the Status should be displayed as “Connected” as shown below.


To enable the alternative Skype for Business user interface perform the following steps.

  • Using the web management interface navigate to the Admin Settings > General Settings > Home Screen Settings menu, or simply search for “skype”, and then select the Skype Mode result. 

  • Select the Enable Skype Mode checkbox.

The screenshot below shows a touch panel that is paired with the Group Series with the Skype Mode UI enabled, as well as the Calendaring Service successfully registered to Exchange and displaying the next five meetings.


Q2 2017 SkypeUG Meetings

April 30, 2017 by · Leave a Comment 

The next round of quarterly Skype for Business Users Group meetings has been announced and scheduled starting this month.


Latest News

Please welcome our newest board member, Josh Blalock.

Event Details

This quarter’s events will be conducted in our familiar two-session format:

The first session will explore the array of various directory synchronization and client authentication models available today within Office 365, including topics like password synchronization and Modern Authentication.

Our second session will focus on the new Microsoft Teams client and then finish up with a recap of the latest Skype for Business announcements from Enterprise Connect 2017 in March.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.


For a full schedule of regional events the Skype for Business Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..

Chicago Event

As usual I will be hosting the Chicago event which will be held in the Downers Grove Microsoft office this quarter.  We will continue with the current plan to alternate locations each quarter between the downtown and suburban Microsoft offices..

Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.

Date Location Address
Tuesday, May 16th
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago Users Group Microsoft Midwest District Office
3025 Highland Pkwy., Suite 300
Downers Grove, IL 6051

Q1 2017 SkypeUG Meetings

February 23, 2017 by · 3 Comments 

The next round of quarterly Skype for Business Users Group meetings has been announced and scheduled starting this month.


Latest News

Please welcome our renewed sponsors for the new year who will be attending various local events.

Event Details

This quarter’s events will be conducted in our familiar two-session format:

Our main presentation will be “An Introduction to Enterprise Voice”.  In this presentation, you will learn about the basic features of Enterprise Voice. What exactly is it and how does it work? You will also learn the differences in features between using Enterprise Voice hosted on premise or via Office 365.

The second session will host an open discussion among the group members.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.


For a full schedule of regional events the Skype for Business Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..

Chicago Event

As usual I will be hosting the Chicago event, but has returned to our original location at the Microsoft Technology Center in downtown Chicago.  The current plan is to alternate locations each quarter between the two Microsoft offices in the region.

Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.

Date Location Address
Thursday, March 16th
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200
Chicago, IL 60601

Skype for Business Online Meeting Room Accounts

January 16, 2017 by · 70 Comments 

One of the most common questions asked when working among the array of available Skype for Business (SfB) audio and video endpoints is regarding what type of Lync or Skype for Business account can or should be used?  The short answer here is that there typically is not only one right answer.  Most of the phones and conferencing devices can work with either available types and generally do not have a single recommended approach due to potential behavioral differences.  This article will go into detail on what those differences are as a way to help the reader understand which approach may be ideal, if not a mixture of both in the same environment.

While the detailed instructions shown later in the article focus on configuring meeting room accounts for Skype for Business Online be aware that most of the concepts explained throughout are also applicable to on-premises Lync and Skype for Business deployments.  The only major difference is how the accounts are initially provisioned as the administrative process differs slightly between on-premises and online environments.  Once configured though the behavior of these accounts are the same whether they are homed on-premises or online.

The steps for configuring these types of accounts for on-premises environments have been covered by multiple sources as well as on this blog so they do not need to be revisited in this article.  Also another earlier article covered setting up remote PowerShell for Lync Online but those steps have been updated for Skype for Business Online as well as expanded upon for additional functionality in this article.

(For repeat visits there is quick reference on creating and configuring Skype for Business Online Meeting Room accounts using PowerShell in the last section of this article.)


The two methodologies mentioned above are simply referring to the use of standard user accounts or special meeting room accounts.  Much of the foundation of these two account types are identical; they are just handled and treated differently within the various products that leverage them.

  • Active Directory – At the primary directory services level there is no difference between the two accounts models.  They both utilize a standard Active Directory (AD) User Account object, meaning any and all of the attributes available to these object types are available to both.  Whether this is a traditional on-premises deployment in Windows Server Active Directory, Azure Active Directory in Office 365, or a Hybrid of both leveraging some directory synchronization services then a standard user account object is always the core component.

  • Exchange Server – Within Exchange Server there exists different mailbox types which for regular users and bookable resource accounts, the latter being meant for things like conference room equipment which can be fixed or mobile.  Exchange treats a User Mailbox differently from a Resource Mailbox in terms of how mail is stored in those mailboxes and even what portions of the messages are retained or stripped.  Mailboxes of either type will allow devices the same level of access to their calendar of scheduled meetings.  A key distinction though is that while resource mailboxes still use the same type of standard user account in AD by default the account cannot actually be used for authentication as no password is defined and the account is disabled.  This is because in the traditional workflow of booking meeting rooms in Outlook which leverage Auto Accept agents no one would typically need to login as the mailbox itself.  This has changed with the addition of the Communications Server platform to this workflow though.  When configuring room mailboxes as part of a Lync or Skype for Business workflow these meeting room mailboxes are enabled specifically to allow authentication using the account’s own credentials.
  • Skype for Business – An AD account is created which allows for user authentication.  That account is then mailbox-enabled within Exchange primarily to provide it an email address and calendar to accept and store meeting invitations.  The final piece in the puzzle now is to SIP-enable the same account to provide all the desired capabilities of adding Lync or Skype for Business to the workflow.  Just like in Exchange there are also two different types of Skype for Business accounts.  A standard User which can be enabled using either the Control Panel or the Management Shell, or a newer Meeting Room which was first introduced in Lync Server 2013 with the advent of the original Lync Room System product.  The meeting room account can only be enabled and managed from the Management Shell and is treated differently by Lync/SfB.  Either approach can be used by devices to sign-in and interact with the SfB services and use the previous calendar access to perform actions like joining the scheduled Skype for Business meetings.

Differences & Guidance

As mentioned above Active Directory itself does not really know, nor care if the core user account object has been used by Exchange to provide either a user or resource mailbox, nor if SfB has enabled a standard SIP user or a meeting room. (Technically it can be aware of the Exchange Server and SfB Server configuration because much of that configuration is stored among various AD attributes defined on the AD account, but that point it moot as AD does not ‘act’ upon that information in anyway that makes a difference as to which approach to chose.)

Because Active Directory does not have different account types for this scenario and the AD account is automatically created during either the Exchange or SfB provisioning step then there is no decision to make here, hence no guidance. Basically, this is irrelevant.

Exchange Server will treat user and resource mailboxes differently.  There are various additional customizations available to control the behavior of a room mailbox by using the Set-CalendarProcessing cmdlet in on-premises and online Exchange environments.  There a several parameters available to adjust the default behavior of actions related to acceptance responses, handling time conflicts, meeting duration, or even the allowed reoccurrence scheduling window to name a few.

Another critical difference between user and resource mailboxes is related to licensing.  Whether dealing with traditional Microsoft licenses or modern Office 365 licenses a standard mailbox user will consume one of these licenses, but a room mailbox will not.  This is easy to see in Office 365 as license-consuming Users are sorted and managed separately from Resources like Rooms and Equipment which are not assigned any licenses.

When it comes down to the vast level of customization offered with a resource mailbox paired with no user-level licenses required then there is virtually no reason to opt to use a regular user mailbox over a resource mailbox.  In short, always use a room mailbox.

Up to this point nothing new has really been covered as that is the way it has been for years across various releases of the Windows Server and Exchange Server products.  As pointed out earlier it was not until Lync Room System created the need for new functionality in Lync Server 2013 that there was really any decision to be made here.

Using a Room Mailbox by itself for just calendaring in Office 365 does not require any licenses be assigned, but when that same room mailbox is also configured .as a Skype for Business Meeting Room then a license must be assigned.  So there is no advantage to using a regular user versus a meeting room as both require SIP registration and authentication to function on a device.  This need for a license also overrides the fact that the Exchange account does not need one as these are one in the same.  For example the configuration shown in the second half of this article for creating a Room Account in Office 365 could be assigned an E1, E3, or E5 license, depending on the device type it was being used for.

There are two important distinctions regarding Meeting Rooms in Skype for Business which relate to the user experience.

Audio Behavior

Meeting Room accounts trigger special behavior when other participants are joining Lync and Skype for Business meetings.  When any device or client registered with a Meeting Room account is already connected to a SfB meeting (ad-hoc or scheduled) then the server is aware of this and triggers a prompt to appear on any other Lync or Skype for Business clients registered as normal user accounts which then join the same conference.

Basically when a Skype for Business or Lync client joins a meeting if there is already at least one participant using a meeting room account in that meeting then the client prompts them to answer the question “Are you in the Skype Room?” before connecting to the meeting.


If the new participant is connecting from their desk or home office they simply answer ‘No’ and are connected to the meeting using the selected default behavior for each modality.  If they happen to actually be in the same physical room as the already connected conferencing system then they would select ‘Yes’ and their client will connect automatically on mute.  This helps to prevent any audio feedback loops which can occur with multiple systems in the same vicinity connected to the same conference.

This scenario can be common when in-room participants want to join the same meeting from their own device to share or control content in ways that may not be available directly via the in-room system controls.  Obviously if using a regular SfB user account on these conference room systems would then prevent the above prompt from appearing and force users to learn to immediately mute their clients as they join meetings in the same room with their own clients.

Lobby Behavior

Meeting Room accounts are treated differently than other user accounts when joining a meeting in another important way.

A scheduled Skype for Business meeting that uses the default lobby option of “Anyone (no restrictions)” will allow all participants to immediately connect to the meeting and bypass the lobby.  Thus devices using either a user or meeting room account will behave the same and connect directly to the meeting like any standard participant.


Where things get interesting though is when the individual meeting options have been customized to control specifically which participants are forced into the lobby.  A scheduled Skype for Business meeting that is configured to allow either “Anyone from my organization” or “People I invite from my company” to bypass the lobby will behave differently between user and meeting room accounts.

The following table shows which account types will bypass the lobby and which will be forced into the lobby across the 4 different lobby settings.

    Lobby Configuration User Account Meeting Room Account
    Only me, the meeting organizer Forced into Lobby Forced into Lobby
    People I invite from my company Allowed Directly into Meeting Forced into Lobby
    Anyone from my organization Allowed Directly into Meeting Forced into Lobby
    Anyone (no restrictions) Allowed Directly into Meeting Allowed Directly into Meeting
    Clients or devices registered with a meeting room account are forced into the lobby when invited directly to the meeting in the two middle options above, even though it is registered as a corporate account from the same organization .  This is because a Skype for Business Meeting Room account is not treated as someone from the organization or someone that was invited directly.  This behavior is by design as one can imagine that anyone could walk into a conference room or up to a common area device and join a meeting on the calendar; employee or guest.  This behavior allows actual authenticated users who are granted presenter rights to ability to curate the lobby list and only allow (or allow and then promptly remove) possibly unknown participants joining from shared endpoints.
    Obviously if this behavior is not desirable for specific devices then choosing to use a regular SfB user configuration instead of a meeting room configuration for that device will address this by always allowing the room to bypass the lobby (unless the meeting was configured for only the meeting organizer to be allowed).  But as covered in the previous section registering a room system with a user account will omit the “Are you in the Skype Room?” prompt from appearing in those meetings.

Given the potential trade-off between audio and lobby behaviors described above there is no single right answer for selecting account types for all devices.  Generally it would be best to use the vendor-preferred approach which is typically a Meeting Room account for most devices. But the desired lobby behavior could be one of the most critical items in making this decision.

Solutions like Skype Room Systems and Group Series video conferencing systems are best suited using the meeting room approach, but work equally as well (when properly configured) with a regular SfB user.

Remember that in either scenario an Exchange room mailbox  is always recommended so the calendaring functionality is no different between them.  Also Audio conferencing phones can leverage Common Area Accounts which do not support Exchange and thus have no calendaring and do not really apply here.  Audio conferencing phones can also leverage Common Area Accounts which do not support Exchange and thus have no calendaring

Given that the overall guidance is to leverage Meeting Room accounts then the remainder of this article will cover exactly how to configure these in Skype for Business Online.

Office 365 PowerShell Setup

As mentioned earlier it is not possible to create Meeting Room accounts using the Skype for Business Online Admin Center so this configuration must be performed using PowerShell cmdlets.  In order to leverage PowerShell for Online services the following workstation configuration must be addressed first.

Software Installation

In order to use Windows PowerShell to connect to Office 365 and manage any of the various online services a few software packages must be installed.  The current Microsoft TechNet documentation covers how to do this but the required steps are also included here in this section.  These steps only need to be performed once per workstation and can be skipped if this prerequisite software is already installed.

Additional steps may be required depending on the Windows and PowerShell version so if there are any problems getting these packages installed and working make sure to reference the official TechNet guide above as well as this previous article which covers this as well as modifying the workstation’s Execution Policy if needed.

If the older Lync Online PowerShell module is installed then it is highly recommended (although not mandatory) to uninstall that package from the workstation and reinstall the newer Skype for Business module covered below.




Now that the required software has been installed the next step is to create a simple PowerShell script to leverage all of these new components in a single command instance.

Management Script

The following basic script file can be used to initiate and authenticate multiple sessions into Office 365 for the purposes of leveraging any Azure Active Directory , Exchange Online, and Skype for Business Online PowerShell cmdlets.  Note that the Skype for Business Online module must be installed on the local workstation first but this is not the case for Exchange Online.  The Exchange session is created manually using the New-PSSession cmdlet and thus does not need any local installation files.

Follow the steps below to create a new script file.  Make sure to pay attention to spacing and dashes in the cmdlets as the formatting on various browsers and display resolutions can change where the longer commands are wrapped to a new line in this article.

  • Using either a simple text editor like Notepad or a more advanced tool like Windows PowerShell ISE create a new script file and select any desired name (e.g. O365.ps1).

  • Enter the following text into this file, replacing the highlighted example user account name with the desired administrator account for the appropriate Office 365 tenant (e.g

$credential = Get-Credential

Import-Module MsOnline

Connect-MsolService -credential $credential

$exchSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $credential -Authentication Basic -AllowRedirection

Import-PSSession $exchSession -DisableNameChecking

Import-Module SkypeOnlineConnector

$sfboSession = New-CsOnlineSession -Credential $credential

Import-PSSession $sfboSession

These 8 individual command lines above perform the following functions:

  1. Prompts the user to enter the password for the defined admin account and securely stores the set of credentials in a newly defined variable.
  2. The previously installed Azure AD module is loaded into the current PowerShell session.
  3. A secure connection is opened to Azure AD in the account’s online tenant.
  4. A new Exchange Online session is defined and stored in another new variable.
  5. The Exchange Online session is imported into the existing PowerShell session.
  6. The previously installed Skype for Business module is loaded into the current PowerShell session.
  7. A new Skype for Business Online session is defined and stored in a third new variable.
  8. The Skype for Business Online session is imported into the existing PowerShell session.

If the workstation still has the older Lync Online module installed and it was decided not to replace it with the Skype for Business module then simply edit command 6 to reference the LyncOnlineConnector instead.

  • Save the file on the local workstation.  Preferably save in a path that PowerShell can see by default (e.g. C:\Windows\) to make it easier to run the script from the command line.

  • Open a new PowerShell session and then run the new script. 


  • Enter the Office 365 tenant administrator account password when prompted.


Once the script completes then the new Exchange and Skype for Business sessions should be displayed as seen below.


To validate a successful connection to all three services run the following basic cmdlets to verify AD, Exchange, and Skype for Business.

Get-MsolUser –UserPrincipalName




Get-CsOnlineUser –Identity


If all steps are successful then the workstation preparation is complete.

Online Meeting Room Configuration

Now that the one-time workstation configuration is complete then the remainder of the steps in this article can be repeatedly used to create individual meeting room accounts at any time.

Exchange Room Mailbox

Using either the same or a new PowerShell session as established in the previous section define a new variable to store the desired User Principal Name for the new meeting room account and then create the new room mailbox.

  • Replace the text in blue below with the desired details for the new meeting room and then issue the following New-Mailbox cmdlet to create a new Room mailbox and enable the account to allow authentication.


New-Mailbox –MicrosoftOnlineServicesID $newUser -Name "Chicago Meeting Room" -Room -RoomMailboxPassword (ConvertTo-SecureString –String "P@ssw0rd1" -AsPlainText -Force) -EnableRoomMailboxAccount $true


It may take several seconds for this cmdlet to return any results and may also even report a replication request failure.  This is normal as it can take up to 15 minutes before the mailbox provisioning is completed in Exchange Online.  There is no need to wait that long though to complete the rest of the Exchange Online configuration steps.

  • Run the following Set-CalendarProcessing cmdlet to modify some of the default behaviors of a standard resource mailbox which are critical to providing the proper in-room join experience

Set-CalendarProcessing -Identity $newUser -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 Skype Meeting will provide a seamless click-to-join experience from the conference room."


  • This optional step simply uses the Set-Mailbox cmdlet to define a custom Mail Tip message for when Outlook 2013 and newer users attempt to send messages to this mailbox. 

Set-Mailbox -Identity $newUser -MailTip "This room is equipped to support Skype for Business Meetings"


Another optional step is to disable password expiration on this new account.  By default, as with any AD account, the password defined in a previous step will automatically expire based on the account’s inherited password policy.  When dealing with shared meeting devices it may not be desirable to be forced to administratively update the account’s password within that interval.

  • To set the new account’s password to never expire simply run the following Set-MsolUser cmdlet and then optionally run the Get-MsolUser cmdlet to verify the change.

Set-MsolUser -UserPrincipalName $newUser -PasswordNeverExpires $true

Get-MsolUser -UserPrincipalName $newUser |fl userp*, passwordN*


Skype for Business Meeting Room

The final steps are used to create a Meeting Room account in Skype for Business Online.  Just as with on-premises deployments of Lync Server 2013 or Skype for Business Server 2015 this configuration is only available via PowerShell and is not provided in the web-based user management tools like the Control Panel or Office 365 Admin Portal.

Just as was performed above some additional variables will be defined to be used by the actionable cmdlet.  One difference here though is that in order to create a meeting room the online tenant’s registrar pool information must first be located. The first command is used to store the name of any existing Skype for Business Online user in the tenant as it will be used to query the proper registrar pool FQDN in the second command.  The third and final command goes about creating the new meeting room account.

It is important to run these commands after the previous Exchange commands in the same PowerShell session it uses the previously defined $newUser variable which would still be cached in the command shell session.

  • Define another variable which will be used to query and store up the proper Skype for Business Online registrar pool name for the specific tenant which will be needed to create the meeting room account.  Enter the SIP URI of any existing Skype for Business Online user in the tenant below (e.g. .

$pool=Get-CsOnlineUser -Identity "" | select -expand RegistrarPool

  • Execute this final cmdlet to create the new meeting room account using the previously created Exchange room mailbox.

Enable-CsMeetingRoom -Identity $newUser -RegistrarPool $pool -SipAddressType EmailAddress

If the Enable-CsMeetingRoom cmdlet fails with the following error then replication of the previously created mailbox has not yet completed throughout the Office 365 environment.  It may be necessary to wait anywhere from a few minutes to hours depending on the health status of Office 365.  Typically it only takes a few minutes before this cmdlet is successful but in some scenarios this has taken up to 24 hours before it works.

Management object not found for identity
+ CategoryInfo           : NotSpecified: (:) [Enable-CsMeetingRoom], ManagementException
+ FullyQualifiedErrorId  : Microsoft.Rtc.Management.AD.ManagementException,   Microsoft.Rtc.Management.AD.Cmdlets.EnableOcsMeetingRoomCmdlet
+ PSComputerName         :

When the Enable-CsMeetingRoom cmdlet is reported as successful then wait a few additional minutes and then run the following cmdlet to return all available meeting room accounts to verify that the new account is listed.

Get-CsMeetingRoom | ft Disp*,SIP*


Office 365 License

The final step is to assign an Office 365 license to the meeting room account.  This action can be performed in either the Admin Center or via PowerShell.  Both approaches are included below but obviously the action only needs to be performed once for each meeting room account that is created.

To assign a license using the same PowerShell session perform the following steps.

  • Enter the Get-MsolAccountSku cmdlet to return a list of the current tenant’s existing license types and units.  The example tenant used here as 25 enterprise licenses available with a unassigned licenses available.



  • Before assigning a license the new account will need to be assigned to a regional usage location. Use the Set-MsolUser cmdlet with the appropriate two-letter country code (e.g. US) for the tenant.

Set-MsolUser -UserPrincipalName $newUSer -UsageLocation "US"

  • Then use the Set-MsolUserLicense cmdlet with the appropriate TenantName:LicenseName value which was queried for earlier to assign a license to the new meeting room account.

Set-MsolUserLicense -UserPrincipalName $newUSer -AddLicenses "Schertz:ENTERPRISEPACK"

Alternatively to assign a license by using the Office 365 Admin Center perform the following actions instead.

  • Login to the Office 365 Admin Center and then browse to Users > Active Users.

  • Either locate the desired account or use the Filters drop-down menu to quickly list only Unlicensed users.


  • Highlight the new meeting room account and then click Edit to the right of the Product licenses option.

  • Select a Location and then enable the desired license (e.g. Office 365 Enterprise E1) and then Save the changes.

The configuration is now complete and the new Skype for Business Online Meeting Room account can be used with the intended device.

Quick Reference

As with many of these articles once the concepts are understood then repeat visits are typically those occasions when the only the process is important.  Thus once a workstation is configured and the script is saved then creating a new meeting room account is as simple as running a host of PowerShell commands, and then tidying things up by assigning a license.

The following block of text cleans up all of the detailed explanation and steps above into a straightforward process.  The commands can be run in three individual groupings to allow for replication process to complete between some of the steps.  Additionally a number of variables have been included to simply repeat usage of these commands.  Simply populate the fields in blue with the desired details and then copy/paste the remainder of the individual cmdlets as shown below.

  • Change the text in blue to the desired information and then execute these commands, waiting for the mailbox creation to complete.

$name="Meeting Room"

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

  • Wait about 30 seconds after the mailbox has been successfully created before running the next group of cmdlets to customize the user account and mailbox settings.

Set-MsolUser -UserPrincipalName $newUser -PasswordNeverExpires $true

Set-MsolUser -UserPrincipalName $newUSer –UsageLocation $location

Set-MsolUserLicense -UserPrincipalName $newUSer –AddLicenses $license

Set-Mailbox -Identity $newUser -MailTip "This room is equipped to support Skype for Business Meetings"

Set-CalendarProcessing -Identity $newUser -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 Skype Meeting will provide a seamless click-to-join experience from the conference room."

  • Given the aforementioned replication delays it may be required to wait up to 15 minutes (typically observed 5-10 minutes) in a healthy tenant before successfully running the next commands.

$pool=Get-CsOnlineUser -Identity $existingUser | select -expand RegistrarPool

Enable-CsMeetingRoom -Identity $newUser -RegistrarPool $pool -SipAddressType EmailAddress

The screenshot below shows all of these commands successfully executed in secession, with suggested interval timing.


« Previous PageNext Page »