Export code integrity logs (WDAC) into LAW

Without Defender for Endpoint P2, collecting WDAC Code Integrity events at scale quickly becomes challenging due to log volume, ingestion complexity, and the effort required to operationalise the data. From our experience working on large WDAC implementations, the real difficulty is not only collecting logs but managing volume and turning those signals into actionable policy decisions without a dedicated operational layer.

PoliEze approaches this by acting as the operational control plane for WDAC. WDAC remains the enforcement layer and all telemetry stays Microsoft native. PoliEze centralises Code Integrity visibility, policy operations, and decision workflows. In environments where Defender for Endpoint is not available, it offers an alternative way to manage Code Integrity telemetry while aligning with the existing WDAC architecture. How teams approach this often depends on scale, licensing, and how WDAC is expected to be operated long term.

Hello Cyber Punk, you’re on the right track using Azure Arc + AMA to pull WDAC logs into Log Analytics without upgrading to Defender P2. The main piece that’s missing is a Data Collection Rule (DCR) that tells the Azure Monitor Agent exactly which Windows Event channel to ship—namely the CodeIntegrity operational log where WDAC writes its audit events.

Here’s what you can try:

1. Create a Data Collection Rule In the Azure portal (or via CLI/PowerShell), create a DCR that points to your Log Analytics workspace and includes the Windows event channel “Microsoft-Windows-CodeIntegrity/Operational.” Example DCR JSON (replace placeholders with your values):

   
      {
   
        "dataSources": {
   
          "windowsEventLogs": [
   
            {
   
              "channels": [ "Microsoft-Windows-CodeIntegrity/Operational" ],
   
              "streams": [ "Microsoft-Windows-Event" ],
   
              "format": "xml"
   
            }
   
          ]
   
        },
   
        "destinations": {
   
          "logAnalytics": [
   
            {
   
              "workspaceResourceId": "/subscriptions/<subID>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<lawName>"
   
            }
   
          ]
   
        }
   
      }
   
   

   • If you prefer CLI, see the “Upload logs to Azure Monitor” doc for the az monitor data-collection-rule create syntax.
2. Assign the DCR to your Arc-enabled machines • In your Log Analytics workspace → Agents management → Data Collection Rules → Assign rule → select your Azure Arc machines. • Or use az monitor data-collection-rule association create to bind the rule to your Arc machines.
3. Validate AMA initialization and log flow • On the endpoint, look under C:\ProgramData\AzureMonitorAgent\—you should see a folder for your DCR and some config files once it’s applied. • Check the AMA logs in that ProgramData path for any errors. • In the portal Log Analytics workspace, run a quick KQL query to confirm logs are arriving:

   
        WindowsEvent
   
        | where EventLog == "Microsoft-Windows-CodeIntegrity/Operational"
   
        | take 20
   
   

4. Troubleshoot if you still don’t see anything • Double-check outbound HTTPS (443) is allowed to your workspace. • Ensure the machine is healthy in Azure Arc (run azcmagent show). • Review the local AMA logs (C:\ProgramData\AzureMonitorAgent\Logs) for DCR parsing or connectivity errors.

Note: Defender Plan 2 will give you turnkey WDAC telemetry in Defender for Endpoint, but you can absolutely collect the raw CodeIntegrity events with AMA + DCR in Plan 1.

Let me know if you hit any specific errors in the AMA logs or if your DCR JSON needs tweaking!

Reference list

• Upload logs to Azure Monitor (via Arc data services DCR examples)

https://dotnet.territoriali.olinfo.it/azure/azure-arc/data/upload-logs?wt.mc_id=azure-cxp-community

WDAC code integrity events can be collected into Log Analytics with Azure Monitor Agent on Arc-enabled devices, but only if a valid Data Collection Rule (DCR) is correctly targeting the machines and a supported log source is configured. The behavior described (extension shows Succeeded, AMA service running, but no %ProgramData%\Azure Monitor folder and no data) indicates that AMA is installed but not yet configured by any effective DCR.

Use the following checks and steps:

1. Verify AMA and Arc prerequisites

• Confirm the machine is shown as an Azure Arc–enabled server in Azure and is in the same subscription/region scope where the DCR is defined.
• Ensure the Azure Monitor Agent extension status is Succeeded on the Arc resource (already done) and that the Azure Monitor Agent service is running.

2. Confirm a DCR is actually applied to the device

• In the Azure portal, open the Data Collection Rule that was created.
• On the Resources tab, verify that the Arc-enabled server is explicitly selected. If not, add it and save.
• If using scope-based association (resource group/subscription), ensure the Arc server is within that scope.
• After saving, allow a few minutes for the agent to contact the Azure Monitor Configuration Service (AMCS) and download the configuration.

3. Validate DCR configuration for log collection

• In the DCR Collect tab, confirm that a log data source is configured that matches what is on the device:
  • For custom text logs (for example, exported WDAC logs written to a file), configure Custom Logs via AMA and specify the correct File pattern path and table name ending with _CL.
  • Ensure the destination is a Log Analytics workspace and that the workspace is reachable.
• For custom logs, first create the destination table in the workspace with the required schema:
  • TimeGenerated (DateTime)
  • RawData (String) or Message (String) if using a forwarder.

4. Check that AMA has pulled the DCR

• Once the DCR is correctly associated, AMA contacts AMCS to fetch the configuration. When this succeeds, the agent creates its configuration and data directories under %ProgramData%.
• If %ProgramData%\Azure Monitor (or similar AMA folders) still does not appear after 10–15 minutes, it usually means:
  • No effective DCR is associated with the Arc resource, or
  • The machine cannot reach Azure Monitor endpoints (network/firewall issue).

5. Network and connectivity

• Ensure outbound connectivity from the Arc server to Azure Monitor endpoints (logs endpoint and AMCS). If egress is restricted, AMA cannot download DCRs or send data.

6. Licensing vs. collection method

• Upgrading to Defender for Endpoint Plan 2 is not required for AMA itself to collect logs into Log Analytics. Plan 2 is needed for advanced Defender features and built-in WDAC reporting, but AMA + Arc + DCR is a valid and supported way to ingest logs into a Log Analytics workspace.
• The key is to ensure that WDAC events are actually written to a source that AMA can read (for example, a text log file configured as a Custom Log via AMA) and that the DCR is correctly configured and applied.

7. Troubleshooting AMA on Arc

• Use the Azure Monitor agent troubleshooting guidance for Windows Arc-enabled servers to verify:
  • The agent can reach AMCS and the logs endpoint.
  • The Arc instance metadata (HIMDS) is available and the resource identity is correct.
• If AMA cannot reach AMCS, it will not initialize fully and no configuration or %ProgramData% structure will be created.

Once the Arc server is correctly associated with a DCR that collects from a valid WDAC log source and network connectivity is confirmed, AMA will initialize, create its configuration under %ProgramData%, and begin sending data to the Log Analytics workspace. WDAC events will then be queryable in the target table (for example, the custom _CL table configured in the DCR).

References:

• Troubleshooting guidance for the Azure Monitor agent on Windows Arc-enabled server
• Collect logs from text files with the Azure Monitor Agent and ingest to Microsoft Sentinel