MSMQ Out of Band Patch Restores Message Queuing After December ACL Regression

Microsoft has quietly shipped an out‑of‑band update to undo a December security hardening that left Microsoft Message Queuing (MSMQ) unable to write its on‑disk message files on many enterprise systems, restoring queue functionality after a week of outages, confusing logs, and emergency rollbacks and workarounds for administrators.

Background​

Microsoft Message Queuing (MSMQ) is a decades‑old Windows component that persists messages on disk to provide durable, asynchronous communication between applications. Because it stores messages as files beneath C:\Windows\System32\MSMQ\storage, MSMQ’s availability is tightly coupled to NTFS permissions and the effective rights of the service identities that perform writes (IIS app‑pool identities, LocalService, NetworkService, or named service accounts). The December 2025 cumulative updates included a security hardening that changed how the MSMQ storage folder’s security descriptor and ACL inheritance were applied, which in turn removed effective write access for many non‑administrative service identities and caused message writes to fail. Microsoft first shipped the December cumulative updates on December 9, 2025. By December 12 the vendor had added a “known issue” entry to the affected KB articles after administrators began reporting queues showing as “inactive,” System.Messaging exceptions in IIS, and event logs claiming the message file could not be created — often accompanied by misleading “There is insufficient disk space or memory” messages despite ample system resources. Microsoft then released catalog‑only out‑of‑band (OOB) cumulative packages on December 18 that restore MSMQ behavior for the affected SKUs.

---

What changed, in technical terms​

NTFS ACL regeneration and the Auto‑Inherited flag​

The December patches regenerated or hardened the security descriptor (SDDL) on the MSMQ storage folder and introduced changes to ACE inheritance semantics, including an Auto‑Inherited (AI) marker in the SDDL. That altered the effective DACL such that accounts that previously relied on implicit or inherited write rights lost the ability to create and append .mq files. Because MSMQ maps these low‑level file creation failures into resource errors, administrators were presented with misleading diagnostics — prompting investigations into disk or memory before permissions were checked.

Why MSMQ reported the wrong error​

MSMQ’s internal error handling converts a failed file create/append call into a generic resource exhaustion error rather than an Access Denied result. That translation is the key reason the failure mode was opaque: systems with healthy CPU, RAM, and free disk still failed to enqueue messages because the process identity could not write to the storage folder. The symptoms therefore looked like resource starvation rather than an ACL regression. Practical reproductions in community threads and Microsoft Q&A confirmed the pattern.

---

Timeline — how events unfolded​

• December 9, 2025: Microsoft released the regular December cumulative updates (LCUs) across Windows 10 ESU and server branches; the changes that triggered the regression were included here.
• December 10–12, 2025: Administrators began reporting MSMQ outages, IIS errors, and misleading event log messages; community triage identified altered SDDL and missing effective write ACEs as likely causes.
• December 12, 2025: Microsoft updated the December KB pages to add a Message Queuing (MSMQ) known‑issue note and advised customers to engage support for mitigations.
• December 18, 2025: Microsoft published out‑of‑band cumulative updates (catalog packages) that explicitly fix the MSMQ regression (for example, KB5074976 for Windows 10 ESU builds and corresponding KB5074974/KB5074975/KB5074978 for server SKUs). These were made available via the Microsoft Update Catalog and in the release‑health pages as resolved on that date.

This narrow window — a few days between reports and a fix — is rapid by enterprise update standards, but the disruption and the need for manual catalog installs and workarounds amplified operational pain for many shops.

---

Who was affected​

• Primary impact: Enterprise and managed IT environments that run MSMQ (line‑of‑business apps, integration middleware, IIS‑hosted services, clustered MSMQ nodes).
• Less likely to be affected: Consumer Windows Home/Pro machines where MSMQ is typically not installed. Microsoft explicitly stated Home/Pro end users are “very unlikely” to encounter the issue.
• Affected SKUs: Windows 10 ESU builds (22H2, 21H2, 1809, 1607) and Windows Server families (Server 2019, Server 2016, Server 2012 R2, Server 2012) — the December KBs for these products were updated to document the MSMQ known issue and later the resolution.

The pattern of affected systems mapped cleanly to environments where on‑prem MSMQ is used in production workloads, particularly those with non‑admin service identities running under least‑privilege constraints.

---

Symptoms administrators reported​

• MSMQ queues suddenly showing as inactive and refusing new messages.
• IIS‑hosted applications throwing System.Messaging.MessageQueueException with “Insufficient resources to perform operation.”
• Event log entries stating “The message file 'C:\Windows\System32\MSMQ\storage*.mq' cannot be created.”
• Misleading logs about disk or memory exhaustion despite available resources.

