Azure Arc is a hybrid cloud solution from Microsoft that projects your existing on-premises and multicloud servers into Azure Resource Manager for unified management. In practice, you can apply Azure’s governance and management tools – like Azure Policy, role-based access control (RBAC), and monitoring – to servers outside Azure. This consistency simplifies operations across diverse environments. Among the many capabilities Azure Arc unlocks (such as centralized patch management with Update Manager and security monitoring with Defender for Cloud​), one crucial feature is Change Tracking and Inventory.

Change Tracking and Inventory (CT&I) is a service that monitors and logs changes on your servers. It tracks modifications to files, Windows Registry keys, installed software (packages), running services (daemons), and more. By maintaining an inventory and recording changes over time, CT&I helps IT teams answer questions like: “What changed on this server yesterday?” or “Which software versions are installed across our fleet?” This is invaluable for compliance audits, diagnosing configuration drift, troubleshooting issues, and maintaining visibility into your server environment. In a hybrid scenario, Azure Arc-enabled servers can leverage Azure’s Change Tracking and Inventory to monitor Azure VMs and non-Azure machines similarly.

While you can enable Change Tracking and Inventory manually on individual machines via the Azure portal (for example, by selecting an Arc-enabled server in the portal and clicking “Enable using AMA agent”)​, doing this at scale for many servers would be time-consuming and error-prone. This is where Azure Policy comes in. By using Azure Policy, you can automatically deploy and configure the required extensions and settings on all your Azure Arc-enabled servers, ensuring every machine is consistently onboarded to Change Tracking and Inventory. This approach improves compliance (any server not meeting the policy will be flagged) and provides automation to reduce manual effort. In this blog post, we will walk through how to create and assign Azure Policies via the Azure Portal to enable Change Tracking and Inventory on Azure Arc-enabled servers. We’ll cover prerequisites, the step-by-step process of deploying the needed agents and configurations with custom policies, how to assign these policies at scale (subscription or resource group level), and tips on remediation and verification. By the end, your hybrid servers will automatically report changes and inventory data to Azure, giving your IT team unified visibility and control.

Azure Arc-Enabled Servers: Benefits for Hybrid Management

Before diving into policies, let’s briefly recap why Azure Arc-enabled servers are beneficial in a hybrid or multi-cloud environment. Azure Arc allows you to manage non-Azure machines (on-premises or in other clouds) as if they were Azure resources. Each Arc-enabled server is represented in your Azure subscription with a resource ID and can have tags, be organized into resource groups, and, crucially, be targetable by Azure RBAC and Azure Policy. This means you can enforce configurations or uniformly deploy extensions across Azure VMs and Arc-connected servers. Azure Arc essentially provides a single pane of glass for management.

Key benefits of Azure Arc for servers include:

  • Consistent Management Experience: Apply the same policies and automation scripts to on-premises or AWS/GCP VMs as you do to Azure VMs. This ensures consistent security and configuration standards across environments.
  • Unified Monitoring and Inventory: Leverage Azure Monitor and services like Change Tracking on all servers, not just those running in Azure. For example, you can track system updates, software installations, or registry changes on a physical server in your data center just as easily as on an Azure VM.
  • Improved Compliance: All Arc-connected servers can be assessed against Azure Policy definitions. If a policy (like having a certain extension or configuration) is not met on an Arc server, it will show up as non-compliant, giving you immediate visibility into any drift from the desired state.
  • Automation and DevOps Integration: Azure Arc enables declarative management of resources outside Azure using ARM templates, Azure CLI, or GitOps (for Kubernetes). For servers, you can automate agent deployments and configurations at scale.
  • RBAC and Security: Arc-enabling a server means you can use Azure RBAC to control its access (for operations via Azure), and integrate the machine with Azure Defender for Cloud for security posture management.

In summary, Azure Arc brings your hybrid servers into Azure’s management ecosystem. This translates to less siloed management and more uniform governance for IT teams.

Change Tracking and Inventory on Arc-enabled servers are excellent examples of these benefits. Normally, tracking changes on a server would require setting up a monitoring agent and perhaps an on-premises logging system. With Azure Arc, you can deploy Azure’s monitoring agent and send all change logs to Azure Monitor with just a few clicks or automated policies. This feature helps ensure that whether a server is on Azure or under your desk, you have the same insight into its configuration changes over time.

Overview of Change Tracking and Inventory (CT&I)

Azure’s Change Tracking and Inventory service provides visibility into system changes and an inventory of software and configurations over time. Specifically, it can track:

  • File changes are additions, modifications, or deletions of files (you can specify which paths to monitor, including using wildcards for entire directories).
  • Windows Registry changes: For Windows servers, registry keys and values can be monitored for changes (adds/edits/deletions).
  • Software installation/uninstallation: It records when software packages or updates are installed or removed on Windows and Linux (this forms a software inventory of the machine)​.
  • Services and Daemons: Changes in the state of services (Windows Services or Linux daemons) are tracked, such as when a service stops, starts, or a new service is installed.
  • Linux configuration files: For Linux systems, you can track changes to text-based config files (by specifying paths, e.g. monitoring all .conf files under /etc/).

