Lync Server

Revamp the Desktop Sharing engine

The use of RDP for desktop sharing is very slow over limited WAN links and wastes a lot of bandwidth. They should either find a way to allow RDP to be tuned for < 100k of bandwidth or find a better engine.


Submitted by

Stage: Active

Feedback Score

52 votes

Idea Details

Vote Activity (latest 20 votes)

  1. Upvoted
  2. Upvoted
  3. Upvoted
  4. Upvoted
  5. Upvoted
  6. Upvoted
  7. Upvoted
  8. Downvoted
  9. Upvoted
  10. Upvoted
  11. Upvoted
  12. Upvoted
  13. Upvoted
  14. Upvoted
  15. Upvoted
  16. Upvoted
  17. Upvoted
  18. Upvoted
  19. Upvoted
  20. Upvoted
(latest 20 votes)

Similar Ideas [ 4 ]


  1. The idea was posted


  1. Comment
    ( Moderator )

    rgreenlee, which desktop sharing system have you used that is more efficient?

  2. Comment
    rgreenlee ( Idea Submitter )

    Even Live Meeting and Webex are much better. We have been working with PSS to try and tune Lync's desktop sharing experience. We have had some luck adjusting the AppSharingBitRateKb setting down although PSS cannot tell us what that setting does.

    Our end goal is to reduce or elimiate our WebEx spend but out of the box webex performance is much better than Lync and does not use nearly as much bandwidth.

    Not sure why MS did not use the engine from Live Meeting in Lync verses RDP.

  3. Comment
    ( Moderator )

    rgreenlee, if you have a forum post or any other details I'd love to see that resource here. thanks.

  4. Comment
    John Porter

    I am of the view that RDP is the right choice for Desktop SHARING, if you just want to present your desktop then by all means use another technology, our organisation is finding substantially improved end user experiences during our support calls as we can interact with them while on a call without having to ask them to do anything more onerous than share their desktop.

  5. Comment
    rgreenlee ( Idea Submitter )

    RDP is ok for one to one connections. Lets consider the standard rate of 500k per RDP connection. Probably ok for a couple of users but not lets try to have a 50 person conferennce. You have one 500k stream heading in to the MCU on the Front-End servers and 25MB heading back out. Might not seem to be that much unless those 50 users are on the other end of T1 MPLS lines. Not try scaling that to hundreds of users. Thats probably the main reason by default conferences are limitd to 250 users.

    I have not been able to find exact stats but a similiar desktop sharing session on webex uses under 100k from my monitoring and is a lot smoother. Don't get me wrong. I love Lync and everything it is doing for us but RDP does not scale as a conferencing desktop sharing engine.

  6. Comment

    I've never seen RDP go that high on bandwidth requirements. I've had to resort to using it on a GPRS data connection in the past and it has worked, albeit slowly.

    Personally I find WebEx very irritating to be on the receiving end of because of the extra popups and bubbles obscure what's happening.

    Our backup supplier uses a mixture of Go2Meeting and WebEx and I must say that my entire team much prefer it when the support tech sets up the call in Go2Meeting rather than WebEx.

  7. Comment
    Community Member

    The current implementation (based on RDP technology) is terribly poor. In Gigabit LAN environment it is still incredibly slow. You can see how it re-draws the screen line-by-line. It takes 4-5 seconds to re-draw a complete screen. If there is significant activity on the screen, it will break/get out-of-sync as long as it finishes a complete screen re-draw. As if we were in the 90's using XT computers for High definition video. The only possible workaround is to share only application window instead of the whole desktop. The client policies offer by default 50Mega(!)bit for appsharing, so it is obviously not a bandwidth issue but rather a technology/implemention flaw.

    2) The inability to reduce color depth during screensharing is a major pain for lot of customers. It was an effective way to reduce bandwidth consumption through constrained links, but now it is no longer available. Livemeeting was so much better even if it required a separate software.

  8. Comment
    Pat Richard

    Keep in mind that presenting PPT in 2013 is handled differently, and clears up some of that.

  9. Comment

    There is one more terrible problem with Lync's implementation of desktop sharing: it does not show the security screen and UAC dialogues

  10. Comment

    Today we did a comparison between Lync 2013 and Cisco WebEx Meeting Server 2.0: specifically focused on testing the user experience of desktop sharing and application sharing. The main page was used as a test source - as it rotates through a series of high quality pictures and then repeats.

    The experience with Lync is that as the website transitions from what image to another, participants see the screen paint from top to bottom every time the image changes. Sometimes the painting occurred up to 3 layers until the image was fully painted. We saw this behavior repeat with PowerPoint presentations as well. While it is functional and the painting happens in less than a second, it is noticeable and a bit distracting.

    The experience with Cisco WebEx Meeting Server was the image faded in. There was no top to bottom paining. Overall the image changes transitioned in about the same amount of time as Lync, but the experience was a more natural and expected experience than the painting effect of Lync.

    The best way for me to describe this is interlace scanning vs. progressive scanning. The Lync behavior was similar to interlace scanning and the WebEx Meeting Server behavior was similar to progressive scanning.

    If there is going to be a revamp of the desktop sharing engine (which I support and encourage), I suggest looking into improving how the information is displayed in addition to bandwidth reductions.

Add your comment