MSMQ Breaks After KB5071546: Permissions Change Hits IIS Apps

Microsoft's December cumulative update for Windows 10 ESU systems, shipped as KB5071546, has introduced a breaking change to Microsoft Message Queuing (MSMQ) that is rendering queues inactive, causing IIS-hosted applications to fail with “Insufficient resources to perform operation”, and preventing applications from writing messages to MSMQ — a problem now acknowledged by Microsoft and under active investigation.

Background​

MSMQ (Microsoft Message Queuing) is a longstanding Windows feature that provides reliable, asynchronous message delivery for applications and services. It is widely used in enterprise scenarios, IIS-hosted applications, legacy integrations and clustered environments where background message delivery and transactional queuing are critical. MSMQ stores queue messages as files under the system path C:\Windows\System32\MSMQ\storage and relies on precise NTFS permissions and a stable security model to allow service accounts and application pools to read and write queue files safely.
On December 9, 2025 Microsoft released KB5071546 for Windows 10 builds 19045.6691 and 19044.6691 as part of the ESU (Extended Security Updates) channel. The package combines a servicing stack update and the latest cumulative update; it contains a security hardening change to PowerShell 5.1 and a set of additional fixes ported from November updates. Within days of distribution, system administrators began reporting widespread MSMQ failures on patched systems. Microsoft added a known-issue notice to the KB article confirming MSMQ functionality can be affected and that the problem stems from recent changes to the MSMQ security model and NTFS permissions on the storage folder.

---

What broke: observable symptoms and immediate impact​

After applying KB5071546, administrators and application owners are seeing consistent, reproducible MSMQ-related failures in affected environments. The most commonly reported symptoms include:

• MSMQ queues becoming inactive and refusing to accept new messages.
• IIS sites and applications failing with “Insufficient resources to perform operation” errors when attempting MSMQ operations.
• Applications unable to write to queues; calls to MSMQ APIs fail with resource or I/O-like errors.
• Errors logged indicating the system cannot create message files, for example: “The message file 'C:\Windows\System32\msmq\storage*.mq' cannot be created.”
• Misleading diagnostic log messages such as “There is insufficient disk space or memory” even when disk and memory are abundant.

These failures have been reported across single-server and clustered MSMQ deployments and tend to surface under load or in environments where multiple services (IIS app pools, LocalService/NetworkService, custom service accounts) interact with MSMQ. The broken behavior is not limited to a single vendor or application; any code path that relies on MSMQ to send or persist messages can be affected.

---

Root cause — what Microsoft changed​

Microsoft’s public problem description indicates the issue arose after changes to the MSMQ security model and NTFS permissions on the local storage path at C:\Windows\System32\MSMQ\storage. After the update, MSMQ users — effectively the service accounts and non-admin identities that previously wrote to the storage folder — now require explicit write access to that folder. Historically, that path was restricted to administrative accounts, with MSMQ relying on internal privilege elevation or specific ACLs to permit operation. The update appears to have altered the DACL (discretionary access control list) or the security descriptor in a way that removes or breaks the previous implicit or inheritable rights for non-administrative accounts such as IIS_IUSRS, NetworkService, LocalService, or custom service accounts.
Technically, affected administrators have observed differences in the SDDL (Security Descriptor Definition Language) representation of the folder permissions after patching: an Auto-Inherited (AI) flag and modified ACEs that lead to loss of write access by the identities that previously operated correctly. When the process attempting to create or extend the memory-mapped MSMQ message files (the .mq files in storage) cannot obtain write permission, the MSMQ API surfaces resource-like errors even though the underlying cause is a denied NTFS write operation. In other words, the error messages are symptomatic and somewhat misleading: they indicate resource exhaustion while the true root is permission-denied on the message file creation.

---

Who is affected​

The issue is primarily observable on Windows 10 systems receiving KB5071546 (ESU builds 19045.6691 / 19044.6691), but the underlying change touches components that are also present in server-class environments and in older Windows builds that received similar hardening patches. Environments at higher risk include:

• IIS-hosted applications that send messages to local MSMQ queues (common in legacy web apps and integration services).
• Services running under low-privilege built-in accounts (NetworkService, LocalService) or under the IIS_IUSRS group.
• Clustered MSMQ deployments under load; clustering increases the chance of encountering the permission checks and file-creation race conditions.
• Enterprise systems relying on MSMQ for asynchronous, durable messaging — financial systems, archival workflows, queued processing pipelines.

