With the move to “unified” compliance features across the Office 365 suite, we have gained a lot of utility, while on the other hand some useful functionalities are no longer available. A common example is the simplicity of the Search-Mailbox cmdlet, which among other things allows us to quickly delete spam/phish/malware messages. The suggested replacement sadly only works for up to 10 messages, making our job harder. For a more detailed comparison you can check this article by Tony.
Recently, I was made aware of another example of such loss of functionality. Namely, the eDiscovery/Content search functionality in the SCC doesn’t seem to accept Exchange-specific identifiers. Let’s give a more specific example. Say I want to check for the presence of a given email in my mailbox. In the Exchange world, I can do this in several ways, including the aforementioned Search-Mailbox cmdlet, the In-Place eDiscovery search functionality or its PowerShell counterpart, New-MailboxSearch. While the UI limits you in terms of which identifier you can provide to designate the objects to search, using any of the PowerShell cmdlets allows you to specify a plethora of identifiers, including: Guid, ExchangeGuid, ArchiveGuid, ExternalDirectoryObjectId. In other words, I can do something like this:
The example above illustrates the use of GUID and the ArchiveGUID parameters for the purposes of Content search. Both attributes are successfully resolved to my own mailbox, regardless of the cmdlet used. The UI on the other hands doesn’t accept such identifiers.
Now, let’s see what happens if we try the same approach with the Content search/eDiscovery functionality in the SCC. Using the Guid/ExchangeGuid/ArchiveGuid value results in “No user, group, or team found” message, so it’s on par with the EAC UI.
However, the same behavior is observed when using the PowerShell approach as well, which is the bad news. As illustrated below, trying to add an Exchange-specific location to the content search fails with an “The compliance search contains the following invalid location(s)” message. Interestingly, the service also issues a complaint about the location being ambiguous:
In effect, it seems that the SCC cmdlets do not accept values such as the mailbox GUID, unlike the corresponding Exchange Online cmdlets. What they do accept is the ExternalDirectoryObjectId value (helpful tip courtesy of Tony Redmond), and indeed if one provides the value of this attribute either in PowerShell or the SCC UI, the corresponding object is found and the search can be executed:
So why am I bothering you with all this, when it’s much easier to just provide the email address or name of the user? Well in some occasions you might have duplicate values for such attributes, for example when you are trying to search against Inactive mailboxes. Not to mention the stupidity of modern groups and guest users ignoring the SMTP address uniqueness constraints. GUID values on the other hand are hardly ever duplicate, so they are the usual choice in such scenarios.
The good news is that for most cases, using the ExternalDirectoryObjectId attribute should solve the issue. However, while Microsoft has been steadily increasing the number of objects across the service that have said attribute populated, there are still a handful of Exchange objects that have it blank. Inactive mailboxes are probably the prime example here, but also objects such as Discovery mailboxes or Public folders. In all fairness, Search-Mailbox doesn’t cover inactive mailboxes or Public folders anyway, so using GUIDs and the “old” cmdlets wont help you there.
So there you have it, another small but potentially impactful loss of functionality in the transition from workload-specific compliance tools to the “unified” feature set exposed in the SCC. While you can work around this limitation via a workload- or service-wide search, you will then have to filter out all the unnecessary data, which can be a problem in large tenants. Microsoft has remained silent with respect to all the other missing features as well, but one can only hope they address all of them before pulling the plug of good old Search-Mailbox and related cmdlets.