Forum Discussion

MichaelMichalko's avatar
MichaelMichalko
Copper Contributor
Aug 03, 2026

Location of Defender for Identity Entry in Defender Tables

Our GRC group wants an automated report on windows servers and workstations over 7 days old not onboarded for Defender for Endpoint. A change in our environment (not sure if it was MS or us) has caused an additional entry in a column named "DiscoverySources" for Defender for Identity. It's my understanding that D4I is only used on domain controllers, but we get entries on non-DCs as well.  This identifier does not appear on the device dashboard, nor can I add it in with the custom column tab. Furthermore, if a machine requires onboarding for D4E, it will show them both in the same column, it separates them with a comma in the same field.

Right now, I have to do this process manually and with the overhead involved, it takes me about 30 minutes to run the reports, filter out the false positives and forward them to the appropriate staff.  They want this every day, and I can't do this operationally. I'd welcome the opportunity to create a Logic App based on a query to perform this function and route it.

Can someone point me in the direction of the table which contains the DiscoverSources column? I haven't been able to find it. That would help me to perform the necessary KQL and Logic App to automate this process. 

Long time listener. First time publisher. Thanks

1 Reply

  • GokselATAKAN's avatar
    GokselATAKAN
    Brass Contributor
    Aug 06, 2026

    Hi Michael,

    The column you're looking for is in the DeviceInfo table under advanced hunting. DiscoverySources lists every product or service that has seen/reported the device, along with when it last reported it, which is why you're seeing D4I and D4E stacked together in the same field with a comma separator when both apply.

    Since it's a dynamic/multi-value string field rather than a discrete column, it won't show up as a filterable option in the device dashboard or the custom column picker, that's expected behavior, not a bug on your end.

    For your use case, something like this should get you close:

    DeviceInfo
| where Timestamp > ago(1d)
| where OnboardingStatus != "Onboarded"
| where isnotempty(DiscoverySources)
| where DeviceType in ("Windows server", "Workstation")
| summarize arg_max(Timestamp, *) by DeviceId

    You'll then want to parse DiscoverySources with split() or has_cs/contains to isolate the D4I-only entries you consider false positives versus the ones that also flag D4E onboarding gaps, since it's stored as a comma delimited string, not an array.

    This should slot cleanly into a Logic App on a daily schedule using the Advanced Hunting API as the trigger source.