Troubleshooting Scenario Questions

Review the IdentityDirectoryEvents table for replication-related events.

Why it fails: IdentityDirectoryEvents logs directory object changes, such as attribute modifications or group membership updates, not authentication or replication access patterns. A DCSync-style replication attempt does not modify directory objects directly; it performs DRSUAPI calls, so querying this table would miss the actual replication events and only show post-hoc changes if any were made. Therefore, this table is not the correct source for identifying suspicious replication attempts.

Use IdentityQueryEvents to find LDAP queries related to replication.

Why it fails: IdentityQueryEvents captures LDAP queries sent to Active Directory, which can sometimes precede a replication attempt. However, the actual replication operation uses DRSUAPI over the Directory Replication Service Remote Protocol, not LDAP, and is recorded as a logon event, not a query event. Thus, querying IdentityQueryEvents would only reveal enumeration or reconnaissance, not the replication attempt itself, making it an insufficient and incorrect choice.

Check the IdentityAlertEvents table to see if the alert has additional context.

Why it fails: IdentityAlertEvents contains high-level security alerts generated by Defender for Identity, such as a suspected DCSync attack, but it does not provide the raw logon-level data needed to investigate or identify the specific replication attempt. Alerts are triggered based on detections, whereas you need to look at the underlying security events to confirm and analyze the attack behavior. Therefore, checking this table only gives you alert metadata, not the granular evidence required for investigation.

Advanced hunting

Why it fails: Advanced hunting is a query-based tool for proactive threat hunting and does not automatically present the full attack story of an incident. It requires writing KQL queries to explore data, so it is not the primary feature for viewing incident details and related entities.

Threat analytics

Why it fails: Threat analytics provides information about emerging threats and campaigns but does not show details of a specific incident in your environment. It is a knowledge base, not an investigation tool for incidents, so it cannot display the attack story and related entities.

Incident queue

Why it fails: The incident queue provides a list of incidents and their statuses, but it does not show the full attack story or detailed relationships between entities. To view the attack story, you need to open an incident, which is not done directly from the queue view.

TXT record

Why it fails: A TXT record carries arbitrary verification or policy text such as domain ownership proof or SPF; it provides no mail exchanger, so senders cannot locate Exchange Online for contoso.com. It is tempting because TXT is genuinely the correct record type when proving domain ownership or publishing DKIM and SPF policy data.

CNAME record

Why it fails: A CNAME aliases one hostname to another; mail routing requires an MX record pointing at Exchange Online's mail exchanger, so inbound mail to contoso.com is never delivered. It is tempting because CNAME is genuinely the correct record for autodiscover or other service hostnames that must resolve to a Microsoft endpoint.

SPF record

Why it fails: SPF is a TXT-based record authorising sending hosts for outbound mail; it does not direct inbound delivery, so mail to contoso.com still cannot reach Exchange Online. It is tempting because SPF is genuinely the correct record when recipients reject or spam-folder your outbound messages due to missing sender authorisation.

Use the Threat analytics dashboard to find the email.

Why it fails: Threat analytics reports on campaigns, actor profiles and vulnerabilities affecting your estate; it holds no tenant message data, so no specific email can be located there. It is the correct destination when researching whether a published threat campaign applies to your environment.

Go to the user entity page and view their email activity.

Why it fails: The user entity page aggregates sign-in, device and mail activity, but exposes only summarised events rather than the raw message. Full headers, attachments and URLs live in Explorer's email entity view. Entity pages suit investigating a compromised account's behaviour across services.

Open the incident related to the email and view the alert details.

Why it fails: Alert details show the detection logic, affected entities and evidence summary, but not the complete message body. The email entity page in Explorer renders headers, attachments and URLs for triage. Incident alerts are the right starting point for correlating multiple related detections across workloads.

The B2BCollaborationOutbound setting is blocking access

Why it fails: The B2BCollaborationOutbound setting controls how Contoso users, the users in the originating tenant, are shared with Fabrikam - specifically, whether Contoso users can be invited to Fabrikam's tenant or access applications hosted there. It says nothing about Fabrikam identities trying to get into Contoso resources. Because the reported problem is an external user from Fabrikam being unable to access Contoso, an outbound policy cannot be the root cause; that failure can only be governed by Contoso's inbound cross-tenant access settings.

