This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 76%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
Greetings, I added a few extra tags to this as we are not quite sure of why we cannot Disconnect or Delete the Security Events Via the Legacy Agent Connector from our Sentinel environment. All Azure VMs have been migrated from the MMA (Legacy) agent to the AMA agent. When I review the AMA migration workbook I see all virtual machines using AMA and non with the Legacy agent still installed.
Yet we cannot remove the Legacy connector and we have seen a huge spike in costs related directly to the SecurityEvent table in the past 3 weeks. It is defiinitely getting duplicate data and we think the most likely contributor is the Legacy connector. We have engaged a consultant and they haven't been able to find it. We have been scouring through many Microsoft posts around this topic. Any help would be greatly appreciated.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(60.8, 94%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESN%3C/text%3E%3C/svg%3E)
This error message typically indicates that you previously configured auto-provisioning of the MMA agent and used a Sentinel instance to send some logs there. However, I have encountered some environments where I could not locate this configuration, while in others, I was able to identify and remove it. The first step should be to check if this configuration exists anywhere in Defender for Cloud.
You can also confirm whether the legacy agent is the problem by checking if any of the machines have both agents installed. By querying the agent category, you can determine if both agents are present, which might indicate that they are both sending logs to Sentinel.
Heartbeat
| where TimeGenerated > ago(21d)
| summarize make_set(Category) by Computer
Currently, Heartbeat logs use a different endpoint than real events. This means that it's possible for someone to block Heartbeat logs while still allowing security events. You can verify if logs are coming from both sources by checking specific fields that are unique to logs created by the newer version of the AMA agent. For example, the EventRecordId field is only present in the newer version of the AMA agent and does not appear in logs from the MMA or older AMA versions.
SecurityEvent
| where TimeGenerated > ago(21d)
| extend IsEventIdPresent = iif(isempty(EventRecordId), false, true)
| summarize make_set(IsEventIdPresent) by Computer
However, in my experience, duplicates are often caused by DCR misconfigurations. This typically happens when multiple DCRs are assigned to the same machine or when logs are processed through multiple ingestion-time transformations, resulting in duplicates being output to the same table.
This error message typically indicates that you previously configured auto-provisioning of the MMA agent and used a Sentinel instance to send some logs there. However, I have encountered some environments where I could not locate this configuration, while in others, I was able to identify and remove it. The first step should be to check if this configuration exists anywhere in Defender for Cloud.
You can also confirm that the issue is with the legacy agent by checking if any of the machines have both agents installed. By querying the agent category, you can determine if both agents are present, which might indicate that they are both sending logs to Sentinel.
Heartbeat
| where TimeGenerated > ago(21d)
| summarize make_set(Category) by Computer
Currently, Heartbeat logs use a different endpoint than real events. This means that it's possible for someone to block Heartbeat logs while still allowing security events. You can verify if logs are coming from both sources by checking specific fields that are unique to logs created by the newer version of the AMA agent. For example, the EventRecordId field is only present in the newer version of the AMA agent and does not appear in logs from the MMA or older AMA versions.
SecurityEvent
| where TimeGenerated > ago(21d)
| extend IsEventIdPresent = iif(isempty(EventRecordId), false, true)
| summarize make_set(IsEventIdPresent) by Computer
However, in my experience, duplicates are often caused by DCR misconfigurations. This typically happens when multiple DCRs are assigned to the same machine or when logs are processed through multiple ingestion-time transformations, resulting in duplicates being output to the same table.
Hello Sandor,
Great suggestions. Yes, I know for sure that there was previously something setup that would auto install the MMA agent. I know this because when I was trying to migrate servers from MMA to AMA, sometimes the MMA agent would get reinstalled. I have not been able to track down where that was coming from yet.
I did trim down the DCRs a few days ago. We are using Defender for Identity on our DCs and Sync servers. We have our Defender environment connected to Sentinel and there are connectors there that maybe are already doing what they need to be pumping Def for Identity events for example for the on prem AD environment to Sentinel. Maybe we do not need to use AMA with DCR to add more content to Sentinel.
I will try your KQL that you shared as well.
So it appears that SecurityEvent Table is no longer ingestion large amounts of data. The data was being ingested via DCR that was applied to DCs. This may have been a remnat of the old AMA config, unless it was auto created when the migration to AMA happened. Will review tomorrow to see if we are still capturing key AD Security Events in Sentinel via Defender for Identity.
When I ran your two queries I had the following results: No legacy agents like the AMA migration Workbook also confirms.
The second query showed my domain controllers with this value:
set_IsEventIdPresent [true]
0 true
Okay I just queried the SecurityEvent Table and it does not look like it's ingesting after we removed the DCs from the DCR. So I believe that tells us the only source was AMA and the DCR on the Domain controllers. So I think we need to tune that DCR to just get the key data elements and then add the domain controllers back to it.
Based on your description, it appears that only the AMA agent was forwarding those events.
However, it could still be a DCR misconfiguration, such as the DCR processing the event multiple times or creating duplicates during transformations.
If that's not the case, it might simply be a noisy machine that requires some tuning.
Let me know if you have any questions.
The DCR that was gathering Securityevent data (Event Logs) via the Domain Controllers was tagged as created by Sentinel. I do think we will want to get this turned back on in slimmed down way. I don't think the Defender XDR connectors are necessarily gathering the key events needed including the Defender for Identity components. Anyway, thank you for your help.