locked
Remote Desktop Connection to VM does not work after sysprep RRS feed

  • Question

  • Hello altogether.

    Often asked, but never answered with an applicable solution!

    What shall we do if we get no access to a Azure VM via Remote Desktop Connection?

    Everything went well: access to the VM via RDC was working perfectly!

    Then the idea came into our mind to create an image of the VM by use of the Azure Management Portal.

    We found that we had to apply “sysprep” on the VM.

    We did it.

    Then we did not take the image and decided to go on with the VM.

    But if we start the VM we get no access via RDC!

    We tried to find a solution by reviewing the already published contributions by other Azure users. But none of the replies marked as answered supply with a qualified solution.

    So can one provide a really applicable solution to us on how to arrange the further use of the VM?

    Thank you in advance.

    Thursday, July 25, 2013 2:18 PM

Answers

  • There is an issue right now where the VM may start unexpectedly after you have run sysprep and selected the shutdown option (which is normally what you should do).

    http://social.msdn.microsoft.com/Forums/windowsazure/en-US/fafb9ee6-1e57-46ba-8440-27467ad986cf/image-capture-issue-vm-unexpectedly-started-after-guestinitiated-shutdown?forum=WAVirtualMachinesforWindows

    But regardless of that issue - you can't use that deployed instance of the VM after you've run sysprep on it. It needs to stay shutdown, then you select Capture to create an image from it.

    If you start it back up, either intentionally, or it is started unexpectedly because of the issue above, it will be sitting at the first interactive screen of setup. RDP is not working at that point, and since there is no console access to an Azure VM, there is no way to get past that prompt.

    For other scenarios, you might be able to attach the OS disk of that VM as a data disk to another VM, and while you could do that in this case too, there is no supported method for disabling sysprep at that stage of setup.

    So while you could attach it to another VM to get data off of it (you would have to remove the VM first), the VHD is no longer in a supported state to use as a VM itself.

    Thanks,

    Craig

    Tuesday, October 15, 2013 11:58 AM

All replies

  • what is the error that you are getting?
    Tuesday, October 15, 2013 10:57 AM
  • There is an issue right now where the VM may start unexpectedly after you have run sysprep and selected the shutdown option (which is normally what you should do).

    http://social.msdn.microsoft.com/Forums/windowsazure/en-US/fafb9ee6-1e57-46ba-8440-27467ad986cf/image-capture-issue-vm-unexpectedly-started-after-guestinitiated-shutdown?forum=WAVirtualMachinesforWindows

    But regardless of that issue - you can't use that deployed instance of the VM after you've run sysprep on it. It needs to stay shutdown, then you select Capture to create an image from it.

    If you start it back up, either intentionally, or it is started unexpectedly because of the issue above, it will be sitting at the first interactive screen of setup. RDP is not working at that point, and since there is no console access to an Azure VM, there is no way to get past that prompt.

    For other scenarios, you might be able to attach the OS disk of that VM as a data disk to another VM, and while you could do that in this case too, there is no supported method for disabling sysprep at that stage of setup.

    So while you could attach it to another VM to get data off of it (you would have to remove the VM first), the VHD is no longer in a supported state to use as a VM itself.

    Thanks,

    Craig

    Tuesday, October 15, 2013 11:58 AM
  • Hi Craig,

    So in other words, you are saying that in case someone followed the instructions on creating a VM image which Microsoft published here:

    http://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-image/

    effectively they have destroyed their VM and their is no way they can get access to it?

    Looking at how many people have actually done this (including myself) and given how Microsoft is trying to push Azure in general, this should be quite high up on the list of priorities your team should push to the product team.

    Is there a way someone can actually go in and fix the issue in case it happens?

    Thanks,

    Boyan


    Boyan Penev --- http://www.bp-msbi.com

    Give us some candy - please upvote helpful posts and mark your answers!

    Sunday, November 10, 2013 11:53 PM

  • A year later and this issue is still going on, I have lost numerous VM's.

    The instructions that Microsoft have on their website is still the same, very bad, losing time and money here.

    Thursday, December 11, 2014 9:17 AM
  • Misery loves company, I guess -- I am glad it's not just me. This is still an issue and apparently sysprepped VHD's (without knowing some secret sauce) are trash for Azure nor can they be rebooted in HyperVisor (or VMware). I am finding it best to not bother with sysprep & upload disks / images to Azure that complain about provisioning but otherwise work. I would be delighted for some clarity -- advice I've seen is that you sysprep but don't shut down the VM until after you have uploaded the vhd (i.e., sysprep to quit but not shutdown). Still scratching my head but I've got deliverables to get out the door ...
    Monday, February 16, 2015 2:53 PM
  • Sorry Craig, the answer about unexpected reboots is completely unhelpful, that was not the scenario discussed

    The issue described... and unfortunately I just went and did it myself... is that after sysprep'ing a server, it can no longer be connected to via RDP.

    Any comments or advice about the sysprep  OoB Experience and whether this intentionally disables RDP connections would be helpful along with any advice how to remotely enable it again, since I am using a cloud based instance (AWS in my case) I have no access to the server's console so I can't walk over to it to troubleshoot/fix.

    Wednesday, March 23, 2016 3:56 PM