Forum Discussion
What caught you off guard when onboarding Sentinel to the Defender portal?
I went ahead and wrote up the full breakdown based on the framing above. If it's useful for anyone working through this: https://securingm365.com/defenderxdr/sentinel/sentineldefender-part2/
Covers the 4 audit aspects I believe need to be considered, before commencing the migration in any production environment.
Would genuinely welcome any pushback or edge cases people have hit that aren't in there.
The incident creation rules being active during onboarding is the one that would catch most teams off guard. Those rules tend to be set-and-forget from early Sentinel deployments - nobody remembers they exist until the XDR connector spins up and suddenly the incident queue doubles overnight. The onboarding wizard offers to disable them, but by that point you're already cleaning up.
What I'd add to the inventory angle: check your automation rules for title-based conditions. Things like "if incident title contains 'Suspicious sign-in', then enrich and notify". After onboarding, XDR groups and renames incidents differently - those conditions don't throw errors, they just quietly stop matching. Found that pattern in more environments than I'd like to admit.
Interested in how you're structuring the pre-migration inventory - one-time audit before onboarding, or something you keep running post-migration to catch drift?
I totally agree, that’s exactly the pattern I see in the wild. The XDR connector flipping on while incident-creation rules are still active is the fastest way to double your incident queue overnight, so id always pause Defender incident creation for each product before connecting (but echo your "too late" comment). I also recommend doing the initial connect into a staging workspace and running a 48–72 hour smoke test so you can validate behavior without impacting production (assuming that environments are running development workspaces). But i honestly believe we need to treat the inventory as living: run a one-time pre-migration audit of connectors, incident rules, analytics, automations, and RBAC, then keep that inventory live with scheduled drift checks (atleast until the dust is settled).