If the subscription is a member-offer with associated benefits, it can only be transferred to an account with the same member-offer with associated benefits (such as MSDN, BizSpark etc.).

July 2016

March 2016

Recommended approach

Support Type: Free Assisted - Billing

Step 1: Sign into the

https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=estsredirect%3d2%26estsrequest%3drQIIAbPSyigpKSi20tdPTE7OL80r0SvPzEvJLy9OrCotStVLzs_Vyy9Kz0wBsaLYgYJJmTk5SYyGRUJcAqYnQx73J-h4bqjZ_nPqbaGEWYwcOZllYE2rGPUImatfXJpUnFyUWVCSmZ9XfIGR8QUjYxcTi6GBsfEmJpZgxwDPE0zNJ-VuMQn6F6V7poQXu6WmpBYlglQ_YuINLU4t8s_LqQzJz07Nm8TMl5OfnpkXX1yUFp-Wk18OFADaUJCYXBJfkpmcnVqyi1nFzNjMPNXYOEU3zSTNUtck2ThV1zLRIknX0CLN0twwzSzF2CLxAMsGzgssArdYWFMTizONdnGS6AsA0&id=&cbcxt=azubill&lc=1033&lw=1&fl=easi2Usage and Billing Portal, select the relevant subscription and click on “Billing History” to view its billing information

Step 2: View your invoice

a) Click on “View Current

Statement” to open the online statement of

charges for the current month (updated daily)

b) Click on “Download invoice” to open

a PDF copy of the selected period’s statement

a

b

Details

“How do I understand my Bill?”

Invoice Summary: Lists the total amount currently owed, including this month’s charges, any previous balances, discounts, credits etc.

If you need additional support or have additional questions about your bill, open a support ticket under Billing

March 2016

Recommended approach

Support Type: Free Assisted - Billing

Step 1: Click on “Download Usage” to open a .CSV file

containing details of each resource’s daily usage and charges.

The top section of the file displays the details on the services you

are being billed for during the previous month's billing cycle. The

next section has a daily breakdown of the same information.

There are two versions of the detailed file. Both versions include a monthly and daily usage table with a row for each billable resource. Version 2 contains the same information as Version 1, yet with added fields and slight name variance for additional clarity. Version 2 is shown below. For more information and full list of field definitions, please visit

Consumed Quantity: Contains the amount of the resource that has been consumed for this month/day.

Meter name: The unit of measure for the resource being consumed (compute hours, database units etc.).

1

2

Resource Group: New column addition. The resource group in which the deployed resource is running in. Refer to

http://azure.microsoft.com/en-us/documentation/articles/resource-group-overviewthis article for more details.

4

Overage Quantity: If the Consumed amount exceeds the included amount, this column displays the difference. You are billed for this amount. For Pay-As-You-Go offers with no amount included with the offer, this total will be the same as the Consumed quantity

http://azure.microsoft.com/en-us/updates/organize-your-azure-resources-with-tagsthis article for more details.

5

March 2016

Recommended approach

Support Type: Free Assisted - Billing

Introduction:

The Service Level Agreement (SLA) describes Microsoft’s commitments for uptime and connectivity. A

https://azure.microsoft.com/en-us/status/#historyservice incident is reported when Azure services experience an issue that impacts uptime or connectivity, often referred to as an “outage.” If we do not achieve and maintain the Service Levels for each Service as described in the SLA, then you may be eligible for a credit towards a portion of your monthly service fees.

Step 1: Log on to the

http://portal.azure.com/Azure Portal. If you have multiple accounts, make sure you use the one that was affected by Azure downtime (this helps Support automatically collect the necessary background information and resolve the case faster).

Step 2: Create a new support request

Step 3: Select “Billing” under Issue type

Step 4: Select “Refund Request” under Problem type

Step 5: Add details to specify that you’re asking for an SLA credit, mentioning the date/time/time-zone as well as the impacted services (VMs, Web Sites, etc.)

Step 3: Open a Support ticket under Technical and select Problem type: “Management” and Category: “Virtual machine restarts.”

Good to know

Unexpected reboots are generally a result of one of the following:

