IT weekly review: verify AD FS, SQL patches, PowerShell and Exchange

This review covers October 11, 18:00 through October 18, 18:00, 2026, Europe/Berlin. Four developments deserve attention in on-premises operations: AD FS permission enforcement, SQL Server security updates, new PowerShell maintenance releases and an Exchange regression following Windows updates. The common task is to check the service after patching, not merely the installation result. The actions below are operational recommendations; they are separate from the vendors' release facts. Prioritize identity and mail availability while preserving a tested route to recovery.

Microsoft moved Active Directory Federation Services (AD FS) DKM (Distributed Key Manager) container hardening into enforcement with the October 13 Windows security updates. The container holds key material used to protect federation certificates. Windows Server 2016, 2019, 2022 and 2025 now remediate insecure permissions by default unless administrators opt out. Server 2012 and 2012 R2 still require manual remediation. This is a new enforcement stage for CVE-2026-56155, originally documented in July, rather than a newly disclosed vulnerability.

Before patching, identify every federation farm, its service identity and the owner of dependent applications. Preserve the existing permission configuration and test representative sign-ins after the change. Microsoft's revised KB5121391 explains that one farm member can change the shared directory object; an exception on only one server is insufficient. Review AD FS/Admin events: 1133 reports secure permissions, while 1136 and 1137 need investigation. Treat an opt-out as an owned, temporary security exception, with a reason and a date for removal.

SQL Server received new security packages on October 13. For the cumulative-update branches covered here, KB5126934 brings SQL Server 2022 CU27 GDR to 16.0.4305.5, and KB5126967 brings SQL Server 2025 CU9 GDR to 17.0.5015.4. Both cover Windows and Linux and address vulnerabilities including remote code execution. These packages are distinct from the Linux bulk-import feature covered earlier this month. The listed builds are specific targets for those servicing branches, not universal targets for every SQL Server installation.

Record each instance's version, servicing branch, operating system and availability-group role before choosing a package. My recommendation is to verify a recoverable database backup, patch a representative non-production instance and exercise the application's actual database operations. Include scheduled jobs, linked-server access and replication where used. For clustered services, agree the sequence and failover acceptance criteria before maintenance. Afterwards, collect the installed build and functional results from every node; a successful update on the primary says nothing about an overlooked secondary or a rarely used reporting instance.

The PowerShell project published 7.6.7, 7.5.12 and 7.4.21 on October 13. All three release notes describe more tolerant handling of IO and JSON errors when reading per-user powershell.config.json, and a session-restriction check in Show-Command. Version 7.6.7 also changes PATH handling for MSIX installations. These are concrete maintenance changes to test on automation hosts. They do not establish that an arbitrary broken configuration is harmless or that every script should move to a different release line.

Inventory the executable actually launched by scheduled tasks, management tools and service accounts. An administrator's interactive shell can be newer than the runtime used overnight. Update within the selected release line, then run a representative job under its real account with the intended configuration and modules. Compare exit status, structured output and resulting changes. Check executable resolution after MSIX servicing where relevant. Keep the previous tested deployment available until acceptance; do not replace verification with the assumption that a command named pwsh resolves to the version just installed.

Microsoft's Exchange incident was opened on October 16 at 16:19 PT, October 17 at 01:19 in Berlin, following the October 13 Windows updates. It reports OWA sign-in failures, undelivered mail and growing queues on some Exchange 2016, 2019 and Subscription Edition installations. The Windows platforms listed are Server 2016, 2019, 2022 and 2025; that list does not make every Exchange/Windows pairing supported. Installing the October Exchange security update is not necessary to trigger the problem.

For affected mail systems, correlate the Windows installation time with queue growth, application events and user symptoms. The pre-cutoff incident record links a temporary registry mitigation; follow Microsoft's procedure for the observed configuration and arrange monitoring after the change. Test web sign-in and mail delivery in both directions under representative load. Record the change and its owner, and reassess it when permanent guidance arrives. The later October 20 FAQ is outside this review's evidence window and is not treated as information available on Sunday.

For the next maintenance window, leave four concise records: federation permissions and sign-in results, SQL target builds and application checks, the runtime used by automation, and Exchange mail-flow evidence. Assign an owner to every exception and failed check. Keep backup and restore verification in the same change record as the patch. This week's practical lesson is specific: security servicing can change shared directory permissions, database behavior and mail availability, so acceptance must follow the service across those boundaries.