Unable to connect to Azure VM after upgrading it to SQL Virtual Machine

John Jacobson 1 Reputation point
2026-09-18T04:27:11.1433333+00:00

Hi,

I wanted to be able to logon to my SQL server using AZURAD credentials, so followed the instructions to make the VM an SQL Virtual Machine. It's just running SQL Express (I also have to upgrade the version). I used the az sql vm create command.

However, I can no longer access the server via RDP.

I am connecting to the SQL Database, and that is working fine.

The port is open in the Network Security Group.

I did the thing of going to Reset Password in Azure Portal and updating the configuration. Didn't resolve it.

I'm also unable to reboot the server during production hours as I have users accessing the SQL database.

The annoying thing is that if I new I would end up with this issue, I would have just left well enough alone.

Would appreciate any assistance.

SQL Server on Azure Virtual Machines
0 comments No comments

2 answers

Sort by: Most helpful
  1. Senthil kumar 2,500 Reputation points
    2026-09-18T04:48:18.3633333+00:00

    Hi @John Jacobson

    Fix RDP WITHOUT rebooting (safe for production)

    ✔ Method A — Use Azure Serial Console (best fix)

    Azure Portal → VM → Serial Console

    If it opens, run these commands:

    Restart RDP service

    net stop termservice

    net start termservice

    netsh advfirewall firewall set rule group="remote desktop" new enable=yes

    ✔ Method B — Use Azure Run Command (no reboot)

    Azure Portal → VM → Run Command → EnableRemoteDesktop

    This runs Microsoft’s built‑in RDP repair script.

    It fixes:

    RDP listener

    Firewall rules

    Terminal Services

    Registry keys

    No reboot required.

    ✔ Method C — Reset NIC (safe, no reboot)

    You already tried NIC reset, but after SQL IaaS extension installation, you must run:

    Azure Portal → VM → Networking → NIC → IP Configurations

    Check:

    Private IP is still assigned

    NIC is still attached

    DNS settings are unchanged

    Sometimes the SQL extension overwrites DNS.

    Thanks.

    Was this answer helpful?


  2. AI answer

    2026-09-18T04:27:32.3333333+00:00

    Since SQL connectivity still works and Reset configuration only did not fix RDP, use the standard Azure VM RDP troubleshooting path in this order:

    1. In the Azure portal, open the VM and check Resource health. The VM should report Available.
    2. Review Boot diagnostics for startup issues or console errors that could block RDP.
    3. Verify the effective Network Security Group rules for inbound TCP 3389. The rule must be allowed and not overridden by a higher-priority deny rule.
    4. Reset the VM NIC.
    5. If needed, use Reset password again, but this time also consider resetting user credentials, not only configuration.

    If the VM’s Connect button is unavailable, confirm the VM has a public IP address unless access is through ExpressRoute or Site-to-Site VPN.

    For immediate access without relying on direct RDP exposure, connect through Bastion:

    1. In the Azure portal, open Virtual machine and select the VM.
    2. Select Connect > Connect via Bastion.
    3. Select Deploy Bastion and wait for deployment to finish.
    4. Choose the authentication type, enter credentials, and select Connect.

    After connecting to the VM, check the local Windows RDP state:

    • Confirm Remote Desktop is enabled.
    • Confirm Windows Firewall is not blocking RDP.
    • Confirm no local issue is affecting the RDP listener.

    If direct SQL access is the only requirement during production hours, avoid rebooting first and use the non-disruptive checks above. A reboot is listed as a later troubleshooting step, not the first one.

    Also note that Microsoft Entra ID authentication for SQL Server on Azure Virtual Machines is supported only on SQL Server 2022 (16.x) and later. Since the VM is running SQL Express, verify that the current SQL version meets that requirement before continuing with Microsoft Entra ID configuration.

    If Bastion access also fails, the next supported path is deeper RDP troubleshooting through boot diagnostics, NIC reset, and VM health review before considering restart or redeploy.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.