Systems that do not use MSMQ, or have MSMQ disabled/removed, are not affected by this particular problem.

---

Why the logs look misleading​

MSMQ uses memory-mapped files and internal quotas to manage message storage. When a write operation fails at the file system level, the MSMQ stack reports resource-related errors because it cannot allocate or grow the necessary storage space. Those error messages — “Insufficient resources to perform operation” or “There is insufficient disk space or memory” — are accurate in the sense that MSMQ's storage operations failed, but they are misleading because they steer responders toward capacity troubleshooting instead of permissions. This mismatch between symptom and cause increases time to remediation and risks misdiagnosis (for example, administrators clearing disk space unnecessarily).

---

Confirmations and corroboration​

Microsoft updated the KB article for KB5071546 to include a known issue entry describing MSMQ failures and explicitly mentioning the permission changes to C:\Windows\System32\MSMQ\storage and the requirement for MSMQ users to have write access to that folder. Community and support channels (including Microsoft’s own Q&A forums) contain corroborating reports from administrators who observed the DACL changes and resolved the symptoms by rolling back the update.
Independent security trackers and industry outlets have catalogued the update, its CVE context (a related MSMQ privilege-elevation CVE appearing in the December advisory set), and community reports of application breakages post-installation. The problem has been observed widely enough to trigger vendor and forum threads and to prompt Microsoft to publicly acknowledge an investigation.

---

Short-term mitigation and recommended operational steps​

Microsoft’s official guidance at the time of acknowledgment was limited to investigation and monitoring; there is no universally sanctioned fix published yet. However, administrators managing MSMQ-dependent systems should consider the following pragmatic, risk-aware steps while awaiting an official patch:

• Immediately monitor MSMQ-dependent services and IIS sites. Prioritize alerts for “Insufficient resources” MSMQ errors and JMS/queue delivery failures. Early detection reduces business impact.
• If the update has been installed in a production environment and critical services are failing, consider systematic rollback of KB5071546 on impacted machines — but proceed with caution. Because the package may be delivered as a combined SSU + LCU, uninstall mechanics are non-trivial: wusa.exe /uninstall will often not work; removal of the LCU component may require DISM /Online /Remove-Package with the exact package identity. Test removal in a staging environment first and verify restore of service.
• As a temporary workaround for systems where rollback is not immediately feasible, consider carefully controlled NTFS ACL adjustments on the MSMQ storage path:
• Identify the service identities that require write access (IIS app pool identity, IIS_IUSRS, NetworkService, LocalService, custom service accounts).
• Grant least-privilege Write and Modify rights to those specific accounts on C:\Windows\System32\MSMQ\storage — not broad Full Control for Everyone.
• Apply permissions only to the targeted subfolder(s) and avoid recursive permissions that affect unrelated system files.
• After modifying permissions, restart the MSMQ service and validate queue operations under load.
• Document the change and plan to revert permissions to the more secure baseline once an official patch is issued.
• Another operational alternative is to move MSMQ storage to a non-system volume where permissions can be controlled without affecting system folders. This requires downtime and careful steps:
• Take MSMQ offline (stop the service).
• Copy the storage files to the new location, or configure MSMQ Storage paths via the Message Queuing MMC (Storage tab) or the registry.
• Restart the MSMQ service and validate behavior.
  Note: moving storage is invasive and can risk message loss if not done properly; proceed only after backups and in maintenance windows.
• For clustered MSMQ environments, apply mitigation steps cluster-wide and test failover scenarios. Permission-related failures can prevent resources from coming online during cluster transitions.

Important caution: modifying NTFS permissions on system folders like C:\Windows\System32 carries security implications. Granting write access to non-administrative groups increases the attack surface and may violate organizational hardening policies. Any permission changes must be tightly scoped, logged, and scheduled for reversal once Microsoft delivers a fix.

---

How to rollback safely (practical guidance)​

If rollback is the chosen path, follow these best-practice steps:

• Identify the package identity: Use DISM /Online /Get-Packages to list installed package names and find the KB5071546 LCU package identity.
• Test in a controlled environment: Don’t attempt removal on mission-critical servers without testing in a lab or staging cluster. Confirm that rollback restores MSMQ behavior and does not introduce other regressions.
• Use DISM to remove the LCU: When the package is a combined SSU+LCU, DISM /Online /Remove-Package /PackageNameackage_Identity is the supported approach to remove the LCU portion.
• Reboot and validate: After removal, reboot and test MSMQ message operations, cluster failover, and IIS app pools that depend on queueing.
• Keep security posture in mind: Reverting to pre-patch state may reintroduce the security hardening the update intended to address. Assess risk trade-offs, and prioritize installation of a future corrected update once available.

