June 30, 2016 by Since the introduction of VBSS in the article (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.
Microsoft's Paul Cannon and Shawn Thomas review your existing Mac client options and go into depth on our plans for a new Skype for Business client for the.
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 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 (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 knowledge base article states that this cumulative update introduces VBSS. So does the update article.
It does seem plausible that, 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 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 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). HKEYCURRENTUSER Software Microsoft Office 16.0 Lync ' Enable P2PScreenSharingOverVideo'=dword:00000000 HKEYLOCALMACHINE SOFTWARE Wow6432Node Microsoft Office 16.0 Lync ' Enable P2PScreenSharingOverVideo'=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).
HKEYCURRENTUSER Software Microsoft Office 16.0 Lync ' Enable ConferenceScreenSharingOverVideo'=dword:00000000 HKEYLOCALMACHINE SOFTWARE Wow6432Node Microsoft Office 16.0 Lync ' Enable ConferenceScreenSharingOverVideo'=dword:00000000 The 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. 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.
A little farther down the log file the endpointConfiguration group will contain the peer to peer parameter EnableP2PScreenSharingOverVideowhich is also now set to False. —snipped— False 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. Hi Jeff, Thank you and your blog for the information provided regarding VBSS issues in Skype for Business.
Our company has also been impacted with desktop sharing drops and skype client hangs and it appears that the workaround to fix this issue is by adding these 2 registry keys mentioned in your blog: EnableP2PScreenSharingOverVideo and setting the Value to 0 EnableConferenceScreenSharingOverVideo and setting the Value to 0 Originally we added the “EnableP2PScreensharingOverVideo” registry key but after running a few tests with skype, it was still running in VBSS mode and then switching back to RDP when using desktop sharing. Adding the second registry “EnableConferenceScreenSharingOverVideo” forced desktop sharing from starting in RDP mode and there was no more screen drops or client hangs. I passed this message over to Microsoft Premier Support and they are currently working (at least I hope) on getting a fix for this issue. They have recommended me to remove our antivirus, and other security software’s that we run in our environment but none of their suggestions have worked. Not sure if I missed this from your blog but is there any explanation that you know of why this is happening? Do you have any suggestions that I can pass along to Microsoft to help them resolve this issue?
Thanks again, you’re the best. I’m greatly interested in following your articles as my company is both a MS SfB shop and Polycom shop. While this particular blog post is excellent, I think it’s a bit over my head technically.
I’ve read through it and some of your other postings dealing with SfB and video conferences. My question is this (and apologies in advance if I missed an already published answer) The short question: Is is possible to have an embedded video in PPT that the meeting attendees can both see AND hear? Currently, I can only get video to be heard by attendees; audio is not heard. We currently have an on-premise SfB Server 2015. And our internal SfB client is 2015 (Lync 2013 v15.0.4875.1001) I think what I’m attempting to do is not yet possible. Here’s the scenario Our shareholders are going to be dialing into their yearly shareholder skype-enabled meeting.
Their method of connection could come from any medium: dial in phone, PC, or mobile device. My intent was to setup a test meeting that is essentially an open-ended meeting that I create and lead with a purpose-built account. In this meeting, I originally wanted to have a looping PPT file that has embedded audio. I was fairly quick to find out that the only way to accomplish this was to create a video and embed the video in Powerpoint. I created the video, embedded it, uploaded it to the server for playback, and then presented it. The video plays and audio is heard through my PC (as expected), and the attendees can see the video, but there is still no audio heard by the attendees.
Am I currently attempting to do the the impossible? If you are available to take this conversation to email, that’s preferred.
But I understand if you want to keep the information here because it helps build your blog content & SEO. Hi, I have a issue with viewing screen on skype web app when screen shared by Polycom real presence group 500. VBSS Is enabled and software is updated to latest version on polycom + I can see the screen from SKype desktop client. Can you let me know is it a bug, because screen shared by skype web app can be viewed in polycom. Scenario: Polycom is connected by HDMI cable to a laptop and content is shared SKype desktop client users can see the content shared by polycom SKype web app users cannot see the content shared by polycom.
BlueJeans with Microsoft The BlueJeans Add-in is now available for Microsoft Lync and Skype for Business! This powerful tool allows Windows users to utilize the messaging capabilities of Skype with all the benefits of the BlueJeans Enterprise Video Cloud. The add-in was specifically designed for ease of use by allowing Lync & S4B users to easily launch a BlueJeans Meeting directly from a Conversation window with the press of a button. Supported OS: Microsoft Windows 7, 8, and 10 (Lync & S4B) Mac OS X (Lync 2011). Supported Clients: Lync 2013 / Skype for Business 2015 & 2016 (32bit & 64bit). Download: for Windows & for Mac. to watch a short training video Installation Instructions The standard BlueJeans Add-in installer can be downloaded and installed directly from our.
Run the installer and follow the installation steps provided by the Setup Wizard.