Restore File Explorer Preview for Internet Marked Files

The Preview pane in File Explorer now shows a hard stop — “The file you are attempting to preview could harm your computer” — for many files Windows marks as coming from the Internet, and while that message is a deliberate security hardening it can break productivity; this guide explains exactly why it appears, how Windows decides which files are blocked, verified methods to restore previews for trusted files, safe bulk workflows for power users and IT, and the trade‑offs administrators must weigh before changing system policy.

Overview​

Microsoft updated File Explorer behavior in October 2025 so that files tagged with the Mark‑of‑the‑Web (MoTW) — the Zone.Identifier alternate data stream written when files are downloaded or saved from Internet sources — are not handed to Explorer preview handlers by default. Instead, the Preview pane displays the message: “The file you are attempting to preview could harm your computer. If you trust the file and the source you received it from, open it to view its contents.” This change is an intentional mitigation to stop a class of attacks that could leak NTLM authentication material when preview handlers resolve external resources inside documents.
The rest of this article explains:

• Why Microsoft made this change and the security threat it mitigates.
• Exact, verified steps to restore previewing for a single file or for large numbers of trusted files.
• Registry and Group Policy options administrators can use (and the security consequences).
• Practical operational advice: safe workflows, logging, and alternatives to mass unblocking.
• What is and isn’t verified — and which community inferences should be treated cautiously.

---

Background: what triggered the change and how Windows decides to block previews​

The underlying risk (in plain language)​

Preview handlers render content inside the shell process for convenience. Some file formats (PDFs, HTML fragments, Office docs, and archives) can contain references that cause the preview engine to fetch external resources — for example images, CSS, or UNC/SMB paths. If the preview operation causes Windows to attempt authentication to attacker‑controlled SMB/HTTP endpoints, negotiable authentication material (NTLM challenge/response blobs) can be observed and potentially replayed or abused in relay or credential‑recovery attacks. Microsoft’s documented change blocks the in‑process Preview pane for files that carry the Internet zone marker in order to remove this low‑friction attack surface.

Which files are affected​

• Files that carry a Mark‑of‑the‑Web (MoTW) Zone.Identifier alternate data stream (typical for files downloaded from browsers, saved from email attachments, or pulled from many web portals).
• Files viewed from network shares that are classified as the Internet security zone.
• Files created locally or saved from the Local intranet / Trusted sites zones are not affected and continue to preview normally.

How to confirm a file is blocked because of MoTW​

• Open File Explorer and enable the Preview pane (Alt+P).
• Select the file. If you see the security message instead of content, the file likely carries MoTW.
• To inspect the alternate streams from PowerShell:
• Get-Item -Path .\filename.pdf -Stream *
• Or use Sysinternals streams.exe to show Zone.Identifier.
  If the Zone.Identifier stream is present, the file is Internet‑marked and subject to the preview block.

---

Quick, safe fixes (verified)​

These steps are ordered from lowest to highest risk. All commands and Windows UI actions below are standard behavior documented by Microsoft or commonly used and validated in the field.

1) Safest: Unblock a single file (UI method)​

• Right‑click the file → Properties → on the General tab check Unblock → Apply → OK.
• After unblocking, reselect the file in the Preview pane; preview should return (sometimes requires restarting Explorer or signing out/in).
  This removes the Zone.Identifier alternate data stream for that file only and is the recommended action for one‑off trusted files.

2) PowerShell: Unblock a single file or specific pattern​

Open PowerShell (Run as Administrator if you need to change files in protected locations) and run:

• To unblock one pattern in Downloads (replace the path with your user folder):
  Unblock-File -Path "C:\Users\<YourUser>\Downloads*.pdf"

This command performs the same action as the UI Unblock checkbox by removing Zone.Identifier. Use this for a handful of files or for file‑type specific work. The cmdlet is part of standard PowerShell and removes the alternate data stream used for MoTW.

3) PowerShell: Bulk unblock a folder (use with caution)​

For trusted folders where you regularly receive vendor drops (archive of invoices, known partner uploads), use an auditable script:

# Example (run from elevated PowerShell)
Set-Location -Path "C:\Shared\VendorDocs"
Get-ChildItem -File -Recurse | Unblock-File

• Log hashes and the time of operation before and after unblocking for auditability.
• Limit the script to targeted directories and include a whitelist of file extensions if possible to reduce blast radius.

---

Policy and registry options — enterprise controls and caveats​

Group Policy (recommended path for administrators)​

The supported, auditable control is the Attachment Manager Group Policy. Path:
User Configuration → Administrative Templates → Windows Components → Attachment Manager → Do not preserve zone information in file attachments