An agent collects all these changes and sends them to a Log Analytics workspace in Azure. This allows querying the data (for example, “show me all changes on server X in the last 24 hours”) and setting up alerts if needed. By maintaining an inventory, the service also lets you see the current state (e.g., list of installed software and versions on a server) at any time, and by looking at change logs, you can see how that state evolved.

Why is this important for IT teams? It dramatically improves visibility and control. You’ll know precisely when a configuration drift occurred – for example, if someone manually edited a configuration file or installed an unauthorized application, it will be logged. In regulated environments, this helps prove compliance (all changes are tracked and auditable). It also aids in troubleshooting: if a server breaks, you can check recent changes to pinpoint what might have caused the issue.

Enabling CT&I on Azure Arc-enabled servers uses Azure Monitor’s infrastructure. Under the hood, it leverages the Azure Monitor Agent (AMA) and Data Collection Rules (DCRs) rather than the legacy Log Analytics Agent (MMA). The Azure Monitor Agent is the newer unified monitoring agent, and DCRs define what data to collect and where to send it. (Notably, Microsoft will depreciate the older Log Analytics agent in favor of AMA by August 2024, so our solution will align with the latest standards.)

When we enable CT&I on Arc servers via the Azure Portal (manually or by policy), what happens behind the scenes is: the Azure Monitor Agent extension is installed on the machine (if not already present), a special Change Tracking extension/agent is enabled (to capture the detailed change data), and a Data Collection Rule is applied linking the machine to send change data to a Log Analytics workspace. Our task is to set up Azure Policies that ensure all these pieces are configured automatically for the target Arc-enabled servers.

Prerequisites and Permissions

Before creating and assigning the policies, ensure you have the following prerequisites in place:

  • Azure Arc-enabled Servers Onboarded: You should already have your target servers onboarded to Azure Arc (i.e., the Azure Arc agent is installed, and the machines appear in Azure as resources). Verify that each machine’s status is “Connected” in the Azure Portal. If a server is not yet Arc-enabled, you must first install the Arc agent and register it with your Azure subscription. Also, make sure the Azure Arc resource (representing your server) is in an Azure region that supports the needed features (at the time of writing, Change Tracking via AMA on Arc may be available in a subset of regions – common regions like East US, West Europe, etc., are typically supported, and support is expanding).
  • Log Analytics Workspace: Change tracking logs and inventory data are stored in a Log Analytics workspace. You should have a Log Analytics Workspace created (or plan to create one) in a supported Azure region. Note the workspace’s resource ID. In many cases, it’s advisable to use the same region for all components (the Arc server resource, workspace, and data collection rule) to avoid regional compatibility issues.
  • Data Collection Rule (DCR) for Change Tracking: Azure Policy must associate your Arc servers with a DCR that tells the Azure Monitor Agent what to collect (i.e., the specific change tracking data). You must create this DCR in advance​ because the policy assignment will require a DCR resource ID as a parameter. Microsoft provides a ready-to-use template JSON to create a DCR configured for Change Tracking and Inventory on Windows and Linux. We will use this template in the steps below to create the DCR via the Azure Portal. (Alternatively, you could create a DCR manually, but the template ensures all necessary configuration is included.)
  • Permissions: To perform these steps, you’ll need sufficient permissions in Azure. To create and assign policies, you must be an owner or contributor on the subscription (or have the Resource Policy Contributor role for the scope in question). You’ll also need permissions to create a DCR (which falls under the Microsoft Insights resources category) and assign managed identities to Arc machines. If you are an Azure admin or owner at the subscription level, you should be fine. Otherwise, ensure you have the rights to assign policies and write to the resource group where the DCR and the Log Analytics workspace reside.
  • Managed Identity on Arc Machines: Azure Monitor Agent on Arc requires a system-assigned managed identity on each server for authentication. Azure Arc currently only supports system-assigned (not user-assigned) identities for this purpose. This is critical – the AMA uses the machine’s managed identity to securely retrieve the DCR configuration from Azure and send data to the Log Analytics workspace. Suppose your Arc-enabled servers do not already have a system-assigned managed identity enabled. In that case, you must enable it (you can do this by navigating to each Arc-enabled server’s Identity pane in the Azure Portal and turning on “System-assigned identity”). This can also be automated via PowerShell or CLI for multiple machines. Remember that the Azure Policy we assign to install AMA will not deploy the agent unless the system-assigned identity is present​– the policy’s logic explicitly checks for an enabled identity and skips installation if the identity is missing. So, identity is a non-negotiable prerequisite for our scenario.
  • Azure Policy and Extensions Resource Providers: Ensure that the Azure Policy service and Azure Arc extensions are registered in your subscription (typically by default). Specifically, the resource provider Microsoft.HybridCompute (for Arc servers) and Microsoft . Insights (for DCR/monitoring) should be registered. Again, this is usually the case if you’ve onboarded Arc and used Log Analytics, but it’s worth verifying if you encounter any issues.