The default cross-tenant access policy is set to block all

Why it fails: The default cross-tenant access policy applies only when no tenant-specific policy has been configured for that partner organization. In the exhibit, Fabrikam has its own organizational-specific cross-tenant access settings, and those settings take precedence over the default policy for that tenant. Even if the default policy were shown as blocking - which it is not - the partner-specific inbound B2B collaboration configuration would override it. Therefore, an empty or non-blocking default cannot explain why Fabrikam B2B users are failing to gain access to Contoso.

The B2BDirectConnectInbound setting is empty

Why it fails: B2B direct connect is a different collaboration capability used for Teams shared channels, allowing users from Fabrikam to participate in shared channels in Contoso's tenant without becoming B2B guest directory objects. An empty B2BDirectConnectInbound setting would therefore affect Teams shared-channel access, not the standard B2B collaboration invitation flow that lets external users sign in as guests and access Contoso apps. Since the issue described is about B2B collaboration guest access, the empty direct-connect setting is irrelevant to the failure, even if it appears alongside the collaboration settings in the cross-tenant access policy.

Isolate the device from the network immediately

Why it fails: Isolating the device cuts network connectivity before compromise is confirmed, and does not start an automated investigation; it is a containment action taken afterwards. It is tempting because isolation limits spread, and would be correct once investigation confirms active compromise requiring immediate containment.

Initiate a Live Response session to gather forensic data

Why it fails: Live Response collects forensic artefacts but does not itself trigger the automated investigation the scenario requires; the device must first be flagged for investigation in Defender XDR. It is tempting because forensic triage is valuable, and would be correct when deep artefact collection is needed after automated investigation has already run.

Run a full antivirus scan from Microsoft Defender Antivirus

Why it fails: A full antivirus scan only inspects local files for known malware signatures; it cannot correlate the multi-source alerts already surfaced in Defender XDR or trigger the automated investigation the scenario requires. It is tempting because scanning is a familiar first response to a slow device, and would be right for suspected file-borne malware with no existing alerts.

Use the Microsoft Purview compliance portal to search for the user's activity in audit logs.

Why it fails: The Microsoft Purview compliance portal's audit log search is primarily a compliance tool, providing coarse-grained activities (e.g., 'User signed in') from a limited set of workloads, with a default retention period of only 90 days (or 180 for E5). It lacks KQL-based correlation across endpoints, email, and identity, so it cannot efficiently timeline a user's actions for a threat investigation. While useful for compliance audits, it is not the optimal first stop for hunting cross-workload activity.

Use Microsoft Defender for Cloud Apps to investigate the user's activity log.

Why it fails: Microsoft Defender for Cloud Apps (MCAS) focuses exclusively on SaaS and cloud platform activities, such as file downloads or sign-ins from third-party apps (e.g., Dropbox, AWS). It does not cover Exchange Online mail events, Teams messages, or on-premises Active Directory sign-ins, so a user's full attack surface would be missed. Additionally, CloudAppEvents is just one schema in advanced hunting; the Defender portal provides a broader, normalized view, making a separate MCAS investigation redundant when advanced hunting is available.

Use Microsoft Sentinel to query the user's events from the workspace.

Why it fails: Microsoft Sentinel is a full SIEM that can consume and analyze logs, but using it for a user investigation requires ingesting data via connectors and having a workspace provisioned with the necessary pricing tier (Pay-as-you-go or Microsoft Sentinel capacity). When a threat is suspected, the integrated, default tool in Defender XDR is advanced hunting—Sentinel is more appropriate for long-term archiving or complex, multi-source correlation that extends beyond M365 data. Querying a Sentinel workspace as a first step adds latency and licensing overhead with no immediate benefit over the built-in Defender portal query.

Ensure that devices are Microsoft Entra ID joined and not domain joined.

Why it fails: The enrollment path for Intune in Microsoft 365 Business Premium supports both Microsoft Entra ID joined and hybrid Microsoft Entra ID joined devices, and domain-joined devices alone cannot use cloud MDM. However, the devices in this scenario are already Microsoft Entra ID joined, so the join type is not the blocker. A device being joined does not provide a user license, and licensing—not join state—is the actual prerequisite for enrollment.

