Windows WUSA Update Failures: Fix Network Share Installs

admin

3 hours ago

Windows WUSA network share update checklist for Windows Server 2025, Windows 11, WSUS, Intune, reboots, and update verification

June 12, 2026 update: Microsoft now lists the Windows Update Standalone Installer issue as fixed in its support pages for Windows 11 version 24H2/25H2 and Windows Server 2025. The practical concern is simple: admins who launch .msu update files from a network share can hit ERROR_BAD_PATHNAME when that share contains multiple update files.

This is not a breach story. It is an operations issue that matters during patch windows, especially for web hosts, MSPs, schools, offices, and internal IT teams that stage Microsoft Update Catalog packages on a file share before installing them on servers or admin workstations.

Who should check this

Windows Server 2025 admins who install cumulative updates manually from a file share.
Windows 11 24H2 or 25H2 fleets where technicians double-click Microsoft Update Catalog packages from shared storage.
MSPs and hosting teams that keep offline update folders for IIS, RDS, Hyper-V, domain controller, backup, or control-panel machines.
RMM, WSUS, and Intune operators who need a clean fallback path when a manual install is needed during maintenance.

What Microsoft fixed

Microsoft’s Windows Server 2025 update page for KB5094125 says the June 9, 2026 cumulative update addresses a WUSA failure where updates can fail with ERROR_BAD_PATHNAME if you double-click an .msu file or run WUSA from a network share that contains multiple .msu files.

Microsoft’s Windows 11 KB5079391 page carries the same Windows Update Deployment known-issue fix for Windows 11 version 25H2. BleepingComputer also reported that Microsoft had fixed the network-share WUSA issue and noted that it affected Windows 11 24H2/25H2 and Windows Server 2025 enterprise environments.

Safe admin path

Use your normal update channel first. Windows Update, WSUS, Intune, Autopatch, or your RMM platform should be the default path when they are already working and monitored.
Confirm the target release. For Windows Server 2025, plan for KB5094125 or a later cumulative update. For Windows 11 24H2/25H2, check the current Windows release-health notes and the applicable KB page before staging a manual install.
Stop launching update files from a crowded share. If you must install manually, copy the required update files to a local folder on the device or use a clean local staging folder for that specific KB and architecture.
Keep update folders boring. Separate Server 2025, Windows 11 x64, Windows 11 Arm, and older update packages into clearly labeled folders so technicians do not pick the wrong file during a maintenance window.
Back up before server patching. Confirm system-state, VM, application, and file backups before touching IIS, RDS, Hyper-V, domain controller, database, backup, or management-plane machines.
Plan the reboot. Treat manual cumulative updates as a real maintenance event. Drain traffic, pause jobs, notify users, and make sure remote-console access is available before rebooting remote servers.
Verify after the reboot. Confirm the OS build, installed update history, service health, event logs, and role-specific checks before closing the ticket.

Role-specific notes

IIS and web servers: verify websites, bindings, TLS certificates, application pools, scheduled jobs, and log noise after the reboot.
RDS and jump hosts: patch during a real access window, confirm licensing and profile loading, and make sure admins are not stranded outside the management path.
Hyper-V hosts: checkpoint only when appropriate, confirm backups, drain or migrate VMs when possible, and verify guest networking after host reboot.
Domain controllers: confirm replication health and time sync, then watch authentication and DNS logs after the update.
Exposed management machines: reduce public access where possible, require MFA, and verify security tooling after the patch.

What to tell users

If your maintenance plan uses Microsoft Update Catalog packages, tell affected users that you are changing the staging process to avoid a known Windows installer failure. The fix is not exotic: use the latest cumulative update, avoid running the installer from a messy network share, reboot on purpose, and verify the build afterward.

Related Fix I.T. Phill reading

Sources

Need help planning a Windows Server maintenance window? Fix I.T. Phill can help stage updates, verify backups, coordinate reboots, and confirm IIS, RDS, Hyper-V, domain controller, and admin-machine health after patching.