Discovering the Skype for Business Registrar

May 30, 2017 by · 2 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 · 4 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 currently qualified or supported with Lync/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.

  • In the Proxy Server field enter the exact same information that was placed into the Registrar Server field above.  Unlike some standard SIP platforms the Microsoft SIP platform contains the proxy and registrar services in the same server roles.  (Note that this field is not used for pointing to a web proxy server.)

  • 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 · 2 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 · 16 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.


Polycom UCS 5.5 for VVX Phones

December 10, 2016 by · 28 Comments 

The latest release of the Polycom VVX 5.5.1 UCS firmware is now available for Lync and Skype for Business (SfB) environments.  While the initial 5.5.0 release was published a number of months ago that was only intended for Open SIP applications and was not yet supported for Lync/SfB use.

With this release comes a large number of anticipated features and improvements related to Skype for Business.  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 has been 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 Lync and the phone will immediately reboot.  If Lync is 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 covers enhancements to the phone user’s experience, like new authentication methods, call transfer workflow changes, group expansion, and device locking behavior to name a few.

Sign In Options

If the updated phone was factory-reset or did not currently have a Lync or Skype for Business user registered then the first screen that will appear after startup is complete will be the following new Sign In window providing up to four unique authentication options.


User ID

The User ID option brings up the User Credentials screen for the traditional registration process requiring appropriate user credentials.  This process remains unchanged and guidance provided among previous articles covering registration to on-premises or online platforms is still applicable.



The PIN option brings up the PIN Authentication screen which requires the user to enter their phone number or extension and their PIN.  This process can only be used with on-premises Lync/SfB deployments as it requires the configuration of DHCP Options 43 and 120 on the local network.

If the PIN authentication option does not appear on the main Sign In window then this would typically indicate that the prerequisite DHCP configuration is not in place and/or the STS-URI override option is not configured on the phone.  If PIN authentication is in fact configured correctly in the network then try canceling the Sign In window and then reselecting the Sign In soft-key from the main menu.  When the window initially appears after the phone has been powered on or rebooted it may still be attempting to locate the required server and sometimes delays in time synchronization can cause this.

image       image

via PC

The via PC option will only appear when the phone has already successfully established a Better Together over Ethernet (BToE) pairing connection to a Windows PC by way of the Polycom BToE Connector application.  This Automatic pairing functions the same as in previous releases but UCS 5.5.1 now includes a new Manual pairing mode which is covered in a later section of this article.  Selecting this option triggers a sign-in window to appear on the connected PC’s Skype for Business client.


Web Sign-In

The new Web Sign-in process can only be used for Microsoft Office 365 Skype for Business Online users.  Lync/SfB users accounts homed on an on-premises server, even in Hybrid models, cannot be used.  Currently this new capability is only for Microsoft cloud user accounts.

The following steps walk through using the new Web Sign-in process for online users.

  • Select the Web Sign-in option to advance through the new external authentication process which requires no additional interaction on the phone itself.  This will bring up the following screen with instructions to visit a Microsoft website on a computer and then enter a unique code.


  • Using a web browser on a separate computer go to and then enter your Skype for Business Online user username.


  • After being redirected to Office 365 enter the password for this account and then select Sign In.


  • Another redirection will occur to the Device Login page.  Enter the alphanumeric code that is currently being displayed on the phone’s screen (e.g. EADVJB5J3). Note that while the code is displayed in all capital letters it is not actually case-sensitive and can be entered in either upper or lower case characters..


Once the code is accurately entered it should immediately update to show the type of device being used, in this case a “Polycom Skype for Business Certified Phone”.

  • Select Continue and then, if prompted, select your desired account from the menu.  The page will report that the process is complete and the window can be closed.

  • Meanwhile the phone should now have automatically advanced to the sign-in process as seen below.


Once the process is complete the phone will prompt to create a device lock code.  This must be created and cannot be skipped, although this new behavior can be disabled which is covered in more detail later on in this article.

  • Enter the desired unlock code (e.g. 123456) and then tap the arrow in the lower-right corner.  Repeat these steps to validate the new unlock code.


Once registration is successful the standard home screen will display along with pinned Favorites.


To summarize, the User ID and via PC modes can be used for any Lync/SfB account on-premises or online. Yet the PIN method is only for on-premises deployments and the Web Sign-in model is only for online users.

Updated 5/12/2017: As of the latest 5.5.2 firmware release the Web Sign-In option can now be hidden via the new feature.webSignIn.enabled configuration parameter.  This parameter is enabled by default (feature.webSignIn.enabled=“1”) but can be disabled by manually setting the value to “0”.  That will hide the option from the main Sign In screen, which is recommended for on-premises deployments where this sign in model cannot be used.

Updated User Interface

At this point the screenshots above clearly show an updated interface more closely matching the color and iconography of the various Microsoft Skype for Business clients.  Note that only the VVX 500 and VVX 600 series support this refreshed look.  The VVX 200/300/400 series phones are thus far unchanged from the previous user interface when in Skype Base Profile.  All other new features and capabilities covered throughout this article still apply to all VVX models.

Here are a few additional screens highlighting the new, cleaner interface.

image          image

With this new release the previously entitled Lync Base Profile option has been renamed to Skype.  Understand that this really means Skype for Business and these phones cannot be used natively with the Skype consumer platform.  Also Lync Server environments are still supported so renaming this profile does not impact UCS support or functionality with existing Lync deployments.  This is purely a cosmetic change.


Device Locking

While VVX phones have long supported locking the phone interfaces down this was handled out-of band from Lync/SfB and required additional phone-side configuration. But now the VVX can leverage the existing device locking capability that was introduced in Lync Server 2010 for Lync Phone Edition devices.

A provisioned phone will automatically lock the interface after powering-up and registering with cached credentials as well as after 10 minutes of inactivity by default.  This behavior is identical in Lync Phone Edition devices.


  • When the screen is locked simply tap the opened padlock icon in the lower right corner and then enter the same device lock code which was created during the original user login process.


