Skype for Business Server 2015 Deployment – Part 2

June 19, 2015 by · 3 Comments 

Continuing from a previous post this article moves into the installation and configuration of the Skype for Business Server components for a Standard Edition Front End server.  As with the previous article any mandatory steps are identified by bulleted paragraphs while non-indented steps for validation and educational purposes are optional.


The second article in this series will cover the following deployment steps:

  • Defining the Topology
  • Deploying the Server Components
  • Verifying the Installation

Before performing these steps in this article make sure to successfully complete all of the prerequisite actions covered in Part 1 of this series.

Define Topology

Before installing any additional server components the Skype for Business topology must be defined.


Create New Topology

  • Launch the Skype for Business Server 2015 Topology Builder and then select New Topology.


    • Save a new .tbxml file with any desired name (e.g. 06072015.tbxml).

    • For the Primary SIP domain enter the desired domain namespace (e.g.

Add any additional desired SIP domains at this point , but a single SIP domain is sufficient for most deployments as well as this series of articles.

  • Select a Name for the first site to be created in the topology (e.g. Lab) and enter a Description if desired.

  • Specify the locality information associated with the first site and then complete the wizard.

At this point the Define New Front End Pool wizard should be automatically launched.

    • On the Define Front End Pool FQDN page select Standard Edition Server and then enter the Fully Qualified Domain Name (FQDN) of the Windows domain member server where the SFB prerequisites were installed (e.g.


  • Select the features which should be installed and enabled on this Front End server.  Later articles will cover the deployment of some of these additional features.


    • Retain the default enabled setting of Collocate Mediation Server on the Select Collocated Server Roles page.

    • On the Associate Server Roles with this Front End Pool page leave the option blank as an Edge Server does not yet exist.  This setting will be addressed when an Edge Server is deployed in a later article.

    • As this is a Standard Edition server then there will be no configurable options available on the Define the SQL Store page.  Take note of the automatically defined SQL Server store which is comprised of the server’s FQDN ( followed by the previously installed SQL Express instance name (RTC).


  • On the Define a File Store page enter the name of the Windows file share created in the previous section (e.g. SFBShare).


  • On the Specify the Web Services URL page the External Base URL will automatically be set to the same FQDN as the internal Front End server (e.g.  For the purposes of this article the default setting will be retained and in the future when external services are published this will be updated to reflect the external namespace.

  • The next page Select an Office Web Apps Server is new to Lync Server 2013 and is used to either define a new OWAS pool FQDN or associate this server with an existing OWAS pool.  As a later article will cover deploying OWAS simply uncheck this option and then click Finish to complete the wizard.  (Note that until this server is deployed that PowerPoint content sharing will be unavailable in Lync conferences as this is no longer performed by the Front End server.)

    Upon completion the Topology Builder window should refresh and the defined settings will be populated as shown.


    • Back at the main Topology Builder window select Edit Properties on the Lync Server root-level object.  Highlight the Simple URLs section and enter the desired Administrative Access URL (e.g.  Technically his is an optional step as the administrative access URL is not required, but is a convenient way to access the Server Control Panel via a web browser internally.

    • Move down to the Central Management Server section and select the new Front End server (e.g. as the location to install the CMS component on.


Publish Topology

The final process is to publish the changes made to the topology into the Central Management Server database which also updates information in the RTC services container in Active Directory and sets up the folder structure and permissions on the file share.

  • From the Action menu select Publish Topology.  The local server FQDN for the Central Management Store location should already be populated in the drop-down menu due to the previous step.  If all configuration steps were performed correctly then the wizard should complete without any errors or warnings.


Deploy Server

Unlike most other Microsoft server platform products were installation of the actual server components is one of the very first steps, the Communications Server family has historically been different.  The server installation itself is quite hands-off and can be automated to a large degree.  The fair amount of activity up until this point has been geared around providing the backend components to store the overall configuration of the environment, which is now available for use by the server installation steps.


Install Skype for Business Server Components

The next step is to install a second SQL Express named instance called RTCLOCAL on the local server which will contain a replica of the existing RTC named instance.

Only the first Standard Edition server in the organization would contain the authoritative RTC instance installed in the previous article, while all other Front End Servers (and even Edge Servers) would contain their own RTCLOCAL instance to replicate the Central Management Store data.

As the Administrative Tools have already been installed on the server then the Skype for Business Server Deployment Wizard can be found in the Start Menu on the local server.  The installation media is no longer required as the installation files have been copied to the server.

  • On the Windows Start Menu search for ‘Deploy’ to locate and launch the Skype for Business Server Deployment Wizard.  From the main menu select Install or Update Skype for Business Server System.

  • On Step 1: Install Local Configuration Store select Run and leave the default setting of Retrieve the configuration data directly from the Central Management Store and complete the wizard.


Reviewing the results in the execution window should confirm that the second SQL Express instance of RTCLOCAL was installed as well as the core SFB Server components.

Checking prerequisite SupportedOSNoDC…prerequisite satisfied.
Checking prerequisite DotNet35…prerequisite satisfied.
Checking prerequisite SupportedSqlRtcLocal…prerequisite satisfied.
Checking prerequisite WMIEnabled…prerequisite satisfied.
Checking prerequisite NoOtherVersionInstalled…prerequisite satisfied.
Checking prerequisite PowerShell…prerequisite satisfied.
Checking prerequisite SqlUpgradeInstanceRtcLocal…prerequisite satisfied.

Secondly the Local CMS replica was instantiated by importing the configuration from the existing CMS database an then replicating the database data itself.

Import-CSConfiguration -FileName "C:\Users\ADMINI~1.JDS\AppData\Local\Temp\2\" -Verbose -LocalStore

> Enable local replica service

Enable-CSReplica -Verbose -Confirm:$false -Report "C:\Users\administrator.JDSKYPE\AppData\Local\Temp\2\Enable-CSReplica-[2015_06_08][13_17_14].html"

Additionally the replication of any certificates stored in the CMS is performed.  Although no certificates have been installed yet for this deployment had there been one then this action would have replicated any existing OAuthcertificates required for server to server MTLS communications.

> Replicate-CsCmsCertificates

Logging status to: C:\Users\administrator.JDSKYPE\AppData\Local\Temp\2\ReplicateCMSCertificates-[2015_06_08][13_17_14].html

To confirm the installation location of the RTCLOCAL database files on the server check the default SQL Server installation directory for the existence of the xds files.

%ProgramFiles%\Microsoft SQL Server\MSSQL12.RTCLOCAL\MSSQL\DATA


    • On the Skype for Business Server Deployment Wizard advance to Step 2: Setup or Remove Skype for Business Server Components and click Run to start the Set Up Lync server Components wizard.

Once again the Bootstrapper application will execute and perform a prerequisite check before installing additional components.  These include a third SQL instance called LyncLocal and additional Windows Speech components and foreign language packs.

Checking prerequisite KB2858668Installed…prerequisite satisfied.
Installing vcredist_11_x64.exe(/Q)…success
Installing WindowsFabric\v3\WindowsFabric.msi( REBOOT=ReallySuppress STARTUPTYPE=demand REMOVEDATA=yes IACCEPTEULA=yes TESTMODESKIPPREREQUISITECHECK=yes)…success
Installing MicrosoftIdentityExtensions.msi( REBOOT=ReallySuppress ALLUSERS=1)…success
Checking prerequisite SqlUpgradeInstanceLyncLocal…prerequisite satisfied.

Immediately following will be the installation of the Lync server components which make up the different services and roles on the Front End server (e.g. AVMCU, Mediation Server).


Verify that the installation task status was reported as successfully completed.


Create Default Server Certificate

Returning to the server deployment process the next step is to request and assign server certificates so that the Lync services can be started.

    • Run Step 3: Request, Install or Assign Certificates and then expand the Default Certificate entry to verify that all roles are checked.  Click Request to start the Certificate Request wizard.


  • Populate the desired information making sure to select the SIP domain to add the sip.<sipdomain> record to the certificate.


The Friendly Name can be set to anything and is not actually part of the certificate request, it can even be changed after the certificate is returned and imported.  Note that although Lyncdiscover.<sipdomain> was not defined as an internal DNS record in the previous article the certificate wizard still includes this FQDN as a requirement for external support.

  • Submit the request to the online certificate authority and when the task completes successfully select the View Certificate Details button to validate the certificate status and that a private key was correctly associated.


  • Advance to the next wizard to perform the Certificate Assignment task.  In the event that the role assignment is accidentally lost between the request and assignment wizards then the assignment task might fail with an error that a Type has not been provided.  If that occurs simply cancel out of the wizard and return to the main wizard screen.  On the Certificate Wizard main screen If the checkboxes to the left of the Server Default, Web Service Internal, and Web Service External roles are no longer selected then reselect them and click Assign.

  • Verify that the proper certificate is highlighted (in the event that this server already has any other server certificates installed on it) and then complete the wizard, verifying that the task status is reported as Completed.


  • Back at the Certificate Wizard main screen the new certificate should now be listed on each of the three Default Certificate roles.


Create OAuth Certificate

As this is the first SfB server deployed into the environment then a new OAuth certificate needs to be created as well.  This is a one-time process as this certificate will be shared by any other SfB server which may be later installed.

  • On the Certificate Wizard main screen select the OAuthTokenIssuer role and then click Request.


  • Enter a descriptive Friendly Name and then submit the certificate request.


  • Advance through the assignment wizard to finish the OAuth certificate configuration in the same fashion as performed for the server certificate.

Start Services

In previous releases the services could be started directly from the deployment wizard as part of Step 4: Start Services.  With the addition of a new PowerShell cmdlet in SFB this task is now a manual one.  While SfB Server now includes a new cmdlet called Start-CsPool this is only intended for use with multiple node Enterprise Edition pools.  When dealing with a single server in a pool or a Standard Edition server as in this article then the previous guidance of using the CsWindowsService cmdlets still holds true.

  • Launch the Skype for Business Server Management Shell and execute the following Start-CsWindowsService cmdlet.



To validate the server status the Get-CsWindowsService cmdlet can be issued to list the individual SfB services.



Verify Topology

Utilizing the Skype for Business Server 2015 Control Panel the basic functionality of the new deployment can begun to be tested.


Before opening the Skype for Business Server 2015 Control Panel, just as with previous Lync Server releases, it is helpful to configure the local server’s Internet Options to bypass the the prompt for credentials whenever the tool is launched.

  • Open Internet Options, navigate to the Security tab, select Local Internet and click Sites, then click Advanced.

  • Enter the local server’s FQDN as a URL (e.g. and then save the changes.


  • If Silverlight is not already installed on the server than the Control Panel will report this fact.


  • Use the provided link to immediately download and install Silverlight on the local server.


  • Once the installation is complete the Home page of the control panel will be displayed.  Select the Topology menu and verify that the new server is listed and the Status and Replication fields are healthy.




With the conclusion of this article a functional Skype for Business Server should now be deployed and is ready for further configuration.  The next article in the series will cover enabling user accounts for clients and devices to leverage.

Skype for Business Server 2015 Deployment – Part 1

June 19, 2015 by · 1 Comment 

Similar to past articles this series of basic deployment articles will be used to capture a specific environment to also be used as the foundation for many Skype for Business (SfB) Server 2015 specific deployment articles.  Starting with a single Standard Edition Skype for Business Server in a fresh Active Directory forest future articles will build on this deployment with additional component installation like Edge Services, Exchange Server integration, etc.

Throughout this series of articles the same basic instructional flow is used as for previous releases.  Although it may not have been obvious the usage of bulleted items is intentionally specific.  Steps starting with a bullet are mandatory to reach the same level of installation completion as the article intends to provide at the end.  Yet normal paragraphs without bullets may include optional steps intended to provide a deeper understanding of a previous action or cover the installation of optional tools or components used to aid in knowledge transfer of the topic at hand.  This format aids in skimming through the article for repeated installations.


For these articles specific to Skype for Business Server 2015 a new lab environment has been created which is slightly different to environments used in the Lync Server articles.  An important change from the past is that a single, flat internal Active Directory and SMTP/SIP domain namespace is now being utilized.  This decision was made based on two factors: that a single namespace is easier to deal with when performing fresh lab installations and also that this reflects more common best practices today.  Because many corporate networks still utilize disparate namespaces the difference between them may be specifically called out in these articles when prudent for educational reasons.

As was also done in the previous Lync Server 2013 deployment articles a valid Top Level Domain (TLD) name was selected for the single namespaces to allow for the use of public certificates where desired, as described in this previous article.  A joint Active Directory and primary SIP/SMTP namespace of is used throughout this new series of articles.

  • Physical Host: VMware ESXi 6.0 server running on an HP ProLiant DL380 with 96GB of RAM and 12 physical CPU cores.

  • Domain Controller: A single Windows Server 2012 R2 x64 guest promoted to a domain controller for the new Active Directory forest root domain of

  • Skype for Business Front End Server: A second virtual guest running Windows Server 2012 R2 x64 Standard Edition and joined to the domain.

  • The default domain administrator account used to perform all steps is a member of the Domain Admins, Enterprise Admins, and Schema Admins domain security groups.

  • The Forest and Domain functional levels were set to Windows Server 2012 R2.

  • A Windows Enterprise Certificate Authority was deployed on the domain controller to provide SSL certificates for internal services. The CA configuration was updated to provide access to the Certificate Revocation List via HTTP, as explained in this article. The Root CA certificate was created with a hash algorithm of SHA256 and a 2048 bit key length.

  • While optional, an Exchange Server 2013 deployment was also previously completed in this environment which will be utilized in future integration articles for features like Unified Messaging or Outlook Web Access integration.


This article will begin with the installation of a single Standard Edition Skype for Business Front End Server.  For the purposes of test or educational lab environments it is more efficient to use this option than to deploy Enterprise Edition servers which requires at least one additional backend SQL Server.  For details specific to deploying Enterprise Edition pools the Skype For Business Server installation documentation should be used to accomplish this as it covers an Enterprise Edition deployment as the primary example.

The first article in this series will address the following  preparation steps:

  • Creating a File Share
  • Configuring DNS Records
  • Installing the Server Prerequisites
  • Installing the Administration Tools
  • Preparing Active Directory
  • Preparing the Central Management Store

Before performing any of these steps though the following actions were already completed in the environment:

  • Windows Server 2102 R2 installed with a static IP address on a new server.
  • Renamed the server and joined it to the Active Directory domain (
  • Signed into the server using the default domain administrator account (e.g. JDSKYPE\administrator).

Create File Share

As this will be a Standard Edition server then it is supported to collocate the required file share on the same server, unlike Enterprise Edition server which must use a separate server to host this.


    • Create a new folder on the server (e.g. SFBShare) anywhere on the server.  The following path was used in this lab deployment:



    • Verify that the local Administrators group is already granted Full Control at the NTFS file permission level and then enable sharing for this folder.  Provide a name for the new share (e.g. SFBShare) and then assign Full Control share permissions to the local Administrators group .  The permissions on this share will be more granularly defined when the Topology is published in a later step, so this step is just to ensure that the later installation process will have sufficient rights to this directory to perform the required changes.


  • Verify that the newly created directory is now available as a shared directory.


Configure DNS Records

The next step is to manually create a few DNS records to support various client lookup requests.


The following table lists the various Fully Qualified Domain Names (FQDN) which must be manually created for a Standard Edition server deployment .  Many guides will instruct that these records are all created as a standard Host (A) record but most of these records are also supported as an Alias (CNAME) record.  Utilizing Alias records when supported is generally a better practice in DNS than managing multiple Host records, but either approach is acceptable.

FQDN Record Type Resolves To Description CNAME Meeting Simple URL CNAME Dial-In Simple URL CNAME Administration URL CNAME Internal SfB Client Auto Discovery A Legacy Client Discovery SRV Legacy Client Discovery


Note that with a Standard Edition server the server’s hostname is the same as the Front End Pool name which will already be defined in DNS as all domain member servers will dynamically create and manage their own DNS record.  The only records which need to be created manually in this step are for client auto-discovery and the various web URLs.

Also be aware that to fully support older Lync clients, especially Lync Phone Edition devices, it is still a best practice to define a ‘sip.<sipdomain>’ DNS record as well as the associated Service Location Record (SRV) in the environment.

  • In the appropriate DNS Forward Lookup Zone create a new Alias (CNAME) record for the ‘meet‘ FQDN, selecting the desired SfB Front End server’s FQDN as the target host.  Repeat this step for the ‘dialin’ and ‘admin’ FQDNs as well.


  • Repeat the previous step for the ‘dialin’ and ‘admin’ FQDNs.

  • Create a new Alias (CNAME) record for the ‘lyncdiscoverinternal’ record, selecting the same FQDN as the target host.


  • Create a new Host (A) record for the legacy ‘sip’ hostname, entering the desired SfB Front End server’s IP address as the target host.


Verify the new records were successfully created and test them against the ping or nslookup command from a server or workstation in the environment.


  • Create a new Service Location (SRV) record from the Other New Records menu option in the Microsoft DNS Manager, entering the following details.

Service:       _sipinternaltls
Protocol:      _tcp
Port Number:   5061


Verify that the new SRV record has been successfully created and is resolvable using the following command in either  Windows Command Prompt or Windows PowerShell.

nslookup -q=srv


Install Server Prerequisites

Prior to running any Skype for Business Server installation tasks a number of Windows Server components need to be installed.


  • If the server does not have Internet connectivity then mount the Windows Server 2012 installation media on the server to an available drive letter as some of the components to be installed will need to be read from the installation media as provided by the Source parameter in the following cmdlet (e.g. D:\sources\sxs).

  • Launch Windows PowerShell by selecting ‘Run As Administrator’ and enter the following cmdlet to quickly install the .NET Framework package, the Remote Server Administrative Tools, and all additional prerequisites followed immediately by a required server reboot.

Add-WindowsFeature NET-Framework-Core, RSAT-ADDS, Windows-Identity-Foundation, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Dir-Browsing, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Mgmt-Tools, Web-Scripting-Tools, Web-Mgmt-Compat, Server-Media-Foundation, BITS -Source D:\sources\sxs -Restart


  • After the server finishes rebooting disconnect the Windows Server media and mount the Skype for Business Server 2015 installation media.

These newly installed Windows Server components may have one or more applicable pending Windows Updates. 

  • Run Windows Update on the server, install any pending recommended updates, and reboot the server if requested.

  • Open Windows Update again and perform another check to verify there are no additional pending recommended updates.

Additionally there is at least one critical hotfix which if not detected by the deployment wizard will block the installation of the SfB server components.  While the required hotfix has already been included as part of the December 2014 Update Rollup the SfB deployment wizard will still fail to locate the prerequisite and fail.  It is recommended to install both the update rollup and the individual prerequisite hotfix.

  • Return to Windows Update on the server to install the Optional Update for Windows Server 2012 R2 (KB3013769).  Sort the list by file size and this large rollup package should be listed near the top of the Server 2010 R2 updates.


  • Also download and install the available hotfix for KB2982006 and then reboot the server.


Install Admin Tools

In order to configure the Topology in a later step the Topology Builder application needs to be installed, which is part of the SfB administration tools package.


  • Open the mounted DVD drive and the deployment wizard should autoplay and (if required) begin the installation of Visual C++ 2013 Runtime package.


    • Confirm the default Installation Location or change the path to a different directory if desired.

C:\Program Files\Skype for Business Server 2015

The Core Components package will automatically be installed.


  • When the Deployment Wizard loads the main page select the Install Administrative Tools option on the right-hand side to launch the Install Administrative Tools wizard.  Advance through the wizard and when both the prerequisite component check and the tools installation is successful the task status will be reported as Completed.


To see the list of newly installed application search for ‘skype’ in the server.


Prepare Active Directory

As this is the first Skype for Business Server 2015 installation in the Active Directory forest then the AD Schema, Forest, and Domain will need to be extended to include the various configuration objects utilized by Skype for Business Server 2015.


  • Return to the main menu of the deployment wizard and select Prepare Active Directory and then click Run on Step 1: Prepare Schema.


To confirm some of the changes applied by this step open adsiedit.msc and connect to the Schema container to verify that the various ‘ms-RTC-SIP…’ schema attributes have been created.


If deploying in an environment with a single domain controller there is no need to run the replication verification processes.

  • Select Run on Step 3: Prepare Current Forest and select the Local Domain as the Universal Group Location if desired.  If SfB is being installed into a multiple domain forest and the universal groups need to be stored in a domain other than the domain that the current server is a member of then enter the desired domain FQDN.


Run dsa.msc to open Active Directory Users and Computers and then browse to the default Users container.  Look for a number of groups starting with ‘CS’ and ‘RTC’ in their names.  These groups were created during the Forest preparation step in the chosen domain.


    • Advance to Step 5: Prepare Current Domain to complete the Active Directory preparation steps.


Prepare Central Management Service

The final preparation step is to install SQL on the first Front End server in the forest so that the topology configuration can be published to it.


This process will install the SQL Native Client and SQL Server Express components as well as configure Windows Firewall exceptions for remote SQL connectivity. Mostly importantly it also deploys a SQL Server Express named instance, simply called RTC.  This instance will be the default location for the Central Management Store which is where Lync will store the majority of the global (forest-wide) configuration data.  The RTC Service container shown above in the AD Configuration partition is still used to store some data, but mainly for coexistence with previous releases.

  • Return to the main menu of the deployment wizard and select Prepare First Standard Edition server.  It is normal for this process to take a few minutes to complete as the SQL Server Express components are installed.


A quick glance at the Programs and Features control panel shows all of the components which were installed on the server once this process is completed.


  • Before moving further the domain Administrator account used throughout this process should be added as a member to the domain security groups CsAdministrator and RTCUniversalServerAdmins.


  • This user account should then logoff and back on to the Windows Server where Skype for Business Server is being installed to update the associated security token.

Once logged back on use the following whoami commands in the Windows Command Prompt to verify the new group membership.

whoami /groups /fo list | findstr /i CsAdmin
whoami /groups /fo list | findstr /i RTC




This concludes the preparation of the environment and the next article in this series will address defining a new topology and installing the SfB Front End server components.

Microsoft Ignite 2015

May 1, 2015 by · 2 Comments 

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 · 8 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 · 10 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 · 55 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 · 21 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.

Next Page »