M365 Incident Response Toolkit: Graph, Exchange Online and Retired Modules

Introduction

Per IR0.4 the evidence lives in four domains reached through several surfaces. This section is what you install to reach them, what each tool is for, and where to practice without touching anything that matters.

It is deliberately short on installation instructions and long on which tool answers which question, because the second is the part that decides whether an investigation moves.

A toolkit section is the fastest-ageing part of any incident response material, and two entries in the standard M365 list stopped working during 2025.

Start with what to remove, because a toolkit section that only adds things leaves the broken entries in place.

Neither retirement was quiet in Microsoft's own channels and both are close to invisible from inside a working script, which is the combination that produces the scenario at the top of this section.

This is not a style preference or a recommendation to modernize. Both modules stop working, and one of them already has.

Start with what no longer works, because it is the most common cause of a first session going wrong.

MSOnline PowerShell is retired. Microsoft's own migration guidance states it was retired as of 30 May 2025, following deprecation on 30 March 2024 and a series of deliberate temporary outages through early 2025 to prepare tenants for it.

That outage program is worth knowing about because it is unusual. Microsoft deliberately broke the module for hours at a time across 2025 so that organizations would find their dependencies while there was still time to migrate, which tells you how widely the modules were still in use.

The retirement was not sudden. It was announced in 2022, deprecated in March 2024, and Microsoft ran a series of deliberate temporary outages through early 2025 so that tenants would discover their dependencies before the permanent switch-off rather than after it.

Both retirements landed close together, which is why so much surviving material predates them.

AzureAD PowerShell is retired as well. Support ended on 30 March 2025, and its retirement began from 1 July 2025 after being deferred so organizations could finish migrating off MSOnline first.

The practical risk is not that somebody runs a retired module today. It is that a runbook written against one has never been tested since, and per module one an untested procedure is the failure mode this course keeps returning to.

Both were the standard way to reach Entra ID from PowerShell for the best part of a decade, which is why they are still named in so much material.

Both appear throughout material written before 2025, which is most of the M365 incident response guidance on the internet. A script found in a repository or a command copied from a blog post is more likely than not to name one of them.

The recommendation reports the operations, the number of API requests, the date of the last one and the daily user count, which is enough to find the script and the account running it rather than only to know that something is.

Check whether yours still reference them. Entra sign-in logs will show usage, and there is an Entra recommendation that reports on legacy module usage over the previous thirty days, which is the fastest way to find scripts nobody remembers writing.

Two retired modules and a great deal of surviving guidance that still names them is the situation this section opens in, and it catches people who learned this platform earlier rather than later.

Three modules cover everything this course asks you to run.

The replacements are supported, current and cover the same ground.

Two of the three cover almost everything, and the third exists to make migration easier.

Three modules cover everything this course asks you to run, and every command in the material is written against them.

The Graph module is large and installs a great many sub-modules by default, which is worth knowing on a constrained machine. It can be installed in parts where only some services are needed.

Installation is a single command each and the modules are published in the PowerShell Gallery, so nothing here requires an approval or a download from anywhere unusual.

# The current toolkit
Install-Module Microsoft.Graph            -Scope CurrentUser
Install-Module ExchangeOnlineManagement   -Scope CurrentUser

# And check whether anything you run still names the retired ones
Get-InstalledModule |
  Where-Object { $_.Name -in @('MSOnline','AzureAD','AzureADPreview') } |
  Select-Object Name, Version, InstalledDate

The first two do most of the work in this course. Graph reaches the identity and directory domains from IR0.4, and Exchange Online reaches email and the audit log, which between them covers every practice card up to module six.

Graph is the one to reach for by default and Exchange Online is the one you will use more often than you expect, because several mailbox questions have no equivalent anywhere else per IR0.4.

Every command in this course is written against these three, so a reader working the practice cards will not meet a retired module anywhere in the material.

The Entra module exists because the migration from AzureAD left gaps, and it was built to close them with over ninety per cent parity against the module it replaces. If you are converting old scripts rather than writing new ones, it is frequently the shorter path.

The consolidation has a practical consequence worth understanding rather than resenting. Before Graph, each product had its own module, its own authentication and its own field names, and a cross-product question meant three connections and a manual join. One endpoint removes that, at the cost of a larger surface to learn.

