In a recent pilot, about 10 Azure Arc-enabled Windows servers were onboarded to the wrong Log Analytics workspace for Change Tracking and Inventory (CT&I). The team needed to move these machines to a new, correct workspace – and do so without breaking CT&I. However, they quickly discovered a challenge: when CT&I was first enabled via the Azure Portal, it allowed the selection of a Log Analytics workspace and automatically created the necessary Data Collection Rules (DCRs) behind the scenes. If you later create a new workspace and want to switch to it, there is no obvious portal option to trigger the same DCR setup again for that fresh workspace. Creating a new workspace and hoping to “point” the Arc machines to it doesn’t work because the required DCRs (which tell the Azure Monitor Agent what to collect and where to send it) won’t exist.

As a result, trying to switch workspaces directly can leave CT&I non-functional – the machines would no longer report change or inventory data since they aren’t associated with any CT&I DCR on the new workspace. The initial workspace had a DCR created automatically, but the new workspace is missing one, so the move isn’t straightforward.

Why It Happens

This behavior concerns how the Azure Monitor Agent (AMA) and CT&I are architected. When you enable Change Tracking and Inventory on a machine using AMA, Azure automatically creates a Data Collection Rule (DCR) that defines the data to collect (file changes, registry changes, software inventory, etc.) and the Log Analytics workspace to send that data to. The DCR is typically named with a prefix like ct-dcr-… and is placed in a resource group (often the VM’s resource group). All machines that use CT&I with that workspace will be associated with this DCR. The first time you set up CT&I (for example, via the portal’s “Enable Change Tracking” wizard), Azure handles creating this rule automatically.

However, if you later decide to use a different Log Analytics workspace, Azure won’t create a new DCR for that workspace until at least one machine is enabled. There’s no button labeled “Move CT&I to new workspace.” The DCR from the old workspace can’t simply be “repointed” to a new workspace without manual steps. The result is that until you create a proper DCR for the new workspace, your Arc servers have nowhere to send their change-tracking data in that workspace. In short, CT&I requires a DCR per workspace, and it isn’t created until you onboard a machine to that workspace’s CT&I.

It’s also important to note that the Change Tracking & Inventory extension (for AMA) remains installed on the Arc machines. The extension works in tandem with AMA and the DCR: The DCR tells AMA (and the extension) what to collect and which workspace to use. A machine not associated with a CT&I DCR won’t report CT&I data to any workspace. This is why moving the workspace isn’t as easy as flipping a switch – ensuring the proper DCR and associations are in place.

The Simple Fix

Thankfully, the solution was straightforward. Once you know the trick, onboard at least one machine to CT&I in the new workspace to automatically trigger Azure to create the DCRs. In our scenario, the admin added a new Azure Arc server (one that wasn’t yet using CT&I) and enabled CT&I on that machine, pointing it to the new Log Analytics workspace. This single action caused Azure to generate the required CT&I DCRs for the new workspace (just like it initially did for the old workspace)​

With the new DCRs in place, the remaining task was to switch the other servers to use those DCRs. The admin accomplished this by manually disassociating the 10 original machines from the old workspace’s DCR and then reassociating them with the newly created DCR (which points to the new workspace). Once moved over, all 10 servers immediately began reporting change and inventory data to the new Log Analytics workspace, with CT&I functioning as expected. The switch was done without uninstalling agents or extensions and significant data gaps.

Why this works: By triggering the creation of the DCR through one machine, we leverage Azure’s built-in configuration for CT&I. We didn’t have to craft custom JSON templates or guess at DCR settings – Azure did it for us, ensuring the DCR has the correct data sources and schema for CT&I. (It is possible to create a CT&I DCR via an ARM template – Microsoft even provides one – but using the portal onboarding is the easiest and least error-prone method​.) With the DCR in hand, reassigning machines requires updating associations.

Note: An important caveat: Do not manually add or edit data sources on the auto-generated CT&I DCR. The DCR created by Azure includes the necessary data sources for change tracking and inventory. Changing or adding data sources can break the CT&I functionality or its UI. You should only attach or detach resources (machines) to this DCR, not modify what it collects.

Step-by-Step Instructions

The following is a step-by-step guide to implement this solution. It assumes you’ve already set up the new Log Analytics workspace and that all machines are Arc-enabled and have the Azure Monitor Agent (AMA) installed (since they were already reporting to the old workspace via AMA).

  1. Create the New Log Analytics Workspace (if not already done).
    In the Azure portal, create a new Log Analytics workspace (in the same region as your servers). Note this workspace’s name and resource group. No CT&I data will flow here until a DCR is set up, which we’ll handle next. To avoid confusion, ensure no policies or auto-onboarding are trying to use the old workspace for these machines.
  2. Onboard a “trigger” machine to CT&I using the new workspace.
    Choose one Azure Arc-enabled server (or an Azure VM) that is not currently enabled for Change Tracking (this could be a brand new Arc server or one of the 10 after you disable its CT&I – but using a new machine avoids any interruption on the existing ones). Navigate to that machine’s page in the Azure portal, go to Change tracking under Operations, and click Enable using AMA agent (Recommended). When prompted for a Log Analytics workspace, select the new workspace. Then click Enable. Azure will deploy in the background to set up Change Tracking on this machine with AMA. A deployment success notification should appear within a few minutes, and a new DCR will be created for the new workspace.