• Enabling this policy prevents Windows from adding MoTW to saved attachments (so previews won’t be blocked for newly saved files).
• This should only be applied with compensating controls (EDR, network egress filtering, strong authentication hardening) because it removes a native OS signal used to measure file provenance.

Registry alternative (use with caution and test first)​

Community guidance shows administrators creating the following registry location when configuring this policy via registry:

• Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments
• Create DWORD (32‑bit) Value: SaveZoneInformation
• Set Value data: (community posts differ on exact values — see caution below)

Warning and verification: registry value semantics around SaveZoneInformation have been interpreted differently in community threads and some STIG documentation; the safe administrative recommendation is to use the Group Policy interface (or the official ADMX/MDM CSP mapping) rather than editing raw registry values in production. Always test in a lab before deploying. Microsoft documents the Attachment Manager policy and the related parameters — follow vendor documentation for exact registry mappings.

Important verification note: community write‑ups and independent forums reproduce a SaveZoneInformation registry approach, but exact numeric meanings in older documentation and some STIGs appear inconsistent. Treat low‑level registry edits as high risk until validated in a controlled test environment. Prefer Group Policy or MDM policy CSPs wherever possible.

---

Step‑by‑step repair recipes (practical)​

A. Restore preview for a single, trusted PDF — recommended for end users​

• In File Explorer, select the file and press Alt+Enter (Properties).
• In the General tab, check Unblock → Apply → OK.
• Reopen or refresh the Preview pane (Alt+P). If still blank, restart Explorer or sign out/in.

B. Bulk‑unblock a vendor drop folder safely — recommended for small teams​

• Create an operational change request: list folder path, operator name, time window, and file hash log.
• On a maintenance host: run elevated PowerShell:
  

  $folder = "C:\Shared\VendorDocs"
  # Log file list & hashes first
  Get-ChildItem -Path $folder -File -Recurse | Select FullName, Length, @{Name='SHA256';Expression={(Get-FileHash $_.FullName -Algorithm SHA256).Hash}} | Export-Csv C:\logs\pre_unblock.csv -NoTypeInformation

Unblock files (target file types only)​

Get-ChildItem -Path $folder -File -Recurse -Include .pdf,.docx | Unblock-File

Log after unblock​

Get-ChildItem -Path $folder -File -Recurse | Select FullName, Length | Export-Csv C:\logs\post_unblock.csv -NoTypeInformation

3. Store logs in a SIEM or change ticket for audit. Limit scope to a single vendor folder to reduce risk.

### C. If files are on a NAS or network share

