VM Loses Connectivity After NIC Change
Litware has a Windows Server VM in subnet 10.50.3.0/24 with a static private IP 10.50.3.10 assigned inside the guest OS. The VM's NIC uses dynamic allocation in Azure. An administrator deletes and recreates the NIC during maintenance, and the VM comes back with Azure-assigned IP 10.50.3.20. The guest still has 10.50.3.10 configured, so RDP fails and the VM is unreachable. The NSG allows 3389 from the corporate range 203.0.113.0/24. Azure Boot Diagnostics shows the OS is running. A second VM in the same subnet is reachable.
1. Diagnose the unreachable VM and describe the safest recovery path.
Read the worked answer
Root cause is an IP mismatch between Azure and the guest OS. Azure assigned 10.50.3.20 to the new NIC, but the guest still binds 10.50.3.10, so traffic sent to the Azure-known address never reaches the guest stack, and return traffic from the guest uses an address Azure does not associate with the NIC. The NSG rule is irrelevant because the failure occurs before policy evaluation succeeds on a mismatched address.
Recovery options, safest first:
- Run command via the VM agent to reconfigure the guest IP to 10.50.3.20 (or to DHCP), then restart the NIC. This avoids redeploying the VM.
- Serial console to correct the guest configuration if the agent is unresponsive.
- Redeploy the VM only if the agent and console fail; redeploy moves the VM to a new host but does not fix guest IP configuration by itself.
Prevention: assign the static private IP in Azure (static allocation on the NIC) rather than inside the guest, so the platform and guest agree.
2. What would you check to rule out an NSG or platform fault before touching the guest?
Read the worked answer
Confirm the platform view first:
- The NIC's effective private IP and whether it matches the guest's configured address (the mismatch is already strong evidence).
- Effective security rules on the NIC to confirm 3389 from 203.0.113.0/24 is allowed and no higher-priority deny exists.
- IP flow verify to 10.50.3.20:3389 to see if the NSG permits the flow; if it permits but the connection still fails, the fault is in the guest.
- Boot diagnostics and VM health status to confirm the OS is running and the agent is reporting.
- Compare with the second VM in the same subnet, which is reachable, isolating the issue to this VM rather than the subnet or NSG.