Diagnose Azure Windows VM RDP failures caused by subnet or NIC Network Security Groups, rule priority and source restrictions.
Start with Confirm the RDP symptom and work through the six diagnostic checks in order.
Record results before changing configuration and validate the original symptom after each controlled change.
Quick checks
Start with the basic checks in this runbook before moving to deeper troubleshooting.
- Confirm the affected service or component is available.
- Check recent configuration or connectivity changes.
- Run the relevant commands and compare the result with the expected state.
Confirm the RDP symptom
Determine whether RDP times out, is refused, or works only from selected source networks.
Run IP Flow Verify
Use Network Watcher IP Flow Verify to identify whether inbound TCP 3389 is denied by an NSG.
Review effective security rules
Inspect the effective security rules applied through both NIC and subnet NSGs.
Check rule priority
Confirm the intended allow rule is evaluated before any matching deny rule.
Check Windows Firewall and TermService
If Azure permits the flow, inspect Windows Firewall and the Remote Desktop service inside the VM.
Retest securely
Retest from the approved source and use Azure Bastion or JIT access where appropriate instead of broad public RDP exposure.
Useful commands
Run these checks from an appropriate administrative session and replace example values with your environment.
RDP port
Test-NetConnection <vm-fqdn-or-ip> -Port 3389Effective NSGs
az network nic list-effective-nsg --resource-group <resource-group> --name <nic-name>Quick troubleshooting path
Use this sequence to isolate the failing dependency before changing production configuration.
- Confirm the RDP symptom → Determine whether RDP times out, is refused, or works only from selected source networks.
- Run IP Flow Verify → Use Network Watcher IP Flow Verify to identify whether inbound TCP 3389 is denied by an NSG.
- Review effective security rules → Inspect the effective security rules applied through both NIC and subnet NSGs.
- Check rule priority → Confirm the intended allow rule is evaluated before any matching deny rule.
- Check Windows Firewall and TermService → If Azure permits the flow, inspect Windows Firewall and the Remote Desktop service inside the VM.
- Retest securely → Retest from the approved source and use Azure Bastion or JIT access where appropriate instead of broad public RDP exposure.
What good troubleshooting looks like
Good infrastructure troubleshooting is evidence-driven. Capture the original state, test the dependency that can prove or disprove your hypothesis, make the smallest safe change and repeat the original test.
Symptom → hypothesis → direct test → result → controlled change → validation → documentation