The phone can be manually locked by selecting the Lock option from the Home menu.


There is also a new menu located under Settings > Basic > Device Lock which can be used to either lock the phone immediately or to change the device lock code.  The current code will be needed to change it.

image     image

If the VVX phone is actively paired to a Windows PC using the BToE application then it will also automatically lock and unlock when the Windows PC is locked or unlocked, just like LPE devices always have when they were USB tethered.

If only VVX phones have been used in a Lync Server, Skype for Business Server, or Skype for Business Online deployment, with no Lync Phone Edition devices, then this default device locking behavior would never have actually been experienced.  Being forced to create a device PIN during the first successful registration after updating to 5.5.1 (as shown in the process above) may not be a desirable user experience in some environments.  Nor may be the basic behavior of having the phones automatically locking after the default  timeout interval of 10 minutes.

This previous article explains how to either disable or modify this locking behavior natively within Lync Server, and those steps are still applicable to Skype for Business Server.  But for Skype for Business Online tenants it is not currently possible to perform the same customization in the Office 365 administration portal.  Another more recent article outlines the few currently available parameters for controlling IP phone behavior directly from within SfB Online.  Unfortunately the options to disable device lock or control the timeout and device PIN complexity rules are not included.

Thus the traditional UCS provisioning model can be used to disable this device locking feature directly on the phone.  As with all other UCS configuration parameters these can be applied manually on the phone, or automatically using the standard provisioning server model or via enhanced third-party solutions like UC Commander, for example.

To disable this manually on a single VVX phone the Web Configuration Utility can be used to import a basic configuration file with the defined parameter.

  • Create a new file in any standard text editor (e.g. Notepad) and then copy/paste the following text. 

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<PARAMETERS feature.deviceLock.enable="0" />

  • Save the file with a .CFG extension (e.g. DisableDeviceLock.cfg).
  • Access the Web Configuration Utility using the VVX phone’s IP address and then sign in with the Admin account password (the default password is “456”).
  • Browse to the Utilities > Import & Export Configuration menu and expand the Import Configuration section, if it is not already.
  • Click Choose File and then locate and select the configuration file created in the first step.


  • Click Import to apply the configuration to the phone, triggering an immediate reboot.

After the reboot is complete it will automatically go to the standard home screen and no longer ask for a PIN to unlock the phone.

To re-enable the device locking behavior simply either perform a factory reset or use the same process above but first change the configuration parameter value from ‘0’ to  ‘1’. (e.g. feature.deviceLock.enable="1").  Ideally just create a copy of the configuration file and change the name to something like “EnableDeviceLock.cfg” to make it easy to switch the phone back and forth.

Although enabling and disabling the device lock capability is the only configurable UCS parameter in this release the phone will still adhere to a few additional in-band settings.  Both Lync Server and Skype for Business Server allow administrators the ability to modify not just whether device locking is turned on or off, but also to control the length of the device unlock PIN and the interval of idle time reached before locking the phone.

The PhoneLockTimeout and MinPhonePinLength parameters are configurable via either the Control Panel or Management Shell for on-premises server deployments only.  Any VVX phones running UCS 5.5.1 will adhere to the customized values of these Lync/SfB parameters.



In the example above the device lock remains enabled but the default 6-digit PN requirement was reduced to 4 digits and default timeout value of 10 minutes was increased to 30 minutes.  (Note that while the server will allow a timeout value to be set as low as 1 second on the policy the VVX itself will ignore values below 60 seconds as that is the shortest amount of time allowed before the phone will invoke the lock screen.)

In summary the new behavior here is that UCS will adhere to server-side configuration of device lock state, timeout, and PIN length just like a Lync Phone Edition device always has.  This server configuration for these features is only available to administrators of on-premises Lync/Skype deployments and cannot currently be managed on Skype for Business Online accounts.  Thus the only option for Office 365 hosted accounts is to disable the feature altogether using the phone-side parameter shown in this section; the timeout and PIN length are not currently customizable for these online tenants.

Call Transfer

In UCS 5.5.1 the call transfer behavior has changed in two ways, with one alteration being hardcoded and the other controllable through a new configuration parameter.

Unchanged is the default action in UCS to perform a Blind transfer and this behavior can be customized on the phone to instead prefer a Consultative transfer as the default action.

  • To modify the default transfer type on the phone press the Home key and then navigate to the Settings > Basic > Preferences > Default Transfer Type menu.


The steps below all show a blind transfer as the default option but understand that if the phone’s default setting is changed to consultative then the behavior will be the exact opposite as what what is shown here.

In firmware versions older than 5.5.1 the VVX call transfer behavior has been as follows:

  • Simply Tapping the Transfer button will bring up the standard transfer window and perform the default transfer action, (blind in this case)


The text entry field (highlighted in yellow in the edited image above) will either say “Blind transfer to” when Blind is the current action or simply “Transfer to” when Consultative is the current action.

  • Alternatively pressing and holding down the Transfer button for one second instead brings up a menu to change the transfer type for this call only.


In the new 5.5.1 firmware this behavior has been changed to following:

  • Tapping the Transfer button still triggers the default transfer action on the phone. (Again, Blind on this phone)


  • Alternatively pressing and holding down the Transfer button for one second will now trigger the non-default transfer action: in this case Consultative.  (Notice that the word Blind does not appear in the text entry field.)


  • And if using the long press method is not preferred then by default a new More soft-key has been placed in the upper right-hand corner of the Transfer window.  Selecting the More soft-key will brings up the following menu, providing the possible transfer actions for the current call.


By setting the new parameter up.softkey.transferTypeOption.enabled to “0” the More soft-key can be hidden, but the short/long press behavior in 5.5.1 cannot be changed. The identical process shown earlier in the Device Locking section be used to import this setting into a single phone for testing.

In short, with UCS 5.5.1 the call transfer process basically works as this: pressing the Transfer key performs the default transfer type while holding the Transfer key uses the other transfer type. In either method an additional, optional menu is provided to select the desired action without the need to understand the short/long press behavior.

