Microsoft 365 Apps for Windows version 2508, released on August 26, 2025, now blocks the FrontPage Remote Procedure Call (FPRPC) protocol by default—a move that will break file-open operations relying on legacy web folder paths. System administrators and power users who still use http:// or https:// paths mapped through WebDAV or ancient SharePoint workflows are already seeing errors when opening documents directly in Word, Excel, or PowerPoint. The change is a silent but significant hardening step that slams the door on a decades-old attack surface, but it also forces organizations to finally modernize their file access patterns or implement workarounds through Office Trusted Locations.

The Forgotten Protocol: What Is FPRPC?

FrontPage Remote Procedure Call is a Microsoft proprietary protocol originally built for the long-defunct FrontPage web authoring tool. In the late 1990s and early 2000s, it enabled remote file management and collaborative editing over HTTP. When SharePoint emerged, FPRPC was baked into its foundations for opening and saving documents directly from web-based document libraries. Even after FrontPage itself was discontinued in 2006, the protocol lived on inside Office desktop apps, allowing users to enter a URL like http://server/Shared Documents/report.docx into the File Open dialog and edit the file in place.

FPRPC works by tunneling RPC calls over HTTP, often through the WebDAV extension. Under the hood, it uses the MS-FSSHTTP protocol suite. Over the years, security researchers have repeatedly flagged FPRPC as risky—it expands the Office attack surface because it processes remote data without the stricter constraints of modern authentication and transport security. Multiple CVEs have targeted Office URI handling and WebDAV-based payload delivery, making FPRPC a favorite vector for phishing campaigns. In 2023, for instance, attackers used file:// and WebDAV links to coerce NTLM hashes from unsuspecting users, leading to credential theft. Blocking FPRPC by default is Microsoft’s answer to those lingering threats.

Version 2508: The Cutoff

According to the update manifest for Microsoft 365 Apps for Windows version 2508 (build 18324.20000, released on August 26, 2025), the FPRPC block is now active out-of-the-box. Previously, Office allowed FPRPC calls to any network location; administrators could disable the protocol via Group Policy or registry tweaks, but it was never the default. With 2508, the setting BlockFPRPC is effectively flipped to 1, and any attempt to open a file through an FPRPC-dependent path throws an error like:
\"Cannot open the file. The operation can only be performed on a location in a Trusted Locations list.\"

The block covers all core Office apps: Word, Excel, PowerPoint, Access, and Publisher. Outlook and OneNote are not directly affected because they don’t use FPRPC for file attachments or notes. The change also applies retroactively to older document links—if a .docx file on a SharePoint 2010 server was set to open via FPRPC, that click now fails.

Who Feels the Pain?

The immediate impact lands on three groups:

  • Legacy SharePoint farms running on-premises versions earlier than SharePoint 2013. Those releases rely heavily on FPRPC for co-authoring and in-place editing through the client integration feature. Users get “file could not be found” or “access denied” messages when double-clicking documents in a library.
  • Organizations using WebDAV-mapped drives to access file shares or cloud storage over https://. While WebDAV itself is still supported, the path through Office’s internal handlers often triggered FPRPC as a fallback. Without it, these mapped drives become read-only from within Office, or they fail to open entirely.
  • Custom line-of-business applications that generate direct Office file-open URLs using the ms-word:ofe|u|http://... protocol. Many older inventory systems, document management tools, and ERP modules still embed such links. When Office 2508 receives that command, FPRPC is rejected, and the document stays closed.

Early reports on Windows forums indicate confusion because the error message points users to Trusted Locations—a feature many casual users have never encountered. Some IT admins are scrambling to push Group Policy overrides before the update reaches their entire fleet, while others see the block as a welcome nudge to clean up ancient dependencies.

Immediate Fix: Add Paths to Trusted Locations

