Aug 01 2017 10:33 AM - edited Aug 01 2017 10:34 AM
On premise implementation.
I noticed recently that when a screen sharing session drops from VBSS to RDP for whatever reason, while there's an expected frame rate drop for clients connected on-net, there's a major performance drop for clients connected via the Edge. For example, when someone types in a command prompt, it takes five to ten seconds before external viewers even see the entire line of text. When moving a window around, the screen paints very slowly as well. It is almost unusable.
I can reproduce this on multiple internet connections. It doesn't happen while in VBSS mode. Network bandwidth is good. Internal QoS policy is good.
Am I missing a setting somewhere?
Sep 20 2017 10:42 AM
Just an update on this one - I narrowed this down to being an issue (at least externally) with SfB client users on a Surface Pro or 4k screen.
Unfortunately we still get random reports internally of SfB screen sharing getting really bad. 10 second delays / screen tearing / even fully freezing up. Has anyone seen an uptick in reports of screen sharing issues like this?
Oct 16 2017 07:57 AM
Based on this statement from support.office.com, "Not only is VbSS faster, but it also more reliable and works better in case of low network bandwidth conditions.", I had high hopes for VbSS, but as we rolled out Office 2016 (now virtually 100%), it seems like we are having more screen share problems rather than fewer. Many of the same issues that David Phillips mentions (10 second delays / screen tearing / even fully freezing up). It also seems that forcing the meeting back to RDP/TCP, either with a registry change or by doing 'request control'-'give control'-'take back control' in sequence has helped resolve the issues.
My environment is global, thousands of associates, all Office 365 Online (no on-prem). Any insights from anyone would be appreciated.