I have Internal Server Error 500 when Trying to Purge Emails with eDiscovery Purge.

Hi @Manoj S ,

You and the others in this thread aren't doing anything wrong this is a live service-side issue on the Microsoft Graph eDiscovery (classic) API, not a tenant, permission, or PowerShell module problem. Multiple tenants are hitting the same 500 InternalServerError on security/cases/ediscoveryCases (GET list, GET by case ID, POST new case) starting July 6–7, and Rafael's observation lines up with that child collections like custodians still respond, but the case list/read/create path is broken. That points squarely at the Graph eDiscovery (classic) backend, not at your call.

A couple of important things to know before you spend more time debugging:

1. Get-MgSecurityCaseEdiscoveryCase and /security/cases/ediscoveryCases target eDiscovery (classic), which is being retired. Microsoft has publicly announced classic eDiscovery retirement, with the API/UX moving to the new eDiscovery experience under /security/cases/ediscoverycases (new schema) and the Purview portal. Intermittent 500s on the classic surface are increasingly common as the backend is drained.
2. Because of that, don't rebuild anything on top of the classic endpoint. Any fix on classic is temporary.

What to do right now (in this order):

• Retry with a small delay. Transient 500s from x-ms-ags-diagnostic East US 2 / Ring 5 in this window are being seen tenant-wide. Keep the request-id and client-request-id values from your failed calls those are what Support needs.
• Confirm it isn't your client: run the exact same call from Graph Explorer signed in as a Global Admin / eDiscovery Manager. If Graph Explorer also returns 500, it's confirmed service-side (which is what Rafael already saw).
• Do the eDiscovery work you need to unblock users via the Purview portal → eDiscovery UI in the meantime. The UI uses a different internal path and is generally still functional even when the Graph classic endpoint is 500'ing.
• If it's business-critical, open a Microsoft 365 admin center service request under Microsoft Purview → eDiscovery → Graph API returning 500 on security/cases/ediscoveryCases, and attach the request-id + client-request-id + timestamp (UTC) of a failed call. That's the fastest way to get it linked to the active incident on the backend.
• Watch the Service Health Dashboard in the M365 admin center under Microsoft Purview / eDiscovery if this is a broad incident (it looks like one), an advisory usually shows up there.

Going forward, plan to move off the classic endpoint. For new automation, use the new eDiscovery Graph APIs (the ones under the updated /security/cases/ediscoverycases schema tied to the new eDiscovery experience) rather than the classic cmdlets/endpoints. The purge action itself is still driven from an eDiscovery case + search, but on the new experience it's exposed via the updated microsoft.graph.security.ediscoverySearch: purgeData action. Rebuilding on that path avoids getting stuck again when classic is fully retired.

TL;DR: it's not you Graph eDiscovery (classic) is 500'ing service-side since July 6–7, use the Purview portal to unblock, log a ticket with the request-ids to get attached to the incident, and plan the migration to the new eDiscovery Graph API since classic is on its way out anyway.

If you share your tenant region and one failed request-id + timestamp, I can help you correlate it to the incident when Support picks it up.

We started seeing a similar issue as of Friday, September 4th. Getting a 500 error when trying to add a user source to a Hold. Not sure if anyone is seeing the same.