Microsoft Ignite 2015

May 1, 2015 by · Leave a Comment 

Next week at the Microsoft Ignite 2015 event in Chicago I will be presenting a session on video conferencing with Skype for Business 2015. 

This presentation will brush up on a few new client features, introduce various interoperability models and then dive deep into the new Video Interop Server role in Skype for Business Server 2015.


A Technical Deep Dive into Skype for Business Video and Interoperability

Wednesday, May 6

5:00 PM – 6:15 PM

Room: E450

The great video experience of Skype for Business demystified! Behind the smiling faces of your customers, colleagues, and partners is some sophisticated technology. Come learn the details of how Skype for Business pulls it all together for a great video calling experience. We provide in-depth coverage of architecture, user experiences, and the new investments around Video Interoperability.

If you are attending Ignite you can join me for this session by adding it to your My Schedule page.  I’ll also be working in various booths across the Expo floor so come by and say hello at either the Polycom, Skype for Business, or Lync Users Group booths throughout the week.

Managing Lync Online with PowerShell

April 20, 2015 by · 2 Comments 

While articles on this blog are primarily focused on real time communication capabilities provided throughout Lync on-premises environments, as Microsoft moves forward with including more voice and video features in their cloud offering then integration and management of Lync Online will start become more common here.


One of the first steps in this journey is understanding how a Lync Online tenant can administer their environment.  Just as with a Lync on-premises deployment there are two primary tools for doing this: a web-based graphical user interface (GUI) and a command-line shell.

Since the original Lync 2010 release the GUI tool has been a Microsoft Silverlight based control panel that was also delivered as a web portal provided by IIS running on a Lync Front End server.  The shell portion has leveraged Windows PowerShell by using a module of several hundred cmdlets to control every aspect of the platform.


Yet Lync Online, soon to be upgraded to Skype for Business Online, leverages a single, massive multitenant deployment of Lync 2013 thus a large portion of server-side capabilities are not exposed to the individual tenant administrators.  Clearly disastrous results could occur if a single tenant had the ability to modify the behavior of any single component or parameter that could potentially impact any or all other tenants. Because of this shared model the administration tools for managing Lync Online are quite different than what administrators of on-premises deployments are used to.

First off the Lync Control Panel is replaced with the Lync Admin Center which is a component of the centralized Office 365 Admin Center.  As seen below the listed sections in the admin center is a mere shadow of what is available in the control panel shown above.


As expected the available PowerShell cmdlets is also quite different between the platforms.  With just a couple commands the current total of individual cmdlets in the Lync on-premises server module can be retrieved.


As of the time this article was written there are only 50 unique cmdlets available in Lync Online, which is quite the difference from the nearly 750 cmdlets provided to manage an on-premises deployment of Lync.


While connecting to the admin center is as simple as opening a web browser on any computer or device with Internet access leveraging PowerShell does require a short one-time setup for a Windows workstation.

As a prerequisite the Windows operating system on the computer to be used must be of the 64-bit variety and be running at a minimum Windows 7 or Windows Server 2008 R2.  Additionally Windows PowerShell 3.0 or newer must be installed on the system.  Windows 7 and Server 2008 R2 with at least Service Pack 1 will already fulfill this requirement as PowerShell 3.0 is the default version, with newer operating systems (e.g. Windows 8 and Server 2012) utilizing 4.0 and newer.

  • To confirm the version of PowerShell running on the selected Windows computer open a new PowerShell session and execute the $PSVersionTable cmdlet and then take note of the PSVersion value.

PS C:\Windows\system32> $PSversionTable

Name                           Value
—-                           —–
PSVersion                      4.0
WSManStackVersion              3.0
CLRVersion                     4.0.30319.34209
BuildVersion                   6.3.9600.17090
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.2


Once completed the installation will not create any shortcuts to a separate shell or application, but the Lync Online Connector module will be installed and ready to be imported into PowerShell.

As this new command module is not part of the inherent Windows installation and although provided and signed by Microsoft it was downloaded from the Internet, thus the default behavior of PowerShell will be to block even the computer administrator from importing the command module.  To resolve this the script execution policy must be modified.

  • Open a Windows PowerShell session as an administrator and then enter the following cmdlet to query the existing script execution policy configuration.

PS C:\> Get-ExecutionPolicy

If this workstation has already been configured to use another product’s external modules then the value may already be set to something other than Restricted.  If that is the case then the next step can possibly be skipped, depending on the current value.

If the default value of Restricted is set then this will need to be changed in order to import the Lync command module each time a new PowerShell instance is started.

  • In the same PowerShell window enter the following Set-ExecutionPolicy cmdlet to lower the policy to a compatible level of RemoteSigned required to use the Lync Online module.

PS C:\> Set-ExecutionPolicy RemoteSigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at Do you want to change the execution policy?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y

This completes the one-time setup for the workstation and these steps should not need to be performed again.

Connecting to Lync Online

While there are already a handful of articles on this topic, including the official TechNet documentation, many of these include extraneous steps which make it a bit difficult for the first time user to understand the process.  This section will cover the minimum number of basic commands required to connected, while a later section will introduce a customized script which can be used to automate these individual steps for repeated future use.

What is important to understand is that the installed command module does not contain a complete set of Lync Online cmdlets, but is instead a single cmdlet that is used to establish a remote PowerShell session to Lync Online.  Each online user account which is configured as an administrator in Lync is allowed up to 3 simultaneously remote PowerShell sessions.

The individual steps listed here all include the optional -Verbose parameter in the screenshots for instructional purposes and can be omitted when running each cmdlet.

  • Open a Windows PowerShell session and then enter the Import-Module cmdlet to import the Lync Online command module into the active PowerShell instance.

Import-Module LyncOnlineConnector


If the Import-Module command fails with a message about not being able locate the modules then a reboot may be necessary to complete the previous installation.

  • Enter the following  command to establish a connection to Lync Online which automatically triggers a prompt for the user credentials of a Lync Online administrator account.

$session = New-CsOnlineSession



  • Enter the following command to complete the connection by importing the Lync Online cmdlets form the remote session into the local session.

Import-PSSession $session


These three easy steps have now provided remote PowerShell access to the connected Lync Online tenant.  To test connectivity simply try running one of the supported Lync Online cmdlets, like Get-CsClientPolicy.

Managing Lync Online

As previously mentioned there are only a handful of cmdlets for Lync Online so a majority of the common Lync cmdlets will not work here.  How is one to know exactly which cmdlets are available to the Lync Online administrator?  One option is to look at the TechNet documentation listing the Lync Online cmdlets but as that information is not always up to date another option is to query for the actual list directly from within PowerShell.

In the PowerShell instance from in the previous step notice that the output of the Import-PSSession cmdlet reports a temporary name (e.g. tmp_cmmvwal0.zrc) for the imported session.  If that output has already been cleared or scrolled off of the buffer then the following cmdlet can be used to query for it.

  • In the existing PowerShell instance run the Get-Module cmdlet to list all currently active modules.  Note the name of last entry which lists a “*-Cs*” cmdlet format under the Exported Commands field.