Planned maintenance of the Azure platform: the host environment is updated about every 2-3 months to keep the it secure for all applications and virtual machines running on the platform. There is no option or configuration to avoid these host updates. Learn more about Azure Maintenance and avoiding downtime

Unplanned maintenance: if Azure cannot reach the VM during regular monitoring, connectivity loss can occur. If the VM isn’t available or isn’t healthy, Azure stops and restarts your VM. Learn more about Service Healing and auto-recovery

Proactive maintenance: administrator/co-administrators are sent notifications of upcoming planned maintenance (by AZCOMM). There are also portal toast notifications of planned maintenance.

You can change your update settings to gain more control of update timing.

If a VM is restarting, the status, (listed in the Azure Management Portal) will be shown as ‘Starting.’ After a restart, restart details can be found in the Azure Management Portal under Management Services (click Operations logs).

View Reboot Logs is available on Classic VMs in the Dashboard of the Cloud Service in current portal and in Boot Diagnostics in the Azure Portal. Boot Diagnostics is available for RM VMs

July 2016

Support Type: Paid Assisted - Technical

Recommended approach

Create a case: Click on the

https://ms.portal.azure.com/Help + support tile in the Azure Portal and then on “New support request”.

Open a Support ticket under Technical and select Problem type: “connectivity” and Category: “Cannot connect to virtual machine by using RDP or SSH.”

Test: First, ensure the status is Running and restart the VM using the Azure portal. Then try connecting again. If this does not work,

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs/resizing your VM may help with your connection issues.

When resolving this issue, be sure to distinguish between Classic VMs (v1) and Resource Manager (ARM or v2) VMs, as there are additional options in the new portal for Classic VMs that are not yet available for ARM VMs.

Attempt to deploy the VMs in a new region. The new region may be more readily equipped to store the VMs at that time.

Solution 2:

Wait and try again. Microsoft’s engineers continuously adjust storage capacity and type in order to best accommodate your needs. By waiting and reattempting a deployment, you may find that the engineers have created additional space to accommodate the VM deployment request.

Most often, the root cause is a capacity issue. This error typically means that the cluster, or group of servers in a database, either does not have resources available or cannot support the deployed VM size.

Visit these articles to learn about troubleshooting allocation failures:

VM failed to provision: Restart the VM and retry connection, if error persists open a Support case.

VM stuck at OOBE (Out-of-the-box experience) screen, VM started but can’t RDP: Run

https://azure.microsoft.com/en-us/blog/boot-diagnostics-for-virtual-machines-v2/Boot Diagnostics to check the VM status. If that doesn’t help then recapture the image following the steps above or open a Support case.

VM failed to provision: Restart the VM and retry connection, if error persists open a Support case.

VM stuck at OOBE (Out-of-the-box experience) screen, VM started but can’t RDP: Run

https://azure.microsoft.com/en-us/blog/boot-diagnostics-for-virtual-machines-v2/Boot Diagnostics to check the VM status. If that doesn’t help then recapture the image following the steps above or open a Support case.

Step 2: Click “Manage” from the left navigation and click on the “Account” tab

Step 3: Hover over the account you wish to change to make the action items appear on the right, then click the transfer subscriptions icon (the icon on the far right)

Example

Step 5: Choose the target account, then click the “Submit” button to confirm

Step 4:

Choose the subscriptions you wish to transfer, then click the “Next” button to confirm

example

example

example

example

Good to know

“How do I transfer my EA subscription?”

Supported transfers:

Work/School account to another Work/School account

Microsoft account to a Work/School account

Microsoft account to another Microsoft account (Please note: the target Microsoft Account must have created an Azure subscription in order for it to be a valid target account. If the account is empty, please ask the Microsoft Account owner to first create an empty Azure subscription before attempting the transfer of subscriptions to the account)

Unsupported transfers:

Work/School account to Microsoft account

Before processing a subscription transfer, the account owner is advised to visit the

https://portal.azure.com/Azure Portal to take a screenshot of the subscription’s current service administrator and co-administrators. After the transfer of subscription(s) is complete, the new account owner needs to log on to the

https://portal.azure.com/Azure Portal, click into the relevant subscription and select the “edit subscription details” option on the right to either add or revoke service administrator and co-administrator access as appropriate.

Step 2: Click “Manage” from the left navigation and click on the “Account” tab