It also means one authentication rather than several, which matters more during an incident than it does on an ordinary day, because per module one every connection is an opportunity to discover a permission problem.

Graph is the one worth learning properly. It is a single endpoint across the Microsoft 365 services rather than a separate module per product, which is the reason Microsoft consolidated onto it and the reason a query written against it will still work next year.

The retirements matter more than a version note usually would, because guidance written against the old modules is still the majority of what a search returns. Per IR6.2 a command that no longer exists is the obvious failure and the dangerous one is a command that still runs against a different object model, so establishing which module you are in comes first rather than after something behaves oddly.

Knowing what to install is the easy half. Knowing which one to open when somebody asks a question is what saves the first hour of a case.

Per IR0.4 the four domains are reached through different surfaces, and the same split applies to the tooling.

Four questions cover most of what an investigation asks in its first hours, and each one has an obvious home once you know the map.

The identity question has two answers because that work genuinely splits: the portal is faster for reading a handful of sign-ins with their risk and policy evaluation attached, and Graph is the only sensible route for anything at volume.

Reading the table as a routing decision rather than a feature list is the useful habit. The question arrives first, and the tool follows from which domain it belongs to.

That pairing is the one to internalize first, because per IR0.4 the unified audit log reaches all four evidence domains and is therefore where a question goes when you do not yet know which domain it belongs to.

The audit log is reachable two ways and the difference matters. The Purview portal search is convenient and limited; the PowerShell cmdlet supports finer filtering and bulk work, and per module one both carry result ceilings that are easy to hit without noticing.

Message trace and mailbox audit are the two people confuse. A mailbox's configuration and the tenant's record of what happened to that mailbox are different questions with different sources, and asking the first when you meant the second returns a confident answer about the present when you wanted one about last month.

The KQL entry is the one that depends on your environment. Defender's advanced hunting is available wherever Defender is, and Sentinel only holds what somebody exported into it, which per IR0.4 is rarely everything.

That is the reason this course teaches the shell rather than the portal for anything at volume. A portal search is the right tool for a single question and the wrong one for an investigation that needs a complete set.

Beyond Microsoft's own modules there is a small ecosystem built specifically for this work.

Several open-source tools exist specifically for Microsoft 365 incident response, and they are worth knowing about with a caveat attached.

Neither is required for this course and both are worth knowing about, because you will meet them in other people's runbooks and in most published M365 investigation guidance.

They exist for a reason worth understanding. The standard collection at the start of an M365 case is the same handful of queries every time, and automating it is an obvious win when a case is moving quickly.

Hawk is a PowerShell module built for M365 investigations, which automates the collection most cases begin with: sign-in activity, mailbox rules, forwarding configuration and administrative changes, gathered per user or per tenant.

It runs a standard set against a user or a tenant and produces a collection, which is a reasonable first move on a case that has just arrived and which you should then read rather than summarize.

The Microsoft Extractor Suite is a broader collection aimed at pulling the relevant log sets out of a tenant for offline analysis, which is the shape of work per module one that the export decision otherwise makes difficult.

Neither replaces knowing the sources, and both are worth having installed before an incident rather than discovered during one.

Both are actively maintained community projects rather than vendor products, which is worth knowing for two reasons: they move faster than Microsoft's own tooling, and they carry no support commitment if something breaks mid-incident.

The caveat is not about quality. Both are good tools, and the risk is that a tool which collects for you is also a tool which decides for you what to collect.

Verify what a tool collected rather than trusting the summary. A collection script that silently skipped a source because of a permission problem produces a report that looks complete, and per module one an empty result and an unreachable source are indistinguishable in the output.

That failure mode is the argument for reading a collection tool's output rather than its report. A summary that says forty-one rules were collected is a claim about what the tool retrieved, not about what exists.

That is the same reasoning behind per IR0.4 teaching the evidence map rather than a console: the sources outlive the interfaces, and a responder who knows the source can adapt to whatever is in front of them.

This course teaches the underlying sources rather than a tool, deliberately. Tools change, and a responder who knows what MailItemsAccessed records can use any tool that collects it or none.

