Blocked File Types

How MigrationFox handles the SharePoint tenant policy that refuses specific file extensions. Every Microsoft 365 tenant has a DisallowedFileTypes list. MigrationFox reads your destination tenant’s live policy at pre-flight, labels any file it refuses as a destination-side skip (not a failure), and gives you the exact extension and path so you can decide whether to relax policy, exclude the file, or move it through a different channel.

What SharePoint blocks by default

Every Microsoft 365 tenant ships with a default blocked-file-types list configured under SharePoint admin center → Policies → Blocked file types. The default is conservative and focused on executables and server-scripting extensions that represent historic malware-delivery vectors. Your tenant’s effective list may differ — admins add or remove entries over the years — so always confirm against your own tenant before planning a migration.

Extension	Why blocked by default
.aspx .asmx .ashx	Server-side SharePoint page handlers — risk of uploaded content being executed as server code.
.master	SharePoint master page — controls site chrome, a replacement can compromise a site.
.htc	HTML component — runs script in legacy IE contexts; still flagged for compatibility.
.soap	SOAP message — associated with legacy SharePoint service endpoints.
.shtm .shtml .stm	Server-parsed HTML — historic web-server execution paths.
.dll .exe .msi	Windows binaries — general malware vector, blocked at platform level.
.config	.NET configuration — blocked to prevent SharePoint behavior overrides.
.ps1 .psm1 .ps1xml	PowerShell — executable script, administrative risk.
.vbs .wsf .jse .vbe	Windows Script Host formats — legacy malware vector.

Microsoft has trimmed this list over the years. Several extensions that were once blocked by default (.html, .htm, .js, .jar) were removed as SharePoint’s execution model moved to client-side rendering. The only authoritative source for your own effective list is the tenant itself, which is what MigrationFox reads.

How MigrationFox detects a blocked file

Detection happens in two places. Both matter because the second is the ground truth.

At pre-flight

When a migration job starts, MigrationFox reads the destination tenant’s current blocked-file-types policy once, caches it for the run, and displays the expected skip count on the scan report before any upload begins. You see something like “12 files will be rejected by tenant policy” with the specific extensions listed. This is a prediction, not a guarantee — policy can change between pre-flight and upload — but it is accurate the vast majority of the time and lets you request a policy relaxation before cutover rather than discovering it mid-migration.

At upload

When the engine attempts to upload a file whose extension the cached policy blocks, it skips the upload altogether rather than wasting a round trip. When a file slips past the cached list and SharePoint rejects it at upload (for example, because the policy changed mid-run), the response comes back as a blocked-file-type error. MigrationFox classifies the file as SKIPPED-dest-blocked with the specific extension and policy reason, not as FAILED. The distinction is critical: FAILED implies a defect that a retry might fix, SKIPPED implies a conscious policy exclusion that retrying will never resolve.

The four-column verdict

Every completed migration report in MigrationFox breaks outcomes into four columns rather than the usual two:

Column	Meaning	Retry helps?
Completed	File is in the destination.	N/A
Skipped — Source	Source platform refused the download (e.g. Google Drive malware scan on a binary).	No — requires file-owner manual action.
Skipped — Destination	Destination tenant policy refused the upload (blocked file type).	No — requires policy change or out-of-band move.
Failed	Transient error, throttle exhaustion, malformed content, storage quota.	Yes — retried automatically, operator intervention for persistent failures.

Each skip row in the report carries the full source path, the exact extension, and the reason code (e.g. dest.ext.blocked or source.download.refused). The CSV export preserves the same columns so you can hand the destination-blocked list to a SharePoint admin without reformatting.

Exception workflow

Three ways to handle a set of files that would otherwise be blocked at the destination. Pick based on how many files, how permanent the need, and whether you control the destination tenant.

Custom tenant allowlists

The DisallowedFileTypes policy is a blocklist, not an allowlist — SharePoint accepts any extension not explicitly on the list. So there is no “allowlist” to configure; the way you “allow” an extension is to remove it from the blocklist.

Scoping considerations when you customize the list:

• Policy is tenant-wide. There is no per-site-collection or per-library override. Relaxing the policy to accept .exe relaxes it for every site in the tenant.
• Mitigate with site membership. If you need an installer library, create a dedicated site collection, tighten its membership to the IT team that needs installer access, and document the choice in your migration run-book so a future admin does not re-tighten the policy without understanding why it was relaxed.
• Extensions are matched case-insensitively. .EXE and .exe match the same rule. Double extensions (setup.exe.txt) are evaluated on the final segment only — a .txt file with .exe earlier in the name passes.

What MigrationFox does automatically

• Reads the destination policy once per job at pre-flight and caches it for the run. No per-file round trips to check policy.
• Short-circuits at source-read time when possible. If .exe is known to be blocked at the destination, the engine does not spend source API budget downloading the file at all.
• Distinguishes source vs. destination skips in both the dashboard verdict and the CSV export. You can filter and act on each category separately.
• Never silently renames or re-extensions files. Renaming setup.exe to setup.exe.bin to slip past the filter would be a policy bypass and would break any downstream automation that reads extensions. If you want a workaround, you do it explicitly.
• Surfaces the exception list up front on the scan report, so you can request a policy relaxation or plan an exclusion before cutover rather than after.

Troubleshooting

Symptom	Likely cause	Fix
Scan report shows “N files will be rejected by tenant policy”	Destination tenant blocks one or more extensions present in the source.	Click the count to see the full list. Decide per file whether to exclude, relax policy, or move out-of-band.
Files appear under Skipped-Destination even though the admin claims the policy was relaxed	Policy was changed after the job started; MigrationFox cached the older list at pre-flight.	Re-run the job or start a new one — the new job reads the updated policy at start.
A file my user cares about is in Skipped-Destination	That file’s extension is on the tenant blocklist.	Relax the tenant policy to admit the extension and re-run, or migrate the file out-of-band. Retrying the same job without a policy change will produce the same skip.
Expected skip count differs from actual	Policy changed between pre-flight and upload, or a subset of files was filtered by another rule (junk-file filter, size limit) before reaching the blocked-file check.	Compare the pre-flight skip list with the post-run CSV. The diff explains the delta row-by-row.
Files appear under Skipped-Source (not Destination) even though they are executables	Google Drive’s malware-download policy refused to serve the bytes. This is source-side and independent of SharePoint’s blocklist.	See Executable file handling. Resolution requires the file owner to acknowledge the download manually via the Google Drive UI.
The scan report does not show an expected-skip row at all	MigrationFox could not read the destination’s DisallowedFileTypes policy (missing credential scope, or destination is not a SharePoint target).	Verify the destination credential has SharePoint Admin or Global Admin rights on the tenant. For non-SharePoint destinations (Azure Blob, S3, SFTP), the blocked-file concept does not apply.

Related

• Executable file handling — focused deep-dive on .exe, .dll, and Google Drive’s malware-download policy
• Skip junk files — the other category of Skipped, for harmless OS artifacts
• SharePoint provisioning — automated destination site creation that runs before uploads begin