Distribution Lists

Another new feature in UCS 5.5.1 is the ability to support Exchange Distribution Lists (DL).  This is something that has been available in the regular clients as well as Lync Phone Edition devices for some time.  Basically a user can now search for, save, expand, and place calls to DLs found in the organizational address book.

  • To search for and add a distribution list to the contact list for the account registered on the phone simply hit the Home button and select the Search icon.

  • Then search for the name of the desired distribution group.  The follow example is searching for a group named “Device Accounts”.


  • Highlight the result and then select Add to Contacts.

Now that the DL has been added to the phone it can be used to place calls to individual members or create an immediate conference call with all available members.

  • From the main screen select More > Contacts > Groups, highlight the saved DL, and then select Expand

image   image

The individual DL members will be displayed on the phone as seen above, which is shown alongside a screen capture of the same DL expanded in the Skype for Business client.

This VVX menu provides options to view the DL details, which displays the SMTP address for the group if applicable, as well as options to either Dial one specific member or to Dial All of them which starts a new conference call on the Skype for Business server.

Manual BToE Pairing

The latest Better Together over Ethernet (BToE) 3.4.0 software introduces a new Manual pairing mode.

It is important to understand that this new option is simply a means to an end and does not really provide any additional capabilities to the VVX with the 5.5.1 release.  This new pairing mode is laying the foundation for future support of different tethering scenarios which would no longer be limited to a physical Ethernet uplink directly to the phone.

Auto Pairing

The automatic process is unchanged and remains the default experience on the phone, and is still the recommended method to use.

  • On the phone press the Home key and then navigate to the Settings > Features > BToE PC Pairing menu and verify that the Pairing Mode is set to Auto.  (If the phone is set to manual then select the Pairing Mode to change it to automatic.)

image     image

  • Upgrade or install the latest 3.4.0 version of the Polycom BToE Connector Application on the PC.

  • Connect the desired Windows PC via wired Ethernet to the PC uplink port on the VVX phone and within a few seconds the phone should automatically be detected and the pair established. 
  • Return to the BToE PC Pairing menu to verify that the Pairing Status is reported as Paired.


If the Skype for Business logon prompt does not automatically appear on paired, unregistered phone then the sign in process can manually be triggered as shown below.

  • Press the Sign In button on the main screen of the phone to bring up the Sign In menu.  When the phone is already successfully paired to a PC then the via PC option will be provided. 


  • Select via PC to trigger the Skype for Business client phone logon prompt to appear on the paired PC.  Enter the user’s credentials on the PC to complete the sign-in process.

image     image

Manual Pairing

To be clear this new manual pairing mode currently still requires that the PC is physically connected via Ethernet to the phone’s Ethernet uplink port, no differently than all past BToE requirements.  (A later release is planned to add the ability to pair to the phone to a PC on the same subnet that is not physically connected to the phone itself.)  For now the manual mode would only be used if for some reason automatic pairing was not desirable in an environment.

  • On the phone press the Home key and then navigate to the Settings > Features > BToE PC Pairing menu and change the Pairing Mode to Manual


If the phone was already paired using the automatic process then the pairing connection will be broken at this time. Note the inclusion of a new Pairing Code (e.g. 599882) on the screen shown above; this is the information needed on the PC to initiate the pairing process.

  • On the PC right-click on the Polycom BToE Connector icon in the system tray and select the Pair with Phone menu option.

  • Enter the pairing code (e.g. 599882) provided by the phone into the Polycom BToE Connector window and then select Pair.


The connector application will report the paired phone details once the connection has been established.


Alternatively the current pairing status can also be found in the phone’s Web Configuration Utility under the BToE PC Pairing section of the Skype for Business Status screen.


The items in this section are generally of more interest to the IT administrators than the end users as these new capabilities in the firmware address subjects like call quality monitoring and managing device diagnostic logs.

Quality of Experience (QoE)

Along with improved media statistic reporting for native QoE monitoring in Lync/SfB the VVX now also supports the in-call QoE feature provided in Skype for Business 2015 server and 2016 clients.

The current status QoE status and configuration can be validated from the phone’s Web Configuration Utility.

  • Connect to the phone’s Web Configuration Utility and then navigate to Diagnostics > Skype for Business Status and expanded the Quality of Experience section shown below.


The additional in-call capability is not enabled by default on Skype for Business Server 2015, hence the ‘Disabled’ status reported above.  This behavior can currently be controlled only with Skype for Business Server 2015 on-premises deployments.

  • From the Skype for Business Management Shell on the Front End server use the Get-CsMediaConfiguration cmdlet to validate the current In Call QoS settings.



  • Either the following Set-CsMediaConfiguration parameters to enable and/or modify how often the phone will send in-call diagnostic information to the server.

Set-CsMediaConfiguration -EnableInCallQoS $true
Set-CsMediaConfiguration -InCallQoSIntervalSeconds 60

  • Reboot the phone and check the Quality of Experience section of the Skype for Business Status window in the Web Configuration Utility to validate that the phone has reflected the new settings.


Whether in-call diagnostics are enabled or not the new 5.5.1 firmware sends more report data to the Monitoring Server than in previous releases.  To validate this additional information the following screenshot is an excerpt from the Media Quality Report of a peer-to-peer audio call from a VVX phone running older 5.4.4 firmware (the Caller) and a Skype for Business 2016 Windows client (the Callee).


Notice that some of the MediaLine information above is missing and that the entire Caller Device and Signal Metrics section is blank.

Now compare this to the data shown below from the same call scenario repeated after upgrading the phone to UCS 5.5.1.


Device Log Upload

Not only can users and administrators now trigger the automatic upload of a phone’s device logs to the centralized Lync/SfB device log directory but administrators also have the ability to disable this capability if so desired.

