search and purge job failed halfway and copies of the phish remained in archive mailboxes

TL;DR

Purge what the first job never searched: build the search to explicitly include archive mailboxes, shared and delegated mailboxes, and recoverable items where policy allows, run it in batches with per batch verification, and then prove removal with a fresh search that must return zero outside known hold locations. Search and purge defaults were written for primary mailboxes, and a job that reports success on the mailboxes it searched says nothing about the archive copies it never looked at.

search and purge job failed halfway and copies of the phish remained in archive mailboxes

Use this when

• After a reported successful purge, users or auditors find the same phish in archive mailboxes.
• The original search used default content locations or primary mailboxes only.
• The campaign is confirmed malicious and approved for removal.

Not for this skill when

• Copies remain in a mailbox under legal hold. That retention is intentional; document it rather than fighting the hold.
• The remaining copy is in a personal PST export outside the tenant. That is outside purge reach and needs a device process.

Steps

1. Recreate the original search and list exactly which locations it covered, by mailbox type. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the coverage of the first purge is documented, including the archive gap
2. Build a new search with explicit location selection covering primary, archive, shared, and delegated mailboxes for the affected users, using the campaign hard identifiers. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the new search location list shows all intended types included
3. Run the purge in batches by location type and record the item count removed per batch. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: each batch reports its removed count and completes without error
4. Run a verification search with the same identifiers that must return zero, excluding only documented hold locations. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the verification returns zero outside the documented exceptions
5. Record the full location coverage and the verification result in the campaign file for audit. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the campaign file shows the coverage list and the zero result

Why it happens

Modern mailboxes are several stores wearing one name: the primary mailbox, the in place archive, shared and delegated stores the user touches daily, and recoverable items underneath. Search tooling defaults and licensing have historically centred the primary store, so a purge can be entirely successful and entirely incomplete at the same time. Verification has to search the same full scope independently, or the organisation learns about the leftover copies from the next user who opens their archive.

Variants and edge cases

search and purge failed halfway copies phish remained archive mailboxes

The exact leftover location wording.

purge phishing from archive mailbox compliance search locations incomplete

The location scoping variant.

phish still found after purge shared archive mailbox verify removal

The verification variant users report after reopening mail.

Compatibility: Microsoft Purview eDiscovery and search and purge, Exchange archive and shared mailbox architecture.

Edge cases to check:

• Licensing can silently exclude archive locations for some accounts; a location count check before the purge catches that.
• Coordinate with legal before purging anything that might sit under a preservation duty, even inside a phishing response.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstNWAnhK00aSsNQbCJgZh-A

Resolved from the public thread: https://vectle.com/posts/pstNWAnhK00aSsNQbCJgZh-A

Thread query: search and purge job failed halfway and copies of the phish remained in archive mailboxes

TL;DR: Purge what the first job never searched: build the search to explicitly include archive mailboxes, shared and delegated mailboxes, and recoverable items where policy allows, run it in batches with per batch verification, and then prove removal with a fresh search that must return zero outside known hold locations. Search and purge defaults were written for primary mailboxes, and a job that reports success on the mailboxes it searched says nothing about the archive copies it never looked at.