You can verify the DCR creation using Azure Monitor > Data Collection Rules. There should now be a DCR with a name starting with “ct-dcr-…” in the list, likely in the resource group of the machine or the workspace. This DCR contains the CT&I data collection configuration for your new workspace. (If you click on it and view its details, you’ll see it targets your new Log Analytics workspace as the destination for data.)

  1. Verify that the new DCR exists and is configured.
    After the above step, double-check that the DCR was indeed created. In Azure Monitor’s DCR list, find the new ct-dcr-* rule (you can filter by the new workspace’s resource group if needed). Open it and ensure that under “Data sources,” it has entries for things like Windows Registry, Windows Services, Files, Software, etc. (these represent the CT&I data types). Also, check under “Destinations” to see if it references the new Log Analytics workspace. You don’t need to change anything here – note the DCR’s Resource ID (found on the Properties or Overview page), as you’ll need that if you use PowerShell/CLI in later steps. This DCR should already have the “trigger” machine associated with it (since the portal added that machine when creating the DCR). No, we need to add the other servers to this rule.
  2. Disassociate the original servers from the old DCR.
    Before associating the machines with the new rule, it’s best to remove their association with the old CT&I DCR (the one pointing to the old workspace). This ensures they don’t report to two places or have conflicting configurations. There are a couple of ways to do this:

    • Via Azure Portal: Navigate to Azure Monitor > Data Collection Rules and open the old workspace’s CT&I DCR (it will also have a name like ct-dcr-…). Go to the Resources tab for that DCR, which lists all VMs/Arc machines currently associated. For each of the 10 Arc servers, please select it and click Delete (this removes the association, not the machine itself). Confirm the disassociation when prompted. Alternatively, you can go to each Arc machine’s Change tracking blade, click on Settings > DCR, see which DCR it’s attached to, and delete the association from there​ – the portal will guide you to remove it. Either way, removing the association means those machines are no longer linked to the old DCR (so they’ll stop sending CT&I data to the old workspace).
    • Via PowerShell: If you prefer, you can script the disassociation. You’ll first need the association name for each machine’s current DCR link. You can retrieve it with:

# Get the DCR associations for a given Arc server (replace with your server's resource ID)

Get-AzDataCollectionRuleAssociation -ResourceUri "ArcServerResourceID"

#This will list associations; look for one corresponding to the old ct-dcr rule (the #Name property typically includes part of the DCR name). Then you can remove it:

Remove-AzDataCollectionRuleAssociation -ResourceUri "ArcServerResourceID" -AssociationName "AssociationNameFromAbove"

#Run the above for each Arc server (or script a loop if you have many). This does the same thing as the portal: it removes the link between the machine and the old DCR.
  1. After this step, the 10 servers are no longer associated with any CT&I DCR. They will temporarily not report any change/inventory data (until we attach them to the new DCR in the next step). The Change Tracking extension is still installed on them but inactive. Do not uninstall the extension or AMA – that’s not necessary for the move.
  2. Associate the servers with the new workspace’s DCR.
    Now we’ll attach the 10 servers to the newly created DCR (so they start reporting to the new workspace). Azure provides a straightforward way to do this:

    • Via Azure Portal: Go to Azure Monitor > Data Collection Rules and open the new CT&I DCR (the one created for the new workspace). On the DCR’s page, select the Resources tab. Click the + Add button to add resources to this rule. In the Select a Scope pane, find your Arc-enabled servers and check them (you can filter by subscription, resource group, etc., to locate them). Once you’ve selected the servers you want to add, click Apply (or Add). Then click Save on the DCR page to finalize the change. All the chosen machines will be associated with the new DCR. You should now see the list of machines under the DCR’s Resources tab.

Using the Data Collection Rule’s Resources tab in the Azure portal to manage associations. Click + Add to select Azure Arc machines or VMs to attach to the DCR, or select an existing machine and click Delete to remove its association. In our case, we add the previously unassociated Arc servers to the new CT&I DCR.

    • Via PowerShell/CLI: You can also script the association of each machine to the new DCR. You’ll need the Resource ID of the new DCR (let’s call it $newDcrId) and each Arc server’s resource ID ($arcServerId). Then run the following for each server:

