Azure VM Issues Troubleshooting Guide

Contents
Troubleshooting Azure VMs

Allocation failures
Allocation failures
Allocation failures for classic deployments
RDP
Reset RDP
RDP troubleshooting
Detailed RDP troubleshooting
Troubleshoot RDP error because the DHCP is disabled
Troubleshoot RDP error because of the NSG setting
Troubleshoot specific errors
Troubleshoot no license server errors
Troubleshoot remote desktop services issues
Troubleshoot An internal error
Troubleshoot connection disconnects frequently
Troubleshoot a general error
Troubleshoot authentication errors
Troubleshoot Azure VM RDP connection issues by Event ID
Troubleshoot RDP error in VM because of static IP
Troubleshoot RDP error in VM because the NIC is disabled
Troubleshoot RDP error caused by Safe Mode
Disable the guest OS Firewall in Azure VM
Enable or disable a firewall rule on a guest OS
Guest OS firewall is blocking inbound traffic
Guest OS firewall is misconfigured
Troubleshoot RDP error caused by netvsc.sys
SSH
SSH troubleshooting
Troubleshoot file system errors
Troubleshoot kernel-related boot problems
Troubleshoot fstab errors
Detailed SSH troubleshooting
Common error messages
Performance issues with Windows VMs
How to use PerfInsights
Performance diagnostics extension
Install Windows VM agent offline
Redeploy a VM
Linux
Windows
Reset VM password
Windows
Linux
Reset NIC
Restarting or resizing a VM
Use the serial console
Linux VM
Serial Console GRUB/Single user mode
Serial Console NMI/SysRq
Windows VM
CMD and PowerShell commands
Errors when deleting storage resources
Errors when deleting classic storage resources
Unexpected reboots of VMs with attached VHDs
Windows activation problems
Activation problem with forced tunneling
Application access issues
New VM deployments
Linux
Windows
Troubleshoot deployments
Linux
Linux
Windows
Device names are changed
VM recovery access
Windows
PowerShell
Azure portal
Linux
CLI
Azure portal
Boot errors
Boot diagnostics
BitLocker errors
Checking file system errors
Blue screen errors
VM startup is stuck
Critical service failed
Reboot loop
Stuck at Windows update
Throttling errors
Use nested virtualization
Understand a system reboot
Remote troubleshooting tools
Allocation failures
Allocation failures
Allocation failures for classic deployments
Boot diagnostics
RDP
Reset RDP
RDP troubleshooting
SSH
SSH troubleshooting
Detailed SSH troubleshooting
Common error messages
Performance issues with Windows VMs
Performance diagnostics extension
Install Windows VM agent offline
Redeploy a VM
Linux
Windows
Reset VM password
Windows
Linux
Reset NIC
Restarting or resizing a VM
Use the serial console
Linux VM
Serial Console GRUB/Single user mode
Serial Console NMI/SysRq
Windows VM
CMD and PowerShell commands
Errors when deleting storage resources
Unexpected reboots of VMs with attached VHDs
Windows activation problems
Application access issues
Troubleshoot deployments
Linux
Windows
Device names are changed
VM recovery access
Windows
PowerShell
Azure portal
Linux
CLI
Azure portal
Boot errors
BitLocker errors
Checking file system errors
Blue screen errors
Throttling errors
Use nested virtualization
Understand a system reboot
Troubleshoot allocation failures when you create,
restart, or resize VMs in Azure
3/21/2019 • 6 minutes to read • Edit Online
When you create a virtual machine (VM ), restart stopped (deallocated) VMs, or resize a VM, Microsoft Azure
allocates compute resources to your subscription. We are continually investing in additional infrastructure and
features to make sure that we always have all VM types available to support customer demand. However, you may
occasionally experience resource allocation failures because of unprecedented growth in demand for Azure
services in specific regions. This problem can occur when you try to create or start VMs in a region while the VMs
display the following error code and message:
Error code: AllocationFailed or ZonalAllocationFailed
Error message: "Allocation failed. We do not have sufficient capacity for the requested VM size in this region. Read
more about improving likelihood of allocation success at https://aka.ms/allocation-guidance"
This article explains the causes of some of the common allocation failures and suggests possible remedies.
If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and Stack Overflow. You can
post your issue on these forums or to @AzureSupport on Twitter. Also, you can file an Azure support request by
selecting Get support on the Azure support site.
Until your preferred VM type is available in your preferred region, we advise customers who encounter
deployment issues to consider the guidance in the following table as a temporary workaround.
Identify the scenario that best matches your case, and then retry the allocation request by using the corresponding
suggested workaround to increase the likelihood of allocation success. Alternatively, you can always retry later. This
is because enough resources may have been freed in the cluster, region, or zone to accommodate your request.
Resize a VM or add VMs to an existing availability set

Cause
A request to resize a VM or add a VM to an existing availability set must be tried at the original cluster that hosts
the existing availability set. The requested VM size is supported by the cluster, but the cluster may not currently
have sufficient capacity.
Workaround
If the VM can be part of a different availability set, create a VM in a different availability set (in the same region).
This new VM can then be added to the same virtual network.
Stop (deallocate) all VMs in the same availability set, then restart each one. To stop: Click Resource groups > [your
resource group] > Resources > [your availability set] > Virtual Machines > [your virtual machine] > Stop. After all
VMs stop, select the first VM, and then click Start. This step makes sure that a new allocation attempt is run and
that a new cluster can be selected that has sufficient capacity.
Restart partially stopped (deallocated) VMs

Cause
Partial deallocation means that you stopped (deallocated) one or more, but not all, VMs in an availability set. When
you deallocate a VM, the associated resources are released. Restarting VMs in a partially deallocated availability set
is the same as adding VMs to an existing availability set. Therefore, the allocation request must be tried at the
original cluster that hosts the existing availability set that may not have sufficient capacity.
Workaround
Stop (deallocate) all VMs in the same availability set, then restart each one. To stop: Click Resource groups > [your
resource group] > Resources > [your availability set] > Virtual Machines > [your virtual machine] > Stop. After all
VMs stop, select the first VM, and then click Start. This will make sure that a new allocation attempt is run and that
a new cluster can be selected that has sufficient capacity.
Restart fully stopped (deallocated) VMs

Cause
Full deallocation means that you stopped (deallocated) all VMs in an availability set. The allocation request to
restart these VMs will target all clusters that support the desired size within the region or zone. Change your
allocation request per the suggestions in this article, and retry the request to improve the chance of allocation
success.
Workaround
If you use older VM series or sizes, such as Dv1, DSv1, Av1, D15v2, or DS15v2, consider moving to newer
versions. See these recommendations for specific VM sizes. If you don’t have the option to use a different VM size,
try deploying to a different region within the same geo. For more information about the available VM sizes in each
region at https://aka.ms/azure-regions
If you are using availability zones, try another zone within the region that may have available capacity for the
requested VM size.
If your allocation request is large (more than 500 cores), see the guidance in the following sections to break up the
request into smaller deployments.
Allocation failures for older VM sizes (Av1, Dv1, DSv1, D15v2, DS15v2,
etc.)
As we expand Azure infrastructure, we deploy newer-generation hardware that’s designed to support the latest
virtual machine types. Some of the older series VMs do not run on our latest generation infrastructure. For this
reason, customers may occasionally experience allocation failures for these legacy SKUs. To avoid this problem, we
encourage customers who are using legacy series virtual machines to consider moving to the equivalent newer
VMs per the following recommendations: These VMs are optimized for the latest hardware and will let you take
advantage of better pricing and performance.
LEGACY VM-SERIES/SIZE RECOMMENDED NEWER VM-SERIES/SIZE MORE INFORMATION
Av1-series Av2-series https://azure.microsoft.com/blog/new-

av2-series-vm-sizes/
Dv1 or DSv1-series (D1 to D5) Dv3 or DSv3-series https://azure.microsoft.com/blog/introd

ucing-the-new-dv3-and-ev3-vm-sizes/
Dv1 or DSv1-series (D11 to D14) Ev3 or ESv3-series

LEGACY VM-SERIES/SIZE RECOMMENDED NEWER VM-SERIES/SIZE MORE INFORMATION
D15v2 or DS15v2 If you are using theResource Manager https://azure.microsoft.com/blog/new-

deployment model in order to take isolated-vm-sizes-now-available/
advantage of the larger VM sizes,
consider moving to D16v3/DS16v3 or
D32v3/DS32v3. These are designed to
run on the latest generation hardware.
If you are using the Resource Manager
deployment model to make sure your
VM instance is isolated to hardware
dedicated to a single customer, consider
moving to the new isolated VM sizes,
E64i_v3 or E64is_v3, which are designed
to run on the latest generation
hardware.
Allocation failures for large deployments (more than 500 cores)

Reduce the number of instances of the requested VM size, and then retry the deployment operation. Additionally,
for larger deployments, you may want to evaluate Azure virtual machine scale sets. The number of VM instances
can automatically increase or decrease in response to demand or a defined schedule, and you have a greater
chance of allocation success because the deployments can be spread across multiple clusters.
Background information
How allocation works
The servers in Azure datacenters are partitioned into clusters. Normally, an allocation request is attempted in
multiple clusters, but it's possible that certain constraints from the allocation request force the Azure platform to
attempt the request in only one cluster. In this article, we'll refer to this as "pinned to a cluster." Diagram 1 below
illustrates the case of a normal allocation that is attempted in multiple clusters. Diagram 2 illustrates the case of an
allocation that's pinned to Cluster 2 because that's where the existing Cloud Service CS_1 or availability set is
hosted.
Why allocation failures happen
When an allocation request is pinned to a cluster, there's a higher chance of failing to find free resources since the
available resource pool is smaller. Furthermore, if your allocation request is pinned to a cluster but the type of
resource you requested is not supported by that cluster, your request will fail even if the cluster has free resources.
The following Diagram 3 illustrates the case where a pinned allocation fails because the only candidate cluster does
not have free resources. Diagram 4 illustrates the case where a pinned allocation fails because the only candidate
cluster does not support the requested VM size, even though the cluster has free resources.
Troubleshooting steps specific to allocation failure
scenarios in the classic deployment model
The following are common allocation scenarios that cause an allocation request to be pinned. We'll dive into each
scenario later in this article.
Resize a VM or add VMs or role instances to an existing cloud service
Staging and production deployments (platform as a service only)
Affinity group (VM or service proximity)
Affinity–group-based virtual network
When you receive an allocation error, check whether any of the listed scenarios apply to your error. Use the
allocation error that’s returned by the Azure platform to identify the corresponding scenario. If your request is
pinned, remove some of the pinning constraints to open your request to more clusters, thereby increasing the
chance of allocation success. In general, if the error does not state that "the requested VM size is not supported,"
you can always retry at a later time. This is because enough resources may have been freed in the cluster to
accommodate your request. If the problem is that the requested VM size is not supported, try a different VM size.
Otherwise, the only option is to remove the pinning constraint.
Two common failure scenarios are related to affinity groups. In the past, an affinity group was used to provide close
proximity to VMs and service instances, or it was used to enable the creation of a virtual network. With the
introduction of regional virtual networks, affinity groups are no longer required to create a virtual network. With
the reduction of network latency in Azure infrastructure, the recommendation to use affinity groups for VMs or
service proximity has changed.
The following Diagram presents the taxonomy of the (pinned) allocation scenarios.
Resize a VM or add VMs or role instances to an existing cloud service

Error
Upgrade_VMSizeNotSupported or GeneralError
Cause of cluster pinning
A request to resize a VM or add a VM or a role instance to an existing cloud service has to be attempted at the
original cluster that hosts the existing cloud service. Creating a new cloud service allows the Azure platform to find
another cluster that has free resources or supports the VM size that you requested.
Workaround
If the error is Upgrade_VMSizeNotSupported*, try a different VM size. If using a different VM size is not an option,
but if it's acceptable to use a different virtual IP address (VIP ), create a new cloud service to host the new VM and
add the new cloud service to the regional virtual network where the existing VMs are running. If your existing
cloud service does not use a regional virtual network, you can still create a new virtual network for the new cloud
service, and then connect your existing virtual network to the new virtual network. See more about regional virtual
networks.
If the error is GeneralError*, it's likely that the type of resource (such as a particular VM size) is supported by the
cluster, but the cluster does not have free resources at the moment. Similar to the above scenario, add the desired
compute resource through creating a new cloud service (note that the new cloud service has to use a different VIP )
and use a regional virtual network to connect your cloud services.

Error
GeneralError*
Partial deallocation means that you stopped (deallocated) one or more, but not all, VMs in a cloud service. When
you stop (deallocate) a VM, the associated resources are released. Restarting that stopped (deallocated) VM is
therefore a new allocation request. Restarting VMs in a partially deallocated cloud service is equivalent to adding
VMs to an existing cloud service. The allocation request has to be attempted at the original cluster that hosts the
existing cloud service. Creating a different cloud service allows the Azure platform to find another cluster that has
free resource or supports the VM size that you requested.
Workaround
If it's acceptable to use a different VIP, delete the stopped (deallocated) VMs (but keep the associated disks) and
add the VMs back through a different cloud service. Use a regional virtual network to connect your cloud services:
If your existing cloud service uses a regional virtual network, simply add the new cloud service to the same
virtual network.
If your existing cloud service does not use a regional virtual network, create a new virtual network for the new
cloud service, and then connect your existing virtual network to the new virtual network. See more about
regional virtual networks.

Error
GeneralError*
Full deallocation means that you stopped (deallocated) all VMs from a cloud service. The allocation requests to
restart these VMs have to be attempted at the original cluster that hosts the cloud service. Creating a new cloud
service allows the Azure platform to find another cluster that has free resources or supports the VM size that you
requested.
Workaround
If it's acceptable to use a different VIP, delete the original stopped (deallocated) VMs (but keep the associated
disks) and delete the corresponding cloud service (the associated compute resources were already released when
you stopped (deallocated) the VMs). Create a new cloud service to add the VMs back.
Staging/production deployments (platform as a service only)

Error
New_General* or New_VMSizeNotSupported*
The staging deployment and the production deployment of a cloud service are hosted in the same cluster. When
you add the second deployment, the corresponding allocation request will be attempted in the same cluster that
hosts the first deployment.
Workaround
Delete the first deployment and the original cloud service and redeploy the cloud service. This action may land the
first deployment in a cluster that has enough free resources to fit both deployments or in a cluster that supports
the VM sizes that you requested.
Affinity group (VM/service proximity)

Error
Any compute resource assigned to an affinity group is tied to one cluster. New compute resource requests in that
affinity group are attempted in the same cluster where the existing resources are hosted. This is true whether the
new resources are created through a new cloud service or through an existing cloud service.
Workaround
If an affinity group is not necessary, do not use an affinity group, or group your compute resources into multiple
affinity groups.
Affinity-group-based virtual network

Error
Before regional virtual networks were introduced, you were required to associate a virtual network with an affinity
group. As a result, compute resources placed into an affinity group are bound by the same constraints as described
in the "Allocation scenario: Affinity group (VM/service proximity)" section above. The compute resources are tied to
one cluster.
Workaround
If you do not need an affinity group, create a new regional virtual network for the new resources you're adding, and
then connect your existing virtual network to the new virtual network. See more about regional virtual networks.
Alternatively, you can migrate your affinity-group-based virtual network to a regional virtual network , and then
add the desired resources again.
Troubleshoot RDP issues
The following issues with creating an RDP to connection to a VM are covered in this section:
Reset RDP
RDP troubleshooting
Troubleshoot RDP error because the DHCP is disabled
Troubleshoot RDP error because of the NSG setting
Troubleshoot no license server errors
Troubleshoot remote desktop services issues
Troubleshoot An internal error
Troubleshoot connection disconnects frequently
Troubleshoot a general error
Troubleshoot authentication errors
Troubleshoot Azure VM RDP connection issues by Event ID
Troubleshoot RDP error in VM because of static IP
Troubleshoot RDP error in VM because the NIC is disabled
Troubleshoot RDP error caused by Safe Mode
Enable or disable a firewall rule on a guest OS
Guest OS firewall is blocking inbound traffic
Guest OS firewall is misconfigured
Troubleshoot RDP error caused by netvsc.sys
Reset Remote Desktop Services or its administrator
password in a Windows VM
If you can't connect to a Windows virtual machine (VM ), you can reset your local administrator password or reset
the Remote Desktop Services configuration (not supported on Windows domain controllers). To reset the
password, use either the Azure portal or the VM Access extension in Azure PowerShell. After you've signed in to
the VM, reset the password for that local administrator.
If you're using PowerShell, make sure that you have the latest PowerShell module installed and configured and
are signed in to your Azure subscription. You can also perform these steps for VMs created with the classic
deployment model.
You can reset Remote Desktop Services and credentials in the following ways:
Reset by using the Azure portal
Reset by using the VMAccess extension and PowerShell
Reset by using the Azure portal

First, sign in to the Azure portal and then select Virtual machines on the left menu.
Reset the local administrator account password
1. Select your Windows VM and then select Reset password under Support + Troubleshooting. The Reset
password window is displayed.
2. Select Reset password, enter a username and a password, and then select Update.
3. Try connecting to your VM again.
Reset the Remote Desktop Services configuration
This process will enable Remote Desktop service in the VM, and create a firewall rule for the default RDP port
3389.
1. Select your Windows VM and then select Reset password under Support + Troubleshooting. The Reset
password window is displayed.
2. Select Reset configuration only and then select Update.
3. Try connecting to your VM again.
Reset by using the VMAccess extension and PowerShell

First, make sure that you have the latest PowerShell module installed and configured and are signed in to your
Azure subscription by using the Connect-AzAccount cmdlet.
Reset the local administrator account password
Reset the administrator password or user name with the Set-AzVMAccessExtension PowerShell cmdlet.
The typeHandlerVersion setting must be 2.0 or greater, because version 1 is deprecated.
$SubID = "<SUBSCRIPTION ID>"
$RgName = "<RESOURCE GROUP NAME>"
$VmName = "<VM NAME>"
$Location = "<LOCATION>"
Connect-AzAccount
Select-AzSubscription -SubscriptionId $SubID
Set-AzVMAccessExtension -ResourceGroupName $RgName -Location $Location -VMName $VmName -Credential
(get-credential) -typeHandlerVersion "2.0" -Name VMAccessAgent
NOTE
If you enter a different name than the current local administrator account on your VM, the VMAccess extension will
add a local administrator account with that name, and assign your specified password to that account. If the local
administrator account on your VM exists, the VMAccess extension will reset the password. If the account is disabled,
the VMAccess extension will enable it.
Reset the Remote Desktop Services configuration

1. Reset remote access to your VM with the Set-AzVMAccessExtension PowerShell cmdlet. The following
example resets the access extension named myVMAccess on the VM named myVM in the myResourceGroup
resource group:
Set-AzVMAccessExtension -ResourceGroupName "myResoureGroup" -VMName "myVM" -Name "myVMAccess" -Location

WestUS -typeHandlerVersion "2.0" -ForceRerun
TIP
At any point, a VM can have only a single VM access agent. To set the VM access agent properties, use the
-ForceRerun option. When you use -ForceRerun , ensure you use the same name for the VM access agent that
you might have used in any previous commands.
2. If you still can't connect remotely to your virtual machine, see Troubleshoot Remote Desktop connections to
a Windows-based Azure virtual machine. If you lose the connection to the Windows domain controller, you
will need to restore it from a domain controller backup.
Next steps
If the Azure VM access extension doesn't respond and you're unable to reset the password, you can reset
the local Windows password offline. This method is more advanced and requires you to connect the virtual
hard disk of the problematic VM to another VM. Follow the steps documented in this article first, and
attempt the offline password reset method only if those steps don't work.
Learn about Azure VM extensions and features.
Connect to an Azure virtual machine with RDP or SSH.
Troubleshoot Remote Desktop connections to a Windows-based Azure virtual machine.
Troubleshoot Remote Desktop connections to an
Azure virtual machine
The Remote Desktop Protocol (RDP ) connection to your Windows-based Azure virtual machine (VM ) can fail for
various reasons, leaving you unable to access your VM. The issue can be with the Remote Desktop service on the
VM, the network connection, or the Remote Desktop client on your host computer. This article guides you
through some of the most common methods to resolve RDP connection issues.
If you need more help at any point in this article, you can contact the Azure experts on the MSDN Azure and
Stack Overflow forums. Alternatively, you can file an Azure support incident. Go to the Azure support site and
select Get Support.
NOTE
This article has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which
will continue to receive bug fixes until at least December 2020. To learn more about the new Az module and AzureRM
compatibility, see Introducing the new Azure PowerShell Az module. For Az module installation instructions, see Install
Azure PowerShell.
Quick troubleshooting steps

After each troubleshooting step, try reconnecting to the VM:
1. Reset Remote Desktop configuration.
2. Check Network Security Group rules / Cloud Services endpoints.
3. Review VM console logs.
4. Reset the NIC for the VM.
5. Check the VM Resource Health.
6. Reset your VM password.
7. Restart your VM.
8. Redeploy your VM.
Continue reading if you need more detailed steps and explanations. Verify that local network equipment such as
routers and firewalls are not blocking outbound TCP port 3389, as noted in detailed RDP troubleshooting
scenarios.
TIP
If the Connect button for your VM is grayed out in the portal and you are not connected to Azure via an Express Route or
Site-to-Site VPN connection, you need to create and assign your VM a public IP address before you can use RDP. You can
read more about public IP addresses in Azure.
Ways to troubleshoot RDP issues

You can troubleshoot VMs created using the Resource Manager deployment model by using one of the
following methods:
Azure portal - great if you need to quickly reset the RDP configuration or user credentials and you don't have
the Azure tools installed.
Azure PowerShell - if you are comfortable with a PowerShell prompt, quickly reset the RDP configuration or
user credentials using the Azure PowerShell cmdlets.
You can also find steps on troubleshooting VMs created using the Classic deployment model.
Troubleshoot using the Azure portal

After each troubleshooting step, try connecting to your VM again. If you still cannot connect, try the next step.
1. Reset your RDP connection. This troubleshooting step resets the RDP configuration when Remote
Connections are disabled or Windows Firewall rules are blocking RDP, for example.
Select your VM in the Azure portal. Scroll down the settings pane to the Support + Troubleshooting
section near bottom of the list. Click the Reset password button. Set the Mode to Reset configuration
only and then click the Update button:
2. Verify Network Security Group rules. Use IP flow verify to confirm if a rule in a Network Security
Group is blocking traffic to or from a virtual machine. You can also review effective security group rules to
ensure inbound "Allow" NSG rule exists and is prioritized for RDP port(default 3389). For more
information, see Using Effective Security Rules to troubleshoot VM traffic flow.
3. Review VM boot diagnostics. This troubleshooting step reviews the VM console logs to determine if
the VM is reporting an issue. Not all VMs have boot diagnostics enabled, so this troubleshooting step
may be optional.
Specific troubleshooting steps are beyond the scope of this article, but may indicate a wider problem that
is affecting RDP connectivity. For more information on reviewing the console logs and VM screenshot,
see Boot Diagnostics for VMs.
4. Reset the NIC for the VM. For more information, see how to reset NIC for Azure Windows VM.
5. Check the VM Resource Health. This troubleshooting step verifies there are no known issues with the
Azure platform that may impact connectivity to the VM.
section near bottom of the list. Click the Resource health button. A healthy VM reports as being
Available:
6. Reset user credentials. This troubleshooting step resets the password on a local administrator account
when you are unsure or have forgotten the credentials. Once you have logged into the VM, you should
reset the password for that user.
section near bottom of the list. Click the Reset password button. Make sure the Mode is set to Reset
password and then enter your username and a new password. Finally, click the Update button:
7. Restart your VM. This troubleshooting step can correct any underlying issues the VM itself is having.
Select your VM in the Azure portal and click the Overview tab. Click the Restart button:
8. Redeploy your VM. This troubleshooting step redeploys your VM to another host within Azure to
correct any underlying platform or networking issues.
section near bottom of the list. Click the Redeploy button, and then click Redeploy:
After this operation finishes, ephemeral disk data is lost and dynamic IP addresses that are associated
with the VM are updated.
9. Verify routing. Use Network Watcher's Next hop capability to confirm that a route isn't preventing traffic
from being routed to or from a virtual machine. You can also review effective routes to see all effective
routes for a network interface. For more information, see Using effective routes to troubleshoot VM traffic
flow.
10. Ensure that any on-premises firewall, or firewall on your computer, allows outbound TCP 3389 traffic to
Azure.
If you are still encountering RDP issues, you can open a support request or read more detailed RDP
troubleshooting concepts and steps.
Troubleshoot using Azure PowerShell

If you haven't already, install and configure the latest Azure PowerShell.
The following examples use variables such as myResourceGroup , myVM , and myVMAccessExtension . Replace these
variable names and locations with your own values.
NOTE
You reset the user credentials and the RDP configuration by using the Set-AzVMAccessExtension PowerShell cmdlet. In the
following examples, myVMAccessExtension is a name that you specify as part of the process. If you have previously
worked with the VMAccessAgent, you can get the name of the existing extension by using
Get-AzVM -ResourceGroupName "myResourceGroup" -Name "myVM" to check the properties of the VM. To view the name,
look under the 'Extensions' section of the output.
The follow example resets the RDP connection on a VM named myVM in the WestUS location and in the
resource group named myResourceGroup :
Set-AzVMAccessExtension -ResourceGroupName "myResourceGroup" `

-VMName "myVM" -Location Westus -Name "myVMAccessExtension"
2. Verify Network Security Group rules. This troubleshooting step verifies that you have a rule in your
Network Security Group to permit RDP traffic. The default port for RDP is TCP port 3389. A rule to
permit RDP traffic may not be created automatically when you create your VM.
First, assign all the configuration data for your Network Security Group to the $rules variable. The
following example obtains information about the Network Security Group named
myNetworkSecurityGroup in the resource group named myResourceGroup :
$rules = Get-AzNetworkSecurityGroup -ResourceGroupName "myResourceGroup" `

-Name "myNetworkSecurityGroup"
Now, view the rules that are configured for this Network Security Group. Verify that a rule exists to allow
TCP port 3389 for inbound connections as follows:
$rules.SecurityRules
The following example shows a valid security rule that permits RDP traffic. You can see Protocol ,
DestinationPortRange , Access , and Direction are configured correctly:
Name : default-allow-rdp
Id :
/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/m
yNetworkSecurityGroup/securityRules/default-allow-rdp
Etag :
ProvisioningState : Succeeded
Description :
Protocol : TCP
SourcePortRange : *
DestinationPortRange : 3389
SourceAddressPrefix : *
DestinationAddressPrefix : *
Access : Allow
Priority : 1000
Direction : Inbound
If you do not have a rule that allows RDP traffic, create a Network Security Group rule. Allow TCP port
3389.
3. Reset user credentials. This troubleshooting step resets the password on the local administrator account
that you specify when you are unsure of, or have forgotten, the credentials.
First, specify the username and a new password by assigning credentials to the $cred variable as follows:
$cred=Get-Credential
Now, update the credentials on your VM. The following example updates the credentials on a VM named
myVM in the WestUS location and in the resource group named myResourceGroup :
Set-AzVMAccessExtension -ResourceGroupName "myResourceGroup" `

-VMName "myVM" -Location WestUS -Name "myVMAccessExtension" `
-UserName $cred.GetNetworkCredential().Username `
-Password $cred.GetNetworkCredential().Password
The following example restarts the VM named myVM in the resource group named myResourceGroup :
Restart-AzVM -ResourceGroup "myResourceGroup" -Name "myVM"
5. Redeploy your VM. This troubleshooting step redeploys your VM to another host within Azure to
correct any underlying platform or networking issues.
The following example redeploys the VM named myVM in the WestUS location and in the resource group
named myResourceGroup :
Set-AzVM -Redeploy -ResourceGroupName "myResourceGroup" -Name "myVM"
6. Verify routing. Use Network Watcher's Next hop capability to confirm that a route isn't preventing traffic
from being routed to or from a virtual machine. You can also review effective routes to see all effective
routes for a network interface. For more information, see Using effective routes to troubleshoot VM traffic
flow.
Azure.
Troubleshoot VMs created using the Classic deployment model

After each troubleshooting step, try reconnecting to the VM.
Select your VM in the Azure portal. Click the ...More button, then click Reset Remote Access:
2. Verify Cloud Services endpoints. This troubleshooting step verifies that you have endpoints in your
Cloud Services to permit RDP traffic. The default port for RDP is TCP port 3389. A rule to permit RDP
traffic may not be created automatically when you create your VM.
Select your VM in the Azure portal. Click the Endpoints button to view the endpoints currently
configured for your VM. Verify that endpoints exist that allow RDP traffic on TCP port 3389.
The following example shows valid endpoints that permit RDP traffic:
If you do not have an endpoint that allows RDP traffic, create a Cloud Services endpoint. Allow TCP to
private port 3389.
3. Review VM boot diagnostics. This troubleshooting step reviews the VM console logs to determine if
the VM is reporting an issue. Not all VMs have boot diagnostics enabled, so this troubleshooting step
may be optional.
Specific troubleshooting steps are beyond the scope of this article, but may indicate a wider problem that
is affecting RDP connectivity. For more information on reviewing the console logs and VM screenshot,
see Boot Diagnostics for VMs.
4. Check the VM Resource Health. This troubleshooting step verifies there are no known issues with the
Azure platform that may impact connectivity to the VM.
section near bottom of the list. Click the Resource Health button. A healthy VM reports as being
Available:
5. Reset user credentials. This troubleshooting step resets the password on the local administrator account
that you specify when you are unsure or have forgotten the credentials. Once you have logged into the
VM, you should reset the password for that user.
section near bottom of the list. Click the Reset password button. Enter your username and a new
password. Finally, click the Save button:
Select your VM in the Azure portal and click the Overview tab. Click the Restart button:
Azure.
Troubleshoot specific RDP errors

You may encounter a specific error message when trying to connect to your VM via RDP. The following are the
most common error messages:
The remote session was disconnected because there are no Remote Desktop License Servers available to
provide a license.
Remote Desktop can't find the computer "name".
An authentication error has occurred. The Local Security Authority cannot be contacted.
Windows Security error: Your credentials did not work.
This computer can't connect to the remote computer.
Additional resources
If none of these errors occurred and you still can't connect to the VM via Remote Desktop, read the detailed
troubleshooting guide for Remote Desktop.
For troubleshooting steps in accessing applications running on a VM, see Troubleshoot access to an
application running on an Azure VM.
If you are having issues using Secure Shell (SSH) to connect to a Linux VM in Azure, see Troubleshoot SSH
connections to a Linux VM in Azure.
Detailed troubleshooting steps for remote desktop
connection issues to Windows VMs in Azure
This article provides detailed troubleshooting steps to diagnose and fix complex Remote Desktop errors for
Windows-based Azure virtual machines.
IMPORTANT
To eliminate the more common Remote Desktop errors, make sure to read the basic troubleshooting article for Remote
Desktop before proceeding.
You may encounter a Remote Desktop error message that does not resemble any of the specific error messages
covered in the basic Remote Desktop troubleshooting guide. Follow these steps to determine why the Remote
Desktop (RDP ) client is unable to connect to the RDP service on the Azure VM.
NOTE
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager
model.
If you need more help at any point in this article, you can contact the Azure experts on the MSDN Azure and the
Stack Overflow forums. Alternatively, you can also file an Azure support incident. Go to the Azure Support site
and click Get Support. For information about using Azure Support, read the Microsoft Azure Support FAQ.
Components of a Remote Desktop connection

The following components are involved in an RDP connection:
Before proceeding, it might help to mentally review what has changed since the last successful Remote Desktop
connection to the VM. For example:
The public IP address of the VM or the cloud service containing the VM (also called the virtual IP address
VIP ) has changed. The RDP failure could be because your DNS client cache still has the old IP address
registered for the DNS name. Flush your DNS client cache and try connecting the VM again. Or try
connecting directly with the new VIP.
You are using a third-party application to manage your Remote Desktop connections instead of using the
connection generated by the Azure portal. Verify that the application configuration includes the correct TCP
port for the Remote Desktop traffic. You can check this port for a classic virtual machine in the Azure portal,
by clicking the VM's Settings > Endpoints.
Preliminary steps
Before proceeding to the detailed troubleshooting,
Check the status of the virtual machine in the Azure portal for any obvious issues.
Follow the quick fix steps for common RDP errors in the basic troubleshooting guide.
For custom images, make sure that your VHD is properly prepared prior to upload it. For more information,
see Prepare a Windows VHD or VHDX to upload to Azure.
Try reconnecting to the VM via Remote Desktop after these steps.
Detailed troubleshooting steps

The Remote Desktop client may not be able to reach the Remote Desktop service on the Azure VM due to issues
at the following sources:
Remote Desktop client computer
Organization intranet edge device
Cloud service endpoint and access control list (ACL )
Network security groups
Windows-based Azure VM
Source 1: Remote Desktop client computer

Verify that your computer can make Remote Desktop connections to another on-premises, Windows-based
computer.
If you cannot, check for the following settings on your computer:

A local firewall setting that is blocking Remote Desktop traffic.
Locally installed client proxy software that is preventing Remote Desktop connections.
Locally installed network monitoring software that is preventing Remote Desktop connections.
Other types of security software that either monitor traffic or allow/disallow specific types of traffic that is
preventing Remote Desktop connections.
In all these cases, temporarily disable the software and try to connect to an on-premises computer via Remote
Desktop. If you can find out the actual cause this way, work with your network administrator to correct the
software settings to allow Remote Desktop connections.
Source 2: Organization intranet edge device

Verify that a computer directly connected to the Internet can make Remote Desktop connections to your Azure
virtual machine.
If you do not have a computer that is directly connected to the Internet, create and test with a new Azure virtual
machine in a resource group or cloud service. For more information, see Create a virtual machine running
Windows in Azure. You can delete the virtual machine and the resource group or the cloud service, after the test.
If you can create a Remote Desktop connection with a computer directly attached to the Internet, check your
organization intranet edge device for:
An internal firewall blocking HTTPS connections to the Internet.
A proxy server preventing Remote Desktop connections.
Intrusion detection or network monitoring software running on devices in your edge network that is
preventing Remote Desktop connections.
Work with your network administrator to correct the settings of your organization intranet edge device to allow
HTTPS -based Remote Desktop connections to the Internet.
Source 3: Cloud service endpoint and ACL

For VMs created using the Classic deployment model, verify that another Azure VM that is in the same cloud
service or virtual network can make Remote Desktop connections to your Azure VM.
NOTE
For virtual machines created in Resource Manager, skip to Source 4: Network Security Groups.
If you do not have another virtual machine in the same cloud service or virtual network, create one. Follow the
steps in Create a virtual machine running Windows in Azure. Delete the test virtual machine after the test is
completed.
If you can connect via Remote Desktop to a virtual machine in the same cloud service or virtual network, check
for these settings:
The endpoint configuration for Remote Desktop traffic on the target VM: The private TCP port of the endpoint
must match the TCP port on which the VM's Remote Desktop service is listening (default is 3389).
The ACL for the Remote Desktop traffic endpoint on the target VM: ACLs allow you to specify allowed or
denied incoming traffic from the Internet based on its source IP address. Misconfigured ACLs can prevent
incoming Remote Desktop traffic to the endpoint. Check your ACLs to ensure that incoming traffic from your
public IP addresses of your proxy or other edge server is allowed. For more information, see What is a
Network Access Control List (ACL )?
To check if the endpoint is the source of the problem, remove the current endpoint and create a new one,
choosing a random port in the range 49152–65535 for the external port number. For more information, see How
to set up endpoints to a virtual machine.
Source 4: Network Security Groups

Network Security Groups allow more granular control of allowed inbound and outbound traffic. You can create
rules spanning subnets and cloud services in an Azure virtual network.
Use IP flow verify to confirm if a rule in a Network Security Group is blocking traffic to or from a virtual machine.
You can also review effective security group rules to ensure inbound "Allow" NSG rule exists and is prioritized for
RDP port(default 3389). For more information, see Using Effective Security Rules to troubleshoot VM traffic
flow.
Source 5: Windows-based Azure VM

Follow the instructions in this article. This article resets the Remote Desktop service on the virtual machine:
Enable the "Remote Desktop" Windows Firewall default rule (TCP port 3389).
Enable Remote Desktop connections by setting the HKLM\System\CurrentControlSet\Control\Terminal
Server\fDenyTSConnections registry value to 0.
Try the connection from your computer again. If you are still not able to connect via Remote Desktop, check for
the following possible problems:
The Remote Desktop service is not running on the target VM.
The Remote Desktop service is not listening on TCP port 3389.
Windows Firewall or another local firewall has an outbound rule that is preventing Remote Desktop traffic.
Intrusion detection or network monitoring software running on the Azure virtual machine is preventing
Remote Desktop connections.
For VMs created using the classic deployment model, you can use a remote Azure PowerShell session to the
Azure virtual machine. First, you need to install a certificate for the virtual machine's hosting cloud service. Go to
Configure Secure Remote PowerShell Access to Azure Virtual Machines and download the
InstallWinRMCertAzureVM.ps1 script file to your local computer.
Next, install Azure PowerShell if you haven't already. See How to install and configure Azure PowerShell.
Next, open an Azure PowerShell command prompt and change the current folder to the location of the
InstallWinRMCertAzureVM.ps1 script file. To run an Azure PowerShell script, you must set the correct
execution policy. Run the Get-ExecutionPolicy command to determine your current policy level. For
information about setting the appropriate level, see Set-ExecutionPolicy.
Next, fill in your Azure subscription name, the cloud service name, and your virtual machine name (removing the
< and > characters), and then run these commands.
$subscr="<Name of your Azure subscription>"

$serviceName="<Name of the cloud service that contains the target virtual machine>"
$vmName="<Name of the target virtual machine>"
.\InstallWinRMCertAzureVM.ps1 -SubscriptionName $subscr -ServiceName $serviceName -Name $vmName
You can get the correct subscription name from the SubscriptionName property of the display of the Get-
AzureSubscription command. You can get the cloud service name for the virtual machine from the
ServiceName column in the display of the Get-AzureVM command.
Check if you have the new certificate. Open a Certificates snap-in for the current user and look in the Trusted
Root Certification Authorities\Certificates folder. You should see a certificate with the DNS name of your
cloud service in the Issued To column (example: cloudservice4testing.cloudapp.net).
Next, initiate a remote Azure PowerShell session by using these commands.
$uri = Get-AzureWinRMUri -ServiceName $serviceName -Name $vmName

$creds = Get-Credential
Enter-PSSession -ConnectionUri $uri -Credential $creds
After entering valid administrator credentials, you should see something similar to the following Azure
PowerShell prompt:
[cloudservice4testing.cloudapp.net]: PS C:\Users\User1\Documents>
The first part of this prompt is your cloud service name that contains the target VM, which could be different
from "cloudservice4testing.cloudapp.net". You can now issue Azure PowerShell commands for this cloud service
to investigate the problems mentioned and correct the configuration.
To manually correct the Remote Desktop Services listening TCP port
At the remote Azure PowerShell session prompt, run this command.
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name

"PortNumber"
The PortNumber property shows the current port number. If needed, change the Remote Desktop port number
back to its default value (3389) by using this command.
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name

"PortNumber" -Value 3389
Verify that the port has been changed to 3389 by using this command.
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name

"PortNumber"
Exit the remote Azure PowerShell session by using this command.
Exit-PSSession
Verify that the Remote Desktop endpoint for the Azure VM is also using TCP port 3398 as its internal port.
Restart the Azure VM and try the Remote Desktop connection again.
How to reset a password or the Remote Desktop service for Windows virtual machines
How to install and configure Azure PowerShell
Troubleshoot Secure Shell (SSH) connections to a Linux-based Azure virtual machine
Troubleshoot access to an application running on an Azure virtual machine
Cannot RDP to Azure Virtual Machines because the
DHCP Client service is disabled
This article describes a problem in which you cannot remote desktop to Azure Windows Virtual Machines (VMs)
after the DHCP Client service is disabled in the VM.
NOTE
article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager model.
Symptoms
You cannot make an RDP connection a VM in Azure because the DHCP Client service is disabled in the VM. When
you check the screenshot in the Boot diagnostics in the Azure portal, you see the VM boots normally and waits for
credentials in the login screen. You remotely view the event logs in the VM by using Event Viewer. You see that the
DHCP Client Service isn't started or fails to start. The following a sample log:
Log Name: System
Source: Service Control Manager
Date: 12/16/2015 11:19:36 AM
Event ID: 7022
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: myvm.cosotos.com
Description: The DHCP Client service hung on starting.
For Resource Manager VMs, you can use Serial Access Console feature to query for the event logs 7022 using the
following command:
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Service Control Manager'] and EventID=7022

and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
For Classic VMs, you will need to work in OFFLINE mode and collect the logs manually.
Cause
The DHCP Client Service is not running on the VM.
NOTE
This article applies only for the DHCP Client service and not DHCP Server.
Solution
Before you follow these steps, take a snapshot of the OS disk of the affected VM as a backup. For more
information, see Snapshot a disk.
To resolve this problem, use Serial control to enable DHCP or reset network interface for the VM.
Use Serial control
1. Connect to Serial Console and open CMD instance. ). If the Serial Console is not enabled on your VM, see
Reset network interface.
2. Check if the DHCP is disabled on the network interface:
sc query DHCP
3. If the DHCP is stopped, try to start the service
sc start DHCP
4. Query the service again to make sure that the service is started successfully.
sc query DHCP
Try to connect to the VM and see if the problem is resolved.

5. If the service does not start, use the following appropriate solution, based on the error message that you
received:
ERROR SOLUTION
5- ACCESS DENIED See DHCP Client service is stopped because of an Access

Denied error.
1053 - ERROR_SERVICE_REQUEST_TIMEOUT See DHCP Client service crashes or hangs.
1058 - ERROR_SERVICE_DISABLED See DHCP Client service is disabled.
1059 - ERROR_CIRCULAR_DEPENDENCY Contact support to get your problem resolved quickly.
1067 - ERROR_PROCESS_ABORTED See DHCP Client service crashes or hangs.
1068 - ERROR_SERVICE_DEPENDENCY_FAIL Contact support to get your problem resolved quickly.
1069 - ERROR_SERVICE_LOGON_FAILED See DHCP Client service fails because of logon failure
1070 - ERROR_SERVICE_START_HANG See DHCP Client service crashes or hangs.
1077 - ERROR_SERVICE_NEVER_STARTED See DHCP Client service is disabled.
1079 - ERROR_DIFERENCE_SERVICE_ACCOUNT Contact support to get your problem resolved quickly.
1053 Contact support to get your problem resolved quickly.
DHCP Client service is stopped because of an Access Denied error

1. Connect to Serial Console and open a PowerShell instance.
2. Download theProcess Monitor tool by running the following script:
remove-module psreadline
$source = "https://download.sysinternals.com/files/ProcessMonitor.zip"
$destination = "c:\temp\ProcessMonitor.zip"
$wc = New-Object System.Net.WebClient
$wc.DownloadFile($source,$destination)
3. Now start a procmon trace:
procmon /Quiet /Minimized /BackingFile c:\temp\ProcMonTrace.PML
4. Reproduce the problem by starting the service that's generating the Access Denied message:
sc start DHCP
When it fails, terminate the Process Monitor trace:
procmon /Terminate
5. Collect the c:\temp\ProcMonTrace.PML file:

a. Attach a data disk to the VM.
b. Use Serial Console you can copy the file to the new drive. For example,
copy C:\temp\ProcMonTrace.PML F:\ . In this command, F is the driver letter of the attached data disk.
Replace the letter as appropriate with the correct value.
c. Detach the data drive and then attach it to a working VM that has Process Monitor ubstakke installed.
6. Open ProcMonTrace.PML by using Process Monitor on the working VM. Then filter byResult is ACCESS
DENIED, as shown in the following screenshot：
7. Fix the registry keys, folders, or files that are on the output. Usually, this problem is caused when the sign-in
account that's used on the service doesn't have ACL permission to access these objects. To determine the
correct ACL permission for the sign-in account, you can check on a healthy VM.
DHCP Client service is disabled
1. Restore the service to its default startup value:
sc config DHCP start= auto
2. Start the service:
sc start DHCP
3. Query the service status again to make sure it's running:
sc query DHCP
4. Try to connect to the VM by using Remote Desktop.

DHCP Client service fails because of logon failure
1. Because this problem occurs if the startup account of this service was changed, revert the account to its
default status:
sc config DHCP obj= 'NT Authority\Localservice'
sc start DHCP
3. Try to connect to the VM by using Remote Desktop.

DHCP Client service crashes or hangs
1. If the service status is stuck in the Starting or Stopping state, try to stop the service:
sc stop DHCP
2. Isolate the service on its own ‘svchost’ container:
sc config DHCP type= own
sc start DHCP
4. If the service still does not start, Contact support.

Repair the VM offline
Attach the OS disk to a recovery VM
1. Attach the OS disk to a recovery VM.
2. Start a Remote Desktop connection to the recovery VM. Make sure that the attached disk is flagged as
Online in the Disk Management console. Note the drive letter that's assigned to the attached OS disk.
3. Open an elevated command prompt instance (Run as administrator). Then run the following script. This
script assumes that the drive letter that's assigned to the attached OS disk is F. Replace the letter as
appropriate with the value in your VM.
reg load HKLM\BROKENSYSTEM F:\windows\system32\config\SYSTEM
REM Set default values back on the broken service

reg add "HKLM\BROKENSYSTEM\ControlSet001\services\DHCP" /v start /t REG_DWORD /d 2 /f
reg add "HKLM\BROKENSYSTEM\ControlSet001\services\DHCP" /v ObjectName /t REG_SZ /d "NT
Authority\LocalService" /f
reg add "HKLM\BROKENSYSTEM\ControlSet001\services\DHCP" /v type /t REG_DWORD /d 16 /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\services\DHCP" /v start /t REG_DWORD /d 2 /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\services\DHCP" /v ObjectName /t REG_SZ /d "NT
Authority\LocalService" /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\services\DHCP" /v type /t REG_DWORD /d 16 /f
reg unload HKLM\BROKENSYSTEM
4. Detach the OS disk and recreate the VM. Then check whether the problem is resolved.
Next steps
If you still need help, contact support to get your problem resolved.
Cannot connect remotely to a VM because RDP port
is not enabled in NSG
This article explains how to resolve a problem in which you cannot connect to an Azure Windows virtual machine
(VM ) because the Remote Desktop Protocol (RDP ) port is not enabled in the network security group (NSG ).
NOTE
Azure has two deployment models for creating and working with resources: Resource Manager and classic. We recommend
that you use the Resource Manager deployment model instead of the classic deployment model for new deployments.
Symptom
You cannot make an RDP connection to a VM in Azure because the RDP port is not opened in the network
security group.
Solution
When you create a new VM, all traffic from the Internet is blocked by default.
To enable the RDP port in an NSG, follow these steps:
1. Sign in to the Azure portal.
2. In Virtual Machines, select the VM that has the problem.
3. In Settings, select Networking.
4. In Inbound port rules, check whether the port for RDP is set correctly. The following is an example of the
configuration:
Priority: 300
Port: 3389
Name: Port_3389
Port: 3389
Protocol: TCP
Source: Any
Destinations: Any
Action: Allow
If you specify the source IP address, this setting allows traffic only from a specific IP address or range of IP
addresses to connect to the VM. Make sure that the computer you are using to start the RDP session is within the
range.
For more information about NSGs, see network security group.
NOTE
RDP port 3389 is exposed to the Internet. Therefore, we recommend that you use this port only for recommended for
testing. For production environments, we recommend that you use a VPN or private connection.
Next steps
If the RDP port is already enabled in NSG, see Troubleshoot an RDP general error in Azure VM.
Troubleshooting specific RDP error messages to a
Windows VM in Azure
You may receive a specific error message when using Remote Desktop connection to a Windows virtual machine
(VM ) in Azure. This article details some of the more common error messages encountered, along with
troubleshooting steps to resolve them. If you are having issues connecting to your VM using RDP but do not
encounter a specific error message, see the troubleshooting guide for Remote Desktop.
For information on specific error messages, see the following:
The remote session was disconnected because there are no Remote Desktop License Servers available to
provide a license.
The remote session was disconnected because there are no Remote

Desktop License Servers available to provide a license.
Cause: The 120-day licensing grace period for the Remote Desktop Server role has expired and you need to install
licenses.
As a workaround, save a local copy of the RDP file from the portal and run this command at a PowerShell
command prompt to connect. This step disables licensing for just that connection:
mstsc <File name>.RDP /admin
If you don't actually need more than two simultaneous Remote Desktop connections to the VM, you can use
Server Manager to remove the Remote Desktop Server role.
For more information, see the blog post Azure VM fails with "No Remote Desktop License Servers available".

Cause: The Remote Desktop client on your computer can't resolve the name of the computer in the settings of the
RDP file.
Possible solutions:
If you're on an organization's intranet, make sure that your computer has access to the proxy server and can
send HTTPS traffic to it.
If you're using a locally stored RDP file, try using the one that's generated by the portal. This step ensures
that you have the correct DNS name for the virtual machine, or the cloud service and the endpoint port of
the VM. Here is a sample RDP file generated by the portal:
full address:s:tailspin-azdatatier.cloudapp.net:55919
prompt for credentials:i:1
The address portion of this RDP file has:

The fully qualified domain name of the cloud service that contains the VM ("tailspin-azdatatier.cloudapp.net" in
this example).
The external TCP port of the endpoint for Remote Desktop traffic (55919).
An authentication error has occurred. The Local Security Authority

cannot be contacted.
Cause: The target VM can't locate the security authority in the user name portion of your credentials.
When your user name is in the form SecurityAuthority\UserName (example: CORP\User1), the SecurityAuthority
portion is either the VM's computer name (for the local security authority) or an Active Directory domain name.
Possible solutions:
If the account is local to the VM, make sure that the VM name is spelled correctly.
If the account is on an Active Directory domain, check the spelling of the domain name.
If it is an Active Directory domain account and the domain name is spelled correctly, verify that a domain
controller is available in that domain. It's a common issue in Azure virtual networks that contain domain
controllers that a domain controller is unavailable because it hasn't been started. As a workaround, you can use
a local administrator account instead of a domain account.

Cause: The target VM can't validate your account name and password.
A Windows-based computer can validate the credentials of either a local account or a domain account.
For local accounts, use the ComputerName\UserName syntax (example: SQL1\Admin4798).
For domain accounts, use the DomainName\UserName syntax (example: CONTOSO\peterodman).
If you have promoted your VM to a domain controller in a new Active Directory forest, the local administrator
account that you signed in with is converted to an equivalent account with the same password in the new forest
and domain. The local account is then deleted.
For example, if you signed in with the local account DC1\DCAdmin, and then promoted the virtual machine as a
domain controller in a new forest for the corp.contoso.com domain, the DC1\DCAdmin local account gets deleted
and a new domain account (CORP\DCAdmin) is created with the same password.
Make sure that the account name is a name that the virtual machine can verify as a valid account, and that the
password is correct.
If you need to change the password of the local administrator account, see How to reset a password or the Remote
Desktop service for Windows virtual machines.

Cause: The account that's used to connect does not have Remote Desktop sign-in rights.
Every Windows computer has a Remote Desktop users local group, which contains the accounts and groups that
can sign into it remotely. Members of the local administrators group also have access, even though those accounts
are not listed in the Remote Desktop users local group. For domain-joined machines, the local administrators
group also contains the domain administrators for the domain.
Make sure that the account you're using to connect with has Remote Desktop sign-in rights. As a workaround, use
a domain or local administrator account to connect over Remote Desktop. To add the desired account to the
Remote Desktop users local group, use the Microsoft Management Console snap-in (System Tools > Local Users
and Groups > Groups > Remote Desktop Users).
Next steps
If none of these errors occurred and you have an unknown issue with connecting using RDP, see the
troubleshooting guide for Remote Desktop.
For troubleshooting steps in accessing applications running on a VM, see Troubleshoot access to an application
running on an Azure VM.
If you are having issues using Secure Shell (SSH) to connect to a Linux VM in Azure, see Troubleshoot SSH
connections to a Linux VM in Azure.
Remote Desktop license server isn't available when
you connect to an Azure VM
This article helps resolve the issue when you can't connect to an Azure virtual machine (VM ) because no Remote
Desktop license server is available to provide a license.
Symptoms
When you try to connect to a virtual machine (VM ), you experience the following scenarios:
The VM screenshot shows that the operating system is fully loaded and waiting for credentials.
You receive the following error messages when you try to make a Microsoft Remote Desktop Protocol
(RDP ) connection:
The remote session was disconnected because there are no Remote Desktop license servers available
to provide a license.
No Remote Desktop license server is available. Remote Desktop Services will stop working because
this computer is past its grace period and hasn't contacted at least a valid Windows Server 2008
license server. Select this message to open RD Session Host Server Configuration to use Licensing
Diagnosis.
However, you can connect to the VM normally by using an administrative session:
mstsc /v:<Server>[:<Port>] /admin
Cause
This problem occurs if a Remote Desktop license server is unavailable to provide a license to start a remote
session. It can be caused by several scenarios, even though a Remote Desktop Session Host role was set up on the
VM:
There was never a Remote Desktop licensing role in the environment, and the grace period, 180 days, is over.
A Remote Desktop license was installed in the environment, but it's never activated.
A Remote Desktop license in the environment doesn't have Client Access Licenses (CALs) injected to set up the
connection.
A Remote Desktop license was installed in the environment. There are available CALs, but they weren't
configured properly.
A Remote Desktop license has CALs, and it was activated. However, some other issues on the Remote Desktop
license server prevent it from providing licenses in the environment.
Solution
To resolve this problem, back up the OS disk and follow these steps:
1. Connect to the VM by using an administrative session:
mstsc /v:<Server>[:<Port>] /admin
If you can't connect to the VM by using an administrative session, you can use the Virtual Machine Serial
Console on Azure to access the VM as follows:
a. Access the Serial Console by selecting Support & Troubleshooting > Serial console (Preview). If
the feature is enabled on the VM, you can connect the VM successfully.
b. Create a new channel for a CMD instance. Enter CMD to start the channel and get the channel name.
c. Switch to the channel that runs the CMD instance. In this case, it should be channel 1:
ch -si 1
d. Select Enter again and enter a valid username and password, local or domain ID, for the VM.
2. Check whether the VM has a Remote Desktop Session Host role enabled. If the role is enabled, make sure
that it's functioning properly. Open an elevated CMD instance and follow these steps:
a. Use the following command to check the status of the Remote Desktop Session Host role:
reg query "HKLM\SOFTWARE\Microsoft\ServerManager\ServicingStorage\ServerComponentCache\RDS-RD-

Server" /v InstallState
If this command returns a value of 0, it means that the role is disabled, and you can go to step 3.
b. Use the following command to check the policies and reconfigure as needed:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core" /v

LicensingMode reg query "HKLM\SYSTEM\CurrentControlSet\Services\TermService\Parameters" /v
SpecifiedLicenseServers
If the LicensingMode value is set to any value other than 4, per user, then set the value to 4:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core" /v

LicensingMode /t REG_DWORD /d 4
If the SpecifiedLicenseServers value doesn't exist, or it has incorrect license server information,
then change it as follows:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\TermService\Parameters" /v

SpecifiedLicenseServers /t REG_MULTI_SZ /d "<FQDN / IP License server>"
c. After you make any changes to the registry, restart the VM.
d. If you don't have CALs, remove the Remote Desktop Session Host role. Then the RDP will be set
back to normal. It only allows two concurrent RDP connections to the VM:
dism /ONLINE /Disable-feature /FeatureName:Remote-Desktop-Services
If the VM has the Remote Desktop licensing role and it isn't used, you can also remove that role:
dism /ONLINE /Disable-feature /FeatureName:Licensing
e. Make sure that the VM can connect to the Remote Desktop license server. You can test the
connectivity to the port 135 between the VM and the license server:
telnet <FQDN / IP License Server> 135
3. If there's no Remote Desktop license server in the environment and you want one, you can install a Remote
Desktop licensing role service. Then configure the RDS licensing.
4. If a Remote Desktop license server is configured and healthy, make sure that the Remote Desktop license
server is activated with CALs.
Need help? Contact support

If you still need help, contact support to get your issue resolved.
Remote Desktop Services isn't starting on an Azure
VM
This article describes how to troubleshoot issues when you connect to an Azure virtual machine (VM ) and Remote
Desktop Services, or TermService, isn't starting or fails to start.
NOTE
Azure has two different deployment models to create and work with resources: Azure Resource Manager and classic. This
article describes using the Resource Manager deployment model. We recommend that you use this model for new
deployments instead of the classic deployment model.
Symptoms
When you try to connect to a VM, you experience the following scenarios:
The VM screenshot shows the operating system is fully loaded and waiting for credentials.
You remotely view the event logs in the VM by using Event Viewer. You see that Remote Desktop Services,
TermService, isn't starting or fails to start. The following log is a sample:
Log Name: System
Source: Service Control Manager
Date: 12/16/2017 11:19:36 AM
Event ID: 7022
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: vm.contoso.com
Description: The Remote Desktop Services service hung on starting.
You can also use the Serial Access Console feature to look for these errors by running the following query:
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Service Control Manager'] and
EventID=7022 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
Cause
This problem occurs because Remote Desktop Services isn't running on the VM. The cause can depend on the
following scenarios:
The TermService service is set to Disabled.
The TermService service is crashing or not responding.
The TermService is not starting because of to an incorrect configuration.
Solution
To troubleshoot this issue, use the Serial Console. Or else repair the VM offline by attaching the OS disk of the VM
to a recovery VM.
Use Serial Console
1. Access the Serial Console by selecting Support & Troubleshooting > Serial console. If the feature is
enabled on the VM, you can connect the VM successfully.
2. Create a new channel for a CMD instance. Enter CMD to start the channel and get the channel name.
3. Switch to the channel that runs the CMD instance. In this case, it should be channel 1:
ch -si 1
4. Select Enter again and enter a valid username and password, local or domain ID, for the VM.
5. Query the status of the TermService service:
sc query TermService
6. If the service status shows Stopped, try to start the service:
sc start TermService
7. Query the service again to make sure that the service is started successfully:
8. If the service fails to start, follow the solution based on the error you received:
ERROR SUGGESTION
5- ACCESS DENIED See TermService service is stopped because of an Access

Denied error.
1053 - ERROR_SERVICE_REQUEST_TIMEOUT See TermService service is disabled.
1058 - ERROR_SERVICE_DISABLED See TermService service crashes or hangs.

ERROR SUGGESTION
1059 - ERROR_CIRCULAR_DEPENDENCY Contact support to get your issue resolved quickly.
1067 - ERROR_PROCESS_ABORTED See TermService service crashes or hangs.
1068 - ERROR_SERVICE_DEPENDENCY_FAIL Contact support to get your issue resolved quickly.
1069 - ERROR_SERVICE_LOGON_FAILED See TermService service fails because of logon failure
1070 - ERROR_SERVICE_START_HANG See TermService service crashes or hangs.
1077 - ERROR_SERVICE_NEVER_STARTED See TermService service is disabled.
1079 - ERROR_DIFERENCE_SERVICE_ACCOUNT Contact support to get your issue resolved quickly.
1753 Contact support to get your issue resolved quickly.
TermService service is stopped because of an Access Denied problem

1. Connect to Serial Console and open a PowerShell instance.
2. Download theProcess Monitor tool by running the following script:
$source = "https://download.sysinternals.com/files/ProcessMonitor.zip"
$destination = "c:\temp\ProcessMonitor.zip"
$wc = New-Object System.Net.WebClient
$wc.DownloadFile($source,$destination)
3. Now start a procmon trace:
procmon /Quiet /Minimized /BackingFile c:\temp\ProcMonTrace.PML
4. Reproduce the problem by starting the service that's giving Access Denied:
When it fails, terminate the Process Monitor trace:
procmon /Terminate
5. Collect the filec:\temp\ProcMonTrace.PML:

a. Attach a data disk to the VM.
b. Use Serial Console you can copy the file to the new drive. For example,
copy C:\temp\ProcMonTrace.PML F:\ . In this command, F is the driver letter of the attached data disk.
c. Detach the data drive and attach it on a working VM that has Process Monitor ubstakke installed.
6. Open ProcMonTrace.PML by using Process Monitor the working VM. Then filter byResult is ACCESS
DENIED, as shown in the following screenshot：
7. Fix the registry keys, folders, or files that are on the output. Usually, this problem is caused when the sign-in
account that's used on the service doesn't have ACL permission to access these objects. To know the correct
ACL permission for the sign-in account, you can check on a healthy VM.
TermService service is disabled
1. Restore the service to its default startup value:
sc config TermService start= demand
3. Query its status again to make sure the service is running:
4. Try to connect to VM by using Remote Desktop.

TermService service fails because of logon failure
1. This problem occurs if the startup account of this service was changed. Changed this back to its default:
sc config TermService obj= 'NT Authority\NetworkService'
3. Try to connect to VM by using Remote Desktop.

TermService service crashes or hangs
1. If the service status is stuck in Starting or Stopping, then try to stop the service:
sc stop TermService
2. Isolate the service on its own ‘svchost’ container:
sc config TermService type= own
4. If the service is still failing to start, Contact support.

2. Start a Remote Desktop connection to the recovery VM. Make sure that the attached disk is flagged as
Online in the Disk Management console. Note the drive letter that's assigned to the attached OS disk.
3. Open an elevated command prompt instance (Run as administrator). Then run the following script. We
assume that the drive letter that's assigned to the attached OS disk is F. Replace it with the appropriate
value in your VM.
reg load HKLM\BROKENSYSTEM F:\windows\system32\config\SYSTEM.hiv
REM Set default values back on the broken service

reg add "HKLM\BROKENSYSTEM\ControlSet001\services\TermService" /v start /t REG_DWORD /d 3 /f
reg add "HKLM\BROKENSYSTEM\ControlSet001\services\TermService" /v ObjectName /t REG_SZ /d "NT
Authority\NetworkService“ /f
reg add "HKLM\BROKENSYSTEM\ControlSet001\services\TermService" /v type /t REG_DWORD /d 16 /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\services\TermService" /v start /t REG_DWORD /d 3 /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\services\TermService" /v ObjectName /t REG_SZ /d "NT
Authority\NetworkService" /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\services\TermService" /v type /t REG_DWORD /d 16 /f
4. Detach the OS disk and recreate the VM. Then check whether the issue is resolved.

If you still need help, contact support to get your issue resolved.
An internal error occurs when you try to connect to
an Azure VM through Remote Desktop
This article describes an error that you may experience when you try to connect to a virtual machine (VM ) in
Microsoft Azure.
NOTE
article covers using the Resource Manager deployment model, which we recommend using for new deployments instead of
the classic deployment model.
Symptoms
You cannot connect to an Azure VM by using the remote desktop protocol (RDP ). The connection gets stuck on the
"Configuring Remote" section, or you receive the following error message:
RDP internal error
An internal error has occurred
This computer can't be connected to the remote computer. Try connecting again. If the problem continues,
contact the owner of the remote computer or your network administrator
Cause
This issue may occur for the following reasons:
The local RSA encryption keys cannot be accessed.
TLS protocol is disabled.
The certificate is corrupted or expired.
Solution
To troubleshoot this issue, use the Serial Console or repair the VM offline by attaching the OS disk of the VM to a
recovery VM.
Use Serial control
Connect to Serial Console and open PowerShell instance. If the Serial Console is not enabled on your VM, go to
the repair the VM offline section.
Step: 1 Check the RDP port
1. In a PowerShell instance, use the NETSTAT to check whether port 8080 is used by other applications:
Netstat -anob |more
2. If Termservice.exe is using 8080 port, go to step 2. If another service or application other than
Termservice.exe is using 8080 port, follow these steps:
a. Stop the service for the application that is using the 3389 service:
Stop-Service -Name <ServiceName> -Force
b. Start the terminal service:
Start-Service -Name Termservice
3. If the application cannot be stopped, or if this method does not apply to you, change the port for RDP:
a. Change the port:
Set-ItemProperty -Path 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-

Tcp' -name PortNumber -value <Hexportnumber>
Stop-Service -Name Termservice -Force
Start-Service -Name Termservice
b. Set the firewall for the new port:
Set-NetFirewallRule -Name "RemoteDesktop-UserMode-In-TCP" -LocalPort <NEW PORT (decimal)>
c. Update the network security group for the new port in the Azure portal RDP port.
Step 2: Set correct permissions on the RDP self-signed certificate
1. In a PowerShell instance, run the following commands one by one to renew the RDP self-signed certificate:
Import-Module PKI
Set-Location Cert:\LocalMachine
$RdpCertThumbprint = 'Cert:\LocalMachine\Remote Desktop\'+((Get-ChildItem -Path

'Cert:\LocalMachine\Remote Desktop\').thumbprint)
Remove-Item -Path $RdpCertThumbprint
Stop-Service -Name "SessionEnv"
Start-Service -Name "SessionEnv"
2. If you cannot renew the certificate by using this method, try to renew the RDP self-signed certificate
remotely:
a. From a working VM that has connectivity to the VM that is experiencing problems, type mmc in the
Run box to open Microsoft Management Console.
b. On the File menu, select Add/Remove Snap-in, select Certificates, and then select Add.
c. Select Computer accounts, select Another Computer, and then add the IP address of the problem
VM.
d. Go to the Remote Desktop\Certificates folder, right-click the certificate, and then and select
Delete.
e. In a PowerShell instance from the Serial Console, restart the Remote Desktop Configuration service:
3. Reset the permission for the MachineKeys folder.
remove-module psreadline icacls
md c:\temp
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > c:\temp\BeforeScript_permissions.txt
takeown /f "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /a /r
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "NT AUTHORITY\System:(F)"
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "NT AUTHORITY\NETWORK SERVICE:(R)"
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "BUILTIN\Administrators:(F)"
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > c:\temp\AfterScript_permissions.txt
Restart-Service TermService -Force
4. Restart the VM, and then try Start a Remote Desktop connection to the VM. If the error still occurs, go to the
next step.
Step 3: Enable all supported TLS versions
The RDP client uses TLS 1.0 as the default protocol. However, this can be changed to TLS 1.1, which has become
the new standard. If TLS 1.1 is disabled on the VM, the connection will fail.
1. In a CMD instance, enable the TLS protocol:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v

Enabled /t REG_DWORD /d 1 /f


2. To prevent the AD policy from overwriting the changes, stop the group policy update temporarily:
REG add "HKLM\SYSTEM\CurrentControlSet\Services\gpsvc" /v Start /t REG_DWORD /d 4 /f
3. Restart the VM so that the changes take effect. If the issue is resolved, run the following command to re-
enable the group policy:
sc config gpsvc start= auto sc start gpsvc
gpupdate /force
If the change is reverted, it means that there's an Active Directory policy in your company domain. You have
to change that policy to avoid this problem from occurring again.
Repair the VM Offline
2. After the OS disk is attached to the recovery VM, make sure that the disk is flagged as Online in the Disk
Management console. Note the drive letter that is assigned to the attached OS disk.
3. Start a Remote Desktop connection to the recovery VM.
Enable dump log and Serial Console
To enable dump log and Serial Console, run the following script.
1. Open an elevated command prompt session (Run as administrator).
2. Run the following script:
In this script, we assume that the drive letter that is assigned to the attached OS disk is F. Replace this drive
letter with the appropriate value for your VM.
REM Enable Serial Console

bcdedit /store F:\boot\bcd /set {bootmgr} displaybootmenu yes
bcdedit /store F:\boot\bcd /set {bootmgr} timeout 5
bcdedit /store F:\boot\bcd /set {bootmgr} bootems yes
bcdedit /store F:\boot\bcd /ems {<BOOT LOADER IDENTIFIER>} ON
bcdedit /store F:\boot\bcd /emssettings EMSPORT:1 EMSBAUDRATE:115200
REM Suggested configuration to enable OS Dump

REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\CrashControl" /v CrashDumpEnabled /t REG_DWORD /d 1 /f
REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\CrashControl" /v DumpFile /t REG_EXPAND_SZ /d
"%SystemRoot%\MEMORY.DMP" /f
REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\CrashControl" /v NMICrashDump /t REG_DWORD /d 1 /f

Reset the permission for MachineKeys folder

2. Run the following script. In this script, we assume that the drive letter that is assigned to the attached OS
disk is F. Replace this drive letter with the appropriate value for your VM.
Md F:\temp
icacls F:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > c:\temp\BeforeScript_permissions.txt
takeown /f "F:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /a /r
icacls F:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "NT AUTHORITY\System:(F)"
icacls F:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "NT AUTHORITY\NETWORK SERVICE:(R)"
icacls F:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "BUILTIN\Administrators:(F)"
icacls F:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > c:\temp\AfterScript_permissions.txt
Enable all supported TLS versions

1. Open an elevated command prompt session (Run as administrator), and the run the following commands.
The following script assumes that the driver letter is assigned to the attached OS disk is F. Replace this drive
2. Check which TLS is enabled:
REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v






Enabled /t REG_DWO
3. If the key doesn't exist, or its value is 0, enable the protocol by running the following scripts:
REM Enable TLS 1.0, TLS 1.1 and TLS 1.2






4. Enable NLA:
REM Enable NLA
REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer

/t REG_DWORD /d 1 /f
REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\Terminal Server\WinStations\RDP-Tcp" /v

UserAuthentication /t REG_DWORD /d 1 /f

fAllowSecProtocolNegotiation /t REG_DWORD /d 1 /f
REG ADD "HKLM\BROKENSYSTEM\ControlSet002\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer


UserAuthentication /t REG_DWORD /d 1 /f

fAllowSecProtocolNegotiation /t REG_DWORD /d 1 /f reg unload HKLM\BROKENSYSTEM
5. Detach the OS disk and recreate the VM, and then check whether the issue is resolved.
Remote Desktop disconnects frequently in Azure VM
This article explains how to troubleshoot frequent disconnections to an Azure virtual machine (VM ) through
Remote Desktop Protocol RDP ).
NOTE
article covers using the Resource Manager deployment model. We recommend that you use this model for new
deployments instead of using the classic deployment model.
Symptom
You face intermittent RDP connectivity problems during your sessions. You can initially connect to the VM, but
then the connection drops.
Cause
This problem may occur if the RDP Listener is misconfigured. Typically, this problem occurs on a VM that uses a
custom image.
Solution
Before you follow these steps, take a snapshot of the OS disk of the affected VM as a backup.
To troubleshoot this issue, use Serial control or repair the VM offline by attaching the OS disk of the VM to a
recovery VM.
Serial control
1. Connect to Serial Console and open CMD instance. Then, run the following commands to reset the RDP
configurations. If the Serial Console is not enabled on your VM, go to the next step.
2. Lower the RDP Security Layer to 0. At this setting, communications between server and client use the
native RDP encryption.
REG ADD "HKLM\SYSTEM\CurrentControlSet\control\Terminal Server\Winstations\RDP-Tcp" /v 'SecurityLayer'

3. Lower the encryption level to the minimum setting to allow legacy RDP clients to connect.
REG ADD "HKLM\SYSTEM\CurrentControlSet\control\Terminal Server\Winstations\RDP-Tcp" /v

'MinEncryptionLevel' /t REG_DWORD /d 1 /f
4. Set RDP to load the user configuration of the client computer.

'fQueryUserConfigFromLocalMachine' /t REG_DWORD /d 1 /f
5. Enable the RDP Keep-Alive control:

'KeepAliveTimeout' /t REG_DWORD /d 1 /f
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v 'KeepAliveEnable' /t

REG_DWORD /d 1 /f
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v 'KeepAliveInterval' /t

REG_DWORD /d 1 /f
6. Set the RDP Reconnect control:

'fInheritReconnectSame' /t REG_DWORD /d 0 /f

'fReconnectSame' /t REG_DWORD /d 1 /f
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v 'fDisableAutoReconnect' /t

REG_DWORD /d 0 /f
7. Set the RDP Session Time control:

'fInheritMaxSessionTime' /t REG_DWORD /d 1 /f
8. Set the RDP Disconnection Time control:

'fInheritMaxDisconnectionTime' /t REG_DWORD /d 1 /f
'MaxDisconnectionTime' /t REG_DWORD /d 0 /f
9. Set the RDP Connection Time control:

'MaxConnectionTime' /t REG_DWORD /d 0 /f
10. Set the RDP Session Idle Time control:

'fInheritMaxIdleTime' /t REG_DWORD /d 1 /f
REG ADD "HKLM\SYSTEM\CurrentControlSet\control\Terminal Server\Winstations\RDP-Tcp" /v 'MaxIdleTime' /t

REG_DWORD /d 0 /f
11. Set the "Limit the maximum concurrent connections" control:

'MaxInstanceCount' /t REG_DWORD /d 4294967295 /f
12. Restart the VM, and try again to connect to it by using RDP.
2. After the OS disk is attached to the recovery VM, make sure that the disk is flagged as Online in the Disk
Management console. Note the drive letter that is assigned to the attached OS disk.
3. On the OS disk that you attached, navigate to the \windows\system32\config folder. Copy all the files in
this folder as a backup, in case a rollback is required.
4. Start Registry Editor (regedit.exe).
5. Select the HKEY_LOCAL_MACHINE key. On the menu, select File > Load Hive:
6. Browse to the \windows\system32\config\SYSTEM folder on the OS disk that you attached. For the
name of the hive, enter BROKENSYSTEM. The new registry hive is displayed under the
HKEY_LOCAL_MACHINE key. Then load the software hive \windows\system32\config\SOFTWARE
under the HKEY_LOCAL_MACHINE key. For the name of the hive software, enter BROKENSOFTWARE.
7. Open an elevated Command Prompt window (Run as administrator), and run commands in the
remaining steps to reset the RDP configurations.
8. Lower the RDP Security Layer to 0 so that communications between the server and client use the native
RDP Encryption:
REG ADD "HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server\Winstations\RDP-Tcp" /v

'SecurityLayer' /t REG_DWORD /d 0 /f

'SecurityLayer' /t REG_DWORD /d 0 /f
9. Lower the encryption level to the minimum setting to allow legacy RDP clients to connect:


10. Set RDP to load the user configuration of the client machine.


11. Enable the RDP Keep-Alive control:


REG ADD "HKLM\BROKENSOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v 'KeepAliveEnable' /t

REG_DWORD /d 1 /f
REG ADD "HKLM\BROKENSOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v 'KeepAliveInterval' /t

REG_DWORD /d 1 /f
12. Set the RDP Reconnect control:




REG ADD "HKLM\BROKENSOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v

'fDisableAutoReconnect' /t REG_DWORD /d 0 /f
13. Set the RDP Session Time control:


14. Set the RDP Disconnection Time control:




15. Set the RDP Connection Time control:


16. Set the RDP Session Idle Time control: REG ADD
"HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server\Winstations\RDP -Tcp" /v
REG ADD "HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server\Winstations\RDP-Tcp" /v ' MaxIdleTime'


REG ADD "HKLM\BROKENSYSTEM\ControlSet002\control\Terminal Server\Winstations\RDP-Tcp" /v ' MaxIdleTime'

17. Set the "Limit the maximum concurrent connections" control:

'MaxInstanceCount' /t REG_DWORD /d ffffffff /f

'MaxInstanceCount' /t REG_DWORD /d ffffffff /f
18. Restart the VM, and try again to connect to it by using RDP.
Need help?
Contact support. If you still need help, contact support to get your issue resolved quickly.
Troubleshoot an RDP general error in Azure VM
This article describes a general error you may experience when you make a Remote Desktop Protocol (RDP )
connection to a Windows Virtual Machine (VM ) in Azure.
Symptom
When you make an RDP connection to a Window VM in Azure, you may receive the following general error
message:
Remote Desktop can't connect to the remote computer for one of these reasons:
1. Remote access to the server is not enabled
2. The remote Computer is turned off
3. The remote computer is not available on the network
Make sure the remote computer is turned on and connected to the network, and that remote access is
enabled.
Cause
This problem may occur because of the following causes:
Cause 1
The RDP component is disabled as follows:
At the component level
At the listener level
On the terminal server
On the Remote Desktop Session Host role
Cause 2
Remote Desktop Services (TermService) isn't running.
Cause 3
The RDP listener is misconfigured.
Solution
To resolve this problem, back up the operating system disk, and attach the operating system disk to a rescue VM,
and then follow the steps.
Serial Console
Step 1: Open CMD instance in Serial console
1. Access the Serial Console by selecting Support & Troubleshooting > Serial console (Preview). If the
feature is enabled on the VM, you can connect the VM successfully.
2. Create a new channel for a CMD instance. Type CMD to start the channel to get the channel name.
3. Switch to the channel that running the CMD instance, in this case it should be channel 1.
ch -si 1
Step 2: Check the values of RDP registry keys:

1. Check if the RDP is disabled by polices.
REM Get the local policy

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server " /v fDenyTSConnections
REM Get the domain policy if any

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fDenyTSConnections
If the domain policy exists, the setup on the local policy is overwritten.
If the domain policy states that RDP is disabled (1), then update the AD policy from domain
controller.
If the domain policy states that RDP is enabled (0), then no update is needed.
If the domain policy doesn't exist and the local policy states that RDP is disabled (1), enable RDP by
using the following command:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t

REG_DWORD /d 0 /f
2. Check the current configuration of the terminal server.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v TSEnabled
If the command returns 0, the terminal server is disabled. Then, enable the terminal server as follows:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v TSEnabled /t REG_DWORD /d 1 /f
3. The Terminal Server module is set to drain mode if the server is on a terminal server farm (RDS or Citrix).
Check the current mode of the Terminal Server module.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v TSServerDrainMode
If the command returns 1, the Terminal Server module is set to drain mode. Then, set the module to
working mode as follows:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v TSServerDrainMode /t REG_DWORD /d 0

/f
4. Check whether you can connect to the terminal server.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v TSUserEnabled
If the command returns 1, you can't connect to the terminal server. Then, enable the connection as follows:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v TSUserEnabled /t REG_DWORD /d 0 /f

5. Check the current configuration of the RDP listener.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp" /v

fEnableWinStation
If the command returns 0, the RDP listener is disabled. Then, enable the listener as follows:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp" /v

fEnableWinStation /t REG_DWORD /d 1 /f
6. Check whether you can connect to the RDP listener.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp" /v fLogonDisabled
If the command returns 1, you can't connect to the RDP listener. Then, enable the connection as follows:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp" /v fLogonDisabled

7. Restart the VM.

8. Exit from the CMD instance by typing exit , and then press Enter two times.
9. Restart the VM by typing restart , and then connect to the VM.
If the problem still happens, move to the step 2.

Step 2: Enable remote desktop services
For more information, see Remote Desktop Services isn't starting on an Azure VM.
Step 3: Reset RDP listener
For more information, see Remote Desktop disconnects frequently in Azure VM.
Offline repair
Step 1: Turn on Remote Desktop
3. Make sure that the disk is flagged as Online in the Disk Management console. Note the drive letter that is
assigned to the attached OS disk.
5. Open an elevated command prompt session (Run as administrator). Run the following scripts. In this
script, we assume that the drive letter that is assigned to the attached OS disk is F. Replace this drive letter
with the appropriate value for your VM.
reg load HKLM\BROKENSOFTWARE F:\windows\system32\config\SOFTWARE.hiv
REM Ensure that Terminal Server is enabled
reg add "HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server" /v TSEnabled /t REG_DWORD /d 1 /f

reg add "HKLM\BROKENSYSTEM\ControlSet002\control\Terminal Server" /v TSEnabled /t REG_DWORD /d 1 /f
REM Ensure Terminal Service is not set to Drain mode

reg add "HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server" /v TSServerDrainMode /t REG_DWORD /d
0 /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\control\Terminal Server" /v TSServerDrainMode /t REG_DWORD /d
0 /f
REM Ensure Terminal Service has logon enabled

reg add "HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server" /v TSUserEnabled /t REG_DWORD /d 0 /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\control\Terminal Server" /v TSUserEnabled /t REG_DWORD /d 0 /f
REM Ensure the RDP Listener is not disabled

reg add "HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server\Winstations\RDP-Tcp" /v
reg add "HKLM\BROKENSYSTEM\ControlSet002\control\Terminal Server\Winstations\RDP-Tcp" /v
REM Ensure the RDP Listener accepts logons

reg add "HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server\Winstations\RDP-Tcp" /v fLogonDisabled
reg add "HKLM\BROKENSYSTEM\ControlSet002\control\Terminal Server\Winstations\RDP-Tcp" /v fLogonDisabled
REM RDP component is enabled

reg add "HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d
0 /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d
0 /f
reg add "HKLM\BROKENSOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fDenyTSConnections /t
REG_DWORD /d 0 /f

reg unload HKLM\BROKENSOFTWARE
6. If the VM is domain joined, check the following registry key to see if there is a group policy that will disable
RDP.
HKLM\BROKENSOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\fDenyTSConnectionS
If this key value is set to 1 that means RDP is disabled by the policy. To enable Remote Desktop through the
GPO policy, change the following policy from domain controller:
Computer Configuration\Policies\Administrative Templates:
Policy definitions\Windows Components\Remote Desktop Services\Remote Desktop Session
Host\Connections\Allow users to connect remotely by using Remote Desktop Services
7. Detach the disk from the rescue VM.
8. Create a new VM from the disk.
If the problem still happens, move to the step 2.
Step 2: Enable remote desktop services
For more information, see Remote Desktop Services isn't starting on an Azure VM.
Step 3: Reset RDP listener
For more information, see Remote Desktop disconnects frequently in Azure VM.

If you still need help, contact support to get your issue resolved quickly.
Troubleshoot authentication errors when you use
RDP to connect to Azure VM
This article can help you troubleshoot authentication errors that occur when you use Remote Desktop Protocol
(RDP ) connection to connect to an Azure virtual machine (VM ).
Symptoms
You capture a screenshot of an Azure VM that shows the Welcome screen and indicates that the operating system
is running. However, when you try to connect to the VM by using Remote Desktop Connection, you receive one of
the following error messages.
Error message 1
Error message 2
The remote computer that you are trying to connect to requires Network Level Authentication (NLA ),
but your Windows domain controller cannot be contacted to perform NLA. If you are an administrator
on the remote computer, you can disable NLA by using the options on the Remote tab of the System
Properties dialog box.
Error message 3 (generic connection error)
This computer can't connect to the remote computer. Try connecting again, if the problem continues,
contact the owner of the remote computer or your network administrator.
Cause
There are multiple reasons why NLA might block the RDP access to a VM.
Cause 1
The VM cannot communicate with the domain controller (DC ). This problem could prevent an RDP session from
accessing a VM by using domain credentials. However, you would still be able to log on by using the Local
Administrator credentials. This problem may occur in the following situations:
1. The Active Directory Security Channel between this VM and the DC is broken.
2. The VM has an old copy of the account password and the DC has a newer copy.
3. The DC that this VM is connecting to is unhealthy.
Cause 2
The encryption level of the VM is higher than the one that’s used by the client computer.
Cause 3
The TLS 1.0, 1.1, or 1.2 (server) protocols are disabled on the VM.
Cause 4
The VM was set up to disable logging on by using domain credentials, and the Local Security Authority (LSA) is
set up incorrectly.
Cause 5
The VM was set up to accept only Federal Information Processing Standard (FIPS )-compliant algorithm
connections. This is usually done by using Active Directory policy. This is a rare configuration, but FIPS can be
enforced for Remote Desktop connections only.
Before you troubleshoot

Create a backup snapshot
To create a backup snapshot, follow the steps in Snapshot a disk.
Connect to the VM remotely
To connect to the VM remotely , use one of the methods in How to use remote tools to troubleshoot Azure VM
issues.
Group policy client service
If this is a domain-joined VM, first stop the Group Policy Client service to prevent any Active Directory Policy from
overwriting the changes. To do this, run the following command:
REM Disable the member server to retrieve the latest GPO from the domain upon start
REG add "HKLM\SYSTEM\CurrentControlSet\Services\gpsvc" /v Start /t REG_DWORD /d 4 /f
After the problem is fixed, restore the ability of this VM to contact the domain to retrieve the latest GPO from the
domain. To do this, run the following commands:
sc config gpsvc start= auto

sc start gpsvc
gpupdate /force
If the change is reverted, it means that an Active Directory policy is causing the problem.
Workaround
To work around this problem, run the following commands in the command window to disable NLA:
REM Disable the Network Level Authentication

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t
REG_DWORD /d 0
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t
REG_DWORD /d 0
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v
fAllowSecProtocolNegotiation /t REG_DWORD /d 0
Then, restart the VM.

To re-enable NLA, run the following command, and then restart the VM:
REG add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v disabledomaincreds /t REG_DWORD /d 0 /f
REG add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t

REG_DWORD /d 1 /f
REG add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t
REG_DWORD /d 1 /f
REG add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v
fAllowSecProtocolNegotiation /t REG_DWORD /d 1 /f
Troubleshooting
For domain-joined VMs
To troubleshoot this problem, first check whether the VM can connect to a DC, and whether the DC has a status of
"healthy" and can handle requests from the VM.
NOTE
To test the DC health, you can use another VM on the same VNET and Subnet that share the same logon server.
Connect to the VM that has the problem by using Serial console, remote CMD, or remote PowerShell, according to
the steps in the “Connect to the VM remotely” section.
To determine which DC the VM is connecting to, run the following command in the console:
set | find /i "LOGONSERVER"
Then, check the health of the secure channel between the VM and the DC. To do this, run the following command
in an elevated PowerShell instance. This command returns a Boolean flag that indicates whether the secure
channel is alive:
Test-ComputerSecureChannel -verbose
If the channel is broken, run the following command to repair it:
Test-ComputerSecureChannel -repair
Make sure that the computer account password in Active Directory is updated on the VM and the DC:
Reset-ComputerMachinePassword -Server "<COMPUTERNAME>" -Credential <DOMAIN CREDENTIAL WITH DOMAIN ADMIN LEVEL>
If the communication between the DC and the VM is good, but the DC is not healthy enough to open an RDP
session, you can try to restart the DC.
If the preceding commands did not fix the communication problem to the domain, you can rejoin this VM to the
domain. To do this, follow these steps:
1. Create a script that’s named Unjoin.ps1 by using the following content, and then deploy the script as a
Custom Script Extension on the Azure portal:
cmd /c "netdom remove <<MachineName>> /domain:<<DomainName>> /userD:<<DomainAdminhere>> /passwordD:

<<PasswordHere>> /reboot:10 /Force"
This script takes the VM out of the domain forcibly and restarts it 10 seconds later. Then, you have to clean
up the Computer object on the domain side.
2. After the cleanup is done, rejoin this VM to the domain. To do this, create a script that’s named
JoinDomain.ps1 by using the following content, and then deploy the script as a Custom Script Extension on
the Azure portal:
cmd /c "netdom join <<MachineName>> /domain:<<DomainName>> /userD:<<DomainAdminhere>> /passwordD:
<<PasswordHere>> /reboot:10"
NOTE
This joins the VM on the domain by using the specified credentials.
If the Active Directory channel is healthy, the computer password is updated, and the domain controller is working
as expected, try the following steps.
If the problem persists, check whether the domain credential is disabled. To do this, open an elevated Command
Prompt window, and then run the following command to determine whether the VM is set up to disable domain
accounts for logging on to the VM:
REG query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v disabledomaincreds
If the key is set to 1, this means that the server was set up not to allow domain credentials. Change this key to 0.
For standalone VMs
Check MinEncryptionLevel
In an CMD instance, run the following command to query the MinEncryptionLevel registry value:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel
Based on the registry value, follow these steps:

4 (FIPS ): Go to Check FIPs compliant algorithms connections.
3 (128-bit encryption): Set the severity to 2 by running the following command:

MinEncryptionLevel /t REG_DWORD /d 2 /f
2 (Highest encryption possible, as dictated by the client): You can try to set the encryption to the minimum
value of 1 by running the following command:

MinEncryptionLevel /t REG_DWORD /d 1 /f
Restart the VM so that the changes to the registry take effect.

TLS version
Depending on the system, RDP uses the TLS 1.0, 1.1, or 1.2 (server) protocol. To query how these protocols are set
up on the VM, open a CMD instance, and then run the following commands:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v

Enabled
Enabled
Enabled
If the returned values are not all 1, this means that the protocol is disabled. To enable these protocols, run the
following commands:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled

For other protocol versions, you can run the following commands:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS x.x

\Server" /v Enabled
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS x.x
\Server" /v Enabled
NOTE
Get the SSH/TLS version x.x from the Guest OS Logs on the SCHANNEL errors.
Check FIPs compliant algorithms connections

Remote desktop can be enforced to use only FIPs-compliant algorithm connections. This can be set by using a
registry key. To do this, open an elevated Command Prompt window, and then query the following keys:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy" /v Enabled
If the command returns 1, change the registry value to 0.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy" /v Enabled /t REG_DWORD /d 0
Check which is the current MinEncryptionLevel on the VM:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel
If the command returns 4, change the registry value to 2
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel /t

REG_DWORD /d 2
Restart the VM so that the changes to the registry take effect.
Next steps
SetEncryptionLevel method of the Win32_TSGeneralSetting class
Configure Server Authentication and Encryption Levels
Win32_TSGeneralSetting class
Troubleshoot Azure VM RDP connection issues by
Event ID
This article explains how to use event IDs to troubleshoot issues that prevent a Remote Desktop protocol (RDP )
connection to an Azure Virtual Machine (VM ).
Symptoms
You try to use a Remote Desktop protocol (RDP ) session to connect to an Azure VM. After you input your
credentials, the connection fails, and you receive the following error message:
This computer can't connect to the remote computer. Try connecting again, if the problem continues,
contact the owner of the remote computer or your network administrator.
To troubleshoot this issue, review the event logs on the VM, and then refer to the following scenarios.
Before you troubleshoot

Create a backup snapshot
To create a backup snapshot, follow the steps in Snapshot a disk.
Connect to the VM remotely
To connect to the VM remotely, use one of the methods in How to use remote tools to troubleshoot Azure VM
issues.
Scenario 1
Event logs
In a CMD instance, run the following commands to check whether event 1058 or event 1057 is logged in the
System log within the past 24 hours:
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Microsoft-Windows-TerminalServices-

RemoteConnectionManager'] and EventID=1058 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Microsoft-Windows-TerminalServices-
RemoteConnectionManager'] and EventID=1057 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
Log Name: System

Source: Microsoft-Windows-TerminalServices-RemoteConnectionManager
Date: time
Event ID: 1058
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: computer
Description: The RD Session Host Server has failed to replace the expired self signed certificate used for RD
Session Host Server authentication on SSL connections. The relevant status code was Access is denied.
Log Name: System
Date: time
Event ID: 1058
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: computer
Description: RD Session host server has failed to create a new self-signed certificate to be used for RD Session
host server authentication on SSL connections, the relevant status code was object already exists.
Log Name: System
Date: time
Event ID: 1057
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: computer
Description: The RD Session Host Server has failed to create a new self signed certificate to be used for RD
Session Host Server authentication on SSL connections. The relevant status code was Keyset does not exist
You can also check for SCHANNEL error events 36872 and 36870 by running the following commands:
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Schannel'] and EventID=36870 and

TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
Log Name: System

Source: Schannel
Date: —
Event ID: 36870
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: computer
Description: A fatal error occurred when attempting to access the SSL server credential private key. The error
code returned from the cryptographic module is 0x8009030D.
The internal error state is 10001.
Cause
This issue occurs because the local RSA encryption keys in the MachineKeys folder on the VM can't be accessed.
This issue can occur for one of the following reasons:
1. Wrong permissions configuration on the Machinekeys folder or the RSA files.
2. Corrupted or missing RSA key.
Resolution
To troubleshoot this issue, you have to set up the correct permissions on the RDP Certificate by using these steps.
Grant permission to the MachineKeys folder
1. Create a script by using the following content:
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > c:\temp\BeforeScript_permissions.txt
takeown /f "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /a /r
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "NT AUTHORITY\System:(F)"
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "NT AUTHORITY\NETWORK SERVICE:(R)"
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > c:\temp\AfterScript_permissions.txt
Restart-Service TermService -Force
2. Run this script to reset the permissions of the MachineKey folder and to reset the RSA files to the default
values.
3. Try to access the VM again.
After running the script, you can check the following files that are experiencing permissions issues:
c:\temp\BeforeScript_permissions.txt
c:\temp\AfterScript_permissions.txt
Renew RDP self-signed certificate
If the issue persists, run the following script to make sure that the RDP self-signed certificate is renewed:
Import-Module PKI
Set-Location Cert:\LocalMachine
$RdpCertThumbprint = 'Cert:\LocalMachine\Remote Desktop\'+((Get-ChildItem -Path 'Cert:\LocalMachine\Remote
Desktop\').thumbprint)
Remove-Item -Path $RdpCertThumbprint
If you can't renew the certificate, follow these steps to try to delete the certificate:
1. On another VM in the same VNET, open the Run box, type mmc, and then press OK.
2. On the File menu, select Add/Remove Snap-in.
3. In the Available snap-Ins list, select Certificates, and then select Add.
4. Select Computer account, and then select Next.
5. Select Another computer, and then add the IP address of the VM that has problems.
NOTE
Try to use the internal network to avoid using a virtual IP address.
6. Select Finish, and then select OK.

7. Expand the certificates, go to the Remote Desktop\Certificates folder, right-click the certificate, and then
select Delete.
8. Restart the Remote Desktop Configuration service:
net stop SessionEnv

net start SessionEnv
NOTE
At this point, if you refresh the store from mmc, the certificate reappears.
Try to access the VM by using RDP again.

Update Secure Sockets Layer (SSL) certificate
If you set up the VM to use an SSL certificate, run the following command to get the thumbprint. Then check
whether it's the same as the certificate's thumbprint:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v

SSLCertificateSHA1Hash
If it isn't, change the thumbprint:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SSLCertificateSHA1Hash

/t REG_BINARY /d <CERTIFICATE THUMBPRINT>
You can also try to delete the key so that the RDP uses the self-signed certificate for RDP:
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v

SSLCertificateSHA1Hash
Scenario 2
Event log
In a CMD instance, run the following commands to check whether SCHANNEL error event 36871 is logged in the
System log within the past 24 hours:
Log Name: System

Source: Schannel
Date: —
Event ID: 36871
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: computer
Description: A fatal error occurred while creating a TLS server credential. The internal error state is 10013.
Cause
This issue is caused by security policies. When older versions of TLS (such as 1.0) are disabled, RDP access fails.
Resolution
RDP uses TLS 1.0 as the default protocol. However, the protocol might be changed to TLS 1.1, which is the new
standard.
To troubleshoot this issue, see Troubleshoot authentication errors when you use RDP to connect to Azure VM.
Scenario 3
If you have installed the Remote Desktop Connection Broker role on the VM, check whether there's event 2056
or event 1296 within the past 24 hours. In a CMD instance, run the following commands:
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name=' Microsoft-Windows-TerminalServices-

SessionBroker '] and EventID=2056 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name=' Microsoft-Windows-TerminalServices-
SessionBroker-Client '] and EventID=1296 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
Log Name: Microsoft-Windows-TerminalServices-SessionBroker/Operational

Source: Microsoft-Windows-TerminalServices-SessionBroker
Date: time
Event ID: 2056
Task Category: (109)
Level: Error
Keywords:
User: NETWORK SERVICE
Computer: computer fqdn
Description: The description for Event ID 2056 from source Microsoft-Windows-TerminalServices-SessionBroker
cannot be found. Either the component that raises this event is not installed on your local computer or the
installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
NULL
NULL
Logon to the database failed.
Log Name: Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
Source: Microsoft-Windows-TerminalServices-SessionBroker-Client
Date: time
Event ID: 1296
Task Category: (104)
Level: Error
Keywords:
User: NETWORK SERVICE
Computer: computer fqdn
Description: The description for Event ID 1296 from source Microsoft-Windows-TerminalServices-
SessionBroker-Client cannot be found. Either the component that raises this event is not installed on your local
computer or the installation is corrupted. You can install or repair the component on the local computer. If the
event originated on another computer, the display information had to be saved with the event. The following
information was included with the event:
text
text
Remote Desktop Connection Broker is not ready for RPC communication.
Cause
This issue occurs because the host name of the Remote Desktop Connection Broker server is changed, which is not
a supported change.
The hostname has entries and dependencies on the Windows Internal Database, which is required by Remote
Desktop Service farm in order to be able to work. Changing the hostname after the farm is already built causes
many errors and can cause the broker server to stop working.
Resolution
To fix this issue, the Remote Desktop Connection Broker role and the Windows Internal Database must be
reinstalled.
Next Steps
Schannel Events
Schannel SSP Technical Overview
RDP Fails with Event ID 1058 & Event 36870 with Remote Desktop Session Host Certificate & SSL
Communication
Schannel 36872 or Schannel 36870 on a Domain Controller
Event ID 1058 — Remote Desktop Services Authentication and Encryption
Cannot remote desktop to Azure Virtual Machines
because of static IP
This article describes a problem in which you cannot remote desktop to Azure Windows Virtual Machines (VMs)
after a static IP is configured in the VM.
NOTE
Symptoms
When you make an RDP connection to a VM in Azure, you receive the following error message:
Remote Desktop can't connect to the remote computer for one of these reasons:
1. Remote access to the server is not enabled
2. The remote Computer is turned off
3. The remote computer is not available on the network
Make sure the remote computer is turned on and connected to the network, and that remote access is
enabled.
When you check the screenshot in the Boot diagnostics in the Azure portal, you see the VM boots normally and
waits for credentials in the login screen.
Cause
The VM has a static IP address that's defined on the network interface within Windows. This IP address differs
from the address that's defined in the Azure portal.
Solution
To resolve this issue, use Serial control to enable DHCP or reset network interface for the VM.
Use Serial control
1. Connect to Serial Console and open CMD instance. If the Serial Console is not enabled on your VM, see
Reset network interface.
2. Check if the DHCP is disabled on the network interface:
netsh interface ip show config

3. If the DHCP is disabled, revert the configuration of your network interface to use DHCP:
netsh interface ip set address name="<NIC Name>" source=dhc
For example, if the interwork interface names "Ethernet 2", run the following command:
netsh interface ip set address name="Ethernet 2" source=dhc
4. Query the IP configuration again to make sure that the network interface is now correctly set up. The new IP
address should match the one that’s provided by the Azure.
You don't have to restart the VM at this point. The VM will be back reachable.
After that, if you want to configure the static IP for the VM, see Configure static IP addresses for a VM.
Cannot remote desktop to a VM because the
network interface is disabled
This article explains how to resolve a problem in which you cannot make a Remote Desktop connection to Azure
Windows Virtual Machines (VMs) if the network interface is disabled.
NOTE
Symptoms
You cannot make an RDP connection or any other type of connection to any other ports to a VM in Azure because
the network interface in the VM is disabled.
Solution
To enable the interface for the VM, use Serial control or reset network interface for the VM.
Use Serial control
reset network interface.
2. Check the state of the network interface:
netsh interface show interface
Note the name of the disabled network interface.

3. Enable the network interface:
netsh interface set interface name="interface Name" admin=enabled
For example, if the interwork interface is named "Ethernet 2", run the following command:
netsh interface set interface name=""Ethernet 2" admin=enabled
4. Check the state of the network interface again to make sure that the network interface is enabled.
You don't have to restart the VM at this point. The VM will be back reachable.
5. Connect to the VM and see whether the problem is resolved.
Reset network interface

To reset network interface, change the IP address to another IP address that is available in the Subnet. To do this,
use Azure portal or Azure PowerShell. For more information, see Reset network interface.
Cannot RDP to a VM because the VM boots into
Safe Mode
This article shows how to resolve a problem in which you cannot connect to Azure Windows Virtual Machines
(VMs) because the VM is configured to boot into Safe Mode.
NOTE
Symptoms
You cannot make an RDP connection or other connections (such as HTTP ) to a VM in Azure because the VM is
configured to boot into Safe Mode. When you check the screenshot in the Boot diagnostics in the Azure portal,
you might see that the VM boots normally, but the network interface is not available:
Cause
The RDP service is not available in Safe Mode. Only essential system programs and services are loaded when the
VM boots into Safe Mode. This applies for the two different versions of Safe Mode which are "Safe Boot minimal"
and "Safe Boot with connectivity".
Solution
To resolve this issue, use Serial control to configure the VM to boot into normal mode or repair the VM offline by
using a recovery VM.
Use Serial control
repair the VM offline.
2. Check the boot configuration data:
bcdedit /enum
If the VM is configured to boot into Safe Mode, you will see an extra flag under the Windows Boot Loader
section called safeboot. If you do not see the safeboot flag, the VM is not in Safe Mode. This article does
not apply to your scenario.
The safeboot flag could appear with the following values:
Minimal
Network
In either of these two modes, RDP will not be started. Therefore, the fix remains the same.
3. Delete the safemoade flag, so the VM will boot into normal mode:
bcdedit /deletevalue {current} safeboot
4. Check the boot configuration data to make sure that the safeboot flag is removed:
bcdedit /enum
5. Restart the VM, and then check whether the issue is resolved.
assigned to the attached OS disk.
Enable dump log and Serial Console (optional)
The dump log and Serial Console will help us to do further troubleshooting if the problem cannot be resolved by
the solution in this article.
In this script, we assume that the drive letter that is assigned to the attached OS disk is F. Replace this drive
reg load HKLM\BROKENSYSTEM F:\windows\system32\config\SYSTEM



Configure the Windows to boot into normal mode

2. Check the boot configuration data. In the following commands, we assume that the drive letter that is
assigned to the attached OS disk is F. Replace this drive letter with the appropriate value for your VM.
bcdedit /store F:\boot\bcd /enum
Take note of the Identifier name of the partition that has the \windows folder. By default, the Identifier
name is "Default".
If the VM is configured to boot into Safe Mode, you will see an extra flag under the Windows Boot Loader
section called safeboot. If you do not see the safeboot flag, this article does not apply to your scenario.
3. Remove the safeboot flag, so the VM will boot into normal mode:
bcdedit /store F:\boot\bcd /deletevalue {Default} safeboot
4. Check the boot configuration data to make sure that the safeboot flag is removed:
bcdedit /store F:\boot\bcd /enum
This article provides a reference for situations in which you suspect that the guest operating system firewall is
filtering partial or complete traffic to a virtual machine (VM ). This could occur if changes were deliberately made to
the firewall that caused RDP connections to fail.
Solution
The process that is described in this article is intended to be used as a workaround so that you can focus on fixing
your real issue, which is how to set up the firewall rules correctly. It\rquote s a Microsoft Best Practice to have the
Windows Firewall component enabled. How you configure the firewall rules \cf3 depends on the level of access to
the VM that\rquote s required.
Online Solutions
If the VM is online and can be accessed on another VM on the same virtual network, you can make these
mitigations by using the other VM.
Mitigation 1: Custom Script Extension or Run Command feature
If you have a working Azure agent, you can use Custom Script Extension or the Run Commands feature (Resource
Manager VMs only) to remotely run the following scripts.
NOTE
If the firewall is set locally, run the following script:
Set-ItemProperty -Path
'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\DomainProfile' -name
"EnableFirewall" -Value 0
'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\PublicProfile' -name
'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\Standardprofile' -
name "EnableFirewall" -Value 0
Restart-Service -Name mpssvc
If the firewall is set through an Active Directory policy, you can use run the following script for temporary access.
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile' -name

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\WindowsFirewall\PublicProfile' -name
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\WindowsFirewall\StandardProfile' name
However, as soon as the policy is applied again, you’ll be kicked out of the remote session. The permanent fix for this
issue is to modify the policy that's applied on this computer.
Mitigation 2: Remote PowerShell

1. Connect to a VM that’s located on the same virtual network as the VM that you cannot reach by using RDP
connection.
2. Open a PowerShell console window.
3. Run the following commands:
Enter-PSSession (New-PSSession -ComputerName "<HOSTNAME>" -Credential (Get-Credential) -SessionOption

(New-PSSessionOption -SkipCACheck -SkipCNCheck))
netsh advfirewall set allprofiles state off
exit
NOTE
If the firewall is set through a Group Policy Object, this method may not work because this command changes only the local
registry entries. If a policy is in place, it will override this change.
Mitigation 3: PSTools commands

1. On the troubleshooting VM, download PSTools.
2. Open a CMD instance, and then access the VM through its DIP.
psexec \\<DIP> -u <username> cmd

psservice restart mpssvc
Mitigation 4: Remote Registry

Follow these steps to use Remote Registry.
1. On the troubleshooting VM, start registry editor, and then go to File > Connect Network Registry.
2. Open up the TARGET MACHINE\SYSTEM branch, and specify the following values:
<TARGET
MACHINE>\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\EnableFi
rewall --> 0
<TARGET
MACHINE>\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\PublicProfile\EnableFi
rewall --> 0
<TARGET
MACHINE>\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\Enable
Firewall --> 0
3. Restart the service. Because you cannot do that by using the remote registry, you must use Remove Service
Console.
4. Open an instance of Services.msc.
5. Click Services (Local).
6. Select Connect to another computer.
7. Enter the Private IP Address (DIP ) of the problem VM.
8. Restart the local firewall policy.
9. Try to connect to the VM through RDP again from your local computer.
Offline Solutions
If you have a situation in which you cannot reach the VM by any method, Custom Script Extension will fail, and
you will have to work in OFFLINE mode by working directly through the system disk. To do that, follow these
steps:
1. Attach the system disk to a recovery VM.
3. Make sure that the disk is flagged as Online in the Disk Management console. Note the drive letter that’s
assigned to the attached system disk.
4. Before you make any changes, create a copy of the \windows\system32\config folder in case a rollback of
the changes is necessary.
5. On the troubleshooting VM, start the registry editor (regedit.exe).
6. For this troubleshooting procedure, we are mounting the hives
as BROKENSYSTEM and BROKENSOFTWARE.
7. Highlight the HKEY_LOCAL_MACHINE key, and then select File > Load Hive from the menu.
8. Locate the \windows\system32\config\SYSTEM file on the attached system disk.
9. Open an elevated PowerShell instance, and then run the following commands:
# Load the hives - If your attached disk is not F, replace the letter assignment here
reg load HKLM\BROKENSYSTEM f:\windows\system32\config\SYSTEM
reg load HKLM\BROKENSOFTWARE f:\windows\system32\config\SOFTWARE
# Disable the firewall on the local policy
$ControlSet = (get-ItemProperty -Path 'HKLM:\BROKENSYSTEM\Select' -name "Current").Current
$key =
'BROKENSYSTEM\ControlSet00'+$ControlSet+'\services\SharedAccess\Parameters\FirewallPolicy\DomainProfile'
Set-ItemProperty -Path $key -name 'EnableFirewall' -Value 0 -Type Dword -force
$key =
'BROKENSYSTEM\ControlSet00'+$ControlSet+'\services\SharedAccess\Parameters\FirewallPolicy\PublicProfile'
$key =
'BROKENSYSTEM\ControlSet00'+$ControlSet+'\services\SharedAccess\Parameters\FirewallPolicy\StandardProfil
e'
# To ensure the firewall is not set thru AD policy, check if the following registry entries exist and if
they do, then check if the following entries exist:
$key = 'HKLM:\BROKENSOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile'
$key = 'HKLM:\BROKENSOFTWARE\Policies\Microsoft\WindowsFirewall\PublicProfile'
$key = 'HKLM:\BROKENSOFTWARE\Policies\Microsoft\WindowsFirewall\StandardProfile'
# Unload the hives
reg unload HKLM\BROKENSOFTWARE
10. Detach the system disk and re-create the VM.

11. Check whether the issue is resolved.
Enable or disable a firewall rule on an Azure VM
Guest OS
This article provides a reference for troubleshooting a situation in which you suspect that the guest operating
system firewall is filtering partial traffic on a virtual machine (VM ). This could be useful for the following reasons:
If a change was deliberately made to the firewall that caused RDP connections to fail, using the Custom
Script Extension feature can resolve the issue.
Disabling all firewall profiles is a more foolproof way of troubleshooting than setting the RDP -specific
firewall rule.
Solution
How you configure the firewall rules depends on the level of access to the VM that’s required. The following
examples use RDP rules. However, the same methods can be applied to any other kind of traffic by pointing to the
correct registry key.
Online troubleshooting
Mitigation 1: Custom Script Extension
1. Create your script by using the following template.
To enable a rule:
netsh advfirewall firewall set rule dir=in name="Remote Desktop - User Mode (TCP-In)" new
enable=yes
To disable a rule:
enable=no
2. Upload this script in the Azure portal using the Custom Script Extension feature.
Mitigation 2: Remote PowerShell
If the VM is online and can be accessed on another VM on the same virtual network, you can make the follow
1. On the troubleshooting VM, open a PowerShell console window.
2. Run the following commands, as appropriate.
To enable a rule:
Enter-PSSession (New-PSSession -ComputerName "<HOSTNAME>" -Credential (Get-Credential) -

SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck))
Enable-NetFirewallRule -DisplayName "RemoteDesktop-UserMode-In-TCP"
exit
To disable a rule:
Enter-PSSession (New-PSSession -ComputerName "<HOSTNAME>" -Credential (Get-Credential) -
SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck))
Disable-NetFirewallRule -DisplayName "RemoteDesktop-UserMode-In-TCP"
exit
Mitigation 3: PSTools commands

If the VM is online and can be accessed on another VM on the same virtual network, you can make the follow
1. On the troubleshooting VM, download PSTools.
2. Open a CMD instance, and access the VM through its Internal IP (DIP ).
To enable a rule:

enable=yes
To disable a rule:

enable=no
Mitigation 4: Remote Registry

If the VM is online and can be accessed on another VM on the same virtual network, you can use Remote Registry
on the other VM.
1. On the troubleshooting VM, start Registry Editor (regedit.exe), and then select File > Connect Network
Registry.
2. Open the TARGET MACHINE\SYSTEM branch, and then specify the following values:
To enable a rule, open the following registry value:
TARGET
MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\Firewall
Rules\RemoteDesktop-UserMode-In-TCP
Then, change Active=FALSE to Active=TRUE in the string:
v2.22|Action=Allow|Active=TRUE|Dir=In|Protocol=6|Profile=Domain|Profile=Private|Prof
ile=Public|LPort=3389|App=%SystemRoot%\system32\svchost.exe|Svc=termservice|Name
=@FirewallAPI.dll,-28775|Desc=@FirewallAPI.dll,-28756|EmbedCtxt=@FirewallAPI.dll,-
28752|
To disable a rule, open the following registry value:
TARGET
MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\Firewall
Rules\RemoteDesktop-UserMode-In-TCP
Then, change Active =TRUE to Active=FALSE:
v2.22|Action=Allow|Active=FALSE|Dir=In|Protocol=6|Profile=Domain|Profile=Private|Pro
file=Public|LPort=3389|App=%SystemRoot%\system32\svchost.exe|Svc=termservice|Nam
e=@FirewallAPI.dll,-28775|Desc=@FirewallAPI.dll,-28756|EmbedCtxt=@FirewallAPI.dll,-
28752|
3. Restart the VM to apply the changes.
Offline troubleshooting
If you cannot access the VM by any method, using Custom Script Extension will fail, and you will have to work in
OFFLINE mode by working directly through the system disk.
Before you follow these steps, take a snapshot of the system disk of the affected VM as a backup. For more
3. Make sure that the disk is flagged as Online in the Disk Management console. Note that the drive letter
that is assigned to the attached system disk.
4. Before you make any changes, create a copy of the \windows\system32\config folder in case a rollback of
the changes is necessary.
5. On the troubleshooting VM, start Registry Editor (regedit.exe).
6. Highlight the HKEY_LOCAL_MACHINE key, and then select File > Load Hive from the menu.
7. Locate and then open the \windows\system32\config\SYSTEM file.
NOTE
You are prompted for a name. Enter BROKENSYSTEM, and then expand HKEY_LOCAL_MACHINE. You will now
see an additional key that’s named BROKENSYSTEM. For this troubleshooting, we are mounting these problem
hives as BROKENSYSTEM.
8. Make the following changes on the BROKENSYSTEM branch:

a. Check which ControlSet registry key the VM is starting from. You will see its key number
in HKLM\BROKENSYSTEM\Select\Current.
b. To enable a rule, open the following registry value:
HKLM\BROKENSYSTEM\ControlSet00X\Services\SharedAccess\Parameters\FirewallPolicy\Firewa
llRules\RemoteDesktop-UserMode-In-TCP
Then, change Active=FALSE to Active=True.
v2.22|Action=Allow|Active=TRUE|Dir=In|Protocol=6|Profile=Domain|Profile=Private|Prof
ile=Public|LPort=3389|App=%SystemRoot%\system32\svchost.exe|Svc=termservice|Name
=@FirewallAPI.dll,-28775|Desc=@FirewallAPI.dll,-28756|EmbedCtxt=@FirewallAPI.dll,-
28752|
c. To disable a rule, open the following registry key:
HKLM\BROKENSYSTEM\ControlSet00X\Services\SharedAccess\Parameters\FirewallPolicy\Firewa
llRules\RemoteDesktop-UserMode-In-TCP
Then, change Active=True to Active=FALSE.
v2.22|Action=Allow|Active=FALSE|Dir=In|Protocol=6|Profile=Domain|Profile=Private|Pro
file=Public|LPort=3389|App=%SystemRoot%\system32\svchost.exe|Svc=termservice|Nam
e=@FirewallAPI.dll,-28775|Desc=@FirewallAPI.dll,-28756|EmbedCtxt=@FirewallAPI.dll,-
28752|
9. Highlight BROKENSYSTEM, and then select File > Unload Hive from the menu.
Azure VM Guest OS firewall is blocking inbound
traffic
This article discusses how to fix the Remote Desktop Portal (RDP ) issue that occurs if the guest operating system
firewall blocks inbound traffic.
Symptoms
You cannot use an RDP connection to connect to an Azure virtual machine (VM ). From Boot diagnostics ->
Screenshot, it shows that the operating system is fully loaded at the Welcome screen (Ctrl+Alt+Del).
Cause
Cause 1
The RDP rule is not set up to allow the RDP traffic.
Cause 2
The guest system firewall profiles are set up to block all inbound connections, including the RDP traffic.
Solution
To fix the issue, use one of the methods in How to use remote tools to troubleshoot Azure VM issues to connect to
the VM remotely, and then edit the guest operating system firewall rules to Allow RDP traffic.
Online troubleshooting
Connect to the Serial Console, and then open a PowerShell instance. If the Serial Console is not enabled on the
VM, go to "Repair the VM Offline.
Mitigation 1
1. If Azure Agent is installed and working correctly on the VM, you can use the "Reset configuration only"
option under Support + troubleshooting > Reset password on the VM menu.
2. Running this recovery option does the following:
Enables an RDP component if it’s disabled.
Enables all Windows firewall profiles.
Make sure that the RDP rule is turned on in Windows Firewall.
If the previous steps don’t work, manually reset the firewall rule. To do this, query all the rules that
contain the name "Remote Desktop" by running the following command:
netsh advfirewall firewall show rule dir=in name=all | select-string -pattern "(Name.*Remote
Desktop)" -context 9,4 | more
If the RDP port was set to any other port other than 3389, you have to find any custom rule that
might have been created and set to this port. To query for all the inbound rules that have a custom
port, run the following command:
netsh advfirewall firewall show rule dir=in name=all | select-string -pattern "(LocalPort.*
<CUSTOM PORT>)" -context 9,4 | more
3. If you see that the rule is disabled, enable it. To open a whole group, such as the built-in Remote Desktop
group, run the following command:
netsh advfirewall firewall set rule group="Remote Desktop" new enable=yes
Otherwise, to open the specific Remote Desktop (TCP -In) rule, run the following command:
netsh advfirewall firewall set rule name="<CUSTOM RULE NAME>" new enable=yes
4. For troubleshooting, you can turn the firewall profiles to OFF:
After you finish troubleshooting and setting the firewall correctly, re-enable the firewall.
NOTE
You don't have to restart the VM to apply these changes.
5. Try to make an RDP connection to access the VM.

Mitigation 2
1. Query the firewall profiles to determine whether the inbound firewall policy is set to BlockInboundAlways:
netsh advfirewall show allprofiles | more
NOTE
The following guidelines apply to the firewall policy, depending on how it’s set up:
BlockInbound: All inbound traffic will be blocked unless you have a rule in effect to allow that traffic.
BlockInboundAlways: All firewall rules will be ignored and all traffic will be blocked.
2. Edit the DefaultInboundAction to set these profiles to Allow traffic. To do this, run the following command:
netsh advfirewall set allprofiles firewallpolicy allowinbound,allowoutbound
3. Query the profiles again to make sure that your change was made successfully. To do this, run the following
command:
netsh advfirewall show allprofiles | more
NOTE
You don't have to restart the VM to apply the changes.
4. Try again to access your VM through RDP.

Offline Mitigations
Mitigation 1
See How to Enable-Disable a Firewall rule on a Guest OS.
Mitigation 2
3. After the system disk is attached to the recovery VM, make sure that the disk is flagged as Online in the
Disk Management console. Note the drive letter that is assigned to the attached OS disk.
4. Open an elevated CMD instance, and then run the following script:
REM Backup the registry prior doing any change

robocopy f:\windows\system32\config f:\windows\system32\config.BACK /MT
REM Mount the hive

reg load HKLM\BROKENSYSTEM f:\windows\system32\config\SYSTEM
REM Delete the keys to block all inbound connection scenario

REG DELETE
"HKLM\BROKENSYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\DomainProfile" /v
DoNotAllowExceptions
REG DELETE
"HKLM\BROKENSYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\PublicProfile" /v
REG DELETE
"HKLM\BROKENSYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\StandardProfile" /v
REG DELETE
"HKLM\BROKENSYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\DomainProfile" /v
REG DELETE
"HKLM\BROKENSYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\PublicProfile" /v
REG DELETE
"HKLM\BROKENSYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\StandardProfile" /v
REM Unmount the hive


Azure VM guest OS firewall is misconfigured
This article introduce how to fix misconfigured guest operating system firewall on Azure VM.
Symptoms
1. The virtual machine (VM ) Welcome screen shows that the VM is fully loaded.
2. Depending on how the guest operating system is configured, there could be some or no network traffic
reaching the VM.
Cause
A misconfiguration of the guest system firewall can block some or all kinds of network traffic to the VM.
Solution
To troubleshoot this issue, use the Serial Console or repair the VM offline by attaching the system disk of the VM
to a recovery VM.
Online mitigations
Connect to the Serial Console, and then open a PowerShell instance. If the Serial Console is not enabled on the
VM, go to the "Repair the VM Offline" section of the following Azure article:
An internal error occurs when you try to connect to an Azure VM through Remote Desktop
The following rules can be edited to either enable access to the VM (through RDP ) or to provide an easier
troubleshooting experience:
Remote Desktop (TCP -In): This is the standard rule that provides primary access to the VM by allowing
RDP in Azure.
Windows Remote Management (HTTP -In): This rule enables you to connect to the VM by using
PowerShell., In Azure, this kind of access lets you use the scripting aspect of remote scripting and
troubleshooting.
File and Printer Sharing (SMB -In): This rule enables network share access as a troubleshooting option.
File and Printer Sharing (Echo Request - ICMPv4-In): This rule enables you to ping the VM.
In the Serial Console Access instance, you can query the current status of the firewall rule.
Query by using the Display Name as a parameter:
netsh advfirewall firewall show rule dir=in name=all | select-string -pattern "(DisplayName.*<FIREWALL
RULE NAME>)" -context 9,4 | more
Query by using the Local Port that the application uses:

netsh advfirewall firewall show rule dir=in name=all | select-string -pattern "(LocalPort.*<APPLICATION
PORT>)" -context 9,4 | more
Query by using the Local IP address that the application uses:
netsh advfirewall firewall show rule dir=in name=all | select-string -pattern "(LocalIP.*<CUSTOM IP>)" -
context 9,4 | more
If you see that the rule is disabled, you can enable it by running the following command:
netsh advfirewall firewall set rule name="<RULE NAME>" new enable=yes
For troubleshooting, you can turn the firewall profiles OFF:
If you do this to set the firewall correctly, re-enable the firewall after you finish your troubleshooting.
NOTE
You don't have to restart the VM to apply this change.
Try again to connect to the VM through RDP.

Offline Mitigations
1. To enable or disable firewall rules, refer to Enable or disable a firewall rule on an Azure VM Guest OS.
2. Check whether you are in the Guest OS firewall blocking inbound traffic scenario.
3. If you are still in doubt about whether the firewall is blocking your access, refer to Disable the guest OS
Firewall in Azure VM, and then re-enable the guest system firewall by using the correct rules.
Cannot connect remotely to a Windows 10 or
Windows Server 2016 VM in Azure because of
netvsc.sys
This article explains how to troubleshoot an issue in which there is no network connection when you connect to a
Windows 10 or Windows Server 2016 Datacenter virtual machine (VM ) on a Hyper-V Server 2016 host.
Symptoms
You cannot connect to an Azure Windows 10 or Windows Server 2016 VM by using Remote Desktop Protocol
(RDP ). In Boot diagnostics, the screen shows a red cross over the network interface card (NIC ). This indicates that
the VM has no connectivity after the operating system is fully loaded.
Typically, this issue occurs in Windows build 14393 and build 15063. If the version of your operating system is
later than these versions, this article does not apply to your scenario. To check the version of the system, open a
CMD session in the Serial Access Console feature, and then run Ver.
Cause
This issue might occur if the version of the installed netvsc.sys system file is 10.0.14393.594 or 10.0.15063.0.
These versions of netvsc.sys might prevent the system from interacting with the Azure platform.
Solution
Before you follow these steps, take a snapshot of the system disk of the affected VM as a backup. To troubleshoot
this issue, use the Serial Console or repair the VM offline by attaching the system disk of the VM to a recovery
VM.
Use the Serial Console
Connect to the Serial Console, open a PowerShell instance, and then follow these steps.
NOTE
If the Serial Console is not enabled on your VM, go to the repair the VM offline section.
1. Run the following command in a PowerShell instance to get the version of the file
(c:\windows\system32\drivers\netvsc.sys):
(get-childitem "$env:systemroot\system32\drivers\netvsc.sys").VersionInfo.FileVersion
2. Download the appropriate update to a new or existing data disk that is attached to a working VM from the
same region:
10.0.14393.594: KB4073562or a later update
10.0.15063.0: KB4016240 or a later update
3. Detach the utility disk from the working VM, and then attach it to the broken VM.
4. Run the following command to install the update on the VM:
dism /ONLINE /add-package /packagepath:<Utility Disk Letter>:\<KB .msu or .cab>
5. Restart the VM.

Repair the VM Offline
4. Create a copy of the \Windows\System32\config folder in case a rollback on the changes is necessary.
5. On the rescue VM, start Registry Editor (regedit.exe).
6. Select the HKEY_LOCAL_MACHINE key, and then select File > Load Hive from the menu.
7. Locate the SYSTEM file in the \Windows\System32\config folder.
8. Select Open, type BROKENSYSTEM for the name, expand the HKEY_LOCAL_MACHINE key, and then
locate the additional key that is named BROKENSYSTEM.
9. Go to the following location:
HKLM\BROKENSYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}
10. In each subkey (such as 0000), examine the DriverDesc value that is displayed as Microsoft HYPER-V
Network Adapter.
11. In the subkey, examine the DriverVersion value that is the driver version of the network adapter of the VM.
12. Download the appropriate update:
10.0.14393.594: KB4073562or a later update
10.0.15063.0: KB4016240 or a later update
13. Attach the system disk as a data disk on a rescue VM on which you can download the update.
14. Run the following command to install the update on the VM:
dism /image:<OS Disk letter>:\ /add-package /packagepath:c:\temp\<KB .msu or .cab>
15. Run the following command to unmount the hives:
16. Detach the system disk, and create the VM again.

If you still need help, contact Azure Support to get your issue resolved quickly.
Troubleshoot SSH connections to an Azure Linux VM
that fails, errors out, or is refused
This article helps you find and correct the problems that occur due to Secure Shell (SSH) errors, SSH connection
failures, or SSH is refused when you try to connect to a Linux virtual machine (VM ). You can use the Azure portal,
Azure CLI, or VM Access Extension for Linux to troubleshoot and resolve connection problems.
NOTE
article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager model.
If you need more help at any point in this article, you can contact the Azure experts on the MSDN Azure and Stack
Overflow forums. Alternatively, you can file an Azure support incident. Go to the Azure support site and select
Get support. For information about using Azure Support, read the Microsoft Azure support FAQ.
Quick troubleshooting steps

After each troubleshooting step, try reconnecting to the VM.
1. Reset the SSH configuration.
2. Reset the credentials for the user.
3. Verify the network security group rules permit SSH traffic.
Ensure that a Network Security Group rule exists to permit SSH traffic (by default, TCP port 22).
You cannot use port redirection / mapping without using an Azure load balancer.
4. Check the VM resource health.
Ensure that the VM reports as being healthy.
If you have boot diagnostics enabled, verify the VM is not reporting boot errors in the logs.
5. Restart the VM.
6. Redeploy the VM.
Continue reading for more detailed troubleshooting steps and explanations.
Available methods to troubleshoot SSH connection issues

You can reset credentials or SSH configuration using one of the following methods:
Azure portal - great if you need to quickly reset the SSH configuration or SSH key and you don't have the
Azure tools installed.
Azure VM Serial Console - the VM serial console will work regardless of the SSH configuration, and will
provide you with an interactive console to your VM. In fact, "can't SSH" situations are specifically what the
serial console was designed to help solve. More details below.
Azure CLI - if you are already on the command line, quickly reset the SSH configuration or credentials. If you
are working with a classic VM, you can use the Azure classic CLI.
Azure VMAccessForLinux extension - create and reuse json definition files to reset the SSH configuration or
user credentials.
Use the Azure portal

The Azure portal provides a quick way to reset the SSH configuration or user credentials without installing any
tools on your local computer.
To begin, select your VM in the Azure portal. Scroll down to the Support + Troubleshooting section and select
Reset password as in the following example:
Reset the SSH configuration

To reset the SSH configuration, select Reset configuration only in the Mode section as in the preceding
screenshot, then select Update. Once this action has completed, try to access your VM again.
Reset SSH credentials for a user
To reset the credentials of an existing user, select either Reset SSH public key or Reset password in the Mode
section as in the preceding screenshot. Specify the username and an SSH key or new password, then select
Update.
You can also create a user with sudo privileges on the VM from this menu. Enter a new username and associated
password or SSH key, and then select Update.
Check security rules
Use IP flow verify to confirm if a rule in a network security group is blocking traffic to or from a virtual machine.
You can also review effective security group rules to ensure inbound "Allow" NSG rule exists and is prioritized for
SSH port (default 22). For more information, see Using effective security rules to troubleshoot VM traffic flow.
Check routing
Use Network Watcher's Next hop capability to confirm that a route isn't preventing traffic from being routed to or
from a virtual machine. You can also review effective routes to see all effective routes for a network interface. For
more information, see Using effective routes to troubleshoot VM traffic flow.
Use the Azure VM Serial Console

The Azure VM Serial Console provides access to a text-based console for Linux virtual machines. You can use the
console to troubleshoot your SSH connection in an interactive shell. Ensure you have met the prerequisites for
using Serial Console and try the commands below to further troubleshoot your SSH connectivity.
Check that SSH is running
You can use the following command to verify whether SSH is running on your VM:
$ ps -aux | grep ssh
If there is any output, SSH is up and running.

Check which port SSH is running on
You can use the following command to check which port SSH is running on:
$ sudo grep Port /etc/ssh/sshd_config
Your output will look something like:
Port 22
Use the Azure CLI

If you haven't already, install the latest Azure CLI and sign in to an Azure account using az login.
If you created and uploaded a custom Linux disk image, make sure the Microsoft Azure Linux Agent version 2.0.5
or later is installed. For VMs created using Gallery images, this access extension is already installed and configured
for you.
Reset SSH configuration
You can initially try resetting the SSH configuration to default values and rebooting the SSH server on the VM.
This does not change the user account name, password, or SSH keys. The following example uses az vm user
reset-ssh to reset the SSH configuration on the VM named myVM in myResourceGroup . Use your own values as
follows:
az vm user reset-ssh --resource-group myResourceGroup --name myVM

The following example uses az vm user update to reset the credentials for myUsername to the value specified in
myPassword , on the VM named myVM in myResourceGroup . Use your own values as follows:
az vm user update --resource-group myResourceGroup --name myVM \

--username myUsername --password myPassword
If using SSH key authentication, you can reset the SSH key for a given user. The following example uses az vm
access set-linux-user to update the SSH key stored in ~/.ssh/id_rsa.pub for the user named myUsername , on the
VM named myVM in myResourceGroup . Use your own values as follows:
az vm user update --resource-group myResourceGroup --name myVM \

--username myUsername --ssh-key-value ~/.ssh/id_rsa.pub
Use the VMAccess extension

The VM Access Extension for Linux reads in a json file that defines actions to carry out. These actions include
resetting SSHD, resetting an SSH key, or adding a user. You still use the Azure CLI to call the VMAccess extension,
but you can reuse the json files across multiple VMs if desired. This approach allows you to create a repository of
json files that can then be called for given scenarios.
Reset SSHD
Create a file named settings.json with the following content:
{
"reset_ssh":"True"
}
Using the Azure CLI, you then call the VMAccessForLinux extension to reset your SSHD connection by specifying
your json file. The following example uses az vm extension set to reset SSHD on the VM named myVM in
myResourceGroup . Use your own values as follows:
az vm extension set --resource-group philmea --vm-name Ubuntu \

--name VMAccessForLinux --publisher Microsoft.OSTCExtensions --version 1.2 --settings settings.json

If SSHD appears to function correctly, you can reset the credentials for a giver user. To reset the password for a
user, create a file named settings.json . The following example resets the credentials for myUsername to the value
specified in myPassword . Enter the following lines into your settings.json file, using your own values:
{
"username":"myUsername", "password":"myPassword"
}
Or to reset the SSH key for a user, first create a file named settings.json . The following example resets the
credentials for myUsername to the value specified in myPassword , on the VM named myVM in myResourceGroup .
Enter the following lines into your settings.json file, using your own values:
{
"username":"myUsername", "ssh_key":"mySSHKey"
}
After creating your json file, use the Azure CLI to call the VMAccessForLinux extension to reset your SSH user
credentials by specifying your json file. The following example resets credentials on the VM named myVM in
az vm extension set --resource-group philmea --vm-name Ubuntu \

--name VMAccessForLinux --publisher Microsoft.OSTCExtensions --version 1.2 --settings settings.json
Use the Azure classic CLI

If you haven't already, install the Azure classic CLI and connect to your Azure subscription. Make sure that you are
using Resource Manager mode as follows:
azure config mode arm
If you created and uploaded a custom Linux disk image, make sure the Microsoft Azure Linux Agent version 2.0.5
or later is installed. For VMs created using Gallery images, this access extension is already installed and configured
for you.
Reset SSH configuration
The SSHD configuration itself may be misconfigured or the service encountered an error. You can reset SSHD to
make sure the SSH configuration itself is valid. Resetting SSHD should be the first troubleshooting step you take.
The following example resets SSHD on a VM named myVM in the resource group named myResourceGroup . Use
your own VM and resource group names as follows:
azure vm reset-access --resource-group myResourceGroup --name myVM \

--reset-ssh

If SSHD appears to function correctly, you can reset the password for a giver user. The following example resets
the credentials for myUsername to the value specified in myPassword , on the VM named myVM in myResourceGroup .
Use your own values as follows:

--user-name myUsername --password myPassword
If using SSH key authentication, you can reset the SSH key for a given user. The following example updates the
SSH key stored in ~/.ssh/id_rsa.pub for the user named myUsername , on the VM named myVM in

--user-name myUsername --ssh-key-file ~/.ssh/id_rsa.pub
Restart a VM
If you have reset the SSH configuration and user credentials, or encountered an error in doing so, you can try
restarting the VM to address underlying compute issues.
Azure portal
To restart a VM using the Azure portal, select your VM and then select Restart as in the following example:
Azure CLI
The following example uses az vm restart to restart the VM named myVM in the resource group named
az vm restart --resource-group myResourceGroup --name myVM

Azure classic CLI
The following example restarts the VM named myVM in the resource group named myResourceGroup . Use your
own values as follows:
azure vm restart --resource-group myResourceGroup --name myVM
Redeploy a VM
You can redeploy a VM to another node within Azure, which may correct any underlying networking issues. For
information about redeploying a VM, see Redeploy virtual machine to new Azure node.
NOTE
After this operation finishes, ephemeral disk data is lost and dynamic IP addresses that are associated with the virtual
machine are updated.
Azure portal
To redeploy a VM using the Azure portal, select your VM and scroll down to the Support + Troubleshooting
section. Select Redeploy as in the following example:
Azure CLI
The following example use az vm redeploy to redeploy the VM named myVM in the resource group named
az vm redeploy --resource-group myResourceGroup --name myVM
Azure classic CLI

The following example redeploys the VM named myVM in the resource group named myResourceGroup . Use your
own values as follows:
azure vm redeploy --resource-group myResourceGroup --name myVM
VMs created by using the Classic deployment model

Try these steps to resolve the most common SSH connection failures for VMs that were created by using the
classic deployment model. After each step, try reconnecting to the VM.
Reset remote access from the Azure portal. On the Azure portal, select your VM and then select Reset
Remote....
Restart the VM. On the Azure portal, select your VM and select Restart.
Redeploy the VM to a new Azure node. For information about how to redeploy a VM, see Redeploy virtual
machine to new Azure node.
After this operation finishes, ephemeral disk data will be lost and dynamic IP addresses that are associated
with the virtual machine will be updated.
Follow the instructions in How to reset a password or SSH for Linux-based virtual machines to:
Reset the password or SSH key.
Create a sudo user account.
Reset the SSH configuration.
Check the VM's resource health for any platform issues.
Select your VM and scroll down Settings > Check Health.
If you are still unable to SSH to your VM after following the after steps, see more detailed troubleshooting
steps to review additional steps to resolve your issue.
For more information about troubleshooting application access, see Troubleshoot access to an application
running on an Azure virtual machine
For more information about troubleshooting virtual machines that were created by using the classic
deployment model, see How to reset a password or SSH for Linux-based virtual machines.
Detailed SSH troubleshooting steps for issues
connecting to a Linux VM in Azure
There are many possible reasons that the SSH client might not be able to reach the SSH service on the VM. If you
have followed through the more general SSH troubleshooting steps, you need to further troubleshoot the
connection issue. This article guides you through detailed troubleshooting steps to determine where the SSH
connection is failing and how to resolve it.
Take preliminary steps

The following diagram shows the components that are involved.
The following steps help you isolate the source of the failure and figure out solutions or workarounds.
1. Check the status of the VM in the portal. In the Azure portal, select Virtual machines > VM name.
The status pane for the VM should show Running. Scroll down to show recent activity for compute,
storage, and network resources.
2. Select Settings to examine endpoints, IP addresses, network security groups, and other settings.
The VM should have an endpoint defined for SSH traffic that you can view in Endpoints or Network
security group. Endpoints in VMs that were created by using Resource Manager are stored in a network
security group. Verify that the rules have been applied to the network security group and are referenced in
the subnet.
To verify network connectivity, check the configured endpoints and see if you can connect to the VM through
another protocol, such as HTTP or another service.
After these steps, try the SSH connection again.
Find the source of the issue
The SSH client on your computer might fail to connect to the SSH service on the Azure VM due to issues or
misconfigurations in the following areas:
SSH client computer
Organization edge device
Cloud service endpoint and access control list (ACL )
Network security groups
Linux-based Azure VM
Source 1: SSH client computer

To eliminate your computer as the source of the failure, verify that it can make SSH connections to another on-
premises, Linux-based computer.
If the connection fails, check for the following issues on your computer:
A local firewall setting that is blocking inbound or outbound SSH traffic (TCP 22)
Locally installed client proxy software that is preventing SSH connections
Locally installed network monitoring software that is preventing SSH connections
Other types of security software that either monitor traffic or allow/disallow specific types of traffic
If one of these conditions apply, temporarily disable the software and try an SSH connection to an on-premises
computer to find out the reason the connection is being blocked on your computer. Then work with your network
administrator to correct the software settings to allow SSH connections.
If you are using certificate authentication, verify that you have these permissions to the .ssh folder in your home
directory:
Chmod 700 ~/.ssh
Chmod 644 ~/.ssh/*.pub
Chmod 600 ~/.ssh/id_rsa (or any other files that have your private keys stored in them)
Chmod 644 ~/.ssh/known_hosts (contains hosts that you’ve connected to via SSH)
Source 2: Organization edge device
To eliminate your organization edge device as the source of the failure, verify that a computer directly connected to
the Internet can make SSH connections to your Azure VM. If you are accessing the VM over a site-to-site VPN or
an Azure ExpressRoute connection, skip to Source 4: Network security groups.
If you don't have a computer that is directly connected to the Internet, create a new Azure VM in its own resource
group or cloud service and use that new VM. For more information, see Create a virtual machine running Linux in
Azure. Delete the resource group or VM and cloud service when you're done with your testing.
If you can create an SSH connection with a computer that's directly connected to the Internet, check your
organization edge device for:
An internal firewall that's blocking SSH traffic with the Internet
A proxy server that's preventing SSH connections
Intrusion detection or network monitoring software running on devices in your edge network that's preventing
SSH connections
Work with your network administrator to correct the settings of your organization edge devices to allow SSH
traffic with the Internet.
Source 3: Cloud service endpoint and ACL

NOTE
This source applies only to VMs that were created by using the classic deployment model. For VMs that were created by
using Resource Manager, skip to source 4: Network security groups.
To eliminate the cloud service endpoint and ACL as the source of the failure, verify that another Azure VM in the
same virtual network can connect using SSH.
If you don't have another VM in the same virtual network, you can easily create one. For more information, see
Create a Linux VM on Azure using the CLI. Delete the extra VM when you are done with your testing.
If you can create an SSH connection with a VM in the same virtual network, check the following areas:
The endpoint configuration for SSH traffic on the target VM. The private TCP port of the endpoint
should match the TCP port on which the SSH service on the VM is listening. (The default port is 22). Verify the
SSH TCP port number in the Azure portal by selecting Virtual machines > VM name > Settings >
Endpoints.
The ACL for the SSH traffic endpoint on the target virtual machine. An ACL enables you to specify
allowed or denied incoming traffic from the Internet, based on its source IP address. Misconfigured ACLs can
prevent incoming SSH traffic to the endpoint. Check your ACLs to ensure that incoming traffic from the public
IP addresses of your proxy or other edge server is allowed. For more information, see About network access
control lists (ACLs).
To eliminate the endpoint as a source of the problem, remove the current endpoint, create another endpoint, and
specify the SSH name (TCP port 22 for the public and private port number). For more information, see Set up
endpoints on a virtual machine in Azure.
Source 4: Network security groups

Network security groups enable you to have more granular control of allowed inbound and outbound traffic. You
can create rules that span subnets and cloud services in an Azure virtual network. Check your network security
group rules to ensure that SSH traffic to and from the Internet is allowed. For more information, see About
network security groups.
You can also use IP Verify to validate the NSG configuration. For more information, see Azure network monitoring
overview.
Source 5: Linux-based Azure virtual machine

The last source of possible problems is the Azure virtual machine itself.
If you haven't done so already, follow the instructions to reset a password Linux-based virtual machines.
Try connecting from your computer again. If it still fails, the following are some of the possible issues:
The SSH service is not running on the target virtual machine.
The SSH service is not listening on TCP port 22. To test, install a telnet client on your local computer and run
"telnet cloudServiceName.cloudapp.net 22". This step determines if the virtual machine allows inbound and
outbound communication to the SSH endpoint.
The local firewall on the target virtual machine has rules that are preventing inbound or outbound SSH traffic.
Intrusion detection or network monitoring software that's running on the Azure virtual machine is preventing
SSH connections.
For more information about troubleshooting application access, see Troubleshoot access to an application running
on an Azure virtual machine
Understand common error messages when you
manage virtual machines in Azure
This article describes some of the most common error codes and messages you may encounter when you create or
manage virtual machines (VMs) in Azure.
NOTE
You can leave comments on this page for feedback or through Azure feedback with #azerrormessage tag.
Error Response Format

Azure VMs use the following JSON format for error response:
{
"status": "status code",
"error": {
"code":"Top level error code",
"message":"Top level error message",
"details":[
{
"code":"Inner evel error code",
"message":"Inner level error message"
}
]
}
}
An error response always includes a status code and an error object. Each error object always contains an error
code and a message. If the VM is created with a template, the error object also contains a details section that
contains an inner level of error codes and message. Normally, the most inner level of error message is the root
failure.
Common virtual machine management errors

This section lists the common error messages you may encounter when managing VMs:
ERROR CODE ERROR MESSAGE
AcquireDiskLeaseFailed Failed to acquire lease while creating disk '{0}' using blob with
URI {1}. Blob is already in use.
AllocationFailed Allocation failed. Please try reducing the VM size or number of

VMs, retry later, or try deploying to a different Availability Set
or different Azure location.
AllocationFailed The VM allocation failed due to an internal error. Please retry

later or try deploying to a different location.
ArtifactNotFound The VM extension with publisher '{0}' and type '{1}' could not
be found in location '{2}'.
ArtifactNotFound Extension with publisher '{0}', type '{1}', and type handler
version '{2}' could not be found in the extension repository.
ArtifactVersionNotFound No version found in the artifact repository that satisfies the

requested version '{0}'.
ArtifactVersionNotFound No version found in the artifact repository that satisfies the

requested version '{0}' for VM extension with publisher '{1}'
and type '{2}'.
AttachDiskWhileBeingDetached Cannot attach data disk '{0}' to VM '{1}' because the disk is
currently being detached. Please wait until the disk is
completely detached and then try again.
BadRequest Aligned' Availability Sets are not yet supported in this region.
BadRequest Addition of a VM with managed disks to non-managed

Availability Set or addition of a VM with blob based disks to
managed Availability Set is not supported. Please create an
Availability Set with 'managed' property set in order to add a
VM with managed disks to it.
BadRequest Managed Disks are not supported in this region.
BadRequest Multiple VMExtensions per handler not supported for OS type

'{0}'. VMExtension '{1}' with handler '{2}' already added or
specified in input.
BadRequest Operation '{0}' is not supported on Resource '{1}' with

managed disks.
CertificateImproperlyFormatted The secret's JSON representation retrieved from {0} has a data
field which is not a properly formatted PFX file, or the
password provided does not decode the PFX file correctly.
CertificateImproperlyFormatted The data retrieved from {0} is not deserializable into JSON.
Conflict Disk resizing is allowed only when creating a VM or when the

VM is deallocated.
ConflictingUserInput Disk '{0}' cannot be attached as the disk is already owned by

VM '{1}'.
ConflictingUserInput Source and destination resource groups are the same.
ConflictingUserInput Source and destination storage accounts for disk {0} are
different.
ContainerAlreadyOnLease There is already a lease on the storage container holding the

blob with URI {0}.
CrossSubscriptionMoveWithKeyVaultResources The Move resources request contains KeyVault resources

which are referenced by one or more {0}s in the request. This
is not supported currently in Cross subscription Move. Please
check the error details for the KeyVault resource Ids.
DiagnosticsOperationInternalError An internal error occurred while processing diagnostics profile

of VM {0}.
DiskBlobAlreadyInUseByAnotherDisk Blob {0} is already in use by another disk belonging to VM

'{1}'. You can examine the blob metadata for the disk reference
information.
DiskBlobNotFound Unable to find VHD blob with URI {0} for disk '{1}'.
DiskBlobNotFound Unable to find VHD blob with URI {0}.
DiskEncryptionKeySecretMissingTags {0} secret doesn't have the {1} tags. Please update the secret
version, add the required tags and retry.
DiskEncryptionKeySecretUnwrapFailed Unwrap of secret {0} value using key {1} failed.
DiskImageNotReady Disk image {0} is in {1} state. Please retry when image is ready.
DiskPreparationError One or more errors occurred while preparing VM disks. See

disk instance view for details.
DiskProcessingError Disk processing halted as the VM has other disks in failed

disks.
ImageBlobNotFound Unable to find VHD blob with URI {0} for disk '{1}'.
ImageBlobNotFound Unable to find VHD blob with URI {0}.
IncorrectDiskBlobType Disk blobs can only be of type page blob. Blob {0} for disk '{1}'
is of type block blob.
IncorrectDiskBlobType Disk blobs can only be of type page blob. Blob {0} is of type
'{1}'.
IncorrectImageBlobType Disk blobs can only be of type page blob. Blob {0} for disk '{1}'
is of type block blob.
IncorrectImageBlobType Disk blobs can only be of type page blob. Blob {0} is of type
'{1}'.
InternalOperationError Could not resolve storage account {0}. Please ensure it was
created through the Storage Resource Provider in the same
location as the compute resource.
InternalOperationError {0} goal seeking tasks failed.
InternalOperationError Error occurred in validating the network profile of VM '{0}'.

InvalidAccountType The AccountType {0} is invalid.
InvalidParameter The value of parameter {0} is invalid.
InvalidParameter The Admin password specified is not allowed.
InvalidParameter "The supplied password must be between {0}-{1} characters

long and must satisfy at least {2} of password complexity
requirements from the following:
1. Contains an uppercase character
2. Contains a lowercase character
3. Contains a numeric digit
4. Contains a special character.
InvalidParameter The Admin Username specified is not allowed.
InvalidParameter Cannot attach an existing OS disk if the VM is created from a

platform or user image.
InvalidParameter Container name {0} is invalid. Container names must be 3-63

characters in length and may contain only lower-case
alphanumeric characters and hyphen. Hyphen must be
preceded and followed by an alphanumeric character.
InvalidParameter Container name {0} in URL {1} is invalid. Container names

must be 3-63 characters in length and may contain only
lower-case alphanumeric characters and hyphen. Hyphen
must be preceded and followed by an alphanumeric character.
InvalidParameter The blob name in URL {0} contains a slash. This is presently
not supported for disks.
InvalidParameter The URI {0} does not look to be correct blob URI.
InvalidParameter A disk named '{0}' already uses the same LUN: {1}.
InvalidParameter A disk named '{0}' already exists.
InvalidParameter Cannot specify user image overrides for a disk already defined
in the specified image reference.
InvalidParameter A disk named '{0}' already uses the same VHD URL {1}.
InvalidParameter The specified fault domain count {0} must fall in the range {1}
to {2}.
InvalidParameter The license type {0} is invalid. Valid license types are:
Windows_Client or Windows_Server, case sensitive.
InvalidParameter Linux host name cannot exceed {0} characters in length or

contain the following characters: {1}.
InvalidParameter Destination path for Ssh public keys is currently limited to its
default value {0} due to a known issue in Linux provisioning
agent.
InvalidParameter A disk at LUN {0} already exists.
InvalidParameter Subscription {0} of the request must match the subscription

{1} contained in the managed disk id.
InvalidParameter Custom data in OSProfile must be in Base64 encoding and

with a maximum length of {0} characters.
InvalidParameter Blob name in URL {0} must end with '{1}' extension.
InvalidParameter {0}' is not a valid captured VHD blob name prefix. A valid prefix
matches regex '{1}'.
InvalidParameter Certificates cannot be added to your VM if the VM agent is

not provisioned.
InvalidParameter A disk at LUN {0} already exists.
InvalidParameter Unable to create the VM because the requested size {0} is not
available in the cluster where the availability set is currently
allocated. The available sizes are: {1}. Read more on VM
resizing strategy at https://aka.ms/azure-resizevm.
InvalidParameter The requested VM size {0} is not available in the current

region. The sizes available in the current region are: {1}. Find
out more on the available VM sizes in each region at
https://aka.ms/azure-regions.
InvalidParameter The requested VM size {0} is not available in the current

region. Find out more on the available VM sizes in each region
at https://aka.ms/azure-regions.
InvalidParameter Windows admin user name cannot be more than {0}

characters long, end with a period(.), or contain the following
characters: {1}.
InvalidParameter Windows computer name cannot be more than {0} characters

long, be entirely numeric, or contain the following characters:
{1}.
MissingMoveDependentResources The move resources request does not contain all the
dependent resources. Please check error details for missing
resource ids.
MoveResourcesHaveInvalidState The Move Resources request contains VMs which are

associated with invalid storage accounts. Please check details
for these resource ids and referenced storage account names.
MoveResourcesHavePendingOperations The move resources request contains resources for which an

operation is pending. Please check details for these resource
ids. Retry your operation once the pending operations
complete.
MoveResourcesNotFound The move resources request contains resources that cannot be

found. Please check details for these resource ids.
NetworkingInternalOperationError Unknown network allocation error.
NetworkingInternalOperationError Unknown network allocation error
NetworkingInternalOperationError An internal error occurred in processing network profile of the

VM.
NotFound The Availability Set {0} cannot be found.
NotFound Source Virtual Machine '{0}' specified in the request does not
exist in this Azure location.
NotFound Tenant with id {0} not found.
NotFound The Image {0} cannot be found.
NotSupported The license type is {0}, but the image blob {1} is not from on-
premises.
OperationNotAllowed Availability Set {0} cannot be deleted. Before deleting an

Availability Set please ensure that it does not contain any VM.
OperationNotAllowed Changing availability set SKU from 'Aligned' to 'Classic' is not

allowed.
OperationNotAllowed Cannot modify extensions in the VM when the VM is not

running.
OperationNotAllowed The Capture action is only supported on a Virtual Machine

with blob based disks. Please use the 'Image' resource APIs to
create an Image from a managed Virtual Machine.
OperationNotAllowed The resource {0} cannot be created from Image {1} until Image
has been successfully created.
OperationNotAllowed Updates to encryptionSettings is not allowed when VM is

allocated, Please retry after VM is deallocated
OperationNotAllowed Addition of a managed disk to a VM with blob based disks is

not supported.
OperationNotAllowed The maximum number of data disks allowed to be attached to

a VM of this size is {0}.
OperationNotAllowed Addition of a blob based disk to VM with managed disks is

not supported.
OperationNotAllowed Operation '{0}' is not allowed on Image '{1}' since the Image is
marked for deletion. You can only retry the Delete operation
(or wait for an ongoing one to complete).
OperationNotAllowed Operation '{0}' is not allowed on VM '{1}' since the VM is

generalized.
OperationNotAllowed Operation '{0}' is not allowed as Restore point collection '{1}' is

marked for deletion.
OperationNotAllowed Operation '{0}' is not allowed on VM extension '{1}' since it is

OperationNotAllowed Operation '{0}' is not allowed since the Virtual Machines '{1}'
are being provisioned using the Image '{2}'.
OperationNotAllowed Operation '{0}' is not allowed since the Virtual Machine

ScaleSet '{1}' is currently using the Image '{2}'.


either deallocated or marked to be deallocated.

running. Please power off explicitly in case you shut down the
VM from inside the guest operating system.
OperationNotAllowed Operation '{0}' is not allowed on VM '{1}' since the VM is not

deallocated.
OperationNotAllowed Operation '{0}' is not allowed on VM '{1}' since VM has

extension '{2}' in failed state.
OperationNotAllowed Operation '{0}' is not allowed on VM '{1}' since another

operation is in progress.
OperationNotAllowed The operation '{0}' requires the Virtual Machine '{1}' to be

Generalized.
OperationNotAllowed The operation requires the VM to be running (or set to run).
OperationNotAllowed Disk with size {0}GB, which is smaller than the size {1}GB of
corresponding disk in Image, is not allowed.
OperationNotAllowed VM Scale Set extensions of handler '{0}' can be added only at

the time of VM Scale Set creation.
OperationNotAllowed VM Scale Set extensions of handler '{0}' can be deleted only at

the time of VM Scale Set deletion.
OperationNotAllowed VM '{0}' is already using managed disks.
OperationNotAllowed VM '{0}' belongs to 'Classic' availability set '{1}'. Please update

the availability set to use 'Aligned' SKU and then retry the
Conversion.
OperationNotAllowed VM created from Image cannot have blob based disks. All
disks have to be managed disks.
OperationNotAllowed Capture operation cannot be completed because the VM is

not generalized.
OperationNotAllowed Management operations on VM '{0}' are disallowed because

VM disks are being converted to managed disks.
OperationNotAllowed An ongoing operation is changing power state of Virtual

Machine {0} to {1}. Please perform operation {2} after some
time.
OperationNotAllowed Unable to add or update the VM. The requested VM size {0}
may not be available in the existing allocation unit. Read more
on VM resizing strategy at https://aka.ms/azure-resizevm.
OperationNotAllowed Unable to resize the VM because the requested size {0} is not
available in the cluster where the availability set is currently
allocated. The available sizes are: {1}. Read more on VM
resizing strategy at https://aka.ms/azure-resizevm.
OperationNotAllowed Unable to resize the VM because the requested size {0} is not
available in the cluster where the VM is currently allocated. To
resize your VM to {1} please deallocate (this is Stop operation
in the Azure portal) and try the resize operation again. Read
more on VM resizing strategy at https://aka.ms/azure-
resizevm.
OSProvisioningClientError OS Provisioning failed for VM '{0}' because the guest OS is

currently being provisioned.
OSProvisioningClientError OS provisioning for VM '{0}' failed. Error details: {1} Make sure
the image has been properly prepared (generalized).
Instructions for Windows:
https://azure.microsoft.com/documentation/articles/virt
ual-machines-windows-upload-image/
OSProvisioningClientError SSH host key generation failed. Error details: {0}. To resolve this
issue verify if Linux agent is set up properly.
You can check the instructions at :
https://docs.microsoft.com/azure/virtual-
machines/extensions/agent-linux/
OSProvisioningClientError Username specified for the VM is invalid for this Linux

distribution. Error details: {0}.
OSProvisioningInternalError OS Provisioning failed for VM '{0}' due to an internal error.
OSProvisioningTimedOut OS Provisioning for VM '{0}' did not finish in the allotted time.
The VM may still finish provisioning successfully. Please check
provisioning state later.
The VM may still finish provisioning successfully. Please check
provisioning state later. Also, make sure the image has been
properly prepared (generalized).
Instructions for Linux:
ual-machines-linux-capture-image/
However, the VM guest agent was detected running. This
suggests the guest OS has not been properly prepared to be
used as a VM image (with CreateOption=FromImage). To
resolve this issue, either use the VHD as is with
CreateOption=Attach or prepare it properly for use as an
image:
Instructions for Linux:
ual-machines-linux-capture-image/
OverConstrainedAllocationRequest The required VM size is not currently available in the selected

location.
ResourceUpdateBlockedOnPlatformUpdate Resource cannot be updated at this time due to ongoing

platform update. Please try again later.
StorageAccountLimitation Storage account '{0}' does not support page blobs which are
required to create disks.
StorageAccountLimitation Storage account '{0}' has exceeded its allocated quota.
StorageAccountLocationMismatch Could not resolve storage account {0}. Please ensure it was
created through the Storage Resource Provider in the same
location as the compute resource.
StorageAccountNotFound Storage account {0} not found. Ensure storage account is not
deleted and belongs to the same Azure location as the VM.
StorageAccountNotRecognized Please use a storage account managed by Storage Resource

Provider. Use of {0} is not supported.
StorageAccountOperationInternalError Internal error occurred while accessing storage account {0}.
StorageAccountSubscriptionMismatch Storage account {0} doesn't belong to subscription {1}.
StorageAccountTooBusy Storage account '{0}' is too busy currently. Consider using

another account.
StorageAccountTypeNotSupported Disk {0} uses {1} which is a Blob storage account. Please retry
with General purpose storage account.
StorageAccountTypeNotSupported Storage account {0} is of {1} type. Boot Diagnostics supports

{2} storage account types.
This error occurs if you use the premium storage
account for Boot diagnostics. For more information,
see How to use boot diagnostics.
SubscriptionNotAuthorizedForImage The subscription is not authorized.
TargetDiskBlobAlreadyExists Blob {0} already exists. Please provide a different blob URI to
create a new blank data disk '{1}'.
TargetDiskBlobAlreadyExists Capture operation cannot continue because target image blob

{0} already exists and the flag to overwrite VHD blobs is not
set. Either delete the blob or set the flag to overwrite VHD
blobs and retry.
TargetDiskBlobAlreadyExists Capture operation cannot continue because target image blob

{0} has an active lease on it.
TargetDiskBlobAlreadyExists Blob {0} already exists. Please provide a different blob URI as
target for disk '{1}'.
TooManyVMRedeploymentRequests Too many redeployment requests have been received for VM

'{0}' or the VMs in the same availabilityset with this VM. Please
retry later.
VHDSizeInvalid The specified disk size value of {0} for disk '{1}' with blob {2} is
invalid. Disk size must be between {3} and {4}.
VMAgentStatusCommunicationError VM '{0}' has not reported status for VM agent or extensions.

Please verify the VM has a running VM agent, and can
establish outbound connections to Azure storage.
VMArtifactRepositoryInternalError An error occurred while communicating with the artifact

repository to retrieve VM artifact details.
VMArtifactRepositoryInternalError An internal error occurred while retrieving the VM artifact data

from the artifact repository.
VMExtensionHandlerNonTransientError Handler '{0}' has reported failure for VM Extension '{1}' with
terminal error code '{2}' and error message: '{3}'
VMExtensionManagementInternalError Internal error occurred while processing VM extension '{0}'.

VMExtensionManagementInternalError Multiple errors occurred while preparing the VM extensions.

See VM extension instance view for details.
VMExtensionProvisioningError VM has reported a failure when processing extension '{0}'.

Error message: "{1}".
VMExtensionProvisioningError Multiple VM extensions failed to be provisioned on the VM.

Please see the VM extension instance view for details.
VMExtensionProvisioningTimeout Provisioning of VM extension '{0}' has timed out. Extension

installation may be taking too long, or extension status could
not be obtained.
VMMarketplaceInvalidInput Creating a virtual machine from a non Marketplace image

does not need Plan information, please remove the Plan
information in the request. OS disk name is {0}.
VMMarketplaceInvalidInput The purchase information does not match. Unable to deploy

from the Marketplace image. OS disk name is {0}.
VMMarketplaceInvalidInput Creating a virtual machine from Marketplace image requires

Plan information in the request. OS disk name is {0}.
VMNotFound The VM '{0}' cannot be found.
VMRedeploymentFailed VM '{0}' redeployment failed due to an internal error. Please

retry later.
VMRedeploymentTimedOut Redeployment of VM '{0}' didn't finish in the allotted time. It

might finish successfully in sometime. Else, you can retry the
request.
VMStartTimedOut VM '{0}' did not start in the allotted time. The VM may still
start successfully. Please check the power state later.
Next steps
If you need more help, you can contact the Azure experts on the MSDN Azure and Stack Overflow forums.
Alternatively, you can file an Azure support incident. Go to the Azure support site and select Get Support.
Performance diagnostics for Azure virtual machines
The performance diagnostics tool helps you troubleshoot performance issues that can affect a Windows virtual
machine (VM ). Supported troubleshooting scenarios include quick checks on known issues and best practices, and
complex problems that involve slow VM performance or high usage of CPU, disk space, or memory.
You can run performance diagnostics directly from the Azure portal, where you can also review insights and a
report on various logs, rich configuration, and diagnostics data. We recommend that you run performance
diagnostics and review the insights and diagnostics data before you contact Microsoft Support.
NOTE
Performance diagnostics is currently supported on Windows VMs that have .NET SDK version 4.5 or a later version installed.
For the steps to run performance diagnostics on classic VMs, see Azure Performance Diagnostics VM extension.
Supported Operating Systems

Windows 10, Windows 8, Windows 8 Enterprise, Windows 8 Pro, Windows 8.1, Windows Server 2016, Windows
Server 2012, Windows Server 2012 Datacenter, Windows Server 2012 R2, Windows Server 2012 R2 Datacenter,
Windows Server 2012 R2 Standard, Windows Server 2012 Standard, Windows Server 2008 R2, Windows Server
2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Foundation, Windows
Server 2008 R2 SP1, Windows Server 2008 R2 Standard.
Install and run performance diagnostics on your VM

Performance diagnostics installs a VM extension that runs a diagnostics tool that is named PerfInsights. To install
and run performance diagnostics, follow these steps:
1. In the left column of commands, select Virtual machines.
2. From the list of VM names, select the VM that you want to run diagnostics on.
3. In the right column of commands, select Performance diagnostics.
NOTE
In this screenshot, the blade of VM names is hidden.
4. Select a storage account (optional)

If you want to use a single storage account to store the performance diagnostics results for multiple VMs,
you can select a storage account by clicking the Settings button in the toolbar. Click the OK button once
you select the storage account.
If you do not specify a storage account, a new storage account will be created by default.
5. Select the Install performance diagnostics button.
6. Select the Run diagnostics check box if you want to run a diagnostic after the installation is completed. If
you make this selection, you will be able to choose the performance analysis scenario and related options.
Select an analysis scenario to run

The following analysis scenarios are available from the Azure portal. Select an analysis, depending on the
performance issue that you are having. Select the duration and trace options as necessary for the analysis.
Quick performance analysis
Checks for known issues, analyzes best practices, and collects diagnostics data. This analysis takes several
minutes to run. Learn more
Performance analysis
Includes all checks in the quick performance analysis and monitors high resource consumption. Use this
version to troubleshoot general performance issues, such as high CPU, memory, and disk usage. This
analysis takes 30 seconds to 15 minutes, depending on the selected duration. Learn more
Advanced performance analysis
Includes all checks in the performance analysis, and collects one or more of the traces, as listed in the
following sections. Use this scenario to troubleshoot complex issues that require additional traces. Running
this scenario for longer periods will increase the overall size of diagnostics output, depending on the size of
the VM and the trace options that are selected. This analysis takes 30 seconds to 15 minutes to run,
depending on the selected duration. Learn more
Azure Files analysis
Includes all checks in the performance analysis, and captures a network trace and SMB counters. Use this
scenario to troubleshoot the performance of Azure files. This analysis takes 30 seconds to 15 minutes to
run, depending on the selected duration. Learn more
Provide symptoms (optional)

Select any preselected symptoms from the list, or add new symptoms. This helps us improve the analysis in the
future.
Provide support request number, if available (optional)
If you are working with a Microsoft support engineer on an existing support ticket, provide the support ticket
number.
Review the privacy policy and legal terms, and select the check box to acknowledge (required)
To run the diagnostics, you must agree to the legal terms and accept privacy policy.
Select OK to run the diagnostics
A notification is displayed as performance diagnostics starts to install. After the installation is completed, you see a
notification that indicates that the installation is successful. The selected analysis is then run for the specified
duration. This would be a good time to reproduce the performance issue so that the diagnostics data can be
captured at the correct time.
After the analysis is complete, the following items are uploaded to Azure tables and a binary large object (BLOB )
container in the specified storage account:
All the insights and related information about the run
An output compressed (.zip) file (named PerformanceDiagnostics_yyyy-MM -dd_hh-mm -ss-fff.zip) that
contains log files
An HTML report
After the upload, a new diagnostics report is listed in the Azure portal.
How to change performance diagnostics settings

Use the Settings toolbar button to change the storage account where the diagnostics insights and output can be
stored. You can use the same storage account for multiple VMs that use performance diagnostics. When you
change the storage account, the old reports and insights are not deleted. However, they will no longer be displayed
in the list of diagnostics reports.
Review insights and performance diagnostics report

Each diagnostic run contains a list of insights and recommendations, affected resources, log files, and other rich
diagnostics information that is collected, plus a report for offline viewing. For a complete list of all the collected
diagnostics data, see What kind of information is collected by PerfInsights?
Select a performance diagnostics report
You can use the diagnostics report list to find all the diagnostics reports that were run. The list includes details
about the analysis that was used, insights that were found, and their impact levels. Select a row to view more
details.
Review a performance diagnostics report
Each performance diagnostics report may contain several insights and indicate an impact level of High, Medium,
or Low. Each insight also contains recommendations to help lessen the concern. Insights are grouped for easy
filtering.
Impact levels represent the potential for performance issues, based on factors such as misconfiguration, known
problems, or issues that are reported by other users. You might not yet be experiencing one or more of the listed
issues. For example, you may have SQL log files and database files on the same data disk. This condition has a
high potential for bottlenecks and other performance issues if the database usage is high, whereas you might not
notice an issue if the usage is low.
Reviewing performance diagnostics insights and recommendations

You can select an insight to view more details about the affected resources, suggested mitigations, and reference
links.
Download and review the full performance diagnostics report
You can use the Download report button to download an HTML report that contains additional rich diagnostics
information, such as storage and network configuration, performance counters, traces, list of processes, and logs.
The content depends on the selected analysis. For advanced troubleshooting, the report may contain additional
information and interactive charts that are related to high CPU usage, high disk usage, and processes that
consume excessive memory. For more information about the performance diagnostics report, see Review
diagnostics report.
Manage performance diagnostics reports

You can delete one or more performance diagnostics reports by using the Delete report button.
How to uninstall performance diagnostics

You can uninstall performance diagnostics from a VM. This action removes the VM extension but does not affect
any diagnostics data that is in the storage account.
Frequently asked questions

Where is the diagnostics data from my VM stored?
All performance diagnostics insights and reports are stored in your own storage account. Insights are stored inside
Azure tables. The reports compressed file is stored in a binary large object (BLOB ) container that is named
azdiagextnresults.
You can view the storage account information by using the Settings button on the toolbar.
How do I share this data with Microsoft Customer Support?
There are multiple ways to share the diagnostics report with Microsoft.
Option 1: Automatically share the latest report
When you open a support ticket with Microsoft, it is important to share the performance diagnostics report. If you
opted to share this information with Microsoft while you run the diagnostics (by selecting the “I agree to share
diagnostics information with Microsoft” check box), Microsoft will be able to access the report from your
storage account using a SAS link to the output zip file for up to 30 days from the run date. Only the latest report is
available to the support engineer.
Option 2: Generate a Shared Access Signature for the diagnostics report compressed file
You may share a link to the reports compressed file by using Shared Access Signatures. To do this, follow these
steps:
1. In the Azure portal, browse to the storage account in which the diagnostics data is stored.
2. Select Blobs under the Blob service section.
3. Select the azdiagextnresults container.
4. Select the Performance diagnostics output compressed file that you want to share.
5. On the Generate SAS tab, select the criteria for sharing.
6. Click Generate blob SAS token and URL.
7. Copy the Blob SAS URL, and share it with the support engineer.
Option 3: Download the report from the storage account
You can also locate the performance diagnostics report compressed file by using steps 1–4 in Option 2. Select to
download the file, and then share it through email or ask the support engineer for instructions to upload the file.
How do I capture the diagnostics data at the correct time?
Each performance diagnostics run has two stages:
1. Install or update the performance diagnostics VM extension.
2. Run the diagnostics for the specified duration.
Currently there is no easy way to know exactly when the VM extension installation is complete. Generally it takes
about 45 seconds to 1 minute to install the VM extension. After the VM extension is installed, you can run your
repro steps to have the performance diagnostics capture the correct set of data for troubleshooting.
Next steps
After you review the performance diagnostics insights and report, if you still cannot determine the cause of the
issue and need more help, you can open a support ticket with Microsoft Customer Support.
Overflow forums. Alternatively, you can file an Azure support incident. Go to the Azure support site, and select Get
support. For information about using Azure support, read the Microsoft Azure support FAQ.
PerfInsights is a self-help diagnostics tool that collects and analyzes the diagnostic data, and provides a report to
help troubleshoot Windows virtual machine performance problems in Azure. PerfInsights can be run on virtual
machines as a standalone tool, directly from the portal by using Performance Diagnostics for Azure virtual
machines, or by installing Azure Performance Diagnostics VM Extension.
If you are experiencing performance problems with virtual machines, before contacting support, run this tool.
Supported troubleshooting scenarios

PerfInsights can collect and analyze several kinds of information. The following sections cover common scenarios.
Quick performance analysis
This scenario collects the disk configuration and other important information, including:
Event logs
Network status for all incoming and outgoing connections
Network and firewall configuration settings
Task list for all applications that are currently running on the system
Microsoft SQL Server database configuration settings (if the VM is identified as a server that is running SQL
Server)
Storage reliability counters
Important Windows hotfixes
Installed filter drivers
This is a passive collection of information that shouldn't affect the system.
NOTE
This scenario is automatically included in each of the following scenarios:
Benchmarking
This scenario runs the Diskspd benchmark test (IOPS and MBPS ) for all drives that are attached to the VM.
NOTE
This scenario can affect the system, and shouldn’t be run on a live production system. If necessary, run this scenario in a
dedicated maintenance window to avoid any problems. An increased workload that is caused by a trace or benchmark test
can adversely affect the performance of your VM.
Performance analysis
This scenario runs a performance counter trace by using the counters that are specified in the
RuleEngineConfig.json file. If the VM is identified as a server that is running SQL Server, a performance counter
trace is run. It does so by using the counters that are found in the RuleEngineConfig.json file. This scenario also
includes performance diagnostics data.
Azure Files analysis
This scenario runs a special performance counter capture together with a network trace. The capture includes all the
Server Message Block (SMB ) client shares counters. The following are some key SMB client share performance
counters that are part of the capture:
TYPE SMB CLIENT SHARES COUNTER
IOPS Data Requests/sec
Read Requests/sec
Write Requests/sec
Latency Avg. sec/Data Request
Avg. sec/Read
Avg. sec/Write
IO Size Avg. Bytes/Data Request
Avg. Bytes/Read
Avg. Bytes/Write
Throughput Data Bytes/sec
Read Bytes/sec
Write Bytes/sec
Queue Length Avg. Read Queue Length
Avg. Write Queue Length
Avg. Data Queue Length
Advanced performance analysis

When you run an advanced performance analysis, you select traces to run in parallel. If you want, you can run them
all (Performance Counter, Xperf, Network, and StorPort).
NOTE
This scenario can affect the system, and shouldn’t be run on a live production system. If necessary, run this scenario in a
dedicated maintenance window to avoid any problems. An increased workload that is caused by a trace or benchmark test
can adversely affect the performance of your VM.
What kind of information is collected by PerfInsights?

Information about Windows VM, disks or storage pools configuration, performance counters, logs, and various
traces are collected. It depends on the performance scenario you are using. The following table provides details:
DATA PERFORMANCE
COLLECTED SCENARIOS
Quick Benchmarking Performance Azure Files Advanced

performance analysis analysis performance
analysis analysis
Information Yes Yes Yes Yes Yes

from event
logs
System Yes Yes Yes Yes Yes

information
Volume map Yes Yes Yes Yes Yes
Disk map Yes Yes Yes Yes Yes
Running tasks Yes Yes Yes Yes Yes
Storage Yes Yes Yes Yes Yes

reliability
counters
Storage Yes Yes Yes Yes Yes

information
Fsutil output Yes Yes Yes Yes Yes
Filter driver Yes Yes Yes Yes Yes

info
Netstat Yes Yes Yes Yes Yes

output
Network Yes Yes Yes Yes Yes

configuration
Firewall Yes Yes Yes Yes Yes

configuration
SQL Server Yes Yes Yes Yes Yes

configuration
Performance Yes Yes Yes Yes Yes

diagnostics
traces *
Performance Yes Yes

counter trace
**
SMB counter Yes

trace **
DATA PERFORMANCE
COLLECTED SCENARIOS
SQL Server Yes Yes

counter trace
**
Xperf trace Yes
StorPort trace Yes
Network trace Yes Yes
Diskspd Yes
benchmark
trace ***
Performance diagnostics trace (*)

Runs a rule-based engine in the background to collect data and diagnose ongoing performance issues. The
following rules are currently supported:
HighCpuUsage rule: Detects high CPU usage periods, and shows the top CPU usage consumers during those
periods.
HighDiskUsage rule: Detects high disk usage periods on physical disks, and shows the top disk usage
consumers during those periods.
HighResolutionDiskMetric rule: Shows IOPS, throughput, and I/O latency metrics per 50 milliseconds for each
physical disk. It helps to quickly identify disk throttling periods.
HighMemoryUsage rule: Detects high memory usage periods, and shows the top memory usage consumers
during those periods.
NOTE
Currently, Windows versions that include the .NET Framework 4.5 or later versions are supported.
Performance counter trace (**)

Collects the following performance counters:
\Process, \Processor, \Memory, \Thread, \PhysicalDisk, and \LogicalDisk
\Cache\Dirty Pages, \Cache\Lazy Write Flushes/sec, \Server\Pool Nonpaged, Failures, and \Server\Pool Paged
Failures
Selected counters under \Network Interface, \IPv4\Datagrams, \IPv6\Datagrams, \TCPv4\Segments,
\TCPv6\Segments, \Network Adapter, \WFPv4\Packets, \WFPv6\Packets, \UDPv4\Datagrams,
\UDPv6\Datagrams, \TCPv4\Connection, \TCPv6\Connection, \Network QoS Policy\Packets, \Per Processor
Network Interface Card Activity, and \Microsoft Winsock BSP
For SQL Server instances
\SQL Server:Buffer Manager, \SQLServer:Resource Pool Stats, and \SQLServer:SQL Statistics\
\SQLServer:Locks, \SQLServer:General, Statistics
\SQLServer:Access Methods
For Azure Files
\SMB Client Shares
Diskspd benchmark trace (***)
Diskspd I/O workload tests (OS Disk [write] and pool drives [read/write])
Run the PerfInsights tool on your VM

What do I have to know before I run the tool?
Tool requirements
This tool must be run on the VM that has the performance issue.
The following operating systems are supported: Windows Server 2008 R2, Windows Server 2012, Windows
Server 2012 R2, and Windows Server 2016; Windows 8.1 and Windows 10.
Possible problems when you run the tool on production VMs
For the benchmarking scenario or the "Advanced performance analysis" scenario that is configured to use
Xperf or Diskspd, the tool might adversely affect the performance of the VM. These scenarios should not be
run in a live production environment.
For the benchmarking scenario or the "Advanced performance analysis" scenario that is configured to use
Diskspd, ensure that no other background activity interferes with the I/O workload.
By default, the tool uses the temporary storage drive to collect data. If tracing stays enabled for a longer
time, the amount of data that is collected might be relevant. This can reduce the availability of space on the
temporary disk, and can therefore affect any application that relies on this drive.
How do I run PerfInsights?
You can run PerfInsights on a virtual machine by installing Azure Performance Diagnostics VM Extension. You can
also run it as a standalone tool.
Install and run PerfInsights from the Azure portal
For more information about this option, see Install Azure Performance Diagnostics VM Extension.
Run PerfInsights in standalone mode
To run the PerfInsights tool, follow these steps:
1. Download PerfInsights.zip.
2. Unblock the PerfInsights.zip file. To do this, right-click the PerfInsights.zip file, and select Properties. In the
General tab, select Unblock, and then select OK. This ensures that the tool runs without any additional
security prompts.
3. Expand the compressed PerfInsights.zip file into your temporary drive (by default, this is usually the D drive).
4. Open Windows command prompt as an administrator, and then run PerfInsights.exe to view the available
commandline parameters.
cd <the path of PerfInsights folder>
PerfInsights
The basic syntax for running PerfInsights scenarios is:
PerfInsights /run <ScenarioName> [AdditionalOptions]
You can use the below example to run performance analysis scenario for 5 mins:
PerfInsights /run vmslow /d 300 /AcceptDisclaimerAndShareDiagnostics
You can use the following example to run the advanced scenario with Xperf and Performance counter traces
for 5 mins:
PerfInsights /run advanced xp /d 300 /AcceptDisclaimerAndShareDiagnostics
You can use the below example to run performance analysis scenario for 5 mins and upload the result zip file
to the storage account:
PerfInsights /run vmslow /d 300 /AcceptDisclaimerAndShareDiagnostics /sa <StorageAccountName> /sk

<StorageAccountKey>
You can look up all the available scenarios and options by using the /list command:
PerfInsights /list
NOTE
Before running a scenario, PerfInsights prompts the user to agree to share diagnostic information and to agree to the
EULA. Use /AcceptDisclaimerAndShareDiagnostics option to skip these prompts.
If you have an active support ticket with Microsoft and running PerfInsights per the request of the support engineer
you are working with, make sure to provide the support ticket number using the /sr option.
By default, PerfInsights will try updating itself to the latest version if available. Use /SkipAutoUpdate or /sau
parameter to skip auto update.
If the duration switch /d is not specified, PerfInsights will prompt you to repro the issue while running vmslow,
azurefiles and advanced scenarios.
When the traces or operations are completed, a new file appears in the same folder as PerfInsights. The name of
the file is PerformanceDiagnostics_yyyy-MM -dd_hh-mm -ss-fff.zip. You can send this file to the support agent
for analysis or open the report inside the zip file to review findings and recommendations.
Review the diagnostics report

Within the PerformanceDiagnostics_yyyy-MM -dd_hh-mm -ss-fff.zip file, you can find an HTML report that
details the findings of PerfInsights. To review the report, expand the PerformanceDiagnostics_yyyy-MM -dd_hh-
mm -ss-fff.zip file, and then open the PerfInsights Report.html file.
Select the Findings tab.
NOTE
Findings categorized as high are known issues that might cause performance issues. Findings categorized as medium
represent non-optimal configurations that do not necessarily cause performance issues. Findings categorized as low are
informative statements only.
Review the recommendations and links for all high and medium findings. Learn about how they can affect
performance, and also about best practices for performance-optimized configurations.
Storage tab
The Findings section displays various findings and recommendations related to storage.
The Disk Map and Volume Map sections describe how logical volumes and physical disks are related to each
other.
In the physical disk perspective (Disk Map), the table shows all logical volumes that are running on the disk. In the
following example, PhysicalDrive2 runs two logical volumes created on multiple partitions (J and H):
In the volume perspective (Volume Map), the tables show all the physical disks under each logical volume. Notice
that for RAID/Dynamic disks, you might run a logical volume on multiple physical disks. In the following example,
C:\mount is a mount point configured as SpannedDisk on physical disks 2 and 3:
SQL tab
If the target VM hosts any SQL Server instances, you see an additional tab in the report, named SQL:
This section contains a Findings tab, and additional tabs for each of the SQL Server instances hosted on the VM.
The Findings tab contains a list of all the SQL related performance issues found, along with the recommendations.
In the following example, PhysicalDrive0 (running the C drive) is displayed. This is because both the modeldev
and modellog files are located on the C drive, and they are of different types (such as data file and transaction log,
respectively).
The tabs for specific instances of SQL Server contain a general section that displays basic information about the
selected instance. The tabs also contain additional sections for advanced information, including settings,
configurations, and user options.
Diagnostic tab
The Diagnostic tab contains information about top CPU, disk, and memory consumers on the computer for the
duration of the running of PerfInsights. You can also find information about critical patches that the system might
be missing, the task list, and important system events.
References to the external tools used

Diskspd
Diskspd is a storage load generator and performance test tool from Microsoft. For more information, see Diskspd.
Xperf
Xperf is a command-line tool to capture traces from the Windows Performance Toolkit. For more information, see
Windows Performance Toolkit – Xperf.
Next steps
You can upload diagnostics logs and reports to Microsoft Support for further review. Support might request that
you transmit the output that is generated by PerfInsights to assist with the troubleshooting process.
The following screenshot shows a message similar to what you might receive:
Follow the instructions in the message to access the file transfer workspace. For additional security, you have to
change your password on first use.
After you sign in, you will find a dialog box to upload the PerformanceDiagnostics_yyyy-MM -dd_hh-mm -ss-
fff.zip file that was collected by PerfInsights.
Azure Performance Diagnostics VM Extension for
Windows
Azure Performance Diagnostics VM Extension helps collect performance diagnostic data from Windows VMs. The
extension performs analysis, and provides a report of findings and recommendations to identify and resolve
performance issues on the virtual machine. This extension installs a troubleshooting tool called PerfInsights.
NOTE
If you want to run diagnostics on your VM from the Azure portal for non-classic VMs, it is recommended to use the new
experience. For more information, see Performance Diagnostics for Azure virtual machines
Prerequisites
This extension can be installed on Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2,
and Windows Server 2016. It can also be installed on Windows 8.1 and Windows 10.
Extension schema
The following JSON shows the schema for Azure Performance Diagnostics VM Extension. This extension requires
the name and key for a storage account to store the diagnostics output and report. These values are sensitive.
Storage account key should be stored inside a protected setting configuration. Azure VM extension protected
setting data is encrypted, and it is only decrypted on the target virtual machine. Note that storageAccountName
and storageAccountKey are case-sensitive. Other required parameters are listed in the following section.
{
"name": "[concat(parameters('vmName'),'/AzurePerformanceDiagnostics')]",
"type": "Microsoft.Compute/virtualMachines/extensions",
"location": "[parameters('location')]",
"apiVersion": "2015-06-15",
"properties": {
"publisher": "Microsoft.Azure.Performance.Diagnostics",
"type": "AzurePerformanceDiagnostics",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"storageAccountName": "[parameters('storageAccountName')]",
"performanceScenario": "[parameters('performanceScenario')]",
"traceDurationInSeconds": "[parameters('traceDurationInSeconds')]",
"perfCounterTrace": "[parameters('perfCounterTrace')]",
"networkTrace": "[parameters('networkTrace')]",
"xperfTrace": "[parameters('xperfTrace')]",
"storPortTrace": "[parameters('storPortTrace')]",
"srNumber": "[parameters('srNumber')]",
"requestTimeUtc": "[parameters('requestTimeUtc')]",
"resourceId": "[resourceId('Microsoft.Compute/virtualMachines', parameters('vmName'))]"
},
"protectedSettings": {
"storageAccountKey": "[parameters('storageAccountKey')]"
}
}
}
Property values
NAME VALUE / EXAMPLE DESCRIPTION
apiVersion 2015-06-15 The version of the API.
publisher Microsoft.Azure.Performance.Diagnostic The publisher namespace for the

s extension.
type AzurePerformanceDiagnostics The type of the VM extension.
typeHandlerVersion 1.0 The version of the extension handler.
performanceScenario basic The performance scenario for which to

capture data. Valid values are: basic,
vmslow, azurefiles, and custom.
traceDurationInSeconds 300 The duration of the traces, if any of the

trace options are selected.
perfCounterTrace p Option to enable Performance Counter

Trace. Valid values are p or empty value.
If you do not want to capture this trace,
leave the value as empty.
networkTrace n Option to enable Network Trace. Valid

values are n or empty value. If you do
not want to capture this trace, leave the
value as empty.
xperfTrace x Option to enable XPerf Trace. Valid

values are x or empty value. If you do
value as empty.
storPortTrace s Option to enable StorPort Trace. Valid

values are s or empty value. If you do
value as empty.
srNumber 123452016365929 The support ticket number, if available.

Leave the value as empty if you don’t
have it.
requestTimeUtc 2017-09-28T22:08:53.736Z Current Date Time in Utc. If you are

using the portal to install this
extension, you do not need to provide
this value.
resourceId /subscriptions/{subscriptionId}/resource The unique identifier of a VM.

Groups/{resourceGroupName}/provider
s/{resourceProviderNamespace}/{resour
ceType}/{resourceName}
storageAccountName mystorageaccount The name of the storage account to

store the diagnostics logs and results.
NAME VALUE / EXAMPLE DESCRIPTION
storageAccountKey lDuVvxuZB28NNP… The key for the storage account.

hAiRF3voADxLBTcc==
Install the extension

Follow these instructions to install the extension on Windows virtual machines:
2. Select the virtual machine where you want to install this extension.
3. Select the Extensions blade, and select Add.
4. Select Azure Performance Diagnostics, review the terms and conditions, and select Create.
5. Provide the parameter values for the installation, and select OK to install the extension. For more
information about supported scenarios, see How to use PerfInsights.
6. When the installation is successful, you see a message indicating this status.
NOTE
The extension runs when the provisioning has succeeded. It takes two minutes or less to complete for the basic
scenario. For other scenarios, it runs through the duration specified during the installation.
Remove the extension

To remove the extension from a virtual machine, follow these steps:
1. Sign in to the Azure portal, select the virtual machine from which you want to remove this extension, and
then select the Extensions blade.
2. Select the (… ) for the Performance Diagnostics Extension entry from the list, and select Uninstall.
NOTE
You can also select the extension entry, and select the Uninstall option.
Template deployment
Azure virtual machine extensions can be deployed with Azure Resource Manager templates. The JSON schema
detailed in the previous section can be used in an Azure Resource Manager template. This runs the Azure
Performance Diagnostics VM extension during an Azure Resource Manager template deployment. Here is a
sample template:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string",
"defaultValue": "yourVMName"
},
"location": {
"type": "string",
"defaultValue": "southcentralus"
},
"storageAccountName": {
"type": "securestring"
"defaultValue": "yourStorageAccount"
},
"storageAccountKey": {
"type": "securestring"
"defaultValue": "yourStorageAccountKey"
},
"performanceScenario": {
"type": "string",
"defaultValue": "basic"
},
"srNumber": {
"type": "string",
"defaultValue": ""
},
"traceDurationInSeconds": {
"type": "int",
"defaultValue": 300
},
"perfCounterTrace": {
"type": "string",
"defaultValue": "p"
},
"networkTrace": {
"type": "string",
"defaultValue": ""
},
"xperfTrace": {
"type": "string",
"defaultValue": ""
},
"storPortTrace": {
"type": "string",
"defaultValue": ""
},
"requestTimeUtc": {
"type": "string",
"defaultValue": "10/2/2017 11:06:00 PM"
}
},
"resources": [
{
"name": "[concat(parameters('vmName'),'/AzurePerformanceDiagnostics')]",
"type": "Microsoft.Compute/virtualMachines/extensions",
"location": "[parameters('location')]",
"apiVersion": "2015-06-15",
"properties": {
"publisher": "Microsoft.Azure.Performance.Diagnostics",
"type": "AzurePerformanceDiagnostics",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"storageAccountName": "[parameters('storageAccountName')]",
"performanceScenario": "[parameters('performanceScenario')]",
"traceDurationInSeconds": "[parameters('traceDurationInSeconds')]",
"perfCounterTrace": "[parameters('perfCounterTrace')]",
"networkTrace": "[parameters('networkTrace')]",
"xperfTrace": "[parameters('xperfTrace')]",
"storPortTrace": "[parameters('storPortTrace')]",
"srNumber": "[parameters('srNumber')]",
"requestTimeUtc": "[parameters('requestTimeUtc')]",
"resourceId": "[resourceId('Microsoft.Compute/virtualMachines', parameters('vmName'))]"
},
"protectedSettings": {
"storageAccountKey": "[parameters('storageAccountKey')]"
}
}
}
]
}
PowerShell deployment
The Set-AzVMExtension command can be used to deploy Azure Performance Diagnostics VM Extension to an
existing virtual machine.
PowerShell
$PublicSettings = @{
"storageAccountName"="mystorageaccount";"performanceScenario"="basic";"traceDurationInSeconds"=300;"perfCounte
rTrace"="p";"networkTrace"="";"xperfTrace"="";"storPortTrace"="";"srNumber"="";"requestTimeUtc"="2017-09-
28T22:08:53.736Z";"resourceId"="VMResourceId" }
$ProtectedSettings = @{"storageAccountKey"="mystoragekey" }
Set-AzVMExtension -ExtensionName "AzurePerformanceDiagnostics" `

-ResourceGroupName "myResourceGroup" `
-VMName "myVM" `
-Publisher "Microsoft.Azure.Performance.Diagnostics" `
-ExtensionType "AzurePerformanceDiagnostics" `
-TypeHandlerVersion 1.0 `
-Settings $PublicSettings `
-ProtectedSettings $ProtectedSettings `
-Location WestUS
Information on the data captured

The PerfInsights tool collects various logs, configuration, and diagnostic data, depending on the selected scenario.
For more information, see the PerfInsights documentation.
View and share the results

Output from the extension can be found in a zip file that uploaded to the storage account specified during the
installation and is shared for 30 days by using Shared Access Signatures (SAS ). This zip file contains diagnostic
logs and a report with findings and recommendations. A SAS link to the output zip file can be found inside a text
file named zipfilename_saslink.txt under the folder
C:\Packages\Plugins\Microsoft.Azure.Performance.Diagnostics.AzurePerformanceDiagnostics\
<version>. Anyone who has this link is able to download the zip file.
To assist the support engineer working on your support ticket, Microsoft might use this SAS link to download the
diagnostics data.
To view the report, extract the zip file and open the PerfInsights Report.html file.
You should also be able to download the zip file directly from the portal by selecting the extension.
NOTE
The SAS link displayed in the portal might not work sometimes. This can be caused by a malformed URL during the
encoding and decoding operations. You can instead get the link directly from the *_saslink.txt file from the VM.
Troubleshoot and support
Extension deployment status (in the notification area) might show “Deployment in progress” even though
the extension is successfully provisioned.
This issue can be safely ignored, as long as the extension status indicates that the extension is successfully
provisioned.
You can address some issues during installation by using the extension logs. Extension execution output is
logged to files found in the following directory:
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Performance.Diagnostics.AzurePerformanceDiagnostics\
<version>
Overflow forums. Alternatively, you can file an Azure support incident. Go to the Azure support site, and select
Get support. For information about using Azure support, read the Microsoft Azure support FAQ.
Install the Azure Virtual Machine Agent in offline
mode
The Azure Virtual Machine Agent (VM Agent) provides useful features, such as local administrator password reset
and script pushing. This article shows you how to install the VM Agent for an offline Windows virtual machine
(VM ).
When to use the VM Agent in offline mode

Install the VM Agent in offline mode in the following scenarios:
The deployed Azure VM doesn't have the VM Agent installed or the agent isn't working.
You forgot the administrator password for the VM or you can't access the VM.
How to install the VM Agent in offline mode

Use the following steps to install the VM Agent in offline mode.
NOTE
You can automate the process of installing the VM Agent in offline mode. To do this, use the Azure VM Recovery Scripts. If
you choose to use the Azure VM Recovery Scripts, you can use the following process:
1. Skip step 1 by using the scripts to attach the OS disk of the affected VM to a recovery VM.
2. Follow steps 2–10 to apply the mitigations.
3. Skip step 11 by using the scripts to rebuild the VM.
4. Follow step 12.
Step 1: Attach the OS disk of the VM to another VM as a data disk

1. Delete the VM. Be sure to select the Keep the disks option when you delete the VM.
2. Attach the OS disk as a data disk to another VM (known as a troubleshooter VM ). For more information, see
Attach a data disk to a Windows VM in the Azure portal.
3. Connect to the troubleshooter VM. Open Computer management > Disk management. Confirm that
the OS disk is online and that drive letters are assigned to the disk partitions.
Step 2: Modify the OS disk to install the Azure VM Agent
1. Make a remote desktop connection to the troubleshooter VM.
2. On the OS disk that you attached, browse to the \windows\system32\config folder. Copy all of the files in
this folder as a backup, in case a rollback is required.
3. Start the Registry Editor (regedit.exe).
4. Select the HKEY_LOCAL_MACHINE key. On the menu, select File > Load Hive:
5. Browse to the \windows\system32\config\SYSTEM folder on the OS disk that you attached. For the name
of the hive, enter BROKENSYSTEM. The new registry hive is displayed under the
HKEY_LOCAL_MACHINE key.
6. Browse to the \windows\system32\config\SOFTWARE folder on the OS disk that you attached. For the
name of the hive software, enter BROKENSOFTWARE.
7. If the Attached OS disk has the VM agent installed, perform a backup of the current configuration. If it does
not have VM agent installed, move to the next step.
a. Rename the \windowsazure folder to \windowsazure.old.
b. Export the following registries:
HKEY_LOCAL_MACHINE\BROKENSYSTEM\ControlSet001\Services\WindowsAzureGuestAgent
HKEY_LOCAL_MACHINE\BROKENSYSTEM\ControlSet001\Services\WindowsAzureTelemetryService
HKEY_LOCAL_MACHINE\BROKENSYSTEM\ControlSet001\Services\RdAgent
8. Use the existing files on the troubleshooter VM as a repository for the VM Agent installation. Complete the
following steps:
a. From the troubleshooter VM, export the following subkeys in registry format (.reg):
HKEY_LOCAL_MACHINE \SYSTEM\ControlSet001\Services\WindowsAzureGuestAgent
HKEY_LOCAL_MACHINE
\SYSTEM\ControlSet001\Services\WindowsAzureTelemetryService
HKEY_LOCAL_MACHINE \SYSTEM\ControlSet001\Services\RdAgent
b. Edit the registry files. In each file, change the entry value SYSTEM to BROKENSYSTEM (as shown
in the following images) and save the file. Remember the ImagePath of the current VM agent. We
will need to copy the corresponding folder to the attached OS disk.
c. Import the registry files into the repository by double-clicking each registry file.
d. Confirm that the following three subkeys are successfully imported into the BROKENSYSTEM hive:
WindowsAzureGuestAgent
WindowsAzureTelemetryService
RdAgent
e. Copy the installation folder of the current VM Agent to the attached OS disk:
a. On the OS disk that you attached, create a folder named WindowsAzure in the root path.
b. Go to C:\WindowsAzure on the troubleshooter VM, look for any folder with the name
C:\WindowsAzure\GuestAgent_X.X.XXXX.XXX. Copy the GuestAgent folder that has latest
version number from C:\WindowsAzure to the WindowsAzure folder in the attached OS disk.
If you are not sure which folder should be copied, copy all GuestAgent folders. The following
image shows an example of the GuestAgent folder that is copied to the attached OS disk.
9. Select BROKENSYSTEM. From the menu, select File > Unload Hive.
10. Select BROKENSOFTWARE. From the menu, select File > Unload Hive.
11. Detach the OS disk, and then recreate the VM by using the OS disk.
12. Access the VM. Notice that the RdAgent is running and the logs are being generated.
If you created the VM by using the Resource Manager deployment model, you're done.
Use the ProvisionGuestAgent property for classic VMs
If you created the VM by using the classic model, use the Azure PowerShell module to update the
ProvisionGuestAgent property. The property informs Azure that the VM has the VM Agent installed.
To set the ProvisionGuestAgent property, run the following commands in Azure PowerShell:
$vm = Get-AzureVM –ServiceName <cloud service name> –Name <VM name>

$vm.VM.ProvisionGuestAgent = $true
Update-AzureVM –Name <VM name> –VM $vm.VM –ServiceName <cloud service name>
Then run the Get-AzureVM command. Notice that the GuestAgentStatus property is now populated with data:
Get-AzureVM –ServiceName <cloud service name> –Name <VM name>

GuestAgentStatus:Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVMModel.GuestAgentStatus
Next steps
Azure Virtual Machine Agent overview
Virtual machine extensions and features for Windows
Redeploy Linux virtual machine to new Azure node
If you face difficulties troubleshooting SSH or application access to a Linux virtual machine (VM ) in Azure,
redeploying the VM may help. When you redeploy a VM, it moves the VM to a new node within the Azure
infrastructure and then powers it back on. All your configuration options and associated resources are retained.
This article shows you how to redeploy a VM using Azure CLI or the Azure portal.
NOTE
After you redeploy a VM, the temporary disk is lost and dynamic IP addresses associated with virtual network interface are
updated.
Use the Azure CLI

Install the latest Azure CLI and log in to your Azure account using az login.
Redeploy your VM with az vm redeploy. The following example redeploys the VM named myVM in the resource
group named myResourceGroup:
az vm redeploy --resource-group myResourceGroup --name myVM
Use the Azure classic CLI

Install the latest Azure classic CLI and log in to your Azure account. Make sure that you are in Resource Manager
mode ( azure config mode arm ).
The following example redeploys the VM named myVM in the resource group named myResourceGroup:
azure vm redeploy --resource-group myResourceGroup --vm-name myVM

1. Select the VM you wish to redeploy, then select the Redeploy button in the Settings blade. You may need to
scroll down to see the Support and Troubleshooting section that contains the 'Redeploy' button as in the
following example:
2. To confirm the operation, select the Redeploy button:
3. The Status of the VM changes to Updating as the VM prepares to redeploy, as shown in the following
example:
4. The Status then changes to Starting as the VM boots up on a new Azure host, as shown in the following
example:
5. After the VM finishes the boot process, the Status then returns to Running, indicating the VM has been
successfully redeployed:
Next steps
If you are having issues connecting to your VM, you can find specific help on troubleshooting SSH connections or
detailed SSH troubleshooting steps. If you cannot access an application running on your VM, you can also read
application troubleshooting issues.
Redeploy Windows virtual machine to new Azure
node
If you have been facing difficulties troubleshooting Remote Desktop (RDP ) connection or application access to
Windows-based Azure virtual machine (VM ), redeploying the VM may help. When you redeploy a VM, Azure will
shut down the VM, move the VM to a new node within the Azure infrastructure, and then power it back on,
retaining all your configuration options and associated resources. This article shows you how to redeploy a VM
using Azure PowerShell or the Azure portal.
NOTE
After you redeploy a VM, the temporary disk is lost and dynamic IP addresses associated with virtual network interface are
updated.
Using Azure PowerShell

Make sure you have the latest Azure PowerShell 1.x installed on your machine. For more information, see How to
install and configure Azure PowerShell.
The following example deploys the VM named myVM in the resource group named myResourceGroup :
Set-AzVM -Redeploy -ResourceGroupName "myResourceGroup" -Name "myVM"

1. Select the VM you wish to redeploy, then select the Redeploy button in the Settings blade. You may need to
scroll down to see the Support and Troubleshooting section that contains the 'Redeploy' button as in the
following example:
2. To confirm the operation, select the Redeploy button:
3. The Status of the VM changes to Updating as the VM prepares to redeploy, as shown in the following
example:
4. The Status then changes to Starting as the VM boots up on a new Azure host, as shown in the following
example:
5. After the VM finishes the boot process, the Status then returns to Running, indicating the VM has been
successfully redeployed:
Next steps
If you are having issues connecting to your VM, you can find specific help on troubleshooting RDP connections or
detailed RDP troubleshooting steps. If you cannot access an application running on your VM, you can also read
application troubleshooting issues.
Reset local Windows password for Azure VM offline
You can reset the local Windows password of a VM in Azure using the Azure portal or Azure PowerShell provided
the Azure guest agent is installed. This method is the primary way to reset a password for an Azure VM. If you
encounter issues with the Azure guest agent not responding, or failing to install after uploading a custom image,
you can manually reset a Windows password. This article details how to reset a local account password by
attaching the source OS virtual disk to another VM. The steps described in this article do not apply to Windows
domain controllers.
WARNING
Only use this process as a last resort. Always try to reset a password using the Azure portal or Azure PowerShell first.
Overview of the process

The core steps for performing a local password reset for a Windows VM in Azure when there is no access to the
Azure guest agent is as follows:
Delete the source VM. The virtual disks are retained.
Attach the source VM's OS disk to another VM on the same location within your Azure subscription. This VM is
referred to as the troubleshooting VM.
Using the troubleshooting VM, create some config files on the source VM's OS disk.
Detach the VM's OS disk from the troubleshooting VM.
Use a Resource Manager template to create a VM, using the original virtual disk.
When the new VM boots, the config files you create update the password of the required user.
NOTE
You can automate the following processes:
Creating the troubleshooting VM
Attaching the OS disk
Re-creating the original VM
To do this, use the Azure VM Recovery Scripts. If you choose to use the Azure VM Recovery Scripts, you can use the
following process in the "Detailed steps" section:
1. Skip steps 1 and 2 by using the scripts to attach the OS disk of the affected VM to a recovery VM.
2. Follow steps 3–6 to apply the mitigations.
3. Skip steps 7–9 by using the scripts to rebuild the VM.
4. Follow steps 10 and 11.
Detailed steps
NOTE
The steps do not apply to Windows domain controllers. It only works on standalone server or a server that is a member of a
domain.
Always try to reset a password using the Azure portal or Azure PowerShell before trying the following steps. Make
sure you have a backup of your VM before you start.
1. Delete the affected VM in Azure portal. Deleting the VM only deletes the metadata, the reference of the VM
within Azure. The virtual disks are retained when the VM is deleted:
Select the VM in the Azure portal, click Delete:
2. Attach the source VM’s OS disk to the troubleshooting VM. The troubleshooting VM must be in the same
region as the source VM's OS disk (such as West US ):
Select the troubleshooting VM in the Azure portal. Click Disks | Attach existing:
Select VHD File and then select the storage account that contains your source VM:
Select the source container. The source container is typically vhds:
Select the OS vhd to attach. Click Select to complete the process:

3. Connect to the troubleshooting VM using Remote Desktop and ensure the source VM's OS disk is visible:
Select the troubleshooting VM in the Azure portal and click Connect.
Open the RDP file that downloads. Enter the username and password of the troubleshooting VM.
In File Explorer, look for the data disk you attached. If the source VM’s VHD is the only data disk
attached to the troubleshooting VM, it should be the F: drive:
4. Create gpt.ini in \Windows\System32\GroupPolicy on the source VM’s drive (if gpt.ini exists, rename to
gpt.ini.bak):
WARNING
Make sure that you do not accidentally create the following files in C:\Windows, the OS drive for the troubleshooting
VM. Create the following files in the OS drive for your source VM that is attached as a data disk.
Add the following lines into the gpt.ini file you created:
[General]
gPCFunctionalityVersion=2
gPCMachineExtensionNames=[{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B6664F-4972-11D1-A7CA-
0000F87571E3}]
Version=1
5. Create scripts.ini in \Windows\System32\GroupPolicy\Machines\Scripts\ . Make sure hidden folders are

shown. If needed, create the Machine or Scripts folders.
Add the following lines the scripts.ini file you created:
[Startup]
0CmdLine=C:\Windows\System32\FixAzureVM.cmd
0Parameters=
6. Create FixAzureVM.cmd in \Windows\System32 with the following contents, replacing <username> and
<newpassword> with your own values:
net user <username> <newpassword> /add

net localgroup administrators <username> /add
net localgroup "remote desktop users" <username> /add
You must meet the configured password complexity requirements for your VM when defining the new
password.
7. In Azure portal, detach the disk from the troubleshooting VM:
Select the troubleshooting VM in the Azure portal, click Disks.
Select the data disk attached in step 2, click Detach:
8. Before you create a VM, obtain the URI to your source OS disk:
Select the storage account in the Azure portal, click Blobs.
Select the container. The source container is typically vhds:
Select your source VM OS VHD and click the Copy button next to the URL name:
9. Create a VM from the source VM’s OS disk:
Use this Azure Resource Manager template to create a VM from a specialized VHD. Click the
Deploy to Azure button to open the Azure portal with the templated details populated for you.
If you want to retain all the previous settings for the VM, select Edit template to provide your existing
VNet, subnet, network adapter, or public IP.
In the OSDISKVHDURI parameter text box, paste the URI of your source VHD obtain in the preceding
step:
10. After the new VM is running, connect to the VM using Remote Desktop with the new password you
specified in the FixAzureVM.cmd script.
11. From your remote session to the new VM, remove the following files to clean up the environment:
From %windir%\System32
remove FixAzureVM.cmd
From %windir%\System32\GroupPolicy\Machine\Scripts
remove scripts.ini
From %windir%\System32\GroupPolicy
remove gpt.ini (if gpt.ini existed before, and you renamed it to gpt.ini.bak, rename the .bak file
back to gpt.ini)
Next steps
If you still cannot connect using Remote Desktop, see the RDP troubleshooting guide. The detailed RDP
troubleshooting guide looks at troubleshooting methods rather than specific steps. You can also open an Azure
support request for hands-on assistance.
How to reset local Linux password on Azure VMs
This article introduces several methods to reset local Linux Virtual Machine (VM ) passwords. If the user account is
expired or you just want to create a new account, you can use the following methods to create a new local admin
account and re-gain access to the VM.
Symptoms
You can't log in to the VM, and you receive a message that indicates that the password that you used is incorrect.
Additionally, you can't use VMAgent to reset your password on the Azure portal.
Manual password reset procedure

1. Delete the VM and keep the attached disks.
2. Attach the OS Drive as a data disk to another temporal VM in the same location.
3. Run the following SSH command on the temporal VM to become a super-user.
sudo su
4. Run fdisk -l or look at system logs to find the newly attached disk. Locate the drive name to mount. Then on
the temporal VM, look in the relevant log file.
grep SCSI /var/log/kern.log (ubuntu)

grep SCSI /var/log/messages (centos, suse, oracle)
The following is example output of the grep command:
kernel: [ 9707.100572] sd 3:0:0:0: [sdc] Attached SCSI disk
5. Create a mount point called tempmount.
mkdir /tempmount
6. Mount the OS disk on the mount point. You usually need to mount sdc1 or sdc2. This will depend on the
hosting partition in /etc directory from the broken machine disk.
mount /dev/sdc1 /tempmount
7. Create copies of the core credential files before making any changes:
cp /etc/passwd /etc/passwd_orig
cp /etc/shadow /etc/shadow_orig
cp /tempmount/etc/passwd /etc/passwd
cp /tempmount/etc/shadow /etc/shadow
cp /tempmount/etc/passwd /tempmount/etc/passwd_orig
cp /tempmount/etc/shadow /tempmount/etc/shadow_orig
8. Reset the user’s password that you need:
passwd <<USER>>
9. Move the modified files to the correct location on the broken machine's disk.
cp /etc/passwd /tempmount/etc/passwd
cp /etc/shadow /tempmount/etc/shadow
cp /etc/passwd_orig /etc/passwd
cp /etc/shadow_orig /etc/shadow
10. Go back to the root and unmount the disk.
cd /
umount /tempmount
11. Detach the disk from the management portal.

12. Recreate the VM.
Next steps
Troubleshoot Azure VM by attaching OS disk to another Azure VM
Azure CLI: How to delete and re-deploy a VM from VHD
How to reset network interface for Azure Windows
VM
NOTE
article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager
model.
This article shows how to reset the network interface for Azure Windows VM to resolve issues when you cannot
connect to Microsoft Azure Windows Virtual Machine (VM ) after:
You disable the default Network Interface (NIC ).
You manually set a static IP for the NIC.
post your issue in these forums, or post to @AzureSupport on Twitter. You also can submit an Azure support
request. To submit a support request, on the Azure support page, select Get support.
Reset network interface

For VMs deployed in Resource group model
1. Go to the Azure portal.
2. Select the affected Virtual Machine.
3. Select Networking and then select the network Interface of the VM.
4. Select IP configurations.
5. Select the IP.
6. If the Private IP assignment is not Static, change it to Static.
7. Change the IP address to another IP address that is available in the Subnet.
8. The virtual machine will restart to initialize the new NIC to the system.
9. Try to RDP to your machine. If successful, you can change the Private IP address back to the original if you
would like. Otherwise, you can keep it.
Use Azure PowerShell
1. Make sure that you have the latest Azure PowerShell installed
2. Open an elevated Azure PowerShell session (Run as administrator). Run the following commands:
#Set the variables
$SubscriptionID= "<Subscription ID>"
$VM = "<VM Name>"
$ResourceGroup = "<Resource Group>"
$VNET = "<Virtual Network>"
$IP = "NEWIP"
#Log in to the subscription

Add-AzAccount
Select-AzSubscription -SubscriptionId $SubscriptionId
#Check whether the new IP address is available in the virtual network.

Test-AzureStaticVNetIP –VNetName $VNET –IPAddress $IP
#Add/Change static IP. This process will not change MAC address
Get-AzVM -ServiceName $ResourceGroup -Name $VM | Set-AzureStaticVNetIP -IPAddress $IP | Update-AzVM
For Classic VMs
To reset network interface, follow these steps:
Use Azure portal
1. Go to the Azure portal.
2. Select Virtual Machines (Classic).
3. Select the affected Virtual Machine.
4. Select IP addresses.
5. If the Private IP assignment is not Static, change it to Static.
6. Change the IP address to another IP address that is available in the Subnet.
7. Select Save.
8. The virtual machine will restart to initialize the new NIC to the system.
9. Try to RDP to your machine. If successful, you can choose to revert the Private IP address back to the original.
Use Azure PowerShell
1. Make sure that you have the latest Azure PowerShell installed.
2. Open an elevated Azure PowerShell session (Run as administrator). Run the following commands:
#Set the variables

$SubscriptionID= "<Subscription ID>"
$VM = "<VM Name>"
$CloudService = "<Cloud Service>"
$VNET = "<Virtual Network>"
$IP = "NEWIP"
#Log in to the subscription

Add-AzureAccount
Select-AzureSubscription -SubscriptionId $SubscriptionId
#Check whether the new IP address is available in the virtual network.

Test-AzureStaticVNetIP –VNetName $VNET –IPAddress $IP
#Add/Change static IP. This process will not change MAC address
Get-AzureVM -ServiceName $CloudService -Name $VM | Set-AzureStaticVNetIP -IPAddress $IP |Update-AzureVM
Delete the unavailable NICs
After you can remote desktop to the machine, you must delete the old NICs to avoid the potential problem:
1. Open Device Manager.
2. Select View > Show hidden devices.
3. Select Network Adapters.
4. Check for the adapters named as "Microsoft Hyper-V Network Adapter".
5. You might see an unavailable adapter that is grayed out. Right-click the adapter and then select Uninstall.
NOTE
Only uninstall the unavailable adapters that have the name "Microsoft Hyper-V Network Adapter". If you uninstall
any of the other hidden adapters, it could cause additional issues.
6. Now all unavailable adapters should be cleared of your system.

Troubleshoot deployment issues with restarting or
resizing an existing Windows VM in Azure
When you try to start a stopped Azure Virtual Machine (VM ), or resize an existing Azure VM, the common error
you encounter is an allocation failure. This error results when the cluster or region either does not have resources
available or cannot support the requested VM size.
Collect activity logs

To start troubleshooting, collect the activity logs to identify the error associated with the issue. The following links
contain detailed information on the process:
View deployment operations
View activity logs to manage Azure resources
Issue: Error when starting a stopped VM

You try to start a stopped VM but get an allocation failure.
Cause
The request to start the stopped VM has to be attempted at the original cluster that hosts the cloud service.
However, the cluster does not have free space available to fulfill the request.
Resolution
Stop all the VMs in the availability set, and then restart each VM.
1. Click Resource groups > your resource group > Resources > your availability set > Virtual Machines
> your virtual machine > Stop.
2. After all the VMs stop, select each of the stopped VMs and click Start.
Retry the restart request at a later time.
Issue: Error when resizing an existing VM

You try to resize an existing VM but get an allocation failure.
Cause
The request to resize the VM has to be attempted at the original cluster that hosts the cloud service. However, the
cluster does not support the requested VM size.
Resolution
Retry the request using a smaller VM size.
If the size of the requested VM cannot be changed：
1. Stop all the VMs in the availability set.
Click Resource groups > your resource group > Resources > your availability set > Virtual
Machines > your virtual machine > Stop.
2. After all the VMs stop, resize the desired VM to a larger size.
3. Select the resized VM and click Start, and then start each of the stopped VMs.
Next steps
If you encounter issues when you create a new Windows VM in Azure, see Troubleshoot deployment issues with
creating a new Windows virtual machine in Azure.
Azure Serial Console for Linux
The Serial Console in the Azure portal provides access to a text-based console for Linux virtual machines (VMs)
and virtual machine scale set instances. This serial connection connects to the COM1 serial port of the VM or
virtual machine scale set instance, providing access to it independent of the network or operating system state.
The serial console can only be accessed by using the Azure portal and is allowed only for those users who have an
access role of Contributor or higher to the VM or virtual machine scale set.
Serial Console works in the same manner for VMs and virtual machine scale set instances. In this doc, all
mentions to VMs will implicitly include virtual machine scale set instances unless otherwise stated.
For Serial Console documentation for Windows, see Serial Console for Windows.
NOTE
The Serial Console is generally available in global Azure regions. It is not yet available in Azure government or Azure China
clouds.
Prerequisites
Your VM or virtual machine scale set instance must use the resource management deployment model.
Classic deployments aren't supported.
Your account that uses serial console must have the Virtual Machine Contributor role for the VM and the
boot diagnostics storage account
Your VM or virtual machine scale set instance must have a password-based user. You can create one with
the reset password function of the VM access extension. Select Reset password from the Support +
troubleshooting section.
Your VM or virtual machine scale set instance must have boot diagnostics enabled.
For settings specific to Linux distributions, see Serial console Linux distribution availability.
Get started with the Serial Console

The Serial Console for VMs and virtual machine scale set is accessible only through the Azure portal:
Serial Console for Virtual Machines
Serial Console for VMs is as straightforward as clicking on Serial console within the Support +
troubleshooting section in the Azure portal.
1. Open the Azure portal.
2. Navigate to All resources and select a Virtual Machine. The overview page for the VM opens.
3. Scroll down to the Support + troubleshooting section and select Serial console. A new pane with the
serial console opens and starts the connection.
Serial Console for Virtual Machine Scale Sets

Serial Console is available on a per-instance basis for virtual machine scale sets. You will have to navigate to the
individual instance of a virtual machine scale set before seeing the Serial console button. If your virtual machine
scale set does not have boot diagnostics enabled, ensure you update your virtual machine scale set model to
enable boot diagnostics, and then upgrade all instances to the new model in order to access serial console.
2. Navigate to All resources and select a Virtual Machine Scale Set. The overview page for the virtual
machine scale set opens.
3. Navigate to Instances
4. Select a virtual machine scale set instance
5. From the Support + troubleshooting section, select Serial console. A new pane with the serial console
opens and starts the connection.
NOTE
The serial console requires a local user with a configured password. VMs or virtual machine scale sets configured only with
an SSH public key won't be able to sign in to the serial console. To create a local user with a password, use the VMAccess
Extension, which is available in the portal by selecting Reset password in the Azure portal, and create a local user with a
password. You can also reset the administrator password in your account by using GRUB to boot into single user mode.
Serial Console Linux distribution availability

For the serial console to function properly, the guest operating system must be configured to read and write
console messages to the serial port. Most Endorsed Azure Linux distributions have the serial console configured
by default. Selecting Serial console in the Support + troubleshooting section of the Azure portal provides
access to the serial console.
DISTRIBUTION SERIAL CONSOLE ACCESS
Red Hat Enterprise Linux Serial console access enabled by default.
CentOS Serial console access enabled by default.
Ubuntu Serial console access enabled by default.
CoreOS Serial console access enabled by default.
SUSE Newer SLES images available on Azure have serial console

access enabled by default. If you're using older versions (10 or
earlier) of SLES on Azure, see the KB article to enable serial
console.
DISTRIBUTION SERIAL CONSOLE ACCESS
Oracle Linux Serial console access enabled by default.
Custom Linux images To enable the serial console for your custom Linux VM image,
enable console access in the file /etc/inittab to run a terminal
on ttyS0 . For example:
S0:12345:respawn:/sbin/agetty -L 115200 console
vt102
. For more information on properly creating custom images,
see Create and upload a Linux VHD in Azure. If you're building
a custom kernel, consider enabling these kernel flags:
CONFIG_SERIAL_8250=y and
CONFIG_MAGIC_SYSRQ_SERIAL=y . The configuration file is
typically located in the /boot/ path.
NOTE
If you are not seeing anything in the serial console, make sure that boot diagnostics is enabled on your VM. Hitting Enter
will often fix issues where nothing is showing up in the serial console.
Common scenarios for accessing the Serial Console

SCENARIO ACTIONS IN THE SERIAL CONSOLE
Broken FSTAB file Press the Enter key to continue and use a text editor to fix
the FSTAB file. You might need to be in single user mode to
do so. For more information, see the serial console section of
How to fix fstab issues and Use serial console to access GRUB
and single user mode.
Incorrect firewall rules If you have configured iptables to block SSH connectivity, you
can use serial console to interact with your VM without
needing SSH. More details can be found at the iptables man
page.
Similarly, if your firewalld is blocking SSH access, you can
access the VM through serial console and reconfigure
firewalld. More details can be found in the firewalld
documentation.
Filesystem corruption/check Please see the serial console section of Azure Linux VM
cannot start because of file system errors for more details on
troubleshooting corrupted file systems using serial console.
SSH configuration issues Access the serial console and change the settings. Serial
console can be used regardless of the SSH configuration of a
VM as it does not require the VM to have network
connectivity to work. A troubleshooting guide is available at
Troubleshoot SSH connections to an Azure Linux VM that
fails, errors out, or is refused. More details are available at
Detailed SSH troubleshooting steps for issues connecting to a
Linux VM in Azure
Interacting with bootloader Restart your VM from within the serial console blade to access
GRUB on your Linux VM. For more details and distro-specific
information, see Use serial console to access GRUB and single
user mode.
Disable the Serial Console
By default, all subscriptions have serial console access enabled. You can disable the serial console at either the
subscription level or VM/virtual machine scale set level. Note that boot diagnostics must be enabled on a VM in
order for serial console to work.
VM/virtual machine scale set-level disable
The serial console can be disabled for a specific VM or virtual machine scale set by disabling the boot diagnostics
setting. Turn off boot diagnostics from the Azure portal to disable the serial console for the VM or the virtual
machine scale set. If you are using serial console on a virtual machine scale set, ensure you upgrade your virtual
machine scale set instances to the latest model.
NOTE
To enable or disable the serial console for a subscription, you must have write permissions to the subscription. These
permissions include administrator or owner roles. Custom roles can also have write permissions.
Subscription-level disable
The serial console can be disabled for an entire subscription through the Disable Console REST API call. This
action requires contributor level access or above to the subscription. You can use the Try It function available on
this API documentation page to disable and enable the serial console for a subscription. Enter your subscription
ID for subscriptionId, enter default for default, and then select Run. Azure CLI commands aren't yet available.
To reenable serial console for a subscription, use the Enable Console REST API call.
Alternatively, you can use the following set of bash commands in Cloud Shell to disable, enable, and view the
disabled status of the serial console for a subscription:
To get the disabled status of the serial console for a subscription:
$ export ACCESSTOKEN=($(az account get-access-token --output=json | jq .accessToken | tr -d '"'))
$ export SUBSCRIPTION_ID=$(az account show --output=json | jq .id -r)
$ curl
"https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.SerialConsole/consoleS
ervices/default?api-version=2018-05-01" -H "Authorization: Bearer $ACCESSTOKEN" -H "Content-Type:
application/json" -H "Accept: application/json" -s | jq .properties
To disable the serial console for a subscription:
$ curl -X POST
ervices/default/disableConsole?api-version=2018-05-01" -H "Authorization: Bearer $ACCESSTOKEN" -H
"Content-Type: application/json" -H "Accept: application/json" -s -H "Content-Length: 0"
To enable the serial console for a subscription:
$ curl -X POST
ervices/default/enableConsole?api-version=2018-05-01" -H "Authorization: Bearer $ACCESSTOKEN" -H
Serial console security

Access security
Access to the serial console is limited to users who have an access role of Virtual Machine Contributor or higher
to the virtual machine. If your Azure Active Directory tenant requires multi-factor authentication (MFA), then
access to the serial console will also need MFA because the serial console's access is through the Azure portal.
Channel security
All data that is sent back and forth is encrypted on the wire.
Audit logs
All access to the serial console is currently logged in the boot diagnostics logs of the virtual machine. Access to
these logs are owned and controlled by the Azure virtual machine administrator.
Cau t i on
No access passwords for the console are logged. However, if commands run within the console contain or output
passwords, secrets, user names, or any other form of personally identifiable information (PII), those will be written
to the VM boot diagnostics logs. They will be written along with all other visible text, as part of the
implementation of the serial console's scroll back function. These logs are circular and only individuals with read
permissions to the diagnostics storage account have access to them. However, we recommend following the best
practice of using the Remote Desktop for anything that may involve secrets and/or PII.
Concurrent usage
If a user is connected to the serial console and another user successfully requests access to that same virtual
machine, the first user will be disconnected and the second user connected to the same session.
Cau t i on
This means that a user who's disconnected won't be logged out. The ability to enforce a logout upon disconnect
(by using SIGHUP or similar mechanism) is still on the roadmap. For Windows there is an automatic timeout
enabled in Special Administrative Console (SAC ); however, for Linux you can configure the terminal timeout
setting. To do so, add export TMOUT=600 in your .bash_profile or .profile file for the user you use to sign in to the
console. This setting will time out the session after 10 minutes.
Accessibility
Accessibility is a key focus for the Azure Serial Console. To that end, we've ensured that the serial console is fully
accessible.
Keyboard navigation
Use the Tab key on your keyboard to navigate in the serial console interface from the Azure portal. Your location
will be highlighted on screen. To leave the focus of the serial console window, press Ctrl+F6 on your keyboard.
Use Serial Console with a screen reader
The serial console has screen reader support built in. Navigating around with a screen reader turned on will allow
the alt text for the currently selected button to be read aloud by the screen reader.
Errors
Because most errors are transient, retrying your connection can often fix them. The following table shows a list of
errors and mitigations. These errors and mitigations apply for both VMs and virtual machine scale set instances.
ERROR MITIGATION
Unable to retrieve boot diagnostics settings for <VMNAME>. Ensure that the VM has boot diagnostics enabled.
To use the serial console, ensure that boot diagnostics is
enabled for this VM.
The VM is in a stopped deallocated state. Start the VM and The VM must be in a started state to access the serial
retry the serial console connection. console.
You do not have the required permissions to use this VM The serial console access requires certain permissions. For
with the serial console. Ensure you have at least Virtual more information, see Prerequisites.
Machine Contributor role permissions.
Unable to determine the resource group for the boot The serial console access requires certain permissions. For
diagnostics storage account <STORAGEACCOUNTNAME>. more information, see Prerequisites.
Verify that boot diagnostics is enabled for this VM and you
have access to this storage account.
Web socket is closed or could not be opened. You may need to whitelist *.console.azure.com . A more
detailed but longer approach is to whitelist the Microsoft
Azure Datacenter IP ranges, which change fairly regularly.
A "Forbidden" response was encountered when accessing this Ensure that boot diagnostics doesn't have an account firewall.
VM's boot diagnostic storage account. An accessible boot diagnostic storage account is necessary for
the serial console to function.
Known issues
We're aware of some issues with the serial console. Here's a list of these issues and steps for mitigation. These
issues and mitigations apply for both VMs and virtual machine scale set instances.
ISSUE MITIGATION
Pressing Enter after the connection banner does not cause a For more information, see Hitting enter does nothing. This
sign-in prompt to be displayed. issue can occur if you're running a custom VM, hardened
appliance, or GRUB config that causes Linux to fail to connect
to the serial port.
Serial console text only takes up a portion of the screen size Serial consoles do not support negotiating about window size
(often after using a text editor). (RFC 1073), which means that there will be no SIGWINCH
signal sent to update screen size and the VM will have no
knowledge of your terminal's size. Install xterm or a similar
utility to provide you with the resize command, and then
run resize .
Pasting long strings doesn't work. The serial console limits the length of strings pasted into the
terminal to 2048 characters to prevent overloading the serial
port bandwidth.
Serial console does not work with a storage account firewall. Serial console by design cannot work with storage account
firewalls enabled on the boot diagnostics storage account.

Q. How can I send feedback?
A. Provide feedback by creating a GitHub issue at https://aka.ms/serialconsolefeedback. Alternatively (less
preferred), you can send feedback via azserialhelp@microsoft.com or in the virtual machine category of
https://feedback.azure.com.
Q. Does the serial console support copy/paste?
A. Yes. Use Ctrl+Shift+C and Ctrl+Shift+V to copy and paste into the terminal.
Q. Can I use serial console instead of an SSH connection?
A. While this usage may seem technically possible, the serial console is intended to be used primarily as a
troubleshooting tool in situations where connectivity via SSH isn't possible. We recommend against using the
serial console as an SSH replacement for the following reasons:
The serial console doesn't have as much bandwidth as SSH. Because it's a text-only connection, more GUI-
heavy interactions are difficult.
Serial console access is currently possible only by using a username and password. Because SSH keys are far
more secure than username/password combinations, from a sign-in security perspective, we recommend SSH
over serial console.
Q. Who can enable or disable serial console for my subscription?
A. To enable or disable the serial console at a subscription-wide level, you must have write permissions to the
subscription. Roles that have write permission include administrator or owner roles. Custom roles can also have
write permissions.
Q. Who can access the serial console for my VM/virtual machine scale set?
A. You must have the Virtual Machine Contributor role or higher for a VM or virtual machine scale set to access
the serial console.
Q. My serial console isn't displaying anything, what do I do?
A. Your image is likely misconfigured for serial console access. For information about configuring your image to
enable the serial console, see Serial console Linux distribution availability.
Q. Is the serial console available for virtual machine scale sets?
A. Yes, it is! See Serial Console for Virtual Machine Scale Sets
Q. If I set up my VM or virtual machine scale set by using only SSH key authentication, can I still use
the serial console to connect to my VM/virtual machine scale set instance?
A. Yes. Because the serial console doesn't require SSH keys, you only need to set up a username/password
combination. You can do so by selecting Reset password in the Azure portal and using those credentials to sign
in to the serial console.
Next steps
Use the serial console to access GRUB and single user mode.
Use the serial console for NMI and SysRq calls.
Learn how to use the serial console to enable GRUB in various distros.
The serial console is also available for Windows VMs.
Learn more about boot diagnostics.
Use Serial Console to access GRUB and Single User
Mode
GRUB is the GRand Unified Bootloader, which is likely the first thing you will see when booting up a VM. Because
it displays before the operating system has started, it is not accessible via SSH. From GRUB you are able to
modify your boot configuration to boot into single user mode, among other things.
Single user mode is a minimal environment with minimal functionality. It can be useful for investigating boot
issues, filesystem issues, or network issues. Fewer services may run in the background, and, depending on the
runlevel, a filesystem may not even be automatically mounted.
Single user mode is also useful in situations where your VM may only be configured to accept SSH keys to log in.
In this case, you may be able to use single user mode to create an account with password authentication. Note
that the serial console service will only allow users with contributor level access or higher to access the serial
console of a VM.
To enter single user mode, you will need to enter GRUB when your VM is booting up, and modify the boot
configuration in GRUB. Detailed instructions for entering GRUB are below. In general, you may use the restart
button within the VM serial console to restart your VM and show GRUB if your VM has been configured to show
GRUB.
General GRUB access

To access GRUB, you will need to reboot your VM while keeping the serial console blade open. Some distros will
require keyboard input to show GRUB, while others will automatically show GRUB for a few seconds and allow
user keyboard input to cancel the timeout.
You will want to ensure that GRUB is enabled on your VM in order to be able to access single user mode.
Depending on your distro, there may be some setup work to ensure that GRUB is enabled. Distro-specific
information is available below and at this link.
Restart your VM to access GRUB in Serial Console
You can restart your VM within the serial console by navigating to the power button and clicking "Restart VM".
This will initiate a VM restart, and you will see a notification within the Azure portal regarding the restart.
Restarting your VM can also be done with a SysRq 'b' command if SysRq is enabled. Follow the distro-specific
instructions below to learn what to expect from GRUB when you reboot.
General Single User Mode access
Manual access to single user mode may be needed in situations where you have not configured an account with
password authentication. You will need to modify the GRUB configuration to manually enter single user mode.
Once you have done this, see Use Single User Mode to reset or add a password for further instructions.
In cases where the VM is unable to boot, distros will often automatically drop you into single user mode or
emergency mode. Others, however, require additional setup before they can drop you into single-user or
emergency mode automatically (such as setting up a root password).
Use Single User Mode to reset or add a password
Once you are in single user mode, do the following to add a new user with sudo privileges:
1. Run useradd <username> to add a user
2. Run sudo usermod -a -G sudo <username> to grant the new user root privileges
3. Use passwd <username> to set the password for the new user. You will then be able to log in as the new user
Access for Red Hat Enterprise Linux (RHEL)

RHEL will drop you into single user mode automatically if it cannot boot normally. However, if you have not set
up root access for single user mode, you will not have a root password and will be unable to log in. There is a
workaround (See 'Manually entering single user mode' below ), but the suggestion is to set up root access initially.
GRUB access in RHEL
RHEL comes with GRUB enabled out of the box. To enter GRUB, reboot your VM with sudo reboot and press
any key. You will see the GRUB screen show up.
Note: Red Hat also provides documentation for booting into Rescue Mode, Emergency Mode, Debug Mode,
and resetting the root password. Click here to access it.
Set up root access for single user mode in RHEL

Single-user mode in RHEL requires the root user to be enabled, which is disabled by default. If you have a need to
enable single user mode, use the following instructions:
1. Log in to the Red Hat system via SSH
2. Switch to root
3. Enable password for root user
passwd root (set a strong root password)
4. Ensure root user can only log in via ttyS0
edit /etc/ssh/sshd_config and ensure PermitRootLogIn is set to no
edit /etc/securetty file to only allow log in via ttyS0
Now if the system boots into single user mode you can log in via root password.
Alternatively for RHEL 7.4+ or 6.9+ you can enable single user mode in the GRUB prompts, see instructions here
Manually enter single user mode in RHEL
If you have set up GRUB and root access with the instructions above, then you can enter single user mode with
the following instructions:
1. Press 'Esc' while restarting the VM to enter GRUB
2. In GRUB, press 'e' to edit the selected OS you want to boot into (usually the first line)
3. Find the kernel line - in Azure, this will start with linux16
4. Press Ctrl + E to go to the end of the line

5. Add the following to the end of the line: systemd.unit=rescue.target
This will boot you into single user mode. If you want to use emergency mode, add
systemd.unit=emergency.target to the end of the line instead of systemd.unit=rescue.target
6. Press Ctrl + X to exit and reboot with the applied settings
7. You will be prompted for the administrator password before being able to enter single user mode - this is
the same password you created in the instructions above
Enter single user mode without root account enabled in RHEL

If you did not go through the steps above to enable the root user, you can still reset your root password. Use the
following instructions:
Note: If you are using SELinux, please ensure you have taken the additional steps described in the Red Hat
documentation here when resetting the root password.
1. Press 'Esc' while restarting the VM to enter GRUB

2. In GRUB, press 'e' to edit the selected OS you want to boot into (usually the first line)
3. Find the kernel line - in Azure, this will start with linux16
4. Add rd.break to the end of the line, ensuring there is a space before rd.break (see example below )
This will interrupt the boot process before control is passed from initramfs to systemd , as described
in the Red Hat documentation here.
5. Press Ctrl + X to exit and reboot with the applied settings
6. Once you boot, you will be dropped into emergency mode with a read-only file system. Enter
mount -o remount,rw /sysroot into the shell to remount the root file system with read/write permissions
7. Once you boot into single user mode, type in chroot /sysroot to switch into the sysroot jail
8. You are now root. You can reset your root password with passwd and then use the instructions above to enter
single user mode. Type reboot -f to reboot once you are done.
Note: Running through the instructions above will drop you into emergency shell, so you can also perform
tasks such as editing fstab . However, the generally accepted suggestion is to reset your root password and
use that to enter single user mode.
Access for CentOS

Much like Red Hat Enterprise Linux, single user mode in CentOS requires GRUB and the root user to be enabled.
GRUB access in CentOS
CentOS comes with GRUB enabled out of the box. To enter GRUB, reboot your VM with sudo reboot and press
any key. You will see the GRUB screen show up.
Single user mode in CentOS
Follow the instructions for RHEL above to enable single user mode in CentOS.
Access for Ubuntu
Ubuntu images do not require a root password. If the system boots into single user mode, you can use it without
additional credentials.
GRUB access in Ubuntu
To access GRUB, press and hold 'Esc' while the VM is booting up.
By default, Ubuntu images may not automatically show the GRUB screen. This can be changed with the following
instructions:
1. Open /etc/default/grub.d/50-cloudimg-settings.cfg in a text editor of your choice
2. Change the GRUB_TIMEOUT value to a non-zero value
3. Open /etc/default/grub in a text editor of your choice
4. Comment out the GRUB_HIDDEN_TIMEOUT=1 line
5. Run sudo update-grub
Single user mode in Ubuntu
Ubuntu will drop you into single user mode automatically if it cannot boot normally. To manually enter single user
mode, use the following instructions:
1. From GRUB, press 'e' to edit your boot entry (the Ubuntu entry)
2. Look for the line that starts with linux , then look for ro
3. Add single after ro , ensuring there is a space before and after single
4. Press Ctrl + X to reboot with these settings and enter single user mode
Using GRUB to invoke bash in Ubuntu
There may be situations (such as a forgotten root password) where you may still be unable to access single user
mode in your Ubuntu VM after trying the instructions above. You can also tell the kernel to run /bin/bash as init,
rather than the system init, which will give you a bash shell and allow for system maintenance. Use the following
instructions:
1. From GRUB, press 'e' to edit your boot entry (the Ubuntu entry)
2. Look for the line that starts with linux , then look for ro
3. Replace ro with rw init=/bin/bash
This will mount your filesystem as read-write and use /bin/bash as the init process
4. Press Ctrl + X to reboot with these settings
Access for CoreOS

Single user mode in CoreOS requires GRUB to be enabled.
GRUB access in CoreOS
To access GRUB, press any key when your VM is booting up.
Single user mode in CoreOS
CoreOS will drop you into single user mode automatically if it cannot boot normally. To manually enter single
user mode, use the following instructions:
1. From GRUB, press 'e' to edit your boot entry
2. Look for the line that starts with linux$ . There should be 2, encapsulated in different if/else clauses
3. Append coreos.autologin=ttyS0 to the end of both linux$ lines
4. Press Ctrl + X to reboot with these settings and enter single user mode
Access for SUSE SLES
Newer images of SLES 12 SP3+ allow access via the serial console in case the system boots into emergency
mode.
GRUB access in SUSE SLES
GRUB access in SLES requires bootloader configuration via YaST. To do this, follow these instructions:
1. ssh into your SLES VM and run sudo yast bootloader . Use the tab key, enter key, and arrow keys to
navigate through the menu.
2. Navigate to Kernel Parameters , and check Use serial console .
3. Add serial --unit=0 --speed=9600 --parity=no to the Console arguments
4. Press F10 to save your settings and exit
5. To enter GRUB, reboot your VM and press any key during boot sequence to make GRUB stay on screen
The default timeout for GRUB is 1s. You can modify this by changing the GRUB_TIMEOUT variable in
/etc/default/grub
Single user mode in SUSE SLES

You will be automatically dropped into emergency shell if SLES cannot boot normally. To manually enter the
emergency shell, use the following instructions:
1. From GRUB, press 'e' to edit your boot entry (the SLES entry)
2. Look for the kernel line it will start with linux
3. Append systemd.unit=emergency.target to the end of the line
4. Press Ctrl + X to reboot with these settings and enter emergency shell
Note that you will be dropped into emergency shell with a read -only filesystem. If you want to make
any edits to any files, you will need to remount the filesystem with read-write permissions. To do this,
enter mount -o remount,rw / into the shell
Access for Oracle Linux

Much like Red Hat Enterprise Linux, single user mode in Oracle Linux requires GRUB and the root user to be
enabled.
GRUB access in Oracle Linux
Oracle Linux comes with GRUB enabled out of the box. To enter GRUB, reboot your VM with sudo reboot and
press 'Esc'. You will see the GRUB screen show up.
Single user mode in Oracle Linux
Follow the instructions for RHEL above to enable single user mode in Oracle Linux.
Next steps
The main serial console Linux documentation page is located here.
Learn how to use Serial Console to enable GRUB in various distros
Use Serial Console for NMI and SysRq calls
The Serial Console is also available for Windows VMs
Learn more about boot diagnostics
Use Serial Console for SysRq and NMI calls
System Request (SysRq)

A SysRq is a sequence of keys understood by the Linux operation system kernel, which can trigger a set of pre-
defined actions. These commands are often used when virtual machine troubleshooting or recovery can't be
performed through traditional administration (for example, if the VM is not responding). Using the SysRq feature
of Azure Serial Console will mimic pressing of the SysRq key and characters entered on a physical keyboard.
Once the SysRq sequence is delivered, the kernel configuration will control how the system responds. For
information on enabling and disabling SysRq, see the SysRq Admin Guide text | markdown.
The Azure Serial Console can be used to send a SysRq to an Azure virtual machine using the keyboard icon in the
command bar shown below.
Choosing "Send SysRq Command" will open a dialog, which will provide common SysRq options or accept a
sequence of SysRq commands entered into the dialog. This allows for series of SysRq's to perform a high-level
operation such as a safe reboot using: REISUB .
The SysRq command can't be used on virtual machines that are stopped or whose kernel is in a non-responsive
state. (for example a kernel panic).
Enable SysRq
As described in the SysRq Admin Guide above, SysRq can be configured such that all, none, or only certain
commands are available. You can enable all SysRq commands using the step below but it will not survive a reboot:
echo "1" >/proc/sys/kernel/sysrq
To make the SysReq configuration persistent, you can do the following to enable all SysRq commands
1. Adding this line to /etc/sysctl.conf
kernel.sysrq = 1
2. Rebooting or updating sysctl by running
sysctl -p
Command Keys
From the SysRq Admin Guide above:
COMMAND FUNCTION
b Will immediately reboot the system without syncing or

unmounting your disks.
c Will perform a system crash by a NULL pointer dereference. A

crashdump will be taken if configured.
d Shows all locks that are held.
e Send a SIGTERM to all processes, except for init.
f Will call the oom killer to kill a memory hog process, but do
not panic if nothing can be killed.
g Used by kgdb (kernel debugger)
h Will display help (any other key than those listed here will also
display help, but h is easy to remember :-)
i Send a SIGKILL to all processes, except for init.
j Forcibly "Just thaw it" - filesystems frozen by the FIFREEZE

ioctl.
k Secure Access Key (SAK) Kills all programs on the current

virtual console. NOTE: See important comments below in SAK
section.
l Shows a stack backtrace for all active CPUs.
m Will dump current memory info to your console.
n Used to make RT tasks nice-able
o Will shut off your system (if configured and supported).
p Will dump the current registers and flags to your console.
q Will dump per CPU lists of all armed hrtimers (but NOT
regular timer_list timers) and detailed information about all
clockevent devices.
r Turns off keyboard raw mode and sets it to XLATE.
s Will attempt to sync all mounted filesystems.

COMMAND FUNCTION
t Will dump a list of current tasks and their information to your

console.
u Will attempt to remount all mounted filesystems read-only.
v Forcefully restores framebuffer console
v Causes ETM buffer dump [ARM-specific]
w Dumps tasks that are in uninterruptible (blocked) state.
x Used by xmon interface on ppc/powerpc platforms. Show

global PMU Registers on sparc64. Dump all TLB entries on
MIPS.
y Show global CPU Registers [SPARC-64 specific]
z Dump the ftrace buffer
0 - 9 Sets the console log level, controlling which kernel messages

will be printed to your console. ( 0 , for example would make
it so that only emergency messages like PANICs or OOPSes
would make it to your console.)
Distribution-specific documentation
For distribution-specific documentation on SysRq and steps to configure Linux to create a crash dump when it
receives a SysRq "Crash" command, see the links below:
Ubuntu
Kernel Crash Dump
Red Hat
What is the SysRq Facility and how do I use it?
How to use the SysRq facility to collect information from a RHEL server
SUSE
Configure kernel core dump capture
CoreOS
Collecting crash logs
Non-Maskable Interrupt (NMI)

A non-maskable interrupt (NMI) is designed to create a signal that software on a virtual machine will not ignore.
Historically, NMIs have been used to monitor for hardware issues on systems that required specific response
times. Today, programmers and system administrators often use NMI as a mechanism to debug or troubleshoot
systems that are not responding.
The Serial Console can be used to send a NMI to an Azure virtual machine using the keyboard icon in the
command bar shown below. Once the NMI is delivered, the virtual machine configuration will control how the
system responds. Linux operating systems can be configured to crash and create a memory dump the operating
system receives an NMI.
Enable NMI
For Linux systems which support sysctl for configuring kernel parameters, you can enable a panic when receiving
this NMI by using the following:
1. Adding this line to /etc/sysctl.conf
kernel.panic_on_unrecovered_nmi=1
2. Rebooting or updating sysctl by running
sysctl -p
For more information on Linux kernel configurations, including unknown_nmi_panic , panic_on_io_nmi , and
panic_on_unrecovered_nmi , see: Documentation for /proc/sys/kernel/*. For distribution-specific documentation on
NMI and steps to configure Linux to create a crash dump when it receives an NMI, see the links below:
Ubuntu
Kernel Crash Dump
Red Hat
What is an NMI and what can I use it for?
How can I configure my system to crash when NMI switch is pushed?
Crash Dump Admin Guide
SUSE
Configure kernel core dump capture
CoreOS
Collecting crash logs
Next steps
The main Serial Console Linux documentation page is located here.
Use Serial Console to boot into GRUB and enter single user mode
The Serial Console is also available for Windows VMs
Learn more about boot diagnostics
Azure Serial Console for Windows
The Serial Console in the Azure portal provides access to a text-based console for Windows virtual machines
(VMs) and virtual machine scale set instances. This serial connection connects to the COM1 serial port of the
VM or virtual machine scale set instance, providing access to it independent of the network or operating system
state. The serial console can only be accessed by using the Azure portal and is allowed only for those users who
have an access role of Contributor or higher to the VM or virtual machine scale set.
Serial Console works in the same manner for VMs and virtual machine scale set instances. In this doc, all
mentions to VMs will implicitly include virtual machine scale set instances unless otherwise stated.
For serial console documentation for Linux VMs and virtual machine scale set, see Azure Serial Console for
Linux.
NOTE
The Serial Console is generally available in global Azure regions. It is not yet available in Azure government or Azure China
clouds.
Prerequisites
Your VM or virtual machine scale set instance must use the resource management deployment model.
Classic deployments aren't supported.
Your account that uses serial console must have the Virtual Machine Contributor role for the VM and the
boot diagnostics storage account
Your VM or virtual machine scale set instance must have a password-based user. You can create one with
the reset password function of the VM access extension. Select Reset password from the Support +
troubleshooting section.
The VM in which you're accessing a serial console must have boot diagnostics enabled.
Get started with the serial console

The Serial Console for VMs and virtual machine scale set is accessible only through the Azure portal:
Serial Console for Virtual Machines
Serial Console for VMs is as straightforward as clicking on Serial console within the Support +
troubleshooting section in the Azure portal.
2. Navigate to All resources and select a Virtual Machine. The overview page for the VM opens.
3. Scroll down to the Support + troubleshooting section and select Serial console. A new pane with the
serial console opens and starts the connection.
Serial Console for Virtual Machine Scale Sets
Serial Console is available on a per-instance basis for virtual machine scale sets. You will have to navigate to the
individual instance of a virtual machine scale set before seeing the Serial console button. If your virtual
machine scale set does not have boot diagnostics enabled, ensure you update your virtual machine scale set
model to enable boot diagnostics, and then upgrade all instances to the new model in order to access serial
console.
2. Navigate to All resources and select a Virtual Machine Scale Set. The overview page for the virtual
machine scale set opens.
3. Navigate to Instances
4. Select a virtual machine scale set instance
5. From the Support + troubleshooting section, select Serial console. A new pane with the serial
console opens and starts the connection.
Enable Serial Console functionality

NOTE
If you are not seeing anything in the serial console, make sure that boot diagnostics is enabled on your VM or virtual
machine scale set.
Enable the serial console in custom or older images

Newer Windows Server images on Azure have Special Administrative Console (SAC ) enabled by default. SAC is
supported on server versions of Windows but isn't available on client versions (for example, Windows 10,
Windows 8, or Windows 7).
For older Windows Server images (created before February 2018), you can automatically enable the serial
console through the Azure portal's run command feature. In the Azure portal, select Run command, then select
the command named EnableEMS from the list.
Alternatively, to manually enable the serial console for Windows VMs/virtual machine scale set created before
February 2018, follow these steps:
1. Connect to your Windows virtual machine by using Remote Desktop
2. From an administrative command prompt, run the following commands:
bcdedit /ems {current} on
bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
3. Reboot the system for the SAC console to be enabled.
If needed, the SAC can be enabled offline as well:

1. Attach the windows disk for which you want SAC configured as a data disk to the existing VM.
bcdedit /store <mountedvolume>\boot\bcd /ems {default} on
bcdedit /store <mountedvolume>\boot\bcd /emssettings EMSPORT:1 EMSBAUDRATE:115200
How do I know if SAC is enabled?

If SAC isn't enabled, the serial console won't display the SAC prompt. In some cases, VM health information is
shown, and in other cases it's blank. If you're using a Windows Server image created before February 2018,
SAC probably won't be enabled.
Enable the Windows boot menu in the serial console
If you need to enable Windows boot loader prompts to display in the serial console, you can add the following
additional options to your boot configuration data. For more information, see bcdedit.
1. Connect to your Windows VM or virtual machine scale set instance by using Remote Desktop.
bcdedit /set {bootmgr} displaybootmenu yes
bcdedit /set {bootmgr} timeout 10
bcdedit /set {bootmgr} bootems yes
3. Reboot the system for the boot menu to be enabled
NOTE
The timeout that you set for the boot manager menu to display will impact your OS boot time. If you think the 10-second
timeout value is too short or too long, set it to a different value.
Use Serial Console

Use CMD or PowerShell in Serial Console
1. Connect to the serial console. If you successfully connect, the prompt is SAC>:
2. Enter cmd to create a channel that has a CMD instance.

3. Enter ch -si 1 to switch to the channel that's running the CMD instance.
4. Press Enter, and then enter sign-in credentials with administrative permissions.
5. After you've entered valid credentials, the CMD instance opens.
6. To start a PowerShell instance, enter PowerShell in the CMD instance, and then press Enter.
Use the serial console for NMI calls

A non-maskable interrupt (NMI) is designed to create a signal that software on a virtual machine won't ignore.
Historically, NMIs have been used to monitor for hardware issues on systems that required specific response
times. Today, programmers and system administrators often use NMI as a mechanism to debug or troubleshoot
systems that are not responding.
The serial console can be used to send an NMI to an Azure virtual machine by using the keyboard icon in the
command bar. After the NMI is delivered, the virtual machine configuration will control how the system
responds. Windows can be configured to crash and create a memory dump file when receiving an NMI.
For information on configuring Windows to create a crash dump file when it receives an NMI, see How to
generate a crash dump file by using an NMI.
Use function keys in serial console
Function keys are enabled for usage for serial console in Windows VMs. The F8 in the serial console dropdown
provides the convenience of easily entering the Advanced Boot Settings menu, but serial console is compatible
with all other function keys. You may need to press Fn + F1 (or F2, F3, etc.) on your keyboard depending on the
computer you are using serial console from.
Use WSL in serial console
The Windows Subsystem for Linux (WSL ) has been enabled for Windows Server 2019 or later, so it is also
possible to enable WSL for use within the serial console if you are running Windows Server 2019 or later. This
may be beneficial for users that also have a familiarity with Linux commands. For instructions to enable WSL for
Windows Server, see the Installation guide.
Restart your Windows VM/virtual machine scale set instance within Serial Console
You can initiate a restart within the serial console by navigating to the power button and clicking "Restart VM".
This will initiate a VM restart, and you will see a notification within the Azure portal regarding the restart.
This is useful in situations where you may want to access the boot menu without leaving the serial console
experience.
Disable serial console

By default, all subscriptions have serial console access enabled for all VMs. You can disable the serial console at
either the subscription level or the VM level.
VM/virtual machine scale set-level disable
The serial console can be disabled for a specific VM or virtual machine scale set by disabling the boot
diagnostics setting. Turn off boot diagnostics from the Azure portal to disable the serial console for the VM or
the virtual machine scale set. If you are using serial console on a virtual machine scale set, ensure you upgrade
your virtual machine scale set instances to the latest model.
NOTE
To enable or disable the serial console for a subscription, you must have write permissions to the subscription. These
permissions include, but are not limited to, administrator or owner roles. Custom roles can also have write permissions.
Subscription-level disable
The serial console can be disabled for an entire subscription through the Disable Console REST API call. This
action requires contributor level access or above to the subscription. You can use the Try It function available on
this API documentation page to disable and enable the serial console for a subscription. Enter your subscription
ID for subscriptionId, enter "default" for default, and then select Run. Azure CLI commands aren't yet
available.
To reenable serial console for a subscription, use the Enable Console REST API call.
Alternatively, you can use the following set of bash commands in Cloud Shell to disable, enable, and view the
disabled status of the serial console for a subscription:
To get the disabled status of the serial console for a subscription:
$ curl
"https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.SerialConsole/consol
eServices/default?api-version=2018-05-01" -H "Authorization: Bearer $ACCESSTOKEN" -H "Content-Type:
application/json" -H "Accept: application/json" -s | jq .properties
To disable the serial console for a subscription:
$ curl -X POST
eServices/default/disableConsole?api-version=2018-05-01" -H "Authorization: Bearer $ACCESSTOKEN" -H
To enable the serial console for a subscription:
$ curl -X POST
eServices/default/enableConsole?api-version=2018-05-01" -H "Authorization: Bearer $ACCESSTOKEN" -H
Serial console security

Access security
Access to the serial console is limited to users who have an access role of Virtual Machine Contributor or higher
to the virtual machine. If your Azure Active Directory tenant requires multi-factor authentication (MFA), then
access to the serial console will also need MFA because the serial console's access is through the Azure portal.
Channel security
All data that is sent back and forth is encrypted on the wire.
Audit logs
All access to the serial console is currently logged in the boot diagnostics logs of the virtual machine. Access to
these logs are owned and controlled by the Azure virtual machine administrator.
Cau t i on
No access passwords for the console are logged. However, if commands run within the console contain or
output passwords, secrets, user names, or any other form of personally identifiable information (PII), those will
be written to the VM boot diagnostics logs. They will be written along with all other visible text, as part of the
implementation of the serial console's scroll back function. These logs are circular and only individuals with read
permissions to the diagnostics storage account have access to them. However, we recommend following the
best practice of using the Remote Desktop for anything that may involve secrets and/or PII.
Concurrent usage
If a user is connected to the serial console and another user successfully requests access to that same virtual
machine, the first user will be disconnected and the second user connected to the same session.
Cau t i on
This means that a user who's disconnected won't be logged out. The ability to enforce a logout upon disconnect
(by using SIGHUP or similar mechanism) is still in the roadmap. For Windows, there's an automatic timeout
enabled in SAC; for Linux, you can configure the terminal timeout setting.
Accessibility
Accessibility is a key focus for the Azure serial console. To that end, we've ensured that the serial console is
accessible for the visual and hearing impaired, as well as people who might not be able to use a mouse.
Keyboard navigation
Use the Tab key on your keyboard to navigate in the serial console interface from the Azure portal. Your
location will be highlighted on screen. To leave the focus of the serial console window, press Ctrl+F6 on your
keyboard.
Use the serial console with a screen reader
The serial console has screen reader support built in. Navigating around with a screen reader turned on will
allow the alt text for the currently selected button to be read aloud by the screen reader.
Common scenarios for accessing the serial console

SCENARIO ACTIONS IN THE SERIAL CONSOLE
Incorrect firewall rules Access serial console and fix Windows firewall rules.
Filesystem corruption/check Access the serial console and recover the filesystem.
RDP configuration issues Access the serial console and change the settings. For more
information, see the RDP documentation.
Network lock down system Access the serial console from the Azure portal to manage
the system. Some network commands are listed in Windows
commands: CMD and PowerShell.
Interacting with bootloader Access BCD through the serial console. For information, see
Enable the Windows boot menu in the serial console.
Errors
Because most errors are transient, retrying your connection can often fix them. The following table shows a list
of errors and mitigations for both VMs and virtual machine scale set instances.
ERROR MITIGATION
Unable to retrieve boot diagnostics settings for Ensure that the VM has boot diagnostics enabled.
<VMNAME>. To use the serial console, ensure that boot
diagnostics is enabled for this VM.
The VM is in a stopped deallocated state. Start the VM and Virtual machine must be in a started state to access the
retry the serial console connection. serial console
You do not have the required permissions to use this VM Serial console access requires certain permissions. For more
serial console. Ensure you have at least Virtual Machine information, see Prerequisites.
Contributor role permissions.
ERROR MITIGATION
Unable to determine the resource group for the boot Serial console access requires certain permissions. For more
diagnostics storage account <STORAGEACCOUNTNAME>. information, see Prerequisites.
Verify that boot diagnostics is enabled for this VM and you
have access to this storage account.
A "Forbidden" response was encountered when accessing Ensure that boot diagnostics does not have an account
this VM's boot diagnostic storage account. firewall. An accessible boot diagnostic storage account is
necessary for the serial console to function.
Web socket is closed or could not be opened. You may need to whitelist *.console.azure.com . A more
detailed but longer approach is to whitelist the Microsoft
Azure Datacenter IP ranges, which change fairly regularly.
Only health information is shown when connecting to a This error occurs if the Special Administrative Console has
Windows VM not been enabled for your Windows image. See Enable the
serial console in custom or older images for instructions on
how to manually enable SAC on your Windows VM. For
more information, see Windows health signals.
Known issues
We're aware of some issues with the serial console. Here's a list of these issues and steps for mitigation. These
issues and mitigations apply for both VMs and virtual machine scale set instances.
ISSUE MITIGATION
Pressing Enter after the connection banner does not cause a For more information, see Hitting enter does nothing. This
sign-in prompt to be displayed. error can occur if you're running a custom VM, hardened
appliance, or boot config that causes Windows to fail to
properly connect to the serial port. This error will also occur
if you're running a Windows 10 client VM, because only
Windows Server VMs are configured to have EMS enabled.
Unable to type at SAC prompt if kernel debugging is RDP to VM and run bcdedit /debug {current} off from
enabled. an elevated command prompt. If you can't RDP, you can
instead attach the OS disk to another Azure VM and modify
it while attached as a data disk by running
bcdedit /store <drive letter of data
disk>:\boot\bcd /debug <identifier> off
, then swapping the disk back.
Pasting into PowerShell in SAC results in a third character if For a workaround, run Remove-Module PSReadLine to
the original content had a repeating character. unload the PSReadLine module from the current session.
This action will not delete or uninstall the module.
Some keyboard inputs produce strange SAC output (for VT100 escape sequences aren't supported by the SAC
example, [A, [3~). prompt.
Pasting long strings doesn't work. The serial console limits the length of strings pasted into the
terminal to 2048 characters to prevent overloading the serial
port bandwidth.
Serial console does not work with a storage account firewall. Serial console by design cannot work with storage account
firewalls enabled on the boot diagnostics storage account.
Q. How can I send feedback?
A. Provide feedback by creating a GitHub issue at https://aka.ms/serialconsolefeedback. Alternatively (less
preferred), you can send feedback via azserialhelp@microsoft.com or in the virtual machine category of
https://feedback.azure.com.
Q. Does the serial console support copy/paste?
A. Yes. Use Ctrl+Shift+C and Ctrl+Shift+V to copy and paste into the terminal.
Q. Who can enable or disable the serial console for my subscription?
A. To enable or disable the serial console at a subscription-wide level, you must have write permissions to the
subscription. Roles that have write permission include administrator or owner roles. Custom roles can also have
write permissions.
Q. Who can access the serial console for my VM?
A. You must have the Virtual Machine Contributor role or higher for a VM to access the VM's serial console.
Q. My serial console isn't displaying anything, what do I do?
A. Your image is likely misconfigured for serial console access. For information about configuring your image to
enable the serial console, see Enable the serial console in custom or older images.
Q. Is the serial console available for virtual machine scale sets?
A. At this time, access to the serial console for virtual machine scale set instances isn't supported.
Next steps
For an in-depth guide to CMD and PowerShell commands you can use in the Windows SAC, see Windows
commands: CMD and PowerShell.
The serial console is also available for Linux VMs.
Windows Commands - CMD and PowerShell
This section includes example commands for performing common tasks in scenarios where you may need to use
SAC to access your Windows VM, such as when you need to troubleshoot RDP connection failures.
SAC has been included in all versions of Windows since Windows Server 2003 but is disabled by default. SAC
relies on the sacdrv.sys kernel driver, the Special Administration Console Helper service ( sacsvr ), and the
sacsess.exe process. For more information, see Emergency Management Services Tools and Settings.
SAC allows you to connect to your running OS via serial port. When you launch CMD from SAC, sacsess.exe
launches cmd.exe within your running OS. You can see that in Task Manager if you RDP to your VM at the same
time you are connected to SAC via the serial console feature. The CMD you access via SAC is the same cmd.exe
you use when connected via RDP. All the same commands and tools are available, including the ability to launch
PowerShell from that CMD instance. That is a major difference between SAC and the Windows Recovery
Environment (WinRE ) in that SAC is letting you manage your running OS, where WinRE boots into a different,
minimal OS. While Azure VMs do not support the ability to access WinRE, with the serial console feature, Azure
VMs can be managed via SAC.
Because SAC is limited to an 80x24 screen buffer with no scroll back, add | more to commands to display the
output one page at a time. Use <spacebar> to see the next page, or <enter> to see the next line.
SHIFT+INSERT is the paste shortcut for the serial console window.
Because of SAC's limited screen buffer, longer commands may be easier to type out in a local text editor and then
pasted into SAC.
View and Edit Windows Registry Settings

Verify RDP is enabled
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fDenyTSConnections
The second key (under \Policies) will only exist if the relevant group policy setting is configured.
Enable RDP
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fDenyTSConnections /t REG_DWORD /d 0
The second key (under \Policies) would only be needed if the relevant group policy setting had been configured.
Value will be rewritten at next group policy refresh if it is configured in group policy.
Manage Windows Services

View service state
sc query termservice
View service logon account

sc qc termservice
Set service logon account

sc config termservice obj= "NT Authority\NetworkService"
A space is required after the equals sign.

Set service start type
sc config termservice start= demand
A space is required after the equals sign. Possible start values include boot , system , auto , demand , disabled ,
delayed-auto .
Set service dependencies

sc config termservice depend= RPCSS
A space is required after the equals sign.

Start service
net start termservice
or
sc start termservice
Stop service
net stop termservice
or
sc stop termservice
Manage Networking Features

Show NIC properties
Show IP properties
Show IPSec configuration

netsh nap client show configuration
Enable NIC
netsh interface set interface name="<interface name>" admin=enabled
Set NIC to use DHCP

netsh interface ip set address name="<interface name>" source=dhcp
For more information about netsh , click here.

Azure VMs should always be configured in the guest OS to use DHCP to obtain an IP address. The Azure static IP
setting still uses DHCP to give the static IP to the VM.
Ping
ping 8.8.8.8
Port ping
Install the telnet client
dism /online /Enable-Feature /FeatureName:TelnetClient
Test connectivity
telnet bing.com 80
To remove the telnet client

dism /online /Disable-Feature /FeatureName:TelnetClient
When limited to methods available in Windows by default, PowerShell can be a better approach for testing port
connectivity. See the PowerShell section below for examples.
Test DNS name resolution
nslookup bing.com
Show Windows Firewall rule

netsh advfirewall firewall show rule name="Remote Desktop - User Mode (TCP-In)"
Disable Windows Firewall

You can use this command when troubleshooting to temporarily rule out the Windows Firewall. It will be enable
on next restart or when you enable it using the command below. Do not stop the Windows Firewall service
(MPSSVC ) or Base Filtering Engine (BFE ) service as way to rule out the Windows Firewall. Stopping MPSSVC or
BFE will result in all connectivity being blocked.
Enable Windows Firewall
netsh advfirewall set allprofiles state on
Manage Users and Groups

Create local user account
net user /add <username> <password>
Add local user to local group

net localgroup Administrators <username> /add
Verify user account is enabled

net user <username> | find /i "active"
Azure VMs created from generalized image will have the local administrator account renamed to the name
specified during VM provisioning. So it will usually not be Administrator .
Enable user account
net user <username> /active:yes
View user account properties

net user <username>
Example lines of interest from a local admin account:

Account active Yes
Account expires Never
Password expires Never
Workstations allowed All

Logon hours allowed All
Local Group Memberships *Administrators
View local groups

net localgroup
Manage the Windows Event Log

Query event log errors
wevtutil qe system /c:10 /f:text /q:"Event[System[Level=2]]" | more
Change /c:10 to the desired number of events to return, or move it to return all events matching the filter.
Query event log by Event ID
wevtutil qe system /c:1 /f:text /q:"Event[System[EventID=11]]" | more
Query event log by Event ID and Provider

wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Microsoft-Windows-Hyper-V-Netvsc'] and
EventID=11]]" | more
Query event log by Event ID and Provider for the last 24 hours
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Microsoft-Windows-Hyper-V-Netvsc'] and
EventID=11 and TimeCreated[timediff(@SystemTime) <= 86400000]]]"
Use 604800000 to look back 7 days instead of 24 hours.

Query event log by Event ID, Provider, and EventData in the last 7 days
wevtutil qe security /c:1 /f:text /q:"Event[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and
EventID=4624 and TimeCreated[timediff(@SystemTime) <= 604800000]] and
EventData[Data[@Name='TargetUserName']='<username>']]" | more
View or Remove Installed Applications

List installed applications
wmic product get Name,InstallDate | sort /r | more
The sort /r sorts descending by install date to make it easy to see what was recently installed. Use <spacebar>
to advance to the next page of output, or <enter> to advance one line.
Uninstall an application
wmic path win32_product where name="<name>" call uninstall
Replace <name> with the name returned in the above command for the application you want to remove.
File System Management

Get file version
wmic datafile where "drive='C:' and path='\\windows\\system32\\drivers\\' and filename like 'netvsc%'" get
version /format:list
This example returns the file version of the virtual NIC driver, which is netvsc.sys, netvsc63.sys, or netvsc60.sys
depending on the Windows version.
Scan for system file corruption
sfc /scannow
See also Repair a Windows Image.

Scan for system file corruption
dism /online /cleanup-image /scanhealth
See also Repair a Windows Image.

Export file permissions to text file
icacls %programdata%\Microsoft\Crypto\RSA\MachineKeys /t /c > %temp%\MachineKeys_permissions_before.txt
Save file permissions to ACL file

icacls %programdata%\Microsoft\Crypto\RSA\MachineKeys /save %temp%\MachineKeys_permissions_before.aclfile /t
Restore file permissions from ACL file

icacls %programdata%\Microsoft\Crypto\RSA /save %temp%\MachineKeys_permissions_before.aclfile /t
The path when using /restore needs to be the parent folder of the folder you specified when using /save . In this
example, \RSA is the parent of the \MachineKeys folder specified in the /save example above.
Take NTFS ownership of a folder
takeown /f %programdata%\Microsoft\Crypto\RSA\MachineKeys /a /r
Grant NTFS permissions to a folder recursively

Manage Devices
Remove non-present PNP devices
%windir%\System32\RUNDLL32.exe %windir%\System32\pnpclean.dll,RunDLL_PnpClean /Devices /Maxclean
Manage Group Policy

Force group policy update
gpupdate /force /wait:-1
Miscellaneous Tasks
Show OS version
ver
or
wmic os get caption,version,buildnumber /format:list
or
systeminfo find /i "os name"
systeminfo | findstr /i /r "os.*version.*build"
View OS install date

systeminfo | find /i "original"
or
wmic os get installdate
View last boot time

systeminfo | find /i "system boot time"
View time zone

systeminfo | find /i "time zone"
or
wmic timezone get caption,standardname /format:list
Restart Windows
shutdown /r /t 0
Adding /f will force running applications to close without warning users.

Detect Safe Mode boot
bcdedit /enum | find /i "safeboot"
Windows Commands - PowerShell

To run PowerShell in SAC, after you reach a CMD prompt, type:
powershell <enter>
Cau t i on
Remove the PSReadLine module from the PowerShell session before running any other PowerShell commands.
There is a known issue where extra characters may be introduced in text pasted from the clipboard if PSReadLine
is running in a PowerShell session in SAC.
First check if PSReadLine is loaded. It is loaded by default on Windows Server 2016, Windows 10, and later
versions of Windows. It would only be present on earlier Windows versions if it had been manually installed.
If this command returns to a prompt with no output, then the module was not loaded and you can continue using
the PowerShell session in SAC as normal.
get-module psreadline
If the above command returns the PSReadLine module version, run the following command to unload it. This
command does not delete or uninstall the module, it only unloads it from the current PowerShell session.
View and Edit Windows Registry Settings

Verify RDP is enabled
get-itemproperty -path 'hklm:\system\curRentcontrolset\control\terminal server' -name 'fdenytsconNections'
get-itemproperty -path 'hklm:\software\policies\microsoft\windows nt\terminal services' -name

'fdenytsconNections'
The second key (under \Policies) will only exist if the relevant group policy setting is configured.
Enable RDP
set-itemproperty -path 'hklm:\system\curRentcontrolset\control\terminal server' -name 'fdenytsconNections' 0 -
type dword
set-itemproperty -path 'hklm:\software\policies\microsoft\windows nt\terminal services' -name

'fdenytsconNections' 0 -type dword
The second key (under \Policies) would only be needed if the relevant group policy setting had been configured.
Value will be rewritten at next group policy refresh if it is configured in group policy.
Manage Windows Services
View service details
get-wmiobject win32_service -filter "name='termservice'" | format-list
Name,DisplayName,State,StartMode,StartName,PathName,ServiceType,Status,ExitCode,ServiceSpecificExitCode,ProcessId
Get-Service can be used but doesn't include the service logon account. Get-WmiObject win32-service does.
Set service logon account
(get-wmiobject win32_service -filter "name='termservice'").Change($null,$null,$null,$null,$null,$false,'NT
Authority\NetworkService')
When using a service account other than NT AUTHORITY\LocalService , NT AUTHORITY\NetworkService , or

LocalSystem , specify the account password as the last (eighth) argument after the account name.
Set service startup type

set-service termservice -startuptype Manual
Set-service accepts Automatic , Manual , or Disabled for startup type.

Set service dependencies
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\TermService' -Name DependOnService -Value
@('RPCSS','TermDD')
Start service
start-service termservice
Stop service
stop-service termservice
Manage Networking Features

Show NIC properties
get-netadapter | where {$_.ifdesc.startswith('Microsoft Hyper-V Network Adapter')} | format-list
status,name,ifdesc,macadDresS,driverversion,MediaConNectState,MediaDuplexState
or
get-wmiobject win32_networkadapter -filter "servicename='netvsc'" | format-list netenabled,name,macaddress
Get-NetAdapter is available in 2012+, for 2008R2 use Get-WmiObject .

Show IP properties
get-wmiobject Win32_NetworkAdapterConfiguration -filter "ServiceName='netvsc'" | format-list
DNSHostName,IPAddress,DHCPEnabled,IPSubnet,DefaultIPGateway,MACAddress,DHCPServer,DNSServerSearchOrder
Enable NIC
get-netadapter | where {$_.ifdesc.startswith('Microsoft Hyper-V Network Adapter')} | enable-netadapter
or
(get-wmiobject win32_networkadapter -filter "servicename='netvsc'").enable()
Get-NetAdapter is available in 2012+, for 2008R2 use Get-WmiObject .

Set NIC to use DHCP
get-netadapter | where {$_.ifdesc.startswith('Microsoft Hyper-V Network Adapter')} | Set-NetIPInterface -DHCP
Enabled
(get-wmiobject Win32_NetworkAdapterConfiguration -filter "ServiceName='netvsc'").EnableDHCP()

Get-NetAdapter is available on 2012+. For 2008R2 use Get-WmiObject . Azure VMs should always be configured in
the guest OS to use DHCP to obtain an IP address. The Azure static IP setting still uses DHCP to give the IP to the
VM.
Ping
test-netconnection
or
get-wmiobject Win32_PingStatus -Filter 'Address="8.8.8.8"' | format-table -autosize
IPV4Address,ReplySize,ResponseTime
Test-Netconnectionwithout any parameters will try to ping internetbeacon.msedge.net . It is available on 2012+.

For 2008R2 use Get-WmiObject as in the second example.
Port Ping
test-netconnection -ComputerName bing.com -Port 80
or
(new-object Net.Sockets.TcpClient).BeginConnect('bing.com','80',$null,$null).AsyncWaitHandle.WaitOne(300)
Test-NetConnection is available on 2012+. For 2008R2 use Net.Sockets.TcpClient
Test DNS name resolution

resolve-dnsname bing.com
or
[System.Net.Dns]::GetHostAddresses('bing.com')
Resolve-DnsName is available on 2012+. For 2008R2 use System.Net.DNS .

Show Windows firewall rule by name
get-netfirewallrule -name RemoteDesktop-UserMode-In-TCP
Show Windows firewall rule by port

get-netfirewallportfilter | where {$_.localport -eq 3389} | foreach {Get-NetFirewallRule -Name $_.InstanceId} |
format-list Name,Enabled,Profile,Direction,Action
or
(new-object -ComObject hnetcfg.fwpolicy2).rules | where {$_.localports -eq 3389 -and $_.direction -eq 1} |
format-table Name,Enabled
Get-NetFirewallPortFilter is available on 2012+. For 2008R2 use the hnetcfg.fwpolicy2 COM object.
Disable Windows firewall
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
Set-NetFirewallProfile is available on 2012+. For 2008R2 use netsh advfirewall as referenced in the CMD
section above.
Manage Users and Groups

Create local user account
new-localuser <name>
Verify user account is enabled

(get-localuser | where {$_.SID -like "S-1-5-21-*-500"}).Enabled
or
(get-wmiobject Win32_UserAccount -Namespace "root\cimv2" -Filter "SID like 'S-1-5-%-500'").Disabled
Get-LocalUser is available on 2012+. For 2008R2 use Get-WmiObject . This example shows the built-in local
administrator account, which always has SID S-1-5-21-*-500 . Azure VMs created from generalized image will
have the local administrator account renamed to the name specified during VM provisioning. So it will usually not
be Administrator .
Add local user to local group
add-localgroupmember -group Administrators -member <username>
Enable local user account

get-localuser | where {$_.SID -like "S-1-5-21-*-500"} | enable-localuser
This example enables the built-in local administrator account, which always has SID S-1-5-21-*-500 . Azure VMs
created from generalized image will have the local administrator account renamed to the name specified during
VM provisioning. So it will usually not be Administrator .
View user account properties
get-localuser | where {$_.SID -like "S-1-5-21-*-500"} | format-list *
or
get-wmiobject Win32_UserAccount -Namespace "root\cimv2" -Filter "SID like 'S-1-5-%-500'" | format-list
Name,Disabled,Status,Lockout,Description,SID
Get-LocalUser is available on 2012+. For 2008R2 use Get-WmiObject . This example shows the built-in local
administrator account, which always has SID S-1-5-21-*-500 .
View local groups
(get-localgroup).name | sort (get-wmiobject win32_group).Name | sort
Get-LocalUser is available on 2012+. For 2008R2 use Get-WmiObject .
Manage the Windows Event Log

Query event log errors
get-winevent -logname system -maxevents 1 -filterxpath "*[System[Level=2]]" | more
Change /c:10 to the desired number of events to return, or move it to return all events matching the filter.
Query event log by Event ID
get-winevent -logname system -maxevents 1 -filterxpath "*[System[EventID=11]]" | more
Query event log by Event ID and Provider

get-winevent -logname system -maxevents 1 -filterxpath "*[System[Provider[@Name='Microsoft-Windows-Hyper-V-
Netvsc'] and EventID=11]]" | more
Query event log by Event ID and Provider for the last 24 hours
get-winevent -logname system -maxevents 1 -filterxpath "*[System[Provider[@Name='Microsoft-Windows-Hyper-V-
Netvsc'] and EventID=11 and TimeCreated[timediff(@SystemTime) <= 86400000]]]"
Use 604800000 to look back 7 days instead of 24 hours. |

Query event log by Event ID, Provider, and EventData in the last 7 days
get-winevent -logname system -maxevents 1 -filterxpath "*[System[Provider[@Name='Microsoft-Windows-Security-
Auditing'] and EventID=4624 and TimeCreated[timediff(@SystemTime) <= 604800000]] and
EventData[Data[@Name='TargetUserName']='<username>']]" | more
View or Remove Installed Applications
List installed software
get-wmiobject win32_product | select installdate,name | sort installdate -descending | more
Uninstall software
(get-wmiobject win32_product -filter "Name='<name>'").Uninstall()
File System Management

Get file version
(get-childitem $env:windir\system32\drivers\netvsc*.sys).VersionInfo.FileVersion
This example returns the file version of the virtual NIC driver, which is named netvsc.sys, netvsc63.sys, or
netvsc60.sys depending on the Windows version.
Download and extract file
$path='c:\bin';md $path;cd $path;(new-object net.webclient).downloadfile(
('htTp:/'+'/download.sysinternals.com/files/SysinternalsSuite.zip'),"$path\SysinternalsSuite.zip");(new-object
-com shelL.apPlication).namespace($path).CopyHere( (new-object -com
shelL.apPlication).namespace("$path\SysinternalsSuite.zip").Items(),16)
This example creates a c:\bin folder, then downloads and extracts the Sysinternals suite of tools into c:\bin .
Miscellaneous Tasks
Show OS version
get-wmiobject win32_operatingsystem | format-list caption,version,buildnumber
View OS install date

(get-wmiobject win32_operatingsystem).converttodatetime((get-wmiobject win32_operatingsystem).installdate)
View last boot time

(get-wmiobject win32_operatingsystem).lastbootuptime
View Windows uptime

"{0:dd}:{0:hh}:{0:mm}:{0:ss}.{0:ff}" -f ((get-date)-(get-wmiobject
win32_operatingsystem).converttodatetime((get-wmiobject win32_operatingsystem).lastbootuptime))
Returns uptime as <days>:<hours>:<minutes>:<seconds>:<milliseconds> , for example 49:16:48:00.00 .

Restart Windows
restart-computer
Adding -force will force running applications to close without warning users.
Instance Metadata
You can query Azure instance metadata from within your Azure VM to view details such as osType, Location,
vmSize, vmId, name, resourceGroupName, subscriptionId, privateIpAddress, and publicIpAddress.
Querying instance metadata requires healthy guest network connectivity, because it makes a REST call through
the Azure host to the instance metadata service. So if you are able to query instance metadata, that tells you the
guest is able to communicate over the network to an Azure-hosted service.
For more information, see Azure Instance Metadata service.
Instance metadata
$im = invoke-restmethod -headers @{"metadata"="true"} -uri http://169.254.169.254/metadata/instance?api-
version=2017-08-01 -method get
$im | convertto-json
OS Type (Instance Metadata)

$im.Compute.osType
Location (Instance Metadata)

$im.Compute.Location
Size (Instance Metadata)

$im.Compute.vmSize
VM ID (Instance Metadata)
$im.Compute.vmId
VM Name (Instance Metadata)

$im.Compute.name
Resource Group Name (Instance Metadata)

$im.Compute.resourceGroupName
Subscription ID (Instance Metadata)

$im.Compute.subscriptionId
Tags (Instance Metadata)

$im.Compute.tags
Placement Group ID (Instance Metadata)

$im.Compute.placementGroupId
Platform Fault Domain (Instance Metadata)

$im.Compute.platformFaultDomain
Platform Update Domain (Instance Metadata)

$im.Compute.platformUpdateDomain
IPv4 Private IP Address (Instance Metadata)

$im.network.interface.ipv4.ipAddress.privateIpAddress
IPv4 Public IP Address (Instance Metadata)

$im.network.interface.ipv4.ipAddress.publicIpAddress
IPv4 Subnet Address / Prefix (Instance Metadata)

$im.network.interface.ipv4.subnet.address
$im.network.interface.ipv4.subnet.prefix
IPv6 IP Address (Instance Metadata)

$im.network.interface.ipv6.ipAddress
MAC Address (Instance Metadata)

$im.network.interface.macAddress
Next steps
The main serial console Windows documentation page is located here.
The serial console is also available for Linux VMs.
Troubleshoot storage resource deletion errors
In certain scenarios, you may encounter one of the following errors occur while you are trying to delete an Azure
storage account, container, or blob in an Azure Resource Manager deployment:
Failed to delete storage account 'StorageAccountName'. Error: The storage account cannot be
deleted due to its artifacts being in use.
Failed to delete # out of # container(s):
vhds: There is currently a lease on the container and no lease ID was specified in the request.
Failed to delete # out of # blobs:
BlobName.vhd: There is currently a lease on the blob and no lease ID was specified in the request.
The VHDs used in Azure VMs are .vhd files stored as page blobs in a standard or premium storage account in
Azure. For more information about Azure disks, see our Introduction to managed disks.
Azure prevents deletion of a disk that is attached to a VM to prevent corruption. It also prevents deletion of
containers and storage accounts that have a page blob that is attached to a VM.
The process to delete a storage account, container, or blob when receiving one of these errors is:
1. Identify blobs attached to a VM
2. Delete VMs with attached OS disk
3. Detach all data disk(s) from remaining VM (s)
Retry deleting the storage account, container, or blob after these steps are completed.
Step 1: Identify blob attached to a VM

Scenario 1: Deleting a blob – identify attached VM
2. On the Hub menu, select All resources. Go to the storage account, under Blob Service select Containers,
and navigate to the blob to delete.
3. If the blob Lease State is Leased, then right-click and select Edit Metadata to open Blob metadata pane.
4. In Blob metadata pane, check and record the value for MicrosoftAzureCompute_VMName. This value is
the name of the VM that the VHD is attached to. (See important if this field does not exist)
5. In Blob metadata pane, check and record the value of MicrosoftAzureCompute_DiskType. This value
identifies if the attached disk is OS or data disk (See important if this field does not exist).
6. If the blob disk type is OSDisk follow Step 2: Delete VM to detach OS disk. Otherwise, if the blob disk type
is DataDisk follow the steps in Step 3: Detach data disk from the VM.
IMPORTANT
If MicrosoftAzureCompute_VMName and MicrosoftAzureCompute_DiskType do not appear in the blob metadata, it
indicates that the blob is explicitly leased and is not attached to a VM. Leased blobs cannot be deleted without breaking the
lease first. To break lease, right-click on the blob and select Break lease. Leased blobs that are not attached to a VM prevent
deletion of the blob, but do not prevent deletion of container or storage account.
Scenario 2: Deleting a container - identify all blob(s) within container that are attached to VMs
2. On the Hub menu, select All resources. Go to the storage account, under Blob Service select Containers,
and find the container to be deleted.
3. Click to open the container and the list of blobs inside it will appear. Identify all the blobs with Blob Type =
Page blob and Lease State = Leased from this list. Follow Scenario 1 to identify the VM associated with
each of these blobs.
4. Follow Step 2 and Step 3 to delete VM (s) with OSDisk and detach DataDisk.
Scenario 3: Deleting storage account - identify all blob(s) within storage account that are attached to VMs
2. On the Hub menu, select All resources. Go to the storage account, under Blob Service select Blobs.
3. In Containers pane, identify all containers where Lease State is Leased and follow Scenario 2 for each Leased
container.
4. Follow Step 2 and Step 3 to delete VM (s) with OSDisk and detach DataDisk.
Step 2: Delete VM to detach OS disk

If the VHD is an OS disk, you must delete the VM before the attached VHD can be deleted. No additional action
will be required for data disks attached to the same VM once these steps are completed:
2. On the Hub menu, select Virtual Machines.
3. Select the VM that the VHD is attached to.
4. Make sure that nothing is actively using the virtual machine, and that you no longer need the virtual machine.
5. At the top of the Virtual Machine details pane, select Delete, and then click Yes to confirm.
6. The VM should be deleted, but the VHD can be retained. However, the VHD should no longer be attached to a
VM or have a lease on it. It may take a few minutes for the lease to be released. To verify that the lease is
released, browse to the blob location and in the Blob properties pane, the Lease Status should be Available.
Step 3: Detach data disk from the VM

If the VHD is a data disk, detach the VHD from the VM to remove the lease:
2. On the Hub menu, select Virtual Machines.
3. Select the VM that the VHD is attached to.
4. Select Disks on the Virtual Machine details pane.
5. Select the data disk to be deleted the VHD is attached to. You can determine which blob is attached in the
disk by checking the URL of the VHD.
6. You can verify the blob location by clicking on the disk to check the path in VHD URI field.
7. Select Edit on the top of Disks pane.
8. Click detach icon of the data disk to be deleted.
9. Select Save. The disk is now detached from the VM, and the VHD is no longer leased. It may take a few
minutes for the lease to be released. To verify that the lease has been released, browse to the blob location
and in the Blob properties pane, the Lease Status value should be Unlocked or Available.
Troubleshoot classic storage resource deletion errors
This article provides troubleshooting guidance when one of the following errors occurs trying to delete Azure
classic storage account, container, or *.vhd page blob file.
This article only covers issues with classic storage resources. If a user deletes a classic virtual machine using the
Azure portal, PowerShell or CLI then the Disks aren't automatically deleted. The user gets the option to delete the
"Disk" resource. In case the option isn't selected, the "Disk" resource will prevent deletion of the storage account,
container and the actual *.vhd page blob file.
More information about Azure disks can be found here. Azure prevents deletion of a disk that is attached to a VM
to prevent corruption. It also prevents deletion of containers and storage accounts, which have a page blob that is
attached to a VM.
What is a "Disk"?
A "Disk" resource is used to mount a *.vhd page blob file to a virtual machine, as an OS disk or Data disk. An OS
disk or Data disk resource, until deleted, will continue to hold a lease on the *.vhd file. Any storage resource in the
path shown in below image can’t be deleted if a “Disk” resource points to it.
Steps while deleting a classic virtual machine

1. Delete the classic virtual machine.
2. If the “Disks” checkbox is selected, the disk lease (shown in image above) associated with the page blob
*.vhd is broken. The actual page blob *.vhd file will still exist in the storage account.
3. Once the disk(s) lease is broken, the page blob(s) itself can be deleted. A storage account or container can be
deleted once all "Disk" resource present in them are deleted.
NOTE
If user deletes the VM but not the VHD, storage charges will continue to accrue on the page blob *.vhd file. The charges will
be in line with the type of storage account, check the pricing page for more details. If user no longer intends to use the
VHD(s), delete it/them to avoid future charges.
Unable to delete storage account

When user tries to delete a classic storage account that is no longer needed, user may see the following behavior.
Azure portal
User navigates to the classic storage account on the Azure portal and clicks Delete, user will see the following
message:
With disk(s) “attached” to a virtual machine
With disk(s) "unattached" to a virtual machine
Azure PowerShell
User tries to delete a storage account, that is no longer being used, by using classic PowerShell cmdlets. User will
see the following message:
Remove-AzureStorageAccount -StorageAccountName myclassicaccount

Remove-AzureStorageAccount : BadRequest: Storage account myclassicaccount has some active image(s)
and/or disk(s), e.g.
myclassicaccount. Ensure these image(s) and/or disk(s) are removed before deleting this storage account.
Unable to delete storage container

When user tries to delete a classic storage blob container that is no longer needed, user may see the following
behavior.
Azure portal
Azure portal wouldn't allow the user to delete a container if a "Disk(s)" lease exists pointing to a *.vhd page blob file
in the container. It's by design to prevent accidental deletion of a vhd(s) file with Disk(s) lease on them.
Azure PowerShell
If the user chooses to delete using PowerShell, it will result in the following error.
Remove-AzureStorageContainer -Context $context -Name vhds

Remove-AzureStorageContainer : The remote server returned an error: (412) There is currently a lease on the
container and no lease ID was specified in the request.. HTTP Status Code: 412 - HTTP Error Message: There is
currently a lease on the container and no lease ID was specified in the request.
Unable to delete a vhd

After deleting the Azure virtual machine, user tries to delete the vhd file (page blob) and receive the message
below:
Azure portal
On the portal, there could be two experiences depending on the list of blobs selected for deletion.
1. If only “Leased” blobs are selected, then the Delete button doesn’t show up.
2. If a mix of “Leased” and “Available” blobs are selected, the “Delete” button shows up. But the “Delete”
operation will leave behind the page blobs, which have a Disk lease on them.
Azure PowerShell
If the user chooses to delete using PowerShell, it will result in the following error.
Remove-AzureStorageBlob -Context $context -Container vhds -Blob "classicvm -os-8698.vhd"

Remove-AzureStorageBlob : The remote server returned an error: (412) There is currently a lease on the blob
and no lease ID was specified in the request.. HTTP Status Code: 412 - HTTP Error Message: There is currently
a lease on the blob and no lease ID was specified in the request.
Resolution steps
To remove classic Disks
Follow these steps on the Azure portal:
1. Navigate to the Azure portal.
2. Navigate to the Disks(classic).
3. Click the Disks tab.
4. Select your data disk, then click Delete Disk.

5. Retry the Delete operation that previously failed.
6. A storage account or container can't be deleted as long as it has a single Disk.
To remove classic Images
Follow these steps on the Azure portal:
1. Navigate to the Azure portal.
2. Navigate to OS images (classic).
3. Delete the image.
4. Retry the Delete operation that previously failed.
5. A storage account or container can’t be deleted as long as it has a single Image.
Troubleshoot unexpected reboots of VMs with
attached VHDs
If an Azure Virtual Machine (VM ) has a large number of attached VHDs that are in the same storage account, you
may exceed the scalability targets for an individual storage account, causing the VM to reboot unexpectedly. Check
the minute metrics for the storage account (TotalRequests/TotalIngress/TotalEgress) for spikes that exceed the
scalability targets for a storage account. See Metrics show an increase in PercentThrottlingError for assistance in
determining whether throttling has occurred on your storage account.
In general, each individual input or output operation on a VHD from a Virtual Machine translates to Get Page or
Put Page operations on the underlying page blob. Therefore, you can use the estimated IOPS for your
environment to tune how many VHDs you can have in a single storage account based on the specific behavior of
your application. Microsoft recommends having 40 or fewer disks in a single storage account. See Azure Storage
Scalability and Performance Targets for details about scalability targets for storage accounts, in particular the total
request rate and the total bandwidth for the type of storage account you are using.
If you are exceeding the scalability targets for your storage account, place your VHDs in multiple storage accounts
to reduce the activity in each individual account.
Troubleshoot Azure Windows virtual machine
activation problems
If you have trouble when activating Azure Windows virtual machine (VM ) that is created from a custom image, you
can use the information provided in this document to troubleshoot the issue.
Understanding Azure KMS endpoints for Windows product activation

of Azure Virtual Machines
Azure uses different endpoints for KMS activation depending on the cloud region where the VM resides. When
using this troubleshooting guide, use the appropriate KMS endpoint that applies to your region.
Azure public cloud regions: kms.core.windows.net:1688
Azure China 21Vianet national cloud regions: kms.core.chinacloudapi.cn:1688
Azure Germany national cloud regions: kms.core.cloudapi.de:1688
Azure US Gov national cloud regions: kms.core.usgovcloudapi.net:1688
Symptom
When you try to activate an Azure Windows VM, you receive an error message resembles the following sample:
Error: 0xC004F074 The Software LicensingService reported that the computer could not be activated.
No Key ManagementService (KMS ) could be contacted. Please see the Application Event Log for
additional information.
Cause
Generally, Azure VM activation issues occur if the Windows VM is not configured by using the appropriate KMS
client setup key, or the Windows VM has a connectivity problem to the Azure KMS service (kms.core.windows.net,
port 1688).
Solution
NOTE
If you are using a site-to-site VPN and forced tunneling, see Use Azure custom routes to enable KMS activation with forced
tunneling.
If you are using ExpressRoute and you have a default route published, see Azure VM may fail to activate over ExpressRoute.
Step 1 Configure the appropriate KMS client setup key (for Windows Server 2016 and Windows Server 2012 R2)
For the VM that is created from a custom image of Windows Server 2016 or Windows Server 2012 R2, you must
configure the appropriate KMS client setup key for the VM.
This step does not apply to Windows 2012 or Windows 2008 R2. It uses the Automation Virtual Machine
Activation (AVMA) feature, which is supported only by Windows Server 2016 and Windows Server 2012 R2.
1. Run slmgr.vbs /dlv at an elevated command prompt. Check the Description value in the output, and then
determine whether it was created from retail (RETAIL channel) or volume (VOLUME_KMSCLIENT) license
media:
cscript c:\windows\system32\slmgr.vbs /dlv
2. If slmgr.vbs /dlv shows RETAIL channel, run the following commands to set the KMS client setup key for
the version of Windows Server being used, and force it to retry activation:
cscript c:\windows\system32\slmgr.vbs /ipk <KMS client setup key>
cscript c:\windows\system32\slmgr.vbs /ato
For example, for Windows Server 2016 Datacenter, you would run the following command:
cscript c:\windows\system32\slmgr.vbs /ipk CB7KF-BWN84-R7R2Y-793K2-8XDDG
Step 2 Verify the connectivity between the VM and Azure KMS service
1. Download and extract the PSping tool to a local folder in the VM that does not activate.
2. Go to Start, search on Windows PowerShell, right-click Windows PowerShell, and then select Run as
administrator.
3. Make sure that the VM is configured to use the correct Azure KMS server. To do this, run the following
command:
Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms

kms.core.windows.net:1688"
The command should return: Key Management Service machine name set to kms.core.windows.net:1688
successfully.
4. Verify by using Psping that you have connectivity to the KMS server. Switch to the folder where you
extracted the Pstools.zip download, and then run the following:
\psping.exe kms.core.windows.net:1688
In the second-to-last line of the output, make sure that you see: Sent = 4, Received = 4, Lost = 0 (0% loss).
If Lost is greater than 0 (zero), the VM does not have connectivity to the KMS server. In this situation, if the
VM is in a virtual network and has a custom DNS server specified, you must make sure that DNS server is
able to resolve kms.core.windows.net. Or, change the DNS server to one that does resolve
kms.core.windows.net.
Notice that if you remove all DNS servers from a virtual network, VMs use Azure’s internal DNS service.
This service can resolve kms.core.windows.net.
Also verify that the guest firewall has not been configured in a manner that would block activation attempts.
1. After you verify successful connectivity to kms.core.windows.net, run the following command at that
elevated Windows PowerShell prompt. This command tries activation multiple times.
1..12 | ForEach-Object { Invoke-Expression “$env:windir\system32\cscript.exe

$env:windir\system32\slmgr.vbs /ato” ; start-sleep 5 }
A successful activation returns information that resembles the following:
Activating Windows(R), ServerDatacenter edition (12345678-1234-1234-1234-12345678) … Product
activated successfully.
FAQ
I created the Windows Server 2016 from Azure Marketplace. Do I need to configure KMS key for activating the
Windows Server 2016?
No. The image in Azure Marketplace has the appropriate KMS client setup key already configured.
Does Windows activation work the same way regardless if the VM is using Azure Hybrid Use Benefit (HUB ) or
not?
Yes.
What happens if Windows activation period expires?
When the grace period has expired and Windows is still not activated, Windows Server 2008 R2 and later versions
of Windows will show additional notifications about activating. The desktop wallpaper remains black, and
Windows Update will install security and critical updates only, but not optional updates. See the Notifications
section at the bottom of the Licensing Conditions page.
Need help? Contact support.

If you still need help, contact support to get your issue resolved quickly.
Windows activation fails in forced tunneling scenario
This article describes how to resolve the KMS activation problem that you might experience when you enable
forced tunneling in site-to-site VPN connection or ExpressRoute scenarios.
Symptom
You enable forced tunneling on Azure virtual network subnets to direct all Internet-bound traffic back to your on-
premises network. In this scenario, the Azure virtual machines (VMs) that run Windows Server 2012 R2 (or later
versions of Windows) can successfully activate Windows. However, VMs that run earlier version of Windows fail to
activate Windows.
Cause
The Azure Windows VMs need to connect to the Azure KMS server for Windows activation. The activation
requires that the activation request come from an Azure public IP address. In the forced tunneling scenario, the
activation fails because the activation request comes from your on-premises network instead of from an Azure
public IP address.
Solution
To resolve this problem, use the Azure custom route to route activation traffic to the Azure KMS server.
The IP address of the KMS server for the Azure Global cloud is 23.102.135.246. Its DNS name is
kms.core.windows.net. If you use other Azure platforms such as Azure Germany, you must use the IP address of
the corresponding KMS server. For more information, see the following table:
PLATFORM KMS DNS KMS IP
Azure Global kms.core.windows.net 23.102.135.246
Azure Germany kms.core.cloudapi.de 51.4.143.248
Azure US Government kms.core.usgovcloudapi.net 23.97.0.13
Azure China 21Vianet kms.core.chinacloudapi.cn 42.159.7.249
To add the custom route, follow these steps:

For Resource Manager VMs
NOTE
This article has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which will
continue to receive bug fixes until at least December 2020. To learn more about the new Az module and AzureRM
compatibility, see Introducing the new Azure PowerShell Az module. For Az module installation instructions, see Install Azure
PowerShell.
1. Open Azure PowerShell, and then sign in to your Azure subscription.

# First, get the virtual network that hosts the VMs that have activation problems. In this case, we get
virtual network ArmVNet-DM in Resource Group ArmVNet-DM:
$vnet = Get-AzVirtualNetwork -ResourceGroupName "ArmVNet-DM" -Name "ArmVNet-DM"
# Next, create a route table and specify that traffic bound to the KMS IP (23.102.135.246) will go
directly out:
$RouteTable = New-AzRouteTable -Name "ArmVNet-DM-KmsDirectRoute" -ResourceGroupName "ArmVNet-DM" -

Location "centralus"
Add-AzRouteConfig -Name "DirectRouteToKMS" -AddressPrefix 23.102.135.246/32 -NextHopType Internet -

RouteTable $RouteTable
Set-AzRouteTable -RouteTable $RouteTable
3. Go to the VM that has activation problems. Use PsPing to test if it can reach the KMS server:
psping kms.core.windows.net:1688
4. Try to activate Windows, and see if the problem is resolved.

For Classic VMs
1. Open Azure PowerShell, and then sign in to your Azure subscription.
# First, create a new route table:

New-AzureRouteTable -Name "VNet-DM-KmsRouteGroup" -Label "Route table for KMS" -Location "Central US"
# Next, get the route table that was created:

$rt = Get-AzureRouteTable -Name "VNet-DM-KmsRouteTable"
# Next, create a route:

Set-AzureRoute -RouteTable $rt -RouteName "AzureKMS" -AddressPrefix "23.102.135.246/32" -NextHopType
Internet
# Apply the KMS route table to the subnet that hosts the problem VMs (in this case, we apply it to the
subnet that's named Subnet-1):
Set-AzureSubnetRouteTable -VirtualNetworkName "VNet-DM" -SubnetName "Subnet-1"
-RouteTableName "VNet-DM-KmsRouteTable"
3. Go to the VM that has activation problems. Use PsPing to test if it can reach the KMS server:
psping kms.core.windows.net:1688
4. Try to activate Windows, and see if the problem is resolved.
Next steps
KMS Client Setup Keys
Review and Select Activation Methods
Troubleshoot application connectivity issues on
virtual machines in Azure
There are various reasons when you cannot start or connect to an application running on an Azure virtual
machine (VM ). Reasons include the application not running or listening on the expected ports, the listening port
blocked, or networking rules not correctly passing traffic to the application. This article describes a methodical
approach to find and correct the problem.
If you are having issues connecting to your VM using RDP or SSH, see one of the following articles first:
Troubleshoot Remote Desktop connections to a Windows-based Azure Virtual Machine
Troubleshoot Secure Shell (SSH) connections to a Linux-based Azure virtual machine.
If you need more help at any point in this article, you can contact the Azure experts on the MSDN Azure and the
Stack Overflow forums. Alternatively, you can also file an Azure support incident. Go to the Azure support site and
select Get Support.
Quick-start troubleshooting steps

If you have problems connecting to an application, try the following general troubleshooting steps. After each
step, try connecting to your application again:
Restart the virtual machine
Recreate the endpoint / firewall rules / network security group (NSG ) rules
Resource Manager model - Manage Network Security Groups
Classic model - Manage Cloud Services endpoints
Connect from different location, such as a different Azure virtual network
Redeploy the virtual machine
Redeploy Windows VM
Redeploy Linux VM
Recreate the virtual machine
For more information, see Troubleshooting Endpoint Connectivity (RDP/SSH/HTTP, etc. failures).
Detailed troubleshooting overview

There are four main areas to troubleshoot the access of an application that is running on an Azure virtual machine.
1. The application running on the Azure virtual machine.
Is the application itself running correctly?
2. The Azure virtual machine.
Is the VM itself running correctly and responding to requests?
3. Azure network endpoints.
Cloud service endpoints for virtual machines in the Classic deployment model.
Network Security Groups and inbound NAT rules for virtual machines in Resource Manager
deployment model.
Can traffic flow from users to the VM/application on the expected ports?
4. Your Internet edge device.
Are firewall rules in place preventing traffic from flowing correctly?
For client computers that are accessing the application over a site-to-site VPN or ExpressRoute connection, the
main areas that can cause problems are the application and the Azure virtual machine.
To determine the source of the problem and its correction, follow these steps.
Step 1: Access application from target VM

Try to access the application with the appropriate client program from the VM on which it is running. Use the local
host name, the local IP address, or the loopback address (127.0.0.1).
For example, if the application is a web server, open a browser on the VM and try to access a web page hosted on
the VM.
If you can access the application, go to Step 2.
If you cannot access the application, verify the following settings:
The application is running on the target virtual machine.
The application is listening on the expected TCP and UDP ports.
On both Windows and Linux-based virtual machines, use the netstat -a command to show the active listening
ports. Examine the output for the expected ports on which your application should be listening. Restart the
application or configure it to use the expected ports as needed and try to access the application locally again.
Step 2: Access application from another VM in the same virtual

network
Try to access the application from a different VM but in the same virtual network, using the VM's host name or its
Azure-assigned public, private, or provider IP address. For virtual machines created using the classic deployment
model, do not use the public IP address of the cloud service.
For example, if the application is a web server, try to access a web page from a browser on a different VM in the
same virtual network.
If you can access the application, go to Step 3.
The host firewall on the target VM is allowing the inbound request and outbound response traffic.
Intrusion detection or network monitoring software running on the target VM is allowing the traffic.
Cloud Services endpoints or Network Security Groups are allowing the traffic:
Classic model - Manage Cloud Services endpoints
Resource Manager model - Manage Network Security Groups
A separate component running in your VM in the path between the test VM and your VM, such as a load
balancer or firewall, is allowing the traffic.
On a Windows-based virtual machine, use Windows Firewall with Advanced Security to determine whether the
firewall rules exclude your application's inbound and outbound traffic.
Step 3: Access application from outside the virtual network

Try to access the application from a computer outside the virtual network as the VM on which the application is
running. Use a different network as your original client computer.
For example, if the application is a web server, try to access the web page from a browser running on a computer
that is not in the virtual network.
For VMs created using the classic deployment model:
Verify that the endpoint configuration for the VM is allowing the incoming traffic, especially the protocol
(TCP or UDP ) and the public and private port numbers.
Verify that access control lists (ACLs) on the endpoint are not preventing incoming traffic from the
Internet.
For more information, see How to Set Up Endpoints to a Virtual Machine.
For VMs created using the Resource Manager deployment model:
Verify that the inbound NAT rule configuration for the VM is allowing the incoming traffic, especially the
protocol (TCP or UDP ) and the public and private port numbers.
Verify that Network Security Groups are allowing the inbound request and outbound response traffic.
For more information, see What is a network security group?
If the virtual machine or endpoint is a member of a load-balanced set:
Verify that the probe protocol (TCP or UDP ) and port number are correct.
If the probe protocol and port is different than the load-balanced set protocol and port:
Verify that the application is listening on the probe protocol (TCP or UDP ) and port number (use
netstat –a on the target VM ).
Verify that the host firewall on the target VM is allowing the inbound probe request and outbound
probe response traffic.
If you can access the application, ensure that your Internet edge device is allowing:
The outbound application request traffic from your client computer to the Azure virtual machine.
The inbound application response traffic from the Azure virtual machine.
Step 4 If you cannot access the application, use IP Verify to check the
settings.
For more information, see Azure network monitoring overview.
Troubleshoot Remote Desktop connections to a Windows-based Azure Virtual Machine
Troubleshoot Secure Shell (SSH) connections to a Linux-based Azure virtual machine
Troubleshoot Resource Manager deployment issues
with creating a new Linux virtual machine in Azure
When you try to create a new Azure Virtual Machine (VM ), the common errors you encounter are provisioning
failures or allocation failures.
A provisioning failure happens when the OS image fails to load either due to incorrect preparatory steps or
because of selecting the wrong settings during the image capture from the portal.
An allocation failure results when the cluster or region either does not have resources available or cannot
support the requested VM size.
Top issues
The following top issues may help resolve your issue. To start troubleshooting, review these steps:
The cluster cannot support the requested VM size
The cluster does not have free resources
For other VM deployment issues and questions, see Troubleshoot deploying Linux virtual machine issues in Azure.

contain detailed information on the process to follow.
Issue: Custom image; provisioning errors

Provisioning errors arise if you upload or capture a generalized VM image as a specialized VM image or vice versa.
The former will cause a provisioning timeout error and the latter will cause a provisioning failure. To deploy your
custom image without errors, you must ensure that the type of the image does not change during the capture
process.
The following table lists the possible combinations of generalized and specialized images, the error type you will
encounter and what you need to do to fix the errors.
The following table lists the possible upload and capture combinations of Linux generalized and specialized OS
images. The combinations that will process without any errors are indicated by a Y, and those that will throw errors
are indicated by an N. The causes and resolutions for the different errors you will run into are given below the
table.
OS UPLOAD SPEC. UPLOAD GEN. CAPTURE SPEC. CAPTURE GEN.
Linux gen. N1 Y N3 Y
Linux spec. Y N2 Y N4
Y: If the OS is Linux generalized, and it is uploaded and/or captured with the generalized setting, then there won’t
be any errors. Similarly, if the OS is Linux specialized, and it is uploaded and/or captured with the specialized
setting, then there won’t be any errors.
Upload Errors:
N 1: If the OS is Linux generalized, and it is uploaded as specialized, you will get a provisioning timeout error
because the VM is stuck at the provisioning stage.
N 2: If the OS is Linux specialized, and it is uploaded as generalized, you will get a provisioning failure error
because the new VM is running with the original computer name, username and password.
Resolution:
To resolve both these errors, upload the original VHD, available on premises, with the same setting as that for the
OS (generalized/specialized). To upload as generalized, remember to run -deprovision first.
Capture Errors:
N 3: If the OS is Linux generalized, and it is captured as specialized, you will get a provisioning timeout error
because the original VM is not usable as it is marked as generalized.
N 4: If the OS is Linux specialized, and it is captured as generalized, you will get a provisioning failure error because
the new VM is running with the original computer name, username and password. Also, the original VM is not
usable because it is marked as specialized.
Resolution:
To resolve both these errors, delete the current image from the portal, and recapture it from the current VHDs with
the same setting as that for the OS (generalized/specialized).
Issue: Custom/ gallery/ marketplace image; allocation failure

This error arises in situations when the new VM request is pinned to a cluster that either cannot support the VM
size being requested, or does not have available free space to accommodate the request.
Cause 1: The cluster cannot support the requested VM size.
Resolution 1:
If the size of the requested VM cannot be changed:
Stop all the VMs in the availability set. Click Resource groups > your resource group > Resources >
your availability set > Virtual Machines > your virtual machine > Stop.
After all the VMs stop, create the new VM in the desired size.
Start the new VM first, and then select each of the stopped VMs and click Start.
Cause 2: The cluster does not have free resources.
Resolution 2:
Retry the request at a later time.
If the new VM can be part of a different availability set
Create a new VM in a different availability set (in the same region).
Add the new VM to the same virtual network.
Next steps
If you encounter issues when you start a stopped Linux VM or resize an existing Linux VM in Azure, see
Troubleshoot Resource Manager deployment issues with restarting or resizing an existing Linux Virtual Machine in
Azure.
Troubleshoot deployment issues when creating a new
Windows VM in Azure
When you try to create a new Azure Virtual Machine (VM ), the common errors you encounter are provisioning
failures or allocation failures.
A provisioning failure happens when the OS image fails to load either due to incorrect preparatory steps or
because of selecting the wrong settings during the image capture from the portal.
An allocation failure results when the cluster or region either does not have resources available or cannot
support the requested VM size.
Top issues
For other VM deployment issues and questions, see Troubleshoot deploying Windows virtual machine issues in
Azure.

contain detailed information on the process to follow.
Issue: Custom image; provisioning errors

Provisioning errors arise if you upload or capture a generalized VM image as a specialized VM image or vice versa.
The former will cause a provisioning timeout error and the latter will cause a provisioning failure. To deploy your
custom image without errors, you must ensure that the type of the image does not change during the capture
process.
The following table lists the possible combinations of generalized and specialized images, the error type you will
encounter and what you need to do to fix the errors.
The following table lists the possible upload and capture combinations of Windows generalized (gen.) and
specialized (spec.) OS images. The combinations that will process without any errors are indicated by a Y, and
those that will throw errors are indicated by an N. The causes and resolutions for the different errors you will run
into are given below the table.
OS UPLOAD SPEC. UPLOAD GEN. CAPTURE SPEC. CAPTURE GEN.
Windows gen. N1 Y N3 Y
Windows spec. Y N2 Y N4
Y: If the OS is Windows generalized, and it is uploaded and/or captured with the generalized setting, then there
won’t be any errors. Similarly, if the OS is Windows specialized, and it is uploaded and/or captured with the
specialized setting, then there won’t be any errors.
Upload Errors:
N 1: If the OS is Windows generalized, and it is uploaded as specialized, you will get a provisioning timeout error
with the VM stuck at the OOBE screen.
N 2: If the OS is Windows specialized, and it is uploaded as generalized, you will get a provisioning failure error
with the VM stuck at the OOBE screen because the new VM is running with the original computer name, username
and password.
Resolution
To resolve both these errors, use Add-AzVhd to upload the original VHD, available on-premises, with the same
setting as that for the OS (generalized/specialized). To upload as generalized, remember to run sysprep first.
Capture Errors:
N 3: If the OS is Windows generalized, and it is captured as specialized, you will get a provisioning timeout error
because the original VM is not usable as it is marked as generalized.
N 4: If the OS is Windows specialized, and it is captured as generalized, you will get a provisioning failure error
because the new VM is running with the original computer name, username, and password. Also, the original VM
is not usable because it is marked as specialized.
Resolution
To resolve both these errors, delete the current image from the portal, and recapture it from the current VHDs with
the same setting as that for the OS (generalized/specialized).
Issue: Custom/gallery/marketplace image; allocation failure

This error arises in situations when the new VM request is pinned to a cluster that either cannot support the VM
size being requested, or does not have available free space to accommodate the request.
Cause 1: The cluster cannot support the requested VM size.
Resolution 1:
After all the VMs stop, create the new VM in the desired size.
Cause 2: The cluster does not have free resources.
Resolution 2:
Retry the request at a later time.
Create a new VM in a different availability set (in the same region).
Next steps
If you encounter issues when you start a stopped Windows VM or resize an existing Windows VM in Azure, see
Troubleshoot Resource Manager deployment issues with restarting or resizing an existing Windows Virtual
Machine in Azure.
Troubleshoot deploying Linux virtual machine issues
in Azure
To troubleshoot virtual machine (VM ) deployment issues in Azure, review the top issues for common failures and
resolutions.
Overflow forums. Alternatively, you can file an Azure support incident. Go to the Azure support site and select Get
Support.
Top issues

<properties supportTopicIds="123456789" resourceTags="windows" productPesIds="1234, 5678" />
After all the VMs stop, create the VM in the desired size.

Retry the request later.
Create a VM in a different availability set (in the same region).
How do I activate my monthly credit for Visual studio Enterprise

(BizSpark)
To activate your monthly credit, see this article.
Why can I not install the GPU driver for an Ubuntu NV VM?
Currently, Linux GPU support is only available on Azure NC VMs running Ubuntu Server 16.04 LTS. For more
information, see Set up GPU drivers for N -series VMs running Linux.
My drivers are missing for my Linux N-Series VM

Drivers for Linux-based VMs are located here.
I can’t find a GPU instance within my N-Series VM

To take advantage of the GPU capabilities of Azure N -series VMs running Windows Server 2016 or Windows
Server 2012 R2, you must install NVIDIA graphics drivers on each VM after deployment. Driver setup information
is available for Windows VMs and Linux VMs.
Is N-Series VMs available in my region?

You can check the availability from the Products available by region table, and pricing here.
I am not able to see VM Size family that I want when resizing my VM.
When a VM is running, it is deployed to a physical server. The physical servers in Azure regions are grouped in
clusters of common physical hardware. Resizing a VM that requires the VM to be moved to different hardware
clusters is different depending on which deployment model was used to deploy the VM.
VMs deployed in Classic deployment model, the cloud service deployment must be removed and
redeployed to change the VMs to a size in another size family.
VMs deployed in Resource Manager deployment model, you must stop all VMs in the availability set before
changing the size of any VM in the availability set.
The listed VM size is not supported while deploying in Availability Set.

Choose a size that is supported on the availability set's cluster. It is recommended when creating an availability set
to choose the largest VM size you think you need, and have that be your first deployment to the Availability set.
What Linux distributions/versions are supported on Azure?

You can find the list at Linux on Azure-Endorsed Distributions.
Can I add an existing Classic VM to an availability set?

Yes. You can add an existing classic VM to a new or existing Availability Set. For more information see Add an
existing virtual machine to an availability set.
Next steps
Overflow forums.
Troubleshoot deploying Windows virtual machine
issues in Azure
To troubleshoot virtual machine (VM ) deployment issues in Azure, review the top issues for common failures and
resolutions.
Overflow forums. Alternatively, you can file an Azure support incident. Go to the Azure support site and select Get
Support.
Top issues

After all the VMs stop, create the VM in the desired size.

Retry the request later.
Create a VM in a different availability set (in the same region).
How can I use and deploy a windows client image into Azure?
You can use Windows 7, Windows 8, or Windows 10 in Azure for dev/test scenarios if you have an appropriate
Visual Studio (formerly MSDN ) subscription. This article outlines the eligibility requirements for running Windows
client in Azure and uses of the Azure Gallery images.
How can I deploy a virtual machine using the Hybrid Use Benefit
(HUB)?
There are a couple of different ways to deploy Windows virtual machines with the Azure Hybrid Use Benefit.
For an Enterprise Agreement subscription:
• Deploy VMs from specific Marketplace images that are pre-configured with Azure Hybrid Use Benefit.
For Enterprise agreement:
• Upload a custom VM and deploy using a Resource Manager template or Azure PowerShell.
For more information, see the following resources:
Azure Hybrid Use Benefit overview
Downloadable FAQ
Azure Hybrid Use Benefit for Windows Server and Windows Client.
How can I use the Hybrid Use Benefit in Azure
How do I activate my monthly credit for Visual studio Enterprise

(BizSpark)
To activate your monthly credit, see this article.
How to add Enterprise Dev/Test to my Enterprise Agreement (EA) to

get access to Window client images?
The ability to create subscriptions based on the Enterprise Dev/Test offer is restricted to Account Owners who have
been given permission to do so by an Enterprise Administrator. The Account Owner creates subscriptions via the
Azure Account Portal, and then should add active Visual Studio subscribers as co-administrators. So that they can
manage and use the resources needed for development and testing. For more information, see Enterprise
Dev/Test.
My drivers are missing for my Windows N-Series VM

Drivers for Windows-based VMs are located here.
I can’t find a GPU instance within my N-Series VM

To take advantage of the GPU capabilities of Azure N -series VMs running Windows Server 2016 or Windows
Server 2012 R2, you must install NVIDIA graphics drivers on each VM after deployment. Driver setup information
is available for Windows VMs and Linux VMs.
Is N-Series VMs available in my region?

You can check the availability from the Products available by region table, and pricing here.
What client images can I use and deploy in Azure, and how to I get
them?
You can use Windows 7, Windows 8, or Windows 10 in Azure for dev/test scenarios provided you have an
appropriate Visual Studio (formerly MSDN ) subscription.
Windows 10 images are available from the Azure Gallery within eligible dev/test offers.
Visual Studio subscribers within any type of offer can also adequately prepare and create a 64-bit Windows 7,
Windows 8, or Windows 10 image and then upload to Azure. The use remains limited to dev/test by active
Visual Studio subscribers.
This article outlines the eligibility requirements for running Windows client in Azure and use of the Azure Gallery
images.
I am not able to see VM Size family that I want when resizing my VM.
When a VM is running, it is deployed to a physical server. The physical servers in Azure regions are grouped in
clusters of common physical hardware. Resizing a VM that requires the VM to be moved to different hardware
clusters is different depending on which deployment model was used to deploy the VM.
VMs deployed in Classic deployment model, the cloud service deployment must be removed and
redeployed to change the VMs to a size in another size family.
VMs deployed in Resource Manager deployment model, you must stop all VMs in the availability set before
changing the size of any VM in the availability set.
The listed VM size is not supported while deploying in Availability Set.

Choose a size that is supported on the availability set's cluster. It is recommended when creating an availability set
to choose the largest VM size you think you need, and have that be your first deployment to the Availability set.
Can I add an existing Classic VM to an availability set?

Yes. You can add an existing classic VM to a new or existing Availability Set. For more information see Add an
existing virtual machine to an availability set.
Next steps
Overflow forums.
Troubleshoot Linux VM device name changes
This article explains why device names change after you restart a Linux VM or reattach the data disks. The article
also provides solutions for this problem.
Symptoms
You may experience the following problems when running Linux VMs in Microsoft Azure:
The VM fails to boot after a restart.
When data disks are detached and reattached, the disk device names are changed.
An application or script that references a disk by using the device name fails because the device name has
changed.
Cause
Device paths in Linux aren't guaranteed to be consistent across restarts. Device names consist of major numbers
(letters) and minor numbers. When the Linux storage device driver detects a new device, the driver assigns major
and minor numbers from the available range to the device. When a device is removed, the device numbers are
freed for reuse.
The problem occurs because device scanning in Linux is scheduled by the SCSI subsystem to happen
asynchronously. As a result, a device path name can vary across restarts.
Solution
To resolve this problem, use persistent naming. There are four ways to use persistent naming: by filesystem label,
by UUID, by ID, or by path. We recommend using the filesystem label or UUID for Azure Linux VMs.
Most distributions provide the fstab nofail or nobootwait parameters. These parameters enable a system to
boot when the disk fails to mount at startup. Check your distribution documentation for more information about
these parameters. For information on how to configure a Linux VM to use a UUID when you add a data disk, see
Connect to the Linux VM to mount the new disk.
When the Azure Linux agent is installed on a VM, the agent uses Udev rules to construct a set of symbolic links
under the /dev/disk/azure path. Applications and scripts use Udev rules to identify disks that are attached to the
VM, along with the disk type and disk LUNs.
If you have already edited your fstab in such a way that your VM is not booting and you are unable to SSH to your
VM, you can use the VM Serial Console to enter single user mode and modify your fstab.
Identify disk LUNs
Applications use LUNs to find all of the attached disks and to construct symbolic links. The Azure Linux agent
includes Udev rules that set up symbolic links from a LUN to the devices:
$ tree /dev/disk/azure
/dev/disk/azure
├── resource -> ../../sdb
├── resource-part1 -> ../../sdb1
├── root -> ../../sda
├── root-part1 -> ../../sda1
└── scsi1
├── lun0 -> ../../../sdc
├── lun0-part1 -> ../../../sdc1
├── lun1 -> ../../../sdd
├── lun1-part1 -> ../../../sdd1
├── lun1-part2 -> ../../../sdd2
└── lun1-part3 -> ../../../sdd3
LUN information from the Linux guest account is retrieved by using lsscsi or a similar tool:
$ sudo lsscsi
[1:0:0:0] cd/dvd Msft Virtual CD/ROM 1.0 /dev/sr0
[2:0:0:0] disk Msft Virtual Disk 1.0 /dev/sda
[3:0:1:0] disk Msft Virtual Disk 1.0 /dev/sdb
[5:0:0:0] disk Msft Virtual Disk 1.0 /dev/sdc
[5:0:0:1] disk Msft Virtual Disk 1.0 /dev/sdd
The guest LUN information is used with Azure subscription metadata to locate the VHD in Azure Storage that
contains the partition data. For example, you can use the az CLI:
$ az vm show --resource-group testVM --name testVM | jq -r .storageProfile.dataDisks

[
{
"caching": "None",
"createOption": "empty",
"diskSizeGb": 1023,
"image": null,
"lun": 0,
"managedDisk": null,
"name": "testVM-20170619-114353",
"vhd": {
"uri": "https://testVM.blob.core.windows.net/vhd/testVM-20170619-114353.vhd"
}
},
{
"caching": "None",
"createOption": "empty",
"diskSizeGb": 512,
"image": null,
"lun": 1,
"managedDisk": null,
"name": "testVM-20170619-121516",
"vhd": {
"uri": "https://testVM.blob.core.windows.net/vhd/testVM-20170619-121516.vhd"
}
}
]
Discover filesystem UUIDs by using blkid

Applications and scripts read the output of blkid , or similar sources of information, to construct symbolic links in
the /dev path. The output shows the UUIDs of all disks that are attached to the VM and their associated device file:
$ sudo blkid -s UUID
/dev/sr0: UUID="120B021372645f72"
/dev/sda1: UUID="52c6959b-79b0-4bdd-8ed6-71e0ba782fb4"
/dev/sdb1: UUID="176250df-9c7c-436f-94e4-d13f9bdea744"
/dev/sdc1: UUID="b0048738-4ecc-4837-9793-49ce296d2692"
The Azure Linux agent Udev rules construct a set of symbolic links under the /dev/disk/azure path:
$ ls -l /dev/disk/azure
total 0
lrwxrwxrwx 1 root root 9 Jun 2 23:17 resource -> ../../sdb
lrwxrwxrwx 1 root root 10 Jun 2 23:17 resource-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 9 Jun 2 23:17 root -> ../../sda
lrwxrwxrwx 1 root root 10 Jun 2 23:17 root-part1 -> ../../sda1
Applications use the links to identify the boot disk device and the resource (ephemeral) disk. In Azure, applications
should look in the /dev/disk/azure/root-part1 or /dev/disk/azure-resource-part1 paths to discover these partitions.
Any additional partitions from the blkid list reside on a data disk. Applications maintain the UUID for these
partitions and use a path to discover the device name at runtime:
$ ls -l /dev/disk/by-uuid/b0048738-4ecc-4837-9793-49ce296d2692
lrwxrwxrwx 1 root root 10 Jun 19 15:57 /dev/disk/by-uuid/b0048738-4ecc-4837-9793-49ce296d2692 -> ../../sdc1
Get the latest Azure Storage rules

To get the latest Azure Storage rules, run the following commands:
# sudo curl -o /etc/udev/rules.d/66-azure-storage.rules

https://raw.githubusercontent.com/Azure/WALinuxAgent/master/config/66-azure-storage.rules
# sudo udevadm trigger --subsystem-match=block
See also
For more information, see the following articles:
Ubuntu: Using UUID
Red Hat: Persistent naming
Linux: What UUIDs can do for you
Udev: Introduction to device management in a modern Linux system
Troubleshoot a Windows VM by attaching the OS
disk to a recovery VM using Azure PowerShell
If your Windows virtual machine (VM ) in Azure encounters a boot or disk error, you may need to perform
troubleshooting steps on the disk itself. A common example would be a failed application update that prevents the
VM from being able to boot successfully. This article details how to use Azure PowerShell to connect the disk to
another Windows VM to fix any errors, then repair your original VM.
IMPORTANT
The scripts in this article only apply to the VMs that use Managed Disk.
NOTE
PowerShell.
Recovery process overview

We can now use Azure PowerShell to change the OS disk for a VM. We no longer need to delete and recreate the
VM.
The troubleshooting process is as follows:
1. Stop the affected VM.
2. Create a snapshot from the OS Disk of the VM.
3. Create a disk from the OS disk snapshot.
4. Attach the disk as a data disk to a recovery VM.
5. Connect to the recovery VM. Edit files or run any tools to fix issues on the copied OS disk.
6. Unmount and detach disk from recovery VM.
7. Change the OS disk for the affected VM.
You can use the VM recovery scripts to automate steps 1, 2, 3, 4, 6, and 7. For more documentation and
instructions, see VM Recovery Scripts for Resource Manager VM.
Make sure that you have the latest Azure PowerShell installed and logged in to your subscription:
Connect-AzAccount
In the following examples, replace the parameter names with your own values.
Determine boot issues

You can view a screenshot of your VM in Azure to help troubleshoot boot issues. This screenshot can help identify
why a VM fails to boot. The following example gets the screenshot from the Windows VM named myVM in the
resource group named myResourceGroup :
Get-AzVMBootDiagnosticsData -ResourceGroupName myResourceGroup `

-Name myVM -Windows -LocalPath C:\Users\ops\
Review the screenshot to determine why the VM is failing to boot. Note any specific error messages or error codes
provided.
Stop the VM
The following example stops the VM named myVM from the resource group named myResourceGroup :
Stop-AzVM -ResourceGroupName "myResourceGroup" -Name "myVM"
Wait until the VM has finished deleting before you process to the next step.
Create a snapshot from the OS Disk of the VM

The following example creates a snapshot with name mySnapshot from the OS disk of the VM named `myVM'.
$resourceGroupName = 'myResourceGroup'
$location = 'eastus'
$vmName = 'myVM'
$snapshotName = 'mySnapshot'
#Get the VM
$vm = get-azvm `
-ResourceGroupName $resourceGroupName `
-Name $vmName
#Create the snapshot configuration for the OS disk

$snapshot = New-AzSnapshotConfig `
-SourceUri $vm.StorageProfile.OsDisk.ManagedDisk.Id `
-Location $location `
-CreateOption copy
#Take the snapshot

New-AzSnapshot `
-Snapshot $snapshot `
-SnapshotName $snapshotName `
-ResourceGroupName $resourceGroupName
A snapshot is a full, read-only copy of a VHD. It cannot be attached to a VM. In the next step, we will create a disk
from this snapshot.
Create a disk from the snapshot

This script creates a managed disk with name newOSDisk from the snapshot named mysnapshot .
#Set the context to the subscription Id where Managed Disk will be created
#You can skip this step if the subscription is already selected
$subscriptionId = 'yourSubscriptionId'
Select-AzSubscription -SubscriptionId $SubscriptionId
#Provide the name of your resource group

$resourceGroupName ='myResourceGroup'
#Provide the name of the snapshot that will be used to create Managed Disks
$snapshotName = 'mySnapshot'
#Provide the name of the Managed Disk

$diskName = 'newOSDisk'
#Provide the size of the disks in GB. It should be greater than the VHD file size.
$diskSize = '128'
#Provide the storage type for Managed Disk. PremiumLRS or StandardLRS.

$storageType = 'StandardLRS'
#Provide the Azure region (e.g. westus) where Managed Disks will be located.
#This location should be same as the snapshot location
#Get all the Azure location using command below:
#Get-AzLocation
$location = 'eastus'
$snapshot = Get-AzSnapshot -ResourceGroupName $resourceGroupName -SnapshotName $snapshotName
$diskConfig = New-AzDiskConfig -AccountType $storageType -Location $location -CreateOption Copy -

SourceResourceId $snapshot.Id
New-AzDisk -Disk $diskConfig -ResourceGroupName $resourceGroupName -DiskName $diskName
Now you have a copy of the original OS disk. You can mount this disk to another Windows VM for
troubleshooting purposes.
Attach the disk to another Windows VM for troubleshooting

Now we attach the copy of the original OS disk to a VM as a data disk. This process allows you to correct
configuration errors or review additional application or system log files in the disk. The following example attaches
the disk named newOSDisk to the VM named RecoveryVM .
NOTE
To attach the disk, the copy of the original OS disk and the recovery VM must be in the same location.
$rgName = "myResourceGroup"
$vmName = "RecoveryVM"
$location = "eastus"
$dataDiskName = "newOSDisk"
$disk = Get-AzDisk -ResourceGroupName $rgName -DiskName $dataDiskName
$vm = Get-AzVM -Name $vmName -ResourceGroupName $rgName
$vm = Add-AzVMDataDisk -CreateOption Attach -Lun 0 -VM $vm -ManagedDiskId $disk.Id
Update-AzVM -VM $vm -ResourceGroupName $rgName

Connect to the recovery VM and fix issues on the attached disk
1. RDP to your recovery VM using the appropriate credentials. The following example downloads the RDP
connection file for the VM named RecoveryVM in the resource group named myResourceGroup , and
downloads it to C:\Users\ops\Documents "
Get-AzRemoteDesktopFile -ResourceGroupName "myResourceGroup" -Name "RecoveryVM" `

-LocalPath "C:\Users\ops\Documents\myVMRecovery.rdp"
2. The data disk should be automatically detected and attached. View the list of attached volumes to determine
the drive letter as follows:
Get-Disk
The following example output shows the disk connected a disk 2. (You can also use Get-Volume to view the
drive letter):
Number Friendly Name Serial Number HealthStatus OperationalStatus Total Size

Partition
Style
------ ------------- ------------- ------------ ----------------- ---------- ----------
0 Virtual HD Healthy Online 127 GB MBR
2 newOSDisk Healthy Online 127 GB MBR
After the copy of the original OS disk is mounted, you can perform any maintenance and troubleshooting steps as
needed. Once you have addressed the issues, continue with the following steps.
Unmount and detach original OS disk

Once your errors are resolved, you unmount and detach the existing disk from your recovery VM. You cannot use
your disk with any other VM until the lease attaching the disk to the recovery VM is released.
1. From within your RDP session, unmount the data disk on your recovery VM. You need the disk number
from the previous Get-Disk cmdlet. Then, use Set-Disk to set the disk as offline:
Set-Disk -Number 2 -IsOffline $True
Confirm the disk is now set as offline using Get-Disk again. The following example output shows the disk is
now set as offline:
Number Friendly Name Serial Number HealthStatus OperationalStatus Total Size Partition
Style
------ ------------- ------------- ------------ ----------------- ---------- ----------
2 Msft Virtu... Healthy Offline 127 GB MBR
2. Exit your RDP session. From your Azure PowerShell session, remove the disk named newOSDisk from the
VM named 'RecoveryVM'.
$myVM = Get-AzVM -ResourceGroupName "myResourceGroup" -Name "RecoveryVM"
Remove-AzVMDataDisk -VM $myVM -Name "newOSDisk"
Update-AzVM -ResourceGroup "myResourceGroup" -VM $myVM
Change the OS disk for the affected VM

You can use Azure PowerShell to swap the OS disks. You don't have to delete and recreate the VM.
This example stops the VM named myVM and assigns the disk named newOSDisk as the new OS disk.
# Get the VM
$vm = Get-AzVM -ResourceGroupName myResourceGroup -Name myVM
# Make sure the VM is stopped\deallocated

Stop-AzVM -ResourceGroupName myResourceGroup -Name $vm.Name -Force
# Get the new disk that you want to swap in

$disk = Get-AzDisk -ResourceGroupName myResourceGroup -Name newDisk
# Set the VM configuration to point to the new disk

Set-AzVMOSDisk -VM $vm -ManagedDiskId $disk.Id -Name $disk.Name -sto
# Update the VM with the new OS disk. Possible values of StorageAccountType include: 'Standard_LRS' and
'Premium_LRS'
Update-AzVM -ResourceGroupName myResourceGroup -VM $vm -StorageAccountType <Type of the storage account >
# Start the VM
Start-AzVM -Name $vm.Name -ResourceGroupName myResourceGroup
Verify and enable boot diagnostics

The following example enables the diagnostic extension on the VM named myVMDeployed in the resource group
$myVM = Get-AzVM -ResourceGroupName "myResourceGroup" -Name "myVMDeployed"

Set-AzVMBootDiagnostics -ResourceGroupName myResourceGroup -VM $myVM -enable
Update-AzVM -ResourceGroup "myResourceGroup" -VM $myVM
Next steps
If you are having issues connecting to your VM, see Troubleshoot RDP connections to an Azure VM. For issues
with accessing applications running on your VM, see Troubleshoot application connectivity issues on a Windows
VM.
For more information about using Resource Manager, see Azure Resource Manager overview.
Troubleshoot a Windows VM by attaching the OS
disk to a recovery VM using the Azure portal
If your Windows virtual machine (VM ) in Azure encounters a boot or disk error, you may need to perform
troubleshooting steps on the virtual hard disk itself. A common example would be a failed application update
that prevents the VM from being able to boot successfully. This article details how to use the Azure portal to
connect your virtual hard disk to another Windows VM to fix any errors, then re-create your original VM.

1. Delete the VM encountering issues, keeping the virtual hard disks.
2. Attach and mount the virtual hard disk to another Windows VM for troubleshooting purposes.
3. Connect to the troubleshooting VM. Edit files or run any tools to fix issues on the original virtual hard disk.
4. Unmount and detach the virtual hard disk from the troubleshooting VM.
5. Create a VM using the original virtual hard disk.
For the VM that uses managed disk, we can now use Azure PowerShell to change the OS disk for a VM. We no
longer need to delete and recreate the VM. For more information, see Troubleshoot a Windows VM by
attaching the OS disk to a recovery VM using Azure PowerShell.

To determine why your VM is not able to boot correctly, examine the boot diagnostics VM screenshot. A
common example would be a failed application update, or an underlying virtual hard disk being deleted or
moved.
Select your VM in the portal and then scroll down to the Support + Troubleshooting section. Click Boot
diagnostics to view the screenshot. Note any specific error messages or error codes to help determine why the
VM is encountering an issue.
You can also click Download screenshot to download a capture of the VM screenshot.
View existing virtual hard disk details

Before you can attach your virtual hard disk to another VM, you need to identify the name of the virtual hard
disk (VHD ).
Select your resource group from the portal, then select your storage account. Click Blobs, as in the following
example:
Typically you have a container named vhds that stores your virtual hard disks. Select the container to view a list
of virtual hard disks. Note the name of your VHD (the prefix is usually the name of your VM ):
Select your existing virtual hard disk from the list and copy the URL for use in the following steps:
Delete existing VM
Virtual hard disks and VMs are two distinct resources in Azure. A virtual hard disk is where the operating
system itself, applications, and configurations are stored. The VM itself is just metadata that defines the size or
location, and references resources such as a virtual hard disk or virtual network interface card (NIC ). Each
virtual hard disk has a lease assigned when attached to a VM. Although data disks can be attached and detached
even while the VM is running, the OS disk cannot be detached unless the VM resource is deleted. The lease
continues to associate the OS disk with a VM even when that VM is in a stopped and deallocated state.
The first step to recover your VM is to delete the VM resource itself. Deleting the VM leaves the virtual hard
disks in your storage account. After the VM is deleted, you attach the virtual hard disk to another VM to
troubleshoot and resolve the errors.
Select your VM in the portal, then click Delete:
Wait until the VM has finished deleting before you attach the virtual hard disk to another VM. The lease on the
virtual hard disk that associates it with the VM needs to be released before you can attach the virtual hard disk
to another VM.
Attach existing virtual hard disk to another VM

For the next few steps, you use another VM for troubleshooting purposes. You attach the existing virtual hard
disk to this troubleshooting VM to be able to browse and edit the disk's content. This process allows you to
correct any configuration errors or review additional application or system log files, for example. Choose or
create another VM to use for troubleshooting purposes.
1. Select your resource group from the portal, then select your troubleshooting VM. Select Disks and then
click Attach existing:
2. To select your existing virtual hard disk, click VHD File:

3. Select your storage account and container, then click your existing VHD. Click the Select button to
confirm your choice:
4. With your VHD now selected, click OK to attach the existing virtual hard disk:
5. After a few seconds, the Disks pane for your VM lists your existing virtual hard disk connected as a data
disk:
Mount the attached data disk
1. Open a Remote Desktop connection to your VM. Select your VM in the portal and click Connect.
Download and open the RDP connection file. Enter your credentials to sign in to your VM as follows:
2. Open Server Manager, then select File and Storage Services.
3. The data disk is automatically detected and attached. To see a list of the connected disks, select Disks. You
can select your data disk to view volume information, including the drive letter. The following example
shows the data disk attached and using F::
Fix issues on original virtual hard disk
With the existing virtual hard disk mounted, you can now perform any maintenance and troubleshooting steps
as needed. Once you have addressed the issues, continue with the following steps.
Unmount and detach original virtual hard disk

Once your errors are resolved, detach the existing virtual hard disk from your troubleshooting VM. You cannot
use your virtual hard disk with any other VM until the lease attaching the virtual hard disk to the
troubleshooting VM is released.
1. From the RDP session to your VM, open Server Manager, then select File and Storage Services:
2. Select Disks and then select your data disk. Right-click on your data disk and select Take Offline:
3. Now detach the virtual hard disk from the VM. Select your VM in the Azure portal and click Disks. Select
your existing virtual hard disk and then click Detach:
Wait until the VM has successfully detached the data disk before continuing.
Create VM from original hard disk

To create a VM from your original virtual hard disk, use this Azure Resource Manager template. The template
deploys a VM into an existing or new virtual network, using the VHD URL from the earlier command. Click the
Deploy to Azure button as follows:
The template is loaded into the Azure portal for deployment. Enter the names for your new VM and existing
Azure resources, and paste the URL to your existing virtual hard disk. To begin the deployment, click Purchase:
Re-enable boot diagnostics

When you create your VM from the existing virtual hard disk, boot diagnostics may not automatically be
enabled. To check the status of boot diagnostics and turn on if needed, select your VM in the portal. Under
Monitoring, click Diagnostics settings. Ensure the status is On, and the check mark next to Boot diagnostics
is selected. If you make any changes, click Save:
Next steps
VM.
Troubleshoot a Linux VM by attaching the OS disk to
a recovery VM with the Azure CLI
If your Linux virtual machine (VM ) encounters a boot or disk error, you may need to perform troubleshooting steps
on the virtual hard disk itself. A common example would be an invalid entry in /etc/fstab that prevents the VM
from being able to boot successfully. This article details how to use the Azure CLI to connect your virtual hard disk
to another Linux VM to fix any errors, then re-create your original VM.

2. Attach and mount the virtual hard disk to another Linux VM for troubleshooting purposes.
For the VM that uses managed disk, see Troubleshoot a Managed Disk VM by attaching a new OS disk.
To perform these troubleshooting steps, you need the latest Azure CLI installed and logged in to an Azure account
using az login.
In the following examples, replace parameter names with your own values. Example parameter names include
myResourceGroup , mystorageaccount , and myVM .

Examine the serial output to determine why your VM is not able to boot correctly. A common example is an invalid
entry in /etc/fstab , or the underlying virtual hard disk being deleted or moved.
Get the boot logs with az vm boot-diagnostics get-boot-log. The following example gets the serial output from the
VM named myVM in the resource group named myResourceGroup :
az vm boot-diagnostics get-boot-log --resource-group myResourceGroup --name myVM
Review the serial output to determine why the VM is failing to boot. If the serial output isn't providing any
indication, you may need to review log files in /var/log once you have the virtual hard disk connected to a
troubleshooting VM.

Before you can attach your virtual hard disk (VHD ) to another VM, you need to identify the URI of the OS disk.
View information about your VM with az vm show. Use the --query flag to extract the URI to the OS disk. The
following example gets disk information for the VM named myVM in the resource group named myResourceGroup :
az vm show --resource-group myResourceGroup --name myVM \
--query [storageProfile.osDisk.vhd.uri] --output tsv
The URI is similar to https://mystorageaccount.blob.core.windows.net/vhds/myVM.vhd.
Delete existing VM
Virtual hard disks and VMs are two distinct resources in Azure. A virtual hard disk is where the operating system
itself, applications, and configurations are stored. The VM itself is just metadata that defines the size or location,
and references resources such as a virtual hard disk or virtual network interface card (NIC ). Each virtual hard disk
has a lease assigned when attached to a VM. Although data disks can be attached and detached even while the VM
is running, the OS disk cannot be detached unless the VM resource is deleted. The lease continues to associate the
OS disk with a VM even when that VM is in a stopped and deallocated state.
The first step to recover your VM is to delete the VM resource itself. Deleting the VM leaves the virtual hard disks
in your storage account. After the VM is deleted, you attach the virtual hard disk to another VM to troubleshoot
and resolve the errors.
Delete the VM with az vm delete. The following example deletes the VM named myVM from the resource group
az vm delete --resource-group myResourceGroup --name myVM
virtual hard disk that associates it with the VM needs to be released before you can attach the virtual hard disk to
another VM.

For the next few steps, you use another VM for troubleshooting purposes. You attach the existing virtual hard disk
to this troubleshooting VM to browse and edit the disk's content. This process allows you to correct any
configuration errors or review additional application or system log files, for example. Choose or create another VM
to use for troubleshooting purposes.
Attach the existing virtual hard disk with az vm unmanaged-disk attach. When you attach the existing virtual hard
disk, specify the URI to the disk obtained in the preceding az vm show command. The following example attaches
an existing virtual hard disk to the troubleshooting VM named myVMRecovery in the resource group named
myResourceGroup :
az vm unmanaged-disk attach --resource-group myResourceGroup --vm-name myVMRecovery \

--vhd-uri https://mystorageaccount.blob.core.windows.net/vhds/myVM.vhd

NOTE
The following examples detail the steps required on an Ubuntu VM. If you are using a different Linux distro, such as Red Hat
Enterprise Linux or SUSE, the log file locations and mount commands may be a little different. Refer to the documentation
for your specific distro for the appropriate changes in commands.
1. SSH to your troubleshooting VM using the appropriate credentials. If this disk is the first data disk attached
to your troubleshooting VM, the disk is likely connected to /dev/sdc . Use dmseg to view attached disks:
dmesg | grep SCSI
The output is similar to the following example:
[ 0.294784] SCSI subsystem initialized

[ 0.573458] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 7.110271] sd 2:0:0:0: [sda] Attached SCSI disk
[ 8.079653] sd 3:0:1:0: [sdb] Attached SCSI disk
[ 1828.162306] sd 5:0:0:0: [sdc] Attached SCSI disk
In the preceding example, the OS disk is at /dev/sda and the temporary disk provided for each VM is at
/dev/sdb . If you had multiple data disks, they should be at /dev/sdd , /dev/sde , and so on.
2. Create a directory to mount your existing virtual hard disk. The following example creates a directory
named troubleshootingdisk :
sudo mkdir /mnt/troubleshootingdisk
3. If you have multiple partitions on your existing virtual hard disk, mount the required partition. The following
example mounts the first primary partition at /dev/sdc1 :
sudo mount /dev/sdc1 /mnt/troubleshootingdisk
NOTE
Best practice is to mount data disks on VMs in Azure using the universally unique identifier (UUID) of the virtual hard
disk. For this short troubleshooting scenario, mounting the virtual hard disk using the UUID is not necessary.
However, under normal use, editing /etc/fstab to mount virtual hard disks using device name rather than UUID
may cause the VM to fail to boot.

With the existing virtual hard disk mounted, you can now perform any maintenance and troubleshooting steps as

Once your errors are resolved, you unmount and detach the existing virtual hard disk from your troubleshooting
VM. You cannot use your virtual hard disk with any other VM until the lease attaching the virtual hard disk to the
troubleshooting VM is released.
1. From the SSH session to your troubleshooting VM, unmount the existing virtual hard disk. Change out of
the parent directory for your mount point first:
cd /
Now unmount the existing virtual hard disk. The following example unmounts the device at /dev/sdc1 :
sudo umount /dev/sdc1
2. Now detach the virtual hard disk from the VM. Exit the SSH session to your troubleshooting VM. List the
attached data disks to your troubleshooting VM with az vm unmanaged-disk list. The following example lists
the data disks attached to the VM named myVMRecovery in the resource group named myResourceGroup :
azure vm unmanaged-disk list --resource-group myResourceGroup --vm-name myVMRecovery \

--query '[].{Disk:vhd.uri}' --output table
Note the name for your existing virtual hard disk. For example, the name of a disk with the URI of
https://mystorageaccount.blob.core.windows.net/vhds/myVM.vhd is myVHD.
Detach the data disk from your VM az vm unmanaged-disk detach. The following example detaches the disk
named myVHD from the VM named myVMRecovery in the myResourceGroup resource group:
az vm unmanaged-disk detach --resource-group myResourceGroup --vm-name myVMRecovery \

--name myVHD

To create a VM from your original virtual hard disk, use this Azure Resource Manager template. The actual JSON
template is at the following link:
https://github.com/Azure/azure-quickstart-templates/blob/master/201-vm-specialized-vhd-new -or-existing-
vnet/azuredeploy.json
The template deploys a VM using the VHD URI from the earlier command. Deploy the template with az group
deployment create. Provide the URI to your original VHD and then specify the OS type, VM size, and VM name as
follows:
az group deployment create --resource-group myResourceGroup --name myDeployment \

--parameters '{"osDiskVhdUri": {"value": "https://mystorageaccount.blob.core.windows.net/vhds/myVM.vhd"},
"osType": {"value": "Linux"},
"vmSize": {"value": "Standard_DS1_v2"},
"vmName": {"value": "myDeployedVM"}}' \
--template-uri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/201-vm-
specialized-vhd/azuredeploy.json

When you create your VM from the existing virtual hard disk, boot diagnostics may not automatically be enabled.
Enable boot diagnostics with az vm boot-diagnostics enable. The following example enables the diagnostic
extension on the VM named myDeployedVM in the resource group named myResourceGroup :
az vm boot-diagnostics enable --resource-group myResourceGroup --name myDeployedVM
Troubleshoot a Managed Disk VM by attaching a new OS disk

1. Stop the effected VM.
2. Create a managed disk snapshot of the OS Disk of the Managed Disk VM.
3. Create a managed disk from the snapshot.
4. Attach the managed disk as a data disk of the VM.
5. Change the data disk from step 4 to OS disk.
Next steps
If you are having issues connecting to your VM, see Troubleshoot SSH connections to an Azure VM. For issues
with accessing applications running on your VM, see Troubleshoot application connectivity issues on a Linux VM.
Troubleshoot a Linux VM by attaching the OS disk to
a recovery VM using the Azure portal
If your Linux virtual machine (VM ) encounters a boot or disk error, you may need to perform troubleshooting steps
on the virtual hard disk itself. A common example would be an invalid entry in /etc/fstab that prevents the VM
from being able to boot successfully. This article details how to use the Azure portal to connect your virtual hard
disk to another Linux VM to fix any errors, then re-create your original VM.

2. Attach and mount the virtual hard disk to another Linux VM for troubleshooting purposes.
For the VM that uses managed disk, see Troubleshoot a Managed Disk VM by attaching a new OS disk.

Examine the boot diagnostics and VM screenshot to determine why your VM is not able to boot correctly. A
common example would be an invalid entry in /etc/fstab , or an underlying virtual hard disk being deleted or
moved.
Select your VM in the portal and then scroll down to the Support + Troubleshooting section. Click Boot
diagnostics to view the console messages streamed from your VM. Review the console logs to see if you can
determine why the VM is encountering an issue. The following example shows a VM stuck in maintenance mode
that requires manual interaction:
You can also click Screenshot across the top of the boot diagnostics log to download a capture of the VM
screenshot.

Before you can attach your virtual hard disk to another VM, you need to identify the name of the virtual hard disk
(VHD ).
Select your resource group from the portal, then select your storage account. Click Blobs, as in the following
example:
Typically you have a container named vhds that stores your virtual hard disks. Select the container to view a list of
virtual hard disks. Note the name of your VHD (the prefix is usually the name of your VM ):
Select your existing virtual hard disk from the list and copy the URL for use in the following steps:
Delete existing VM
Virtual hard disks and VMs are two distinct resources in Azure. A virtual hard disk is where the operating system
itself, applications, and configurations are stored. The VM itself is just metadata that defines the size or location,
and references resources such as a virtual hard disk or virtual network interface card (NIC ). Each virtual hard disk
has a lease assigned when attached to a VM. Although data disks can be attached and detached even while the VM
is running, the OS disk cannot be detached unless the VM resource is deleted. The lease continues to associate the
OS disk with a VM even when that VM is in a stopped and deallocated state.
The first step to recover your VM is to delete the VM resource itself. Deleting the VM leaves the virtual hard disks
in your storage account. After the VM is deleted, you attach the virtual hard disk to another VM to troubleshoot
and resolve the errors.
Select your VM in the portal, then click Delete:
virtual hard disk that associates it with the VM needs to be released before you can attach the virtual hard disk to
another VM.

For the next few steps, you use another VM for troubleshooting purposes. You attach the existing virtual hard disk
to this troubleshooting VM to be able to browse and edit the disk's content. This process allows you to correct any
configuration errors or review additional application or system log files, for example. Choose or create another VM
to use for troubleshooting purposes.
1. Select your resource group from the portal, then select your troubleshooting VM. Select Disks and then
click Attach existing:
2. To select your existing virtual hard disk, click VHD File:

3. Select your storage account and container, then click your existing VHD. Click the Select button to confirm
your choice:
4. With your VHD now selected, click OK to attach the existing virtual hard disk:
5. After a few seconds, the Disks pane for your VM lists your existing virtual hard disk connected as a data
disk:
NOTE
The following examples detail the steps required on an Ubuntu VM. If you are using a different Linux distro, such as Red Hat
Enterprise Linux or SUSE, the log file locations and mount commands may be a little different. Refer to the documentation
for your specific distro for the appropriate changes in commands.
1. SSH to your troubleshooting VM using the appropriate credentials. If this disk is the first data disk attached
to your troubleshooting VM, it is likely connected to /dev/sdc . Use dmseg to list attached disks:
dmesg | grep SCSI
The output is similar to the following example:
[ 0.294784] SCSI subsystem initialized

[ 0.573458] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 7.110271] sd 2:0:0:0: [sda] Attached SCSI disk
[ 8.079653] sd 3:0:1:0: [sdb] Attached SCSI disk
[ 1828.162306] sd 5:0:0:0: [sdc] Attached SCSI disk
In the preceding example, the OS disk is at /dev/sda and the temporary disk provided for each VM is at
/dev/sdb . If you had multiple data disks, they should be at /dev/sdd , /dev/sde , and so on.
2. Create a directory to mount your existing virtual hard disk. The following example creates a directory
named troubleshootingdisk :
sudo mkdir /mnt/troubleshootingdisk
3. If you have multiple partitions on your existing virtual hard disk, mount the required partition. The following
example mounts the first primary partition at /dev/sdc1 :
sudo mount /dev/sdc1 /mnt/troubleshootingdisk

NOTE
Best practice is to mount data disks on VMs in Azure using the universally unique identifier (UUID) of the virtual hard
disk. For this short troubleshooting scenario, mounting the virtual hard disk using the UUID is not necessary.
However, under normal use, editing /etc/fstab to mount virtual hard disks using device name rather than UUID
may cause the VM to fail to boot.

With the existing virtual hard disk mounted, you can now perform any maintenance and troubleshooting steps as

Once your errors are resolved, detach the existing virtual hard disk from your troubleshooting VM. You cannot use
your virtual hard disk with any other VM until the lease attaching the virtual hard disk to the troubleshooting VM
is released.
1. From the SSH session to your troubleshooting VM, unmount the existing virtual hard disk. Change out of
the parent directory for your mount point first:
cd /
Now unmount the existing virtual hard disk. The following example unmounts the device at /dev/sdc1 :
sudo umount /dev/sdc1
2. Now detach the virtual hard disk from the VM. Select your VM in the portal and click Disks. Select your
existing virtual hard disk and then click Detach:
Wait until the VM has successfully detached the data disk before continuing.

To create a VM from your original virtual hard disk, use this Azure Resource Manager template. The template
deploys a VM into an existing virtual network, using the VHD URL from the earlier command. Click the Deploy to
Azure button as follows:
The template is loaded into the Azure portal for deployment. Enter the names for your new VM and existing Azure
resources, and paste the URL to your existing virtual hard disk. To begin the deployment, click Purchase:
When you create your VM from the existing virtual hard disk, boot diagnostics may not automatically be enabled.
To check the status of boot diagnostics and turn on if needed, select your VM in the portal. Under Monitoring,
click Diagnostics settings. Ensure the status is On, and the check mark next to Boot diagnostics is selected. If
you make any changes, click Save:
Troubleshoot a Managed Disk VM by attaching a new OS disk
1. Stop the effected VM.
2. Create a managed disk snapshot of the OS Disk of the Managed Disk VM.
3. Create a managed disk from the snapshot.
4. Attach the managed disk as a data disk of the VM.
5. Change the data disk from step 4 to OS disk.
Next steps
If you are having issues connecting to your VM, see Troubleshoot SSH connections to an Azure VM. For issues
with accessing applications running on your VM, see Troubleshoot application connectivity issues on a Linux VM.
Troubleshoot Azure Virtual Machines boot errors
This article lists the common boot errors that you may receive when you start a Windows virtual machine (VM ) in
Microsoft Azure. For more information about the errors, see the articles in the Boot errors and solutions section.
Boot errors and solutions

BitLocker boot errors
Windows show "Checking file system" during boot
Blue screen errors
VM startup is stuck on "Getting Windows Ready
"CRITICAL SERVICE FAILED" error on blue screen
Reboot loop problem
VM startup is stuck at Windows update stage
Next steps
Boot diagnostics
VM Serial Console
Troubleshoot a Windows VM by attaching the OS disk to a recovery VM
How to use boot diagnostics to troubleshoot
virtual machines in Azure
There can be many reasons that a virtual machine enters a non-bootable state. To address issues with your
virtual machines created using Resource Manager deployment model you can use the following debugging
features: Console Output and Screenshot support for Azure virtual machines.
For Linux virtual machines, you can view the output of your console log from the Portal. For both Windows
and Linux virtual machines, Azure enables you to see a screenshot of the VM from the hypervisor. Both
features are supported for Azure virtual machines in all regions. Note, screenshots, and output can take up to
10 minutes to appear in your storage account.
You can select the Boot diagnostics option to view the log and the screenshot.
Common boot errors

0xC000000E
0xC000000F
0xC0000011
0xC0000034
0xC0000098
0xC00000BA
0xC000014C
0xC0000221
0xC0000225
0xC0000359
0xC0000605
An operating system wasn't found
Boot failure or INACCESSIBLE_BOOT_DEVICE
Enable diagnostics on a virtual machine created using the Azure

Portal
The following procedure is for a virtual machine created using the Resource Manager deployment model.
On the Management tab, in Monitoring section, make sure that Boot diagnostics is turned on. From the
Diagnostics storage account drop-down list, select a storage account in which to place the diagnostic files.
NOTE
The Boot diagnostics feature does not support premium storage account. If you use the premium storage account for
Boot diagnostics, you might receive the StorageAccountTypeNotSupported error when you start the VM.
Deploying from an Azure Resource Manager template

If you are deploying from an Azure Resource Manager template, navigate to your virtual machine resource
and append the diagnostics profile section. Set the API version header to "2015-06-15" or later. The latest
version is "2018-10-01".
{
"apiVersion": "2018-10-01",
"type": "Microsoft.Compute/virtualMachines",
…
The diagnostics profile enables you to select the storage account where you want to put these logs.
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": "[concat('https://', parameters('newStorageAccountName'), '.blob.core.windows.net')]"
}
}
}
}
For more information on deploying resources using templates, see Quickstart: Create and deploy Azure
Resource Manager templates by using the Azure portal.
Enable boot diagnostics on existing virtual machine

To enable Boot diagnostics on an existing virtual machine, follow these steps:
1. Sign in to the Azure portal, and then select the virtual machine.
2. In the Support + troubleshooting section, select Boot diagnostics, then select the Settings tab.
3. In Boot diagnostics settings, change the status to On, and from the Storage account drop-down list
select a storage account.
4. Save the change.
You must restart the virtual machine for the change to take effect.
Enable boot diagnostics using the Azure CLI
You can use the Azure CLI to enable boot diagnostics on an existing Azure virtual machine. For more
information, see az vm boot-diagnostics.
BitLocker boot errors on an Azure VM
This article describes BitLocker errors that you may experience when you start a Windows virtual machine (VM ) in
Microsoft Azure.
NOTE
PowerShell.
Symptom
A Windows VM doesn't start. When you check the screenshots in the Boot diagnostics window, you see one of the
following error messages:
Plug in the USB driver that has the BitLocker key
You’re locked out! Enter the recovery key to get going again (Keyboard Layout: US ) The wrong sign-in info
has been entered too many times, so your PC was locked to protect your privacy. To retrieve the recovery
key, go to https://windows.microsoft.com/recoverykeyfaq from another PC or mobile device. In case you
need it, the key ID is XXXXXXX. Or, you can reset your PC.
Enter the password to unlock this drive [ ] Press the Insert Key to see the password as you type.
Enter your recovery key Load your recovery key from a USB device.
Cause
This problem may occur if the VM cannot locate the BitLocker Recovery Key (BEK) file to decrypt the encrypted
disk.
Solution
To resolve this problem, stop and deallocate the VM, and then restart it. This operation forces the VM to retrieve
the BEK file from the Azure Key Vault, and then put it on the encrypted disk.
If this method does not the resolve the problem, follow these steps to restore the BEK file manually:
1. Take a snapshot of the system disk of the affected VM as a backup. For more information, see Snapshot a
disk.
2. Attach the system disk to a recovery VM that is encrypted by BitLocker. This is required to run the manage-
bde command that is available only on the BitLocker-encrypted VM.
When you attach a managed disk, you might receive a "contains encryption settings and therefore cannot
be used as a data disk” error message. In this situation, run the following script to try again to attach the
disk:
$rgName = "myResourceGroup"
$osDiskName = "ProblemOsDisk"
New-AzDiskUpdateConfig -EncryptionSettingsEnabled $false |Update-AzDisk -diskName $osDiskName -

ResourceGroupName $rgName
$recoveryVMName = "myRecoveryVM"
$recoveryVMRG = "RecoveryVMRG"
$OSDisk = Get-AzDisk -ResourceGroupName $rgName -DiskName $osDiskName;
$vm = get-AzVM -ResourceGroupName $recoveryVMRG -Name $recoveryVMName
Add-AzVMDataDisk -VM $vm -Name $osDiskName -ManagedDiskId $osDisk.Id -Caching None -Lun 3 -CreateOption
Attach
Update-AzVM -VM $vm -ResourceGroupName $recoveryVMRG
You cannot attach a managed disk to a VM that was restored from a blob image.
3. After the disk is attached, make a remote desktop connection to the recovery VM so that you can run some
Azure PowerShell scripts. Make sure that you have the latest version of Azure PowerShell installed on the
recovery VM.
4. Open an elevated Azure PowerShell session (Run as administrator). Run the following commands to sign in
to Azure subscription:
Add-AzAccount -SubscriptionID [SubscriptionID]
5. Run the following script to check the name of the BEK file:
$vmName = "myVM"
$vault = "myKeyVault"
Get-AzureKeyVaultSecret -VaultName $vault | where {($_.Tags.MachineName -eq $vmName) -and
($_.ContentType -match 'BEK')} `
| Sort-Object -Property Created `
| ft Created, `
@{Label="Content Type";Expression={$_.ContentType}}, `
@{Label ="Volume"; Expression = {$_.Tags.VolumeLetter}}, `
@{Label ="DiskEncryptionKeyFileName"; Expression = {$_.Tags.DiskEncryptionKeyFileName}}
The following is sample of the output. Locate the BEK file name for the attached disk. In this case, we
assume that the drive letter of the attached disk is F, and the BEK file is EF7B2F5A-50C6-4637-9F13-
7F599C12F85C.BEK.
Created Content Type Volume DiskEncryptionKeyFileName

------- ------------ ------ -------------------------
4/5/2018 7:14:59 PM Wrapped BEK C:\ B4B3E070-836C-4AF5-AC5B-66F6FDE6A971.BEK
4/7/2018 7:21:16 PM Wrapped BEK F:\ EF7B2F5A-50C6-4637-9F13-7F599C12F85C.BEK
4/7/2018 7:26:23 PM Wrapped BEK G:\ 70148178-6FAE-41EC-A05B-3431E6252539.BEK
4/7/2018 7:26:26 PM Wrapped BEK H:\ 5745719F-4886-4940-9B51-C98AFABE5305.BEK
If you see two duplicated volumes, the volume that has the newer timestamp is the current BEK file that is
used by the recovery VM.
If the Content Type value is Wrapped BEK, go to the Key Encryption Key (KEK) scenarios.
Now that you have the name of the BEK file for the drive, you have to create the secret-file-name.BEK file to
unlock the drive.
6. Download the BEK file to the recovery disk. The following sample saves the BEK file to the C:\BEK folder.
Make sure that the C:\BEK\ path exists before you run the scripts.
$vault = "myKeyVault"
$bek = " EF7B2F5A-50C6-4637-9F13-7F599C12F85C.BEK"
$keyVaultSecret = Get-AzureKeyVaultSecret -VaultName $vault -Name $bek
$bekSecretBase64 = $keyVaultSecret.SecretValueText
$bekFileBytes = [Convert]::FromBase64String($bekSecretbase64)
$path = "C:\BEK\DiskEncryptionKeyFileName.BEK"
[System.IO.File]::WriteAllBytes($path,$bekFileBytes)
7. To unlock the attached disk by using the BEK file, run the following command:
manage-bde -unlock F: -RecoveryKey "C:\BEK\EF7B2F5A-50C6-4637-9F13-7F599C12F85C.BEK
In this sample, the attached OS disk is drive F. Make sure that you use the correct drive letter.
If the disk was successfully unlocked by using the BEK key. we can consider the BItLocker problem to
be resolved.
If using the BEK key does not unlock the disk, you can use suspend protection to temporarily turn
BitLocker OFF by running the following command
manage-bde -protectors -disable F: -rc 0
If you are going to rebuild the VM by using the dytem disk, you must fully decrypt the drive. To do
this, run the following command:
manage-bde -off F:
8. Detach the disk from the recovery VM, and then re-attach the disk to the affected VM as a system disk. For
more information, see Troubleshoot a Windows VM by attaching the OS disk to a recovery VM.
Key Encryption Key scenario
For a Key Encryption Key scenario, follow these steps:
1. Make sure that the logged-in user account requires the "unwrapped" permission in the Key Vault Access
policies in the USER|Key permissions|Cryptographic Operations|Unwrap Key.
2. Save the following scripts to a .PS1 file:
#Set the Parameters for the script

param (
[Parameter(Mandatory=$true)]
[string]
$keyVaultName,
[string]
$kekName,
[string]
$secretName,
[string]
$bekFilePath,
[string]
$adTenant
$adTenant
)
# Load ADAL Assemblies. The following script assumes that the Azure PowerShell version you installed is
1.0.0.
$adal =
"${env:ProgramFiles}\WindowsPowerShell\Modules\Az.Accounts\1.0.0\PreloadAssemblies\Microsoft.IdentityMod
el.Clients.ActiveDirectory.dll"
$adalforms =
"${env:ProgramFiles}\WindowsPowerShell\Modules\Az.Accounts\1.0.0\PreloadAssemblies\Microsoft.IdentityMod
el.Clients.ActiveDirectory.Platform.dll"
[System.Reflection.Assembly]::LoadFrom($adal)
[System.Reflection.Assembly]::LoadFrom($adalforms)
# Set well-known client ID for AzurePowerShell

$clientId = "1950a258-227b-4e31-a9cf-717495945fc2"
# Set redirect URI for Azure PowerShell
$redirectUri = "urn:ietf:wg:oauth:2.0:oob"
# Set Resource URI to Azure Service Management API
$resourceAppIdURI = "https://vault.azure.net"
# Set Authority to Azure AD Tenant
$authority = "https://login.windows.net/$adtenant"
# Create Authentication Context tied to Azure AD Tenant
$authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" -
ArgumentList $authority
# Acquire token
$authResult = $authContext.AcquireTokenAsync($resourceAppIdURI, $clientId, $redirectUri,
$platformParameters).result
# Generate auth header
$authHeader = $authResult.CreateAuthorizationHeader()
# Set HTTP request headers to include Authorization header
$headers = @{'x-ms-version'='2014-08-01';"Authorization" = $authHeader}
########################################################################################################
################
# 1. Retrieve wrapped BEK
# 2. Make KeyVault REST API call to unwrap the BEK
# 3. Convert the Base64Url string returned by KeyVault unwrap to Base64 string
# 4. Convert Base64 string to bytes and write to the BEK file
########################################################################################################
################
#Get wrapped BEK and place it in JSON object to send to KeyVault REST API
$keyVaultSecret = Get-AzureKeyVaultSecret -VaultName $keyVaultName -Name $secretName
$wrappedBekSecretBase64 = $keyVaultSecret.SecretValueText
$jsonObject = @"
{
"alg": "RSA-OAEP",
"value" : "$wrappedBekSecretBase64"
}
"@
#Get KEK Url

$kekUrl = (Get-AzureKeyVaultKey -VaultName $keyVaultName -Name $kekName).Key.Kid;
$unwrapKeyRequestUrl = $kekUrl+ "/unwrapkey?api-version=2015-06-01";
#Call KeyVault REST API to Unwrap

$result = Invoke-RestMethod -Method POST -Uri $unwrapKeyRequestUrl -Headers $headers -Body $jsonObject -
ContentType "application/json" -Debug
#Convert Base64Url string returned by KeyVault unwrap to Base64 string

$base64UrlBek = $result.value;
$base64Bek = $base64UrlBek.Replace('-', '+');
$base64Bek = $base64Bek.Replace('_', '/');
if($base64Bek.Length %4 -eq 2)
{
$base64Bek+= '==';
}
elseif($base64Bek.Length %4 -eq 3)
{
$base64Bek+= '=';
$base64Bek+= '=';
}
#Convert base64 string to bytes and write to BEK file

$bekFileBytes = [System.Convert]::FromBase64String($base64Bek);
[System.IO.File]::WriteAllBytes($bekFilePath,$bekFileBytes)
3. Set the parameters. The script will process the KEK secret to create the BEK key, and then save it to a local
folder on the recovery VM.
4. You see the following output when the script begins:
GAC Version Location

--- ------- --------
False v4.0.30319 C:\Program Files\WindowsPowerShell\Modules\Az.Accounts\...
False v4.0.30319 C:\Program Files\WindowsPowerShell\Modules\Az.Accounts\...
When the script finishes, you see the following output:
VERBOSE: POST https://myvault.vault.azure.net/keys/rondomkey/<KEY-ID>/unwrapkey?api-

version=2015-06-01 with -1-byte payload
VERBOSE: received 360-byte response of content type application/json; charset=utf-8
5. To unlock the attached disk by using the BEK file, run the following command:
manage-bde -unlock F: -RecoveryKey "C:\BEK\EF7B2F5A-50C6-4637-9F13-7F599C12F85C.BEK
In this sample, the attached OS disk is drive F. Make sure that you use the correct drive letter.
If the disk was successfully unlocked by using the BEK key. we can consider the BItLocker problem to
be resolved.
If using the BEK key does not unlock the disk, you can use suspend protection to temporarily turn
BitLocker OFF by running the following command
manage-bde -protectors -disable F: -rc 0
If you are going to rebuild the VM by using the dytem disk, you must fully decrypt the drive. To do
this, run the following command:
manage-bde -off F:
6. Detach the disk from the recovery VM, and then re-attach the disk to the affected VM as a system disk. For
more information, see Troubleshoot a Windows VM by attaching the OS disk to a recovery VM.
Windows shows “checking file system” when booting
an Azure VM
This article describes the “Checking file system” error that you may encounter when you boot a Windows Virtual
Machine (VM ) in Microsoft Azure.
NOTE
article describes using the Resource Manager deployment model, which we recommend using for new deployments instead
of the classic deployment model.
Symptom
A Windows VM doesn't start. When you check the boot screenshots in Boot diagnostics, you see that the Check
Disk process (chkdsk.exe) is running with one of the following messages:
Scanning and repairing drive (C:)
Checking file system on C:
Cause
If an NTFS error is found in the file system, Windows will check and repair the consistency of the disk at the next
restart. Usually this happens if the VM had any unexpected restart, or if the VM shutdown process was abruptly
interrupted.
Solution
Windows will boot normally after the Check Disk process is completed. If the VM is stuck in the Check Disk
process, try to run the Check Disk on the VM offline:
1. Take a snapshot of the OS disk of the affected VM as a backup. For more information, see Snapshot a disk.
3. On the recovery VM, run Check Disk on the attached OS disk. In the following sample, the driver letter of
the attached OS disk is E:
chkdsk E: /f
4. After the Check Disk completes, detach the disk from the recovery VM, and then re-attach the disk to the
affected VM as an OS disk. For more information, see Troubleshoot a Windows VM by attaching the OS
disk to a recovery VM.
Windows shows blue screen error when booting an
Azure VM
This article describes blue screen errors that you may encounter when you boot a Windows Virtual Machine (VM )
in Microsoft Azure. It provides steps to help you collect data for a support ticket.
NOTE
Symptom
A Windows VM doesn't start. When you check the boot screenshots in Boot diagnostics, you see one of the
following error messages in a blue screen:
our PC ran into a problem and needs to restart. We're just collecting some error info, and then you can restart.
Your PC ran into a problem and needs to restart.
This section lists the common error messages you may encounter when managing VMs:
Cause
There could be multiple reasons as why you would get a stop error. The most common causes are:
Problem with a driver
Corrupted system file or memory
An application accesses to a forbidden sector of the memory
Collect memory dump file

To resolve this problem, you would need first to gather dump file for the crash and contact support with the dump
file. To collect the Dump file, follow these steps:
3. Remote desktop to the recovery VM.
Locate dump file and submit a support ticket
1. On the recovery VM, go to windows folder in the attached OS disk. If the driver letter that is assigned to the
attached OS disk is F, you need to go to F:\Windows.
2. Locate the memory.dmp file, and then submit a support ticket with the dump file.
If you cannot find the dump file, move the next step to enable dump log and Serial Console.
Enable dump log and Serial Console
1. Open elevated command Prompt session (Run as administrator).
In this script, we assume that the drive letter that is assigned to the attached OS disk is F. Replace it with the
appropriate value in your VM.



a. Make sure that there's enough space on the disk to allocate as much memory as the RAM, which
depends on the size that you are selecting for this VM.
b. If there's not enough space or this is a large size VM (G, GS or E series), you could then change the
location where this file will be created and refer that to any other data disk which is attached to the
VM. To do this, you will need to change the following key:
REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\CrashControl" /v DumpFile /t REG_EXPAND_SZ /d "

<DRIVE LETTER OF YOUR DATA DISK>:\MEMORY.DMP" /f
REG ADD "HKLM\BROKENSYSTEM\ControlSet002\Control\CrashControl" /v DumpFile /t REG_EXPAND_SZ /d "
<DRIVE LETTER OF YOUR DATA DISK>:\MEMORY.DMP" /f
3. Detach the OS disk and then Re-attach the OS disk to the affected VM.
4. Start the VM to reproduce the issue, then a dump file will be generated.
5. Attach the OS disk to a recovery VM, collect dump file, and then submit a support ticket with the dump file.
VM startup is stuck on "Getting Windows ready. Don't
turn off your computer" in Azure
This article helps you resolve the issue when your virtual machine (VM ) is stuck on the "Getting Windows Ready.
Don't turn off your computer" stage during startup.
NOTE
PowerShell.
Symptoms
When you use Boot diagnostics to get the screenshot of a VM, the operating system doesn't fully start up. The
VM displays the message "Getting Windows ready. Don't turn off your computer."
Cause
Usually this issue occurs when the server is doing the final reboot after the configuration was changed. The
configuration change might be initialized by Windows updates or by the changes on the roles/feature of the server.
For Windows Update, if the size of the updates was large, the operating system needs more time to reconfigure
the changes.
Back up the OS disk

Before you try to fix the issue, back up the OS disk.
For VMs with an encrypted disk, you must unlock the disks first
Follow these steps to determine whether the VM is an encrypted VM.
1. On the Azure portal, open your VM, and then browse to the disks.
2. Look at the Encryption column to see whether encryption is enabled.
If the OS disk is encrypted, unlock the encrypted disk. To unlock the disk, follow these steps.
1. Create a Recovery VM that's located in the same Resource Group, Storage Account, and Location as the
affected VM.
2. In the Azure portal, delete the affected VM and keep the disk.
3. Run PowerShell as an administrator.
4. Run the following cmdlet to get the secret name.
Login-AzAccount
$vmName = “VirtualMachineName”
$vault = “AzureKeyVaultName”
# Get the Secret for the C drive from Azure Key Vault
($_.Tags.VolumeLetter -eq “C:\”) -and ($_.ContentType -eq ‘BEK‘)}
# OR Use the below command to get BEK keys for all the Volumes
($_.ContentType -eq ‘BEK’)}
5. After you have the secret name, run the following commands in PowerShell.
$secretName = 'SecretName'
$keyVaultSecret = Get-AzureKeyVaultSecret -VaultName $vault -Name $secretname
$bekSecretBase64 = $keyVaultSecret.SecretValueText
6. Convert the Base64-encoded value to bytes, and write the output to a file.
NOTE
If you use the USB unlock option, the BEK file name must match the original BEK GUID. Create a folder on your C
drive named "BEK" before you follow these steps.
New-Item -ItemType directory -Path C:\BEK

$bekFileBytes = [Convert]::FromBase64String($bekSecretbase64)
$path = “c:\BEK\$secretName.BEK”
[System.IO.File]::WriteAllBytes($path,$bekFileBytes)
7. After the BEK file is created on your PC, copy the file to the recovery VM you have the locked OS disk
attached to. Run the following commands by using the BEK file location.
manage-bde -status F:
manage-bde -unlock F: -rk C:\BEKFILENAME.BEK
Optional: In some scenarios, it might be necessary to decrypt the disk by using this command.
manage-bde -off F:
NOTE
The previous command assumes the disk to encrypt is on letter F.
8. If you need to collect logs, go to the path DRIVE LETTER:\Windows\System32\winevt\Logs.

9. Detach the drive from the recovery machine.
Create a snapshot
To create a snapshot, follow the steps in Snapshot a disk.
Collect an OS memory dump

Use the steps in the Collect os dump section to collect an OS dump when the VM is stuck at configuration.
Contact Microsoft support

After you collect the dump file, contact Microsoft support to analyze the root cause.
Rebuild the VM by using PowerShell

After you collect the memory dump file, follow these steps to rebuild the VM.
For non-managed disks
# To log in to Azure Resource Manager

Login-AzAccount
# To view all subscriptions for your account

Get-AzSubscription
# To select a default subscription for your current session

Get-AzSubscription –SubscriptionID “SubscriptionID” | Select-AzSubscription
$rgname = "RGname"
$loc = "Location"
$vmsize = "VmSize"
$vmname = "VmName"
$vm = New-AzVMConfig -VMName $vmname -VMSize $vmsize;
$nic = Get-AzNetworkInterface -Name ("NicName") -ResourceGroupName $rgname;

$nicId = $nic.Id;
$vm = Add-AzVMNetworkInterface -VM $vm -Id $nicId;
$osDiskName = "OSdiskName"
$osDiskVhdUri = "OSdiskURI"
$vm = Set-AzVMOSDisk -VM $vm -VhdUri $osDiskVhdUri -name $osDiskName -CreateOption attach -Windows
New-AzVM -ResourceGroupName $rgname -Location $loc -VM $vm -Verbose
For managed disks

# To log in to Azure Resource Manager
Login-AzAccount
# To view all subscriptions for your account

Get-AzSubscription
# To select a default subscription for your current session

Get-AzSubscription –SubscriptionID "SubscriptionID" | Select-AzSubscription
#Fill in all variables

$subid = "SubscriptionID"
$rgName = "ResourceGroupName";
$loc = "Location";
$vmSize = "VmSize";
$vmName = "VmName";
$nic1Name = "FirstNetworkInterfaceName";
#$nic2Name = "SecondNetworkInterfaceName";
$avName = "AvailabilitySetName";
$osDiskName = "OsDiskName";
$DataDiskName = "DataDiskName"
#This can be found by selecting the Managed Disks you wish you use in the Azure portal if the format below
doesn't match
$osDiskResourceId =
"/subscriptions/$subid/resourceGroups/$rgname/providers/Microsoft.Compute/disks/$osDiskName";
$dataDiskResourceId =
"/subscriptions/$subid/resourceGroups/$rgname/providers/Microsoft.Compute/disks/$DataDiskName";
$vm = New-AzVMConfig -VMName $vmName -VMSize $vmSize;
#Uncomment to add Availability Set

#$avSet = Get-AzAvailabilitySet –Name $avName –ResourceGroupName $rgName;
#$vm = New-AzVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avSet.Id;
#Get NIC Resource Id and add

$nic1 = Get-AzNetworkInterface -Name $nic1Name -ResourceGroupName $rgName;
$vm = Add-AzVMNetworkInterface -VM $vm -Id $nic1.Id -Primary;
#Uncomment to add a secondary NIC

#$nic2 = Get-AzNetworkInterface -Name $nic2Name -ResourceGroupName $rgName;
#$vm = Add-AzVMNetworkInterface -VM $vm -Id $nic2.Id;
#Windows VM
$vm = Set-AzVMOSDisk -VM $vm -ManagedDiskId $osDiskResourceId -name $osDiskName -CreateOption Attach -Windows;
#Linux VM
#$vm = Set-AzVMOSDisk -VM $vm -ManagedDiskId $osDiskResourceId -name $osDiskName -CreateOption Attach -Linux;
#Uncomment to add additional Data Disk

#Add-AzVMDataDisk -VM $vm -ManagedDiskId $dataDiskResourceId -Name $dataDiskName -Caching None -DiskSizeInGB
1024 -Lun 0 -CreateOption Attach;
New-AzVM -ResourceGroupName $rgName -Location $loc -VM $vm;

Windows shows "CRITICAL SERVICE FAILED" on blue
screen when booting an Azure VM
This article describes the "CRITICAL SERVICE FAILED" error that you may experience when you boot a Windows
Virtual Machine (VM ) in Microsoft Azure. It provides troubleshooting steps to help resolve the issues.
NOTE
Symptom
A Windows VM doesn't start. When you check the boot screenshots in Boot diagnostics, you see one of the
following error messages on a blue screen:
"Your PC ran into a problem and needs to restart. You can restart. For more information about this issue and
possible fixes, visit http://windows.com/stopcode. If you call a support person, give them this info: Stop code:
CRITICAL SERVICE FAILED"
"Your PC ran into a problem and needs to restart. We're just collecting some error info, and then we'll restart
for you. If you'd like to know more, you can search online later for this error: CRITICAL_SERVICE_FAILED"
Cause
There are various causes for stop errors. The most common causes are:
Problem with a driver
Corrupted system file or memory
Application accesses a forbidden sector of the memory
Solution
To resolve this problem, contact support and submit a dump file, which will help us diagnose the problem more
quickly, or try the following self-help solution.
3. Establish a remote desktop connection to the recovery VM.
Enable dump logs and Serial Console
The dump log and Serial Console will help us to do further troubleshooting.
To enable dump logs and Serial Console, run the following script.
1. Open an elevated command prompt session (run as administrator).
In this script, we assume that the drive letter that's assigned to the attached OS disk is F. You should replace
it with the appropriate value for your VM.



Replace the unsigned drivers

1. On the recovery VM, run the following command from an elevated command prompt. This command sets
the affected OS disk to start into safe mode at the next boot:
bcdedit /store <OS DISK you attached>:\boot\bcd /set {default} safeboot minimal
For example, if the OS disk that you attached is drive F, run the following command:
bcdedit /store F: boot\bcd /set {default} safeboot minimal
2. Detach the OS disk and then re-attach the OS disk to the affected VM. The VM will boot into Safe mode. If
you still experience the error, go to the optional step.
3. Open the Run box and run verifier to start the Driver Verifier Manager tool.
4. Select Automatically select unsigned drivers, and then click Next.
5. You will get the list of the driver files that are unsigned. Remember the file names.
6. Copy the same versions of these files from a working VM, and then replace these unsigned files.
7. Remove the safe boot settings:
bcdedit /store <OS DISK LETTER>:\boot\bcd /deletevalue {default} safeboot
8. Restart the VM.

Optional: Analyze the dump logs in Dump Crash mode
To analyze the dump logs yourself, follow these steps:
2. On the OS disk that you attached, browse to \windows\system32\config. Copy all the files as a backup in
case a rollback is required.
3. Start Registry Editor (regedit.exe).
4. Select the HKEY_LOCAL_MACHINE key. On the menu, select File > Load Hive.
5. Browse to the \windows\system32\config\SYSTEM folder on the OS disk that you attached. For the
name of the hive, enter BROKENSYSTEM. The new registry hive is displayed under the
HKEY_LOCAL_MACHINE key.
6. Browse to HKEY_LOCAL_MACHINE\BROKENSYSTEM\ControlSet00x\Control\CrashControl and
make the following changes:
Autoreboot = 0
CrashDumpEnabled = 2
7. Select BROKENSYSTEM. From the menu, select File > Unload Hive.
8. Modify the BCD setup to boot into debug mode. Run the following commands from an elevated command
prompt:
REM Setup some debugging flags on the boot manager

bcdedit /store <OS DISK LETTER>:\boot\bcd /set {bootmgr} default {<IDENTIFIER OF THE WINDOWS BOOT
LOADER>}
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {bootmgr} nointegritychecks on
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {bootmgr} integrityservices disable
REM Setup some debugging flags on the boot loader

bcdedit /store <OS DISK LETTER>:\boot\bcd /set {default} bootlog yes
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {default} bootstatuspolicy displayallfailures
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {default} nointegritychecks on
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {default} testsigning off
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {default} recoveryenabled no
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {default} integrityservices disable
9. Detach the OS disk and then re-attach the OS disk to the affected VM.
10. Boot the VM to see if it shows dump analysis. Find the file that fails to load. You need to replace this file with
a file from the working VM.
The following is sample of dump analysis. You can see that the FAILURE is on filecrypt.sys:
"FAILURE_BUCKET_ID: 0x5A_c0000428_IMAGE_filecrypt.sys".
kd> !analyze -v
*******************************************************************************
* * * Bugcheck Analysis * * *
*******************************************************************************
CRITICAL_SERVICE_FAILED (5a) Arguments: Arg1: 0000000000000001 Arg2: ffffd80f4bfe7070 Arg3:
ffffb00b0513d320 Arg4: ffffffffc0000428 Debugging
Details: ------------------
DUMP_CLASS: 1 DUMP_QUALIFIER: 401 BUILD_VERSION_STRING: 10.0.14393.1770 (rs1_release.170917-1700)
DUMP_TYPE: 1 BUGCHECK_P1: 1 BUGCHECK_P2: ffffd80f4bfe7070 BUGCHECK_P3: ffffb00b0513d320 BUGCHECK_P4:
ffffffffc0000428 BUGCHECK_STR: 0x5A_c0000428
CPU_COUNT: 1 CPU_MHZ: a22 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 3d CPU_STEPPING: 4
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: System CURRENT_IRQL: 0 ANALYSIS_SESSION_HOST: MININT-6RMM091 ANALYSIS_SESSION_TIME: 11-15-
2017 19:32:42.0841
ANALYSIS_VERSION: 10.0.16361.1001 amd64fre STACK_TEXT: ffffc701`1dc74948 fffff803`b2ff4b4a :
00000000`0000005a 00000000`00000001 ffffd80f`4bfe7070 ffffb00b`0513d320 : nt!KeBugCheckEx
[d:\rs1\minkernel\ntos\ke\amd64\procstat.asm @ 127] ffffc701`1dc74950 fffff803`b3205df3 :
ffffd80f`4bba9f58 ffffd80f`4bba9f58 ffffc701`1dc74b80 ffffd80f`00000006 : nt!IopLoadDriver+0x19f8e6
[d:\rs1\minkernel\ntos\ke\amd64\threadbg.asm @ 81]
RETRACER_ANALYSIS_TAG_STATUS: DEBUG_FLR_FAULTING_IP is not found THREAD_SHA1_HASH_MOD_FUNC:
eb79608c07faa1af62c0e61f25ff6bc1d6dfdb25 THREAD_SHA1_HASH_MOD_FUNC_OFFSET:
96a3a314834bb4e8443a8b7201525fc5dfc1878b THREAD_SHA1_HASH_MOD: 30a3e915496deaace47137d5b90c3ecc03746bf6
FOLLOWUP_NAME: wintriag
MODULE_NAME: filecrypt IMAGE_NAME: filecrypt.sys DEBUG_FLR_IMAGE_TIMESTAMP: 0 IMAGE_VERSION:
STACK_COMMAND: .thread ; .cxr ; kb FAILURE_BUCKET_ID: 0x5A_c0000428_IMAGE_filecrypt.sys BUCKET_ID:
0x5A_c0000428_IMAGE_filecrypt.sys PRIMARY_PROBLEM_CLASS: 0x5A_c0000428_IMAGE_filecrypt.sys TARGET_TIME:
2017-11-13T20:51:04.000Z OSBUILD: 14393 OSSERVICEPACK: 1770 SERVICEPACK_NUMBER: 0 OS_REVISION: 0
SUITE_MASK: 144 PRODUCT_TYPE: 3 OSPLATFORM_TYPE: x64 OSNAME: Windows 10 OSEDITION: Windows 10 Server
TerminalServer DataCenter OS_LOCALE: USER_LCID: 0 OSBUILD_TIMESTAMP: 2017-09-17 19:16:08
BUILDDATESTAMP_STR: 170917-1700 BUILDLAB_STR: rs1_release BUILDOSVER_STR: 10.0.14393.1770
ANALYSIS_SESSION_ELAPSED_TIME: bfc ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING:
km:0x5a_c0000428_image_filecrypt.sys FAILURE_ID_HASH: {35f25777-b01e-70a1-c502-f690dab6cb3a}
FAILURE_ID_REPORT_LINK: https://go.microsoft.com/fwlink/?LinkID=397724&FailureHash=35f25777-b01e-70a1-
c502-f690dab6cb3a
11. Once the VM is working and booting normally, remove the Dump Crash settings:
REM Restore the boot manager to default values

bcdedit /store <OS DISK LETTER>:\boot\bcd /deletevalue {bootmgr} nointegritychecks
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {bootmgr} integrityservices enable
REM Restore the boot loader to default values for an azure VM

bcdedit /store <OS DISK LETTER>:\boot\bcd /deletevalue {default} bootlog
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {default} bootstatuspolicy ignoreallfailures
bcdedit /store <OS DISK LETTER>:\boot\bcd /deletevalue {default} nointegritychecks
bcdedit /store <OS DISK LETTER>:\boot\bcd /deletevalue {default} testsigning
bcddit /store <OS DISK LETTER>:\boot\bcd /set {default} recoveryenabled no
bcdedit /store <OS DISK LETTER>:\boot\bcd /set {default} integrityservicesenable
Windows reboot loop on an Azure VM
This article describes the reboot loop you may experience on a Windows Virtual Machine (VM ) in Microsoft Azure.
Symptom
When you use Boot diagnostics to get the screenshots of a VM, you find the virtual machine is booting but the
boot process is getting interrupted and the process is starting over.
Cause
The reboot loop occurs because of the following causes:
Cause 1
There is a third-party service that is flagged as critical and it cannot be started. This causes the operating system to
reboot.
Cause 2
Some changes were made to the operating system. Usually, these are related to an update installation, application
installation, or a new policy. You may have to check the following logs for additional details:
Event Logs
CBS.logWindows
Update.log
Cause 3
File system corruption could cause this. However, it is difficult to diagnose and identify the change that causes the
corruption of the operating system.
Solution
To resolve this problem, back up the OS disk, and attach the OS disk to a rescue VM, and then follow the solution
options accordingly, or try the solutions one by one.
Solution for cause 1
1. Once the OS disk is attached to a working VM, make sure that the disk is flagged as Online in the Disk
Management console and note the drive letter of the partition that holds the \Windows folder.
2. If the disk is set to Offline, then set it to Online.
3. Create a copy of the \Windows\System32\config folder in case a rollback on the changes is needed.
4. On the rescue VM, open the Windows Registry Editor (regedit).
5. Select the HKEY_LOCAL_MACHINE key and then select File > Load Hive from the menu.
6. Browse to the SYSTEM file in the \Windows\System32\config folder.
7. Select Open, type BROKENSYSTEM for the name, expand the HKEY_LOCAL_MACHINE key, and then
you will see an additional key called BROKENSYSTEM.
8. Check which ControlSet the computer is booting from. You will see its key number in the following registry
key.
HKEY_LOCAL_MACHINE\BROKENSYSTEM\Select\Current
9. Check which is the criticality of the VM agent service through the following registry key.
HKEY_LOCAL_MACHINE\BROKENSYSTEM\ControlSet00x\Services\RDAgent\ErrorControl
10. If the value of the registry key is not set to 2, then go to the next mitigation.
11. If the value of the registry key is set to 2, then change the value from 2 to 1.
12. If any of the following keys exist and they have value 2 or 3, and then change these values to 1 accordingly:
HKEY_LOCAL_MACHINE\BROKENSYSTEM\ControlSet00x\Services\AzureWLBackupCoordinatorSvc\ErrorControl
HKEY_LOCAL_MACHINE\BROKENSYSTEM\ControlSet00x\Services\AzureWLBackupInquirySvc\ErrorControl
HKEY_LOCAL_MACHINE\BROKENSYSTEM\ControlSet00x\Services\AzureWLBackupPluginSvc\ErrorControl
13. Select the BROKENSYSTEM key and then select File > Load Hive from the menu.
14. Detach the OS disk from the troubleshooting VM.
15. Remove the disk from the troubleshooting VM and wait about 2 minutes for Azure to release this disk.
16. Create a new VM from the OS disk.
17. If the issue is fixed, then you may have to reinstall the RDAgent (WaAppAgent.exe).
Restore the VM to the last known good configuration, follow the steps in How to start Azure Windows VM with
Last Known Good Configuration.
NOTE
The following procedure should only be used as last resource. While restoring from regback may restore access to the
machine, the OS is not considered stable since there is data lost in the registry between the timestamp of the hive and the
current day. You need to build a new VM and make plans to migrate data.
1. Once the disk is attached to a troubleshooting VM, make sure that the disk is flagged as Online in the Disk
Management console.
2. Create a copy of the \Windows\System32\config folder in case a rollback on the changes is needed.
3. Copy the files in the \Windows\System32\config\regback folder and replace the files in the
\Windows\System32\config folder.
4. Remove the disk from the troubleshooting VM and wait about 2 minutes for Azure to release this disk.
5. Create a new VM from the OS disk.
Azure VM startup is stuck at Windows update
This article helps resolve the issue when your Virtual Machine (VM ) is stuck at the Windows Update stage during
startup.
NOTE
article covers using the Resource Manager deployment model. We recommend that you use this model for new deployments
instead of using the classic deployment model.
Symptom
A Windows VM doesn't start. When you check the screenshots in the Boot diagnostics window, you see that the
startup is stuck in the update process. The following are examples of messages that you may receive:
Installing Windows ##% Don't turn off your PC. This will take a while Your PC will restart several times
Keep your PC on until this is done. Installing update # of #...
We couldn't complete the updates Undoing changes Don't turn off your computer
Failure configuring Windows updates Reverting changes Do not turn off your computer
Error < error code > applying update operations ##### of ##### (\Regist...)
Fatal Error < error code > applying update operations ##### of ##### ($$...)
Solution
Depending on the number of updates that are getting installed or rolled backing, the update process can take a
while. Leave the VM in this state for 8 hours. If the VM is still in this state after that period, restart the VM from the
Azure portal, and see if it can start normally. If this step doesn't work, try the following solution.
Remove the update that causes the problem
3. Once the OS disk is attached on the recovery VM, run diskmgmt.msc to open Disk Management, and
ensure the attached disk is ONLINE. Take note of the drive letter that is assigned to the attached OS disk
holding the \windows folder. If the disk is encrypted, decrypt the disk before proceeding with next steps in
this document.
4. Open an elevated command prompt instance (Run as administrator). Run the following command to get the
list of the update packages that are on the attached OS disk:
dism /image:<Attached OS disk>:\ /get-packages > c:\temp\Patch_level.txt
For example, if the attached OS disk is drive F, run the following command:
dism /image:F:\ /get-packages > c:\temp\Patch_level.txt

5. Open the C:\temp\Patch_level.txt file, and then read it from the bottom up. Locate the update that's in
Install Pending or Uninstall Pending state. The following is a sample of the update status:
Package Identity : Package_for_RollupFix~31bf3856ad364e35~amd64~~17134.345.1.5

State : Install Pending
Release Type : Security Update
Install Time :
6. Remove the update that caused the problem:
dism /Image:<Attached OS disk>:\ /Remove-Package /PackageName:<PACKAGE NAME TO DELETE>
Example:
dism /Image:F:\ /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~17134.345.1.5
NOTE
Depending on the size of the package, the DISM tool will take a while to process the un-installation. Normally the
process will be completed within 16 minutes.
Troubleshooting API throttling errors
Azure Compute requests may be throttled at a subscription and on a per-region basis to help with the overall
performance of the service. We ensure all the calls to the Azure Compute Resource Provider (CRP ), which
manages resources under Microsoft.Compute namespace don't exceed the maximum allowed API request rate.
This document describes API throttling, details on how to troubleshoot throttling issues, and best practices to avoid
being throttled.
Throttling by Azure Resource Manager vs Resource Providers

As the front door to Azure, Azure Resource Manager does the authentication and first-order validation and
throttling of all incoming API requests. Azure Resource Manager call rate limits and related diagnostic response
HTTP headers are described here.
When an Azure API client gets a throttling error, the HTTP status is 429 Too Many Requests. To understand if the
request throttling is done by Azure Resource Manager or an underlying resource provider like CRP, inspect the
x-ms-ratelimit-remaining-subscription-reads for GET requests and x-ms-ratelimit-remaining-subscription-writes
response headers for non-GET requests. If the remaining call count is approaching 0, the subscription’s general call
limit defined by Azure Resource Manager has been reached. Activities by all subscription clients are counted
together. Otherwise, the throttling is coming from the target resource provider (the one addressed by the
/providers/<RP> segment of the request URL ).
Call rate informational response headers

HEADER VALUE FORMAT EXAMPLE DESCRIPTION
x-ms-ratelimit-remaining- <source RP>/<policy or Microsoft.Compute/HighCos Remaining API call count for

resource bucket>;<count> tGet3Min;159 the throttling policy covering
the resource bucket or
operation group including
the target of this request
x-ms-request-charge <count> 1 The number of call counts

“charged” for this HTTP
request toward the
applicable policy’s limit. This
is most typically 1. Batch
requests, such as for scaling
a virtual machine scale set,
can charge multiple counts.
Note that an API request can be subjected to multiple throttling policies. There will be a separate
x-ms-ratelimit-remaining-resource header for each policy.
Here is a sample response to delete virtual machine scale set request.
x-ms-ratelimit-remaining-resource: Microsoft.Compute/DeleteVMScaleSet3Min;107
x-ms-ratelimit-remaining-resource: Microsoft.Compute/DeleteVMScaleSet30Min;587
x-ms-ratelimit-remaining-resource: Microsoft.Compute/VMScaleSetBatchedVMRequests5Min;3704
x-ms-ratelimit-remaining-resource: Microsoft.Compute/VmssQueuedVMOperations;4720
Throttling error details
The 429 HTTP status is commonly used to reject a request because a call rate limit is reached. A typical throttling
error response from Compute Resource Provider will look like the example below (only relevant headers are
shown):
HTTP/1.1 429 Too Many Requests

x-ms-ratelimit-remaining-resource: Microsoft.Compute/HighCostGet3Min;46
x-ms-ratelimit-remaining-resource: Microsoft.Compute/HighCostGet30Min;0
Retry-After: 1200
Content-Type: application/json; charset=utf-8
{
"code": "OperationNotAllowed",
"message": "The server rejected the request because too many requests have been received for this
subscription.",
"details": [
{
"code": "TooManyRequests",
"target": "HighCostGet30Min",
"message": "{\"operationGroup\":\"HighCostGet30Min\",\"startTime\":\"2018-06-
29T19:54:21.0914017+00:00\",\"endTime\":\"2018-06-
29T20:14:21.0914017+00:00\",\"allowedRequestCount\":800,\"measuredRequestCount\":1238}"
}
]
}
The policy with remaining call count of 0 is the one due to which the throttling error is returned. In this case that is
HighCostGet30Min . The overall format of the response body is the general Azure Resource Manager API error
format (conformant with OData). The main error code, OperationNotAllowed , is the one Compute Resource
Provider uses to report throttling errors (among other types of client errors). The message property of the inner
error(s) contains a serialized JSON structure with the details of the throttling violation.
As illustrated above, every throttling error includes the Retry-After header, which provides the minimum number
of seconds the client should wait before retrying the request.
API call rate and throttling error analyzer

A preview version of a troubleshooting feature is available for the Compute resource provider’s API. These
PowerShell cmdlets provide statistics about API request rate per time interval per operation and throttling
violations per operation group (policy):
Export-AzLogAnalyticRequestRateByInterval
Export-AzLogAnalyticThrottledRequest
The API call stats can provide great insight into the behavior of a subscription’s client(s) and enable easy
identification of call patterns that cause throttling.
A limitation of the analyzer for the time being is that it does not count requests for disk and snapshot resource
types (in support of managed disks). Since it gathers data from CRP’s telemetry, it also cannot help in identifying
throttling errors from ARM. But those can be identified easily based on the distinctive ARM response headers, as
discussed earlier.
The PowerShell cmdlets are using a REST service API, which can be easily called directly by clients (though with no
formal support yet). To see the HTTP request format, run the cmdlets with -Debug switch or snoop on their
execution with Fiddler.
Best practices
Do not retry Azure service API errors unconditionally and/or immediately. A common occurrence is for client
code to get into a rapid retry loop when encountering an error that’s not retry-able. Retries will eventually
exhaust the allowed call limit for the target operation’s group and impact other clients of the subscription.
In high-volume API automation cases, consider implementing proactive client-side self-throttling when the
available call count for a target operation group drops below some low threshold.
When tracking async operations, respect the Retry-After header hints.
If the client code needs information about a particular Virtual Machine, query that VM directly instead of listing
all VMs in the containing resource group or the entire subscription and then picking the needed VM on the
client side.
If client code needs VMs, disks and snapshots from a specific Azure location, use location-based form of the
query instead of querying all subscription VMs and then filtering by location on the client side:
GET /subscriptions/<subId>/providers/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-
03-30
query to Compute Resource Provider regional endpoints.
When creating or updating API resources in particular, VMs and virtual machine scale sets, it is far more
efficient to track the returned async operation to completion than do polling on the resource URL itself (based
on the provisioningState ).
Next steps
For more information about retry guidance for other services in Azure, see Retry guidance for specific services
Troubleshoot a problem Azure VM by using nested
virtualization in Azure
This article shows how to create a nested virtualization environment in Microsoft Azure, so you can mount the disk
of the problem VM on the Hyper-V host (Rescue VM ) for troubleshooting purposes.
Prerequisites
To mount the problem VM, the Rescue VM must meet the following prerequisites:
The Rescue VM must be in the same location as the problem VM.
The Rescue VM must be in the same resource group as the problem VM.
The Rescue VM must use the same type of Storage Account (Standard or Premium) as the problem VM.
Step 1: Create a Rescue VM and install Hyper-V role

1. Create a new Rescue VM:
Operating system: Windows Server 2016 Datacenter
Size: Any V3 series with at least two cores that support nested virtualization. For more information,
see Introducing the new Dv3 and Ev3 VM sizes.
Same location, Storage Account, and Resource Group as the problem VM.
Select the same storage type as the problem VM (Standard or Premium).
2. After the Rescue VM is created, remote desktop to the Rescue VM.
3. In Server Manager, select Manage > Add Roles and Features.
4. In the Installation Type section, select Role-based or feature-based installation.
5. In the Select destination server section, make sure that the Rescue VM is selected.
6. Select the Hyper-V role > Add Features.
7. Select Next on the Features section.
8. If a virtual switch is available, select it. Otherwise select Next.
9. On the Migration section, select Next
10. On the Default Stores section, select Next.
11. Check the box to restart the server automatically if required.
12. Select Install.
13. Allow the server to install the Hyper-V role. This takes a few minutes and the server will reboot
automatically.
Step 2: Create the problem VM on the Rescue VM’s Hyper-V server

1. Record the name of the disk in the problem VM, and then delete the problem VM. Make sure that you keep
all attached disks.
2. Attach the OS disk of your problem VM as a data disk of the Rescue VM.
a. After the problem VM is deleted, go to the Rescue VM.
b. Select Disks, and then Add data disk.
c. Select the problem VM’s disk, and then select Save.
3. After the disk has successfully attached, remote desktop to the Rescue VM.
4. Open Disk Management (diskmgmt.msc). Make sure that the disk of the problem VM is set to Offline.
5. Open Hyper-V Manager: In Server Manager, select the Hyper-V role. Right-click the server, and then
select the Hyper-V Manager.
6. In the Hyper-V Manager, right-click the Rescue VM, and then select New > Virtual Machine > Next.
7. Type a name for the VM, and then select Next.
8. Select Generation 1.
9. Set the startup memory at 1024 MB or more.
10. If applicable select the Hyper-V Network Switch that was created. Else move to the next page.
11. Select Attach a virtual hard disk later.
12. Select Finish when the VM is created.

13. Right-click the VM that you created, and then select Settings.
14. Select IDE Controller 0, select Hard Drive, and then click Add.
15. In Physical Hard Disk, select the disk of the problem VM that you attached to the Azure VM. If you do not
see any disks listed, check if the disk is set to offline by using Disk management.
16. Select Apply, and then select OK.

17. Double-click on the VM, and then start it.
18. Now you can work on the VM as the on-premises VM. You could follow any troubleshooting steps you
need.
Step 3: Re-create your Azure VM in Azure

1. After you get the VM back online, shut down the VM in the Hyper-V manager.
2. Go to the Azure portal and select the Rescue VM > Disks, copy the name of the disk. You will use the name
in the next step. Detach the fixed disk from the Rescue VM.
3. Go to All resources, search for the disk name, and then select the disk.
4. Click Create VM.

You can also use Azure PowerShell to create the VM from the disk. For more information, see Create the new VM
from an existing disk by using PowerShell.
Next steps
VM.
Understand a system reboot for Azure VM
Azure virtual machines (VMs) might sometimes reboot for no apparent reason, without evidence of your having
initiated the reboot operation. This article lists the actions and events that can cause VMs to reboot and provides
insight into how to avoid unexpected reboot issues or reduce the impact of such issues.
Configure the VMs for high availability

The best way to protect an application that's running on Azure against VM reboots and downtime is to configure
the VMs for high availability.
To provide this level of redundancy to your application, we recommend that you group two or more VMs in an
availability set. This configuration ensures that during either a planned or unplanned maintenance event, at least
one VM is available and meets the 99.95 percent Azure SLA.
For more information about availability sets, see the following articles:
Manage the availability of VMs
Configure availability of VMs
Resource Health information

Azure Resource Health is a service that exposes the health of individual Azure resources and provides actionable
guidance for troubleshooting problems. In a cloud environment where it isn’t possible to directly access servers or
infrastructure elements, the goal of Resource Health is to reduce the time that you spend on troubleshooting. In
particular, the aim is to reduce the time that you spend determining whether the root of the problem lies in the
application or in an event inside the Azure platform. For more information, see Understand and use Resource
Health.
Actions and events that can cause the VM to reboot

Planned maintenance
Microsoft Azure periodically performs updates across the globe to improve the reliability, performance, and
security of the host infrastructure that underlies VMs. Many of these updates, including memory-preserving
updates, are performed without any impact on your VMs or cloud services.
However, some updates do require a reboot. In such cases, the VMs are shut down while we patch the
infrastructure, and then the VMs are restarted.
To understand what Azure planned maintenance is and how it can affect the availability of your Linux VMs, see the
articles listed here. The articles provide background about the Azure planned maintenance process and how to
schedule planned maintenance to further reduce the impact.
Planned maintenance for VMs in Azure
How to schedule planned maintenance on Azure VMs
Memory-preserving updates
For this class of updates in Microsoft Azure, users experience no impact on their running VMs. Many of these
updates are to components or services that can be updated without interfering with the running instance. Some are
platform infrastructure updates on the host operating system that can be applied without a reboot of the VMs.
These memory-preserving updates are accomplished with technology that enables in-place live migration. When it
is being updated, the VM is placed in a paused state. This state preserves the memory in RAM while the underlying
host operating system receives the necessary updates and patches. The VM is resumed within 30 seconds of being
paused. After the VM is resumed, its clock is automatically synchronized.
Because of the short pause period, deploying updates through this mechanism greatly reduces the impact on the
VMs. However, not all updates can be deployed in this way.
Multi-instance updates (for VMs in an availability set) are applied one update domain at a time.
NOTE
Linux machines that have old kernel versions are affected by a kernel panic during this update method. To avoid this issue,
update to kernel version 3.10.0-327.10.1 or later. For more information, see An Azure Linux VM on a 3.10-based kernel
panics after a host node upgrade.
User-initiated reboot or shutdown actions

If you perform a reboot from the Azure portal, Azure PowerShell, command-line interface, or Reset API, you can
find the event in the Azure Activity Log.
If you perform the action from the VM's operating system, you can find the event in the system logs.
Other scenarios that usually cause the VM to reboot include multiple configuration-change actions. You'll
ordinarily see a warning message indicating that executing a particular action will result in a reboot of the VM.
Examples include any VM resize operations, changing the password of the administrative account, and setting a
static IP address.
Azure Security Center and Windows Update
Azure Security Center monitors daily Windows and Linux VMs for missing operating-system updates. Security
Center retrieves a list of available security and critical updates from Windows Update or Windows Server Update
Services (WSUS ), depending on which service is configured on a Windows VM. Security Center also checks for the
latest updates for Linux systems. If your VM is missing a system update, Security Center recommends that you
apply system updates. The application of these system updates is controlled through the Security Center in the
Azure portal. After you apply some updates, VM reboots might be required. For more information, see Apply
system updates in Azure Security Center.
Like on-premises servers, Azure does not push updates from Windows Update to Windows VMs, because these
machines are intended to be managed by their users. You are, however, encouraged to leave the automatic
Windows Update setting enabled. Automatic installation of updates from Windows Update can also cause reboots
to occur after the updates are applied. For more information, see Windows Update FAQ.
Other situations affecting the availability of your VM
There are other cases in which Azure might actively suspend the use of a VM. You'll receive email notifications
before this action is taken, so you'll have a chance to resolve the underlying issues. Examples of issues that affect
VM availability include security violations and the expiration of payment methods.
Host server faults
The VM is hosted on a physical server that is running inside an Azure datacenter. The physical server runs an agent
called the Host Agent in addition to a few other Azure components. When these Azure software components on
the physical server become unresponsive, the monitoring system triggers a reboot of the host server to attempt
recovery. The VM is usually available again within five minutes and continues to live on the same host as
previously.
Server faults are usually caused by hardware failure, such as the failure of a hard disk or solid-state drive. Azure
continuously monitors these occurrences, identifies the underlying bugs, and rolls out updates after the mitigation
has been implemented and tested.
Because some host server faults can be specific to that server, a repeated VM reboot situation might be improved
by manually redeploying the VM to another host server. This operation can be triggered by using the redeploy
option on the details page of the VM, or by stopping and restarting the VM in the Azure portal.
Auto -recovery
If the host server cannot reboot for any reason, the Azure platform initiates an auto-recovery action to take the
faulty host server out of rotation for further investigation.
All VMs on that host are automatically relocated to a different, healthy host server. This process is usually complete
within 15 minutes. To learn more about the auto-recovery process, see Auto-recovery of VMs.
Unplanned maintenance
On rare occasions, the Azure operations team might need to perform maintenance activities to ensure the overall
health of the Azure platform. This behavior might affect VM availability, and it usually results in the same auto-
recovery action as described earlier.
Unplanned maintenance include the following:
Urgent node defragmentation
Urgent network switch updates
VM crashes
VMs might restart because of issues within the VM itself. The workload or role that's running on the VM might
trigger a bug check within the guest operating system. For help determining the reason for the crash, view the
system and application logs for Windows VMs, and the serial logs for Linux VMs.
Storage -related forced shutdowns
VMs in Azure rely on virtual disks for operating system and data storage that is hosted on the Azure Storage
infrastructure. Whenever the availability or connectivity between the VM and the associated virtual disks is affected
for more than 120 seconds, the Azure platform performs a forced shutdown of the VMs to avoid data corruption.
The VMs are automatically powered back on after storage connectivity has been restored.
The duration of the shutdown can be as short as five minutes but can be significantly longer. The following is one
of the specific cases that is associated with storage-related forced shutdowns:
Exceeding IO limits
VMs might be temporarily shut down when I/O requests are consistently throttled because the volume of I/O
operations per second (IOPS ) exceeds the I/O limits for the disk. (Standard disk storage is limited to 500 IOPS.) To
mitigate this issue, use disk striping or configure the storage space inside the guest VM, depending on the
workload. For details, see Configuring Azure VMs for Optimal Storage Performance.
Other incidents
In rare circumstances, a widespread issue can affect multiple servers in an Azure datacenter. If this issue occurs, the
Azure team sends email notifications to the affected subscriptions. You can check the Azure Service Health
dashboard and the Azure portal for the status of ongoing outages and past incidents.
Use remote tools to troubleshoot Azure VM issues
When you troubleshoot issues on an Azure virtual machine (VM ), you can connect to the VM by using the remote
tools that are discussed in this article instead of using Remote Desktop Protocol (RDP ).
Serial Console
Use Virtual Machine Serial Console to run commands on the remote Azure VM.
Remote CMD
Download PsExec. Connect to the VM by running the following command:
psexec \\<computer>-u user -s cmd
NOTE
The command must be run on a computer that’s in the same VNET.
DIP or HostName can be used to replace <computer>.
The -s parameter makes sure that the command is invoked by using System Account (administrator permission).
PsExec uses TCP ports 135 and 445. Therefore, the two ports have to be open on the Firewall.
Run Commands
See Run PowerShell scripts in your Windows VM with Run Command for more information about how to use the
Run Commands feature to run scripts on the VM.
Customer Script Extension

You can use the Custom Script Extension feature to run a custom script on the target VM. To use this feature, the
following conditions must be met:
The VM has connectivity.
Azure Agent is installed and is working as expected on the VM.
The extension was not previously installed on the VM.
The extension will inject the script only the first time that it’s used. If you use this feature later, the extension
will recognize that it was already used and will not upload the new script.
You have to upload your script to a storage account and generate its own container. Then, run the following script
in Azure PowerShell on a computer that has connectivity to the VM.
For V1 VMs
#Setup the basic variables
$subscriptionID = "<<SUBSCRIPTION ID>>"
$storageAccount = "<<STORAGE ACCOUNT>>"
$localScript = "<<FULL PATH OF THE PS1 FILE TO EXECUTE ON THE VM>>"
$blobName = "file.ps1" #Name you want for the blob in the storage
$vmName = "<<VM NAME>>"
$vmCloudService = "<<CLOUD SERVICE>>" #Resource group/Cloud Service where the VM is hosted. I.E.: For
"demo305.cloudapp.net" the cloud service is going to be demo305
#Setup the Azure Powershell module and ensure the access to the subscription
Import-Module Azure
Add-AzureAccount #Ensure Login with account associated with subscription ID
Get-AzureSubscription -SubscriptionId $subscriptionID | Select-AzureSubscription
#Setup the access to the storage account and upload the script
$storageKey = (Get-AzureStorageKey -StorageAccountName $storageAccount).Primary
$context = New-AzureStorageContext -StorageAccountName $storageAccount -StorageAccountKey $storageKey
$container = "cse" + (Get-Date -Format yyyyMMddhhmmss)<
New-AzureStorageContainer -Name $container -Permission Off -Context $context
Set-AzureStorageBlobContent -File $localScript -Container $container -Blob $blobName -Context $context
#Push the script into the VM

$vm = Get-AzureVM -ServiceName $vmCloudService -Name $vmName
Set-AzureVMCustomScriptExtension "CustomScriptExtension" -VM $vm -StorageAccountName $storageAccount -
StorageAccountKey $storagekey -ContainerName $container -FileName $blobName -Run $blobName | Update-AzureVM
For V2 VMs
NOTE
PowerShell.
#Setup the basic variables

$subscriptionID = "<<SUBSCRIPTION ID>>"
$storageAccount = "<<STORAGE ACCOUNT>>"
$storageRG = "<<RESOURCE GROUP OF THE STORAGE ACCOUNT>>"
$localScript = "<<FULL PATH OF THE PS1 FILE TO EXECUTE ON THE VM>>"
$blobName = "file.ps1" #Name you want for blob in storage
$vmName = "<<VM NAME>>"
$vmResourceGroup = "<<RESOURCE GROUP>>"
$vmLocation = "<<DATACENTER>>"
#Setup the Azure Powershell module and ensure the access to the subscription
Login-AzAccount #Ensure Login with account associated with subscription ID
Get-AzSubscription -SubscriptionId $subscriptionID | Select-AzSubscription
#Setup the access to the storage account and upload the script
$storageKey = (Get-AzStorageAccountKey -ResourceGroupName $storageRG -Name $storageAccount).Value[0]
$context = New-AzureStorageContext -StorageAccountName $storageAccount -StorageAccountKey $storageKey
$container = "cse" + (Get-Date -Format yyyyMMddhhmmss)
New-AzureStorageContainer -Name $container -Permission Off -Context $context
Set-AzureStorageBlobContent -File $localScript -Container $container -Blob $blobName -Context $context
#Push the script into the VM

Set-AzVMCustomScriptExtension -Name "CustomScriptExtension" -ResourceGroupName $vmResourceGroup -VMName
$vmName -Location $vmLocation -StorageAccountName $storageAccount -StorageAccountKey $storagekey -
ContainerName $container -FileName $blobName -Run $blobName
Remote PowerShell
NOTE
TCP Port 5986 (HTTPS) must be open so that you can use this option.
For ARM VMs, you must open port 5986 on the network security group (NSG). For more information, see Security groups.
For RDFE VMs, you must have an endpoint that has a private port (5986) and a public port. Then, you have to also open
that public facing-port on the NSG.
Set up the client computer

To use PowerShell to connect to the VM remotely, you first have to set up the client computer to allow the
connection. To do this, add the VM to the PowerShell trusted hosts list by running the following command, as
appropriate.
To add one VM to trusted hosts list:
Set-Item wsman:\localhost\Client\TrustedHosts -value <ComputerName>
To add multiple VMs to trusted hosts list:
Set-Item wsman:\localhost\Client\TrustedHosts -value <ComputerName1>,<ComputerName2>
To add all computers to the trusted hosts list:
Set-Item wsman:\localhost\Client\TrustedHosts -value *
Enable RemotePS on the VM

For Classic VMs, use Custom Script Extension to run the following script:
Enable-PSRemoting -Force
New-NetFirewallRule -Name "Allow WinRM HTTPS" -DisplayName "WinRM HTTPS" -Enabled True -Profile Any -Action
Allow -Direction Inbound -LocalPort 5986 -Protocol TCP
$thumbprint = (New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation
Cert:\LocalMachine\My).Thumbprint
$command = "winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=""$env:computername"";
CertificateThumbprint=""$thumbprint""}"
cmd.exe /C $command
For ARM VMs, use Run Commands from the portal to run the EnableRemotePS script:
Connect to the VM
Run the following command, depending on the client computer location:
Outside the VNET or deployment
For a classic VM, run the following command:
$Skip = New-PSSessionOption -SkipCACheck -SkipCNCheck

Enter-PSSession -ComputerName "<<CLOUDSERVICENAME.cloudapp.net>>" -port "<<PUBLIC PORT
NUMBER>>" -Credential (Get-Credential) -useSSL -SessionOption $Skip
For an ARM VM, first add a DNS name to the public IP address. For detailed steps, see Create a fully
qualified domain name in the Azure portal for a Windows VM. Then, run the following command:

Enter-PSSession -ComputerName "<<DNSname.DataCenter.cloudapp.azure.com>>" -port "5986" -
Credential (Get-Credential) -useSSL -SessionOption $Skip
Inside the VNET or deployment, run the following command:

Enter-PSSession -ComputerName "<<HOSTNAME>>" -port 5986 -Credential (Get-Credential) -useSSL -
SessionOption $Skip
NOTE
Setting the SkipCaCheck flag bypasses the requirement to import a certificate to the VM when you start the session.
You can also use the Invoke-Command cmdlet to run a script on the VM remotely:
Invoke-Command -ComputerName "<<COMPUTERNAME>" -ScriptBlock {"<<SCRIPT BLOCK>>"}
Remote Registry
NOTE
TCP port 135 or 445 must be open in order to use this option.
For ARM VMs, you have to open port 5986 on the NSG. For more information, see Security groups.
For RDFE VMs, you must have an endpoint that has a private port 5986 and a public port. You have to also open that
public-facing port on the NSG.
1. From another VM on the same VNET, open the registry editor (regedit.exe).
2. Select File >Connect Network Registry.
3. Locate the target VM by hostname or Dynamic IP (preferable) by entering it in the "Enter the object
name to select" box.
4. Enter the credentials for the target VM.

5. Make any necessary registry changes.
Remote Services Console

NOTE
TCP ports 135 or 445 must be open in order to use this option.
For ARM VMs, you have to open port 5986 on the NSG. For more information, see Security groups.
For RDFE VMs, you must have an endpoint that has a private port 5986 and a public port. Then, you have to also open that
public-facing port on the NSG.
1. From another VM on the same VNET, open an instance of Services.msc.
2. Right-click Services (Local).
3. Select Connect to another computer.
4. Enter the Dynamic IP of the target VM.
5. Make any necessary changes to the services.
Next Steps
Enter-PSSession
Custom Script Extension for Windows using the classic deployment model
PsExec is part of the PSTools Suite.
For more information about the PSTools Suite, see PSTools Suite.

Azure VM Issues Troubleshooting Guide

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Azure VM Issues Troubleshooting Guide

Diunggah oleh

Hak Cipta:

Format Tersedia

Contents

Troubleshooting Azure VMs

Resize a VM or add VMs to an existing availability set

Restart partially stopped (deallocated) VMs

Restart fully stopped (deallocated) VMs

LEGACY VM-SERIES/SIZE RECOMMENDED NEWER VM-SERIES/SIZE MORE INFORMATION

Av1-series Av2-series https://azure.microsoft.com/blog/new-

Dv1 or DSv1-series (D1 to D5) Dv3 or DSv3-series https://azure.microsoft.com/blog/introd

Dv1 or DSv1-series (D11 to D14) Ev3 or ESv3-series

D15v2 or DS15v2 If you are using theResource Manager https://azure.microsoft.com/blog/new-

Allocation failures for large deployments (more than 500 cores)

Resize a VM or add VMs or role instances to an existing cloud service

Restart partially stopped (deallocated) VMs

Restart fully stopped (deallocated) VMs

Staging/production deployments (platform as a service only)

Affinity group (VM/service proximity)

Affinity-group-based virtual network

Reset by using the Azure portal

Reset by using the VMAccess extension and PowerShell

Reset the Remote Desktop Services configuration

Set-AzVMAccessExtension -ResourceGroupName "myResoureGroup" -VMName "myVM" -Name "myVMAccess" -Location

Quick troubleshooting steps

Ways to troubleshoot RDP issues

Troubleshoot using the Azure portal

Troubleshoot using Azure PowerShell

Set-AzVMAccessExtension -ResourceGroupName "myResourceGroup" `

$rules = Get-AzNetworkSecurityGroup -ResourceGroupName "myResourceGroup" `

Set-AzVMAccessExtension -ResourceGroupName "myResourceGroup" `

Restart-AzVM -ResourceGroup "myResourceGroup" -Name "myVM"

Set-AzVM -Redeploy -ResourceGroupName "myResourceGroup" -Name "myVM"

Troubleshoot VMs created using the Classic deployment model

Troubleshoot specific RDP errors

Components of a Remote Desktop connection

Detailed troubleshooting steps

Source 1: Remote Desktop client computer

If you cannot, check for the following settings on your computer:

Source 2: Organization intranet edge device

Source 3: Cloud service endpoint and ACL

Source 4: Network Security Groups

Source 5: Windows-based Azure VM

$subscr="<Name of your Azure subscription>"

$uri = Get-AzureWinRMUri -ServiceName $serviceName -Name $vmName

Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name

Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name

Exit the remote Azure PowerShell session by using this command.

wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Service Control Manager'] and EventID=7022

3. If the DHCP is stopped, try to start the service

Try to connect to the VM and see if the problem is resolved.

5- ACCESS DENIED See DHCP Client service is stopped because of an Access

1053 - ERROR_SERVICE_REQUEST_TIMEOUT See DHCP Client service crashes or hangs.

1058 - ERROR_SERVICE_DISABLED See DHCP Client service is disabled.

1059 - ERROR_CIRCULAR_DEPENDENCY Contact support to get your problem resolved quickly.

1067 - ERROR_PROCESS_ABORTED See DHCP Client service crashes or hangs.

1068 - ERROR_SERVICE_DEPENDENCY_FAIL Contact support to get your problem resolved quickly.

1070 - ERROR_SERVICE_START_HANG See DHCP Client service crashes or hangs.

1077 - ERROR_SERVICE_NEVER_STARTED See DHCP Client service is disabled.

1079 - ERROR_DIFERENCE_SERVICE_ACCOUNT Contact support to get your problem resolved quickly.

1053 Contact support to get your problem resolved quickly.

DHCP Client service is stopped because of an Access Denied error

3. Now start a procmon trace:

procmon /Quiet /Minimized /BackingFile c:\temp\ProcMonTrace.PML

When it fails, terminate the Process Monitor trace:

5. Collect the c:\temp\ProcMonTrace.PML file: