Administrators relying on Windows Server Update Services (WSUS) on Windows Server 2025 to deliver Extended Security Updates (ESU) to ancient Windows Server 2012 and 2012 R2 machines got an unwelcome surprise with Microsoft’s September 2025 security patch: the update strips out legacy binaries that WSUS needs to service those outdated endpoints, breaking the update pipeline. The change, documented in support article KB5067349 and distributed via Microsoft’s Message Center, is part of a broader hardening push—but for organizations still nursing end-of-life servers on life support, it means patching just got harder.

What changed in September 2025

Starting with the September 2025 security update for Windows Server 2025, WSUS no longer includes the DLLs and EXEs historically used to update or service the Windows Update SelfUpdate component on endpoints. These binaries were pinpointed as dependencies that no longer meet Microsoft’s compliance and security standards, and their removal from the in-market server role is permanent. As a direct consequence, a fully‑patched WSUS instance running on Server 2025 will, by default, fail to distribute ESU updates to Windows Server 2012 and 2012 R2 clients that depend on those SelfUpdate artifacts.

Microsoft has been transparent about the trade-off: the security benefit of eliminating outdated code from the software supply chain is weighed against the operational impact for a shrinking pool of legacy systems. The company stated, “Removing certain binaries from WSUS helps ensure the integrity and security of our software supply chain. This specifically applies to dependencies on components that no longer meet our compliance and security standards.”

Crucially, the update does not affect in‑market, supported operating systems such as Windows 10 (supported branches), Windows 11, or Windows Server 2016/2019/2022. It only disrupts the patch flow for out‑of‑support OS versions that are receiving ESU content.

Why Microsoft pulled the plug

The SelfUpdate component is a relic from earlier Windows era, designed to update the Windows Update agent itself on endpoints. Over the past 18 months, Microsoft has accelerated a sweeping hardening program across Windows and Windows Server that removes compatibility fallbacks, tightens cryptographic requirements, and prunes components considered legacy or non‑compliant. Removing old binaries reduces attack surface, eliminates code paths that could be exploited, and aligns WSUS on Server 2025 with the same security baseline as other modern services. This is consistent with other recent moves—deprecating NTLM, enforcing stronger TLS, and disabling weak Kerberos mappings—all aimed at secure defaults.

For organizations, this means accepting that the days of indefinite backward compatibility are over. The message is clear: migrate off Windows Server 2012/2012 R2 or isolate them, because the update infrastructure itself is evolving past their needs.

Who is affected—and who isn’t

Affected: Any environment where WSUS on Windows Server 2025 (with September 2025 or later updates installed) is the sole update source for ESU-eligible Windows Server 2012 or 2012 R2 machines. These endpoints will stop receiving patches until one of the mitigations below is applied.

Not affected:
- Systems running in‑market Windows versions (Windows 10 22H2, Windows 11, Windows Server 2016–2022).
- Hierarchical WSUS deployments in which an upstream or downstream server still retains an older WSUS build with the SelfUpdate components. In such topologies, “synchronization and update distribution will continue to function as expected,” according to Microsoft’s support article.

The temporary workaround: copy SelfUpdate, create a virtual directory

Microsoft documented a short‑term fix in the same support article. It essentially reintroduces the missing SelfUpdate folder by borrowing it from a WSUS instance that hasn’t been hardened. The company explicitly frames this as an emergency measure, not a permanent solution.

Step‑by‑step restoration

  1. Identify a donor WSUS server. Choose either a Windows Server 2025 machine that has not received the September 2025 update, or a WSUS instance running on Windows Server 2022 (or older, supported version).
  2. On the donor server, navigate to %systemdrive%\Program Files\Update Services\SelfUpdate. Copy the entire folder—preserving NTFS permissions if possible—to a secure transfer location.
  3. On the recipient (patched) Windows Server 2025 WSUS host, stop the WSUS application pool or IIS, then place the copied SelfUpdate folder under the WSUS installation path (typically C:\Program Files\Update Services\SelfUpdate).
  4. Verify NTFS permissions: the NETWORK SERVICE, IIS_IUSRS, and the WSUS application pool identity (e.g., IIS APPPOOL\WsusPool) need read access to the folder.
  5. Open Internet Information Services (IIS) Manager, navigate to the WSUS Administration website, and add a new virtual directory named SelfUpdate that points to the copied folder.
  6. Restart IIS (or recycle the WsusPool), then run a test synchronization and approval with a small pilot group of ESU clients to confirm successful delivery.
  7. Monitor logs: check WSUS application logs, Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient, and IIS logs for any 404 or 500 errors on SelfUpdate paths.

