Navigating the demise of the Azure Monitor VM Insights Dependency Agent: Security and Monitoring considerations

VM Insights Map and Dependency Agent retirement guidance

Official reference: https://learn.microsoft.com/en-us/azure/azure-monitor/vm/vminsights-maps-retirement

Customer impact

With this retirement, all functionality associated with the VM Insights Map and the Dependency Agent will be retired.

Specifically, customers won’t be able to:

• Access the Map tab in VM Insights in the Azure portal
• Access the Connections Overview workbook, which utilizes VM Insights Map data
• Install the Dependency Agent on new VMs from the Azure portal. Customers may still be able to install Dependency Agent through existing downloaded binaries, however, these binaries won’t be able to send data
• Send new data to Azure Monitor Log Analytics using the Dependency Agent
• Query the Service Map API

Customers will still have access to existing VM Insights Map data ingested by Dependency Agent in the associated tables (VMComputer, VMProcess, VMConnection, VMBoundPort). This data is retained as per the settings in the customers’ Log Analytics workspace.

Dependency Agent Features and Data Sources that will be lost

The Dependency Agent collects data about processes running on computers and their external process dependencies. In VM insights, you can view discovered application components on Windows and Linux virtual machines (VMs) that run in Azure or your environment. You can observe the VMs in two ways. You can view a map directly from a VM (as seen in Figure 1). You can also view a map from Azure Monitor to see the components across groups of VMs as seen in Figure 3.

Figure 3 – Multi-machine network map view with superimposed list of Log Analytics VMInsights table names (Retiring: Yes).

Figure 3 illustrates what the four (4) tables created by the Dependency Agent are used for.

• The VMBoundPort, VMConnection, and VMProcess tables (red arrows) render the network maps in the center panel and the Connection workbook seen in Figure 2.
• The VMComputer table (green arrow) provides the computer configuration data seen in the right-side panel of network maps when a computer object in the map is selected.

Performance data is not impacted by Dependency Agent retirement

The InsightsMetrics table is used to render the VMInsights performance charts. The data for this table is provided by Azure Monitor using a Data Collection Rule (DCR). The performance charts and Azure Monitor alert rules that key on VMInsights InsightsMetrics are “safe” and not impacted by the retirement of the Dependency Agent.

The logged metric data for Logical Disk Performance, CPU Utilization %, Available Memory, Logical Disk IOPS, Logical Disk MB/s, Logical Disk Latency (ms), Max Logical Disk Used %, Bytes Sent Rate, and Bytes Received Rate will continue to populate the performance charts available at the Insights menu of each computer as well as the overall Performance chart seen in Figure 4.

Figure 4 – Azure Monitor -> Insights -> Virtual Machines -> Performance chart that will continue to function regardless of Dependency Agent status (Retiring: No).

Network Connections as a data source to Microsoft Sentinel

Your security team may have installed the VM insights workbook from the Microsoft Sentinel content hub, which provides robust visualization of network data (including malicious connection detection) streaming from Azure VMs and Azure Arc-enabled servers, seen in Figure 5.

Figure 5 – The VM Insights workbook installed from the Microsoft Sentinel Content Hub (Retiring: Yes).

The central component for the analysis seen in the Figure 5 workbook is the VMConnection table in Log Analytics, which provides detailed insights into network sessions involving monitored computers.

Data from the VMConnection table is also a contributing data source to the Microsoft Sentinel Threat Intelligence (TI) solution. The solution contains data connectors for analytic rules for matching TI data with event data, workbook, and hunting queries. As seen in Figure 6, Microsoft Sentinel analytics rules which key on the VMConnection table will be deprecated along with the Dependency Agent.

Figure 6 – Microsoft Sentinel analytic rule installed from the Content hub matching VMConnection data to Threat Intelligence IOCs (Retiring: Yes).

Fundamentally, a decision to uninstall the Dependency Agent from existing computers may have potentially serious impact from a cybersecurity perspective.

Tip: To see if your Microsoft Sentinel instance is using any artifacts that depend on the Dependency Agent, navigate to the Content Hub in Microsoft Sentinel and type “VMConnection” in the search bar. The content (hunting queries, analytic rules, data connectors, parsers, workbooks, and summary rules) that keys on the VMConnection table will be listed and you can observe if any content is in the Installed state.

Decision time: What should you do?

Essentially, if you are not using the Dependency Agent features in a monitoring role (such as the network maps) or in a security role (such as Microsoft Sentinel data connectors), and you have no plans to use those features before 30 June 2028, you should uninstall the DA from your environment without delay. Otherwise, you will keep getting reminders from Microsoft about the retiring feature until 2028. You will also immediately begin to achieve cost savings from the reduced log ingestion.