To verify this new behavior which is enabled by default simply trigger an automatic upload directly from the phone using the following instructions.

  • Press the Home key and then select Settings > Basic > Diagnostic Logs to bring up the following screen. Note the Server Log Level option, which allows the user or administrator to modify the level of log verbosity among 5 different levels.

image     image

  • Select Upload Logs to trigger the phone to immediately gather its diagnostics logs and then upload them to the registered Lync or SfB server. The messages “Uploading log information” and “Log upload successful” should follow.

This log file will have been uploaded to the default device log folder on the Lync/SfB server’s file store (e.g. <filestore>\1-WebServices-1\DeviceUpdateLogs\Client\CELog) and will be located next to any Lync Phone Edition device logs.  The filename format includes the source device’s model name and MAC address.  Files uploaded from Lync Phone Edition devices from all vendors will always start with “UCPhone” while the newer generation of qualified phones like the VVX will always start with “3PIP”.


The upload process can also be triggered from the phone’s Web Configuration Utility using the Diagnostics > Upload Logs menu.


As with the other new features this capability can also be disabled to remove the option from the phone’s Basic settings menu as well as from the Web Configuration Utility.

  • In the same process as shown earlier in this article create and import a configuration file with the following parameter set to “0”.


Hide Sign In and Out Options

Borrowing a popular new feature from the Trio 8800 conference phone the VVX phone now supports various combinations of preventing users from signing out and/or in of the phone.  There are separate parameters to control the behaviors of either hiding the registration soft-keys on the main screen or disabling the capability on the phone altogether.

Disable Simple Sign In

The parameter softkey.feature.simplifiedSignIn controls the Simple Sign In feature which is enabled by default (“1”).  Turning this feature of f will remove the soft-keys for signing in and out of the phone as well as disable this in the web UI.  Only the Features settings menu on the phone can then be used to sign the phone in or out of Lync/SfB..

  • To disable the Simple Sign In feature set the following configuration parameter to “0”.


Notice that the Sign In soft-key on an unregistered phone no longer appears. The Sign Out soft-key is also removed on a registered phone.

image     image

A user can still sign in or out directly on the phone using the Settings > Features > Skype menu.


The Skype for Business Sign In option is disabled in the Web Configuration Utility.


Hide Sign In & Sign Out

The parameter feature.lync.hideSignInSignOut hides both the Sign In and Sign Out features entirely on the phone from both the main screen and the Features menu, but does not impact the web UI.  This parameter is disabled by default (“0”),

  • To enable hiding both Sign In and Sign Out capabilities from the phone interface set the following parameter to ‘’1”.


As with the previous feature the Sign In and Sign Out soft-key are also missing.

image     image

But also removed is the Skype Option under the Features menu, preventing a user from signing in at all directly from the phone.


Yet with this parameter an administrator can still use the Web Configuration Utility to register the phone.


Hide Sign Out Only

The parameter feature.lync.hideSignOut behaves identically to the parameter above except that it only impacts the Sign Out behavior and does not remove the Sign In ability.  This parameter is disabled by default (“0”),

  • To remove only the Sign Out capability from the phone interface set the following parameter to ‘’1”


As seen below a user can still sign in directly from the phone, but once registered the user is not able to sign out of the phone.

image     image

Unified Contact Store

The Unified Contact Store (UCS) is a Lync/SfB feature which leverages Exchange Server to store a Lync or SfB user’s SIP contacts in their exchange mailbox instead of the default Lync/SfB SQL location.  (To avoid confusion be aware that the abbreviation UCS is used interchangeably for both Microsoft’s Unified Contact Store as well as Polycom’s Unified Communications Software that runs on VVX and Trio phones.)

Traditionally when UCS is enabled the older VVX firmware versions could exhibit issues with reflecting changes on the user’s contact list or favorites.  These issues are resolved with the inclusion of support for user accounts which have UCS enabled on them.

Fall 2016 SkypeUG Meetings

October 31, 2016 by · 4 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 newest chapter in Austin, TX as their inaugural meeting kicks off on November 10th.

Event Details

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

The first session will take a look back at troubleshooting topics old and new in the Skype for Business platform.

The second session will be cover the next generation of Skype Room System conference room solutions, followed by open discussions with any remaining time.

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 in a different location.  This will be the first event hosted in the suburban Microsoft office and depending on the turn-out we may look into rotating the event location between downtown and suburban locations each quarter, or possibly even hosting two Chicago events per quarter.

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, November 3rd
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

Video Conferencing in Skype for Business Online

September 26, 2016 by · 16 Comments 

Fresh on the heels of the recent Microsoft broadcast entitled Video Interop in the Cloud have come a number of questions from the overall community looking for further clarification on exactly what all this means.  The summaries below also include various details from today’s announcements from Microsoft and some of their device partners at the Ignite 2016 event in Atlanta.  Interoperability is a term which can been used in a few different ways throughout the industry, but the articles here attempt to separate the overall term between ‘native’ integration provided directly within a client or endpoint versus ‘interoperability’ which can be provided indirectly between systems by way of an intermediary component.

The concepts outlined here may look familiar as much of what was covered in this previous article has been applicable to on-premises Skype for Business Server (SfB) deployments for some time.  The main differences since then are that the overall solutions have become more streamlined and feature-rich in the few years that have passed while knowledge of the back-end infrastructure is deemed less important as more of these components are moving into cloud-provided models.

The intent of this article is to clearly explain a few of the concepts and delivery models surrounding a topic of continuously growing interest: bringing traditional video teleconferencing (VTC) solutions into Skype for Business meetings.  Note that in the past most of the interoperability requests were described more often as “bringing together standard conferencing and desktop conferencing systems.”  More recently that need is specifically about getting the traditional solutions to play along in the Microsoft UC workflow.

The tide that seems to driving this is the ubiquitous usage and understanding of a very common workflow based on using Outlook to schedule a Skype for Business meeting.  This familiar behavior was the figurative linchpin in the literal redevelopment of interoperability solutions like Polycom RealConnect back in 2014, later followed by other products like Pexip Infinity or Acano Dual Homed Conferencing (now part of Cisco Meeting Server) which began to use similar architectures pioneered by Polycom.

