HomeNovember 2026 patch cycleKB5135557: NTLM signing change breaks App Volumes agent

Call: Known issueCategory: Enterprise

Issue from: CVE-2026-124194, KB5132061: Patch Tuesday roundup

KB5135557: NTLM signing change breaks App Volumes agent

Part of November 2026 patch cycle

Vendor
Microsoft, Omnissa
Products
Windows 11 24H2 and 25H2 (KB5132061), Other Windows versions with November updates, and Omnissa App Volumes Agent 4.18
Published
Status
Open

Call: Known issue. November’s Windows updates make clients offer NTLM signing by default. That’s phase one of Microsoft’s fix for CVE-2026-118737, documented in KB5135557. On some App Volumes setups it breaks the agent’s sign-in to the App Volumes Manager, and the agent turns virtualization off. This is reported, not confirmed: three admins report it in one Omnissa community thread, and neither Omnissa nor Microsoft lists a known issue. Microsoft’s own compatibility switch brings the old behavior back. Test one pool before November goes into your golden images.

What breaks: After KB5132061, the agent says it can’t reach the App Volumes server, and the Manager reports “Virtualization is disabled.” One admin traced it. The NTLM handshake completes, then the Manager sends a second HTTP 401. The agent logs “WWW-Authenticate header could not be read,” “User login over HTTP failed” and “Unable to contact App Volumes Manager,” and then disables virtualization. Pools still on October’s updates keep working.

Who’s hit: App Volumes shops putting November’s updates into images. The detailed report is App Volumes Agent 4.18.0.3124R on Windows 11 build 26100. A second admin added the fix across Windows 10 VDI and Server 2022 RDSH, and says “this not only hits appvolumes but a ton more” without saying what else. A third has the Manager behind a load-balancer VIP and wonders whether the NetScaler in front of it is involved. Nobody has answered that yet. The change covers every non-anonymous NTLM connection a client makes, so other software that handles NTLM over HTTP itself is worth a test.

Workaround:

  • On affected machines, set ClientAllowUnsignedNtlm (REG_DWORD) to 1 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, then restart the App Volumes agent service (svservice). The posters who tried it say it fixed the problem.
  • Microsoft documents that value as “Client does NOT offer SIGN. Use only for temporary compatibility.” It switches off the new protection on that machine, so apply it to the affected images only, not across the whole domain.
  • To find what isn’t signing, check the Microsoft-Windows-NTLM/Operational log for events 4022 (client side) and 4023 (server side). KB5135557 has a PowerShell snippet that does the filtering.
  • Open a case with Omnissa. In phase two, planned for May 2027, Windows servers start requiring signing, so the registry key only buys you time.

Sources: Omnissa community thread (opens in a new tab), KB5135557 (opens in a new tab), KB5132061 release notes (opens in a new tab).

Sources

More from November 2026 patch cycle