For years, we’ve been hearing how the Graph API is the de facto “control surface” of Microsoft 365 and should be used for all integrations/automations and apps. Yet, years down this journey, the real story still shows fragmented coverage across even the basic workloads (*cough* Exchange Online *cough*). On the Purview front, the situation is somewhat better with at least eDiscovery operations covered by the Graph API. But overall, lots to be desired.
Which brings us to MC1238428, informing us that in month’s time (23 March 2026), Microsoft plans to officially split the UI and PowerShell-based experiences when it comes to eDiscovery cases. Here’s the full text of the message center post:
In other words, starting 23 March 2026, any eDiscovery search or eDiscovery case created or modified via the existing set of PowerShell cmdlets will NOT be visible in the Purview portal. Any admin/operator accessing the Purview UI will not even be aware of the existence of such cases, which is more than just a visibility issue, as eDiscovery holds can also affect the lifecycle of user account. Which is the reason for today’s public service announcement.
As customary, the message center post is a bit light on details and does not clearly answer which UI bits will be affected, so I would suggest taking the cautious approach and assuming “all of them”. It also does not tell us whether synchronization will continue working in the other direction, i.e. whether changes made to cases/searches visible in the UI will still be reflected in the output of the existing PowerShell cmdlets. Same goes for changes made via the Graph API.
The message center post also has a vague mention of PowerShell audit logs, which I suppose we should read as the “Unified audit log”. Hopefully my assumption here is correct and audit records related to eDiscovery cases and searches will continue to be gathered as part of the Unified audit log, regardless of which method was used to perform the operations. We shall see.
Now, why I do appreciate Microsoft moving to the direction of Graph API based experience (albeit at a snail’s pace), I’m a bit puzzled by the approach taken in this case. Surely the PowerShell cmdlets can be updated to proxy the exact same operations the UI leverages, thus eliminating such disjointed experiences? Not to mention that even today, we still have to leverage the -CaseType parameter for the Get-ComplianceCase cmdlet, if we want to enumerate all cases. Putting some engineering effort into the “modernization” of the PowerShell cmdlets would certainly be appreciated, but I suppose Microsoft doesn’t consider the admin experience as a worthwhile investment for all those hard-earned $$$.
In fact, while I’m in a bitching mood, let’s also talk about some other recent examples on the Purview front. The new Unified audit log query endpoints on the Graph API follow the same model, more or less. As we discussed in our initial overview, any queries performed via application permissions do not show when using the GET/LIST methods via delegate permissions and vice versa. Considering how sensitive the data exposed via UAL queries can be, this is again more than just a simple visibility issue.
On a slightly tangent note, we still do not have support for working with all Purview-related cmdlets in the context of an app (service principal). What’s even worse, the documentation remains incomplete, and even misleading, with some of the listed cmdlets actually working with CBA sessions, whereas other affected cmdlets are yet to be added to the article. Instead, we’re forced to keep track of “announcements” published as part of message center posts (i.e. MC1131771 and MC1213770), as part of which we learn about upcoming changes to the supported connectivity methods and cmdlets.
Obviously, customers can understand the need to modernize parts of the service, even in scenarios where the changes result in creating additional overhead on “our” side. Then again, rushing changes just to meet some internal deadlines and without taking the customer experience into consideration, or even bothering to publish proper documentation, is a no go. Microsoft, surely you can do better?