RDP Access during Test Failover?

Question

I'm just beginning to work with ASR and have two VMs (DC's) protected in Azure successfully.  I figured the next step was to test some failover and RDP into them to validate the machines were working.  Once the machine has entered the 'Complete testing' phase in the job, there's a status of 'Waiting for action' and at that point figured I could RDP into them after creating an RDP endpoint.  I left the default RDP ports of 3389 for both public and private.

However, RDP fails.  NOTE:  RDP is enabled on the machine on premise and works just fine.

I've tried to reset RDP using the new portal following the instructions https://azure.microsoft.com/en-in/documentation/articles/virtual-machines-troubleshoot-remote-desktop-connections/

Now, I realize that there are no extensions loaded....so maybe that's the issue?  Do I need to install VM Agent on premise such that it automatically gets replicated to Azure or..am I barking up the wrong tree?

Answer 1

I have ensured that the local Public, Domain, and Private firewall rules are enabled for RDP on the machine.

Answer 2

As it turns out, this has to do with an issue in Azure currently.  I have an open ticket with the Azure backend team to resolve as the VM is not getting a Hostname after it gets booted.

Answer 3

Thank you for the updates Ron. We are having the exact same issues. Please keep the details coming!

Answer 4

I was able to get to my failed over machines by using another method Ron. I created a Site-to-Site VPN from Azure to our on-prem network and then I did a failover within ASR using the on-prem linked network.

Once completed you should be able to completely bypass creating\modifying endpoints on the Azure side of the house and just connect to your failed over instance in Azure via the assigned local IP address.  

Like you I had no success with opening 3389 endpoints and establishing an RDP connection

Answer 5

The case is still open with no word what-so-ever from Microsoft.  Based upon their published documentation this should indeed work.

Additional feedback is that failover takes way to long to spin up a VM.  14-18 minutes per VM is certainly not acceptable.  Anyone else seeing this as well when testing failover?

Answer 6

I haven't run a test failover recently but my planned failover on November 11th took 1 hour and 55 minutes to fail over and 1 hour and 56 minutes to failback.

I don't understand why it takes so long when the systems sync every 15 minutes

Answer 7

The case is now in the hands of the ASR Tier 3 team as the VMs fail to boot in Azure.  They are investigating why they fail...and at some point we'll know why and perhaps be able to correct this.  NO boot...no RDP.

They are standard Generation 2 .vhdx VMs from Hyper-V.  Nothing special.  No special drivers.

Answer 8

Hi Ron, are you still facing the same issue with the gen2 VMs?

BlueMetal and Tyler, could you email me your exported jobs so that we can see why it is taking so much time to failover for you? Is encryption turned on for you?

Email me at [e-mail]

Thank you,

Ruturaj

Answer 9

The reason the VMs failed to boot was due to disk volume renaming of the drive letters.  This KB resolved the issue:  https://support.microsoft.com/en-us/kb/3031135

The machines in question had C:\ = OS, D:\ = CD/DVD-ROM, I:\NTDS/SysVol

Once the machine booted and the public RDP ports were open on the firewall as well as the RDP endpoint in Azure...everything was fine.

Answer 10

Ron,

I am guessing the boot problem was your "I:" drive lost its drive letter on failover? (became E: or F:, yes?) and thus without a NTDS/SysVol... well that wouldn't have been pretty.

I am glad that the problem was resolved and thank you for coming back and following up.

-Neil

---

neilgo