How to prevent Azure RDS disconnect while a file operation, like copying many GBs from RDS to local HDD?

Question

• We have a client who is dropping Azure RDS in favor of running everything on their local machines.
• For the first user to be migrated, I mapped the local drive to his Azure RDS computer and started downloading a few dozen GBs of data from the RDS to the local machine.
• When I checked on it later, it was proceeding fine, averaging 10 MB/s with about one hour of four to go.
• However, when I checked in soon after that, the session had disconnected and the copy operation had been stopped.
• The explanation I got was that there had been no user input in however long and it had disconnected because of that.
• Dismayed but undaunted, I reconnected to the RDS and theatrically cracked my knuckles.
• It would have been impractical to try to manually figure out what had made it and what had not, so I copied everything from before from the RDS to the local machine the same way I had originally - drag-and-drop.
  • I figured the OS could more quickly figure out where to resume than I could, but that seems to have been naive.
  • The operation has been estimating more than a day to completion for about an hour now and does not seem to be checking for already-copied files like normal.
  • It's going through each file, with no evidence of copying; just checking, at a pace of about one every ten seconds or so and there are many thousand files to go.
• The unexpected connection failure would not have been much of a problem if the second attempt at the copy operation had just checked what was there and resumed where it left off, but as it is, I forsee misery for any involved when we start migrating the rest of the users.
• EDIT: After about an hour and a half, the copy operation finally resumed at the previous pace, but still has more time left than the RDS disconnect timeout and I can't remain remote connected to the guy's computer for a few more hours to reset the clock. Also, my shift ends in twelve minutes and there is a selfish part of me that would prefer to do weekend stuff until Monday.
• Does anybody have advice to prevent the RDS from disconnecting while copying data between itself and the local machine?
  • Is there a more elegant way than totally preventing automatic sign-off?
  • I'd just use a mouse jiggler, but the risk that I'll end up with an infected installer that sets the entire datacenter on fire is too high.

Thank you

Answer 1

HI Adminttedly-3412,

1.Could you please enter winver in command prompt on both local computer and Azure RDS computer then look the os version and os version number ? [for example windows 10 enterprise 1809 (os build 17763.316)]

2.Can you enter below command to export the gpresult report on Azure RD session host server and check if there is RD session time limit policy applied on issue Azure RDS server?
If there is, we can set the comfortable value to meet your copy target.
gpresult /h c:\rds.html

Configuring RDP/RDS Sessions Limits (Timeouts) on Windows
http://woshub.com/remote-desktop-session-time-limit/

3.What's data do you want to copy from RDS session host to local computer? only user's profile?

4.Is there RD connection broker server in your RDS environment?

5.Did you configure roaming profile and user profile disk in your Azure RDS environment?
If you configured user profile disk in your Azure RDS environment, we can only copy the user profile disk to local computer then attach it to his computer like picture 1 and picture 2, finally, the end user can copy the file by themselves.

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Thank you. I will go through this at work tomorrow.

Answer 3

Sorry, JuaYou-MSFT, for not replying sooner.

I was not able to go through the troubleshooting you suggested last week, but will as soon as I am able.

Thank you

Answer 4

One of our network engineers told me he will investigate this and get back to me. Once I have his findings, I will post them here for anyone else who has the same question.