Video Conferencing can generically refer to the simple act of turning on the embedded video camera on a laptop or mobile phone while participating in a Skype for Business meeting, or walking into a traditional corporate conferencing room and expecting to join the same meeting using some level of in-room equipment providing a higher-end video experience.  Practically it should refer to any and all scenarios in between these.  The goal is to get away from disparate workflow that ultimately may limit end-users by forcing them to select from one of several different ways to collaborate, none of which may address all of their needs individually and also not be able to operate in conjunction. Thanks to the pervasiveness of readily available tools like Skype this demand is common-place and almost expected of by many information workers today.

In the present stage getting to this single holistic solution is a reality, and in more ways than one.  The two available approaches can be leveraged independently or in conjunction, depending on the current state of an environment or the desired outcome.

The Interoperability route has several options and allows for the continued use of, or rekindled interest in, traditional standards-based video conferencing solutions available by a number of manufacturers.  The Native approach is best suited for greenfield deployments or environments looking to refresh aging equipment that may be beyond its useful life.  And of course a combination of both approaches can be used to leverage some of what may be in place today as well as start the journey towards replacing other solutions with compatible systems which can end up getting to a place where interoperability may no longer even be needed.

Native Compatibility

The simplest, yet often most expensive solution is typically to just go back to the drawing board.  Scrap whatever what may have been shortsightedly tossed together or improperly designed and then inherited.  Whether it is broken, perfectly functional, adequate but unpopular, out of warranty, disjointed, or in the event of equipping new office spaces there are many reasons to look at starting fresh to coincide with an established or emerging Skype for Business deployment.

End-users enabled in Office 365 will immediately have a range of conferencing options available to them across personal and corporate-owned devices.  With the wide array of Android, iOS, and Windows clients available on mobile phones, tablets, Surfaces, laptops, and desktop computers any of these can be used to create or join either scheduled or instant, ad-hoc meetings and provide the ability to share their own video as well as see one or more active video streams from other participants.

So how does one bring this comfortable experience into the traditional conference room space now?  On paper the easiest approach is to add or replace equipment in the room that uses the preferred solution and workflow.  Something that natively and securely registers to the Skype for Business platform, can access Exchange mailbox information to retrieve meeting invitations, and uses the same protocols and codecs to communicate with Skype for Business clients and servers.

There are basically three device categories which addresses this approach: Optimized, Compatible, and Unsupported.  Microsoft maintains a list of currently available partner solutions the Skype for Business Solutions Catalog.

Optimized Solutions

The most obvious category includes systems that run on software that Microsoft has created.  This includes solutions completely owned by Microsoft from development to sale, like the newer Surface Hub products.  This also includes co-developed products where Microsoft owns the software while one or more of their technology partners develop and build hardware devices to run this software.

The original Lync Room System (LRS) products fall into this category as while Microsoft developed and maintains the core Windows Embedded software manufacturers like Crestron and SMART have developed the overall hardware packages, basically building appliances to run the Microsoft-provided software.

The native Lync and Skype for Business capabilities offered by these systems are inherent due to the fact they typically run some flavor of an embedded Windows operating system along with the actual Lync or Skype for Business desktop clients installed.  The design and user interface can often obfuscate this fact but rest assured that the base Microsoft code is included in these software packages in some fashion.  The goal is to provide the core functionality offered by using the native Microsoft software but in a less-personalized package that is well-suited for use in common areas like conference rooms.

Other well-known examples of these types of solutions are the popular Lync Phone Edition desk phones originally built by various partners like Aastra (now owned by Mitel), LG-Nortel, Snom (built for and sold by HP) and Polycom.  It is worth pointing out that Microsoft has been moving away from the optimized model for IP phones for some time, relying on solutions in the next category to provide the next generation of IP telephony desk sets and conference phones.  Note that by now those compatible phones have eclipsed the original optimized phones in terms of telephony capabilities.

An important distinction covering products in this category is that because they are true Microsoft software clients then they only work with the Microsoft platforms.  A Lync Room System on its own cannot directly communicate with a standards-based H.323 or SIP platform, or the Lync Phone Edition device cannot register to a Cisco Call Manager environment.  These are purpose-built solutions which require access to Lync Server, Skype for Business Server, Exchange Server, etc.

Other offerings are the upcoming room systems designed under the Project Rigel program which were announced at Enterprise Connect earlier this year.  Microsoft just announced today at Microsoft Ignite 2016 that these products will officially be named Skype Room Systems, joining products like the previous Lync Room System (which is also referred to as Skype Room System) and Surface Hub products.  This new Skype Room System platform will be running Microsoft-developed software on a Surface Pro 4 bundled with a purpose-built dock offered by the existing program partners of Crestron, Logitech and Polycom.  The dock provides USB connectivity to certain qualified video and audio conferencing products already available today from these manufacturers, with more solutions to be brought into the fold later.  The user interface created by Microsoft will be identical across the various vendors with the actual camera and microphone devices being the main differentiation between the various systems.

Microsoft will cover more details on these new Skype Room System solutions in their upcoming Ignite session Dive into Project Rigel and the Skype for Business Meeting Device Portfolio.  Pre-production models of these will also be on display in the Ignite partner expo this week, like the Polycom MSR series.

Compatible Solutions

‘Compatible’ is the term that Microsoft reserves for third-party products which undergo an official qualification process, hence these also being loosely referred to as ‘qualified’ or ‘certified’ solutions as well.  In practice all of these terms are often used interchangeably but the critical identifier in this category is that these are solutions developed entirely by the partner, hardware and software, and are officially supported by both the manufacturer and Microsoft upon successful completion of a defined qualification process.  This program can also sometimes be seen referred to as 3PIP, or Third Party Interoperability Program.