Note: some cumulative updates include a servicing stack component that cannot be uninstalled. That’s why test validation is essential before wide rollbacks.

---

Risks of inaction and risk of hasty remediation​

• Risk of inaction: Critical applications that depend on MSMQ will remain degraded or nonfunctional, leading to business impact — from failed background processing to halted workflows and customer-facing outages.
• Risk of hasty remediation: Improperly broadening NTFS rights on system folders or incorrectly moving storage files can create security vulnerabilities, data corruption, or message loss. Uninstalling updates without testing may also leave systems vulnerable to the security issues the update intended to fix.

Administrators must weigh immediate service availability against long-term security posture and follow change-control processes for any permissions or update removals.

---

Long-term considerations and engineering analysis​

From a systems-engineering and security perspective, the incident highlights competing priorities in modern OS servicing: hardening and principle-of-least-privilege must coexist with long-standing backward compatibility and operational assumptions in enterprise ecosystems.

• Compatibility vs hardening: MSMQ is used by legacy and modern apps alike. Changes that tighten security descriptors in system folders can have unintended side effects if application patterns depend on permissive or inherited permissions. This is a classic compatibility hazard when hardening mechanisms touch widely shared system paths.
• Opaque error messages: The MSMQ error model surfaces resource-like messages when the underlying cause is permissions. Improving diagnostic clarity would reduce mean time to resolution in support scenarios.
• Packaging and rollback complexity: Combined SSU+LCU packaging complicates rollback. Administrators must be familiar with DISM workflows and have tested rollback procedures as part of incident response planning.
• Operational hygiene: Organizations that explicitly run MSMQ workloads should maintain runbooks that document service accounts, ACLs, storage locations, and cluster procedures. Regular permission audits and staged updates (apply to test, pilot, then production rings) reduce blast radius.

---

Recommended checklist for administrators (actionable)​

• Inventory servers that run MSMQ and identify dependent applications and IIS sites.
• Confirm which systems have KB5071546 applied (check Windows Update history, wmic qfe, or DISM package lists).
• Monitor Application and System event logs for MSMQ-related Event IDs and “Insufficient resources” messages.
• If impacted, escalate to follow your incident-response process; consider patch rollback for critical services with a staged, tested approach.
• If rollbacks are impractical, apply carefully scoped NTFS permissions to the MSMQ storage folder for the required service identities; document and schedule reversal post-fix.
• For clustered setups, coordinate changes across nodes and validate failover behavior.
• Keep systems isolated from untrusted networks and maintain backups of MSMQ storage and LQS configuration files before any remediation that affects storage contents.
• Subscribe to official Microsoft update health and advisory feeds and sign up for vendor notifications for your mission-critical applications.

---

What to expect next​

Microsoft has stated the issue is under investigation and that it will share more information when available. Given the scope — a security-related servicing change that affects a critical legacy subsystem — the expected course is:

• An interim guidance or formal workaround may be published (for example: a documented ACL adjustment, a supported procedure to move storage, or an updated package with the corrected security descriptor).
• A corrected cumulative update or supplemental package will likely be released in a follow-on servicing wave once engineering completes validation.
• Security advisories related to MSMQ (including the associated CVE in the December advisory set) may be updated with mitigations that balance privilege hardening with operational compatibility.

Administrators should plan for a two-stage response: immediate mitigation to restore service where necessary, and a follow-up plan to install the corrected Microsoft update and revert any temporary permissions changes.

---

Conclusion​

The KB5071546 update introduced a permissions-driven regression in MSMQ that breaks queue operations for many real-world workloads. The issue underscores the tension between security hardening and compatibility and demonstrates why staged deployment and robust rollback/runbook procedures remain essential for enterprise patch management. While Microsoft investigates and prepares a fix, administrators must triage impact, apply monitored mitigations that preserve security, and prioritize the restoration of critical messaging flows with minimal risk to data integrity and system security.

---

Source: Windows Report Microsoft: Windows 10 December Patch Breaks MSMQ, Causing App and IIS Sites Failures