The PowerShell SafeScan writes for your tenant — and how to run it safely
Microsoft 365 remediation PowerShell generated from your own scan, not a forum snippet. What the scripts change, and the four rules for running them safely.
Every Microsoft 365 security assessment ends the same way: a PDF of findings, ranked by nothing, handed to whoever is least able to argue. The findings are usually correct. They are also, on their own, useless.
What is missing is the fix — written against the tenant you actually have, not the one in the documentation.
Why a snippet from a forum is not a fix
Search any SharePoint oversharing problem and you will find PowerShell within thirty seconds. It will be correct in outline and wrong in every particular that matters: it does not know your site URLs, your sensitivity label GUIDs, which of your admin accounts are dormant, or which of your sites are under a retention policy that will make the command fail silently.
So the honest version of "here is the PowerShell" is usually four hours of an engineer adapting it, plus a change request, plus the risk that the adaptation is where the mistake gets introduced.
SafeScan generates the script from the scan. The findings already contain the site collection, the sharing capability, the label, the account. The script is those values in the right cmdlets.
What the generated script actually contains
Take the most common exposure finding — overshared files and external links. The generated remediation looks like this, with your tenant's values in place of the placeholders:
# Connect to SharePoint Online
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
# Report all sites with external sharing enabled
Get-SPOSite -Limit All |
Where-Object { $_.SharingCapability -ne "Disabled" } |
Select-Object Title, Url, SharingCapability |
Export-Csv oversharing_report.csv -NoTypeInformation
# Disable tenant-wide external sharing
Set-SPOTenant -SharingCapability DisabledThree things are worth noticing about that.
The middle block is a report, not a change. It writes a CSV. You run it first, read it, and decide. Microsoft documents Get-SPOSite and the SharingCapability values it returns, so nothing here is proprietary behaviour you have to take on trust.
The last line is the blunt instrument. Set-SPOTenant -SharingCapability Disabled turns external sharing off for the entire organisation. That is the correct fix for some tenants and a business-stopping outage for others — which is exactly why it is generated as a script you review rather than a button the tool presses.
And the whole thing is readable. If you cannot explain a script to your change board, it should not run. A generated script that is three cmdlets and two comments passes that test; a 200-line module you found on a blog does not.
How to run it without breaking Friday
Four rules, in order.
1. Read it before you run it
Not a formality. Confirm it touches the scope you expect, that the tenant URL is yours, and that nothing in it deletes rather than reconfigures. The reports are safe by construction; the Set- commands are the ones to slow down on.
2. Use -WhatIf on anything that writes
Most state-changing cmdlets support -WhatIf, which prints what the command would do and then does nothing. Microsoft covers the mechanism in everything about ShouldProcess. Run the change with -WhatIf, read the output, then run it for real. This is the single highest-value habit in tenant administration and it costs about forty seconds.
3. Stage by blast radius
Tenant-wide settings last, not first. Work outward: one site, then one department's sites, then the tenant. A sharing change that annoys one team is a conversation; the same change applied tenant-wide on a Friday afternoon is an incident.
4. Rescan to confirm, rather than assuming
A command that returns no error has not necessarily had the effect you wanted — particularly where a retention policy or a hold is quietly overriding it. Re-run the scan and look at whether the check now passes. That is the only confirmation that counts.
It is not only SharePoint
Exposure findings get the attention because they are the ones Copilot makes visible fastest. The generated remediation covers the other domains too, and those scripts look different in a way worth knowing about.
Identity findings mostly produce reports rather than changes. A script that lists accounts without strong authentication, or admin accounts that have not signed in for ninety days, is something you act on through a policy change rather than a cmdlet — Microsoft's Conditional Access is a policy surface, not a per-user setting, and a script that disabled accounts in bulk would be reckless.
Compliance findings tend to produce one-line enablement commands with long tails. Turning on audit logging is a single command; the consequence is that you now have audit data from today onwards and none from before, which is a planning fact rather than a technical one.
Teams findings sit between the two. External access and anonymous join are tenant settings with real business consequences, so the script reports first and changes second, same as sharing.
When not to run the script at all
Three cases where the right answer is to close the terminal.
When you do not own the decision. Disabling external sharing is a business change wearing a technical costume. If the finding touches how a department works with clients, the fix is a conversation first.
When the finding is the system working correctly. A legal matter structure with hundreds of unique permissions is not sprawl. Ask the owner before you restore inheritance and flatten something deliberate.
When you cannot roll it back. Most sharing and policy changes are reversible. Some content changes are not. If you cannot state how to undo it, you are not ready to run it.
The scripts do not run themselves
Worth being explicit, because it is the first thing security asks: SafeScan has no write permission anywhere in its consent. It cannot execute these scripts, and it could not change your tenant if it wanted to. It reads, it finds, it writes you the remediation. A human runs it, from their own session, with their own credentials, and their own change control.
That is a deliberate limitation rather than a missing feature. A tool that can both find and fix at tenant scale is a tool that can break a tenant at scale.
Where this fits
Copilot SafeScan runs 23 read-only checks across six domains — exposure, identity, compliance, Teams, licensing and the composite Copilot readiness score — in under five minutes on a typical tenant. Each failing check carries the remediation steps written as an admin-centre path, the generated PowerShell, and the raw findings behind it.
Next: 23 findings, one afternoon — what to fix first, and what moving a readiness score is actually worth. For the background on why exposure is the dominant finding, see why overshared SharePoint is your biggest Copilot risk.