With the prerequisites satisfied—Arc servers connected (with system identities enabled), a Log Analytics workspace ready, and a DCR prepared—we can define and assign the Azure Policies to enable Change Tracking and Inventory at scale.

Creating Azure Policy Definitions for CT&I Deployment

Microsoft has provided built-in policy definitions (and a combined initiative) to facilitate deploying Change Tracking and Inventory components to Azure VMs and Arc-enabled machines. We don’t need to write custom JSON from scratch – we can leverage these built-in policies through the Azure Portal. However, understanding what each policy does will help us configure them correctly.

The relevant Azure Policy initiative (policy set) for our scenario is called “Enable ChangeTracking and Inventory for Arc-enabled virtual machines”, which is currently in preview (at the time of this writing) and includes several policies covering Windows and Linux Arc servers. Each policy within this initiative addresses a specific piece of the configuration. The main components are:

  1. Install Azure Monitor Agent (AMA) – for Windows and Linux Arc machines (two separate policies). These policies ensure the Azure Monitor Agent extension is installed on the Arc servers (they have a deploy-if-not-exists effect). The AMA is the base agent needed to collect telemetry. The policy checks if the machine’s region and OS are supported and if the system-assigned identity is enabled; if so, it deploys the agent.
  2. Install Change Tracking Extension—again, one policy for Windows Arc machines and one for Linux. These policies deploy the specific Change Tracking extension/agent on the machine. This extension works alongside AMA to collect change data (such as file changes or registry changes). For example, on Windows, it enables the File Integrity Monitoring capabilities and inventory capture; on Linux, it might configure notify or relevant services. These are also deploy-if-not-exists policies.
  3. Associate with Data Collection Rule – one policy for Windows Arc and one for Linux Arc that will create an association between the machine and a given Data Collection Rule for Change Tracking and Inventory. In Azure Monitor’s model, associating a VM or machine with a DCR means that the agent on that machine will start using the rule’s configuration (i.e. it knows what data to collect and what workspace to send it to). These policies require the DCR resource ID as a parameter, and they have a deploy-if-not-exists (effectively “deploy association”) to link the machine to the DCR if not already linked.

In total, that’s six policy definitions (install AMA [Windows/Linux], install CT extension [Windows/Linux], and associate DCR [Windows/Linux]). Microsoft bundles these into the single initiative “Enable ChangeTracking and Inventory for Arc-enabled VMs” for convenience. We could assign the initiative as a whole (which is useful because it groups all necessary policies) or assign individual policies individually. In the Azure Portal, if you filter Policy Definitions by category “Change Tracking and Inventory”, you will find this initiative and its constituent policies.

Screenshot: The built-in Azure Policy initiative (preview) for enabling Change Tracking and Inventory on Arc-enabled servers. It includes separate deploy-if-not-exists policies to install the Azure Monitor Agent and ChangeTracking extensions and to associate a Data Collection Rule for both Windows and Linux machines.

In our walkthrough, we will effectively deploy all these pieces. For clarity, we’ll go step by step (first AMA, then the CT extension, then the DCR association). If you prefer, you can assign the initiative to cover everything at once – the process in the Portal is similar. Still, you’ll need to fill in parameters for the initiative (like the DCR ID and identity options) in one go. We’ll break it down for learning purposes so you understand each component.

Note: The policy definitions are built-in (type = BuiltIn), so we do not need to create custom definitions. We will be creating policy assignments (and an initiative assignment) in the portal. “Creating custom Azure Policies via the Azure Portal” in this context means selecting these built-ins and configuring them for our environment (scope, parameters, etc.), effectively making custom assignments. If you did need to customize something beyond what the built-ins allow (for example, a different behavior or non-supported region logic), you could start from these definitions JSON and create a custom policy. But in most cases, the provided ones will suffice.

Step 1: Deploy the Data Collection Rule for Change Tracking (One-Time Setup)

Before assigning the policies to associate Arc machines with a DCR, we need to create the Data Collection Rule. As noted in prerequisites, this is required upfront. We’ll do this first to have the DCR’s Azure resource ID handy when configuring the policy in a later step.

