Updated 8/31/2017 – Updated information on Office 2016 MSI supportability.
Updated 10/27/2016 – Included updated information about client VBSS support and required versions. Included updated information about non-VBSS support scenarios. Included updated registry keys to disable VBSS in conference scenarios.
Updated 10/13/2016 – Included updated information about Surface Hub VBSS support and information about LWA/SWA VBSS support
Updated 7/15/2016 – Included updated information about LRS VBSS support, Surface Hub VBSS support, MCU VBSS Support and Office365 MCU VBSS Support, and MCU Bandwidth information
Updated 6/9/2016 – Included information about Cumulative Updates for VBSS-related fixes
Updated 2/12/2016 – Including information about disabling VBSS via registry keys
If you’ve been following along with my blog, you may have noticed that I published an article around application sharing a few months ago. AppShare tends to be the ‘forgotten modality’, in my opinion, so the goal was to raise awareness around just how considerable the usage could impact enterprise networks. Knowing that video based screen sharing (VBSS) was coming down the pipeline, the intention was to come back and publish info on VBSS afterwards, but Jeff Schertz beat me to it and published an article that took the wind out of my sails – we’ll hash out the differences over a beer when I’m back in Chicago, Jeff 😉
Note: While I was away on vacation, Jeff Schertz published another article before me – again – but in his defense, if the roles were reversed then I would have done the same thing! All a matter of timing 😉
I won’t attempt to completely re-invent the wheel given that Jeff’s post already has most of the info, but I’ll add some personal flavor to the discussion that will increase the available information out there and potentially fill in some gaps…
Background on VBSS vs RDP
From OCS 2007 to the current Skype4B Server 2015 version, application sharing has been accomplished by using the RDP protocol for both peer to peer and multi-party communications. The biggest problem came down to performance of that RDP-based solution and the movement away from RDP to H.264UC within VBSS is a big step in overcoming the overall performance issues. Since VBSS uses H.264UC to actually encode the application sharing traffic and UDP as a network transport, it has essentially become a video-stream instead of the RDP/TCP session that was previously present. The improvements are noticeable but there more than a few issues to note as of current…
Where is VBSS available?
Microsoft now has an official TechNet page with information about where VBSS is available.
- The Office 2016 Click to Run on Windows machines only.
- 1:1 (or peer to peer) sessions using the Share Desktop feature in the Skype4B client.
- 1:M (or multiparty) sessions using the Share Desktop feature in the Skype4B client.
- Skype for Business Server 2015 MCUs as of the CU3 update
- Note: Requires July 5, 2016 CU on the client to utilize.
- Office365 MCUs as of the CU3 update
- Note: Requires July 5, 2016 CU on the client to utilize.
- Note: Within a conference, the joining of any down-level client that does not support VBSS forces all clients to switch back to RDP.
- Surface Hub
- Note: Requires the Anniversary Update 1607 to utilize
Note: For P2P scenarios, the ability to use VBSS is largely independent of server version or hybrid topology state and instead is largely based on the client itself. As a result you can still achieve VBSS usage even when your server back-end does not support it.
Where is VBSS not available?
- Office 2016 MSI – If the MSI version of the Skype for Business 2016 client is deployed, RDP is only available to that client version.
- Lync 2013/2010 clients – I am not expecting this to change and those clients will continue to utilize RDP.
- Note: Skype 2015 clients are really Lync 2013 clients with the new UI.
- Using the Share Program feature in the Skype4B client – If you share an application, such as Word, RDP will likely continue to be used for the foreseeable future until Microsft adds VBSS for this particular scenario.
- Using the Share Program feature in the Lync 2013/2010 client – If you share an application, such as Word, RDP is the only option available and will continue to be used for the foreseeable future.
- Using the Give Control feature within application or screen sharing (updated) – if you grant control of your desktop to another user, the client automatically falls back to RDP.
- Lync 2013 Mobility clients – given the more limited processing power in mobile devices (and other mobile challenges such as bandwidth), RDP is still used in the mobile clients.
- Skype4B Mobility clients (updated) – the iOS and Android clients support VBSS but require specific versions:
- iOS version 6.7 or higher
- Android 220.127.116.11 or higher
- Mac clients (updated) – The new Mac 2016 client will include VBSS support but the Lync for Mac 2011 client does not.
- Lync Server 2013 multiparty sessions (updated) – All multiparty application sharing sessions (either formal, such as a meeting, or informal, such as an four-party IM with application sharing) eventually terminate on an MCU, specifically the Application Sharing MCU, on your Front End or an Office365 Front End. The MCU must include support within the SDP for VBSS, which is not available for Lync Server 2013.
- Note: I do not expect VBSS to come to any previous server version, such as Lync Server 2013 or Lync Server 2010.
- Lync Web App/Skype Web App (updated) – Even though VBSS has been added to the MCU’s, the plug-in for LWA (or Skype Web App) does not yet support VBSS. This will be coming in a future CU, but only for Skype Web App via Skype for Business Server 2015 deployments.
- Lync Room Systems – LRS is really the Lync 2013 client at its core, so I do not expect this to change and those clients will continue to utilize RDP until the LRS systems are updated to the 2016 client code.
- Skype for Business Room Systems – At the current time the S4B room system software really is Lync 2013 at the core. The most recent update simply changed the branding and UI but the core application still remains on the Lync 2013 code. I would expect VBSS to come to the Skype4B Room Systems at some point in the future when the core application is upgraded.
- Surface Hub – While Surface Hub now supports VBSS as of the Anniversary Update, there still may be interoperability issues that cause it to fail. Additionally, if the Surface Hub hasn’t been updated to the latest update then VBSS won’t be available.
VBSS Bandwidth Planning
As Jeff Schertz pointed out (and as I’ve seen in deployments already) the bandwidth numbers for VBSS change when compared to RDP. Bandwidth planning for RDP-based app share was a big point in my previous post and with VBSS now in the picture, it becomes even more important. If you search for information on application sharing bandwidth, you’ll likely come up with very few pieces of information. The only published application sharing bandwidth information is actually hidden within two pieces of official Microsoft documentation but that information is specific to RDP-based flows and not VBSS:
- Lync 2010 and 2013 Bandwidth Calculator
- Network Planning, Monitoring, and Troubleshooting Lync Server
In both pieces of documentation, Microsoft explicitly outlines bandwidth estimations for application sharing traffic:
Table 1 – RDP Application Sharing Bandwidth Estimations
|1280×800||384 Kbps||1.5 Mbps|
|1440×900||512 Kbps||2 Mbps|
|1680×1050||768 Kbps||2.75 Mbps|
|1920×1200||1 Mbps||3.5 Mbps|
The numbers above also don’t have any bearing on bandwidth expectations when using the High Performance RDP sharing option, so for the sake of comparison we’ll simply compare VBSS with regular RDP scenarios. Jeff Schertz pointed out an increase of 25% when comparing VBSS to RDP and I can confirm that’s a fairly good expectation, although maybe a bit on the low end, but still usable. With that information and assumption, the application sharing bandwidth table begins to change and we can create ourselves a new table for VBSS:
Table 2 – VBSS Application Sharing Bandwidth Estimations
|1280×800||480 Kbps||1.875 Mbps|
|1440×900||640 Kbps||2.5 Mbps|
|1680×1050||960 Kbps||3.40 Mbps|
|1920×1200||1.25 Mbps||~4 Mbps*|
Looking at the table with new info, a few points (some existing and some new) can be made…
VBSS bandwidth is still variable in nature and can have a wide range of bandwidth requirements
There’s no denying that a static, non-moving screen won’t require much bandwidth, but movement of applications, scrolling of Word documents and refreshing of screens could require a significant increase in bandwidth requirements. Don’t always assume the lower value is a hard-and-fast-rule – it’s really more an average towards the left side of the Bell Curve. Bandwidth above the average can (and will) occur.
VBSS bandwidth requirements are most largely coupled to screen resolution
The higher the resolution, the more bandwidth required but a ceiling does seem to be present due to maximum video payload bitrate of the H.264UC codec implementation within Skype4B. See below.
VBSS may be limited to 1920×1080 screen resolutions*
Given that the H.264UC codec is used for VBSS, there is a limitation with the resolution support of the codec as implemented within Skype4B. Microsoft’s documentation lists 1920×1080 as the top-end resolution for H.264UC, so screens with higher resolution than that – namely 4K or 5K or 8K – will not transmit at the native resolution and be capped at the maximum encoding rate of 1920x1080p which is approximately 4 Mbps. I am anticipating that Microsoft may have to add additional levels and profiles of H.264 to support the higher resolutions above 1080p. If that happens, expect bandwidth to increase accordingly.
What makes it “Acceptable” vs “Optimal”?
VBSS offers a significant improvement in frame rate (and thus performance) when compared to RDP so the tables above will certainly change from what I’ve posted (which aren’t official in any way). That being said, don’t try to starve application sharing bandwidth just because it’s ‘appshare’. Given that VBSS is really a video stream, the performance of VBSS will be directly tied to network performance provided for that traffic. If you go much lower than the ‘Acceptable’ numbers in the second table, expect users to complain of slow refresh rates, jumpy application sharing, and/or wholly unusable application sharing sessions. There absolutely are scenarios where VBSS could consume the bandwidth listed in the ‘Optimal’ column, so it will be paramount to make sure that sufficient bandwidth is provided.
MCU Bandwidth will increase substantially with VBSS
Given that VBSS is a video stream and generally uses more bandwidth than RDP, your Skype4B MCU’s (whether on-premises or in Office365-land) will see an increase in bandwidth usage. Consider the following statement from the newly-minted TechNet page about Capacity Planning:
At full capacity (which as noted above, is 375 screen sharing participants per Front End Server in total, though only 250 per meeting), your Front End Server may be utilizing ~89% of the 1 Gigabit of network card. This is because the existing screen sharing technology in Skype for Business Server CU2 (RDP) transmits the on-screen content at the native resolution of the presenter's PC. So with higher screen resolutions factored in, you may already be experiencing network bottlenecks for screen sharing with Skype for Business Server 2015 CU2. To mitigate this, one or more of the following options may be helpful: Upgrade your Front End Server from a 1 Gigabit network card to a 10 Gigabit Ethernet card. Increase the number of Front End Servers to load-balance traffic. Limit the bandwidth (bitrate) used for VbSS and RDP by putting a cap on the maximum bandwidth used by either channels.
For larger on-premises deployments, re-thinking how you size your Front End pools now becomes critical so that you can properly handle VBSS bandwidth expectations for meetings. For Office365 deployments, properly sizing your Internet and/or ExpressRoute circuits to handle the bandwidth load for VBSS in conferences will be critical. Don’t skimp on this and control application sharing bandwidth per my recommendations below!!!
Controlling VBSS Bandwidth
Microsoft has added no additional controls for controlling application sharing bandwidth, so there’s nothing new to discuss. At this point your only recourse is to utilize one of the methods given in my previous post on controlling Application Sharing Bandwidth.
As of the CU3 update, Microsoft has added native functionality within Conferencing Policies to control the usage of VBSS. There are effectively two options available: disable VBSS globally or disable VBSS within specific conferencing policies.
Option 1: Set-CsMediaConfiguration -EnabledVideoBasedScreenSharing $FALSE Option 2: Set-CsConferencingPolicy -Identity ConfPolicyNameHere -ApplicationSharingMode RDP
Note: The above cmdlets will only be recognized by the July 5, 2016 (and later) client versions of Skype for Business 2016 (not 2015 or Lync 2013), so if you need to disable VBSS for pre-July 5, 2016 clients, then you’ll need to deploy the registry keys below to force the Office 2016 suite client to utilize the legacy RDP functionality for screen sharing:
Windows Registry Editor Version 5.00 [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 [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
Note: the last two registry keys above apply only to clients that are running the July 5 update to the client. That client version supports conferencing-based VBSS, so if you need to disable VBSS for conference scenarios, use the last two registry keys above if you haven’t already disabled VBSS via the conferencing policy settings.
Cumulative Updates for VBSS
Microsoft has been continuously updating the client to fix VBSS issues that have been cropping up over the last few months. If you are having crashing issues you can also take a look at the following KB articles for fixes specific to Skype for Business:
Other Important VBSS Factors
Given that VBSS is H.264UC based, some companies may begin to notice that workstations appear to have more difficulty and crash or experience other odd issues when upgrading to the Office 2016 suite and begin using Skype4B. H.264 is almost always hardware accelerated and as a result has a much tighter integration and reliance with BIOS versions, video drivers, chipset drivers and Windows platform updates. Don’t believe me? Check this out:
Previously, drivers were begrudgingly updated when companies wanted to utilize video within Skype4B and ignored otherwise. Now that VBSS is in the mix and is essentially video, it is absolutely paramount to have the latest drivers on your workstations for proper function of Skype4B for the simple support of application sharing. Now more than ever, it is crucial that companies include a holistic approach to system updates and don’t focus solely on security patching.