Since the introduction of VBSS in the article Video Based Screen Sharing (VBSS) for Skype for Business last year Microsoft has released several changes to the platform to further leverage this technology.  This new article will serve as an update to the concepts outlined in the original as well as outline any future behavior or functionality.

It is recommended to read through the original article to gain a basic understanding of what VBSS is to better appreciate the changes and improvements covered in this new article. 

Conferencing Support

First and foremost Microsoft has delivered, in two separate stages, the ability for Skype for Business 2016 Windows clients to leverage VBSS in conferences now. As covered in the previous article when this new capability was released in 2015 it was only available for peer-to-peer Desktop Sharing sessions between to 16.x version Windows clients.  In the event that these same clients were participating in a multi-party conference then the Skype for Business Front End Server’s Application Sharing Multipoint Control Unit (ASMCU) would be driving the media control for sharing content between all parties.  This ASMCU, whether it was in an on-premises Lync or Skype for Business Server deployment or instead running in the Office 365 cloud as part of Skype for Business Online would still be using the legacy Remote Desktop Protocol (RDP) technology.

Online Meetings

Since posting that original article though this has changed.  Early in 2016 Microsoft quietly added VBSS support to the ASMCU components in their Skype for Business Online platform.  This means that any conference hosted by a Skype for Business Online user and attended by only Skype for Business 2106 Windows clients can leverage VBSS for sharing their desktops.  If any older client versions were to join the meeting then the ASMCU will immediately step-down to using RDP, just as peer sessions were already reverting to RDP in the event that the receiving party would attempt to take remote control of the session.

It is important to understand that the ASMCU does not create a multiple codec stream scenario like the AVMCU can do with X-H264UC encoded video.  As covered in a past Lync Conference presentation the AVMCU can request that the active speaker in a conference should send two encoded video streams: one using Scalable Video Coding (SVC) and the other in Real Time Video (RTV).  This is a “highest-common denominator” experience which continues to provide the SVC video streams to all other meeting participants which support that video codec, yet also allows a legacy client which only supports RTV to still see the active speaker’s video.

The ASMCU does not function this way as only a single Desktop Sharing stream is provided by the sending client, it cannot simultaneously encode an SVC stream and and RDP stream.  Thus the inclusion of any client in the meeting which does not support VBSS (which is literally every Lync/SfB client available except for the 2016 Windows desktop client) will trigger the ASMCU to request the client that is sending content to only use RDP, otherwise referred to as a “lowest-common-denominator” experience.

On-Premises Meetings

As of this week with the release of the June 2016 Skype for Business Server 2015 Cumulative Update (a.k.a. CU3) now on-premises Skype for Business deployments can join in the fun.  With the application of these server updates the ASMCU and all related components are now VBSS-aware and the functionality is identical to what is explained above, although it can be turned off if desired.

Upon closer inspection of the various June update articles there exists one interesting item that may seem a bit confusing at first glance: some of seemingly unrelated server components are referencing VBSS updates.  For example the Video Interop Service knowledge base article states that this cumulative update introduces VBSS.  So does the Mediation Server update article.  It does seem plausible that, with an understanding of VIS, one might think that X-H264UC could now be utilized to somehow provide desktop sharing across the VIS server, but how in the world could a Mediation Server leverage VBSS?  The answer is that these various components are simply updated to be aware of VBSS as a media session so that they function properly, and no different than before, when VBSS is active in a call or conference.  They do not actually support handling VBSS session themselves, only the ASMCU does that.

Along with the recent release of these cumulative updates Microsoft has also posted some guidance in TechNet around VBSS.  That article basically defines the same limitations in the usage of VBSS as originally covered on this blog.  So new new functionality appears to have come to VBSS itself, only that it is now more widely supported throughout the Skype for Business platform.

In short, given the proper circumstances, an improved desktop sharing experience is now available for both peer sessions and conferences.  The key words there are “desktop sharing” as that is still the only modality which can leverage VBSS.  Any other content sharing modality (e.g. Programs, PowerPoint Files, etc).

Management

The ability for the 16.x clients to leverage VBSS is enabled by default, but can be disabled if desired.  As covered in the previous article this can be seen in SIP messages during the initial setup of a desktop sharing session.  The conferencing engines in Skype for Business Online and Server 2015 (with CU3) platforms are also enabled by default, but only the on-premises version can be disabled.

So as long as the remote host that a client is attempting to negotiate and send a desktop share also supports VBSS then it will be used, initially at least.  Regardless of whether that remote host is another supported client, a SfB Online ASMCU, or a SfB Server 2015 ASMCU running CU3.

If an administrator wishes to disable the default behavior for some reason then this can be archived using one of three different methods currently available:

• Disable VBSS for either peer sessions and/or conferences at the client level directly on the workstation.
• Disable VBSS for conferences only at the ASMCU level directly on the server.
• Disable VBSS for both peer sessions and conference at the client level on a server-side client policy.

Out-of-Band Client Configuration

The first option is to disable it at the client level by updating the registry of the workstation where the desired client is installed.  Using this method will disable the use of VBSS and limit the client to using RDP for Desktop Sharing in any and all scenarios. 

This is applicable to both on-premises and online user accounts as the configuration is performed solely at the workstation level and does not depend on any server-side management control.

• Using either the Registry Editor (or an Active Directory Group Policy configuration) set either of these registry values to control the applicable client(s) based on their platform (32 or 64 bit).

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync]
"EnableP2PScreenSharingOverVideo"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\16.0\Lync]
"EnableP2PScreenSharingOverVideo"=dword:00000000