- Add the share’s URL/IP to **Local intranet** or **Trusted sites** via Internet Options → Security → Trusted sites / Local intranet. Files saved from these zones will not receive the Internet zone marking and will preview normally. This is a *targeted* approach appropriate for trusted corporate portals but expands the trust boundary and must be governed. ([support.microsoft.com](https://support.microsoft.com/en-us/topic/file-explorer-automatically-disables-the-preview-feature-for-files-downloaded-from-the-internet-56d55920-6187-4aae-a4f6-102454ef61fb?utm_source=openai))

---

## Things you should NOT do (common but risky suggestions)

- Do not **globally disable MoTW** or broadly set policies that stop saving zone information without compensating security controls. That removes a valuable OS‑level signal for potentially dangerous files and can increase exposure. ([support.microsoft.com](https://support.microsoft.com/en-us/topic/information-about-the-attachment-manager-in-microsoft-windows-c48a4dcd-8de5-2af5-ee9b-cd795ae42738?utm_source=openai))
- Do not instruct non‑technical users to “just unblock everything.” Bulk unblocking without whitelisting, logging, and verification is a high‑risk operational shortcut.
- Avoid rolling back October 2025 security updates as a production fix. Uninstalling security updates is a last resort and reintroduces fixed CVEs; it is complex with combined servicing packages and not recommended as an organization‑wide remedy.

---

## Why this is a reasonable (if blunt) change — security analysis

- The mitigation reduces a low‑interaction, high‑impact attack vector: simply selecting a file in Explorer previously gave attackers an inexpensive path to cause network authentication attempts and capture negotiable authentication artefacts. Blocking preview for Internet‑zoned files closes that vector immediately without requiring third‑party preview handler fixes.
- The trade‑off is productivity: teams that triage many external documents will lose a speed shortcut and may incur more help‑desk work. The right operational posture is to combine *targeted* exceptions (Trusted Sites / Local intranet), audited unblocking scripts, and network/identity hardening rather than broad policy relaxations.

Security hardening steps to reduce overall risk:
- Block outbound SMB (TCP 445) egress from endpoints to the public internet at the perimeter firewall.
- Enforce SMB signing where possible and phase out NTLM or at least require NTLMv2 and strict restrictions.
- Use EDR to detect anomalous explorer.exe or dllhost.exe network connections and alert on unexpected SMB/NTLM traffic.

---

## Alternatives and practical stopgaps

- Use third‑party preview tools (for example QuickLook or PowerToys plugins) as a stopgap, but test these carefully — some use the same OS APIs and can be affected by the same zone checks.
- For suspicious files you must triage, use an isolated virtual machine or a sandboxing service to detonate files and observe outbound network behavior before unblocking locally. This reduces the chance of exposing credentials or contacting attacker infrastructure.

---

## FAQ — concise, verified answers

1. Will unblocking a file make it safe?
   - Unblocking only removes the provenance marker (MoTW). It does not scan or remove embedded threats. Always validate the file origin and scan unblocked files with up‑to‑date AV/EDR. ([support.microsoft.com](https://support.microsoft.com/en-us/topic/file-explorer-automatically-disables-the-preview-feature-for-files-downloaded-from-the-internet-56d55920-6187-4aae-a4f6-102454ef61fb?utm_source=openai))

2. Is Unblock‑File safe to use in scripts?
   - Yes, the PowerShell cmdlet removes the Zone.Identifier stream. Use it only against controlled, trusted folders and implement logging and change control. ([pdq.com](https://www.pdq.com/powershell/unblock-file/?utm_source=openai))

3. Does Microsoft provide an official fix to restore previous behavior?
   - Microsoft’s published guidance states the behavior is deliberate to mitigate NTLM leakage and documents the supported override actions (Unblock, Trusted sites, Group Policy). Monitor Microsoft Release Health for any targeted hotfix or Known Issue Rollback, but do not rely on undocumented registry “hacks.” ([support.microsoft.com](https://support.microsoft.com/en-us/topic/file-explorer-automatically-disables-the-preview-feature-for-files-downloaded-from-the-internet-56d55920-6187-4aae-a4f6-102454ef61fb?utm_source=openai))

4. Are the registry values to change SaveZoneInformation safe and standardized?
   - The Group Policy mapping is the supported method. Community posts suggest specific registry edits, but some older documentation and STIG descriptions vary in how they present numeric values; administrators should prefer Group Policy or the ADMX/MDM CSP and test registry edits in a lab first.

---

## Final recommendations and operational checklist

1. Patch first — ensure Windows Update is current and devices have the October 2025 security updates (the preview pane change accompanies those updates). Do not skip security rollups in order to preserve preview behavior.
2. Use per‑file Unblock for one‑offs and logged PowerShell Unblock workflows for narrowly scoped vendor drop folders. Keep an audit trail.
3. For recurring trusted sources (vendor portals, internal file servers), add the server to **Local intranet** or **Trusted sites** rather than disabling MoTW globally. This keeps the trust boundary limited. ([support.microsoft.com](https://support.microsoft.com/en-us/topic/file-explorer-automatically-disables-the-preview-feature-for-files-downloaded-from-the-internet-56d55920-6187-4aae-a4f6-102454ef61fb?utm_source=openai))
4. If you manage an organization: inventory who relies on Explorer previews, pilot targeted mitigations, and harden network/identity posture (SMB egress rules, NTLM restrictions, EDR detection).
5. Avoid raw registry edits in production — prefer Group Policy or the Attachment Manager policy CSP, and test any change in a lab before broad rollout.

---

## Conclusion

The Preview pane message “The file you are attempting to preview could harm your computer” is not a transient bug but an intentional, defensive change aimed at preventing low‑interaction credential‑leak attacks via preview handlers. For individuals and small teams, the safest fixes are the UI **Unblock** checkbox or the PowerShell **Unblock‑File** cmdlet applied to trusted files. For enterprises, targeted zone exceptions and auditable unblocking scripts — combined with identity and network hardening — strike the best balance between productivity and security. Use Group Policy and documented Attachment Manager controls where possible, test registry or policy changes in a lab, and keep thorough logs when you unblock files at scale. ([support.microsoft.com](https://support.microsoft.com/en-us/topic/file-explorer-automatically-disables-the-preview-feature-for-files-downloaded-from-the-internet-56d55920-6187-4aae-a4f6-102454ef61fb?utm_source=openai))

If you follow the steps and controls described here you can restore preview convenience for trusted workflows while preserving the security benefits that motivated Microsoft’s change.

[hr][/hr]**Source:** Followchain [How to Fix The File You Are Attempting To Preview Could Harm Your Computer in Windows 11](https://www.followchain.org/the-file-you-are-attempting-to-preview/)