# PowerShell example - associate an Arc server with the new CT&I DCR

New-AzDataCollectionRuleAssociation `

-AssociationName "CTI-NewWorkspace-Assoc1" `

-ResourceUri $arcServerId `

-DataCollectionRuleId $newDcrId

#In the above, you can choose any friendly name for AssociationName (it could be something like "cti-new-assoc-machineName" or simply leave it consistent). You would repeat this for #each #server (or loop through a list).

#Similarly, with Azure CLI, you can run:

az monitor data-collection rule association create \

--name "CTI-NewWorkspace-Assoc1" \

--rule-id "$newDcrId" \

--resource "$arcServerId"

Replace $newDcrId and $arcServerId with the actual IDs. This command will create the association between the Arc machine and the new DCR. (Ensure you have the Azure CLI extension monitor-control-service installed, which the CLI should prompt for automatically.)

  1. Once done, the 10 Arc servers are all associated with the new DCR. Behind the scenes, the AMA on each machine gets the updated configuration telling it to send change data to the new workspace (and the change tracking extension on the machine is now governed by this DCR’s settings). Within minutes, these machines should resume uploading Change Tracking and Inventory data, but now to the new Log Analytics workspace.
  2. Verify data and clean up.
    Finally, confirm that everything is working on the new workspace. In the Azure portal, navigate to Azure Arc > [Your Server] > Change tracking and Inventory for a couple of the moved servers. You should see their data populating (file changes, software list, etc.) just as before. You can also run a Log Analytics query against the new workspace, for example:

ConfigurationChange

| where Computer startswith "ServerName"

Verify that you see recent change entries from the servers, or check the Inventory tab for software/services data. If data is appearing, the switch was successful. Meanwhile, the old workspace should stop receiving new data from these machines (historical data remains, but new records will go to the new workspace’s tables).

At this point, you have effectively moved the CT&I monitoring to the new workspace. All that remains is any housekeeping: if the old workspace is no longer needed, you might disable CT&I there or delete the old DCR. (If no machines are associated with the old DCR, it’s harmless to leave it, but you could delete that DCR resource to avoid confusion. The Change Tracking extension on each machine will now send data to the new workspace, so you do not need to reinstall anything. If you ever want to disable CT&I on a machine completely, you would disassociate it from its DCR and uninstall the extension – but that’s not needed in this scenario since we’re just moving workspaces, not turning off the feature.)

Key Takeaways

  • Changing the Log Analytics workspace for Change Tracking & Inventory (with AMA) isn’t automatic – you must ensure a proper Data Collection Rule exists for the new workspace. Azure will auto-create the DCR only when you enable CT&I on at least one machine in that workspace*​. Always start by onboarding one test machine to the new workspace to bootstrap the DCR setup.
  • Data Collection Rules (DCRs) are the linchpin for AMA-based monitoring like CT&I. All your Arc servers/VMs must be associated with a CT&I DCR that points to the intended workspace, or they won’t report data there. In our case, the solution was to create a new DCR (by onboarding a machine) for the new workspace and then repoint servers to that DCR.
  • Moving machines to a new workspace requires updating DCR associations, not reinstalling agents. We did not remove or reinstall the Azure Monitor Agent or the Change Tracking extension on the servers – we changed which DCR they were linked to. This makes the switch quick and low-risk.
  • Use the Azure Portal or scripts to manage DCR associations. The portal provides a user-friendly way to add or remove machines from a DCR (under Azure Monitor > Data Collection Rules > Your CTI DCR > Resources). For bulk operations or automation, PowerShell (New-AzDataCollectionRuleAssociation / Remove-AzDataCollectionRuleAssociation) and Azure CLI (az monitor data-collection rule association …) are available and let you script the re-association process.
  • Permanently attach and never modify the CT&I DCR’s data sources. When Azure creates the CT&I DCR, it includes the correct data sources (Registry, Files, Software, etc.) for Change Tracking & Inventory. Do not manually add or change data sources on this DCR – doing so can break the CT&I solution. Only add or remove resources (VMs/servers) to the rule. If you need different data sources, that’s beyond the scope of the built-in CT&I solution.
  • Plan workspace assignments ahead of time when possible. Although it’s possible to move machines, as we showed, it’s best to decide on the correct Log Analytics workspace beforehand during deployment or pilot. If mistakes happen (as in our pilot scenario), knowing this DCR method allows you to correct course cleanly.

By following these steps, Azure admins can confidently move Azure Arc-enabled servers to a new Log Analytics workspace for Change Tracking and Inventory without losing monitoring continuity. The key is leveraging Azure’s automation (via that one trigger machine) and then correctly updating associations – a clean and supported approach that avoids heavy lifting or guesswork. Happy monitoring!

Thanks,

Dave Kawula – MVP