Keep in mind that disabling this feature will mean that if the affected client joins a conference were VBSS is available then the ASMCU will be forced to revert to the lowest-common-denominator scenario and fallback to using RDP for all attendees.  It does not matter if the ASMCU still prefers to use VBSS by default though as if any or all connected clients have this disabled then they will not attempt to use it and instead force the use of RDP as the only remaining option.

With the addition of VBSS support in conferences there is now another new registry value made available to the client.  While not specifically stated in the Microsoft documentation, assume that the June update for the Skype for Business 2016 client is also needed in order to support this new setting.  (Some of the testing performed for this article was using the 16.0.6925.1018 Click-to-Run version.)

• Using either the Registry Editor (or an Active Directory Group Policy configuration) set either of these registry values to control the applicable client(s) based on their platform (32 or 64 bit).

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync]
"EnableConferenceScreenSharingOverVideo"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\16.0\Lync]
"EnableConferenceScreenSharingOverVideo"=dword:00000000

The TechNet documentation is currently a bit vague here as while these parameters are included, the actual implementation of them is vague and confusing.  There is also a statement that both of these P2P and Conference settings should be set to the same values: either both disabled or both enabled.  Yet testing showed that the expected behavior is seen when only one of the two modes are disabled.  Given the amount of other incorrect information currently in that document it is difficult to state why it might not be supported.

Server-Side Configuration

Another approach is to control the behavior directly from within Skype for Business Sever.  There are currently two server-side options available to control whether VBSS or RDP is the default option for desktop sharing.  These settings are only available for on-premises deployments as Online tenants clearly could not be given control of a multitenant-impacting feature such as this in the various ASMCUs across the cloud.

The first server-side option applies only to conferences by turning off VBSS at the ASMCU level.

• In the Skype for Business Server Management Shell use the Get-CsMediaConfiguration cmdlet to verify the current configuration.  Note that EnableVideoBasedSharing parameter should be enabled by default after the successful installation of CU3.

Get-CsMediaConfiguration

• To disable the default usage of VBSS on conferences simply use the following Set-CsMediaConfiguration.

Set-CsMediaConfiguration -EnableVideoBasedSharing $false

• To confirm the modification simply use the Get-CsMediaConfiguration alone or optionally with a filter as shown below weed out the unwanted parameters

Get-CsMediaConfiguration | Select-Object Identity,EnableV* | fl

Omitting the Identity parameter in the cmdlet above will apply the change to the default Global entry.  If additional Media configurations are defined then the above parameter could alternatively be configured differently for individual pools at the site or service levels.

Remember that this configuration parameter only applies to the ASMCU though.  So while RDP will be used in conference calls hosted on the configured environment or pool this does not disable the use of VBSS in peer desktop sharing sessions between SfB clients in the same environment.  The change is near immediate and will start to apply to any new Desktop Sharing sessions started in a conference, even in existing conferences, but not to an active sharing session that was already running before the change was applied.

In-Band Client Configuration

This option will disable VBSS for both conferences and peer to peer sessions by using a single parameter which actually controls the clients themselves.  Where the setting above disables VBSS directly on the ASMCU, making client configuration moot, this approach leaves VBSS enabled on the ASMCU and utilizes the client policy provisioning model to disable VBSS at the client level.

One advantage of this option would be to configure unique conferencing polices for different groups of users, allowing VBSS for some and limiting others to RDP.  Clearly VBSS cannot be disable at the ASMCU for that scenario to work so the previous configuration option would not work as it would disable VBSS for all ASMCU participants.

In essence this configuration can produce the same behavior as the out-of-band registry approach with one exception: both conferencing and P2P functionality is impacted.  Where as with the registry approach it is possible (although stated as unsupported) to individually disable one call scenario or the other.

• In the Skype for Business Server Management Shell use the Get-CsConferencingPolicy cmdlet to see the new ApplicationSharingMode parameter and default VideoWithFallback value.

Get-CsConferencingPolicy

• To disable VBSS for both conference and peer sessions for all clients assigned to the Global policy enter the following Set-CsConferencingPolicy cmdlet.

Set-CsConferencingPolicy -ApplicationSharingMode RDP

• To confirm the modification simply use the Get-CsConferencingPolicy alone or optionally with a filter as shown below weed out the unwanted parameters.

Get-CsConferencingPolicy | Select-Object Identity,App* | fl*

For this change to take affect the Front End server was rebooted and the clients were (automatically) reregistered.

The relationship between the server policy and client configuration is shown in the table below.  The steps above would have changed the configuration from the default of enabled to disabled.

To validate the configuration and actually see how these in-band settings are pushed to the client then the workstation’s UCCAPI logs can be reviewed to see the provisioning information outlined above.  Each time a client signs-in then the following provisioning data is passed in-band to the client.

• Inside the meetingPolicy provisioning group the EnableConferenceScreenSharingOverVideo parameter will be set to False when the server parameter is set to RDP as explained above.

<provisionGroup name="meetingPolicy" >
<instance >
—snipped—
<property name="EnableConferenceScreenSharingOverVideo" >False</property>
—snipped—
</instance>
</provisionGroup>

• A little farther down the log file the endpointConfiguration group will contain the peer to peer parameter EnableP2PScreenSharingOverVideo which is also now set to False.

<provisionGroup name="endpointConfiguration" >
<propertyEntryList >
—snipped—
<property name="EnableP2PScreenSharingOverVideo" >False</property>
</propertyEntryList>

Summary

As the behavior covered in this article is brand new and still awaiting additional documentation from Microsoft then any future changes or additional details will be added to this article.