This can be a difficult category to understand based on the various terminology that in reality is not even used consistently throughout Microsoft’s own documentation.  Even browsing between different categories in the device catalog like Meeting Peripherals versus Meeting Room Systems will display ‘Certified’ on one, yet ‘Compatible’ on the other.  Improved clarity across these various programs and catalogs would no doubt be welcomed by all.

An example of a product in this category is the RealPresence Trio 8800 conference phone, which is designed and built entirely by Polycom.  While the actual Microsoft Lync or Skype for Business client software is not included in these devices they do support an array of Microsoft protocols and codecs, providing the features and capabilities needed to pass the qualification requirements.  This simply means that the manufacturers include native support for things like server auto-discovery, secure SIP registration, presence advertisement, voice calling features, video codecs like X-H264UC, and more.

Whereas the optimized solutions will only work with Microsoft UC platforms many of the devices in this category are not limited in that way.  These products often support many different call control platforms, although not always concurrently.  So the same device could register to Skype for Business or could register to a Cisco VCS or Call Manager platform, or possibly even both at the same time.  The supported alternative platforms and capabilities will vary based on the products used but this flexibility can open the door for using a combination of approaches covered in this article.

Take the Polycom Group Series endpoints for example.  This solution’s unique design allows it to communicate with concurrent disparate platforms by leveraging the SIP configuration to register to a Lync/SfB server while also using the H.323 configuration to participate in calls with other systems outside of the Microsoft UC platforms.  The previous generation HDX products also supported this same dual registration model with Lync Server.

Furthermore there are modular solutions available today, like the Trio 8800, which are qualified in a specific configuration but not currently in others.  To clarify the Trio is qualified for SfB as stand-alone audio conference phone but not when paired with a Visual+ module to provide connections to a display and camera.  Then audio scenarios are still covered within the qualified realm but video conferencing and content sharing features fall into the remaining “supported but not certified” category.

Unqualified Solutions

The category is more of a catch-all then a specifically defined set of products. Basically anything not qualified or supported by Microsoft falls in here.  This could include a product that the manufacturer performs extensive internal testing and officially supports it themselves with Lync or Skype for Business environments, yet Microsoft does not directly support or may even acknowledge the existence of.  This could include products that barely function with Skype for Business and are not even supported by their own vendor.  Generally these types are not recommended as the interoperability can come as a result of reverse-engineering processes as opposed to working directly through the Microsoft partner programs.


A number of different scenarios were covered in the previous article focused primarily with on-premises conferencing deployments but at this stage the clear favorite among users and administrators alike has been the cascading topology that allows the SfB platform to drive nearly every part of the meeting lifecycle yet still allow for typically incompatible room systems to join in.  A meeting is scheduled, managed, and hosted using routine SfB tasks and all SfB clients are still connecting to their native environment for this experience.

This cascading experience was first developed by Polycom for use with Lync Server 2013 deployments and has since been adopted to the Skype for Business Server platform, with other vendors following suit and largely moving away from the legacy model of dialing directly into a Virtual Meeting Room (VMR) where the Microsoft UC clients would place calls directly into the standards-based bridges and not their own Lync/SfB meeting bridge.

Office 365 Offering

The Polycom RealConnect solution has been becoming more cloud-focused and this culminates with the addition of cloud video interoperability services directly in Office 365.  The Skype for Business product team’s recent broadcast meeting on this topic provided further details as to what this service is intended to be.  Basically this offering will be the Polycom RealConnect solution running inside of Office 365 and tied directly to the Skype for Business Online environment.  Gone will be any requirements to host on-premises components to leverage this basic capability.  Existing SfB Online users will continue to schedule meetings as they have done and the plethora of available standards-based conferencing systems can also join these same meetings.  While the term “standards-based” can sometimes be a gray area the functionality is available for nearly every type of common video conferencing solution from manufacturers like Cisco/Tandberg, Polycom, and LifeSize.

For those keeping a keen eye on the space this solution was also announced during Microsoft’s Enterprise Connect keynote this year.  It has since been referred to by various unofficial names including “Project Aqua”.  Another announcement from today is the official name for this offering as “Polycom RealConnect Service for Office 365.”  The public Skype for Business Preview program for this service will be made available later this year for select existing Office 365 tenants based in the U.S.  Next year will see the service rolled out to globally in a similar manner as other Office 365 features have been in the past.

But what about the native Video Interoperability Service (VIS) that was provided in Skype for Business Server 2015?  Why has Microsoft not simply leveraged software that is already in the sever platform today?  While the VIS role is still available for on-premises server deployments it has not received any further development since the original RTM version of the server platform. VIS does not currently provide near the features or level of security that purpose-built third party solutions can offer today when integrating with SfB.  By leveraging an existing complete solution rooted in the standards-based world that interoperability is desired with then a huge leap forward can be taken, yet still protecting the SfB user experience.

Third-Party Alternatives

Because this embedded Office 365 service is not yet available to the general public then what about addressing immediate needs?  The popular SfB interoperability solutions offer some level of capabilities today but the main limitation is these have not yet supported the preferred cascading topology with Office 365 users.  Regardless of where the third-party software is deployed (on-premises or in a cloud service) they have not been able to allow SfB Online users to schedule normal meeting that any room system can join.  Only the legacy VMR approach has worked with SfB user accounts which are homed in Office 365, meaning that those users must place a peer SIP call to something like “” which terminates on the third-party Multiparty Control Unit (MCU).

The desired MCU cascading methodology has so far been limited mostly to on-premises Lync and Skype for Business server deployments, but Polycom RealConnect has also introduced support for Hybrid or Federated SfB scenarios.  By utilizing SIP connectivity provided by on-premises Skype for Business servers (which no longer actually host any user accounts) the cascading meeting interoperability workflow can be provided to Skype for Business Online user accounts.

Understand that the upcoming Office 365 service discussed above is not simply taking a third-party infrastructure and hosting it into Microsoft Azure.  The clear benefit of the upcoming native cloud interoperability service is allowing the ‘better together’ workflow which keeps the call control and majority of the moving pieces within the SfB platform by allowing for the cascading model to be used.  Also, just as with best practices common with device selection, make sure to reference the Skype for Business Catalog to consider officially supported infrastructure solutions available from active Microsoft partners.

