Excel "Enable Editing" (Protected View) keeps re-prompting every time on Windows Server 2022, but works correctly on Windows 11 for the same file

Laxman singh 1 Reputation point
2026-08-17T13:09:14.63+00:00

Environment

Product: Microsoft 365 Apps for business, Current Channel

Version: 2607 (Build 20228.20124, Click-to-Run)

Affected machine: Windows Server 2022

Comparison machine (working correctly): Windows 11, same Microsoft 365 Apps version

Office Administrative Template files (ADMX/ADML): version 5568.1000, loaded into C:\Windows\PolicyDefinitions on the Server 2022 machine so Excel-specific Group Policy settings are visible in Local Group Policy Editor

Goal

We regularly open legacy .xls (Excel 97-2003) files that need editing. We expect to click "Enable Editing" once per file — after that, reopening the same file should not prompt again, exactly as it behaves on our Windows 11 machines.

The problem

On Windows Server 2022, every time we reopen the exact same .xls file, Excel shows the Protected View banner and asks us to click "Enable Editing" again — even within the same day/session, after we already approved that file once. On a Windows 11 machine running the same Microsoft 365 Apps version, clicking "Enable Editing" once is remembered permanently for that file; reopening it never prompts again.

Steps to reproduce (on Windows Server 2022)

Open an .xls file from a local folder — the Protected View banner appears with an "Enable Editing" button.

Click "Enable Editing" — the file becomes editable.

Close the file.

Reopen the exact same file again.

Expected: file opens directly, fully editable, no prompt.

Actual: the Protected View banner appears again, asking to click "Enable Editing" once more.

The same exact file, copied to a Windows 11 machine running the same Office version, does not exhibit this problem — step 4 opens it directly editable after the first approval.

What we've already checked and ruled out

File is not marked Read-only at the NTFS/file-attribute level, and folder/file permissions grant Modify/Write to the account in use.

No stale Excel lock file (~$filename.xls) present.

Confirmed via reg query "HKCU\Software\Policies\Microsoft\Office\16.0\excel\security\fileblock" that a separate File Block Settings policy ("Allow editing and open in Protected View" for Excel 97-2003 files) is applied and working as intended — this only affects whether Protected View can be exited at all, and is functioning correctly; it is not the cause of the repeat-prompt behavior.

Investigating whether HKCU\Software\Policies\Microsoft\Office\16.0\excel\security\trusted documents\disabletrusteddocuments is set to 1 on the Server 2022 machine (this is the registry value that, if set, disables the "remember this file" behavior entirely) — suspect a pre-existing security hardening policy/baseline may have set this, but haven't yet found the exact source GPO.

Questions for the community/Microsoft

Is Trusted Documents expected to behave any differently by default on Windows Server 2022 vs. Windows 10/11 client editions for Microsoft 365 Apps (Current Channel)? Or should behavior be identical unless a policy explicitly overrides it?

What is the current, correct Group Policy path and/or registry key to force Trusted Documents to be enabled (i.e., remembered between opens) on Windows Server 2022 for Microsoft 365 Apps Version 2607+?

Are there any known Windows Server-specific security baselines, RDS/multi-session considerations, or Microsoft 365 Apps-on-Server caveats that intentionally disable Trusted Documents by design, that we should be aware of before re-enabling it?

Any guidance — official documentation links, the exact supported registry/GPO path, or confirmation this is a known server-vs-client difference — would be appreciated.

Microsoft 365 and Office | Excel | For business | Other
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Michelle Nguyen 1,180 Reputation points Independent Advisor
    2026-08-17T13:51:42.1333333+00:00

    Hi @Laxman singh

    Thank you for the detailed post, the environment information, reproduction steps, and what you’ve already ruled out make this much easier to narrow down.

    Based on your description, I understand that on Windows Server 2022, Excel re-prompts “Enable Editing” every time the same .xls file is reopened, while on Windows 11 with the identical Microsoft 365 Apps build the trust decision is remembered permanently, and you suspect the Trusted Documents feature is being disabled by policy on the server.

    -Is behavior expected to differ between Server 2022 and Windows 10/11?

    No. Trusted Documents behavior in Microsoft 365 Apps is identical across supported client and server operating systems. There is no built-in, by-design difference on Windows Server 2022. When you click Enable Editing, Excel writes a per-file trust record under:

    HKCU\Software\Microsoft\Office\16.0\Common\Trusted Documents\TrustRecords

    If reopening the same file prompts again, either the trust record is not being written (blocked by policy), or it is being discarded (profile/registry not persisting). Since your issue reproduces within the same session, a policy is the most likely cause, your suspicion is well-founded.

    1.The exact policy paths to check

    Please verify all of the following, as any one of them produces your symptom:

    -Turn off trusted documents — Registry: HKCU\Software\Policies\Microsoft\Office\16.0\excel\security\trusted documents > DisableTrustedDocuments = 1. GPO path: User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center > Trusted Documents > “Turn off trusted documents”. This must be Not Configured or Disabled for trust to be remembered.

    -Turn off trusted documents on the network, same key, value DisableNetworkTrustedDocuments = 1, same GPO folder. Important: if the .xls files are opened from a mapped drive, UNC path, or DFS share on the server, this policy alone reproduces your exact behavior while local files work fine. The Microsoft Security Baseline for Microsoft 365 Apps for enterprise enables this setting by default, so if a baseline was imported on the server, this is a very likely culprit.

    -Also check the same two values under the Office-wide hive: HKCU\Software\Policies\Microsoft\Office\16.0\common\security\trusted documents.

    To confirm which GPO is delivering the value, run gpresult /h report.html under the affected user account and search the report for “Trusted Documents”, or use rsop.msc. If the value exists in the registry but no GPO appears in the report, it was likely set directly by a hardening script or imported baseline (LGPO.exe), in which case check Local Group Policy on the server itself.

    2.Server-specific caveats before re-enabling

    -Security baselines such as the Microsoft 365 Apps security baseline, CIS benchmarks, and DISA STIGs commonly disable Trusted Documents (especially on the network) as intentional hardening. Please confirm with your security team before overriding, and prefer scoping the change (e.g., a separate GPO/OU for the server, or keep network trust disabled but allow local trust).

    -On RDS / multi-session hosts, trust records live in HKCU, so mandatory profiles, profile resets, or FSLogix/UPD misconfiguration will silently discard trust between logons. That would cause re-prompting across sessions rather than within one, so it’s a secondary check in your case.

    -A cleaner long-term alternative: add the folder containing these legacy .xls files as a Trusted Location (Excel > Trust Center > Trusted Locations, or the equivalent policy). Files in a Trusted Location bypass Protected View entirely and don’t depend on per-file trust records at all.

    Quick verification once you make the change: open the .xls, click Enable Editing, then check whether a new entry for that file path appears under the TrustRecords key above. If the record appears and persists, reopening will no longer prompt.

    Please let me know what gpresult shows, happy to help trace the source GPO if the value turns out to come from somewhere unexpected.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.