Community tooling earns its place by being faster at the things you already understand, and it is worth being clear that this is the order rather than a preference. Per IR4.3 a wrapper that returns a clean table is excellent when you can say what the underlying operation was and dangerous when you cannot, because its gaps look identical to absences in the tenant.

One more division to settle before the practice card, because getting it wrong wastes time in both directions.

It is tempting to treat the graphical interfaces as the beginner route and the shell as the real one, and that is not the division.

Both surfaces are primary for different things, and the choice is about the task rather than about experience.

Several things are portal-first. Defender's incident view assembles alerts across products into one object, Purview's audit retention configuration is a portal task, and the Entra sign-in blade presents risk and Conditional Access evaluation more legibly than the raw record does.

Retention configuration is the other one worth noting, because it is a portal task that changes what future investigations can reach, which makes it the highest-consequence setting in this course that has no shell equivalent most people use.

The Defender incident view is the clearest example. It assembles alerts from several products into one object with a shared timeline, and that assembly is work the platform has already done for you, which no shell query reproduces.

Several things are shell-only or shell-mostly. Bulk audit collection, mailbox configuration at scale, and anything you intend to repeat or hand to somebody else belong in a script.

The working practice is to use the portal to understand a case and the shell to work it. A portal gives you the shape quickly; a shell gives you a result you can reproduce, and per IR1.9 reproducibility is what makes a finding defensible.

A shell result is also the one you can attach to a finding. Per IR1.9 a conclusion somebody else can reproduce is worth more than the same conclusion reached by clicking, and reproducibility is largely a property of how the query was run.

Know where both are before an incident. Per module one the account that opens them matters as much as the tool, and a portal you have never opened is not a fallback.

Everything above assumes somewhere to run it. That is a decision worth making before module one rather than during it.

Per IR0.2 read-only work belongs against production and anything that changes state belongs in a lab. Building that lab is its own subject and this course has a module for it.

Five pages cover it, and they are written as a build rather than as a description.

Nothing in the first three teaching modules needs a lab, and the practice cards mark themselves read-only where they are, so this is a decision you can defer without falling behind.

The module is deliberate about cost, which is the question that stops most people. A lab tenant is not free and the material says what it runs to, so the decision is made with a figure rather than a guess.

The third item is the one that makes a lab worth building. Reading about a device code authentication is different from generating one and then finding it in your own logs, and that exercise is what converts recognition into something you can do under pressure.

The fifth item is the one worth reading even if you never build a lab. A lab reproduces the tenant and not the organization, so it can teach you to run a query under pressure and cannot teach you what happens when Phil per IR0.3 objects to the containment step.

Go to that module when you want a lab rather than now. Nothing in the first three teaching modules requires one, and the practice cards say per card whether they are read-only.

A lab is worth having for one specific reason rather than for completeness. Per IR2.8 the gap between knowing a command and having run it is where the time goes during an incident, and the only way to close it is to have connected, authenticated and had something come back before anybody needed it to.

The last thing to do before the teaching modules begin is to prove that any of this works.

Installation is not the same as working, and the difference surfaces at the worst moment.

Three checks, in an order that isolates the failure rather than just reporting one.

It is a short exercise and it is the one that would have prevented the scenario at the top of this section, which is why it closes the orientation rather than appearing somewhere later.

The three checks look almost identical and they fail for different reasons. An import failure is a missing module, a connection failure is authentication, and an empty result from a working connection is nearly always permissions.

Import-Module Microsoft.Graph.Authentication   # fails: module missing
Connect-MgGraph -Scopes "AuditLog.Read.All"    # fails: authentication
Get-MgAuditLogSignIn -Top 1                    # returns nothing: permissions

Connect-ExchangeOnline
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

Do it from the on-call account rather than yours. Per module one a check run from a privileged account establishes that the privileged account works, which was never the question.

Do the verification once now and again whenever the rota changes, because per module one the permission is a property of the account rather than of the organization.

That is the whole of the toolkit section. Two modules to install, one to know well, a portal habit, and a verification that takes a single session and prevents the scenario at the top of this page.

Per IR1.10 that last clause is the whole exercise. The account matters more than the tool.

The card below is the last thing to do before module one, and the fourth step is the one most likely to produce a finding.

That completes the orientation. The first teaching module establishes what your tenant can and cannot answer, which is the position everything else in this course is built on.