Step 3: Click “+Add Account” in the top right corner of the screen

Step 4: To create a new account, enter the account owner email address (if the account owner has an active Pay as You Go/MOSP account, this will transition the account and its subscriptions to the EA account)

Step 5: Confirm ownership by signing in to the EA Portal with the account owner email address

“How do I add an account?”

Good to know

The association of an account and its subscriptions happens on the day the account owner signs into the enterprise portal and thereby confirms association of the account owner email address

Existing subscriptions transferred to an Enterprise Enrollment will be immediately transitioned to billing on the Enterprise Enrollment on that day

The account owner is responsible for paying any outstanding charges on the payment instrument prior to the association date

All usage on transferred accounts will be billed based on terms of the Enterprise Enrollment. Subscriptions that were using a different offer type for payment, like Pay As You Go on a credit card, will be converted to Enterprise Offers. The automated process will rename the subscription appending the words “converted to EA” to the end of the subscription name so that you know it has made that transition.

June 2016

Important

If an account has subscriptions with special pricing (including no charge services), once transferred, the account will begin incurring costs based on the terms of the Azure Amendment to the Enterprise Enrollment.

Support Type: Free Assisted-

Enterprise Agreement

Recommended approach

Before you start: The Account Owner is the user role that can add new subscriptions on the EA Portal

Step 1: Log into the

https://ea.azure.com/EA Portal with the Account Owner credentials

Step 2: Select the “Admin” tab and navigate to “Subscription” on the top ribbon

Step 3: Click “+Add subscription”

Step 4: Click “Purchase”

PLEASE NOTE: The first time you add a new subscription to your enrollment from the enterprise portal, you will be asked to accept the MOSA agreement and Rate Plan. These sections are NOT Applicable to EA customers, but are necessary to provision the subscription.

Step 5: Fill out contact information and click the “Sign Up” button

Example

Example

Example

“How do I add a new subscription?”

Good to know

Subscription creation can take a few minutes so tutorials are offered while you wait

When the subscription is ready, you will see a link to the management portal. You will need to come back to the account portal to customize the subscription name or sign up for preview features

All new subscriptions will be added with the default “Microsoft Azure Enterprise” name. Therefore it is important to update the subscription name so that it is recognizable on reports at the enterprise level

June 2016

Quota increase is one of the top requests for which customers need support. The primary issue customers will face in this scenario is increasing quota beyond the default limit.

If your customers would like to increase quota, guide them to the Azure Portal. Here, they can assess their current usage to determine their exact quota increase need. Inform customers that they may increase quota up to the maximum value. Also be sure to let them know that a credit check may be performed depending on how many cores are requested. CSP, internal and EA customers do not go through credit checks. Quota increase, like all Subscription Management Support, is included as part of Azure Subscriptions at no extra charge. Many cases will be approved via automated capacity system to help the customer receive a core and cloud services increase more quickly (< 15 mins). Free trials and programs such as DreamSpark are not eligible for quota increase.

Other requests may create a support case and an engineer will contact the customer for further assistance.

Ownership transfer is a key volume driver within Azure Support and occurs when a customer would like to change the Azure subscription account administrator. This is most common during employee turnover or when responsibility is handed off from a service provider to a client.

Azure offers self-serve account ownership transfer for Pay-As-You-Go, MSDN, Action Pack and BizSpark customers, removing the need to open a support case for this process.

However, if your customer needs further assistance, direct them to create a support ticket in the Azure Portal. This is an included service that your customer can request at any time. Ensure that your customer knows the following details when opening a support ticket for ownership transfer:

Org ID or MSA (Live ID)

Owner status: are they the Account Admin or Service Admin (or both)?

Whether or not an O365 account is tied to the same credentials

To offer the best support, inform your customers that if their subscription is a member-offer with associated benefits, it must be transferred into an account with the same member-offer (such as MSDN, BizSpark etc.).

For CSP subscriptions, ownership transfers are only allowed between Cloud Service Providers. Both partners need to approve the transfer prior to moving the subscription. A transfer document needs to be signed by both providers, which is available on the Partner Center. Be sure to reiterate that the previous partner will still have access until they remove them as noted in the document they signed.

To request ownership transfer of a CSP subscription, please have the CSP submit a request through the Partner Center.