Basically the landscape is set to leverage several years worth of the RealConnect cascading workflow and experience for environments moving from on-premises SfB footprints, to hybrid, and eventually into Office 365 primarily.

Some of Both

The obvious question to come from all of this information is which approach to use: Native, Interoperability, or both?  This can best be answered by understanding the current strengths or any existing limitations in each and weighing them against what is needed in the environment.  Each can offer different experiences based on whether granularity of features or a focus on simplicity is more important.

When a video conferencing system is acting solely as a standards-based system, either by limitation (when it cannot register to SfB) or by choice (when available SfB registration capabilities are intently not enabled) then the interoperability model alone is used.  Traditional VTCs fall into two types: those which support calendaring and those which do not.  Many of the present-day VTCs from Polycom and Cisco support connecting to Exchange Server mailboxes to retrieve and display scheduling meeting information created by Outlook.  When these invitations also include Skype for Business meeting details then these systems can provide a simple click-to-join experience whether driven by a remote control, touch panel, or even touchscreen displays.

The older systems which do not support calendaring are limited to continuing the legacy experience of dialing number strings to join any meetings. Yet this action can now end up in a Skype for Business Meeting instead of being locked into meetings that only the other similar VTCs can participate in.

Another important use-case when considering between the two options is whether meetings will need to allow external parties like partners or customer the ability to join from their own standards-based video systems.  When looking at the native approach by deploying and/or upgrading all corporate conference rooms having an additional interoperability may seem unnecessary.  But what about outside participants in room systems that are not equipped to handle native SfB communications?  Leveraging an interoperability solution allows for this when desired by incorporating a perimeter network solution akin to the Edge Server that handles the communications protocols used by traditional VTCs.

Overall a fair amount of concepts and direction is included here yet without getting into the weeds on different products and their capabilities.  It is important to spend some time investigating specific offerings to understand that there is not always a one-size-fits-all solution.  The nuisances of each approach can either be ideal or cumbersome, depending on the desired outcome and overall flexibility to move away from workflows that are not working today and eagerness to adopt new and improved ways of doing old things.

Consider this post as an open forum to ask any questions via the comments section on this specific topic or if clarification is required on individual capabilities of any of the solutions or platforms covered above.

Summer 2016 SkypeUG Meetings

August 26, 2016 by · 1 Comment 

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


Event Details

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

The first session will take a look at the upcoming Skype for Business Mac client as well as review the various Skype for Business Preview Programs available today.

The second session will be a sneak peak at the Microsoft Ignite 2016 event, highlighting the solutions and products available by our group’s many sponsors.

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 downtown.  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, Sept 13th
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

Device Updates with Skype for Business Online

July 8, 2016 by · 1 Comment 

As outlined in this previous article a wide array of Polycom phones are now supported directly with Skype for Business Online in Office 365.  In the past dealing with device updates has been covered in several articles for the different device families and models.  These same concepts still generally apply when using the devices with Skype for Business Online but the configuration and management is slightly different.

While separate provisioning servers can still be utilized with the various 3PIP devices, the guidance across all of the previous articles is focused on traditional on-premises deployments of Lync and Skype for Business server platforms.  But what about the growing number of environments where none of those components exist and literally everything outside of the clients and end-user devices are simply leveraging the Office 365 cloud platform?

This article addresses these online-only tenants with guidance on how to manage IP phone firmware without using any additional management solutions.  Keep in mind that in the future some of these management tasks may become even easier as with Microsoft’s recent acquisition of some portions of Event Zero’s UC Commander platform as that could materialize into more direct control of Polycom UCS configuration parameters inside of the Office 365 administration portals.


With the introduction of official support for Qualified IP Phones in the online platform there arose a need to offer some sort of firmware management capability that resembles what the existing Lync and Skype for Business server installations already offered.  This is handled by the native Device Update service which is already part of Skype for Business Server.  The main difference though is that while the on-premises server platform the configuration is performed through a combination of Control Panel setting and Management Shell cmdlets, Office 365 administrators only have access to settings exposed in the online Administration Portal.  There is a limited subset of cmdlets defined for online tenants which do not match the vast array of on-premises server cmdlets.

Office 365 administrators today are given control of only a few IP Phone-specific options which includes the ability to disable the default in-band firmware updates behavior.  Microsoft controls what firmware version this will be so an administrator can only control whether or not they want the officially approved and supported firmware automatically deployed to their VVX phones, which is enabled by default.  It is not possible to select or upload a desired version using the device update service in Office 365 like an on-premises deployment offers.  To utilize any version other than the currently approved release the automatic update behavior must manually be disabled.

Default Behavior

At the time this article was written only the Polycom VVX IP phones will automatically receive device updates when registered with a Skype for Business Online user account.  The Trio 8800 conference phone, which is part of the same core Unified Communications Software (UCS) family, does not yet receive updates from the Skype for Business Online device update server.  Lync Phone Edition devices also do not receive firmware updates when registered directly to Skype for Business Online.

As outlined in Adam Jacob’s article earlier this year a pair of new cmdlets were added to the Skype for Business Online PowerShell Module for controlling some behavior of the IP Phones.  These new Get-CsIPPhonePolicy and Set-CsIPPhonePolicy cmdlets are only available using the online management shell.

  • Using Skype for Business Online Management Shell issue the Get-CsIPPhonePolicy cmdlet to review the following default configuration for any Office 365 tenant.  Note that the EnableDeviceUpdate parameter is set to True by default.



When a VVX phone is registered with a user account in this online tenant running at least the minimum required 5.4.0A firmware version it will automatically check with the device update server when signing in or booting up with previously entered cached credentials.

Shortly after a successful registration the phone may display a message that a new firmware update is available.  This will happen if the phone is currently running a version which does not exactly match the version that Microsoft currently has published on their servers.  As is always the case with the device update process it does not matter if existing version is older or newer, meaning the phone can upgrade or downgrade based on its version compared to the version advertised by the server.

