共用方式為

Migrating from Exchange Online eDiscovery and In-Place Hold to the Security & Compliance Center

  • 發行項

One of the issues that some of my larger customers have been dealing with is the lack of tooling and planning around moving legacy Exchange Online In-Place eDiscovery & Holds to the new(ish) Security & Compliance Center.  Our direction has been to either let them age out or manually recreate them the Security & Compliance Center.

Some of my customers have pointed to the fact that we put a notice in the Exchange Online Admin Center saying the functionality will be gone, but have revised it from a hard date to a “we’re working on it” type of notification, which has instilled somewhat of a sense of anxiety in some of them for what to do with their existing searches and not knowing when for sure we'll turn it off.

Here's the banner currently displayed in the Exchange Online Admin Center:

To help my customers make the transition from their legacy mailbox searches and to help their adoption of the SCC, I’ve written a tool to try to help alleviate some of the difficulty in recreating them.

If you're not entirely familiar with how the Exchange Online in-place eDiscovery and holds work, it's what we use to describe a Mailbox Search (search) or a Mailbox Search with InPlaceHoldEnabled set to $true.  When you configure an in-place hold, a unique hold gets created and applied to the user mailbox, as seen in the InPlaceHolds property:

Shameless plug: If you want a view of all the holds applied to your mailboxes across your organization, be sure to check out my Get-UserHoldPolicies script or my User Hold Policies blog post.

With a mailbox search, by default, anyone who has been granted the Discovery Management role can create and see all of the searches and holds in an organization, as well as their properties.

From PowerShell, logged in as my default global admin account, running Get-MailboxSearch produces the following result:

And logged into the portal as Adele, I see the same results:

When we dive into the Security & Compliance Center, there is a corollary "Content Search" function, but I try to guide my customers towards creating actual eDiscovery cases.  An eDiscovery case is really a container object that can hold multiple searches and holds across all of a tenant's Office 365 assets. One of the advantages of the Security & Compliance Center view is that even the view of the case list is security-trimmed, meaning that only the eDiscovery case creator or someone who has been explicitly added to the case as a member will even know that it exists (with the exception of designated eDiscovery Admins, who can see all cases).  From a separation of duties perspective, it can be pretty important for some organizations to limit the visibility of open cases, particularly if someone who has access to the console is under some sort of search, investigation, or hold (unbeknownst to them).

When we shift towards creating eDiscovery cases from Mailbox Searches, there are a number of properties and attributes that need to be combined to create the corresponding search in the Security & Compliance Center. From the mailbox search, this means the following properties:

  • CreatedBy
  • SourceMailboxes
  • Sources
  • AllSourceMailboxes
  • PublicFolderSources
  • AllPublicFolderSources
  • SearchQuery
  • Senders
  • Recipients
  • StartDate
  • EndDate
  • MessageTypes

The first property, CreatedBy, we'll use to map to who will own the new eDiscovery case.  This means we would want them to be a case member.  From the Security & Compliance Center side, everything that has Source in the property name from the Mailbox Search maps to the eDiscovery case (ComplianceSearch or CaseHoldPolicy) Locations. The rest of the Mailbox Search properties (Search Query, Senders, Recipients, StartDate, EndDate, and MessageTypes) map to the ContentMatchQuery parameter in either New-ComplianceSearch or New-CaseHoldRule.

The content match queries need to be grouped together and ANDed (from the boolean perspective) in the KQL syntax formatting.  To get an idea of what that might look like, you can go look at the reference.

For the sample mailbox search, you can see how I assemble the value that will be passed to the ContentMatchQuery parameter of the case hold rule:

(california AND case) AND (kind:email OR kind:meetings OR kind:tasks OR kind:notes OR kind:docs OR kind:journals OR kind:contacts OR kind:im) AND ( between:01/07/1990 05:00:00..01/08/2019 05:00:59) AND (from:AlexW@undocumentedfeatures.OnMicrosoft.com OR from:ChristieC@undocumentedfeatures.OnMicrosoft.com) AND (to:EnricoC@undocumentedfeatures.OnMicrosoft.com OR to:GradyA@undocumentedfeatures.OnMicrosoft.com)

To break it down:

(SearchQuery) AND ([MessageTypes] OR'd together) AND (StartDate/EndDate rules) AND ([Senders] OR'd together) AND ([Recipients] OR'd together)

When you run the tool, you’ll have options to:

  • Add the CreatedBy user from the original mailbox search to the eDiscovery manager role (which will allow the users access to their own cases in SCC). If a user is not a member of a case and not a member of any role that has eDiscovery permissions, they will not be able to open cases in the Security & Compliance Center.
  • Create a new case for each mailbox search
    • Mailbox searches with holds will create a hold and corresponding case hold rule in the case
    • Mailbox searches with search only will create a content search in the case

During the case creation, I perform duplicate checking for eDiscovery case names—one of the limitations is that you can’t have more than one case with the same name (even though they have their own Guids).

The available parameters:

 .PARAMETER AddCreatedByToEDiscoveryManagers
Add the user listed in the CreatedBy parameter of the original mailbox search
to the eDiscoveryManager role group.

.PARAMETER Credential
A credential object. If not present, you will be promtped.

.PARAMETER Debug
Enable debug logging.

.PARAMETER Identity
Specify an individual mailbox search to run against.

.PARAMETER Logfile
Does just what you think it does.

When running with the -AddCreatedByToEDiscoveryManagers parameter, you'll see this output:

As a technical note, the native Security & Compliance Center cmdlets have the SupportsShouldProcess binding, but they don't actually support the -WhatIf parameter (the commands proceed as normal).  As such, I've written a simple IF clause wrapper around every command executed and report back the status to console.

To go get the tool, head to the TechNet Gallery: https://gallery.technet.microsoft.com/Migrate-Exchange-Online-In-e4946d66