Not able to login to Azure windows server post in-place upgrade

Hello 17723955

It sounds like you're facing RDP login issues after performing an in-place upgrade from Windows Server 2012 to 2016 on your Azure VMs. Let’s break down your situation and identify some potential solutions.

Troubleshoot using the Azure portal

After each troubleshooting step, try connecting to your VM again. If you still cannot connect, try the next step.

Reset your RDP connection. This troubleshooting step resets the RDP configuration when Remote Connections are disabled or Windows Firewall rules are blocking RDP, for example.

Select your VM in the Azure portal. Scroll down the settings pane to the Help section near bottom of the list. Click the Reset password button. Set the Mode to Reset configuration only and then click the Update button:

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.

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.

Reset the NIC for the VM. For more information, see how to reset NIC for Azure Windows VM.

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 Help section near bottom of the list. Click the Resource health button. A healthy VM reports as being Available:

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 Help 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:

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.

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 Help 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.

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.

1. Ensure that any on-premises firewall, or firewall on your computer, allows outbound TCP 3389 traffic to Azure.

Troubleshoot using Azure PowerShell

The following examples use variables such as myResourceGroup, myVM, and myVMAccessExtension. Replace these variable names and locations with your own values.

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: PowerShell

      Set-AzVMAccessExtension -ResourceGroupName "myResourceGroup" `
       -VMName "myVM" -Location Westus -Name "myVMAccessExtension"
   

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

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

   Now, view the rules that are configured for this Network Security Group. Verify that a rule exists to allow TCP port 3389 for inbound connections as follows: PowerShell

      $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: PowerShell

      Name                     : default-allow-rdp
   

Id : /subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetworkSecurityGroup/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](https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machines/windows/nsg-quickstart-powershell). Allow TCP port 3389.
   
1. **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:
   
   PowerShell
   
   ```sql
   $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:

PowerShell

   Set-AzVMAccessExtension -ResourceGroupName "myResourceGroup" `
    -VMName "myVM" -Location WestUS -Name "myVMAccessExtension" `
    -UserName $cred.GetNetworkCredential().Username `
    -Password $cred.GetNetworkCredential().Password

1. 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: PowerShell

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

2. 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: PowerShell

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

3. 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.
4. Ensure that any on-premises firewall, or firewall on your computer, allows outbound TCP 3389 traffic to Azure.

Reference - https://dori-uw-1.kuma-moon.com/en-us/troubleshoot/azure/virtual-machines/windows/troubleshoot-rdp-connection

Thanks,
Manish Deshpande.