While these reports contain all the data you need, they aren't exactly "human-readable." Trying to find out why 5% of your items failed or which custodian is driving the most volume involves a lot of Excel filtering, pivot tables, and wasted time.

That’s why I built the Purview eDiscovery Items Report Aggregator.

The Problem: The "CSV Headache"

The standard Purview Items report is a goldmine of metadata, but it’s hard to digest quickly. When a legal team asks for a status update, they want to know:

• What percentage of the collection was successful?

• What are the specific reasons for the failures (exceptions)?

• What is the total data volume and which file types are the biggest?

• Is there searchable text for most of the items?

Answering these questions manually takes time you don't have.

The Solution: A Privacy-First, Local Summary Tool

I created a lightweight, offline-friendly web app that processes these CSVs entirely in your browser.

🚀 Try the Purview eDiscovery Items Report Aggregator here!

Why this tool is different:

1. Zero Data Uploads (Privacy First): In the legal world, data privacy is non-negotiable. This tool uses a Content Security Policy (CSP) to block all network requests. Your CSV never leaves your computer; it is processed locally in your browser's memory.

2. Instant Summarization: Drop your Items_...csv file in, and within seconds, you get a beautiful dashboard of your data.

3. Exception Deep-Dives: It automatically groups errors—like "Operation timed out" or "Access denied"—so you can troubleshoot your collection immediately.

4. Offline Capability: You can download the tool as a single HTML file and run it locally too!

What Insights Can You Get?

Based on a typical report, here is the kind of data the tool extracts for you:

1. High-Level Success Metrics

See your "Success vs. Non-Success" ratio instantly. If you have a 9.17% failure rate (as seen in our demo data), you can immediately identify if that’s a "Retrieval Error" or a "Throttling" issue.

2. Workload & Scope Breakdown

The tool categorizes data by Effective Workload. Even if the CSV labels everything as "Exchange," the tool identifies Teams-specific rows, SharePoint sites, and OneDrive accounts so you know exactly where your data is coming from.

3. Volume Drivers

Ever wondered what's eating up your storage? The tool breaks down:

• Size Bands: How many files are over 100MB?

• Extensions: Are .msg files or .zip files driving your volume?

• Text Readiness: What percentage of your items actually have searchable text?

4. Errors, Failures & Processing Readiness

Quickly sanity check the export, the tool gives guidance on:

• Errors: Failures/Errors & How to Resolve!

• Readiness: What % Are Text Searchable?

• Defensibility: Are There Parent Items Missing From Child?

5. Shareable HTML Reports

Once the analysis is done, you can download a one-page HTML report. This is a standalone snapshot you can email to stakeholders or save as part of your case documentation.

How to use it

1. Export from Purview: In your eDiscovery case, go to Process manager, select your process, and click Download report.

2. Download Tool Locally: Simply download the HTML file and open in the browser OR

3. Process In Browser: Open the aggregator tool and it processes locally in your browser (NO UPLOAD).

4. Analyse & Save: Review the dashboard and download your summary report.

Open Source & Transparent

As an eDiscovery professional, I value transparency. The SHA-256 fingerprint is provided for every version, and the tool is designed to be as "no-footprint" as possible.

Check it out, and let me know how it changes your workflow!

If you rely on a single SMTP address, you will miss data. If you use the DisplayName, you let the Microsoft 365 Substrate do the heavy lifting for you.

How it Works: The "Stamping" of Identity

The effectiveness of this search relies on how the Microsoft 365 Substrate (the data layer for Purview) indexes mail.

When an email is sent, it passes through the Exchange Transport pipeline. During this "ingestion" phase, the system performs Metadata Enrichment. It doesn't just look at the email address; it resolves the sender against the Global Address List (GAL).

Even if a user sends an email using a secondary alias (e.g., marketing@company.com) or a legacy X500 address, the Substrate "stamps" the user's official DisplayName (e.g., "Joe Blogs") onto the item in the index. This creates a permanent, searchable "human-readable" tag that is baked into the item's metadata at the moment of creation.

Bypassing the "Alias Trap"

In Microsoft Purview, "Recipient Expansion" is the feature meant to find a user's aliases. However, it has a significant limitation: it often fails to expand secondary proxy addresses.

