How to use preview feature given the Oct update that blocks the files with MOTW tag?

I have tried all of the listed fixes in this post and none of them fully resolve the issue. I found a fix buried somewhere in reddit that I figured I'd share. Keep in mind this totally bypasses the security MS put in place that broke the functionality in the first place. I tested it on a workstation to verify that it worked before pushing it out through group policy. Hopefully this helps someone out.

Copy and paste the following into notepad. Save with a .reg extension and run it. Reboot and the problem should be fixed.

Windows Registry Editor Version 5.00

; Allow previews for files marked Internet Zone (ZoneId=3)

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]

"180F"=dword:00000000

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]

"180F"=dword:00000000

; Also allow under "Internet (Lockdown)" zone, in case Explorer uses lockdown policies

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones\3]

"180F"=dword:00000000

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones\3]

"180F"=dword:00000000

Hi Burhan Kanchwala,

Just following up to ensure the distinction is clear. The registry keys (SaveZoneInformation) only alter how Windows processes incoming data streams; they do not retroactively scrub the Zone.Identifier Alternate Data Stream (ADS) from files already sitting on the drive.

For the existing blocked files on your network share, the PowerShell command Get-ChildItem -Path "\\Server\Share" -Recurse | Unblock-File is the mandatory step to strip those hidden tags in bulk. If you prefer to rely on the ZoneMap registry fix to allow previews without unblocking the files, strictly ensure the registry key (ZoneMap\Domains\ServerName or ZoneMap\Ranges\Range1) matches the exact string users type to access the share (e.g., if users map via FQDN, an IP registry entry will be ignored by the OS). A full restart of the explorer.exe process is required for these Zone changes to activate.

If the issue has been successfully resolved, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

VP

The registry key SaveZoneInformation strictly prevents the Mark of the Web (MOTW) from being applied to future file operations; it does not retroactively strip the Zone.Identifier Alternate Data Stream (ADS) from files that are already tagged. While the Intranet Zone mapping (ZoneMap) solution I provided should instruct Windows to trust the location regardless of the file's tag, this detection is brittle if there is a mismatch between the registry entry and the access path (e.g., mapping an IP but browsing via Hostname) or if the explorer.exe process has not been restarted to reload the security zones.

To resolve the issue for existing files immediately, you need to forcefully strip the MOTW stream from the entire directory structure. The most efficient method is using PowerShell to recurse through the share and remove the identifier from every file. Open an elevated PowerShell prompt and run the following command, replacing the path with your actual UNC path:

Get-ChildItem -Path "\\fileserver\folder" -Recurse -File | Unblock-File

This command identifies every file in that tree and deletes the hidden Zone.Identifier stream, permanently unblocking them without requiring the ZoneMap trust to function perfectly.

Regarding the ZoneMap failure you observed: for the registry fix to work on existing files without the PowerShell step, the entry in HKEY_CURRENT_USER\...\ZoneMap must exactly match how users access the share. If you added the IP address (e.g., 10.0.0.5) to the Ranges key but users browse to \\FileServer01, Windows considers \\FileServer01 to be in the Internet Zone because it doesn't match the specific IP entry you whitelisted. You must verify that the registry key under ZoneMap\Domains matches the hostname (e.g., fileserver01) exactly, or ensure users are browsing via the IP you whitelisted. Additionally, a reboot or a forced restart of the explorer.exe process via Task Manager is mandatory for these Zone changes to take effect on active Explorer windows.

VP

Hi Burhan Kanchwala,

The registry key SaveZoneInformation you previously applied instructs the Attachment Manager to stop adding the Zone Identifier to newly downloaded files, but it does not resolve the issue for files residing on a Network Share that Windows determines to be part of the Internet Zone (Zone 3). When a UNC path or mapped drive is not explicitly trusted, Windows treats it as an external source, applying the Mark of the Web (MOTW) logic and blocking Preview Handlers (which often run in a sandbox like Office Protected View) from rendering the content. To fix this specifically for network shares, you must map the server's IP address or hostname to the Local Intranet Zone (Zone 1).

You can force this assignment directly via the Registry, which is more reliable than the GUI for persisting across sessions. Open the Registry Editor (regedit.exe) and navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Ranges. Right-click Ranges and create a new Key (folder) named Range1 (ensure this name is unique if other ranges exist). Inside this new Range1 key, create a String Value (REG_SZ) named :Range and set its value to the IP address of your file server (e.g., 10.0.0.50). Next, within the same key, create a DWORD (32-bit) Value named * and set its data to 1. The value 1 strictly assigns that IP range to the Local Intranet zone.

If you access the share via a hostname (e.g., \\FileServer01) instead of an IP, you must instead configure the path HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains. Create a new key matching the server name, and inside it, create the same * DWORD with a value of 1. After applying these changes, restart the explorer.exe process or reboot. This configuration forces Windows to trust the location natively, bypassing the security blocks for the preview pane without requiring you to lower the global MOTW policies.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

The issue you're experiencing with the inability to preview files marked with the Mark of the Web (MOTW) is indeed related to security changes in Windows updates. Here are some key points regarding the handling of MOTW and how to address the preview feature:

1. Understanding MOTW: Files downloaded from the internet are tagged with MOTW, which prevents certain actions, including previewing the file in applications like Outlook. This is a security measure to avoid potential malicious code execution.
2. Unblocking Files: To restore the ability to preview these files, you typically need to manually unblock them. However, there are methods to automate or simplify this process:
   • Group Policy Setting: If you have access to Group Policy, you can enable the policy "Do not preserve zone information in file attachments". This will remove the MOTW from files automatically, allowing previews without manual intervention.
   • Registry Tweak: For users without Group Policy access, editing the registry can achieve similar results. By setting the SaveZoneInformation DWORD value to 2, you can prevent the preservation of MOTW, thus allowing previews.
   • PowerShell Script: For bulk unblocking of files, a PowerShell script can be used to remove MOTW from multiple files at once, which can be particularly useful if you have many files affected.
3. Network Shares: If you are still facing issues with files saved on network shares, ensure that the network location is either in the Trusted sites or Local intranet zone, as this can affect how MOTW is applied to those files.

These steps should help you manage the preview feature effectively despite the changes introduced in the October update.