Microsoft provides a sample ARM template called CtDcrCreation.json to create a DCR tailored for Change Tracking and Inventory. This template defines data collection for Windows (registry, files, software, services) and Linux (files, software, services) and targets a Log Analytics workspace of your choice. It essentially sets up everything the AMA needs to know to gather CT&I data. We will use the Azure Portal’s custom deployment feature to deploy this template:

  1. Open the Azure Portal and use the global search to find “Deploy a custom template” (or navigate to Resource Groups > (your target resource group) > Deployments > New Deployment > Build your template). This opens the Custom deployment blade, where you can deploy ARM templates.
  2. Click “Build your template in the editor.” In the template editor, either paste the content of the CtDcrCreation.json or use the Load file option to upload the JSON file (if you have it downloaded). The JSON is available on Microsoft’s documentation site- you can obtain it from Microsoft Learn (Automation Change Tracking documentation) or possibly from a link provided in community blogs. After pasting or loading the template, click Save.
  3. Back in the custom deployment UI, fill in the Basics section:
    • Subscription: Select the Azure subscription where you want the DCR created (it should be the same subscription your Arc servers and workspace are in).
    • Resource Group: Choose a resource group to contain the Data Collection Rule (you might create a new dedicated RG for monitoring config or use an existing one). Remember that your chosen resource group will form part of the DCR’s resource ID.
    • Optionally, give the deployment a name or use the default.
  4. In the Parameters for the template (often this appears after Basics in the custom deployment interface), you will need to provide:
    • workspaceResourceId: The full Azure Resource ID of your Log Analytics workspace where change data should be sent. You can copy this from the workspace’s Properties page; it will look like this:
      /subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>
    • dataCollectionRuleName: (Optional) You can name the DCR. The default template is “Microsoft-CT-DCR,” which is fine unless you have a naming convention.
  5. Click Review + create, then Create to deploy the template. The Azure Portal will deploy the resources described by the template. You should see a successful deployment within a few minutes.

What does this deployment do? It creates a Data Collection Rule resource (visible under Azure Monitor’s DCR listings or under the resource group in the portal) with the necessary configuration for Change Tracking. It also creates an Operations Management Suite (OMS) solution resource for ChangeTracking linked to your workspace—this is essentially metadata that lights up the Change Tracking solution in the workspace (required for the portal experiences). The important output for us is the DCR.

Go to the resource group and find the newly created Data Collection Rule (it might be named “Microsoft-CT-DCR” or whatever you specified). If you like, open it and verify its settings (you can see in its JSON that it has data sources for ChangeTracking-Windows and ChangeTracking-Linux streams and a destination pointing to your Log Analytics workspace). Now copy the Resource ID of this DCR (you can find it in the DCR’s Overview or Properties or the JSON view). We need this string when assigning the policy that associates machines with the rule. It should look like this:


/subscriptions/sub-id/resourceGroups/rg/providers/Microsoft.Insights/dataCollectionRules/DCR-name

#Keep this Resource ID handy (perhaps in a text file or clipboard).

Tip: If you have multiple Azure regions or separate groups of servers that need different settings, you could create multiple DCRs (for example, one per region or environment). For simplicity, we assume all Arc servers will use one DCR for CT&I. That DCR can be in one region (as long as that region supports sending data from all your servers, it generally does, since Arc servers can send to any workspace region as long as the AMA is supported).

Now that the DCR is in place, we can assign the Azure Policies to deploy the agent and extensions and link to this rule.

Step 2: Assign Policy to Install Azure Monitor Agent on Arc Servers

First, we want every Arc-enabled server in our scope to install the Azure Monitor Agent (AMA). Often, Azure Arc onboarding might already install the AMA by default (especially if you enabled specific monitoring when adding the server). Still, to be sure and to cover new servers, we use a policy.

Azure provides built-in definitions: “Configure Windows Arc-enabled machines to install AMA for ChangeTracking and Inventory” and the equivalent for Linux Arc-enabled machines. These are the policies we identified earlier. They have a DeployIfNotExists effect. We will assign each of these policies at the appropriate scope.