If you search for sender:joe.blogs@company.com, the system may not automatically look for mail sent from j.blogs@company.com. But because the Substrate stamped "Joe Blogs" on both emails when they were sent, a search for sender:"Joe Blogs" will catch both. For a regulatory production where "missing data" is a compliance risk, this name-based approach ensures you capture the user's entire output across all their technical identities.

Important: Targeted Searches Only

It is critical to understand that this is a targeted mailbox strategy, not a tenant-wide strategy.

• Why it works in a targeted search: If you have already narrowed your "Data Sources" to Joe Blogs's mailbox, searching for sender:"Joe Blogs" is incredibly accurate. You’ve already defined the "Where" (the specific mailbox); the name search simply ensures the "What" is comprehensive.

• Why it fails tenant-wide: If you search your entire organization for sender:"Joe Blogs", you will return every "Joe Blogs" in the directory and potentially unrelated external hits. This strategy is for capturing the full history of a specific custodian.

Sender vs. Participants: Which is better?

When you are looking for what a custodian sent from their own mailbox, you should use the sender property rather than participants.

• Sender="Joe Blogs": This is a precision tool. It targets only the items where the custodian is the author. This is the superior property for producing a user's "sent history."

• Participants="Joe Blogs": This is a "wide net" tool that searches the Sender, To, Cc, and Bcc fields simultaneously. Using this within a custodian's mailbox would clutter your results with every email they received, making it difficult to isolate their outbound correspondence.

The "Name Change" Caveat

Because the display name is "stamped" on the item at the moment it is sent, it represents the user's identity at that point in time.

If a custodian has had a name change (for example, due to marriage or a preference change from "Joseph" to "Joe"), searching for their current name will not return items sent under their previous name. To ensure a truly defensible and comprehensive production, you must include any previous display names as "OR" terms in your query.

(For Purview prerequisites on tracking and identifying these historical name changes, please refer to this article)

Summary for eDiscovery Managers

1. Scope the search: Target the specific custodian mailbox as the data source.

2. Use the Name: Use sender:"Display Name" to bypass the "Proxy Address" gap and catch all aliases.

3. Include History: Add previous display names to the query to ensure you catch items sent before a name change.

4. Avoid SMTP-only: Don't rely on a single SMTP address, as Purview’s expansion may miss departmental or legacy aliases.

By leveraging the way the Substrate "stamps" names at the point of ingestion, you can produce a more accurate and defensible set of sent items with significantly less manual configuration.

The problem is simple: Purview is heavily reliant on what is currently present in Microsoft Entra ID (formerly Azure AD). While this works fine for active employees who have never changed roles or names, it creates a significant risk of under-collection for everyone else.

1. The "Ghost" Custodian: Employees Who Have Left

When an investigator needs to search the mailbox of someone who left the organisation two years ago, they hit an immediate roadblock. KQL searches require exact matches for identifiers like SMTP addresses or UPNs to pull data accurately from the index.

However, once an employee leaves, their Entra ID record is often stripped back or deleted entirely. Finding a comprehensive list of every SMTP address that person ever used during their tenure becomes a manual, often impossible, task. If you don't have those historical identifiers to include in your sender: or recipient: KQL queries, those emails will stay hidden in the index.

2. The Name Change Trap

This issue isn't limited to leavers. We see it constantly with active employees who have changed their names—due to marriage, for example. When a name change occurs, the UPN, primary email address, and display name are typically updated.

Microsoft Purview has a "Recipient Expansion" feature designed to help, but it is notoriously focused on the "here and now." It often only returns the current identifiers. If you search using the current identity, the index may not map that back to items stamped with the previous identity from three years ago. The result? You only collect half the story, and often, you won't even realise the earlier data is missing until the case is well underway.

The Risk: Defensibility and Under-Collection

In a legal context, this is a major red flag. If you are relying on KQL to be inclusive, but your query only looks for the custodian’s current "identity," you are effectively self-selecting a subset of the data. This isn't just a technical glitch; it’s a defensibility risk.

The Solutions: How to Solve the Identity Crisis

So, how do we fix this? There are two main paths, depending on your setup and your budget.

Solution A: Build a Bespoke Identity Tool
If KQL is your preferred method of searching, you need to be better informed before you even open Purview. The most effective way to do this is to build a custom tool or dashboard that pulls historical identity information from your HR systems or take a feed from Active Directory to gather identifiers as they change over time.

