Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, September 30, 2013 2:42 PM | 5 votes
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.
- Create a second user account that you add to the local Administrators group to use for troubleshooting if needed.
- Run Sysprep, selecting Enter System Out-of-Box Experience (OOBE) and Generalize checked but select Quit instead of Shutdown.
Or from a command-line:
**c:\windows\system32\sysprep\sysprep.exe /generalize /oobe /quit
** - Wait for the C:\Windows\System32\sysprep\Sysprep_succeeded.tag file to be created before doing anything else, as that indicates sysprep completed.
- Log off from the VM, leaving it running. Do not shut it down from within the RDP session.
- Click Shutdown for the VM in the Windows Azure management portal.
- 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.
All replies (34)
Thursday, October 3, 2013 1:21 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.
Monday, October 14, 2013 3:59 AM
Any update on this? It's impeding the ability to create a reusable image.
Monday, October 14, 2013 2:27 PM
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.
Tuesday, October 15, 2013 12:03 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
Wednesday, October 23, 2013 3:23 PM
Any update on this?
Thanks,
Wednesday, October 30, 2013 5:54 AM
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.
Saturday, November 2, 2013 10:01 PM
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
Wednesday, November 6, 2013 7:12 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?
Monday, November 11, 2013 4:11 AM
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.
Tuesday, November 12, 2013 1:19 PM
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.
Wednesday, November 13, 2013 11:44 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...
Monday, November 18, 2013 9:30 PM
I tried the "QUIT" option and still got disconnected.
Monday, November 25, 2013 10:20 AM
This does not seem to be working anymore, I also get disconnected if I choose Quit option.
Wednesday, December 4, 2013 4:14 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.
Sunday, December 8, 2013 12:59 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
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
Wednesday, December 25, 2013 9:49 AM
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.
Thursday, December 26, 2013 6:30 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 5:35 PM
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, January 2, 2014 2:37 AM
Bump...any solution/workaround for this?
Tuesday, January 7, 2014 1:48 PM
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
Wednesday, January 8, 2014 2:23 AM
Hi Craig,
does that apply only to new virtual machines created with the latest release of the images from the gallery?
Regards
Doug Taylor
Saturday, February 1, 2014 1:24 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
Monday, February 3, 2014 8:26 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 3, 2014 7:35 PM
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.
Friday, February 21, 2014 3:39 PM
This issue is so frustrating, why is there no resolution yet.
Thursday, March 6, 2014 8:42 PM | 1 vote
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.
Sunday, March 16, 2014 10:11 AM
Same with me. Any solution yet?
Saturday, August 2, 2014 3:51 AM
What a waist of time! I lost 2 days worth of work all because I wanted to create and image of my 2012 windows box! This issue has been reported and not resolved for to long!
Luckily I have a reliable backup vm on AWS for my meeting on Monday. I have created images on AWS in minutes with out an issue.
Just lost another customer...
Wednesday, September 10, 2014 5:50 PM
Is there any solution without recreating the vm
Saturday, May 16, 2015 3:28 AM
I'm still facing this issue in 2015. Did Microsoft ever resolved this?
The article here http://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-image/
Points to 404 NOT FOUND.
R.S.S.
Thursday, June 18, 2015 2:28 PM
I am also still facing this issue as of June 2015, this issue has clearly not been fixed.
Tuesday, January 12, 2016 6:27 PM
Seems still issue exists. Created a Azure VM with Windows 2012 Data center edition. After creation able to do RDP with out any issues. Ran Sysprep with shutdown option, VM got shutdown. After that not able to do RDP.
Tuesday, July 19, 2016 9:29 PM
Same here in July, 2016
Monday, July 16, 2018 12:53 PM
Same here , August, 2018
Venu