Perform the following for Windows Arc-enabled machines AMA policy (and then repeat for Linux):

  1. Navigate to Azure Policy in the Portal (you can search for “Policy” in the Azure Portal search bar). On the left menu, click Definitions. Use the search bar or filters at the top to find the policy. For example, you can search for “Arc AMA ChangeTracking”. Another method is to filter by Category: select Change Tracking and Inventory as the category, and perhaps filter by Policy Type = Built-in. You should see an entry for Configure Windows Arc-enabled machines to install AMA for ChangeTracking and Inventory. (If you see it labeled as [Preview], that’s fine – the policy is relatively new. Ensure you have the latest Azure Policy alias updates.)
  2. Click on the policy name to open its definition page. If you are curious, you can review the definition of JSON, but our focus is on assigning it. Click the Assign button at the top. This starts the policy assignment wizard for this definition.
  3. In the Basics tab of the assignment wizard:
    • Scope: Click the ellipsis (…) to select the scope. You can choose a subscription or a resource group. For example, if all your Arc servers are in one resource group, you might scope it there. Often, one would scope at the subscription level if you want the policy to apply to any Arc-enabled server under that subscription (you can optionally exclude certain resource groups if needed). Select the desired subscription and narrow it down to a resource group.
    • Assignment name: This will auto-populate with the policy name, but you can edit it to something like “Install AMA on Arc Windows – CTI” if you want clarity.
    • Description: Optional, but you can note “Deploy AMA agent on all Windows Arc-enabled servers for Change Tracking”.
    • Policy enforcement: leave Enabled (default).
  4. Move to the Parameters tab. The Windows AMA policy may have a parameter related to the managed identity (for VMs, some policies let you bring your own user-assigned identity, but for Arc, it might not appear). If you see a parameter like “Use your own managed identity” or similar, ensure it’s set to false (meaning the policy will use the system-assigned identity approach). In our case, a system-assigned identity is the only option, so it is likely that the parameter is not present or is just informational. In the tech community blog, it was mentioned to “uncheck the parameter”​– this likely refers to not using a custom identity. So, proceed with default parameters.
  5. In the Remediation tab (this appears for deploy policies in the portal assignment wizard):
    • Check the option to create a remediation task if available. This ensures that the policy will attempt to remediate (install the AMA extension) on existing resources that currently do not have the AMA. Essentially, without a remediation task, the policy would only apply to new resource creations or updates; enabling remediation triggers Azure Policy to scan existing Arc machines and deploy the agent on those missing it. Rem remediation is essential since we aim to enable this on all existing Arc servers.
    • For the Managed Identity to use for remediation: Don’t confuse this with the Arc machine’s identity. This is asking what identity Azure Policy should use to perform the deployment. You can typically use the system-assigned identity of the Policy assignment (which is a managed identity created at assignment time to carry out the deployment). The portal might handle this automatically. Alternatively, you could specify a user-assigned identity with contributor rights to the machines. However, using the default system identity is the simplest. Azure will create a temporary identity with the permissions needed to install the extension on the Arc machines. Ensure that the identity has permission to create extensions on the Arc resource (Contributor on the scope will suffice).
    • Leave the other settings on default unless you have a specific reason for changing them.
  6. Review and create the assignment. After a moment, the policy assignment will be active. Azure Policy will evaluate all Arc-enabled Windows servers in the scope. Any server that does not have the AMA extension installed (and meets the criteria: it is in a supported region and has system identity) will show as non-compliant and trigger a deployment to install the Azure Monitor Agent. If you navigate the Compliance tab in Azure Policy, you can find this assignment and see the compliance state. Initially, it will likely show non-compliant while deploying the agent; then, as machines get the agent, it should flip to compliant.
  7. Repeat the assignment for “Configure Linux Arc-enabled machines to install AMA for ChangeTracking and Inventory.” The steps are essentially the same. The Linux policy likely has no parameters (other than scope). Assign it to the same scope (or a different scope if you segregate Windows vs. Linux servers in different groups). Enable remediation as well.

After these two policy assignments, within 15-30 minutes, you should expect all targeted Arc servers to have the Azure Monitor Agent deployed. You can verify on a machine by checking in the Azure Portal: go to an Arc-enabled server resource, and under Extensions, you should see the AzureMonitorLinuxAgent or AzureMonitorWindowsAgent listed (depending on OS). Azure Policy will use a DeployIfNotExists effect to install the extension if missing. If a machine was missing the required system identity or in an unsupported region, it would remain non-compliant (and the deployment would be skipped). Ensure those prerequisites are addressed and trigger a remediation again if needed.

At this point, we have the base monitoring agent on all machines but haven’t yet enabled the actual change tracking functionality – that’s where the Change Tracking extension and DCR come in.

Step 3: Assign Policy to Deploy Change Tracking Extension

Next, we will assign the policies to install the ChangeTracking extension on the Arc machines. As with AMA, there are two policies: “Configure ChangeTracking Extension for Windows Arc machines” and “… for Linux Arc machines.” These will deploy the actual change tracking components (often called the File Integrity Monitoring (FIM) extension in Security Center context) on top of AMA. AMA alone wouldn’t know how to collect file/registry/service changes without this. The extension works with AMA to capture those changes on the guest OS.

The process is very similar to the previous step:

  1. In Azure Policy > Definitions, locate Configure ChangeTracking Extension for Windows Arc machines (Built-in). You might also see it labeled as [Preview]. Please open it and click Assign.
  2. Choose the same Scope as before (e.g., the subscription or resource group containing your Arc servers). Consistency is key – you likely want this wherever you deployed AMA. If you like, you can create an Initiative in the portal containing the AMA and Extension policies and assign them together, but doing them separately is fine.
  3. Parameters: These extension deployment policies typically have no required parameters; they know what extension type to deploy (there might be optional settings, but likely none needed for CT extension). So proceed.
  4. Remediation: Again, enable remediation tasks. This will push the extension to existing machines. Use a system-assigned managed identity for the deployment task (Azure will handle the actual extension installation via the Arc agent).
  5. Create the assignment.
  6. Repeat for “Configure ChangeTracking Extension for Linux Arc machines”—assign it to the same scope and enable remediation.