This tool should provide investigators with a "Full Identity Map" for any custodian, including:

• Every SMTP address ever assigned to them.

• Previous UPNs and Display Names.

• Tenure dates.

By surfacing this information up front, investigators can build KQL queries that include every identifier the custodian has ever used, ensuring the index returns a complete set of results.

Solution B: The "Premium" Approach (E5/Review Sets)
If you have eDiscovery Premium (E5), there is a much more robust way to handle this: Stop using inclusive KQL at the search stage.

Instead of trying to match specific identifiers up front, you should target the custodian’s mailbox directly as a data source. Run a broad search—using only date ranges or specific keywords—and move those results directly into a Review Set.

By targeting the mailbox (the container) rather than trying to match the person (the identity) via KQL, you bypass the identity crisis entirely. The Review Set will pull in all data that matches your keywords or dates, regardless of which version of the custodian's name or email address was stamped on the metadata at the time the email was sent.

Summary

We have to accept that Microsoft Purview isn’t a time machine; it’s a reflection of your current Entra ID state. To avoid the trap of under-collection, you either need to arm your investigators with a complete historical map of custodian identities or shift your workflow toward targeted mailbox collections in eDiscovery Premium.

In eDiscovery, what you don't know can hurt you—and usually, it's the identifiers you didn't know existed that cause the most trouble.

Unfortunately, because of how Microsoft 365 is built, you are almost certainly missing data.

The Problem with Modern Indexing

For those who have spent years working with legacy on-premises eDiscovery solutions—like Enterprise Vault or Relativity—this wasn’t an issue. Those systems typically used "Envelope Journaling." When an email was sent, it was wrapped in a P1 envelope that contained every single recipient's details. Even if a user was hidden in the BCC field or was just one name in a 500-person Distribution List, the index saw them because the envelope expanded that data.

Microsoft Purview works differently. It searches "in-situ" within the Substrate (the underlying data layer for M365). When an email lands in a recipient's mailbox, Purview indexes the actual headers of that item.

The issue is that:

1. BCC details are stripped from the recipient’s copy of the email for privacy.

2. Distribution Lists aren’t expanded in the header; the "To" field simply shows the group address, not the individuals within it.

Because the custodian’s individual email address isn't physically in the header of the item in their mailbox, a KQL search for their name or email address will simply fail to find a match.

Sender vs. Recipient Context

It’s worth noting that if you happen to be searching the sender’s mailbox, you’ll see those BCC and DL details perfectly fine in their "Sent Items." But in eDiscovery, we are often working in a recipient context. If the sender is an external party, or if you only have access to the recipient's mailbox, that metadata simply doesn’t exist in a searchable format within those headers.

Because this is a fundamental part of the Exchange Online architecture, it’s unlikely that Microsoft will be able to "fix" this. The data items in the Substrate simply don't contain the recipient expansion required for a traditional header match.

A More Reliable Solution

Rather than trying to force an "Include" query that relies on missing header information, I’ve found that we need to change our approach. We need to stop searching for who the email was sent to and instead focus on the container (the mailbox) and the received context.

The strategy is simple:

1. Target the specific user's mailbox.

2. Query for everything in that mailbox.

3. Filter for email items only.

4. Filter out the items the user sent to others (to remove the noise of their Sent Items).

5. Keep items the user sent to themselves (self-notes/reminders).

kind:email AND (NOT from:user@contoso.com OR recipients:user@contoso.com)

Why this works

• Captures BCC/DL Traffic: By ignoring the recipient headers and focusing on the fact that the item was delivered to the mailbox(es), you catch everything.

• Filters Out the "Noise": Using kind:email ensures you aren’t bloating your data set with calendar invites, tasks, or system notifications.

• Isolates Incoming Mail: We filter out anything sent by the mailbox owner unless they sent to themselves (we want to capture that)

One Vital Pro-Tip

A word of caution: You must target specific custodian mailboxes for this to work.

Do not try to run this as a tenant-wide search. Because this query doesn't specify a person's name, running a search across your entire organisation would return every single email received by every single employee during that timeframe.

By targeting the specific mailboxes and using this method, you bypass the architectural limitations of Purview and ensure your collection is both thorough and defensible. It’s a much safer way to ensure those "invisible" BCC and DL emails don't slip through the cracks.