Check the Windows 10 version; version 1607 or later is required.

Why it fails: Windows 10 version 1607 or later is a baseline for Microsoft Entra ID auto-enrollment in legacy scenarios, but the current version is almost certainly above that threshold and therefore irrelevant. Even a fully supported Windows 10 build will fail Intune enrollment if the user account lacks an Intune license. Checking the OS version checks the wrong prerequisite; it would only diagnose an environment that hasn't been updated in years.

Check that the MDM authority is set to Microsoft Intune in Microsoft Entra ID.

Why it fails: The MDM authority is the service that manages devices, and in Microsoft Entra ID it must be set to Microsoft Intune for MDM enrollment. When automatic enrollment is configured, that authority is already Intune; if it were not, enrollment wouldn't be attempted at all. Rechecking it is redundant because the error is about per-user licensing, not the overall management authority.

Number of affected users

Why it fails: The number of affected users is a business-impact metric that support may factor into severity or SLA response times, but it is not required to open a ticket. During initial triage, the engineer can proceed with the Tenant ID and a detailed problem description, then ask for the user count if needed. Specifically, this number can be updated later via an incident change request, so it should never block submission of the support request.

Network bandwidth graph from the past 24 hours

Why it fails: A network bandwidth graph is a specialized diagnostic artifact that support will explicitly request only after initial checks point to connectivity, jitter, or throughput as a root-cause candidate. Prematurely attaching it can mislead triage, because most M365 issues are due to identity or service-side states rather than local bandwidth. It is also not a standard field in the Microsoft 365 admin center support request form, so supplying it provides no benefit to the initial routing.

Microsoft Intune admin center

Why it fails: The Microsoft Intune admin center is focused on mobile device management (MDM) and mobile application management (MAM) for Windows, iOS, Android, and macOS devices. While it can show device compliance and conditional access status, it lacks the security analytics engine and incident correlation that Defender for Identity alerts require. It also does not ingest identity authentication metadata from domain controllers, so it cannot display suspicious account activities or compromised credential paths.

Microsoft Purview compliance portal

Why it fails: Microsoft Purview's compliance portal is dedicated to information protection, data-loss prevention, eDiscovery, and audit log search, serving legal and regulatory requirements. Although it contains unified audit logs that might include some identity events, it is not an incident-management or threat-investigation workspace. Defender for Identity alerts have no native queue or incident correlation inside Purview; its role is retrospective compliance, not live security operations.

Microsoft Entra admin center

Why it fails: The Microsoft Entra admin center handles directory administration, user provisioning, self-service password reset, and conditional access policies, and it does show Microsoft Entra Identity Protection risk events. However, those risk detections are not the same as Defender for Identity alerts and are not correlated with endpoint or email telemetry in a unified incident view. For full attack-chain reconstruction—especially where Defender for Identity sensors monitor domain controllers—you must use the Microsoft Defender XDR portal rather than Entra.

The device is not enrolled in Microsoft Intune

Why it fails: The device is actually enrolled in Microsoft Intune; enrollment is not the cause of the access block. Conditional Access evaluates the device's compliance state after enrollment, and the compliance policy flagged the device as non-compliant due to missing security updates. If the device were unenrolled, the Conditional Access policy would still block, but for a different reason—lack of a managed identity—whereas here the Intune management record exists and shows non-compliance.

The Conditional Access policy is not applied to SharePoint Online

Why it fails: The Conditional Access policy does target SharePoint Online; the cloud apps assignment includes it, so the policy is evaluated during the access request. The access attempt is blocked because the grant control 'Require device to be marked as compliant' fails, not because the policy is scoped away. If the policy did not include SharePoint Online, no block would occur, but this scenario specifies that the policy applies to the service in question.

The user does not have an Intune license

Why it fails: The user must have an Intune license because the device is enrolled and its compliance status is being evaluated—enrollment requires an Intune license assigned to the user. The block is not due to missing licensing; it is the device's non-compliant state from missing security updates that fails the Conditional Access grant control. Licensing issues would typically prevent enrollment or policy assignment, not trigger a specific compliance-based access denial after enrollment.

DeviceProcessEvents

