The Case of Where’s My Virtual Machine?

During the course of working with a client during an implementation, we discovered some pre-existing custom configurations at the VM level that when the virtual machine was rebooted, it led to complications.

The symptoms started out as the server was not reachable. When I was checking the configuration I found some interesting issues:

1. Turn on your Boot Diagnostics
   

2. Go to Run Command within the virtual machine blade

Select RunPowerShellScript and execute the code:

Get-NetConnectionProfile

You should see the Network classified as Private in most cases.

In my case, it has to be Private as Public interfaces are blocked for traffic going between VNets.

Lessons Learned:

• If you are using a virtual machine operating system level work-around for your DNS configuration you may see complications during IP address changes.
• What I encountered was having to set the profile of the NIC back to Private from Public via the PowerShell console to the virtual machine. This allowed me to interact with the configuration even though I was not able to establish a remote session for either PowerShell, CloudShell (in general context), and RDP failed until after the change.
• If your firewall, NSG, and security policies differentiate between public and private profiles, ensure that you correct.

Always check your configurations and ensure you are documenting them. It’s important to understand how your traffic is both classified, and moves around in your Azure virtual networks.

What a great opportunity to take some time and update your documentation.