Step 1: Sign into the Usage and Billing Portal, select the relevant subscription and click on "Billing History" to view its billing information

Step 2: View your invoice

a) Click on "View Current Statement" to open the online statement of charges for the current month (updated daily)

b) Click on "Download invoice" to open a PDF copy of the selected period's statement

Details

Invoice Summary: Lists the total amount currently owed, including this month's charges, any previous balances, discounts, credits etc.

Usage Charges: Breaks down the amounts of each resource (e.g. Virtual Machines, Storage, etc.) that was consumed and billed.

For daily break downs of usage charges for each resource and more details about the .CSV file, please visit this scenario

For more details about your bill, visit this blog If you need additional support or have additional questions about your bill, open a support ticket under Billing

There are two versions of the detailed file. Both versions include a monthly and daily usage table with a row for each billable resource. Version 2 contains the same information as Version 1, yet with added fields and slight name variance for additional clarity. Version 2 is shown below. For more information and full list of field definitions, please visit this blog.

The top section of the file displays the details on the services you are being billed for during the previous month's billing cycle. The next section has a daily breakdown of the same information.

The Service Level Agreement (SLA) describes Microsoft's commitments for uptime and connectivity. A service incident is reported when Azure services experience an issue that impacts uptime or connectivity, often referred to as an "outage." If we do not achieve and maintain the Service Levels for each Service as described in the SLA, then you may be eligible for a credit towards a portion of your monthly service fees.

• For some services, there are conditions in the SLA e.g. Virtual Machines need to have two or more instances deployed in the same Availability Set

For more information please visit the SLA documentation page and the SLA summary page for Azure services

Virtual Machine restart is one of the most common scenarios for technical support and is generally a result of either planned or unplanned maintenance. You can determine if your restart was due to planned or unplanned maintenance by viewing your reboot logs. Learn how to view and understand those here.

Planned maintenance of the Azure platform occurs about every 2-3 months and is intended to keep the environment secure for all applications and virtual machines running on the platform. There is no option or configuration to avoid these host updates and they may result in the VM restarting, however proactive notification of planned maintenance is provided. Administrators and co-administrators are sent notifications of upcoming planned maintenance by AZCOMM. There are also portal toast notifications of planned maintenance and can change their update settings to put themselves more in control of when updates will take place.

Unplanned maintenance can result in a connectivity loss if Azure cannot reach the VM during regular monitoring. If the VM isn’t available or isn’t healthy, Azure will stop and restart the VM. If a VM is restarting, the status, (listed in the Azure Portal) will be shown as ‘Starting.’ After a restart, restart details can be found in the Azure Portal under Management Services (View Reboot Logs). Learn more about Azure Maintenance and avoiding downtime here.

Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft that is used to connect local machines to VMs running on Azure datacenters.

When it comes to VM RDP errors, the most common and generic error reported is the following: “remote desktop can’t find the computer computername. This might mean that computername does not belong to the specified network. Verify the computer name and domain that you are trying to connect to.”

To resolve this, there are two recommended options. First, ensure that the VM’s status is Running and restart the VM using the Azure Portal. Then try connecting again. If this does not work, resizing your VM may help with your connection issues. If this does not work, it is recommended to open a technical support ticket in the Azure Preview Portal. Click on the Help + support tile in the Azure Portal to start. From there, click “Create support request” and click on each of the three steps providing responses to the prompts clicking “Next.” Finally, click “Create.”

When resolving this issue, be sure to distinguish between Classic VMs (v1) and Resource Manager (RM) VMs (v2), as there are additional options in the Ibiza portal for Classic VMs that are not yet available for RM VMs.

Deep dive troubleshooting guides:

Troubleshoot Remote Desktop connections to Windows Azure VMs

Troubleshoot SSH connections to a Linux-based VM

Troubleshoot to an application running on Azure VMs

Additional information:

Read more about Azure infrastructure services implementation guidelines to avoid issues in the future

For Windows: read more about troubleshooting Remote Desktop connections and how to reset Remote Desktop service

For Linux: read more about how to reset the SSH configuration

