Microsoft Remote Desktop WTF



  • If you drag&drop a file onto a Remote Desktop window, the upload is controlled by your local computer, which basically does its damndest to saturate your upload bandwidth-- normally a good thing, right?

    But no, in this case, it'll starve the remote desktop connection of bandwidth, it'll lose the connection, and when you re-establish it, the upload's failed. Hm.

    If, instead, you go into Remote Desktop options and tell it to map your local drive to a remote share and do the exact same drag&drop operation-- now the upload is controlled by the remote server, and it never consumes enough bandwidth to starve the remote desktop connection.

    This bites me on the ass EVERY SINGLE TIME. I always do the drag&drop first, end up with a lost connection, then go, "oh... right" and have to do it over again the right away.



  • Huuuuh. TIL.

    No wonder that's never worked. Wonder how that slipped past QA (and if it's been reported).


  • FoxDev

    it works well enough if you've got a big enough pipe that you can saturate the disk on the sending or receiving side and still have enough bandwidth left over for the RDP session.

    so it works if you are on a gigabit connection in the same LAN segment as the "remote" host and there's no one else on that LAN segment.

    ....

    so basically it works if you're in a test lab, and maybe if your doing small files from your desktop to a server in the same office.


  • Discourse touched me in a no-no place

    An alternative: Share a drive or directory on your own PC, and set up ACLs as appropriate. Then on the server, just view your PC's share. You can even use the last-character-is-a-$ security-by-obscurity thing.


  • :belt_onion:

    err... every time I've tried to drag and drop it doesn't even allow it to go into the Remote Desktop window, it just drops it back on my desktop. (and then I SMH and use CTRL+C/CTRL+V instead)

    And I've CTRL+C --> CTRL+Ved files both into and out of remote desktops without a problem.

    Is this a new windows 8 "feature"?



  • Yeah, this one should be fixed. If you have a Connect bug filed, shoot me the # or link....

    As a side note, using an independent path (i.e. not over the RDP channel at all) will almost always give significantly better performance.



  • @FrostCat said:

    An alternative: Share a drive or directory on your own PC, and set up ACLs as appropriate. Then on the server, just view your PC's share. You can even use the last-character-is-a-$ security-by-obscurity thing.

    That's way harder than just checking the "show local drives on remote computer" checkbox, and gives zero added benefit.

    @darkmatter said:

    Is this a new windows 8 "feature"?

    No; it worked in XP definitely, possibly Windows 2000 (honestly that's going back far enough that my memory's not clear. But I'm like 75% sure it worked in Windows 2000.)

    @TheCPUWizard said:

    Yeah, this one should be fixed. If you have a Connect bug filed, shoot me the # or link....

    Meh, that takes effort.



  • @blakeyrat said:

    That's way harder than just checking the "show local drives on remote computer" checkbox, and gives zero added benefit.

    In most (not all) scenarios it actually does give a significant benefit...see my previous post...

    @blakeyrat said:

    Meh, that takes effort

    Indeed....but, for better or worse, Connect is the primary way that bug fixes are prioritized at Microsoft. If nobody reports it, it typically does not stand a chance of getting fixed...if thousands do (and it all starts with one) then the odds increase.



  • @TheCPUWizard said:

    In most (not all) scenarios it actually does give a significant benefit...see my previous post...

    At the cost of tweaking firewalls for 37 hours. PASS!

    Unless both servers are on the same LAN/domain, then maybe.



  • @blakeyrat said:

    At the cost of tweaking firewalls for 37 hours. PASS!

    Unless both servers are on the same LAN/domain, then maybe.

    Of course, situations vary... but that seems to be (which does not mean it actually) is a bit of a WTF...it would take many more details, but the only times I see a problem...

    1. You can RDP onto machine X, but do not have permissions to create a Share on X, and there is no existing "drop folder" share...

    2. You can RDP onto machine X, but machine X can not see back to your machine and the data is only on your machine.


  • Grade A Premium Asshole

    @blakeyrat said:

    it'll starve the remote desktop connection of bandwidth, it'll lose the connection, and when you re-establish it, the upload's failed.

    I have never had that happen...



  • @blakeyrat said:

    it'll starve the remote desktop connection of bandwidth, it'll lose the connection

    I used to get this kind of thing happening with ssh sessions back to a remote Linux box as well. Turned out that it was because at least one NAT router in between us was a little too aggressive about forgetting NAT sessions.

    For ssh this is fixable using the ClientAliveInterval server option, which forces the ssh server to send empty keepalive messages at the specified interval, or with the ServerAliveInterval client option that does the same thing from the other end. Might be worth your while finding out whether RDP offers a similar facility.



  • I don't understand how, with all the hundred fancy network protocols they invented, we still have to manually limit file upload bandwidth or the connection craps out.



  • If it is a NAT issue, it's because NAT was wrong from the start; it's essentially a MITM attack against routing. Personally I'm amazed it works at all.


Log in to reply