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.
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.
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.
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).
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).
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).
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.
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.
- 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.
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" >
<property name="EnableConferenceScreenSharingOverVideo" >False</property>
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" >
<property name="EnableP2PScreenSharingOverVideo" >False</property>
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.
44 thoughts on “Skype for Business VBSS Update”
I assume that with polycom integration… css … cascading content … vbss would fall back to rdp as the css probably doesn’t support this yet?
Correct, any third party solution supporting only RDP today will trigger the same fallback as any Microsoft clients that only supports RDP. e.g. Lync/SfB 15.x, iOS, Android, Web App, Skype Room System, Group Series, Trio 8800, ContentConnect (aka CSS), etc. In reality
Note that, prior to Trio UCS software version 5.4.3 REV AA, desktop sharing from a 16.x Skype for Business client to a Trio 8800 would fail. I was able to replicate on a number of deployments. The Trio would not negotiate “down” to RDP. After applying 5.4.3, I have not been able to replicate.
Yes, the 5.4.3 version added support for the 16.x SfB clients, which perform the initial content sharing negotiation slightly different even when still using RDP.
Thanks for this informative piece Jeff. Will Polycom be extending this functionality to the Group Series for Real Presence (cascaded RPCS/Skype for Business) scenarios? Thanks.
Do you know if it is possible to disable Skype Video via GPO/Registry? We have mobile (laptop) users that we would like to disable video when they roam onto certain subnets.
If you disable that via client policies it may write that configuration into the registry. If you capture that change you can add it to GPO policies
I think a lot of Skype settings are now stored in the database, so I’m guessing that won’t work.
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.
Thanks for a very informative article about VBSS.
Is there any way we can configure and set the application sharing mode of Skype (O365) from VBSS to RDP?
Appreciate your response. Cheers
No, only Desktop Sharing can utilize VBSS. Individual Application Sharing still uses RDP only.
Hi Jeff! 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. 🙂
Andre, you are correct in your assumption that it is not possible. Content Sharing in SfB does not include any audio, it is only screen sharing. Standard’s based video content sharing does include audio by comparison. So if you connected a computer to something like a Group Series codec using HDMI but the video and audio if captured and shared, but the audio cannot make it to any SfB clients in interoperability calls or meetings.
Thanks Jeff. I was afraid you were going to say that. My CIO was closely watching my progress with this. It’s going to be like telling him *spolier alert* Santa doesn’t exist. 🙂
I have a question. In your article you mention 16.x clients can use vbss. I have the Sfb 2016 basic client installed at version 16.0.4444.x. From my understanding vbss is not enabled on these clients. You have to have a 16.0.6330.x or above to have the vbss option. Do you know if this is a correct statement?
I’m not sure on the individual version related to the Basic clients but it does support VBSS, as documented here: https://technet.microsoft.com/en-us/library/dn933896.aspx (look for the “Video-based screen sharing” row).
What is the actual frame rate for content with SfB and will it improve with VBSS?
RDP does not have an actual stated frame rate as it’s not a frame-based transmission. In practice it’s in the low single digits if you were to compare apples-to-oranges. VBSS supports up to 15fps of motion which is capped at half the potential max frame rate based on using the same X-H264UC codec that provides video streams at up to 30fps for the cameras.
Getting the below codec error from Lync Server Side. Supposedly Lync does not have any codec to negotitate on.
Can you please help me with the command to enable it.
Is this correct? Set-CsMediaConfiguration -EnableG722StereoCodec $true
584 TL_INFO(TF_COMPONENT) 256BC.3E2F0::09/03/2018-07:48:18.962.0000010e (AvMcu,SdpCodecDescriptionParser.CheckName:mctypes.cs(2498))(0000000001B34025)No Codec ID found for [g719/48000/2]
Jeff – great information. Do you have any insight into VBSS traffic through a stateful firewall? I suspect our problems with sharing are due to VBSS but I can’t lock it down. We don’t have an internal SfB server as we are using vanilla hosted o365.
If the VBSS traffic is UDP, I don’t see how return traffic can be made to return to the end user in a reliable manner.
VBSS is delivered in the same fashion as the video stream. Same codec, same media traversal behavior (UDP preferred, TCP fallback) leveraging ICE. So if you can establish a video session between two clients then a VBSS desktop share should also work.
I have Skype for Business Server 2015 (6.0.9319.0): installed but when I run the “Get-CsMediaConfiguration” I do not see “EnableVideoBasedSharing ”
Identity : Global
EnableQoS : False
EncryptionLevel : RequireEncryption
EnableSiren : False
MaxVideoRateAllowed : Hd720p15M
EnableInCallQoS : False
InCallQoSIntervalSeconds : 35
EnableRtpRtcpMultiplexing : True
However when I make the call using 2 skype for business client I see that application sharing is happening over VBSS, so my question is that if I using 2 latest client does it ignore the settings or “EnableVideoBasedSharing ” has been removed?
Am I missing any components on my server?
The peer-to-peer call should use VBSS regardless as long as the two clients are SfB 2016. The new configuration parameter is for controlling the ASMCU behavior for meetings, not peer calls.
When I share my computer screen via polycom group 310 , Group 310 camera is disabled on skype window And only screen which shared from group 310 can be seen on the skype. We want to take screen sharing window and camera window simultaneous from skype. Is it possible or not ?
That is normal behavior for peer-to-peer calls. The recent 6.1.5 firmware release will now send content and video in separate channels, but only in a SfB Meeting (leveraging VBSS). Peer sharing scenarios between two endpoints still functions as you see today with the content replacing the video stream.
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.
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
That should work as the web app supports receiving VBSS content (it only sends content in RDP though). Suggest opening a support ticket.
we are facing this issue from couple of months in our environment and the ticket with polycom and microsoft is also opened but there is no progress in that , it is pending since months.
For the same problem that while connecting to third party device polycom video conferencing group 500 as SIP my skype call has getting only the shared screen my near end video is not visible.In this case could you help me that should
1. i need to upgrade the software version of skype for both far end and near end user
2.should i need to check the application shell that vbss is enabled or disabled
3,should i need to need to check the ports for audio and video traversal.
If shared content is replacing the video camera image then RDP is being used for that session. In order to utilize VBSS instead you’ll need to make sure that VBSS is possible in your scenario, based on the details in these articles.
Does anyone knows if Microsoft had removed the cmdlets for CsMediaConfiguration and CsConferencingPolicy? When Im trying to check Get-CsMediaConfiguration or Get-CsConferencingPolicy I am unable to see the parameters mentioned in the article such as EnableVideoBasedSharing or ApplicationSharingMode.Any advice would be much appreciated.
Assuming you are referring to Skype for Business Online the EnableVideoBasedSharing parameter is not available as the Get|Set-CsMediaConfiguration cmdlet is not available. These changes cannot be applied per tenant and would impact the entire MCU, so they are not allowed in the multi-tenant environment. You can use the New|Get|Set-CsConferencingPolicy cmdlets online, although the ApplicationSharingMode parameter cannot be changed online due to the same multi-tenancy rules previous noted.
Thanks for the article. Really very helpful in getting an understanding of content sharing.
I have a situation where -in we are unable to view the shared content between s4b user and VC user
Server is Lync 2013.
When a VC room and a skype for business user are both connected to a virtual meeting room … the video end point can share content but the skype for business end point cannot see it.
It sounds like you are using an older workflow of calling into a VMR from a SfB client (e.g. email@example.com) and unless you have the Polycom Content Connect server installed and properly configured then content sharing will not work across all participants in that scenario. You should ideally be leveraging RealConnect which address that limitation.
Good afternoon Jeff,
I work for the Dept. of Veterans Affairs and I have an issue with Skype for Business on some Windows clients. I’ve noticed that on a two separate systems (one Windows 7 desktop and one Server 2016 Terminal Server) when a Skype conference call opens, the computer (or at least the RDP session I’m using to connect to the systems) slows way down. Sometimes making screen sharing unusable due to the delay in mouse and button click actions. These conferences are mostly being launched via an Outook meeting and I’ve noticed that if I choose the “don’t join audio” option and instead call into the conference call via phone then the computer latency does not occur. Skype for business was recently deployed as an update with a conversion to O365 and though I’m an administrator I do not control the O365(w/ Skype) deployment directly. I’ve been researching this issue for a little while but haven’t really found anything helpful so far. Any help you could provide would be greatly appreciated. Thanks.
We have seen some issue in some of our branch locations with screen freezing in application sharing during conference calls. The voice portion of the call works fine and peer to peer calls don’t appear to be affected. Additionally if the user goes to a different location they usually can have the call without any screen freezing. Microsoft has looked at our issue and determined from the logs that the screen freezing is due to high packet loss during the calls. Working with our networking team they are unable to see any issues in the network that would cause this packet loss. In fact we have even had this problem when there was plenty of bandwidth to the branch. Has anyone see this type of issue before?
Run KHI check do you get packets received discarded
If it is virtual machine check on the VMWare graph CPU Ready
Let me know the results of your findings.
[…] disable VBSS in an environment where UCMA is trying to handle the application sharing calls. This blog covers the options to do that by either changing registry settings on the client, or changing […]
we experienced same issue as well.
I discovered the root cause of the issue.
In test scenario I set the appshare to 4Mbps in configuration.
Technical insight: valid for Cisco 2960X
SWT#sh policy-map test
Policy Map test
police 1500000 50000 exceed-action drop
BOUND: inbound at Switch
This we used to simulate a bandwidth limitation in high load times.
The result is exactly what happens in real.
We can successfully reproduce the behavior by changing the switch configuration for both ports used by clients while conferencing (adhoc) test situation because we thought it might be related to bandwidth
• Configure policer on switch port for client to max receive 2Mpbs
• Appshare will freeze instantly if line is less than 2Mpbs and will get running again if 3Mpbs or more bandwidth is available (just switching in test)
In the network “stream” you will see that the UPD will consume at min 2 Mbps even nothing will change in apphare.
This will lead me to the result that this is a design flaw!
Got a ticket open on Microsoft to approve this siuation.
We’ve run into an issue using Poly Trio’s and Skype for Business while sharing content. When sharing content from the Trio there is a noticeable hit in quality as remote users join the call. If a user joins from the S4B phone app the quality of the content becomes unreadable. We’ve worked with MS and PGS on this and they’ve said it comes down to the Trio only being able to provide 1 VSS Tx stream.
Is there any known workaround or setting that can be changed so this drop in quality doesn’t occur?
I believe this is a known issue with no current workaround, but please contact Poly support to confirm.
I am also having this same issue with Poly Trio. Poly Support have been on site and points towards a Network issue. Ramon – have you had any improvement in your service?
Do you know if there’s a way to determine which client or clients in a conference is triggering a step-down from VBSS to RDP?
I do not. I suppose you might be able to guess from the QoE details by looking client versions or content sharing media reports.