Eksportuj (0) Drukuj
Rozwiń wszystko
Ta zawartość nie jest dostępna w wymaganym języku. Wersja w języku angielskim znajduje się tutaj.

Top Support Issues in Azure

Updated: January 12, 2015

This page lists the top issues for the Windows Azure Support Team and gives some guidance how to resolve them yourself.

When you attempt to delete a storage account associated with an Azure virtual machine, the deletion will fail if the storage account contains an active OS image, VHD, or Disk artifact. You will receive an error similar to the following:

Storage account storage-account-name has n container(s) which have an active image and/or disk artifacts. Ensure those artifacts are removed from the image repository before deleting this storage account.

The error message blocking the deletion of the storage account indicates that there are OSImage, Disk, or Disk Image artifacts still associated with the storage account.  Ensure that you have no OSImage, Disk, or Disk Image artifacts and retry the storage account deletion again.

If the deletion is part of an automated script, and deletion of the disk artifacts is performed with an asynchronous operation such as the Delete Deployment operation, you must call Get Operation Status to ensure the operation is completed before calling the Delete Storage Account operation. Even after the last artifact is deleted for a storage account, it may take up to 15 minutes for the Delete Storage Account operation to succeed, so continue retrying the operation for up to 15 minutes.

A new Azure Virtual Machines FAQ is now available to answer some of these questions.

Problems with the code running in your Virtual Machines or Cloud Services roles can cause reboots. However, Microsoft will also reboot your roles in the following cases:

  1. Guest OS Updates – Affect only Cloud Services Web and Worker roles. See the Azure Guest OS Releases and SDK Compatibility Matrix for information on how to limit these reboots. The page refers to a feed that is updated within a few hours of a Guest OS rollout giving you a warning of when reboots are likely to occur, assuming you are set to automatically update your Guest OS. The page describes the Guest OS release process and when to expect releases in general.

    Microsoft prefers that you set your Guest OS to upgrade automatically so you get the latest MSRC security updates as soon as possible. But if you must, you can control reboots by manually setting your Guest OS to a specific version and then upgrading it sometime after a new release comes out. The drawback of this strategy is that Guest OS releases come every month and only the last two Guest OS releases are supported. Manually upgrading requires extra work for the service administrator. For additional information, see this blog post written by a Windows Azure support engineer

  2. Host OS Updates – Affect Cloud Services Web and Worker roles and Windows Azure Virtual Machines. See Azure Host OS Updates for general information on what the Host OS is and the update process. Host OS updates are done fewer times than Guest OS upgrades. As of Jan 2014, they occur approximately every 6 weeks, though that frequency can change at any time. There is currently no notification process in place for these updates. You cannot prevent or control the timing of the updates. More information is available in the blog post referenced above.

  3. Service Healing – Service healing occurs when the hardware running your role(s) fails causing the role to crash or become unresponsive. Windows Azure detects this situation and will automatically move your role or Virtual Machine to another piece of hardware and restart it. Hardware failures are unplanned so there is no way to know when a reboot will occur. You will receive no notification when service healing occurs. Reboots due to service healing are unlikely to repeatedly affect a typical service.

Even with these system initiated reboots, Microsoft is committed to maintaining the Service Level Agreement (SLA) outlined on the WindowsAzure.com site. Microsoft is aware that system initiated reboots is an issue for administrators and is actively working to improve the customer experience.

© 2015 Microsoft