MSMQ / IIS – Access issues with C:\Windows\System32\msmq after December Update (Windows Server 2019)

Question

Description:
Since installing KB5071544 (December 2025 Update), IIS applications (IIS_IUSRS) as well as services running under LocalService / NetworkService can no longer write to the folder C:\Windows\System32\msmq. As a result, MSMQ-based applications fail. Everything worked flawlessly before the update. Rolling back the update immediately resolves the issue.

Analysis: The NTFS security descriptor of the MSMQ folder is modified by the December update.

SDDL comparison:

Unpatched: D:P(...)

Patched: D:PAI(...)

The additional AI flag (Auto-Inherited) indicates that the update is regenerating or altering the DACL. The Windows GUI does not display this difference, but functionally the services lose the access rights they previously had.

Impact:

Applications running under IIS_IUSRS / LocalService / NetworkService can no longer write to MSMQ.

• Services must be changed to LocalSystem or given manual NTFS permissions → unacceptable from a security perspective, and it appears that permissions we set manually under C:\Windows\System32\msmq are not persistent and get automatically reverted to defaults.
• The issue is reproducible on multiple systems, and similar reports are appearing on Reddit.
  See: https://www.reddit.com/r/sysadmin/comments/1phyxbt/comment/ntanh4l/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Request to Microsoft:

• Confirmation whether the December update modifies MSMQ ACLs / security descriptors
• Clarification whether this behavior is intentional or a bug
• A fix or guidance on how to restore the original permissions

Answer 1

Hi there,

Update (December 18, 2025): This issue has now been RESOLVED by Microsoft

This issue has been officially acknowledged and patched by Microsoft! You can track it here: https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-22h2#message-queuing--msmq--might-fail-with-the-december-2025-windows-security-update

What happened:

Microsoft confirmed that the December 2025 security update (KB5071546) introduced changes to the MSMQ security model and NTFS permissions on the C:\Windows\System32\MSMQ\storage folder. MSMQ users now require write access to this folder, which is normally restricted to administrators. This caused the "Insufficient resources to perform operation" errors you were experiencing.

The symptoms matched what you were seeing:

• MSMQ queues becoming inactive
• IIS sites failing with resource errors
• Applications unable to write to queues
• Message file creation failures
• Misleading logs about insufficient disk space/memory

Resolution:

This issue was resolved by the Windows out-of-band update released December 18, 2025 (KB5074976), which is available via the Microsoft Update Catalog.

Action Required:

Install the latest update (KB5074976) for your device. You can download it from the Microsoft Update Catalog.

Affected versions:

• Client: Windows 10, version 22H2, Windows 10, version 21H2, Windows 10, version 1809, Windows 10, version 1607
• Server: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

If you previously uninstalled KB5071546 as a workaround, you can now safely reinstall it along with KB5074976 to get both the security fixes and the MSMQ resolution.

Answer 2

After KB5071543 / KB5071544, we're seeing the following error when sending multicast messages via System.Messaging API from an IIS Web App.

System.Messaging.MessageQueueException: Insufficient resources to perform operation.

On Windows Server 2019, if we rollback KB5071544 things work again.

On Windows Server 2016, if we rollback KB5071543 things work again.

System.Messaging.MessageQueueException: Insufficient resources to perform operation.   at System.Messaging.MessageQueue.SendInternal(Object obj, MessageQueueTransaction internalTransaction, MessageQueueTransactionType transactionType)   at CompAnalytics.Extension.Msmq.AlertContextExtension.SendAlert(String alertName, String alertTitle, Uri alertLink, String msgBody, IList`1 extensionObjects, String priority) in C:\agent_work\7\s\Product\CompAnalytics.Extension.Msmq\AlertContextExtension.cs:line 95   at CompAnalytics.Extension.Msmq.AlertSender.Execute(IExecutionContext context) in C:\agent_work\7\s\Product\CompAnalytics.Extension.Msmq\AlertSender.cs:line 63   at CompAnalytics.Execution.ExecutionContext.ExecuteModuleOrSurrogate(ModuleExecutor executor, Module module) in C:\agent_work\7\s\Product\CompAnalytics.Execution\ExecutionContext.cs:line 1207   at CompAnalytics.Execution.ExecutionContext.ExecuteOrRestoreModule(ModuleExecutor executor, Module module, Int32 currentRetryCount) in C:\agent_work\7\s\Product\CompAnalytics.Execution\ExecutionContext.cs:line 1185   at CompAnalytics.Execution.ExecutionContext.ExecuteModuleWithRetry(ModuleExecutor executor, Module module) in C:\agent_work\7\s\Product\CompAnalytics.Execution\ExecutionContext.cs:line 1150   at CompAnalytics.Execution.ExecutionContext.ExecuteModule(ModuleExecutor executor, Module module, ExecutionCallback postExecutionCallback) in C:\agent_work\7\s\Product\CompAnalytics.Execution\ExecutionContext.cs:line 992