Why it fails: DeviceProcessEvents captures process creation and execution events, such as ProcessName, ProcessCommandLine, and parent/child relationships. While a malicious executable might eventually appear in this table when it runs, the question asks about finding the executable's file creation, which happens before execution. Relying on this table would miss droppers that create files but are never executed, and even when a process is recorded, the file's creation timestamp and full folder path may not be captured.

DeviceNetworkEvents

Why it fails: DeviceNetworkEvents is incorrect because it tracks outbound and inbound network connections, including SourceIP, DestinationIP, Ports, and URLs. It does not contain a FileName or FolderPath field, so it cannot be used to identify the malicious executable on disk. Network telemetry is useful for discovering command-and-control communication or data exfiltration, but it is not the right source for local file creation events.

DeviceRegistryEvents

Why it fails: DeviceRegistryEvents is not the right table because it records changes to registry keys and values, such as registry value modifications and data written to the Windows Registry. Although malware may create registry persistence entries that reference a file path, the table does not log the file creation itself, and the path is only present if the malware writes it as part of its persistence mechanism. The investigation requires locating the file, not the registry modification, so this table is insufficient.

Outbound cross-tenant access settings for the partner's tenant ID

Why it fails: Outbound cross-tenant access settings for the partner's tenant ID govern what your organization's users can access in the partner tenant (e.g., MFA or device-compliance requirements imposed on your users when they authenticate to partner apps). They do not control whether partner users can sign in to your applications, so examining them cannot reveal why inbound partner access is failing.

The app's user assignment and provisioning configuration

Why it fails: While the app's user assignment and provisioning configuration can affect which users appear in the app or whether accounts are synced, cross-tenant access settings are evaluated first at the Microsoft Entra ID tenant boundary for an external identity. Even if the partner user is assigned to the app, a blocked default inbound cross-tenant access policy will reject the authentication before app-level assignment is considered.

The partner's inbound cross-tenant access settings for your tenant

Why it fails: The partner's inbound cross-tenant access settings for your tenant define the policies your users must satisfy when they access resources in the partner tenant—for example, whether the partner trusts your MFA claims. The issue involves partner users attempting to access your apps, so the relevant configuration is your inbound settings for the partner tenant, not the partner's inbound settings for your tenant.

Hunting

Why it fails: Hunting (Advanced hunting) is a query-based workspace where security teams proactively search raw telemetry data for threats using KQL. It does not provide the incident queue or correlated alert grouping needed to review a specific incident's full story. Incident review focuses on investigating an existing alert-detection aggregation, not crafting custom queries over historical data.

Action center

Why it fails: The Action center tracks and manages remediation actions such as deleting a file, quarantining a device, or blocking a URL, often generated by automated investigations. It lists pending and completed actions, not the incidents themselves, and offers no incident list or attack story view. For reviewing incidents, you must navigate to the Incidents queue rather than the action-level workflow.

Reports

Why it fails: Reports in Defender XDR present aggregated telemetry and trend summaries—such as threat detection counts, protection status, and device health—rather than a list of specific incidents with their alert evidence and associated entities. They are useful for executive or historical analyses, not for triaging and investigating the details of current incidents. The incident review workflow lives outside the reporting area.

Threat Analytics

Why it fails: Threat Analytics in Microsoft 365 Defender aggregates threat intelligence, attack campaigns, and vulnerability reports specific to the organization's exposed assets. While it provides valuable context on active threat actors and recommended mitigation actions, it only generates static incident intelligence and does not trigger any automated investigation or remediation workflow.

Advanced Hunting

Why it fails: Advanced Hunting in the Microsoft 365 portal is a query-based Kusto Query Language (KQL) interface that enables security analysts to interactively search raw event data across up to 30 days, pivot across tables, and customize threat hypotheses. It is a manual and retrospective exercise that requires analytical skill to identify and interpret patterns, and it never performs automated response or remediation without an integrated custom action outside its workflow.

Secure Score

Why it fails: Secure Score is a configuration benchmarking tool that evaluates an organization's security posture by quantifying adoption of Microsoft security controls and recommending improvement actions with a scoring system. It measures the maturity of security settings but does not analyze live signals, escalate alerts, or execute automated remediation activities, making it entirely separate from incident response automation.