These reproducible fingerprints made the problem both severe and curious: the service layer reported resource problems while the true root cause was file system access control.

---

What Microsoft released to fix it​

Microsoft’s remediation approach was to bundle the MSMQ correction into SKU‑specific out‑of‑band cumulative updates and publish them to the Microsoft Update Catalog on December 18, 2025. For example:

• KB5074976 — Windows 10 (OS builds 19044.6693 / 19045.6693) OOB update that includes the MSMQ fix.
• KB5074974 — Windows Server 2016 / Windows 10 Enterprise LTSB 2016 OOB fix.
• KB5074975 — Windows Server 2019 OOB fix.
• KB5074978 — Windows Server 2012 R2 OOB rollup addressing the same issue.

Microsoft’s release notes explicitly state that the OOB packages restore the correct MSMQ behavior and that prior December updates (for example KB5071546) were the origin of the regression. The vendor also noted that these OOB fixes are catalog‑only and advised administrators to install the latest update from the Catalog or obtain it via WSUS/ConfigMgr import.

---

Practical remediation runbook for administrators​

The operational response falls into immediate triage, short‑term remediation, and validation.

Immediate triage checklist​

• Confirm where MSMQ is installed: use Get‑WindowsOptionalFeature / DISM or Get‑WindowsFeature on servers to enumerate MSMQ presence.
• Check installed updates: identify KB5071546/K B5071544/K B5071543 in update history or with DISM /online /Get‑Packages.
• Look for fingerprinted errors: Event Viewer entries about storage*.mq creation failures and System.Messaging exceptions.
• Reproduce a controlled enqueue as the identity your application uses to confirm whether writes fail with Access Denied (or the misleading resource error).

Short‑term remediation options​

• Option A — Apply Microsoft’s out‑of‑band update (recommended): Download the appropriate OOB package from the Microsoft Update Catalog (KB5074976 / KB5074974 / KB5074975 / KB5074978) and deploy through your patch management pipeline after standard testing. These updates include the December fixes plus the MSMQ remediation.
• Option B — Roll back the December LCU (temporary): If a rapid catalog deployment isn’t possible, you can uninstall the December cumulative update to restore previous behavior. Note this removes the security fixes that shipped with the LCU — evaluate risk vs. availability carefully. Use DISM or wusa /uninstall for package removal.
• Option C — Narrowly scoped ACL workaround (emergency only): Grant explicit write/modify permissions to the specific service identity (e.g., NETWORK SERVICE, the IIS app‑pool identity) on C:\Windows\System32\MSMQ\storage to restore enqueue ability. This should be treated as a temporary mitigation because it relaxes the hardening intent of the December update. Log and audit any ACL change and remove it after installing Microsoft’s OOB update. Example PowerShell approach is widely shared in community guidance but must be tailored to your principal names.

Validation and monitoring​

• After remediation, validate by sending test messages under real service identities and exercising production workloads at load.
• Monitor Event Viewer for storage*.mq creation errors and custom application metrics for queue throughput and error rates.
• Ensure the update/rollback state is consistent across clusters to avoid mixed states that complicate failover behavior.

---

Analysis: what this incident reveals about Microsoft’s validation practices​

Strengths in response​

• Microsoft acknowledged the regression and published a known‑issue entry within days of the first public reports, providing administrators with an official symptom list and a vendor‑level explanation of the root cause.
• The company produced a targeted remediation within nine days of the initial December 9 rollouts — a reasonably fast turnaround for a security‑sensitive regression that spans multiple SKUs. The fixes were packaged as cumulative master updates that avoid piecemeal hotfixes.

Shortcomings and risk vectors​

• The December change was a low‑level ACL/regeneration action that affected legacy operational assumptions. That kind of change needs extensive compatibility testing across a wide range of service identity patterns and enterprise deployment models. The regression shows gaps in that coverage.
• Distribution model friction: the initial catalog‑only delivery of OOB packages increased operational friction. Administrators who rely on automated pipelines (Windows Update, WSUS automatic approvals) had to import and stage catalog packages manually, which slowed remediation in some environments.
• Diagnostics mismatch: MSMQ’s internal mapping of filesystem access denials to resource errors obscured the root cause and prolonged triage. While the incorrect mapping is an MSMQ implementation detail, patch validation should include checking that error messaging remains actionable after code or security‑descriptor changes.

The human cost​

Operational teams reported major incidents in finance, healthcare, retail, and logistics where MSMQ is still used for transactional pipelines. Customer‑facing outages and service interruptions forced emergency patch rollbacks or temporary ACL relaxations — both costly choices that increased exposure or removed security fixes. The swift fix limited the window of disruption, but the episode extracted real time and reputation costs from affected organizations.