Trusted Locations have been part of Office since 2007. They are folders, network shares, or URLs that Office trusts to run active content like macros and, crucially, to permit FPRPC file access. When the new block hits, the quickest remediation is to add the affected web folder path to the Trusted Locations list. Here’s how:

  1. Open any Office app (Word is fine) and go to File > Options.
  2. Click Trust Center > Trust Center Settings > Trusted Locations.
  3. Click Add new location and enter the full URL or UNC path of the FPRPC source (e.g., http://server/Shared Documents or \\server\share).
  4. Check the box “Subfolders of this location are also trusted” if the entire library hierarchy needs to be accessible.
  5. Optionally, you can restrict “Allow Trusted Locations on my network (not recommended)” — but this must stay checked for non-local paths.

This change takes effect immediately for the current user. To deploy it across an organization, use the Office Administrative Template (ADMX) files and configure the “Trusted Locations” policies under Microsoft Office 2016 > Security Settings > Trust Center. You can whitelist specific servers or entire domains using Group Policy preferences or the Office Cloud Policy Service.

For a faster registry-based rollout, add entries under:
HKEY_CURRENT_USER\\Software\\Microsoft\\Office\\16.0\\Common\\Trusted Locations\\LocationN
where N increments for each path. Each key needs a Path REG_SZ (the URL) and AllowSubfolders REG_DWORD set to 1.

Caution: Trusted Locations also weaken macro security for those paths. If the remote server could be compromised, allowing FPRPC through Trusted Locations reintroduces the very risk Microsoft is trying to mitigate. Only add servers you control and monitor.

Group Policy Override: Disable the FPRPC Block Entirely

For organizations that need more time to migrate away from FPRPC, Office 2508 still respects the older policy to disable the block. The setting is located in Group Policy at:
User Configuration > Policies > Administrative Templates > Microsoft Office 2016 > Security Settings > Trust Center > Block opening of Office documents from FrontPage Server

Set it to Disabled and the old behavior returns—Office will no longer block FPRPC. This is a blunt instrument, however, and should only be a temporary measure. Microsoft warns that future Office updates may remove the policy entirely, so IT teams should not bank on indefinite support.

A per-machine registry equivalent exists:
HKEY_CURRENT_USER\\Software\\Policies\\Microsoft\\Office\\16.0\\Common\\Security\\FprpcBlock
Create a DWORD BlockFPRPC set to 0. (Note: the absence of the key now defaults to blocked behavior; previously it defaulted to allowed.)

Long-Term Strategy: Ditch FPRPC Altogether

Microsoft’s direction is clear: FPRPC is dead. The recommended path forward depends on the scenario:

  • SharePoint On-Premises: Upgrade to SharePoint Subscription Edition (or at least 2016) and switch to the modern file handler using the Office Online Server or direct WebDAV over HTTPS with authentication. The modern document library experience uses REST APIs and the FSSHTTPB protocol, which is not affected by this block.
  • WebDAV File Access: Replace WebDAV-mounted drives with OneDrive Sync for SharePoint libraries or Azure File Shares accessed over SMB 3.0. If WebDAV must remain, ensure Office opens files via the local sync client rather than direct HTTP paths.
  • Custom Application Links: Revise URL schemes to use the ms-word:ofe|u|https://... format with the WOPI handler if connecting to an Office Web Apps server, or switch to opening from synced local copies.
  • Macros and Active Content: Eliminate any macro-dependent workflows that rely on FPRPC-delivered documents. Move to Office Add-ins or Power Automate for automation.

Microsoft has published guidance for developers to update their integrations: replace direct FPRPC calls with the Microsoft Graph API for file access, which offers granular permissions and does not require legacy protocol whitelisting.

Security Wins Behind the Scenes

Security researchers have long called for FPRPC’s retirement. The protocol’s architecture predates modern threat models—it lacks proper authentication validation, encryption enforcement, and uses a complex state machine that is rife with parsing bugs. By cutting it out by default, Microsoft eliminates several classes of attack:

  • WebDAV-based credential harvesting: Attackers send an email with a link to \\\\evil.com\\share\\doc.docx. When clicked, Windows attempts to authenticate over SMB, leaking NTLM hashes. FPRPC could be used similarly over HTTP. With the block, those links fail outright if they attempt to open through Office.
  • Office URI scheme exploits: The ms-word: protocol can feed arbitrary parameters. Without FPRPC, the attack surface shrinks because Office won’t fetch files from arbitrary HTTP servers by default.
  • Zero-day mitigations: Many recent Office RCE bugs (like the infamous “Follina” vulnerability in 2022) leveraged the diagnostic tool, but FPRPC has been a constant background risk. Blocking it reduces the chances of future sandbox escapes.

Version 2508 is part of a broader “secure by default” push. Earlier in 2025, Microsoft began disabling legacy TLS versions in Office 365, hardening Outlook against malicious links, and enforcing modern authentication for all Office apps. The FPRPC block fits that pattern—cut off outdated, high-risk functionality before it’s actively exploited in the wild.

What IT Admins Should Do Now

If you manage a fleet of Windows devices with Microsoft 365 Apps, take these steps immediately:

  1. Audit your existing file access patterns. Check SharePoint logs, network traces, or desk support tickets for file-open failures that mention “Trusted Locations.” Identify every server or web path using FPRPC.
  2. Pilot version 2508 on a test ring before broad deployment. Use Office Deployment Tool or Configuration Manager to delay the update while you validate fixes.
  3. Implement Trusted Location updates silently through Group Policy for any paths that cannot be retired in the short term.
  4. Communicate with end users who routinely open files from browser-based SharePoint links. Show them the new error message and instruct them to save the file locally if a Trusted Location hasn’t been configured.
  5. Plan a migration sprint to remove FPRPC dependencies entirely. Set a hard deadline—Microsoft may drop Group Policy overrides in the next semi-annual channel release.

Windows enthusiasts and early adopters on forums have already cataloged the specific error codes: 80004005 (general failure), 0x80030002 (invalid path), and a rarely seen 0x80070057 suggesting a parameter mismatch. These can help your service desk quickly identify FPRPC-related issues.

The Bigger Picture

This change underscores a growing divide between legacy enterprise setups and Microsoft’s cloud-first vision. Organizations that have clung to SharePoint 2010 or WebDAV as a quick-and-dirty file sharing method now face a hard stop. While the workaround is straightforward, it’s a band-aid. The real fix—embracing modern protocols—requires investment in infrastructure and user training.

For the average Windows user who opens documents from local drives or OneDrive, version 2508 is completely transparent. The drama is confined to niche but critical business systems. Security wins, however, are universal: every blocked FPRPC call is one less potential vector for ransomware or data exfiltration.

Microsoft has not published a dedicated KB article for this change, which is unusual for a potentially breaking modification. It’s bundled under the general security improvements for the August 2025 update. That silence has frustrated some admins, but it aligns with the company’s recent emphasis on progress over perpetual compatibility. The message is clear: if you still rely on FrontPage RPC, you have five months (until the next major update) to move on.

As Office continues to evolve, expect more legacy cruft to be swept away. The days of thirty-year-old protocols hanging on by a thread are numbered. For now, check your Trusted Locations list—and maybe start that SharePoint migration you’ve been putting off.