Many might remember the day that Windows Servers stood still in Microsoft Azure because Microsoft made a change to the backend artifact repository for the Microsoft Azure agent. Now many are not that familiar with what that agent does and how it integrates into the Azure Fabric Controller, so I decided to do a little more digging and write a bit more about it and how important it is for an Azure VM.
Now first thing to understand is that there are two components for each Windows VM.
- RD Agent Service: This service is responsible for the Installation of Guest Agent. Transparent Installer is also a component of Rd Agent that helps to upgrade other components and services of Guest Agent. RDAgent is also responsible for sending heartbeats from Guest VM to Host Agent on the physical server.
- Windows Azure Guest Agent Service: This service is the service that is responsible for all the logging in WAppAgent.log. This service is responsible for configuring various extensions and communication from Guest to Host.
Which have different services running:
- WindowsAzureGuestAgent.exe: Windows Azure Guest Agent service
- WaAppAgent.exe: RDAgent service
- WindowsAzureNetAgent.exe: Windows Azure Network Agent service
- WindowsAzureTelemetryService.exe: Windows Azure Telemetry Service
The Azure Windows Guest Agent has an auto update feature, you can view the latest releases ot the agent here –> Releases · Azure/WindowsVMAgent (github.com).
Now the Azure Guest Agent has a couple of important roles.
- Enables the VM Agent to communicate with the Azure platform to signal that it is in a “Ready” state.
- Enables communication with the DNS virtual server to provide filtered name resolution to the resources (such as VM) that do not have a custom DNS server. This filtering makes sure that customers can resolve only the hostnames of their resources.
- Enables health probes from Azure load balancer to determine the health state of VMs.
- Enables the VM to obtain a dynamic IP address from the DHCP service in Azure. (Once the service has run once it
- Run Scripts/Extensions via the Azure Portal.
It is constantly communicating with the WireServer (or the underlying VM Host). Where it is sending information such as health status. It also has its own self-signed certificate that is used to communicate with the backend and sending
The VM agent will reply to the backend about status which is then reflected into the Azure Portal.
This agent is also used to install extensions. So, if you install an extension from the Azure Portal it will used the guest agent to get the manifest file and start downloading the extension from Azure blob storage.
This guest agent is also used to provide the “Run Script” option as well.
So how does the VM know to connect to these IP addresses? When the VM boots it will receive the following static routes using DHCP which is the reason you should never block these IP addresses within Azure.
DHCP lookup and static routes
You can also read more about it here –> What is IP address 168.63.129.16? | Microsoft Docs