Microsoft's December 2025 Extended Security Update (ESU) rollups for Windows 10 and server systems have introduced a critical regression affecting Message Queuing (MSMQ) functionality, leaving enterprise administrators scrambling to restore business-critical messaging systems while balancing security concerns. The cumulative updates, including KB5071546 for Windows 10 21H2/22H2 ESU builds and companion KBs for server SKUs, modify NTFS permissions on the MSMQ storage folder, causing write-access failures that manifest as misleading "insufficient resources" errors and application failures.

The Scope of the Problem

According to Microsoft's official documentation, the December 2025 updates introduce changes to the MSMQ security model and NTFS permissions on the C:\Windows\System32\MSMQ\storage folder. These changes, while intended as security hardening measures, have created a situation where non-administrative service identities that previously could write to MSMQ storage no longer have the necessary permissions. This affects a wide range of enterprise scenarios, particularly those involving legacy applications and integration middleware that still rely on MSMQ for asynchronous messaging.

From the WindowsForum community discussion, administrators report immediate and severe impacts: "When MSMQ storage operations fail, the impact is immediate and often severe: queued messages are not accepted, delivery stalls, application threads time out, and downstream systems are starved of data." This isn't merely an inconvenience—for organizations running transactional pipelines, order processing systems, telemetry ingestion, or archival queues, the failure represents potential business disruption.

Technical Root Cause Analysis

The core issue stems from security hardening changes mapped to CVE-2025-62455. Microsoft's updates alter the NTFS security descriptor on MSMQ folders, including the storage subfolder. Community analysis reveals that "administrators inspecting the folder SDDL observed differences after patching that remove or break previously effective inheritance/ACE entries for low-privilege identities."

What makes this particularly problematic is how MSMQ surfaces these failures. Rather than returning explicit access-denied errors, the MSMQ APIs interpret the permission failures as resource exhaustion, leading to misleading error messages about insufficient disk space or memory. This misdirection significantly slows initial triage and troubleshooting efforts.

Affected Systems and Environments

The regression predominantly impacts environments running:

  • Windows 10 ESU builds that received KB5071546 (Windows 10 22H2 and 21H2 ESU builds)
  • Server systems updated with parallel KBs containing the same MSMQ hardening
  • Applications that write to local MSMQ queues, especially IIS-hosted applications using IIS app-pool identities (IIS_IUSRS) or built-in service accounts (LocalService, NetworkService)
  • Clustered MSMQ environments under load, where storage-file creation steps can fail across nodes
  • Legacy middleware or integration software built around MSMQ, including ERP integrations and archival queues

Community reports emphasize that "home users and systems that do not use MSMQ will typically not see any impact. However, for organizations running legacy Microsoft middleware or bespoke line-of-business apps that were never re-architected away from MSMQ, the effects can be immediate business outages."

Symptoms and Diagnostic Approach

Administrators should watch for these observable signs:

  • IIS sites returning 500-series errors with application logs containing "Insufficient resources to perform operation"
  • Applications failing to enqueue messages to local MSMQ queues
  • Event Viewer showing misleading messages about disk space or memory despite adequate resources
  • Errors during MSMQ startup such as "The message file 'C:\Windows\System32\msmq\storage*.mq' cannot be created"
  • Clustered MSMQ resources failing to come online or failing over cleanly under load

A comprehensive diagnostic checklist from community experience includes:

  1. Confirm installation of December 2025 cumulative updates (KB5071546 or relevant KB for your SKU)
  2. Inspect ACLs on C:\Windows\System32\MSMQ and C:\Windows\System32\MSMQ\storage using PowerShell's Get-Acl or File Explorer
  3. Review MSMQ service status and System/Application event logs for error messages
  4. Identify the identity expected to perform MSMQ writes (IIS app pool identity, service accounts)
  5. Isolate affected IIS app pools or services and test queue write operations under controlled contexts

Mitigation Strategies with Security Trade-offs

Administrators face three primary mitigation options, each with significant security and operational implications:

Option 1: Roll Back the Cumulative Update

This approach provides the fastest full recovery but removes all security fixes included in the update. The community warns that "uninstalling an LCU removes multiple security patches; this increases exposure and may not be acceptable in high-risk environments." The process involves:

  • Identifying the specific KB to remove (e.g., KB5071546)
  • Uninstalling through Settings > Update & Security > Windows Update > View update history > Uninstall updates
  • Alternatively using: wusa /uninstall /kb:5071546
  • Rebooting and validating MSMQ and application behavior

Option 2: Apply Targeted NTFS ACL Workaround