This workaround restores ESU delivery, but it comes with significant strings attached.

Risks and trade-offs of the fix

Reintroducing legacy binaries onto a modern server undermines the very security posture Microsoft is trying to enforce. The copied SelfUpdate code is exactly the supply‑chain artifact that was removed for being non‑compliant; it may contain unpatched vulnerabilities, lack modern exploit mitigations, and complicate compliance audits. Administrators must treat this as a stop‑gap, not a long‑term strategy.

There are also operational risks. WSUS and IIS configurations are notoriously fragile. Misapplying permissions, missing a virtual directory, or using an incorrect application pool identity can cause widespread failures—not just for ESU clients, but for all update services. The community strongly recommends testing in a lab or staging ring, backing up the WSUS registry keys (HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup), IIS configuration (using appcmd add backup), and the WSUS database before making any changes.

If you do implement the workaround, couple it with compensating controls: isolate the WSUS server behind a firewall, restrict administrative access, enable aggressive monitoring, and set a firm sunset date for removal. Every day the legacy binaries stay in place increases risk.

Long‑term solutions: migrate or modernize

The only defensible permanent fix is to decommission Windows Server 2012 and 2012 R2 altogether. Extended Security Updates are a paid, last‑resort program that Microsoft offers through 2026, but they are not a substitute for a supported operating system. Organizations should prioritize in‑place upgrades where feasible or provision new servers and migrate workloads. Domain controllers, internet‑facing services, and critical infrastructure should be at the top of the list.

If immediate migration isn’t possible, a hierarchical WSUS architecture can buy time. By keeping at least one downstream or upstream WSUS server on an older build (e.g., Windows Server 2022), you preserve the SelfUpdate components and maintain update flow while executing larger migration projects. This approach avoids the need to copy binaries manually and reduces the security exposure to that one legacy node.

Looking ahead, Microsoft’s strategic direction is clear: WSUS is deprecated in favor of cloud‑native update management. The support article explicitly nudges customers toward Windows Autopatch, Microsoft Intune, and Azure Update Manager. These tools reduce on‑premises maintenance, align with modern security practices, and avoid the kind of legacy‑code dependency that caused the current situation. For air‑gapped or highly regulated environments where cloud migration isn’t viable, strongly consider isolated update points with rigorous network segmentation, jump‑box management, and comprehensive logging.

Operational checklist for administrators

Reacting to this change requires methodical planning. Use the following checklist to get your environment under control:

  • Inventory all WSUS servers and their OS build levels. Confirm which have received the September 2025 update. Identify every endpoint still running Windows Server 2012/2012 R2 and verify its ESU eligibility and purchase status.
  • Map the topology. Document any hierarchical WSUS relationships. If a downstream server retains the SelfUpdate content, you may not need the temporary workaround.
  • Test before production. Establish a pilot ring for any change—whether the SelfUpdate copy or a new WSUS hierarchy—and validate against a representative set of ESU endpoints. Monitor for failures and unexpected behavior.
  • Secure the workaround. If you must restore the SelfUpdate folder, restrict network and user access to the WSUS server, apply least‑privilege permissions, and set up alerts for abnormal SelfUpdate traffic.
  • Backup everything. Use wsusutil.exe postinstall with verbose logging to capture errors, back up the IIS configuration via appcmd, and export the WSUS registry keys. Have a rollback plan.
  • Plan the migration. Start scheduling upgrades for legacy servers immediately. Even if the workaround holds, the clock is ticking on ESU support, and the next hardening change could be more disruptive.

What this tells us about Microsoft’s direction

The WSUS hardening in Windows Server 2025 is not an isolated event—it’s part of a larger pattern of retiring legacy components that have lingered too long. Microsoft’s commitment to supply‑chain security means that code paths serving only end‑of‑life products will increasingly be removed, even if that creates short‑term pain. The company is banking on the fact that most enterprises are either already on modern platforms or have clear migration roadmaps.

For IT teams caught off guard, the immediate priority is triage: restore patching using the provided workaround, but only after rigorous testing and with full awareness of the security trade‑offs. Then, pivot quickly to long‑term modernization. The alternative—indefinitely maintaining patched‑together update infrastructures on aging OS versions—is neither secure nor sustainable.

As one community note put it: “Implement the short‑term mitigation only with rigorous controls and a clear sunset date; your security posture and auditors will thank you for migrating legacy workloads rather than indefinitely extending their life on patched systems that intentionally removed the very binaries needed to keep them current.”