Once assigned, Azure Policy will evaluate Arc machines for compliance. Suppose an Arc-enabled server (Windows) does not have the ChangeTracking extension installed. In that case, the policy will mark it non-compliant and then deploy the extension (since we enabled the remediation task). You can monitor the deployment by checking the Compliance view of the assignment or by going to an Arc server’s Extensions list in the Azure Portal. After a short while, you should see a new extension on each machine named something like ChangeTracking or similar (the exact name might be “Microsoft.GuestConfiguration.ChangeTracking” or a part of Azure Monitor; it’s deployed via the Arc extension framework).

At this stage, your Arc-enabled servers have:

  • Azure Monitor Agent is installed (but not yet configured to collect CTI data).
  • The change Tracking extension has been installed (ready to produce data about changes).

However, we still need to instruct the agent on what to do with this extension data—that’s where the Data Collection Rule and association come into play. Without associating the machine with the DCR, the agent might not actively start the change tracking. The DCR provides the configuration (like which streams to collect and which to send to the Log Analytics workspace).

Step 4: Assign Policy to Associate Arc Servers with the DCR

Now that the infrastructure (agent + extension + DCR) is in place, the final step is to link them together. We will use the DCR association policies: “Configure Windows Arc-enabled machines to be associated with a Data Collection Rule for ChangeTracking and Inventory” and the corresponding Linux one. These policies essentially perform a “deploy association” action, which tells Azure Monitor that any machine in scope should be attached to the specified DCR.

This step requires the Resource ID of the DCR we created earlier. Make sure you have that string copied.

Proceed as follows for Windows (and then Linux):

  1. In Azure Policy > Definitions, find Configure Windows Arc-enabled machines associated with a Data Collection Rule for ChangeTracking and Inventory. Click Assign.
  2. Scope: Choose the same scope (subscription or RG) to cover the intended machines.
  3. In Parameters, you will see a field to input the Data Collection Rule Resource ID (it might be called “Data Collection Rule (DCR) to associate” or similar). Paste the full Resource ID of the DCR you created in Step 1 here. Double-check it’s correct (the ID includes /providers/Microsoft.Insights/dataCollectionRules/<name>). If the policy has any other parameters (like a toggle for multiple DCRs, but likely just the one), fill them accordingly.
  4. Remediation: Enable remediation so existing machines get associated immediately, not just new ones. Azure Policy will attempt to create the association resource for each existing machine in scope when enabling remediation for an association. Use the system-assigned managed identity as before.
  5. Assign the policy.
  6. Repeat for Linux Arc-enabled machines to be associated with a DCR—assign at the same scope, paste the same DCR Resource ID (assuming your DCR covers both Windows and Linux data, which the template one does), and enable remediation.

When these assignments are created, Azure Policy will again evaluate compliance. Initially, no Arc machines are associated with the DCR, so they’ll appear non-compliant. Then, the policy’s deploy-if-not-exists effect will kick in to create the association. Under the covers, an association is an Azure resource linking the Arc machine resource to the DCR. Once associated, the Azure Monitor Agent on that machine is informed (via Azure Arc’s agent or the AMA service) to apply the rule. In practical terms, within a few minutes of association, the Arc server’s AMA will start sending change-tracking data to the Log Analytics workspace as per the rule.

After remediation, you should see the compliance state turn green (compliant) for those policies, meaning each Arc server now has the DCR link. If you go to Azure Portal, navigate to the DCR resource and look under “Associated Resources”, you should see all your Arc machines listed as being attached to that DCR. Conversely, on each Arc machine’s Overview or Azure Monitor, you might see that it uses a Data Collection Rule for collecting data.

At this point, all required components are deployed: the monitoring agent and change tracking extension on each machine, and each machine is configured to send data to your Log Analytics workspace according to the DCR.

Step 5: Verification and Results

