Lync, Office365, Skype4B, ,

Updated 1/20/2018 – Corrected information on Office 2016 MSI supportability.  Updated information on Skype for Business for Mac 2016.  Updated Skype Meetings App supportability.  Updated mobility clients supportability.

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 Office support page with information about where VBSS is available.

  • The Office 2016 suite (Click to Run) on Windows machines only.
  • The Office 2016 suite (MSI) on Windows machines only.
    • Note:  Requires version 16.0.4401.1000 or above
  • Skype for Business for Mac 2016
  • Skype4B Mobility clients
  • Skype Meetings App
  • 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
  • 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:  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?

  • 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.
  • Lync for Mac 2011 – the Lync for Mac 2011 client does not support VBSS and will continue to utilize RDP.
  • 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 – Even though VBSS has been added to the MCU’s, the plug-in for LWA (or Skype Web App) does not support VBSS.
  • 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:

  1. Lync 2010 and 2013 Bandwidth Calculator
  2. 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

Screen Size Acceptable Optimal
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

Screen Size Acceptable Optimal
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*

Update:  confirmed

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.

Disabling VBSS

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.

https://support.microsoft.com/en-us/kb/3150900

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:

https://support.microsoft.com/en-us/kb/3169044

https://support.microsoft.com/en-us/kb/3153361

https://support.microsoft.com/en-us/kb/3159724

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:

https://support.microsoft.com/en-us/kb/2768648

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.