---

Longer‑term implications and recommended actions​

For enterprises​

• Inventory legacy dependencies: Maintain a clear inventory of servers and applications that rely on MSMQ (and similar legacy Windows components). That inventory should include the service account principals, cluster topologies, and failover characteristics.
• Harden patch validation: Expand patch test matrices to include non‑administrative service identities, IIS app‑pool security contexts, and clustered I/O under load. Automated integration tests that exercise permission‑sensitive file writes will catch regressions like this early.
• Use least‑privilege intentionally: Where possible, move from implicit/inherited privileges to explicit, documented ACLs that are codified in infrastructure‑as‑code repositories. That makes permission changes auditable and reproducible.

For Microsoft and vendors​

• Expand compatibility testing to real‑world identity patterns: Changes that touch system DACLs and SDDL must be tested against typical service identities used by enterprise apps. Unit tests are insufficient; simulated production workloads are necessary.
• Improve error transparency: When the system maps underlying error codes to generic messages, make sure the mapping is comprehensible to administrators. A clear “Access Denied writing MSMQ storage” would have saved hours for many teams.
• Consider broader distribution channels for critical fixes: Catalog‑only delivery minimizes collateral risk but creates deployment friction; Microsoft should balance targeted distribution with availability for automated patch workflows or supply configurable channels for business customers.

---

Cross‑checking facts — verification summary​

The core facts and timeline in this report are corroborated by Microsoft’s release‑health pages and individual KB entries that document the December 9, 2025 LCU, the December 12 known‑issue additions, and the December 18 out‑of‑band patches that resolved MSMQ behavior. Independent reporting and community threads reproduced the symptom set and confirmed the OOB fixes: industry outlets and community sources documented the same errors, the NTFS SDDL diffs, and the operational mitigations administrators used while waiting for vendor remediation. Those independent confirmations align with Microsoft’s own notes.
Where vendor documentation or community posts claim specific KB numbers for server SKUs (for example KB5074974, KB5074975, KB5074978), Microsoft’s KB pages for those OOB packages list the MSMQ resolution on the December 18 updates for Server 2016/2019/2012 R2 respectively, confirming the mapping. These server KBs appear in Microsoft’s support catalog. If any claim remains primarily anecdotal (for instance, precise timelines for internal Microsoft testing or how a particular enterprise discovered the issue), that is flagged as field reporting rather than vendor‑verified fact; the vendor timeline and KB entries are the authoritative record for the change and the remediation dates.

---

Final assessment​

The December MSMQ regression was a meaningful outage vector for enterprises that still rely on this legacy messaging layer. Microsoft’s security intent — hardening MSMQ — is defensible, particularly where elevation‑of‑privilege fixes are in scope. However, the compatibility fallout underscores two immutable truths in enterprise software maintenance:

• Changes that touch system ACLs and inheritance semantics must be validated against a wide set of real‑world service identity patterns and cluster scenarios.
• Diagnostic fidelity matters — when an access denial is logged as a resource exhaustion problem, incident response time multiplies.

Microsoft ultimately fixed the issue with out‑of‑band updates across client and server SKUs in under two weeks, which is a solid operational recovery. That response, however, does not erase the disruption and risk enterprises experienced while triaging, rolling back, or temporarily loosening ACLs. The incident is a reminder for both vendors and operators: modern patch management must include robust compatibility validation and rapid, low‑friction delivery mechanisms for urgent fixes to avoid preventable downtime in critical systems.

---

Quick action checklist (for posting to an operations runbook)​

• Identify systems with MSMQ installed and list the service identities that write to queues.
• Check whether the December 2025 LCUs (KB5071546 / KB5071544 / KB5071543 / KB5071505) are installed.
• If impacted, prioritize installation of the corresponding OOB update from the Microsoft Update Catalog (KB5074976 / KB5074974 / KB5074975 / KB5074978).
• If OOB deployment is not immediately feasible, roll back the December LCU or temporarily apply a scoped ACL change only to the explicitly required service principals — and schedule the vendor fix as soon as possible.
• Validate by exercising message producers and monitoring Event Viewer and application logs for continued storage*.mq creation failures.

This incident will likely be cited as an example in future patch‑validation discussions: a security hardening that made operational assumptions explicit — intentionally — but without a robust compatibility safety net, which led to real‑world outages for organizations running legacy but mission‑critical middleware. The correct path forward for administrators is pragmatic: remediate quickly with Microsoft’s OOB updates, validate queue behavior under load, and then harden and document service‑account ACLs so the next security update does not produce a repeat outage.

---

---

Source: theregister.com Microsoft fixes Message Queuing issue in new update