So if the phone has detected that a different version is available on the server then an alert notification message will be shown on the Warnings screen, which is reported on the Alert icon on the top-left corner of the home screen.


For example the phone used to capture these screenshots is a VVX 601 running the most recent version of software supported for on-premises Lync and Skype for Business environments.

Understand that Microsoft publishes only the most recently qualified version for Skype for Business Online.  While updated versions are released for Skype for Business on-premises deployments often not every individual release goes through the complete online qualification process.  The point here is that the most current version that is both qualified and fully supported by Microsoft and Polycom is what should be used on O365-registered phones.  Leaving the device update service enabled is currently the best practice for keeping the phones on that specific approved version.


As shown above the qualified version at the time of writing this article is which is a few releases older than the version currently installed on this specific phone.

So what will happen here is that as soon as this phone is left inactive for 15 minutes (900 seconds) it will automatically begin the process of installing the approved firmware version from the server, effectively downgrading the device to the older, approved version.  Also note that the Reboot button on the above screen can be used to immediately trigger the update process as apposed to waiting for the inactivity timeout to be reached.

The Lync Device Update menu shown below can be used to see the last time the phone checked in with the device update service.

Home > Settings > Status > Diagnostics > Lync Device Updates


Disable Device Updates

To allow phone to run on a different version then the device update behavior can be disabled by editing the online IP phone policy that Polycom UCS devices natively understand.

Configure Policy

  • Using the Skype for Business Online Management Shell issue the following Set-CsIPPhonePolicy cmdlet to change the device update behavior.

Set-CsIPPhonePolicy -EnableDeviceUpdate $false


  • Then run the Get-CsIPPhonePolicy cmdlet to verify the change has been applied to the policy.  The following cmdlet example simply shows how to filter out the other parameters.

Get-CsIPPhonePolicy | Select-Object EnableD* | fl


As with any policy changes the registering device will not see this immediately.  There are several factors at play impacting how quickly a currently registered phone would pick up the new setting.  Typically within 8 hours policy changes are refreshed throughout all clients, but a manual reboot of the phone can help expedite this.  Given that this change is applied to a massive and mostly uncharted cloud provider environment it typically takes a few minutes for that change to propagate amongst the tenants home pool.

Testing has shown that waiting about 15 minutes after applying the policy change above is sufficient before rebooting a phone.  Because the default update timeout is also 15 minutes make sure to interact with the phone at least once to reset that timer to prevent the device from updating itself before picking up the new setting.

Obviously this approach works if one is prepared for this but most likely the phones have already flipped to the undesired version and when looking for a solution this blog article was found.  So more likely the phone is already been downgraded and the timing is not really critical.  Simply disable the update service, wait until the phones have picked up the policy change, and then upgrade them to the desired version using any of the supported methods.

Validate Endpoint Configuration

To verify that the phone has picked up the new configuration after rebooting and re-registering to Skype for Business Online there are a few items which can be checked.

  • The notification of an available device update will no longer appear on the phone’s home screen nor in the Warnings window.

  • The Lync Device Updates menu is now hidden and will no longer be shown under the Diagnostics menu. 
  • The ‘device.prov.lyncDeviceUpdateEnabled’ parameter will be set to ‘0’ to indicate that it is disabled.

While the first two items can easily be seen directly on the phone to be absolutely sure that device updates has been disabled on the device configuration parameters can be viewed using the following procedure.

  • Connect to the web management UI on the phone.  If it is disabled then enable it and reboot the phone, as shown in the Enable Web Server section of this past article..

  • Sign in using the defined Admin password (456 by default) and then browse to the Utilities > Import & Export Configuration menu.
  • Expand the Export Configuration section and then select Device Settings from the drop-down menu.


  • Click Export and save the file.  Once downloaded open the Export_device_settings.cfg file.  These files are easiest to navigate using an XML Editor like XML Notepad, but any text editor/viewer will work.

  • Scroll down towards the bottom of the file and look for the device.prov.LyncDeviceUpdate* section of parameters.
  • Check the value of the device.prov.lyncDeviceUpdateEnabled parameter.  As shown below a defined value of 0 indicates that the device updates are disabled which the phone did receive in-band during the last registration attempt.


Configure Individual Phones

As mentioned earlier it is recommended to leave these device updates services enabled to insure the phones are always running on the latest approved build.  But in the event that a different version needs to be installed on all phones then the process above can be used.

If only looking to prevent one or a few phones from upgrading for the purposes of testing other firmware versions then it is better to disable the update capability directly on the phone instead of on the server which currently only supports a single Global policy that applies to all users in the specific O365 tenant.

  • Create a new txt file called DisableLyncUpdate.cfg and copy/paste in following text:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<PARAMETERS device.set="1" device.prov.lyncDeviceUpdateEnabled.set="1" device.prov.lyncDeviceUpdateEnabled="0" lync.provisionDeviceParams.enabled="0" />

  • Using the process shown in the previous step access the web management UI and from the Utilities > Import & Export Configuration menu Import the file that was created in the previous step into the phone.

The first two parameters must be set to 1 in order to write changes to any phone parameters in the device settings partition.  The last two parameters will then disable device updates in addition to ignoring any device parameters currently being provisioned in-band during the SfB registration process.  Obviously changing only the device update parameter would not be sufficient as the next time the phone applies the client policy settings then it will simply revert back to the server-provisioned behavior.  Setting the lync.provisionDeviceParams.enabled parameter to 0 makes sure that does not happen

It is important to note though that setting this parameter to ‘0’ will actually disable more than just device updates as the phone will also ignore all of the following parameters controlled by the Set-CsIPPhonePolicy cmdlet:


To configure the alternative scenario of disabling updates on the client policy and then enabling them for a few individual phones then simply change the device.prov.lyncDeviceUpdateEnabled values to ‘1’.

Next Page »