19 thoughts on “Video Based Screen Share within Skype4B and Office365”

  1. Hi,
    I’m wondering if this topic relates to some issues we’re seeing in our enterprise with screen sharing. At times, when sharing to some computers running SfB2016 the sharing works, then hangs on the receiver’s computer. It just won’t “paint” the screen with the window the sender is sending. Sometimes the window is literally halfway to displaying but pauses.. Video/Voice remain working for the most part, until the hanging eventually causes the sender’s SfB app to crash. What makes it more intriguing is the app that the sender (who is sharing their full desktop, not just the app) is trying to maximize/display is usually an Office App (e.g Excel or OUtlook), that seems to set off the hanging. I know, this makes no sense. But am at a total loss.

    The help topic at Msoft that I’ve got going is: https://community.office365.com/en-us/f/166/p/430108/1086880

    1. Are you referring to my point made at the end of the post regarding updates (BIOS/video/chipset/platform/etc)?? If so, then yes, I would absolutely recommend starting there. Update all the drivers on your affected systems as a starting point. I’ve had several significant issues at customers where a simple driver update fixed the problem. Also take a look at anti-virus as well and make sure that A/V engines aren’t trying to somehow inject themselves into the application process or manipulate the network traffic. If that doesn’t fix it, then take a look at the Platform Updates in the Microsoft KB support article and make sure those are deployed. You can’t just deploy security updates anymore – you have to deploy the non-security related updates because many of the other products – Skype4B included – now tie into features/benefits/requirements offered in those updates. You really do have to maintain a holistic patching process.

      As an aside: I had significant issues with my Lenovo T520 when I first updated to Lync 2013. It boiled down to BIOS, video drivers and a special configuration specific to my laptop. My laptop has two video cards and it “intelligently” chooses which to use based on “application need” – yeah, that never worked. Had to turn that feature off before things became stable. And that was just to fix application sharing.

      1. Thanks for the reply. Unfortunately our patching process is not anywhere close to what is needed it seems. It is a massive task to maintain all the drivers and bios, especially when many of the same models of a computer have different hardware under the hood. We do have a couple machines in a lab that we know are experiencing these issues, so we can at least try and bring those as up to date as possible and go from there.

        I find it very odd that VBSS sharing session hangs when the presenter is flipping between Office apps (ie, bringing up OFfice or Excel docs, etc..) Surprised it’s app-specific. AT least that’s been our experience so far.
        When taking VBSS out of the equation (ie, multiparty or sharing an application or using SfB2015), the hanging of screen sharing sessions is not an issue.

        1. Multiparty sharing still uses RDP so you wouldn’t see the issue there. Reading your description, I believe that the core cause is simply how H.264UC works and not the fact that you switch apps during a VBSS session. Switching apps is the symptom but likely not the real issue. Remember, VBSS is video at heart, so if you switch apps you’re essentially causing the H.264UC video codec to have to render the entire monitor screen all over again. In actual video calls this almost never happens because the only changes in the frame are around a person’s movement (which is typically their head and mouth), so the changes are minimal (and typically centered in the frame), but not so in VBSS. A change in an app results in the H.264UC codec crunching numbers on the ENTIRE monitor frame. Add in the fact that you’re probably using 1080P monitors (or close to) and H.264UC will be doing some serious number crunching…or wanting your hardware to do it.
          If it were me, I’d do updates in this order:
          Video
          Chipset
          Audio
          BIOS
          Windows OS Patches – all non security related
          Application Patches (eg: Office) – all non-security related

          1. Thanks for the reply. We’ll give it a go. I just find this feature an unrealistic expectation by Microsoft to place on its users, considering their push for SfB to become the UC standard in enterprises. It’s one thing for small companies to manage this, but when talking large organizations with 1000+ devices, this is an onerous task. Not saying patching shouldn’t be done anyway, but to require it done to such a high level, without the ability to disable VBSS in the client, well, that seems like a big error in judgement on their part.

  3. Hi,
    If there is no Lync folder under the registry:
    [HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\]

    Should we bother to add that registry key?
    Thanks

    1. Wow6432Node is only utilized for 32-bit apps installed on a 64-bit operating system. If your Office suite is 64-bit then you need not concern yourself with the Wow6432Node.

  4. Just as a follow-up to this, and in hopes it helps someone else, the end result with my conversations with Microsoft is they closed the ticket and acknowledged this is a known issue with SfB2016/VBSS and Windows 7 operating systems.

    It certainly would have been nice for them to publish this known issue to have saved me a bunch of time, so I’m hoping I’m helping by posting this here.

    1. I’m not aware of the ‘known issue’ they speak of, unfortunately. I’m currently working with a very large customer using Office 2016 on Windows 7, which initially had issues very similar to yours, but the registry keys (along with disabling hardware acceleration) seems to have done the trick for the short term. Their long(er) term plan is to update hardware acceleration dependent drivers, such as BIOS, video, chipset, etc, both at the request from me and MSFT PSS. They are still tracking existing Service Desk cases and working with MSFT but I’ve not seen any official statement from our internal channels with MSFT in saying Windows 7 has a known bug with VBSS. That is not to preclude that there isn’t a bug – I’ve just not heard of it.

  5. I came across this post after MS support provided a registry key to test on our end. There are not many online discussions or articles about this problem.

    We isolated the problem to SfB 2016 on Windows 7 system and sharing the desktop from that system. We have an open ticket with MS support and they also mentioned there is a problem and they are working to resolve it. We have had SfB either hang, which requires force closing the program, or crash suddenly. This appears to differ based on video/display driver versions.

    Our scenario is Windows 7 systems will crash when they present their desktop to any Windows version system with Office 365 (2016) installed. If a system with Windows 8.1 or 10 presents there is no crash. To test, we went so far as to reimage a Windows 10 system back to Windows 7 and installed Office 365 (2016). With Windows 7 OS, the system would hang/crash, but would not with Windows 10.

    There was a recent Office 365 update that showed additional fixes for SfB, (https://technet.microsoft.com/en-us/office/mt465751) but it looks as though we have not received the latest updates yet. I am currently running Windows 7 and Office 365 (2016) updated to version 16.0.6001.1068. So I guess we’ll have to wait for the fix to roll out.

    Another thing we found is the error messages were referring to the d2d1.dll file, which online searches point to being part of DirectX. There are no longer an updates for DirectX on Windows 7 versions. All Windows 8.1 and newer versions have DirectX 11.2.

    I will try to post something here once MS has resolved our issue.

    1. Did MSFT have you disable hardware acceleration for Office 2016? I would hope that was attempted…

      1. We tried the disabling of hardware acceleration and it didn’t help. Microsoft acknowledged to me the bug and said there was a recent update which they believe has solved it. Oddly they asked me to verify if it worked, which I found odd because I figured they’d have more resources available to test that me. But I think really they just wanted to ensure I’m aware of it and give it a try.
        As mentioned in this blog, VBSS will require additional bandwidth capacity, and is only enacted at this time for 1-to-1 calls.

      2. Microsoft support has not requested that we make any changes to hardware acceleration. I searched my registry and do not have the entry for DisableHardwareAcceleration either. I’m not sure why this setting is not available in Skype for Business, but I went ahead and made the setting change and tested my SfB again. After testing I can tell you that setting does not help with SfB problems with screen sharing.

  6. It’s really resolved my very painful problem of crashing skype on every fine minutes. Thank you soooo much 🙂

  7. We may have a solution by using one of the latest versions of Office 365 (2016) along with the version specific registry key entry. My 64 bit install of Skype for Business is definitely working better. No more crashing or freezing withing 5-10 minutes of sharing my Desktop.
    We are still doing more testing. My Office 365 is now at version 16.0.6741.2021 and I added the DWORD key below –
    [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync]
    “EnableP2PScreenSharingOverVideo”=DWORD:00000000

    1. You may want to test without the Registry keys first. If there was truly an application code issue then the updated version may be your fix without making any other changes. Keep me posted – interested to hear the outcome!

Comments are closed.