2

An automated Windows update this morning left my Windows Server 2012 R2 Classic Virtual Machine on Azure in a semi-crashed state. The VM is a web server, and all the files and applications in it are still accessible via the browser. In other words, IIS and a number of other services are still running. Unfortunately, however, the VM is not accessible via Remote Desktop and is unresponsive to commands from the Azure management interface on the portal.azure.com website.

This type of error is quite common and can be found reported on many other websites. The error has been happening to Windows users (not just Windows Server) for many years already, and none of the solutions online will work for Azure users, because they involve restarting from a CD, pressing shift-f8 during boot, issuing DOS commands, restoring from backup, or unchecking certain properties in VMWare or other software.

Does anybody have a real solution for this problem on Microsoft Azure?

enter image description here

Valtinho
  • 327
  • 1
  • 3
  • 16
  • Does it work? Boot diagnostics does not show real-time log. Could you show the log when your RDP to your VM? – Shui shengbao May 29 '17 at 05:30
  • Hi Walter. I don't think the RDP log has anything useful. It says: "Remote Desktop Service start failed. The relevant status code was 0x800706b5." Log Name: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational. Event ID: 17. Level: 2. Task: 0. OpCode: 0. ProcessID: 832. ThreadID: 912. User: System. Task Category: None. – Valtinho May 30 '17 at 13:00

3 Answers3

5

After struggling with this for weeks, I think I was able to fix this with the help of Microsoft support! I decide to post the solution here in case it can help someone in the future. Here are the three things that you need to do to fix this:

1-Restore the VM from a backup prior to the crash. The VM with the "Undoing Changes" crash is pretty much toast at this point. Now, proceed to steps 2 and 3 to ensure that the next batch of Windows Updates won't crash it again!

2-On your new VM, ensure that the Environment Variables for TEMP and TMP both point to C:\Windows\TEMP. In my case, they were both pointing to a temporary folder in the logged in user's profile.

3-Ensure that C:\Windows\TEMP is always empty. I achieved this by setting up a scheduled task that runs a simple BAT file that deletes all files and folders inside of the C:\Windows\TEMP once a day. I spoke with a Microsoft representative who said that even though you may have plenty of hard drive space in your C:\ drive, the Windows TEMP folder is really not supposed to get much bigger than 500MB. When it gets very large you may have some issues with Windows Updates (mine was just under 500MB when the updates were failing).

Valtinho
  • 327
  • 1
  • 3
  • 16
  • Thank you so much for posting this!!! I have been fighting this problem for a week and was just about ready to just destroy the VM and start over. You just saved me tons of work. – meyousikmann Mar 02 '18 at 18:35
0

I would recommend contacting Azure support as something may have to be done by an engineer to fix the issue and unfortunately classic VMs don't have the redeploy feature.

Brian Hauger
  • 490
  • 1
  • 4
  • 22
  • Thank you. I submitted a ticket on Friday (5/26/2017), but still no response (as of 5/30/2017). Still trying to get this resolved... – Valtinho May 30 '17 at 12:52
0

I've added only InboundPort 3389 RPD, and works well now.

Selim Kayalı
  • 11
  • 1
  • 3
  • Could you please clarify where you added it, and what it entails? It may be obvious to you, but not necessarily to others. – easythrees Nov 16 '18 at 22:57
  • Sign in on Azure Portal, select your VM, when the new new screen appeared, you can see the search box top of the left menu, you write there "Networking" and slide screen again, and you can see Inbound Port Rules, then click Add inbound port rule for RDP - 3389, by the way, it works for me. I am not sure for other issues. – Selim Kayalı Nov 17 '18 at 23:11