Most SharePoint environments that have run without governance review for three or more years share a predictable profile: external access that outlasted the projects it was granted for, version history sitting at the platform default of 500 copies per file, and a storage utilisation figure nobody on the admin team can fully explain. Add a pending compliance rollout to that picture and the cleanup work becomes urgent.
The scenario: Marcus Tran is IT Manager at a regional hospital group operating across three facilities with around 800 staff. His organisation is eight weeks from a planned Microsoft Purview Records Management go-live. The records team has mapped document categories, defined retention periods, and signed off the policy taxonomy. Marcus's job is to get SharePoint into a state where those policies can actually be applied. Seven years of unaudited document libraries are waiting for him.
The Problem: A Purview Rollout with No SharePoint Baseline
The hospital group migrated to Microsoft 365 in 2019. Since then, SharePoint had grown organically: site collections created per department, libraries set up by team leads, external consultants granted access for specific projects and rarely removed. The Microsoft 365 admin centre showed storage consumption at 78 per cent of the tenant's allocated quota, but nobody could explain where most of that quota was going.
Applying Purview retention policies to a SharePoint environment in this state carried real risk. Retention policies need to land on the right libraries, attached to the right content types. If the estate has libraries being used informally, or access that no longer reflects actual employment relationships, you end up preserving the wrong content and potentially maintaining data accessible to people who left the organisation years ago.
Marcus identified three priorities before go-live: understand what was stored and where, identify and remove stale external access, and reduce version history overhead before retention policies locked that content in place.
Step 1: Mapping the Estate
Permission discovery across 47 sites
The tenant had 47 SharePoint site collections. Marcus needed a complete picture of who had access to what: every user, at every access level, across every site, showing whether grants came through groups or directly. Running this manually through the SharePoint admin centre would have taken close to a week and produced results he could not sort or pivot without rebuilding them in a spreadsheet.
Using Report Master, he exported the full permission matrix to Excel in under an hour. Each row represented one user-site combination, with columns for access level, grant method (group or direct), and account type (internal or external guest). Sorting by account type immediately surfaced 31 external guest accounts still holding access to at least one site collection.
Library and storage audit
The storage report told a more specific story. Across the 47 site collections, version history accounted for 61 per cent of total storage. The four largest libraries were all administrative document libraries in clinical operations, HR, and legal. Nobody had touched the versioning settings since 2019. Seven years of 500-version history had been accumulating on files that were saved multiple times per day.
The report also surfaced three libraries last actively used in 2021. These were project libraries created for implementation efforts, still inheriting permissions from a group that included contractors no longer with the organisation. Nobody had archived or decommissioned them.
Step 2: Removing Stale External Access
Of the 31 external guest accounts in the permission export, Marcus confirmed 24 were associated with consultants, contractors, or vendor representatives whose engagements had ended. Cross-referencing with the contracts team confirmed none of the 24 were active. Four had not signed into the tenant in more than 18 months, according to the Entra ID last sign-in report.
Removing external access at scale involved two steps: deactivating the guest accounts in Entra ID, then verifying that no direct sharing links had been sent to those users' email addresses. The permission matrix from Report Master handled the first part. For sharing links, he used ShareMaster's Shared Links and Permissions view, which listed all active sharing links across the tenant, filterable by link type and recipient.
In total, Marcus removed external access for 24 accounts and revoked 19 direct sharing links. The process took one afternoon. He had budgeted two weeks for this work.
Guide: How to audit SharePoint shared links and external access
Step 3: Trimming Version History Before Retention Policies Landed
With external access cleaned up, Marcus turned to version history. The four high-volume libraries contained a combined 2.1 million stored versions. The records team had defined a governance target of 10 major versions per file for libraries that would carry long-term retention policies, and 5 major versions for general administrative libraries.
Using Space Master's Version Trimmer, he configured a trim for each library: keep the 10 most recent major versions per file, delete everything older. He ran a dry-run pass first to see how many versions would be removed. The preview showed 1.8 million versions across the four libraries would be deleted, recovering approximately 108 GB of quota. The actual trim ran overnight. By morning, storage utilisation had dropped from 78 per cent to 52 per cent of the allocated quota.
More importantly, the estate was now in a state where Purview retention policies could be applied to predictable, bounded content. The retention labels would preserve up to 10 versions per file going forward rather than locking in seven years of history.
Try ShareMaster free for 14 daysThe Outcome
The Purview rollout went live on schedule. The hospital group had a SharePoint environment that Marcus could describe in a governance document: which libraries held which content types, who had access and why, what version limits were in place, and which legacy libraries were decommissioned or set to read-only pending archive.
That baseline did not exist eight weeks earlier. The audit outputs - permission matrix, storage breakdown, version trim report - became part of the organisation's records management documentation. For similar preparation work, see the guide to auditing SharePoint permissions and the use case on storage audit and cleanup for a 200-user tenant.
| Task | Estimated without ShareMaster | Actual time with ShareMaster |
|---|---|---|
| Permission matrix across 47 sites | 4-5 days manual review | Under 1 hour |
| External access identification and removal | 2 weeks with PowerShell scripting | 1 afternoon |
| Version history trim across 4 libraries | Not practical without custom scripting | Overnight automated run |
| Sharing links audit and revocation | Manual per-site review | Under 30 minutes |
Frequently Asked Questions
Should you trim SharePoint version history before or after applying Microsoft Purview retention policies?
Before. Once a Purview retention policy applies to a SharePoint location, it overrides version trimming for items covered by the policy. Versions that fall within the retention period will be preserved even if they would otherwise have been deleted by a version limit change. Trimming before the policy is applied means you control what gets preserved rather than locking in years of accumulated history.
How do you find external users who still have access across a whole SharePoint tenant?
The SharePoint admin centre shows external sharing per site but does not produce a tenant-wide list of which guest accounts hold access to which sites and libraries. The Entra ID admin centre lists all guest accounts with last sign-in dates. Report Master exports a full permission matrix to Excel, covering all sites and showing whether each access grant is direct or group-based, without requiring PowerShell.
What SharePoint cleanup tasks should be completed before a Microsoft Purview deployment?
The highest-value pre-Purview tasks are: (1) audit and remove stale external access so retention policies do not preserve data accessible to former contractors; (2) trim version history before retention policies lock it in place; (3) identify and archive or decommission libraries no longer in active use; and (4) review and revoke sharing links that extend beyond current business relationships.
Learn more about Report Master's permission and storage reporting