Professional Documents
Culture Documents
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.
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.
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
11/1/2018 • 5 minutes to read • Edit Online
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
Restart partially stopped (deallocated) VMs
Restart fully stopped (deallocated) VMs
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.
The following issues with creating an RDP to connection to a VM are covered in this section:
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
Reset Remote Desktop Services or its administrator
password in a Windows VM
3/25/2019 • 3 minutes to read • Edit Online
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
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.
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
4/22/2019 • 11 minutes to read • Edit Online
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.
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.
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.
Select your VM in the Azure portal. Scroll down the settings pane to the Support + Troubleshooting
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.
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. 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.
Select your VM in the Azure portal. Scroll down the settings pane to the Support + Troubleshooting
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.
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.
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.
The follow example resets the RDP connection on a VM named myVM in the WestUS location and in the
resource group named myResourceGroup :
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 :
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 :
4. Restart your VM. This troubleshooting step can correct any underlying issues the VM itself is having.
The following example restarts the VM named myVM in the resource group named myResourceGroup :
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 :
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.
7. 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.
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.
Select your VM in the Azure portal. Scroll down the settings pane to the Support + Troubleshooting
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.
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. Enter your username and a new
password. Finally, click the Save button:
6. 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:
7. 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.
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
11/7/2018 • 8 minutes to read • Edit Online
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.
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.
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.
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.
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.
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.
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.
Verify that the port has been changed to 3389 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.
Additional resources
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
3/29/2019 • 5 minutes to read • Edit Online
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
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.
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:
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
sc start DHCP
4. Query the service again to make sure that the service is started successfully.
sc query DHCP
ERROR SOLUTION
1069 - ERROR_SERVICE_LOGON_FAILED See DHCP Client service fails because of logon failure
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)
4. Reproduce the problem by starting the service that's generating the Access Denied message:
sc start DHCP
procmon /Terminate
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 start DHCP
sc query DHCP
sc start DHCP
sc stop DHCP
sc start DHCP
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
12/5/2018 • 2 minutes to read • Edit Online
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
10/31/2018 • 4 minutes to read • Edit Online
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.
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.
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".
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
11/1/2018 • 3 minutes to read • Edit Online
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:
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:
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:
If the LicensingMode value is set to any value other than 4, per user, then set the value to 4:
If the SpecifiedLicenseServers value doesn't exist, or it has incorrect license server information,
then change it as follows:
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:
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:
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.
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
sc start TermService
7. Query the service again to make sure that the service is started successfully:
sc query TermService
8. If the service fails to start, follow the solution based on the error you received:
ERROR SUGGESTION
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)
4. Reproduce the problem by starting the service that's giving Access Denied:
sc start TermService
procmon /Terminate
sc start TermService
sc query TermService
sc start TermService
sc start TermService
4. Detach the OS disk and recreate the VM. Then check whether the issue is resolved.
This article describes an error that you may experience when you try to connect to a virtual machine (VM ) in
Microsoft Azure.
NOTE
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
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
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 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:
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:
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:
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
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:
md c:\temp
takeown /f "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /a /r
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:
2. To prevent the AD policy from overwriting the changes, stop the group policy update temporarily:
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:
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
Attach the OS disk to a recovery VM
1. Attach the OS disk to a recovery VM.
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.
Md F:\temp
takeown /f "F:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /a /r
3. If the key doesn't exist, or its value is 0, enable the protocol by running the following scripts:
4. Enable NLA:
REM Enable NLA
5. Detach the OS disk and recreate the VM, and then check whether the issue is resolved.
Remote Desktop disconnects frequently in Azure VM
2/7/2019 • 5 minutes to read • Edit Online
This article explains how to troubleshoot frequent disconnections to an Azure virtual machine (VM ) through
Remote Desktop Protocol RDP ).
NOTE
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
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.
3. Lower the encryption level to the minimum setting to allow legacy RDP clients to connect.
12. Restart the VM, and try again to connect to it by using RDP.
Repair the VM offline
1. Attach the OS disk to a recovery VM.
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:
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.
16. Set the RDP Session Idle Time control: REG ADD
"HKLM\BROKENSYSTEM\ControlSet001\control\Terminal Server\Winstations\RDP -Tcp" /v
'fInheritMaxIdleTime' /t REG_DWORD /d 1 /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
3/15/2019 • 5 minutes to read • Edit Online
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
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:
If the command returns 0, the terminal server is disabled. Then, enable the terminal server as follows:
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.
If the command returns 1, the Terminal Server module is set to drain mode. Then, set the module to
working mode as follows:
If the command returns 1, you can't connect to the terminal server. Then, enable the connection as follows:
If the command returns 0, the RDP listener is disabled. Then, enable the listener as follows:
If the command returns 1, you can't connect to the RDP listener. Then, enable the connection as follows:
6. If the VM is domain joined, check the following registry key to see if there is a group policy that will disable
RDP.
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.
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
An authentication error has occurred. The Local Security Authority cannot be contacted.
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.
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:
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:
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:
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
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:
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:
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:
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:
For other protocol versions, you can run the following commands:
NOTE
Get the SSH/TLS version x.x from the Guest OS Logs on the SCHANNEL errors.
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
12/5/2018 • 7 minutes to read • Edit Online
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.
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:
remove-module psreadline
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
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
Stop-Service -Name "SessionEnv"
Start-Service -Name "SessionEnv"
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.
NOTE
At this point, if you refresh the store from mmc, the certificate reappears.
You can also try to delete the key so that the RDP uses the self-signed certificate for RDP:
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:
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Schannel'] and EventID=36871 and
TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
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:
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
12/10/2018 • 2 minutes to read • Edit Online
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
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
article covers using the Resource Manager deployment model, which we recommend using for new deployments instead of
the classic deployment model.
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
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 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:
For example, if the interwork interface names "Ethernet 2", run the following command:
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
12/10/2018 • 2 minutes to read • Edit Online
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
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
article covers using the Resource Manager deployment model, which we recommend using for new deployments instead of
the classic deployment model.
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
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 enable the interface for the VM, use Serial control 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 the state of the network interface:
For example, if the interwork interface is named "Ethernet 2", run the following command:
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.
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
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
article covers using the Resource Manager deployment model, which we recommend using for new deployments instead of
the classic deployment model.
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
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 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
1. Connect to Serial Console and open CMD instance. If the Serial Console is not enabled on your VM, see
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:
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.
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.
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.
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.
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.
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:
4. Check the boot configuration data to make sure that the safeboot flag is removed:
5. Detach the OS disk and recreate the VM. Then check whether the issue is resolved.
Disable the guest OS Firewall in Azure VM
2/25/2019 • 4 minutes to read • Edit Online
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
Set-ItemProperty -Path
'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\PublicProfile' -name
"EnableFirewall" -Value 0
Set-ItemProperty -Path
'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.
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.
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.
<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.
2. Start a Remote Desktop connection to the 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'
Set-ItemProperty -Path $key -name 'EnableFirewall' -Value 0 -Type Dword -force
$key =
'BROKENSYSTEM\ControlSet00'+$ControlSet+'\services\SharedAccess\Parameters\FirewallPolicy\StandardProfil
e'
Set-ItemProperty -Path $key -name 'EnableFirewall' -Value 0 -Type Dword -force
# 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'
Set-ItemProperty -Path $key -name 'EnableFirewall' -Value 0 -Type Dword -force
$key = 'HKLM:\BROKENSOFTWARE\Policies\Microsoft\WindowsFirewall\PublicProfile'
Set-ItemProperty -Path $key -name 'EnableFirewall' -Value 0 -Type Dword -force
$key = 'HKLM:\BROKENSOFTWARE\Policies\Microsoft\WindowsFirewall\StandardProfile'
Set-ItemProperty -Path $key -name 'EnableFirewall' -Value 0 -Type Dword -force
# Unload the hives
reg unload HKLM\BROKENSYSTEM
reg unload HKLM\BROKENSOFTWARE
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:
netsh advfirewall firewall set rule dir=in name="Remote Desktop - User Mode (TCP-In)" new
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
mitigations by using the other VM.
1. On the troubleshooting VM, open a PowerShell console window.
2. Run the following commands, as appropriate.
To enable a rule:
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
To disable a rule:
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.
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
Before you follow these steps, take a snapshot of the system disk of the affected VM as a backup. For more
information, see Snapshot a disk.
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:
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
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.
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:
3. Query the profiles again to make sure that your change was made successfully. To do this, run the following
command:
NOTE
You don't have to restart the VM to apply the changes.
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
Before you follow these steps, take a snapshot of the system disk of the affected VM as a backup. For more
information, see Snapshot a disk.
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
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:
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.
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:
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:
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
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 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.
Port 22
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:
{
"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:
{
"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
myResourceGroup . Use your own values as follows:
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:
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
myResourceGroup . Use your own values as follows:
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
myResourceGroup . Use your own values as follows:
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
myResourceGroup . Use your own values as follows:
Additional resources
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
10/31/2018 • 6 minutes to read • Edit Online
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.
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
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.
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.
Additional resources
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
3/5/2019 • 15 minutes to read • Edit Online
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.
{
"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.
AcquireDiskLeaseFailed Failed to acquire lease while creating disk '{0}' using blob with
URI {1}. Blob is already in use.
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.
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.
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.
ConflictingUserInput Source and destination storage accounts for disk {0} are
different.
DiskBlobNotFound Unable to find VHD blob with URI {0} for disk '{1}'.
DiskEncryptionKeySecretMissingTags {0} secret doesn't have the {1} tags. Please update the secret
version, add the required tags and retry.
DiskImageNotReady Disk image {0} is in {1} state. Please retry when image is ready.
ImageBlobNotFound Unable to find VHD blob with URI {0} for disk '{1}'.
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.
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 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 Destination path for Ssh public keys is currently limited to its
default value {0} due to a known issue in Linux provisioning
agent.
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 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.
MissingMoveDependentResources The move resources request does not contain all the
dependent resources. Please check error details for missing
resource ids.
NotFound Source Virtual Machine '{0}' specified in the request does not
exist in this Azure location.
NotSupported The license type is {0}, but the image blob {1} is not from on-
premises.
OperationNotAllowed The resource {0} cannot be created from Image {1} until Image
has been successfully created.
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 since the Virtual Machines '{1}'
are being provisioned using the Image '{2}'.
OperationNotAllowed Disk with size {0}GB, which is smaller than the size {1}GB of
corresponding disk in Image, is not allowed.
OperationNotAllowed VM created from Image cannot have blob based disks. All
disks have to be managed disks.
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 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/
ERROR CODE ERROR MESSAGE
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.
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. Also, make sure the image has been
properly prepared (generalized).
Instructions for Windows:
https://azure.microsoft.com/documentation/articles/virt
ual-machines-windows-upload-image/
Instructions for Linux:
https://azure.microsoft.com/documentation/articles/virt
ual-machines-linux-capture-image/
OSProvisioningTimedOut OS Provisioning for VM '{0}' did not finish in the allotted time.
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 Windows:
https://azure.microsoft.com/documentation/articles/virt
ual-machines-windows-upload-image/
Instructions for Linux:
https://azure.microsoft.com/documentation/articles/virt
ual-machines-linux-capture-image/
StorageAccountLimitation Storage account '{0}' does not support page blobs which are
required to create disks.
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.
StorageAccountTypeNotSupported Disk {0} uses {1} which is a Blob storage account. Please retry
with General purpose storage account.
TargetDiskBlobAlreadyExists Blob {0} already exists. Please provide a different blob URI to
create a new blank data disk '{1}'.
TargetDiskBlobAlreadyExists Blob {0} already exists. Please provide a different blob URI as
target for disk '{1}'.
VHDSizeInvalid The specified disk size value of {0} for disk '{1}' with blob {2} is
invalid. Disk size must be between {3} and {4}.
VMExtensionHandlerNonTransientError Handler '{0}' has reported failure for VM Extension '{1}' with
terminal error code '{2}' and error message: '{3}'
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
3/5/2019 • 8 minutes to read • Edit Online
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.
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.
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.
How to use PerfInsights
11/20/2018 • 10 minutes to read • Edit Online
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.
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:
Read Requests/sec
Write Requests/sec
Avg. sec/Read
Avg. sec/Write
Avg. Bytes/Read
Avg. Bytes/Write
Read Bytes/sec
Write Bytes/sec
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.
Diskspd Yes
benchmark
trace ***
NOTE
Currently, Windows versions that include the .NET Framework 4.5 or later versions are supported.
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
You can use the below example to run performance analysis scenario for 5 mins:
You can use the following example to run the advanced scenario with Xperf and Performance counter traces
for 5 mins:
You can use the below example to run performance analysis scenario for 5 mins and upload the result zip file
to the storage account:
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 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.
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
3/14/2019 • 6 minutes to read • Edit Online
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
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.
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" }
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>
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.
Install the Azure Virtual Machine Agent in offline
mode
1/14/2019 • 4 minutes to read • Edit Online
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 ).
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.
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:
Then run the Get-AzureVM command. Notice that the GuestAgentStatus property is now populated with data:
Next steps
Azure Virtual Machine Agent overview
Virtual machine extensions and features for Windows
Redeploy Linux virtual machine to new Azure node
2/5/2019 • 2 minutes to read • Edit Online
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.
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
2/8/2019 • 2 minutes to read • Edit Online
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.
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
4/25/2019 • 5 minutes to read • Edit Online
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.
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:
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
[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:
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
11/7/2018 • 2 minutes to read • Edit Online
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.
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.
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.
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
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
cd /
umount /tempmount
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
2/8/2019 • 3 minutes to read • Edit Online
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.
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.
If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and Stack Overflow. You can
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.
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"
#Add/Change static IP. This process will not change MAC address
Get-AzVM -ServiceName $ResourceGroup -Name $VM | Set-AzureStaticVNetIP -IPAddress $IP | Update-AzVM
3. 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.
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:
#Add/Change static IP. This process will not change MAC address
Get-AzureVM -ServiceName $CloudService -Name $VM | Set-AzureStaticVNetIP -IPAddress $IP |Update-AzureVM
3. 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.
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.
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.
If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and Stack Overflow. You can
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.
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
5/23/2019 • 14 minutes to read • Edit Online
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.
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.
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:
$ 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
$ curl -X POST
"https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.SerialConsole/consoleS
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"
$ curl -X POST
"https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.SerialConsole/consoleS
ervices/default/enableConsole?api-version=2018-05-01" -H "Authorization: Bearer $ACCESSTOKEN" -H
"Content-Type: application/json" -H "Accept: application/json" -s -H "Content-Length: 0"
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.
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
5/17/2019 • 10 minutes to read • Edit Online
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.
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.
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
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
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.
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.
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
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
5/6/2019 • 4 minutes to read • Edit Online
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:
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
f Will call the oom killer to kill a memory hog process, but do
not panic if nothing can be killed.
h Will display help (any other key than those listed here will also
display help, but h is easy to remember :-)
q Will dump per CPU lists of all armed hrtimers (but NOT
regular timer_list timers) and detailed information about all
clockevent devices.
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
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
5/23/2019 • 15 minutes to read • Edit Online
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.
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.
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.
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:
$ export ACCESSTOKEN=($(az account get-access-token --output=json | jq .accessToken | tr -d '"'))
$ 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
$ curl -X POST
"https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.SerialConsole/consol
eServices/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"
$ curl -X POST
"https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.SerialConsole/consol
eServices/default/enableConsole?api-version=2018-05-01" -H "Authorization: Bearer $ACCESSTOKEN" -H
"Content-Type: application/json" -H "Accept: application/json" -s -H "Content-Length: 0"
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.
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.
Frequently asked questions
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.
Learn more about boot diagnostics.
Windows Commands - CMD and PowerShell
3/15/2019 • 13 minutes to read • Edit Online
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.
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
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.
A space is required after the equals sign. Possible start values include boot , system , auto , demand , disabled ,
delayed-auto .
or
sc start termservice
Stop service
net stop termservice
or
sc stop termservice
Show IP properties
netsh interface ip show config
Enable NIC
netsh interface set interface name="<interface name>" admin=enabled
Port ping
Install the telnet client
dism /online /Enable-Feature /FeatureName:TelnetClient
Test connectivity
telnet bing.com 80
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
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
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
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 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]]]"
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.
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
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
Manage Devices
Remove non-present PNP devices
%windir%\System32\RUNDLL32.exe %windir%\System32\pnpclean.dll,RunDLL_PnpClean /Devices /Maxclean
Miscellaneous Tasks
Show OS version
ver
or
wmic os get caption,version,buildnumber /format:list
or
systeminfo find /i "os name"
or
wmic os get installdate
or
wmic timezone get caption,standardname /format:list
Restart Windows
shutdown /r /t 0
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.
remove-module psreadline
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
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')
Start service
start-service termservice
Stop service
stop-service termservice
or
get-wmiobject win32_networkadapter -filter "servicename='netvsc'" | format-list netenabled,name,macaddress
Enable NIC
get-netadapter | where {$_.ifdesc.startswith('Microsoft Hyper-V Network Adapter')} | enable-netadapter
or
(get-wmiobject win32_networkadapter -filter "servicename='netvsc'").enable()
or
get-wmiobject Win32_PingStatus -Filter 'Address="8.8.8.8"' | format-table -autosize
IPV4Address,ReplySize,ResponseTime
or
(new-object Net.Sockets.TcpClient).BeginConnect('bing.com','80',$null,$null).AsyncWaitHandle.WaitOne(300)
or
[System.Net.Dns]::GetHostAddresses('bing.com')
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.
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>
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
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 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]]]"
Uninstall software
(get-wmiobject win32_product -filter "Name='<name>'").Uninstall()
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
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
VM ID (Instance Metadata)
$im.Compute.vmId
$im.network.interface.ipv4.subnet.prefix
Next steps
The main serial console Windows documentation page is located here.
The serial console is also available for Linux VMs.
Learn more about boot diagnostics.
Troubleshoot storage resource deletion errors
3/15/2019 • 4 minutes to read • Edit Online
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.
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
1. Sign in to the Azure portal.
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
1. Sign in to the Azure portal.
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.
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
4/29/2019 • 4 minutes to read • Edit Online
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.
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.
Azure PowerShell
If the user chooses to delete using PowerShell, it will result in the following error.
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.
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.
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
4/1/2019 • 4 minutes to read • Edit Online
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.
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:
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:
For example, for Windows Server 2016 Datacenter, you would run the following command:
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:
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.
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.
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:
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.
# 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:
# Next, create a route table and specify that traffic bound to the KMS IP (23.102.135.246) will go
directly out:
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
# 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
Next steps
KMS Client Setup Keys
Review and Select Activation Methods
Troubleshoot application connectivity issues on
virtual machines in Azure
10/31/2018 • 5 minutes to read • Edit Online
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.
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.
If you cannot access the application, verify the following settings:
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.
Additional resources
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
3/5/2019 • 4 minutes to read • Edit Online
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.
If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and Stack Overflow. You can
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.
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.
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).
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
2/8/2019 • 4 minutes to read • Edit Online
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.
If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and Stack Overflow. You can
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.
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 Windows virtual machine issues in
Azure.
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).
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
3/27/2019 • 3 minutes to read • Edit Online
To troubleshoot virtual machine (VM ) deployment issues in Azure, review the top issues for common failures and
resolutions.
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.
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
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.
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.
Next steps
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.
Troubleshoot deploying Windows virtual machine
issues in Azure
3/27/2019 • 4 minutes to read • Edit Online
To troubleshoot virtual machine (VM ) deployment issues in Azure, review the top issues for common failures and
resolutions.
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.
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
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
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.
Next steps
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.
Troubleshoot Linux VM device name changes
3/26/2019 • 4 minutes to read • Edit Online
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
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:
/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
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
4/22/2019 • 7 minutes to read • Edit Online
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
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.
Connect-AzAccount
In the following examples, replace the parameter names with your own values.
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 :
Wait until the VM has finished deleting before you process to the next step.
$resourceGroupName = 'myResourceGroup'
$location = 'eastus'
$vmName = 'myVM'
$snapshotName = 'mySnapshot'
#Get the VM
$vm = get-azvm `
-ResourceGroupName $resourceGroupName `
-Name $vmName
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.
$subscriptionId = 'yourSubscriptionId'
#Provide the name of the snapshot that will be used to create Managed Disks
$snapshotName = 'mySnapshot'
#Provide the size of the disks in GB. It should be greater than the VHD file size.
$diskSize = '128'
#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'
Now you have a copy of the original OS disk. You can mount this disk to another Windows VM for
troubleshooting purposes.
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
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):
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.
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
------ ------------- ------------- ------------ ----------------- ---------- ----------
0 Virtual HD Healthy Online 127 GB MBR
1 Virtual HD Healthy Online 50 GB MBR
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
# Get the VM
$vm = Get-AzVM -ResourceGroupName myResourceGroup -Name myVM
# 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
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
3/11/2019 • 6 minutes to read • Edit Online
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.
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.
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:
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.
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.
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.
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.
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
named myResourceGroup :
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.
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:
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 :
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 :
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.
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 :
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:
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
3/11/2019 • 7 minutes to read • Edit Online
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.
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.
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
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:
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 :
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 :
cd /
Now unmount the existing virtual hard disk. The following example unmounts the device at /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.
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:
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.
For more information about using Resource Manager, see Azure Resource Manager overview.
Troubleshoot Azure Virtual Machines boot errors
3/11/2019 • 2 minutes to read • Edit Online
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.
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
1/21/2019 • 2 minutes to read • Edit Online
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.
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.
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.
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
4/22/2019 • 7 minutes to read • Edit Online
This article describes BitLocker errors that you may experience when you start a Windows virtual machine (VM ) in
Microsoft Azure.
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.
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"
$recoveryVMName = "myRecoveryVM"
$recoveryVMRG = "RecoveryVMRG"
$OSDisk = Get-AzDisk -ResourceGroupName $rgName -DiskName $osDiskName;
Add-AzVMDataDisk -VM $vm -Name $osDiskName -ManagedDiskId $osDisk.Id -Caching None -Lun 3 -CreateOption
Attach
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:
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.
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:
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
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:
########################################################################################################
################
# 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"
}
"@
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:
5. To unlock the attached disk by using the BEK file, run the following command:
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
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
3/11/2019 • 2 minutes to read • Edit Online
This article describes the “Checking file system” error that you may encounter when you boot a Windows Virtual
Machine (VM ) in Microsoft Azure.
NOTE
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
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.
2. Attach the OS disk to a recovery VM.
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
4/24/2019 • 3 minutes to read • Edit Online
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
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
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 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
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:
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
4/22/2019 • 4 minutes to read • Edit Online
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
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.
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.
$vmName = “VirtualMachineName”
$vault = “AzureKeyVaultName”
# Get the Secret for the C drive from Azure Key Vault
Get-AzureKeyVaultSecret -VaultName $vault | where {($_.Tags.MachineName -eq $vmName) -and
($_.Tags.VolumeLetter -eq “C:\”) -and ($_.ContentType -eq ‘BEK‘)}
# OR Use the below command to get BEK keys for all the Volumes
Get-AzureKeyVaultSecret -VaultName $vault | where {($_.Tags.MachineName -eq $vmName) -and
($_.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.
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.
$rgname = "RGname"
$loc = "Location"
$vmsize = "VmSize"
$vmname = "VmName"
$vm = New-AzVMConfig -VMName $vmname -VMSize $vmsize;
$osDiskName = "OSdiskName"
$osDiskVhdUri = "OSdiskURI"
$vm = Set-AzVMOSDisk -VM $vm -VhdUri $osDiskVhdUri -name $osDiskName -CreateOption attach -Windows
#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";
#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;
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
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
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 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.
Attach the OS disk to a recovery VM
1. Take a snapshot of the OS disk of the affected VM as a backup. For more information, see Snapshot a disk.
2. Attach the OS disk to a recovery VM.
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).
2. Run the following script:
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.
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:
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:
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:
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).
Solution for cause 2
Restore the VM to the last known good configuration, follow the steps in How to start Azure Windows VM with
Last Known Good Configuration.
Solution for cause 3
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
3/11/2019 • 2 minutes to read • Edit Online
This article helps resolve the issue when your Virtual Machine (VM ) is stuck at the Windows Update stage during
startup.
NOTE
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
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
1. Take a snapshot of the OS disk of the affected VM as a backup. For more information, see Snapshot a disk.
2. Attach the OS disk to a recovery VM.
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:
For example, if the attached OS disk is drive F, run the following command:
Example:
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.
7. Detach the OS disk and recreate the VM. Then check whether the issue is resolved.
Troubleshooting API throttling errors
5/7/2019 • 4 minutes to read • Edit Online
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.
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.
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):
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.
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
11/5/2018 • 3 minutes to read • Edit Online
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.
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.
Understand a system reboot for Azure VM
3/5/2019 • 7 minutes to read • Edit Online
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.
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.
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:
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.
#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
For V2 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.
#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
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:
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:
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:
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.
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.