If you are actively using data derived from the Dependency Agent in monitoring and/or security roles, you need to make a plan to replace the data source with alternatives. Of course, there is no hurry. All existing DA instances are assured continuous support until June 2028. That gives you almost three (3) years to find alternatives or adapt to the loss of data that will occur when the DA stops working in 2028.

Removing the Dependency Agent from your environment

Sooner or later, everyone that received the email from Microsoft discussed at the beginning of this article will need to perform various actions to completely remove the DA from their environment. When the times comes, this link has a Azure Resource Graph query to produce a list of all cloud VMs and Arc-connected VMs with the Dependency Agent VM Extension.

Uninstall Dependency Agent from computers running the AMA

AMA-connected computers found to have the DA installed must have the Dependency Agent extension uninstalled as seen in Figure 7. Uninstalling the DA from the Extensions list will automatically uninstall the Dependency Agent application from a computer.

Figure 7 – The proper way to uninstall the Dependency Agent on computers running the Azure Monitor Agent (AMA).

It is very important that the DA be removed this way on AMA-connected computers. Do not uninstall the DA from AMA-connected computers using Control Panel or other software provisioning tools.

Uninstall Dependency Agent from computers not running the AMA

However, you may have on-premises computers utilizing the Dependency Agent without Arc connectivity. This situation would occur if you previously deployed the DA with the now-retired Microsoft Management Agent (MMA), without migrating those on-premises computers to the Azure Monitor Agent (AMA).

On computers where the DA is found to be installed, and those computers are not running the AMA, it is necessary to uninstall the Dependency Agent manually using the Control Panel (seen Figure 8) or other software provisioning tools.

Figure 8 – Manually uninstalling the Dependency Agent from computers not running the Azure Monitor Agent (AMA).

Azure Policy considerations

If your organization has assigned Azure Policy initiatives to your computer populations in order to use VMInsights features, you will need to remove any settings that include deployment of the Dependency Agent. These two well-known Azure Policy initiatives should be inspected for their current status:

• Enable Azure Monitor for Hybrid VMs with AMA
• Enable Azure Monitor for VMs with Azure Monitoring Agent(AMA)

The parameter that directs to install or not install the DA with the AMA is “Enable Processes and Dependencies” as seen in Figure 9. This setting must be changed to false when you are ready to remove the DA from your environment. This will stop new instances of the DA from being deployed by policy.

Figure 9 – Change the enableProcessAndDependencies parameter to cease installing the Dependency Agent alongside the AMA.

Possible replacement technologies for Dependency Agent Data Sources

If you are actively using data from the Dependency Agent for monitoring or security purposes, you need to plan for loss of that functionality after June 2028.

• If you enjoy DA-provided features, but can envision your environment running fine without them, just use them until June 2028 and then uninstall the DA from your environment.
• If you need the same diagram-based ‘computer process to network destination IP and port map’ as is provided by VMInsights, you will need to investigate third party alternatives or write your own application and have the new solution in place by June 2028.
• In lieu of either abandoning the features, or replacing them with a third-party application, a recommended approach is more granular: Investigate what monitoring or security value you are receiving from specific DA-provided features and have a migration or contingency plan for each feature. Implement the follow-on technologies that functionally replace the former DA-provided features at your own pace and not later than June 2028.

Computer process to network destination IP and port map

This is the most difficult feature provided by the Dependency Agent to replace. There is simply nothing in the Microsoft toolset as sophisticated as the VMInsights network map. Essentially, this feature took the computer process to network destination IP and port dumps from every computer and combined those outputs into a live graphical display. These maps are useful to determine which applications on a computer are communicating with remote destinations.

To get you started on envisioning a replacement methodology for this intelligence, consider the diagnostic information that is at the heart of the DA’s VMConnections table. This information can be gathered individually by running a script on a local computer. At-scale implementations can run the script remotely and capture the output for display in a management console.

Collect process to network destination and port information from Windows computers

To get process to network destination IP and port mapping, in Windows run this PowerShell (observe the output in Figure 10):

Proc2IP.ps1

# Get process and connection info
$netConnections = Get-NetTCPConnection | Where-Object { $_.State -eq 'Established' }
$processes = Get-Process
# Combine process and connection info
$results = foreach ($conn in $netConnections) {
$proc = $processes | Where-Object { $_.Id -eq $conn.OwningProcess }
if ($proc) {
[PSCustomObject]@{
ProcessName = $proc.ProcessName
PID = $proc.Id
LocalIP = $conn.LocalAddress
LocalPort = $conn.LocalPort

RemoteIP = $conn.RemoteAddress
RemotePort = $conn.RemotePort
Protocol = "TCP"
}
}
}
# Output the result
$results | Sort-Object -Property ProcessName | Format-Table -AutoSize

Figure 10 – Capturing process to network destination information on a Windows computer using a PowerShell script.