PS C:\> Get-Module

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Script    LyncOnlineConnector                 {New-CsOnlineSession, Set-W…
Manifest    Microsoft.PowerShell.Management     {Add-Computer, Add-Conte…
Manifest    Microsoft.PowerShell.Utility        {Add-Member, Add-Type, Clear…
Manifest    Microsoft.WSMan.Management          {Connect-WSMan, Disable-WSMan…
Script     1.0        tmp_cmmvwal0.zrc                    {Copy-CsVoicePolicy, Disab…

    • Using the temporary name displayed  (e.g. tmp_cmmvwal0.zrc) issue the Get-Command cmdlet to list all of the Lync Online cmdlets which where imported into the local session.

PS C:\> Get-Command -Module tmp_cmmvwal0.zrc

CommandType     Name                                               ModuleName
———–     —-                                               ———-
Function        Copy-CsVoicePolicy                                 tmp_cmmvwal0.zrc
Function        Disable-CsMeetingRoom                              tmp_cmmvwal0.zrc
Function        Enable-CsMeetingRoom                               tmp_cmmvwal0.zrc
Function        Get-CsAudioConferencingProvider                    tmp_cmmvwal0.zrc
Function        Get-CsClientPolicy                                 tmp_cmmvwal0.zrc
Function        Get-CsConferencingPolicy                           tmp_cmmvwal0.zrc
Function        Get-CsDialPlan                                     tmp_cmmvwal0.zrc
Function        Get-CsExternalAccessPolicy                         tmp_cmmvwal0.zrc
Function        Get-CsExUmContact                                  tmp_cmmvwal0.zrc
Function        Get-CsHostedVoicemailPolicy                        tmp_cmmvwal0.zrc
Function        Get-CsHostingProvider                              tmp_cmmvwal0.zrc
Function        Get-CsImFilterConfiguration                        tmp_cmmvwal0.zrc
Function        Get-CsMeetingConfiguration                         tmp_cmmvwal0.zrc
Function        Get-CsMeetingRoom                                  tmp_cmmvwal0.zrc
Function        Get-CsOnlineUser                                   tmp_cmmvwal0.zrc
Function        Get-CsPresencePolicy                               tmp_cmmvwal0.zrc
Function        Get-CsPrivacyConfiguration                         tmp_cmmvwal0.zrc
Function        Get-CsPushNotificationConfiguration                tmp_cmmvwal0.zrc
Function        Get-CsTenant                                       tmp_cmmvwal0.zrc
Function        Get-CsTenantFederationConfiguration                tmp_cmmvwal0.zrc
Function        Get-CsTenantHybridConfiguration                    tmp_cmmvwal0.zrc
Function        Get-CsTenantLicensingConfiguration                 tmp_cmmvwal0.zrc
Function        Get-CsTenantPublicProvider                         tmp_cmmvwal0.zrc
Function        Get-CsUserAcp                                      tmp_cmmvwal0.zrc
Function        Get-CsVoicePolicy                                  tmp_cmmvwal0.zrc
Function        Grant-CsClientPolicy                               tmp_cmmvwal0.zrc
Function        Grant-CsConferencingPolicy                         tmp_cmmvwal0.zrc
Function        Grant-CsDialPlan                                   tmp_cmmvwal0.zrc
Function        Grant-CsExternalAccessPolicy                       tmp_cmmvwal0.zrc
Function        Grant-CsHostedVoicemailPolicy                      tmp_cmmvwal0.zrc
Function        Grant-CsVoicePolicy                                tmp_cmmvwal0.zrc
Function        Invoke-CsUcsRollback                               tmp_cmmvwal0.zrc
Function        New-CsEdgeAllowAllKnownDomains                     tmp_cmmvwal0.zrc
Function        New-CsEdgeAllowList                                tmp_cmmvwal0.zrc
Function        New-CsEdgeDomainPattern                            tmp_cmmvwal0.zrc
Function        New-CsExUmContact                                  tmp_cmmvwal0.zrc
Function        Remove-CsExUmContact                               tmp_cmmvwal0.zrc
Function        Remove-CsUserAcp                                   tmp_cmmvwal0.zrc
Function        Remove-CsVoicePolicy                               tmp_cmmvwal0.zrc
Function        Set-CsExUmContact                                  tmp_cmmvwal0.zrc
Function        Set-CsMeetingConfiguration                         tmp_cmmvwal0.zrc
Function        Set-CsMeetingRoom                                  tmp_cmmvwal0.zrc
Function        Set-CsPrivacyConfiguration                         tmp_cmmvwal0.zrc
Function        Set-CsPushNotificationConfiguration                tmp_cmmvwal0.zrc
Function        Set-CsTenantFederationConfiguration                tmp_cmmvwal0.zrc
Function        Set-CsTenantHybridConfiguration                    tmp_cmmvwal0.zrc
Function        Set-CsTenantPublicProvider                         tmp_cmmvwal0.zrc
Function        Set-CsUser                                         tmp_cmmvwal0.zrc
Function        Set-CsUserAcp                                      tmp_cmmvwal0.zrc
Function        Update-CsTenantMeetingUrl                          tmp_cmmvwal0.zrc

Simplifying the Process

As promised the following guidance can be used to create a script to start up the PowerShell session requiring nothing more than entering the administrator’s password.

  • Using either a simple text editor like Notepad or a more advanced tool like Windows PowerShell ISE create a new script file (e.g. LyncOnline.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.

Import-Module LyncOnlineConnector
$credential = Get-Credential
$session = New-CsOnlineSession -Credential $credential
Import-PSSession $session
Get-CsTenant | fl DisplayName

  • Save the file and then either store it in a path that PowerShell can see by default (e.g. C:\Windows) and simply invoke this script after starting a new PowerShell session.


This basic script will perform all of the required commands including prompting for the supplied account’s password, and then complete with an optional query of the tenant’s Display Name to (a) verify the remote connection is working and (b) list the connected tenant name which may come in handy if administering more than one tenant form the same workstation.  The last command can be omitted if desired.

April 2015 Lync Users Group

April 19, 2015 by · Leave a Comment 

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


Event Details

This meeting will be conducted in our familiar two-session format:

This meeting will include two sessions, the first session will cover the Skype for Business Client, which was just released to the public last week.

The second session will dive into a Best Practices Open Forum. This second half will be facilitated by the local presenter, but member driven. Please come prepared to discuss an Lync-related topic that you feel you can provide guidance on to the rest of the members.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Lync.  Food, beverages and additional door prizes will be provided courtesy of the Lync 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 Lync Users Group Locations page lists all planned event locations with links to the associated page for each regional group.  For current members if your region’s event is not yet scheduled just make sure that your notification options are configured so that you’ll get an alert when the new event is posted.  For anyone who is not yet a member and would like to participate simply create a new Meetup account (or use an existing one) and join your local group.

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
Thursday, April 23rd
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago UC Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200 
Chicago, IL 60601

Lync Registration on VVX Phones

April 19, 2015 by · 4 Comments 

Most of the instruction in this article has already been included in various past articles but as some additional methods for Lync registration have been introduced it seems logical to revisit each of the options in a single referenceable article.  The options covered below are available on any VVX phone running at least UCS 5.2 firmware or newer.

When in doubt the phone can be reset to factory defaults as described in this previous article to start from a clean slate and then registered using any of the following procedures.

Enable Lync Base Profile

The first step for any Lync registration process is always to enable Lync Base Profile if it is not already.  Some devices will come preconfigured with Lync Base Profile directly from the factory and this may not be necessary depending on the current state of the phone.

Previous articles have covered various ways to set this but the easiest is to use the Multi Key Combo (MKC) of 1,4,9 to jump right to the Base Profile menu.

  • Press and hold the 1, 4, and 9 keys together for at least 3 seconds, then enter the administrator password when prompted (the default password is ‘456’).

  • At the Base Profile menu Select Lync and confirm the choice to immediately reboot the phone and apply the changes.

Once the reboot process has completed then any of the following registration methods can be used.

Register From the Handset

A standalone phone can be registered to Lync by simply entering the Active Directory credentials or the phone number/extension and PIN of the desired user directly into the handset.

  • After Lync Profile is enabled the PIN Authentication window will appear by default.  If this is the preferred method simply enter the desired user’s phone number or extension and PIN and then select Sign In.


Understand that using PIN Authentication will not provide access to any Exchange server features like the Calendar, personal Contacts, Voice Mail, etc.

  • To utilize user credentials which will provide Exchange connectivity simply navigate back to the home screen instead.

  • From the home screen select the More soft key and then choose Sign In.
  • Select the User Credentials option and then populate the required fields.  (The on-screen keyboard available on the VVX 500 and 600 models can expedite the character entry over using the number pad.)



  • Select Sign In to start the registration process with the Lync Server.

Register from a Paired Workstation

The Better Together over Ethernet (BToE) method can be used to provision Lync user credentials to a VVX handset from a paired workstation, identical to how a Lync Phone Edition devices can be provisioned using USB tethering.

  • Download the appropriate BToE client software and install it on a Windows workstation which is connected to the network via the Ethernet uplink port on the VVX phone.

  • After the software has been installed the phone should automatically be located via the Ethernet uplink and reported as Paired by the workstation


  • Sign into the Lync client on the workstation (if not already) and the following window should automatically appear, prompting for the Lync user’s credentials to send to the phone.  Enter the appropriate Sign-in address (SIP URI), Active Directory domain and user names, and the password. Either the DOMAIN\username NetBIOS format or the User Principal Name format can be used.


The phone’s display will then indicate the attempt to sign in to Lync and should complete in a few seconds.


A successful registration will show the Lync user’s name and status, along with a message that the BToE pairing was activated.


Register from the Web Management UI

As defined by the Microsoft 3PIP qualification the phone’s web management user interface is now disabled by default whenever Lync Base Profile is enabled.  In order to access the web interface’s Lync SignIn section then it must first be re-enabled from the phone (or remotely via a provisioning server configuration file is desired).

Enable Web UI

Re-enable the Web management user interface in order to use if for user authentication.

  • Press the Home key on the phone and then navigate to the following menu: Settings > Advanced menu and when prompted to enter a password on the Advanced menu enter the administrator password configured on the phone (the default value is ‘456’).

  • Continue on to the Administration Settings > Web Server Configuration.  (The Web Server Configuration item is located at the bottom of the Administration Settings menu.)

Note that the phone’s embedded Web Server is disabled because Lync Base Profile was activated.


  • Change the Web Server parameter to Enabled and the Web Config Mode parameter to whichever combination of HTTP and HTTPS is desired (e.g. HTTP/HTTPS).


  • Back out and select Save Config which should trigger a reboot of the phone to apply the change.

Register to Lync

Connect to the phone’s web management user interface to register it to Lync.

  • Press the Home key on the phone and then navigate to the following menu: Settings > Status > Network > TCP/IP Parameters

  • Note the IP address and then connect to that address in a web browser. 
  • Leave the Login As value at the default setting of Admin and then enter the default administrator password of ‘456’. (If Internet Explorer 11 is used then it may be required to add the IP address to the Compatibility View list if getting stuck at this menu.)
  • Browse to the Settings > Lync SignIn menu.
  • Select an Authentication Type of either Login Credentials or PIN Authentication and then fill out the appropriate fields as shown in the examples below.

image  image

    A successful registration will be reported by the following window appearing in the browser.  Checking the status on the phone itself should also confirm this.


A successful registration will show the user’s presence status, any pinned Lync favorites on the home screen, and report the synchronization status of various features.


Introducing the Polycom RoundTable 100

April 15, 2015 by · 6 Comments 

Recently at Enterprise Connect 2015 Microsoft and Polycom together unveiled the latest in conference room solutions designed for Microsoft’s enterprise UC platform. The RoundTable 100 is the first offering in a series of new co-developed products designed specifically to work with Skype for Business (SfB). 


This product enters a completely new arena in terms of target audience, design, architecture, and user experience.

This article will cover both what this specific model is intended to address, as well as help to understand what the product is not. As the landscape of meeting room devices improves in the future and additional options are available it is important to understand the difference in the various products and that there is no one-size-fits-all solution.

Polycom RoundTable

The RoundTable name should be recognizable to anyone familiar with Microsoft UC devices as that was the name which was given to the original 360 degree panoramic camera created by Microsoft Research and designed for Live Meeting.  When Polycom purchased the rights to the device it was renamed to the CX5000 fit in with the existing ‘CX’ nomenclature for all Lync-specific devices like the popular CX600 desktop phone.

Going forward the Polycom RoundTable name will be used to denote all of the conference room products designed specifically for Skype for Business.  Not just the panoramic cameras but any type of room collaboration device, round or square in shape.  Additionally the existing CX5100, CX5500, and CX8000 products will also fall under the same RoundTable umbrella (CX audio devices will not be changed).

So, what is it?

The RoundTable 100 will come as three bundled main components: a Windows embedded appliance PC, a high definition USB camera, and a USB speaker phone.  The bundled audio and video devices are the only devices which can be used, attempting to connect any other Lync qualified (or unqualified) devices to the main unit will not function.

The main unit can be connected to any monitor and to an Ethernet port with access to the Internet.  From there the unit will automatically connect via a special account to Microsoft’s Office 365 offering, this is not a unit which can be manually registered directly to any on-premises or cloud Lync/SfB tenant.


Firstly, the RoundTable 100 is ideal for environments with little to no IT staff available to manage conference rooms. In these small-to-medium businesses existing options are limited to BYOD or plug-and-play solutions which require Lync-enabled devices to be brought into the conference room and physically connected. Requiring users to connect and test devices before each meeting may not be ideal so some sort of dedicated in-room system is often desired. The existing Lync Room System model helps address this need at the top end, but potentially at an executive-level cost and experience which does not always fit into the limited budget of many SMBs.

The RoundTable 100 is the first foray into this market with a set-it-and-forget-it deployment model designed with a Lync user experience. Intended primarily for but not limited to Office 365 consumers this product opens the doors for a prepackaged room system experience that closely mimics what an employee would experience if they brought their own laptop or Surface tablet into a conference room and then connected it to a Lync Qualified USB video camera and/or small conference room speaker. This dedicated in-room system addresses the need for anyone to bring that type of device into the room, only their own personal smartphone or similar mobile device is required.

There is no in-room interface device coupled with the RoundTable 100 like a touch panel or keyboard.  The entire in-room experience is driven by an attendee’s mobile device by leveraging a Companion Application on their personal mobile device.

What is it not?

It is not Lync Room System (LRS) version 2.  Neither is the recently announced Surface Hub  Each of these products are intended for different use cases, driven primarily by cost and the desired in-room user experience. Regarding the future of LRS Microsoft has already publically announced their intent to release a Skype Room System platform based on Windows 10 and the Skype for Business client, with current LRS hardware being provided a roadmap to upgrade to this new software.  In essence this could simply be a rebranding of the platform, potentially bringing some of the newly improved Skype user interface into the room system itself.

While the RoundTable 100 will provide a very simplistic, factory-provisioned deployment experience this also means that IT management options are little to none with this product. The more control an enterprise requires over devices deployed on the network the more that it is not a good fit. Existing and future room systems and devices intended for Lync and Skype for Business are designed specifically for the enterprise and medium-sized businesses with IT departments, better matching those types of management requirements.

It is not configurable. The device is pre-provisioned from the factory with a unique, masked identity to perform the required SIP registration to Microsoft’s cloud. When meetings are joined from this device the user’s own account is how they are identified in the meeting.  Whatever user has paired to the device using their Companion Application is the identity which will appear in the meeting. Again this is unlike any current room systems which have their own meeting room identity in Lync and in Exchange.

It is not customizable. The device is locked down to only work with the supplied USB camera and speakerphone unit. Connecting any other Lync or SfB qualified USB devices (including even Polycom’s RoundTable cameras) will result in an error reported on the unit and will break that modality (audio and/or video).

It is not designed for existing Lync or SfB deployments, directly. The backend infrastructure that provides the provisioning model will be part of Microsoft’s Office 365 environment driven by Skype for Business.  This means that any business can use these devices although the target customer is any on or planning to utilize Office 365.  All that is required to use this product is an Internet connection and personal devices with the Companion App loaded which contain Lync Meeting invitations in its calendar. The RoundTable 100 can then join any meeting regardless of what types of environment those invitations point to: on-premises or hosted Lync/SfB environments.  The system simply connects to the AVMCU as a federated client, be it an on-premises pool or a pool accessible via the Internet.


Overall while this entry level solution is not something that slots into the enterprise landscape today this does signal the beginning of a new family of products which will eventually make that journey.  And for the large amount of small businesses out there today which are already moving toward Office 365 as their UC platform there will soon be a simple product which can be dropped into any room with a monitor to help increase productivity in a matter of minutes.


Polycom UCS 5.3 for VVX Phones

March 31, 2015 by · 48 Comments 

The newest release of Polycom VVX firmware is now available as the 5.3 UCS release.  There are a lot of new Lync specific features, some of which are highlighted in this article.  Not all of the features are covered, so make sure to also look for the upcoming administrators guide for release 5.3 for full details.

New Firmware

Prior to using any of the new features a VVX handset will need to be upgraded to the 5.3 software release.

As covered in past articles there are various ways to upgrade the firmware using a centralized distribution point like the Lync Device Update service.  The easiest way to update a single phone to get started testing out the new features is to use the web server interface on phone to download and install the latest version from a Polycom hosted server over the Internet.

Enable Web UI

As of the previous version’s 3PIP qualification the phone’s web management user interface is now disabled by default whenever Lync Base Profile is enabled.  In order to access the web interface then it must first be re-enabled from the phone (or remotely via a provisioning server configuration file if desired).

If the web management interface is not currently enabled then it must be turned on temporarily in order to install an update directly from the public Polycom update server.

  • Press the Home key on the phone and then navigate to the following menu: Settings > Advanced (Enter Password)> Administration Settings > Web Server Configuration.
    When prompted to enter a password on the Advanced menu enter the administrator password configured on the phone (the default value is ‘456’).  Also the Web Server Configuration item is located at the bottom of the Administration Settings menu.

Note that the phone’s embedded Web Server is disabled now that Lync Base Profile was activated.


  • Change the Web Server parameter to Enabled and the Web Config Mode parameter to whichever combination of HTTP and HTTPS is desired (e.g. HTTP/HTTPS).


  • Back out and select Save Config which should trigger a reboot of the phone to apply the change.

Upgrade Firmware

Once the phone has completed rebooting the device’s IP address can be retrieved directly from the phone to use for connecting to the web management UI.

  • Press the Home key on the phone and then navigate to the following menu: Settings > Status > Network > TCP/IP Parameters

  • Note the IP address and then connect to that address in a web browser. 

  • Leave the Login As value at the default setting of Admin and then enter the default administrator password of ‘456’. (If Internet Explorer 11 is used then it may be required to add the IP address to the Compatibility View list if getting stuck at this menu.)

  • Browse to the Utilities > Software Upgrade menu and verify that the Server Type is set to Polycom Hosted Server.

  • Select the Check for Updates button to check the hosted server for the available versions.

  • Select the latest version and then confirm the process.


The phone will reboot a couple of times as the upgrade process completes and then will return to the default home screen.  If desired the web management interface can be disabled again to prevent any remote access to the phone.

If the VVX phone was already registered to a Lync Server prior to upgrading (or even downgrading) the firmware then it will retain the cached credentials and automatically sign back in after the final reboot completes the process.

If Better Together over Ethernet (BToE) is used with this phone then make sure to download and install the newest BToE client software release on the workstation.  For the UCS 5.3 release the accompanying 3.0.0 client version must be installed.

New Features

As mentioned before the following is not a complete list of all of the new features but does cover a majority of them, focusing on the most important additions.

Exchange Autodiscover

Gone is the old, manual configuration and in its place is Exchange Autodiscover support.  When signing in with Active Directory user credentials in any of the supported methods the phone will perform the same automatic discovery procedures that most Lync clients and devices support.  (Note that using PIN Authentication does not provide any Exchange connectivity; this is no different than Lync Phone Edition devices.)

Once connected to Exchange this provides not only the same calendar access as before but a host of new features like call logs, visual voice mail, contact integration

Voice Mail

  • Visual Voice Mail has enhanced the messages screen on the phone to now provide entries for each message in addition to options like playing the message on the phone, deleting it, or calling the Exchange Subscriber Access number.



Personal contacts stored in the user’s Exchange mailbox are now accessible by the phone.  These contacts can appear in a contacts list or be returned as part of address book search queries.  If the contact contains a SIP address for a Lync federated user then the presence will also be displayed for that user on the phone.

  • Another new feature is the ability to start a conference call to all contacts in a specific contact group by using the Dial All action.


  • Lync Address Book searches are now real-time and will automatically perform a search and return results as characters are entered into the search field.



One of the biggest improvements in the VVX software is support for Microsoft’s Centralized Conferencing Control Protocol (CCCP) which is the heart of Lync conference control.  Interoperability with this protocol allows for proper click-to-join capabilities with scheduled meetings as well as meeting and roster control functions included directly on the phone.

  • Lync Meetings stored in the user’s calendar can now be joined using the single ‘Join’ button. 


  • Meetings can also be joined directly from the configurable reminder alerts which pop up on the home screen.


While the new Roster is the default view when in a Lync conference a host of additional features are now available through two screens of soft keys.

  • For example the ability to put the conference call on hold or end the call, invite new participants, or issue moderator mute/unmute of all attendees.


  • Additional options include enabling or disabling arrival and departure announcements, locking the conference to prevent new attendees, granting participants access from the lobby  and viewing the Meeting details like the Dial-In Conferencing Number and Conference ID.


These conference calls also work in tandem with the Lync Group Conversation windows when BToE is utilized.

  • Additionally the calendar Reminder Settings can be customized in greater detail to provide for more a meaning experience without simply having to disable them.


Better Together over Ethernet (BToE)

Along with the latest BToE 3.0.0 client software the device can stream HD audio from the paired PC directly to the phone’s speaker or handset.

  • The paired phone can now be selected as the default audio device in Windows, for playback of all system sounds, music, or any audio source.


  • When audio is actively being played to the phone will reflect this on the display, indicated by the ‘PC Audio’ label and the speaker icon on the left side.



A host of features have been added for Boss/Admin relationships including the ability to set custom ring tones, safe transfer support, and distinct icons.

  • A delegate’s phone will also now display their boss icon differently than the other favorites tagged to the home screen to make it easier to tell the two types of contacts apart.


Music On Hold

One of the longest CX parity hold-outs, Music On Hold is finally available on the VVX handsets.  Yet while the Lync Phone Edition feature was not customizable, the VVX handsets can support custom WAV files, up to 1MB in size.

Call Transfers

  • Another welcome addition is the ability to select between either Blind or Consultative as the Default Transfer Type on the phone.  When selecting the Transfer key in a call with a normal press the selected default action will be used, but when long pressed a similar menu will appear to prompt for which action to be used for that specific call transfer.


Acoustic Bubble

A feature exclusive to Polycom and borrowed directly from the video conferencing room solutions this allows the VVX phone to utilize the built-in microphone in tandem with the handset or a headset to completely eliminate any background noises.  This is not traditional noise cancellation but is an adaptive approach to identifying sounds further away than the primary user and removing those sounds completely from the encoded audio stream.

This feature is not enabled by default, but can be turned on by defining the following example provisioning parameters:


Lync Status Screen

Available on the web management UI from the Diagnostics menu the Lync Status screen now includes even more details, divided across the following groups.


DHCP Option 43 Override

Another feature exclusive to the VVX phones is the ability to provide the Lync Certificate Provisioning Server URL via a standard XML configuration file or environments where other Lync phones are not used and either the DHCP parameters are not, or cannot be configured.  This can be beneficial when testing Lync phone deployments in production networks, prior to making any changes to production DHCP services, for example.

New Multi-Key Combinations

  • By pressing and holding the 1, 4, 7 keys all together a new status screen will appear on the phone that quickly displays network information like the phone’s IP and MAC addresses.


To perform a simple factory reset, almost identical to the Lync Phone Edition devices, the * and # keys can now be used.

  • When the phone is initially powered on or rebooted a message will be appear on the display that states “Starting Application, press Cancel to interrupt.

  • Press the Cancel button and then a countdown of 5 seconds will begin.

  • immediately press and hold both the * and # keys and after a few seconds, before the timer reaches zero, a new message should appear that reads “The operation you have requested will erase all user-created data. Do you want to continue?

  • Select Yes to begin the factory reset procedure.  Just as with Lync Phone Edition devices this will only erase all non-factory configuration data stored in the phone, it will not reset the currently installed version of firmware.

Polycom RPP Configuration for Lync

March 25, 2015 by · 5 Comments 

The core Polycom video bridging infrastructure components of the RealPresence Platform (RPP) have recently attained Lync Qualification.  As of the posting of this article the following RPP products qualified for Lync Server 2013 are:

This means that when the DMA and RMX are deployed together and integrated into a Lync 2013 environment then a host of different features and conferencing topologies are supported by both Polycom and Microsoft.  In this recent article the concepts of utilizing a third party MCU to either host all conference attendees or better yet leverage both MCUs by hosting attendees on both the standards-based MCU and the Lync A/V MCU together in a single, cascaded meeting.  This improved workflow, referred to as RealConnect, is discussed in this article by Adam Jacobs.

Regardless of the chosen conferencing scenarios the base integration between Lync Server and the RPP core components is the same.  The latest deployment guide can always be found at the bottom of the Polycom Microsoft partner support page which can be found using this simple URL:


The overall configuration guidance has remained largely unchanged since Lync 2010 was first released.  These third party solutions are integrated using the Trusted Application Pool methodology and the guidance in this previous article is still applicable, with the except of a few changes and improvements over time.

Trusted Application Pools

  • For most installations only one Trusted Application Pool for the entire topology is required.  This pool should be created as a multiple-computer pool so that both the DMA and RMX, as well as any additional DMAs or RMX is resilient deployments are all defined in this same pool.

  • Having a single pool means that only a single Trusted Application needs to be defined.

Note that it is important to understand the difference between single-computer and multiple-computer Trusted Application Pools.  Use of single-computer pool is not recommended as it requires some steps to be duplicated and adds unneeded complexity to an environment which never aids anyone when troubleshooting potential issues.  Utilizing a multiple-computer pool means that all of the Polycom RPP resources are contained in a single grouping and granted the same level of trust throughout the Lync topology


Also important to understand is the difference between the concepts above and having one or more unique Trusted Application Pools.  As mentioned above the default practice is to create one (1) multiple-computer Trusted Application Pool, meaning one pool is defined which contains multiple computer objects.

There is at least one scenario though where more than one Trusted Application Pool should be defined in the topology.  This would be in multiple Lync Pool deployments where (often geographically) separate Lync pools are paired with their own Edge pools.  In the event that there is more than a single Edge pool and also more than a single Polycom RPP deployment in the environment then it is recommended to use separate Trusted Application Pools for each set of RPP components.

In the following example this Lync topology includes two separate sites (East and West) which each contains their own Front End and Edge pools.


The reason for this configuration is that the RMX will utilize the Edge server or pool that is allocated to the Front End Pool that its Trusted Application Pool points.  So in the example above the RMX in the East site would leverage the Edge Server in that site, and the RMX in the West would us its local Edge Server.  If the topology only contains a single Polycom RPP deployment or a single Edge pool then this is not necessary.  Defining just one Trusted Application Pool will be sufficient for all Front End servers in all pools in any site in the entire topology to function correctly as Trusted Application Pools are topology-wide.

Static Routes

One of the steps that is still included in the official guidance covers how to define a static route to send SIP messages from Lync to the trusteed application.

In the new RealConnect workflow this is no longer necessary as all Lync participants will only ever connect to the Lync AVMCU in conference calls and then RMX will automatically connect into the same meeting running on that Lync AVMCU.  Hence there is no need to define a static route, nor a Matching URI in Lync.  If the traditional approach of landing Lync endpoints directly into the RMX is still required (both can be enabled in the same environment) then the static route would still be needed for those calls.

But for RealConnect-only workflows the static route is a thing of the past.

Legacy ICE Configuration Method

In past RMX releases the method of enabling Lync Edge Server connectivity to leverage ICE/STUN/TURN media traversal support has been an optional step which requires only the creation of a basic Lync user account.  That configuration has been superseded by a newer approach which is now a requirement (even if there is no Edge Server in the environment) and uses a n improved design.

The original approach was to simply create a standard Lync-enabled user account and then supply that account’s SIP URI to the RMX (and not to SIP register the RMX directly to an Edge Server which has often been performed mistakenly).  For older versions and comparison’s sake the legacy method is revisited in the following steps.  If using RMX 8.4 or a newer release then do not uses these steps; skip directly to the next section.

  • Create a new AD user account and then enable it in Lync.  the AD account’s username and password fields are irrelevant so they can be anything within company policies.

  • Create a simple, meaningful SIP URI in the same SIP domain name space as what was already defined in the RMX configuration. (e.g


  • Go to the SIP Advanced section on the RMX under the Default IP Network Service properties and select MS from the ICE Environment drop-down menu.  Then enter the name portion of the SIP URI (e.g. rmxice) into the Server User Name field.


  • Go to the SIP Servers section on the RMX under the Default IP Network Services properties and verify that the Server Domain Name field is using the same SIP domain as the Lync account above.


If the SIP domains do not match then it is required to change the Lync account’s SIP URI suffix to the same SIP domain that is already defined on the RMX.  This issue would only be applicable for Lync deployments with more than a single SIP domain defined.

New ICE Configuration Method

The ICE support configuration has now changed to utilize a Trusted Application Endpoint instead of a standard Lync user as shown above.  Also the Service Globally Routable User Agent (GRUU) for the Trusted Application Pool containing the RMX is leveraged, meaning that the new ICE configuration is a two-part setup.

  • In RMX 8.3 or earlier releases only the legacy methodology must be utilized.
  • In the RMX 8.4 release either method can be used s both are supported.
  • In RMX 8.5 and newer only the new method is supported and the legacy method can no longer be used.

Understand that the supportability statements above mean that the existing ICE configuration in a current deployment would need to be modified if the RMX is upgraded to 8.5 or newer.  Also be aware that the ICE configuration is no longer optional.  For the rare Lync deployments which do not contain a functional Edge Server in the deployment this ICE configuration is still required.  The Lync Front End pool will actually support some of the required capabilities when an Edge Server does not exist.

Lync Configuration

Whether the Trusted Application Pool and Trusted Application objects already exist from a previous integration or need to be created for a new integration a third object needs to be created: the Trusted Application Endpoint.  For new configurations simply follow the official deployment guide referenced at the beginning of this article.  If updating an existing configuration use the following cmdlets to determine the desired target application pool to attach the new ednpoint object to.

  • Using the Lync Server Management Shell issue the following Get-CsTrustedApplicationPool cmdlet to identify the required attributes.

Get-CsTrustedApplication | Select-Object identity,ApplicationId | ft


Identify the correct Trusted Application Pool and record the FQDN ( and the Application ID (video).

  • Issue the New-CsTrustedApplicationEndpoint cmdlet to create a new endpoint object in the desired existing pool.  The TrustedApplicationPoolFqdn and ApplicationId parameters must match the values resolved in the previous step.  The SipAddress parameter defines a SIP URI for this new endpoint object and must be a unique value that is not already in use by another Lync user, contact, or service.  Anything unique can be used and in this example a SIP URI of ‘’ is chosen.

New-CsTrustedApplicationEndpoint -TrustedApplicationPoolFqdn
-ApplicationId video -SipAddress

The TrustedApplicationPoolFqdn and ApplicationId parameters must match the values resolved in the previous step.  The SipAddress parameter defines the SIP address for this endpoint object and must be a unique value that is not already in use by another Lync user, contact, or service.

  • Make sure to issue the Enable-CsTopology cmdlet to comment this change to the Lync Topology.


Before leaving the management shell there is one more step to complete.  The target Trusted Application Pool will contain a parameter called the Service GRUU (Global Routable User-Agent URI) which needs to be set in the RMX and DMA. This Service GRUU is not something which can be manually defined in the topology; it is a value that Lync automatically defines when a Trusted Application is added to the topology.

  • Run the following Get-CsTrustedApplication cmdlet to retrieve the Service GRUUs defined in Lync.  Highlight the entire parameter and copy it to the clipboard or save to a text file for later use.

Get-CsTrustedApplication | fl ServiceGruu


Polycom Configuration

Any RPCS/RMX instances deployed in the environment can be updated using the following configuration for ICE support within Lync.

  • Go to the SIP Advanced section on the RMX under the Default IP Network Service properties and select MS from the ICE Environment drop-down menu.  Enter or change the value to use the name portion of the new Trusted Application Endpoint’s SIP URI (e.g. rpp) into the Server User Name field.


  • Go to the SIP Servers section on the RMX under the Default IP Network Services properties and verify that the Server Domain Name field is using the same SIP domain as the Lync account above. This should not need to be changed as it should be in the same SIP domain as the previous ICE Lync account.


Save these changes but defer any reboot request in order to make one final change.

  • Navigate to the Setup > System Configuration > System Configuration menu and in the default MCMS_PARAMETERS_USER view select New Flag.

  • For the New Flag name enter SIP_CONTACT_OVERRIDE_STR and then paste in the Service GRUU value which was saved to the clipboard or a text file in the previous section.


It is important to note that in the RPCS/RMX the “sip:” prefix must be omitted from the Service GRUU value when entered into this system flag.

  • Save these changes and then reboot the system to enable the new configuration.

While the DMA does not actually interact with the Lync Edge Server directly for ICE support the Service GRUU is still utilized for other capabilities and should also be configured using the Service GRUU..

  • Using the DMA web management interface navigate to the Network > External SIP Peers menu.

  • Edit the desired Lync Front-End Pool peer object and then in the editor window switch to the Lync Integration tab.
  • Enable the checkbox for the CsTrustedApplication ServiceGruu setting and then paste the entire Service GRUU into this field. 


It is important to note that in the DMA the “sip:” prefix must be included from the Service GRUU value when entered into this system flag.

Video Interoperability in Skype for Business

January 26, 2015 by · 19 Comments 

With the recently launched Office 365 Summit events Microsoft has started sharing technical details on the various new capabilities which are on the horizon with the future release of Skype for Business Server.  In a previous article this rebranding of Lync to Skype for Business (SfB) was analyzed and explained in an effort to clarify some of the confusion immediately seen after that announcement.

This article will attempt to do the same regarding one of the advertised capabilities coming to the Lync replacement in Skype for Business: Video Interoperability.  As made evident by the unexpected popularity of an earlier article on this same topic for Lync 2013, there is a growing need to understand this space which has actually become more complicated over time, due to the increasing number of applicable solutions and methods coming into the market since then, provided by multiple Microsoft partners and even Microsoft themselves.


Before getting into the new information it would be prudent to start with some baseline understanding of what the generalized term of ‘video interoperability’ actually means.  Depending on the source this could be referring to traditional standards-based conference room solutions communicating with foreign systems, or this could be more of a story about tying together with enterprise and consumer grade applications.  Or both.  Whatever the discussion, it always boils down to figuring out a way to get something old to work with something new or making things foreign to each other find a way to interact successfully.

One additional approach is simply forego interoperability by replacing any incompatible system with new, supported solutions.  This alternative approach is what the Lync Room System product line is intended to address.  Either by reducing the need for interoperability by shifting new purchases toward these native systems, or by figuratively ‘biting the bullet’ and just replacing everything with an LRS solution.  Clearly cost, scale, and time are controlling factors in the ability to even attempt this approach which can look much simpler on paper.  Also this only addresses a company’s own systems and limits their ability to host conferences with partners and customers who may be using different solutions.

Hence the very real and common need for finding a way to protect and leverage any investment in existing systems, while possibly even shifting future expenditures toward a completely Skype-centric view.

Apples to Spaceships

There have always been a fair share of challenges in providing a bridge between the Microsoft UC platform world and the massive in-place deployment of the world’s standards-based conferencing solutions.  Much of that complexity has to do with the wide array of communication paths (e.g. signaling, audio, video, content) and the large gap in design methodology between each.  The popular fruit-based idiom just does not ring true in this scenario even if though both sides are trying to share the same sources of data: a person’s face, their voice, a spreadsheet, or presentation deck.  It is the delivery mechanisms which can be quite different in design and application to where neither can be equated with being from the same food group, much less even both be considered foods. 

The shear growth in adoption of Microsoft’s Commutations Server platform over time has driven multiple partners to provide a varying array of solutions from value-add devices to complete endpoints to core infrastructure.

Also understand that any references to H.264 Scalable Video Coding (SVC) in this article infers Microsoft’s specific implementation of the codec, advertised as X-H264UC, which is not directly compatible with H.264 SVC that some standards-based video systems support today.

Lync to Skype

Simply rebranding the enterprise solution is not enough to make it and the existing consumer platform play nice together.  Microsoft has already been working on addressing how to bring together existing Skype consumer clients with the Lync enterprise deployment base.  Renaming the enterprise platform the same as the consumer platform may look like the first step down that path, but in reality much work has already gone on in the background starting over one year ago, as covered in this article

In place today is the version 2 Skype Gateway architecture which provides for direct media traversal between Skype consumer Windows desktop clients and Lync 2013 clients.  This same solution will be applicable to Skype for Business clients when that product is released.  Basically the Lync 2013 clients have received SILK audio support via a past Cumulative update, and the latest Skype consumer client for Windows include support for both the H.264 SVC video codec and media relay utilizing the Lync Edge Server.

This Business to Consumer (B2C) concept has been discussed in various past articles amongst the community, so for now the focus of this article will be on the various enterprise-grade options for Business to Business (B2B) needs.

Enterprise Video Interoperability

As captured in this category of articles there are already a variety of third-party solutions available to address this which have been around since the early days of the Communications Server platform.  These options range from basic signaling gateways or more powerful transcoding gateways with limited scalability all the way through full suites of conferencing bridges and signaling servers which can either host the entire conference itself or join an existing Lync conference.

The four available methodologies for addressing these needs can be summarized as:

  • Native Endpoint Registration
  • Gateways
  • Multipoint Control Unit
  • Bridge Cascading

Native Endpoint Registration

As the name suggests, this means that no back-end interoperability solution is used.  The Lync or Skype for Business environment is used as the sole conferencing engine and all endpoints (software clients and hardware devices) will connect directly and natively to these environments wherever they may reside.


Note that in this diagram the ‘Desktop Client’ could be any variety of past or future Microsoft UC clients: Office Communicator 2007, Lync 2010, Lync 2013, or the upcoming Skype for Business client.  These clients all support a range of compatible audio and video codecs, with varying support for both RealTime Video (RTV) and H.264 SVC.  For example, while the Lync 2013 and SfB clients will support both RTV and SVC, the Lync 2010 and older clients only support RTV.  When hosting conferencing on a Lync 2013 or Skype for Business platform which either may contain older desktop clients or (more realistically) be inviting federated or foreign attendees who may still be running older Lync or Communicator client versions then it is important for the room system solutions in these environments to also support the older RTV codec so that all participants in the meeting can be seen and heard by all attendees regardless of their versions.

A few different options are available today to either provide a plug-and-play experience to users or deploy a dedicated conferencing room system that can talk directly to the Skype for Business or Lync platform.  The Microsoft Lync Catalog currently lists all of the qualified Meeting Room Device and Solutions.  Some of these systems support native registration to on-premises services only, while other may be also able to connect directly to Microsoft’s Office 365 offering, or even other hosting provider’s clouds.

  1. Desktop Clients: Provide one of the various qualified Lync video conferencing devices which connect to a Windows desktop to provide an enhanced in-room audio and video experience without the need for a dedicated endpoint.  Users will bring their own workstation, connect via USB to one of these systems, and then drive the meeting from their own Lync client using their own identity.  This is the least expensive option and only requires deployment of something like the Logitech CC3000e or Polycom CX5500.

  2. Lync Room Systems: To eliminate the need to bring any workstations into the conference room as well as improve the audio and video experience then a completely native and permanent solution is deployed into the conferencing like a Lync Room System (LRS) package available from Crestron, Polycom, or Smart.  These systems are back-ended by a hardened Windows-embedded PC which communications directly with an on-premises or hosted Lync or Skype for Business environment.  Also new in this space is the recently announced Microsoft Surface Hub platform which can serve as a low-end LRS-like package to easily bring a conferencing experience to any wall with basic audio and video capabilities served by an integrated microphone and camera. (Note that the Surface Hub does not run the LRS client and is a completely new design based solely on Windows 10 and the Surface touch experience.)

  3. Qualified Room Systems: To move even further beyond the current Lync or Skype for Business specific solutions a modern standards-based room system can be deployed which support native Lync and Skype for Business communications protocols and codecs.  Partners in this space have included in their standards-based systems additional support for varying levels of the multiple protocols and codecs like Microsoft’s implementation of SIP and H.264 SVC, RTV, or the Centralized Conference Control Protocol (CCCP) to name just a few.  Examples of these room solutions are the LifeSize 220 or Polycom HDX & Group Series.

Any other conferencing solutions outside of these categories are simply not invited to the party and would require some assistance from a additional solution to bridge the communications barrier.

Microsoft generically refers to these legacy standards-based conference room systems which do not contain any embedded Lync interoperability as a Video TeleConferencing system, or VTC.  Throughout this article the term VTC will continue to refer to these types of systems, which must utilize one of the following solutions in order to have any chance of participating in meetings with any Lync or Skype for Business users.


The first, and most basic method to address the issue would be to use gateways to provide an access route for various unsupported room systems to reach the Lync/SfB world.  Conferences and peer call control is still owned by the Lync/SfB environment, but a transcoding and/or signaling gateway can offer a path for a limited number of systems to communicate with the Lync clients and servers, often with only a subset of the available modalities and features.  In short these solutions may either only support audio and video with no content sharing capabilities across all platforms, or may be limited to internally connected systems with no Edge media traversal compatibility.


In this diagram the foreign VTC is registered via H.323 or SIP either directly to a video gateway or is registered to their own native environment which includes a gateway configured to route traffic between to and the Lync environment.  The gateway will translate the different signaling protocols, for example between H.323 and Microsoft SIP.  Some gateways are even capable of further transcoding the audio and video codecs, like Microsoft’s X-H264UC implementation of H.264 SVC against H.264 AVC.

The diagram shows a simple environment of one VTC behind a single gateway, but imagine that the environment within the dotted grey box could be as vast as multiple endpoints connected to a complete video infrastructure behind pools of multiple gateways which are then connected to the Microsoft environment.

Examples of endpoints which fit into the VTC category would be any array of Cisco’s older Tandberg H.323 or SIP endpoints or their TelePresence solutions, some LifeSize systems, older Polycom VSX endpoints, and even ISDN video systems just to name a few.

Examples of the video gateways would be the Cisco VCS or Radvision Scopia. Note that this category has been the least active over the past few years as solutions have matured into one of the next methodologies..  Cisco’s VCS solution has received some updates for Lync 2013 video interoperability in the past year but this solution has never been included among the Lync qualified solutions.  While vendor support is available from Cisco this is not a solution seen actually deployed that often in the field.  Also the Radvision Scopia gateway was last qualified for Lync 2010 and has not seen any updates to support H.264 SVC as implemented in Lync 2013.

The topic of gateways will be revisited in the second-half of this article as Microsoft will will utilizing this methodology with Skype for Business server.

Multipoint Control Unit (MCU)

The simplicity of the first scenario is also its most limiting factor.  As mentioned before, what about the cost of simply replacing the large of amount of functional systems out there in use today? Or deploying and managing a large number of gateways, thus further complicating the environment and communication paths?  One alternative here is to utilize a standards-based conferencing solution which can deal with the plethora of non-Lync standards in existence today, and then provide a path for the Lync users to also reach this same conference.  Lync and SfB users simply call into these meetings which are hosted on the standards-based MCU, also referred to as bridges, providing a single meeting place that can bring everyone together.  These separate bridges are the virtual location where everyone calls into to hear and see each other.


Conferences in this scenario are hosted on the standards-based side of the fence so all clients must negotiate their media sessions directly, or indirectly with the assistance of an Edge Server if supported by the third party solution.  The call signaling path is still native for endpoints on both sides, but SIP messages are routed out of the Front End Server to the integrated standards-based system.  This means that conferences held in this manner, although technically able to handle audio, video and possibly some content sharing, are not utilizing any of the Front End server’s conferencing capabilities. A varying degree of native Lync and Skype for Business capabilities may not be available to those users, depending on which third party vendor’s solution is deployed.

Because each and every Lync client must directly connect to the third party bridge then vendors must test and support every type of Microsoft client available in the Lync and Skype for Business platforms.  Most vendors only support a subset of these clients across different versions, and even then only some codecs and modalities among those.  This means that conferences may not be able to provide the same level of results to all types, with the mobile and Mac clients traditionally lagging behind in support.

Examples of some third party vendors which support this model today are Acano, BlueJeans, Fuze, Pexip, and Polycom.  Note that currently the only Lync Qualified solution among these is the Polycom RealPresence Platform, comprised of the RMX and DMA components.

Bridge Cascading

Every one of the scenarios above are really just a combination of compromises in the end as while each may contain some measurable advantages over the other the overall architectures is not ideal.  The best single solution is to not have a single solution, but to use both environments as originally intended and then just connect them to each other.  This approach leverages the strengths of both platforms and retains the native user experiences on both sides.


In this topology the standards-based MCU is connected directly to the Lync AVMCU during any meetings allowing endpoints on either side of the table to join the same, cascaded conference with all participants able to see and hear any active speakers, and in some cases even multiple video steams in one direction or the other.

Examples of third party solutions which support this model today are Acano CoSpace, Pexip Infinity, and Polycom RealConnect.  While each of these solutions leverage both MCUs in a single meeting there are varying amounts of capabilities related to the mechanics behind them, the manner in which participants join meetings, the amount of video streams, and the list of supported codecs.

One of the single biggest advantages of this model is that it leaves all of the Lync clients completely on their side of the map, unlike the previous approach which forces them to connect directly to the third party MCU.  While the initial gateway approach utilizes the Lync MCU for all conferencing attendees that environment is limited to what those gateways can bring in, which often is not very much in terms of types and amounts of VTCs.

Other major advantages of this architecture is that the entire conference is native to both side. For example, capabilities unique to RealConnect are that scheduling meetings is done within Outlook using the standard Lync Meeting invitations.  Joining meetings is the same for all, clicking an embedded link (for desktop users) or dialing a Conference Id (for audio attendees and room video systems).  Secondly bidirectional, transcoded content sharing is made available to all parties on either side when either a Lync or SfB participants is sharing their desktop or if a VTC is sending some sort of H.239 or BFCP content stream.

Video Interoperability Server

The various options covered above are great for supplying a full conferencing environment which addresses a multitude of real-world requirements and issues.  But what about the smaller environments where maybe only a handful of legacy room systems are deployed but cannot simply be replaced with new systems, nor is deploying additional infrastructure (physical or virtual) in the cards.  If additional costs or management worries have traditionally meant that the third-party back-end solutions have just been not viable options, then in traditional Microsoft fashion a basic solution is now about to be embedded natively into the product.

Just as Microsoft has incorporated capabilities into the Communications Server platform along the way, like an XMPP Gateway for example, the upcoming releases of the Communications Server platform Microsoft has positioned Skype for Business Server to address both consumer client B2C scenarios and standards-based interoperability for B2B video-based communications.

B2C video support for Skype consumer clients has already been delivered by incorporating changes into the Lync 2013 client and server platform late last year to allow for peer-to-peer video calls between Lync 2013 users and Skype consumer Windows desktop users.

The B2B scenario is also being addressed natively, for the first time within the product itself, by leveraging a new server role available with on-premises deployments of the upcoming Skype for Business Server platform.  This software release will contain a new server role available to define the topology and deploy called the Video Interoperability Server (VIS).

Fellow Lync MVP Adam Jacobs posted an article introducing VIS nearly a year ago, just after the 2014 Lync Conference was held in Las Vegas.  That article discusses this gateway concept of a Back-to-Back User Agent (B2BUA) with what was publically known about VIS at the time.  He has also just posted a follow-up article touching on both the Skype consumer capability as well as VIS.  With the recent release of the latest content from the Summit events there are now more public details on VIS in terms of the supported topology and endpoints.  The first takeaway from reviewing the information is that the capabilities are a smaller subset of what was originally advertised.


VIS is available only as a separate server role, and will not be offered as a collocated Front End server role, unlike the Mediation Server role.  This means that additional physical or virtual Skype for Business servers will need to be deployed into one or more scaled VIS pools.  Also note that Microsoft has stated that the role is only available to on-premises and Hybrid deployments, meaning an on-premises pool will need to be deployed and is not available as a feature for Office 365-only customers.

The initial offering of VIS will support a single Operating Mode entitled SIP Trunk Mode, which could be equated to what the Mediation Server role does for audio calling between Lync and IP-PBX platforms by virtue of establishing SIP trunks between them, but now for both audio and video.  Basically this new server role acts as a gateway between the Skype for Business servers/clients and some sort of foreign video signaling server. 


VIS supports a 1:N topology in that a single VIS pool can be configured to communicate with multiple different video signaling gateways.  Meanwhile any one video signaling server can only be connected to a single VIS pool.

The only supported environment at product launch will require that VIS be connected to a Cisco Unified Communications Manager (CUCM or CallManager) deployment which in turn includes one or more of a specific list of tested and supported Cisco VTC models.  Note that there is no support here for the Cisco Video Communications Server (VCS) which is more commonly found in currently deployed video environment.  Cisco appears to be moving away from the legacy VCS platform by supporting video signaling in CUCM and Microsoft has chose to go the same route with VIS support.


The supported VTC endpoints listed at the time this article was written are as follows:

  • Cisco TelePresence Codecs (C40, C60, C90)
  • Cisco TelePresence MX Series (MX200, MX300)
  • Cisco TelePresence EX Series (EX60, EX90)
  • Cisco TelePresence SX Series (SX20)

Microsoft has stated that additional models which can support Cisco TelePresence System codec software version 7 or newer (TC7.0.0) may be tested after the initial Skype for Business Server release and then added to the UC Open Interoperability Program for VTCs.

The most obvious thing about VIS at this point should be that it appears to be a Microsoft-provided Cisco gateway.  There is no mention of other third party VTC manufacturer involvement in this program to date. There are a variety of reasons for that, one being that some partners which were focused on video compatibility with Office Communications Server and Lync Server in the past have fallen off the radar.  For example Radvision’s gateway solution for Lync has not shown any activity in the qualification space since their purchase by Avaya.  LifeSize has also not stayed up to date in the qualification program, as well as bowing out of the Lync Room System program last year.  Most of the newer names in this space, like Acano or Pexip, are providing gateway and bridge solutions and do not provide any compatible endpoints. 

Also clearly missing from the list above are any Polycom room systems.  As covered in this variety of articles or in this blog post from another Lync MVP Brennon Kwok it should be clear that the last two generations of Polycom room systems support native Lync registration including a wide variety of features, much beyond what VIS can offer.  So it would be a step backwards to attempt to utilize VIS as a gateway for the HDX and Group Series room systems instead of just using their native registration capabilities to fit into that first scenario near the beginning of this article.

Multiparty Architecture

VIS will provide connectivity for supported VTCs to both clients and servers.  The previous diagram shows the signaling and media flow for a conference hosted on the SfB Front End server by the collocated AVMCU service.  VIS is used to proxy the connection and media for VTCs so they can participate directly in the meeting.  In the SIP Trunk mode each VTC remains registered to the CUCM infrastructure and then can place calls through CUCM, to the VIS pool, and then on to the Skype for Business Front End pool’s Conference Auto Attendant.  There is no drag-and-drop support so SfB users cannot locate a specific VTC and simply drag it into a peer or conference call in an attempt to invite the VTC to the meeting.  The VTC must call into the meeting manually by the conference room attendees.

Once in the meeting only a single active video participant can be sent to/from the VTC via VIS, and there is no support for content sharing thus far.  This means that the experience from inside the conference room will look a lot like the following image.  The Skype for Business and Lync users will receive multiple video participants via the Gallery View in addition to content shared by another desktop client, the same as they would in any normal meeting.  Yet when the VTC joins the meeting the attendee will only see the active speaker and will also not receive any of the shared content.


Compare the room system and desktop user experience above, as provided by VIS with what a third-party solution like bridge cascading can provide because they can support multiple streams and content.  For example the capabilities of Polycom RealConnect are depicted below which includes bi-directional content sharing and multiple active speaker video participants from Lync appearing on the VTC.


Simulcast Transcoding

Microsoft’s implementation of H.264 SVC provides multiple simulcast video streams in multiparty conference calls.  While Lync 2013 and SfB clients are programmed to send (when requested) these additional streams directly to the Front End server, the legacy VTCs do not have this capability.  (Note that native endpoints like LRS and the Polycom Group Series do support these simulcast streams).

In order to retain the flexibility to fulfill different video resolution and frame rate requests across various clients the Front End Server AVMCU needs this to be addressed by VIS.  The way this works is that VIS acts as a media transcoding gateway, not just a basic signaling gateway.

The VTC will negotiate an outbound video stream directly to VIS at a specific resolution and frame rate .  If the Front End Server AVMCU has any client requests for differing, lower resolutions or frame rates it will then request one or two additional streams.  Because the VTC can not provide these additional streams then VIS must create them.  VIS itself will transcode and send to the AVMCU up to a maximum of three different video streams, all derived from the single, original stream send by the VTC.


The example above shows a VTC joining a meeting with 3 other Skype for Business endpoints of varying hardware capabilities and conference views.  The VTC in this case happens to negotiate and encode a 720p video stream at 30 frames per second to VIS.

  1. VIS repackages the original H.264 AVC stream into an SVC session understood by the AVMCU which in turn relays it to the laptop participant who happens to have ‘Speaker View’ enabled and thus is requesting full screen high definition video at the full 30 fps.

  2. VIS will transcode a second stream, downscaling the resolution to 360p as requested by the desktop client which has the default ‘Gallery View’ enabled.
  3. VIS will also transcode as third stream, downscaling the provided video even further to supply a 180p stream at only 15fps for the mobile device in the conference.

All three of the above streams are simulcast from VIS directly to the AVMCU.  If any attendees change the way that video is viewed during the call, leave the meeting, or new participants join then the AVMCU will adjust the requests to VIS in the event that one or more of the additional simulcast streams is no longer required.

VIS must perform this work as the legacy VTCs do not support this capability.  For this reason a single VIS server can only support up to a few VTCs simultaneously in a single environment, thus multiple server nodes and even multiple pools may be required to support the transcoding demand which may exist in a specific environment.

One important limitation of this design is that VIS can only transcode H.264 SVC video streams to and from the Skype for Business side of the equation.  It does not support transcoding RTV so only Lync 2013 and SfB clients, or any other native device which supports the H.264 SVC implementation in Lync/Skype will be applicable.  If a Lync 2010 or Office Communicator client were to join this conference call they would still see the other native participants, who are capable of sending a second RTV stream during the meeting for legacy clients.  That additional RTV stream is not sent on to VIS though as it does not support it transcoding it, so that means the VTC will not be able to see the 2010 client’s video and the 2010 client will not see the VTCs video.

An additional limitation is that VIS cannot leverage Edge for media traversal between itself and the VTC environment because the legacy VTCs contain no built-in support for ICE/STUN/TURN as implemented in Skype for Business Server.  This means that both CUCM and all VTCs must have the ability to communicate directly with the VIS pool without traversing any network address translation (NAT).  The VIS pool does communicate with the Edge server on its SfB-facing side though to establish media sessions with any external or federated Lync and Skype for Business clients, so the imitation is only placed on the VTC side of the network.

Peer to Peer Calling

Peer-to-peer (P2P) calls between the VTCs and other registered Skype for Business or Lync 2013 clients are also supported, although in the initial release only calls placed by a VTC to a SfB user is supported.  SfB users cannot call a VTC.

And just as described in the meeting scenario VIS does not support transcoding of RTV so only Lync 2013 clients, Skype for Business clients, or any qualified system which supports Microsoft H.264 SVC can participate in peer calls with supported VTCs.


While VIS does not need to supply additional simulcast streams in a simple two-party call it must still perform some basic transcoding to translate the standards-based H.264 AVC stream sent by the VTC into a n X-H264UC compatible SVC stream that the Lync 2013 or newer clients require for interoperability.


One of the points of this article is to explain not only what VIS is, but also what VIS is not (or at least is not yet).

It does not offer any native capabilities in Skype for Business server to bridge its clients with the vast array of H.323 based conferencing systems, as SIP-only endpoints registered to CUCM is the single supported topology for now.  For environments moving in that direction then VIS can provide some capabilities for cross-platform conferences, but it is clear that Microsoft partners providing video interoperability solutions for many years now provide solution sets far beyond the capabilities of VIS, today  But as Skype for Business matures one might expect to see additional features and capabilities coming to the platform which will help close some of the gaps.  In the meantime, or for the foreseeable future going with a complete end-to-end solution like bridge cascading is one of the ways to finally bring together desktop users and conference rooms in a user experience that is easy to schedule, simple to join, and familiar to all.

January 2015 Lync Users Group

January 16, 2015 by · 1 Comment 

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


Event Details

This meeting will be conducted in our familiar two-session format:

The first session presented by Enghouse Interactive will cover Contact Center solutions for Lync.

The second session presented by a local subject matter expert will discuss the announcement of, as well as provide an update on Skype for Business Server.

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

Our ever-growing LUG family has adopted two new regions this quarter in Baltimore and Kansas City.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.


For a full schedule of regional events the Lync Users Group Locations page lists all planned event locations with links to the associated page for each regional group.  For current members if your region’s event is not yet scheduled just make sure that your notification options are configured so that you’ll get an alert when the new event is posted.  For anyone who is not yet a member and would like to participate simply create a new Meetup account (or use an existing one) and join your local group.

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, January 20th
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago UC Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200 
Chicago, IL 60601

Announcing Skype for Business

November 11, 2014 by · 22 Comments 


Just this morning Microsoft has announced, by way of Twitter and new posts on the Office and Skype blogs that the Lync Server product will be rebranded as Skype for Business.

Microsoft’s Corporate Vice President for Skype, Gurdeep Singh Pall, released the following message to Twitter coinciding with the official blog articles confirming the hunches of many in the industry on how Microsoft would ultimately tie the Lync and Skype products even more closely together.


The articles do not go into much detail at all about exactly what is happening, outside of some semblance of a rebranding but a closer look at some of the statements do point to a few important items.

In the first half of 2015, the next version of Lync will become Skype for Business with a new client experience, new server release and updates to the service in Office 365.

This basically means that the next on-premises server, clients, and Office 365 releases of what would be Lync will now simply be renamed, and the Lync name will be apparently be deemphasized.  Surely this does not mean that the existing consumer Skype platform would be positioned to businesses, or mean the death of Lync as a platform.  For all intents and purposes the two separate products must still exist : the consumer ad-driven solution known as Skype, and the enterprise-grade solution known to all as Lync which will simply be rebranded as Skype for Business.

Many enterprises will continue to run on Lync 2010 and 2013 platforms if they have just upgraded and moving to the next platform may be far off for them, while others will be excited to start evaluating the next release to see if it is a candidate for them to warrant upgrading to.

And speaking of upgrades the following statement seems to validate the rumors that in-place upgrades will be supported in the next server release cycle.

Current Lync Server customers will be able to take advantage of these capabilities simply by updating from Lync Server 2013 to the new Skype for Business Server in their datacenters. No new hardware is required.

Ultimately this rebranding fits a pattern that the product has had since it was first rolled out as Live Communications Server  (LCS) 2003 and then 2005.  It was brought into the Office collective by name as Office Communications Server for the next two releases (2007 and 2007 R2), followed by two more release cycles rebranded as Lync 2010 and 2013.   So this is not a surprise at all given the history of the product.

Furthermore a redesign of the Windows client has also occurred in the past three release cycles (Office Communicator 2007, Lync 2010, and Lync 2013) so this change also comes as no surprise.  A closer look at the Windows client shows that while the design borrows the color scheme and icons from Skype, the layout and function is still most definitely Lync at its core.


On a personal note I have known about this rebranding for quite some time and have already gone through the five stages of loss and grief that the rest of the technical community will undoubtedly be experiencing starting today.

  1. Denial – “Well that’s a silly idea, so clearly they will come to their senses.”
  2. Anger – “Stop changing the name already! People just became comfortable with Lync.”
  3. Bargaining – “ Look, how about using the Skype client with the Lync server, akin to Exchange and Outlook”"?”
  4. Depression – “Well, forget this. I’m going to stop blogging about the product and join a monastery.”
  5. Acceptance – “OK, I suppose it’s not the end of the world.  There might be some upside here.”

It will be confusing for a bit as the lines are blurred between the consumer and enterprise products, but in the end the user community (and not necessarily IT administrative staff) should benefit the most.  Imagine an employee, already comfortable with operating the Skype client on their personal computer and devices, seeing this familiar interface on their corporate workstation and devices, both handheld and in conference rooms?  Nearly 5 years ago there was roughly the same initial reaction to the new Lync rebranding of OCS and the product itself clearly won over many fans in the years to come.  On the upside at least I won’t have to hear anyone calling it ‘Lynx’ anymore. :)

Next Page »