With everything configured via policy, it’s time to verify that Change Tracking and Inventory are indeed working on the Arc-enabled servers:

  • Azure Portal (Change Tracking blade): Pick one of your Arc-enabled server resources in the Azure Portal. In the menu, under Operations, click on Change tracking. You should now see that the feature is enabled. A message or indicator may say, “Change tracking with AMA is enabled,” and data should start appearing. After deployment, it might take a little while (several minutes) for the first data to be collected and uploaded. Once some data is in, you will see the number of changes or items for categories like Software, Files, Registry, Services, etc. For example, it might show counts of Software changes or list the current software inventory. The UI often has tabs for Inventory and Change Log. The Inventory tab will list installed software (and other tracked configuration items) with their current state, while the Change Log or Changes View will show a timeline of changes.
  • Log Analytics Queries: You can also go directly to the Log Analytics workspace and run queries against the data. The data collected by CT&I via AMA typically lands in tables like ConfigurationChange or ConfigurationData. You might query for ConfigurationChange | where Computer contains “<name-of-arc-server>” | sort by TimeGenerated desc to see recent changes. Another table, ConfigurationData, might hold the inventory snapshots. If the data is flowing, these queries will return results.
  • Azure Policy Compliance: Check the Azure Policy compliance dashboard for your assigned policies. Ideally, all Arc-enabled servers in scope should now comply with each policy (AMA installed, CT extension installed, DCR associated). If any are non-compliant, drill in to see why – for example, if a machine still shows missing AMA, ensure its managed identity is enabled and trigger the remediation task again. Over time, as new Arc-enabled servers are added to the scope, Azure Policy will automatically evaluate and deploy the agent/extension/DCR association to them, keeping compliance high.

You should also verify that the Data Collection Rule association is functioning: in the Azure Portal, go to the DCR resource and see the list of associated machines (under “Resources” or similar). Each Arc server should appear there to confirm the link.

To test that everything is working, try making a simple change on one of the Arc machines:

  • On a Windows Arc-enabled server, create a test text file in a directory that is being tracked (the DCR tracks certain paths by default; if you want to be sure, you could edit the DCR to add a specific path). Or change a registry value that might be tracked. Install or uninstall a small application.
  • Perhaps modify a .conf file in /etc or stop/start a service on a Linux Arc-enabled server.

After doing so, wait a few minutes and then check the Change Tracking log in Azure (or query the Log Analytics workspace) to see if your change was recorded. This will give you confidence that the pipeline from the server to Azure is working.

Expected Outcome: The Azure Arc machine’s Change Tracking and Inventory page should list the changes. For example, if you installed software, that should appear as an installation event in the change log, and the new software should appear in the inventory list. If you modify a file within scope, it should show up as a file change record. The screenshot below shows an example of an Arc-enabled machine’s Inventory view after enabling CT&I – you can see it has tabs for Software, Files, Windows Registry, Windows Services, and it’s listing installed software with details (this particular example highlights software inventory and updates on a Windows server):

Screenshot: Azure Arc-enabled server Inventory view after enabling Change Tracking and Inventory via AMA. The “Changes tracking with AMA” interface shows categories like Software, Files, Registry, and Services with counts of changes or items. In this example, the Software inventory is listed, showing installed updates and applications along with their version and installation time. This confirms that the Arc-enabled machine is reporting inventory data to Azure.

Compliance, Visibility, and Automation Benefits

