Why .exe, .dll, and other executables show as Skipped

If your migration report has a non-zero Skipped count and your content included software installers or build artifacts, this is why. Executable files are blocked on both ends of a Google Drive → SharePoint migration, for different reasons, and MigrationFox detects both policies at pre-flight so the migration doesn't waste API budget trying.

Example completion report for an IT team shared drive. Two distinct Skipped columns: source-side (Google refused the download) and destination-side (SharePoint policy block).

Why Google Drive blocks downloads of executables

Google Drive runs an opportunistic malware scan on download. For files under 25 MB the scan runs inline and most binaries come through fine. For files over 25 MB, the scan can't run synchronously, so the API returns a 403 cannotDownloadAbusiveFile on any file Drive considers high-risk — typically installers, archives of binaries, unsigned DLLs, and anything Drive's heuristic flagged as "potentially malicious" regardless of whether it actually is.

There is a per-file override parameter (acknowledgeAbuse=true) that a signed-in owner of the file can set to force the download. Service accounts and OAuth apps cannot set it — it must be the file's owner, clicking a warning banner, in the UI. MigrationFox cannot impersonate a human click, so we log these as source-side skips and list them on the report with enough detail for the file's owner to download manually.

Why SharePoint has a blocked-file-types policy

Every Microsoft 365 tenant has a DisallowedFileTypes list, editable by a SharePoint Admin. Uploading a file whose extension is on the list returns HTTP 400 with a blocked-file-type error. The default list exists because executable content in document libraries is a malware-delivery vector that OneDrive/SharePoint's scanner cannot fully inspect (code-signed installers, macro-laden Office files with double extensions, script runners).

The default is conservative but the tenant admin can relax it. Many IT teams with legitimate installer repositories do exactly this — usually by removing .exe, .msi, and .ps1 from the tenant default and leaving the malware-heavy extensions (.bat, .vbs, .js at root) blocked.

SharePoint default blocked-file-types list

The default DisallowedFileTypes varies slightly across tenant vintages but these are the extensions every current tenant ships blocked:

Extension	Description
.ashx	ASP.NET HTTP handler — executable at URL if uploaded to certain paths.
.asmx	ASP.NET web service endpoint — same risk class as .ashx.
.aspx	ASP.NET Web Forms page — can contain code-behind that runs in-process.
.bat	Windows batch script — runs verbatim in cmd.exe.
.cmd	Modern Windows command script; same risk as .bat.
.com	Legacy DOS executable — still runs on Windows.
.dll	Windows dynamic-link library — loaded by other executables.
.exe	Windows portable executable — the canonical installer/binary extension.
.htm / .html	HTML page — can host script content that runs in browser if served from SharePoint.
.ins	Internet Communications Settings — can reconfigure Windows network stack.
.isp	Internet Communications Service Provider — related to .ins.
.jar	Java archive — executable with a JRE installed.
.js	JavaScript file — runs via Windows Script Host or in a page context.
.jse	Encoded JScript — obfuscated .js.
.lnk	Windows shortcut — can point at an arbitrary executable.
.mde	Compiled Access database with code.
.mht / .mhtml	MIME HTML archive — historically used to smuggle script payloads.
.msh, .msh1, .msh2	Microsoft Shell (early PowerShell) script.
.msi	Windows Installer package.
.msp	Windows Installer patch package.
.ps1, .ps1xml, .ps2, .psc1, .psc2	PowerShell script and related manifest types.
.reg	Windows registry merge file — can silently modify system config.
.scf	Windows Explorer command file.
.scr	Windows screensaver — effectively a renamed .exe.
.shtml	Server-side include — executes in certain SP configurations.
.soap	SOAP service definition.
.svc	WCF service endpoint.
.vb, .vbe, .vbs	VBScript variants — ran automatically by Windows Script Host.
.ws, .wsc, .wsf, .wsh	Windows Script Host container formats.

Your tenant's effective list can differ — admins add or remove entries over the years and rarely document the change. Always check your own tenant's policy before making assumptions.

How to check your destination tenant's policy

From a PowerShell session with the SharePoint Online module installed:

Install-Module Microsoft.Online.SharePoint.PowerShell -Scope CurrentUser
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
(Get-SPOTenant).DisallowedFileTypes

The output is a semicolon-separated string of extensions, no dots. If it's empty, the tenant has disabled blocking entirely (uncommon, and not recommended).

How to relax it if you need installers in SharePoint

Two approaches. Pick based on how permanent the need is.

Temporary removal for the cutover window

Relax the policy just long enough to run the migration, then restore it. Run as a SharePoint Admin:

# Capture current list so you can restore it after
$before = (Get-SPOTenant).DisallowedFileTypes

# Relax — example: allow .exe, .msi, .dll, .ps1
Set-SPOTenant -DisallowedFileTypes "ashx;asmx;aspx;bat;cmd;com;htm;html;ins;isp;jar;js;jse;lnk;mde;mht;mhtml;msh;msh1;msh2;msp;reg;scf;scr;shtml;soap;svc;vb;vbe;vbs;ws;wsc;wsf;wsh"

# Run the migration...

# Restore original policy
Set-SPOTenant -DisallowedFileTypes $before

Changes propagate across the tenant within a few minutes. The MigrationFox pre-flight check re-reads the policy at job start, so a mid-day relaxation will only take effect on jobs you start after the change.

Permanent relaxation for an installer library

Tenant-wide relaxation is appropriate if your IT team needs an installer repository in SharePoint as a normal working practice. Best practice: create a dedicated site collection for installers, lock down membership, and remove only the minimum extensions from the tenant list. Layering a site-level policy on top to re-block is not possible — DisallowedFileTypes is a tenant-level setting only.

What MigrationFox does automatically

• Reads the destination policy at pre-flight. The current DisallowedFileTypes is fetched once at job start and cached for the run. No per-file round-trips to check.
• Skips at source-read time, not upload time. If .exe is blocked at the destination, we don't download it from Google Drive at all — saving source API budget and bandwidth. You'd be surprised how often this matters on a 100 GB installer archive.
• Distinguishes source vs. destination skips on the report. The final CSV has a skipReason column with values like dest.ext.blocked, source.download.refused, or source.abusive-file. You can filter and act on each category separately.
• Never silently re-extensions files. We don't rename setup.exe to setup.exe.bin to slip past the filter. That would be a policy bypass and would break any downstream automation that reads extensions. If you want a workaround, you do it explicitly.

What's next

• Auto-skipped files reference — the other category of Skipped, for harmless OS artifacts.
• Google Drive migration reliability — where Skipped fits in the overall reliability model alongside Retried and Failed.
• Migration Rehearsal dry-run — the rehearsal surfaces the executable block list before cutover so you can request a policy relaxation in advance.