Collect process to network destination and port information from Linux computers

To get process to network destination IP and port mapping in Lunix, run this shell script (observe the output in Figure 11):

Proc2IP.sh

#!/bin/bash 

# Check if 'ss' command is available 

if command -v ss &> /dev/null; then

conn_cmd="ss -tnp"

elif command -v netstat &> /dev/null; then

conn_cmd="netstat -tnp" 

else

echo "Neither 'ss' nor 'netstat' is available. Exiting."
exit 1
fi
echo -e "Process\tPID\tLocal IP\tLocal Port\tRemote IP\tRemote Port"
# Extract established connections
$conn_cmd | awk '/ESTAB/ {print}' | while read -r line; do

# Parse connection details
local_ip=$(echo "$line" | awk '{split($4,a,":"); print a[1]}')
local_port=$(echo "$line" | awk '{split($4,a,":"); print a[2]}')
remote_ip=$(echo "$line" | awk '{split($5,a,":"); print a[1]}')
remote_port=$(echo "$line" | awk '{split($5,a,":"); print a[2]}')
pid_proc=$(echo "$line" | grep -oP 'pid=\K[0-9]+')
# Get process name
if [[ -n "$pid_proc" ]]; then
proc_name=$(ps -p $pid_proc -o comm= 2>/dev/null)
fi

echo -e "$proc_name\t$pid_proc\t$local_ip\t$local_port\t$remote_ip\t$remote_port"

done

Figure 11 – Capturing process to network destination information on a Linux computer using a shell script.

Computer configuration information

The VMInsights VMComputer table is a useful tool for discovering basic configuration information about Windows and Linux computers in the solution. This information is seen in the right-side panel of network maps when a computer object in the map is selected (green arrow on the right side of Figure 3).

General configuration information about computers is probably the easiest feature to replace when considering the loss of Dependency Agent-provided data. Table 1 lists interesting data columns that appear in the VMComputer table and example data from an Azure Arc-enabled server.

Table 1 – List of VMComputer table columns with sample data from an Azure Arc-enabled server.

Most, but not all the data will continue to available in Azure for managed computers. If you have processes that leverage data from the VMComputer table, you need to locate alternative sources of that data elsewhere in Azure. Then retool/refactor your processes to use the data from the alternative source(s).

Some basic data such as computer FQDN and OS name is contained in the AMA Heartbeat table. Another resource for computer configuration data is the DeviceInfo table which may be collected if your organization has connected Microsoft Defender for Endpoint.

You might need other data to replace the VMInsights VMComputer table, and some can be found in Azure Resource Graph (ARG). Table 2 lists VMComputer column names and corresponding locations of the same data in ARG for Azure Arc-enabled servers.

Table 2 – List of VMComputer table columns with matching data in Azure Resource Graph for Azure Arc-enabled servers.

VMConnection data in Microsoft Sentinel

Having cybersecurity-related reliance on the Dependency Agent VMConnection table is probably the more impactful situation you may need to plan for. The primary security benefit of connecting VMInsights to Microsoft Sentinel is capturing the network connections the computer is making so that those connections can be examined for hostile or malicious characteristics. You need to make sure your SIEM has visibility into this traffic.

The VMConnection table created by VMInsights is a first-class citizen in the Microsoft Sentinel world when it comes to normalizing Network Session data. I recommend continue to use the Dependency Agent on all supported platforms as long as it is supported, until June 2028–it’s a high-value solution from a security perspective when also connected to Microsoft Sentinel.

The list in Figure 12 includes relevant data sources participating in the Advanced Security Information Model (ASIM) Microsoft Sentinel solution. ASIM transforms source telemetry to user friendly data to facilitate exchange and integration.

Figure 12 – Microsoft Sentinel Network Session Essentials included data sources.

When planning for the loss of data from the VMConnection table, equivalent security can be achieved by collecting Windows Firewall logs from Windows computers and Microsoft Sysmon logs from Linux computers.

• Windows Firewall logging is an excellent replacement for VMConnection data. Activate the Windows Firewall Events via AMA connector in Microsoft Sentinel. See this article from my blog for details on Microsoft ASIM and tips to deploy and configure Windows Firewall logging in your environment. It’s not necessary that you use the firewall features of Windows Firewall—only the logging portion of Windows Firewall needs to be turned on.
• Microsoft Sysmon for Linux, when configured, writes data to the Linux syslog, which you should already be collecting from all Linux computers. Activate the Microsoft Sysmon For Linux Solution connector in Microsoft Sentinel. See this guide by Microsoft MVP Jeffrey Appel for how to use Sysmon for Linux in Microsoft Sentinel.

#MVPBuzz #AzureMonitor #MicrosoftSentinel #DefenderXDR #SIEM #DefenderXDRan