It can be very difficult to migrate VMs to Premium storage. The advantage of doing so, however, is that with Premium storage, applications can reach up to 64TB of storage per VM and achieve 50,000 IOPS (input/output operations per second) per VM with extremely low latencies for read operations. Use the steps listed below in the new Azure Portal to ease the process.

Before you begin, be sure that you have both a Premium storage account into which you will copy your VHDs (virtual hard drives) and a tool such as AzCopy to upload the VHD into the storage account.

To migrate your VMs to Premium Storage, complete the following steps:

Shut down the designated VMs using Azure Portal in your standard storage account. Once the VM shutdown is complete, the disk is ready.

Delete the VM with the option "Keep the attached disk." Important: If you delete the VM, all data on the Temp Disk D:\ will be deleted (don’t store important data here!)

Copy all VHDs (OS Disks and Data Disks) that are attached to this VM from your standard account to your Premium account using the latest version of AzCopy. Once the download is complete, open Command prompt window and go to the location/path where AzCopy is installed. Copy the VHDs from the source storage location to destination storage location with the following command:

Create a new Resource Group or choose an existing and click “Create” to create the VM.

Attach data disks to the new VM once the VM has been created by selecting VM on https://portal.azure.com and choosing the option “Attach Existing” below Virtual machine /Settings/Disks.

Run the VM to see if it is running properly. If so, you can delete the VMs from the standard account (or keep them as back-up storage).

The number one root cause of VM performance issues is related to wrong storage configuration. A less common issue is that the physical host (node) is running out of memory. This article describes steps and provides resources for both standard users and more advanced users to resolve storage issues.

Before engaging support, there are a number of steps you can perform in order to resolve the issue. The general process is to check the VM configuration limits to determine if optimal levels are reached. First, explore the basics of VM configuration and how to configure a VM for optimal storage in this blog. Next, learn how to set up monitoring on a storage account here. Finally, download the IaaS Support Diagnostics Platform (SDP) package, which enables you to identify Azure VM and Azure platform storage and disk configuration issues that can cause performance degradation.

For advanced users with a good knowledge of how storage works, there are a number of useful resources we recommend. First, you can test their configuration to see if it reaches the system limits (see the technical blog here for instructions). If you would like to run through troubleshooting options on your own before contacting support, this tutorial provides many Microsoft and Azure Storage tools as well as a sample troubleshooting scenario with detailed end-to-end steps and information. If the above options do not resolve the issue, please contact support and open a ticket under Technical and select Virtual Machine.

When creating a VM, restarting a stopped VM, resizing a VM, or adding new web or worker role instances, some users encounter a failed allocation error message even though they have not yet reached their quota limit.

Most often, the root cause is a capacity issue. This error typically means that the cluster, or group of servers in a database, either does not have resources available or cannot support the deployed VM size.

The primary two solutions are to:

Attempt to deploy the VM in a new region. The new region may be more readily equipped to store your VMs at that time.

Wait and try again. Microsoft’s engineers continuously adjust storage capacity and type in order to best accommodate your needs. By waiting and reattempting a deployment, you may find that the engineers have created additional space to accommodate the VM deployment request.

If those do not work, open a support ticket in the Azure Portal.

When capturing a custom image, you may face a provision failure as a result of improper preparatory steps or selecting the wrong settings in image capture from the portal.

Note: Azure has two different resource deployment models: Classic (v1) and Resource Manager (v2). This article covers the process for capturing an image for the classic deployment model.

Step 1:

Prepare the guest OS by either running sysprep and checking the “Generalize” box (Windows) or using “sudo waagent –deprovision+user” (Linux).

Step 2:

If your VM was prepared on-premises, upload the VHD to Azure.

Step 3:

Capture the image in Azure, ensuring that you check the “I have run sysprep” box (Windows) or “I have run waagent –deprovision+user” box (Linux) when entering the Name and Description.

Visit the following links for detailed information on the processes for Windows and Linux.

Capture an image from an existing VM:

Windows guidelines

Linux guidelines

Upload a VHD and capture:

Windows guidelines

Linux guidelines

Provision failures may result in two common errors:

VM failed to provision: Restart the VM and retry connection, if error persists open a Support case.

VM stuck at OOBE screen, VM started but can’t RDP: Run Boot Diagnostics to check the VM status. If that doesn’t help then recapture the image following the steps above or open a Support case.