By using Azure Policy to deploy Change Tracking and Inventory, you’ve achieved a consistent and automated configuration across your hybrid servers. Let’s highlight the key benefits and considerations of this approach:

  • Continuous Compliance: Once the policies are assigned, any current or future Arc-enabled server in the scope will automatically get the required extensions. If someone adds a new server to the environment (and onboards it to Arc), you don’t have to remember to set up change tracking on it – Azure Policy will take care of it. This ensures compliance with your organization’s requirement to have CT&I enabled everywhere. If a machine misses the agent or extension, it will appear non-compliant in Azure Policy, alerting you to an issue. The compliance dashboard becomes a quick way to see if all servers are being monitored.
  • Enhanced Visibility and Inventory Management: With CT&I enabled on all these servers, your team gains visibility into the configurations of all servers in one place. You can go to the Change Tracking blade (either via Azure Arc > Servers or Azure Automation/Monitor’s Change Tracking interface) and see a unified view of changes across machines. You can answer questions like “how many machines have X software installed” or “which machines had changes in the last week”. The inventory data helps in IT asset management (knowing what software versions are running, for example), and the change logs help in security and operations (detecting unauthorized changes or diagnosing incidents). All of this is now aggregated in Azure, leveraging the scalability of Azure Monitor.
  • Automation & Reduced Manual Effort: Before this, enabling change tracking on a server-by-server basis would require manually enabling each one or writing custom scripts. By using Azure Policy, we automated the rollout. The initial setup took some effort (as described in steps above), but now it’s largely self-sustaining. Azure Policy also automates remediation – e.g., if an admin accidentally removes the AMA extension from a server, the policy will detect non-compliance and redeploy it, bringing the server back into the fold. This kind of self-healing mechanism means your configuration is more resilient to drift.
  • Integration with Azure Services: The data collected can be used by other Azure services. For instance, you can create Azure Monitor Alerts based on the change data (maybe alert if a specific critical file is changed). Or integrate with Azure Automation runbooks or Logic Apps to respond to changes. Additionally, if your organization uses Microsoft Defender for Cloud (formerly Azure Security Center), enabling File Integrity Monitoring (FIM) is often a recommended practice – and the Change Tracking extension we deployed serves as the FIM solution for Arc machines. Thus, you’re also bolstering security monitoring by having this in place.
  • Permissions and Security Considerations: All data sent from the servers is secured via the AMA and the managed identity (which authenticates to Azure). The managed identity on the Arc server was crucial for the agent to fetch the DCR configuration securely. Ensure the identity was created adequately on each server (which you likely did manually). Sometimes, you could also use Azure Policy to enforce that Arc machines have system-assigned identities. However, that particular action might currently be done manually or through a script (the Policy only audits it in preview). Be aware that with system-assigned identities, you might need to grant the DCR appropriate permissions. Fortunately, when we associated the DCR via policy, Azure automatically handled permissions so that the machine’s identity could read the DCR (this is usually done by adding the “Azure Monitor Agent” service role for that identity on the DCR resource). If troubleshooting, ensure the DCR access control lists include the managed identity of the machine (or a wildcard for all Arc identities in that RG or subscription).
  • Region-Specific Notes: It’s worth noting that some features were in preview during their initial rollout. For example, at one point, the policies for Arc CT&I were marked [Preview] and initially supported only certain regions. If your Arc-enabled server’s resource is in a region not yet supported by Azure Monitor Agent or DCR, the policy will skip installation, as we saw. Microsoft continuously adds support, so check the latest documentation for regional limitations. The Data Collection Rule is a regional resource (typically tied to your Log Analytics workspace). Ideally, choose a region for the DCR that matches most of your Arc servers’ regions for optimal performance. Still, it’s not strictly required to match – Arc and AMA communicate via Azure’s global endpoints. If you operate in sovereign clouds (like Azure Government or China cloud), ensure the same features are available there, as there might be a slight lag in roll-out.
  • Ongoing Management: After the initial setup, you might rarely need to touch these policies again. However, keep them in mind if changes are needed. For example, if you want to adjust what is being tracked (add additional file paths or registry keys to monitor), you would edit the Data Collection Rule (you can do this in the portal by modifying the DCR’s configuration – enabling additional settings or paths). This change would automatically apply to all associated machines. If Microsoft updates the Change Tracking extension or you run into any issues, ensure your Arc agent and AMA are kept up to date (they usually update automatically). Monitor the Azure Policy compliance view occasionally to catch any anomalies.

Implementing Change Tracking and Inventory via Azure Policy on Azure Arc-enabled servers has effectively extended Azure’s configuration management capabilities to your entire hybrid environment. This setup will help maintain compliance, provide visibility into changes, and save your IT staff time by automating what would otherwise be repetitive tasks.

Conclusion

This blog introduced Azure Arc’s ability to bring Azure management to on-premises and multi-cloud servers. We focused on a practical scenario: enabling Change Tracking and Inventory on Arc-enabled servers using Azure Policy. We covered how Azure Arc projects servers into Azure Resource Manager, allowing us to use Azure Policy to ensure every server has the Azure Monitor Agent and Change Tracking extensions deployed and sending data to a Log Analytics workspace. By walking through the process of creating custom policy assignments via the Azure Portal, we deployed a solution that automatically onboards servers to Change Tracking at scale.

We started with the prerequisites like Log Analytics and Data Collection Rules, then systematically assigned built-in policies for Windows and Linux Arc machines to install the necessary extensions and configurations (with remediation tasks for existing machines). Along the way, we highlighted the importance of managed identities and how the policies help enforce compliance. The result is a robust, automated deployment of change tracking across all targeted machines, yielding better compliance, visibility, and control. Optionally, if your environment has specific needs, you could encapsulate all these policies into a single initiative or blueprint and reuse it across multiple subscriptions or tenants, ensuring your hybrid cloud governance includes change tracking everywhere.

With this setup, your team can confidently track changes across servers in Azure, your data center, or another cloud. When an auditor asks for the list of software versions on all servers, you can generate it from Azure. When a colleague says, “I wonder what changed on that server last night,” you have the answer at your fingertips. And when you deploy new servers through Azure Arc, they will automatically adhere to your change-tracking policy. This is the power of combining Azure Arc with Azure Policy – bringing automation and consistency to your hybrid environment and freeing you to focus on using the data (insights) rather than worrying about how to collect it.

By following the steps outlined above, IT teams can implement Change Tracking and Inventory on Azure Arc-enabled servers in a structured, repeatable way, using Azure’s portal tools and without needing complex scripting. Embracing such cloud-native management practices for hybrid infrastructure sets the stage for greater operational efficiency and control as your environment grows.

Happy tracking, and may your configuration changes always be visible and under control!

Thanks,

Steve Labeau, Principal Consultant / Blogger