Microsoft fixes WUSA update failures that hit enterprise networks for over a year

Microsoft has closed out a known issue that quietly frustrated Windows administrators for the better part of a year. Updates released since May 2025 could fail to install when deployed through the Windows Update Standalone Installer (WUSA) from a network share holding multiple .msu files. The June 2026 Patch Tuesday cumulative updates finally resolve it across all affected systems.

If you have never had to script update deployments by hand, WUSA might be unfamiliar. It is a built-in command-line tool that installs and uninstalls Microsoft Standalone Update (.msu) packages by calling into the Windows Update Agent API. Admins lean on it to push patches, hotfixes, and out-of-band fixes across fleets where the standard Windows Update channel either isn't available or isn't trusted to act on schedule. It is plumbing, the kind of tool you only think about when it breaks.

And break it did. Devices that installed updates from May 28, 2025 (KB5058499) onward would throw ERROR_BAD_PATHNAME when an admin ran WUSA, or simply double-clicked an .msu file, from a network share containing several .msu files. Microsoft acknowledged the behavior in August 2025 and confirmed the trigger was specific: a single .msu file worked fine, and so did files stored locally. The failure surfaced only with multiple packages sitting on a remote share.

That narrow trigger explains why this stayed an enterprise problem. WUSA-from-share is not how home users get patched, so Windows 11 Home devices never felt it. The pain concentrated on Windows 11 24H2 and 25H2 and Windows Server 2025 machines on corporate networks, exactly the environments where centralized deployment shares are standard practice.

How Microsoft handled the gap

Microsoft's response came in two stages, and the timeline is worth understanding because it reflects how the company manages defects it can't fix instantly. Starting September 2025, it pushed a Known Issue Rollback (KIR) through Group Policy. KIR is a useful mechanism to know about: it lets Microsoft selectively disable a problematic code change on already-deployed systems without shipping a full new build. The catch is that the September rollback only reached home and non-managed business devices automatically. Managed enterprise systems, the ones actually using WUSA at scale, were left to apply the policy themselves or wait.

The real fix landed in the June 2026 cumulative updates: KB5079391 for Windows 11 and KB5094125 for Windows Server 2025. These address the root cause for all affected systems rather than papering over it with a rollback.

Practical advice for admins

If you manage Windows fleets, a few concrete takeaways follow from this.

First, install the June updates. KB5079391 and KB5094125 are the durable fix, and applying them retires the workaround entirely.

Second, if you are still on a pre-June build and hitting the error, Microsoft's own guidance is the simplest path: copy the .msu files to the local device and install from there instead of running them off the share. Local installation never exhibited the bug.

Third, watch out for a confusing side effect Microsoft flagged. After installing an .msu via WUSA and restarting, wait 15 minutes or more before checking the Update History page in Settings. The Settings app can briefly misreport the result, showing a success as incomplete or vice versa. Give it that delay and the status should settle correctly. This is the kind of detail that sends help desk tickets flying when an admin sees a patch they know installed listed as failed.

A pattern worth tracking

This isn't an isolated stumble. Microsoft resolved a similar problem in April 2025 that blocked enterprise customers from installing security updates through Windows Server Update Services (WSUS), and an identical defect caused August 2025 Windows 11 updates to fail with 0x80240069 errors. Earlier this week, the company also warned that the latest monthly updates may fail to install on some devices upgraded to Windows 11 24H2 or 25H2.

The common thread is the update delivery layer itself, not the payloads. For teams responsible for patch compliance, that argues for a habit more than a one-off fix: validate that your deployment mechanism actually delivered the patch, rather than assuming a green checkmark means the job is done. Pull update history through PowerShell or your management platform, confirm the build number on a sample of endpoints, and treat the deployment tool as something that can fail independently of the patch.

The broader lesson here is unglamorous but real. The hardest update problems are rarely the dramatic ones. They are the slow-burning compatibility bugs in the tools you trust to do the delivering, the ones that erode confidence in your patch pipeline a ticket at a time. Microsoft took roughly ten months from acknowledgment to full fix on this one. Keeping an eye on the Windows release health dashboard remains one of the better defenses against being surprised by the next one.