Learn about the benefits and limitations of sysprep here

Troubleshoot common deployment issues in Linux and Window

When capturing a custom image, you may face a provision failure as a result of improper preparatory steps or selecting the wrong settings in image capture from the portal.

Note: Azure has two different resource deployment models: Classic (v1) and Resource Manager (v2). This article covers the process for capturing an image for the Resource Manager (or “ARM”) deployment model.

Step 1:

Prepare the guest OS by either running sysprep and checking the “Generalize” box (Windows) or using “sudo waagent –deprovision+user” (Linux).

Step 2:

If your VM was prepared on-premises, upload the VHD to Azure.

Step 3:

Capture the image in Azure, ensuring that you have first marked your VM as “Generalized” in Azure through PowerShell or the Command Line Interface.

See the guidelines for capturing an image for Windows and Linux. If you need to upload your vhd from on-premises, you should use the Add-AzureRMVhd cmdlet.

Provision failures may result in two common errors:

VM failed to provision: Restart the VM and retry connection, if error persists open a Support case.

VM stuck at OOBE screen, VM started but can’t RDP: Run Boot Diagnostics to check the VM status. If that doesn’t help then recapture the image following the steps above or open a Support case.

Learn about the benefits and limitations of sysprep here

Troubleshoot common deployment issues in Linux and Windows

ng support, this tutorial provides many Microsoft and Azure Storage tools as well as a sample troubleshooting scenario with detailed end-to-end steps and information. If the above options do not resolve the issue, please contact support and open a ticket under Technical and select Virtual Machine.

When creating a VM, restarting a stopped VM, resizing a VM, or adding new web or worker role instances, some users encounter a failed allocation error message even though they have not yet reached their quota limit.

Most often, the root cause is a capacity issue. This error typically means that the cluster, or group of servers in a database, either does not have resources available or cannot support the deployed VM size.

The primary two solutions are to:

Attempt to deploy the VM in a new region. The new region may be more readily equipped to store your VMs at that time.

Wait and try again. Microsoft’s engineers continuously adjust storage capacity and type in order to best accommodate your needs. By waiting and reattempting a deployment, you may find that the engineers have created additional space to accommodate the VM deployment request.

If those do not work, open a support ticket in the Azure Portal.

When capturing a custom image, you may face a provision failure as a result of improper preparatory steps or selecting the wrong settings in image capture from the portal.

Note: Azure has two different resource deployment models: Classic (v1) and Resource Manager (v2). This article covers the process for capturing an image for the classic deployment model.

Step 1:

Prepare the guest OS by either running sysprep and checking the “Generalize” box (Windows) or using “sudo waagent –deprovision+user” (Linux).

Step 2:

If your VM was prepared on-premises, upload the VHD to Azure.

Step 3:

Capture the image in Azure, ensuring that you check the “I have run sysprep” box (Windows) or “I have run waagent –deprovision+user” box (Linux) when entering the Name and Description.

Visit the following links for detailed information on the processes for Windows and Linux.

Capture an image from an existing VM:

Windows guidelines

Linux guidelines

Upload a VHD and capture:

Windows guidelines

Linux guidelines

Provision failures may result in two common errors:

VM failed to provision: Restart the VM and retry connection, if error persists open a Support case.

VM stuck at OOBE screen, VM started but can’t RDP: Run Boot Diagnostics to check the VM status. If that doesn’t help then recapture the image following the steps above or open a Support case.

Learn about the benefits and limitations of sysprep here

Troubleshoot common deployment issues in Linux and Window

When capturing a custom image, you may face a provision failure as a result of improper preparatory steps or selecting the wrong settings in image capture from the portal.

Note: Azure has two different resource deployment models: Classic (v1) and Resource Manager (v2). This article covers the process for capturing an image for the Resource Manager (or “ARM”) deployment model.

Step 1:

Prepare the guest OS by either running sysprep and checking the “Generalize” box (Windows) or using “sudo waagent –deprovision+user” (Linux).

Step 2:

If your VM was prepared on-premises, upload the VHD to Azure.

Step 3:

Capture the image in Azure, ensuring that you have first marked your VM as “Generalized” in Azure through PowerShell or the Command Line Interface.