none
Image capture issue / VM unexpectedly started after guest-initiated shutdown

    General discussion

  • UPDATE 03/31/14: The issue that resulted in some VMs unexpectedly restarting instead of shutting down has been resolved. The normal recommended steps can be used again to run sysprep with Shutdown.

    Note that using sysprep with Quit is still a viable method, but you must always remember to shutdown the VM from the portal before you capture the VM. If you restart the VM before capturing, it will not be in the correct state when captured and VMs created from the image will end up in provisioning timeout.

    ------------------------------

    When capturing an image, the guest needs to remain shutdown for it to be captured in the correct state. If you capture a VM that has been started after sysprep has been run, the guest OS is not in the correct state. The capture operation will succeed, but VMs created from the image will fail to provision successfully, and will ultimately show status Provisioning timed out. This is because the VM was captured when the setup state was IMAGE_STATE _UNDEPLOYABLE instead of the desired IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE (see also http://technet.microsoft.com/en-us/library/cc721913(v=ws.10).aspx for description of those values).

    To workaround this issue, specify Quit instead of Shutdown when running sysprep, and once sysprep completes, shutdown the VM from the Shutdown option in the Windows Azure management portal instead of from within the RDP session.

    1. Create a second user account that you add to the local Administrators group to use for troubleshooting if needed.
       
    2. Run Sysprep, selecting Enter System Out-of-Box Experience (OOBE) and Generalize checked but select Quit instead of Shutdown.
       
      Sysprep - Enter System Out-of-Box Experience (OOBE) - Generalize - Quit
       
      Or from a command-line:
       
      c:\windows\system32\sysprep\sysprep.exe /generalize /oobe /quit
       
    3. Wait for the C:\Windows\System32\sysprep\Sysprep_succeeded.tag file to be created before doing anything else, as that indicates sysprep completed.
       
      Sysprep_succeeded.tag
       
    4. Log off from the VM, leaving it running. Do not shut it down from within the RDP session.
       
    5. Click Shutdown for the VM in the Windows Azure management portal.
       
    6. When the Status under Quick Glance on the Dashboard of the VM in the portal shows Stopped (Deallocated), then you can click Capture at the bottom to create the image.

    Monday, September 30, 2013 2:42 PM

All replies

  • We are now aware of the issue with the article here: http://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-image/ and will update it at the next available opportunity.

    Thursday, October 03, 2013 1:21 AM
  • Any update on this? It's impeding the ability to create a reusable image.

    Monday, October 14, 2013 3:59 AM
  • Thanks for this workaround, it works perfectly for me and actually I will use this method going forward. I didn't lose a massive amount of time having to rebuild my base image as I was already starting from a previous sysprep with shutdown success.

    I had noticed away from sysprep that shutdown when running a normal RDP session wasn't reacting the way it used to, but I never connected the two issues until I re-looked at the capture image documentation to double check I was still sane and doing it the required way.

    Here is what I posted against the main article of image capture where most people are reporting their findings:

    It is a little frustrating that this bug has materialised over recent weeks, I thought I was going mad as I'd done it only a few weeks prior to today with the same build of Windows Server 2012 Datacenter and so I thought I had made a mistake.
    The fix of using Quit rather than Shutdown mentioned in the Support article worked perfectly for me.
    Working with physical hardware and then into on premise virtual servers where console access still exists, I had and continue to choose the Shutdown option pretty much every time. So I got bitten by this bug as I was on auto pilot.

    That said, I actually now prefer the Quit option as I remain in control of the environment with full access to logging etc. and I think it is a little safer doing it this way rather than losing total visibility and not truly knowing where the environment is at.
    It adds slight complexity to any kind of automation that you might have around sysprep and image capturing, but I am sure a sprinkling of PowerShell to complete the sysprep routine with Quit and check for the latest time stamped sysprep_succeeded.tag before shutting down the machine via the portal would do the trick.

    Monday, October 14, 2013 2:27 PM
  • Hi Dan,

    I apologize for the frustrating experience. We are pushing to get this addressed as soon as possible. We are expecting a fix for this issue in the next week or so. I'll update the post once that is confirmed to be in production.

    Thanks,
    Craig

    Tuesday, October 15, 2013 12:03 PM
  • Any update on this?

    Thanks,

    Wednesday, October 23, 2013 3:23 PM
  • The issue is it deletes the VM when the image is captured. What I was after is to create a new server from snapshot like you can do in AWS.
    Wednesday, October 30, 2013 5:54 AM
  • Hello,  PLEASE HELP

    We accidentally used a "Shutdown" option, however we did use the image yet.

    However I cannot connect to the original VM with same credentials we used to connect before

    Can Somebody help here?

    Thank you in advance,

    Jim

    Saturday, November 02, 2013 10:01 PM
  • I did this too and accidentally picked the shutdown option. I wasn't thinking. What happens if I do this - any way back? If I create an image anyway and create a VM from that image can I just carry on with the new VM?
    Wednesday, November 06, 2013 7:12 PM
  • Hi, I gave it a go using the Quit option but my RDP session was disconnected as well as another session I had open to the same server for just in case.  I then could not get back to the server so I'm going to try to shut it down and capture the image in the hope it worked.
    Monday, November 11, 2013 4:11 AM
  • We are now aware of the issue with the article here: http://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-image/ and will update it at the next available opportunity.

    You obviously did not succeed in updating it in a very effective way. I just lost about 2 weeks of work.

    Remove the freaking SCREENSHOTS from the article! or better yet, remove the whole article!

    SYSPREP IS NOT YOUR FRIEND. I learned the hard way.

    Tuesday, November 12, 2013 1:19 PM
  • I really need/want to snapshot vm images to move the whole vm's around to be started elsewhere.

    As of today do I use the quit method? I am hearing reports that even that does not work. What is the ground truth? I have been watching this thread for several weeks now and I am not getting that warm fuzzy feeling that the feature is working and the workaround is sound.

    Please advise!

    Signed
    -Afraid to try...

    Wednesday, November 13, 2013 11:44 PM
  • I tried the "QUIT" option and still got disconnected.
    Monday, November 18, 2013 9:30 PM
  • This does not seem to be working anymore, I also get disconnected if I choose Quit option. 

    Monday, November 25, 2013 10:20 AM
  • Well, just to update my last comment - another waste of time.  Even though I picked the Quit option for sure, I was still disconnected and hours of work on a standard image were wasted.  Not happy that a bug like this has been around for months and still not fixed.
    Wednesday, December 04, 2013 4:14 AM
  • Hi Dan,

    I apologize for the frustrating experience. We are pushing to get this addressed as soon as possible. We are expecting a fix for this issue in the next week or so. I'll update the post once that is confirmed to be in production.

    Thanks,
    Craig

    Hi Craig, 

    Can you update on the status of this bug fix process? I lost a VM which I tried to use as a template even that the 'quit' option has been chosen. Any chance this is going to be fixed anytime soon? 

    Thanks,

    Marcin

    Sunday, December 08, 2013 12:59 PM
  • After step 2, the RDP lost and can't connect to the machine any more. I didn't see file as Step 3 before lost RDP. Sounds the workaround does not work on my end.
    Wednesday, December 25, 2013 9:49 AM
  • Hi everyone,

        Same experience here. i set up a stock Windows 2012 R2 VM, restarted it once, then immediately ran c:\windows\system32\sysprep\sysprep.exe /generalize /oobe /quit -- didn't do any configuration, software installation,etc. -- got disconnected when sysprep was still running, and cannot connect to the VM now.

    Thursday, December 26, 2013 6:30 AM
  • This issue now seems to also occur when using the Quit option. I have a custom image which we created about a month ago, using the Quit option, and now when I create a new VM from the image, make changes, and then try to sysprep it (to update the image) with the Quit option, it disconnects me from the RDP session and I can no longer RDP to the machine.

    This is a huge problem. It also does not seem to be 100% consistent, as it seems that we can sysprep machines created from Gallery images.

    Thursday, December 26, 2013 5:35 PM
  • Bump...any solution/workaround for this?

    Thursday, January 02, 2014 2:37 AM
  • The guest-initiated shutdown issue is resolved. You can return to using shutdown with sysprep, and using the workaround to quit instead of shutdown still works also.

    Thanks,
    Craig

    Tuesday, January 07, 2014 1:48 PM
  • Hi Craig,

    does that apply only to new virtual machines created with the latest release of the images from the gallery?

    Regards
    Doug Taylor

    Wednesday, January 08, 2014 2:23 AM
  • Hi Doug,

    The issue is not specific to the OS version of the VM.

    I've updated the original post to reflect that we are currently seeing this issue again, albeit for a small subset of VMs, so currently it is again recommended to use Quit instead of Shutdown with sysprep, and then use Shutdown from the management portal to shut it down before capturing.

    If you saw it work on one VM but unexpected restart on another VM - that isn't related to the VM itself or the OS version of the VM - it has to do with the host where the VM was running.

    We'll update the thread when more information is available.

    Thanks,
    Craig

    Saturday, February 01, 2014 1:24 AM
  • Hi Craig,

    This is getting stranger and stranger.

    For me sysprep works perfectly with any options when used on a Server 2008 R2 machine.

    If I however try to to sysprep a Server 2012 R2 machine it ALWAYS reboots into that dreaded state, no matter if I specify shutdown or quit.

    All machines are created from gallery using the most recent versions.

    This renders us completly unable to provision machines.
    Any advice?

    best regards,

    Georg 

    Monday, February 03, 2014 8:26 AM
  • Hi Doug,

    I was not aware of this issue and I executed sysprep with the Shutdown option. Now I can't connect to my VM anymore (and it is running). How can I fix this?

    Thanks.

    Monday, February 03, 2014 7:35 PM
  • This issue is so frustrating, why is there no resolution yet.
    Friday, February 21, 2014 3:39 PM
  • As of 3/1, selecting Quit caused the VM to become unbootable using the default Windows Server 2012 R2 Datacenter image from the gallery (dated 2/21/2014, IIRC).

    After completely rebuilding the VM, selecting Shutdown, as the original article indicated, was successful in creating a bootable image.

    Thursday, March 06, 2014 8:42 PM
  • Same with me. Any solution yet?
    Sunday, March 16, 2014 10:11 AM