This operational fix grants minimal Write/Modify permissions to specific identities needing access to the MSMQ storage folder. While this restores functionality without removing security patches, it increases local attack surface. Community recommendations include:

  • Identifying exact identities needing access (IIS Application Pool identity or service accounts)
  • Testing in lab or non-production environments first
  • Using PowerShell to inspect existing ACLs: Get-Acl -Path 'C:\Windows\System32\MSMQ\storage' | Format-List
  • Applying narrowly scoped grants using icacls: icacls "C:\Windows\System32\MSMQ\storage" /grant "IIS_IUSRS:(OI)(CI)(M)"
  • Restarting MSMQ service: net stop msmq && net start msmq

Security considerations are paramount: "Grant only the exact privileges required (Modify vs Full control). Use inheritance flags carefully; avoid granting broadly to 'Everyone.'"

Option 3: Move MSMQ Storage to Non-System Volume

This structural fix involves relocating MSMQ storage to another volume where administrators can control NTFS permissions without relaxing System32 ACLs. While more secure from an ACL perspective, it's operationally invasive and requires careful planning:

  • Stopping MSMQ service on all nodes: net stop msmq
  • Copying existing storage files to target volume with proper backups
  • Reconfiguring MSMQ to use new storage path via MMC or registry
  • Starting MSMQ and validating operation and message integrity
  • Testing failover and cluster behavior if applicable

Community warnings emphasize that "mistakes during relocation can cause message loss. Take full backups. Clustered MSMQ requires coordinated changes across nodes."

Security Implications and Risk Assessment

This incident highlights the recurring tension between security hardening and backward compatibility for legacy middleware. The MSMQ hardening addresses a genuine elevation-of-privilege vulnerability (CVE-2025-62455), representing valid security priorities. However, the community analysis notes that "the ACL change has high operational impact for organizations still dependent on MSMQ. The masking of access-denied as resource errors increases time to detection and remediation."

Security implications of common mitigations include:

  • Rolling back updates removes security remediation for the CVE, potentially unacceptable in high-threat environments
  • Granting write access to non-admin accounts on System32 subfolders increases exploitation risk if attackers can impersonate or escalate to those accounts
  • Moving MSMQ storage to non-system paths is safer from an ACL perspective but requires careful operational controls to avoid data loss

Enterprise Response and Governance

For enterprise administrators, a pragmatic triage plan should include:

  1. Identifying affected systems and prioritizing by business impact
  2. Considering controlled rollback for severely impacted production systems while opening risk exceptions
  3. Implementing narrowly scoped ACL workarounds where rollback is unacceptable
  4. Performing cluster-wide mitigation tests in maintenance windows
  5. Documenting all changes and notifying security/compliance teams
  6. Maintaining timeline for reverting temporary ACL relaxations once Microsoft issues corrective patch

Communication with stakeholders is critical. As noted in community discussions: "Inform operations, application owners, and security teams immediately if you identify impacted systems. Be explicit about the trade-offs: rollback reduces security posture; ACL workarounds increase attack surface."

Testing and Validation Requirements

Before and after applying any mitigation, administrators should validate:

  • MSMQ service starts cleanly and stays online
  • Application endpoints can enqueue and dequeue messages under simulated load
  • IIS sites don't return resource errors after ACL or rollback application
  • Cluster failovers succeed and MSMQ resources come online on passive nodes
  • No unintended permission escalation or overly permissive NTFS entries were introduced

Microsoft's Response and Future Outlook

Microsoft has acknowledged the problem and added it to the Known Issues section of the KB documentation, stating: "The issue is under investigation, and additional information will be shared as soon as it becomes available." However, as of December 12, 2025, no firm timeframe for a corrective release has been provided.

The community assessment notes that "the absence of a patch ETA leaves administrators in a difficult position balancing security and availability—not an ideal place for production operations teams." This situation serves as a reminder that "long-lived middleware like MSMQ requires explicit attention during modern patching cycles—and that compatibility testing should remain an essential part of enterprise change control."

Practical Commands and Quick Reference

For administrators needing immediate guidance:

  • Check update history: wmic qfe list | findstr 5071546
  • Inspect ACL on MSMQ storage: Get-Acl -Path 'C:\Windows\System32\MSMQ\storage' | Format-List
  • Restart MSMQ: net stop msmq && net start msmq
  • Validate MSMQ service: sc query msmq
  • Check Event Viewer: Windows Logs → System/Application for MSMQ entries

Community warnings emphasize: "Do not apply any of the changes above in production without prior testing, backups, and approval from security/compliance stakeholders."

Conclusion

The December 2025 ESU rollups represent a significant challenge for organizations still dependent on MSMQ for critical business functions. While the security hardening addresses legitimate vulnerabilities, the operational impact requires careful navigation of mitigation options, each with distinct security trade-offs. Administrators must balance immediate business continuity needs against long-term security posture, documenting all changes and maintaining readiness to implement Microsoft's eventual fix when available.