Recent Discussions
Out of Band Cumulative Updates Question
I installed March 2026 Cumulative Update on a new server instead of April due to some RC4 changes to test something. I noticed that after the update installed in the event viewer it thinks the June 2026 update was installed. I don't see the June update under installed updates but shows up in update history. The build version of the server matches with the March 2026 update. Is this a weird side effect of installing a superceded update? I'm having trouble understanding what is going on.BLOG: Windows Insiders - State of vbscript deprecation June 2026
While I greatly appreciate the decision of vbscript / cscript / wscript removal, with security and hardening in mind – I would also appreciate if Microsoft could be actively using the vNext release channel, preparing for feature removal. With this blogpost, I am sharing my point of view on the state of dependencies I am seeing in this regard, focusing on a way forward towards the full removal of vbscript. My findings show, that there is a quite some action required, and this stands a bit contrary to the announcement, Microsoft intends removing the optional feature of vbscript by default with the upcoming release - anticipated by fall 2027. Given my lessons learned from Secure Boot CA2023 exchange initiative, Microsoft guidance, foremost PowerShell based scripts, tooling and dashboards have been released quite late, looking at the timeline, considering the impact and scale customers had to deal with, and consequences for their security posture if they are not ready and done, with first certificates to expire soon. Taking this learning into account and and projecting it to vbscript deprecration I come to the following conclusion: SMB customers, enterprises, Microsoft Products, see below, are required to be updated or replaced, in order of adopting this change. I believe there is quite some communication and learning curve required for users, admins, enterprises and OEMs in adopting the implicated change and including changed workflows and automation processes. Looking forward to the next Windows Insider and esp. Windows Server Insider vNext builds! Both Windows Insiders and Windows Server Insiders, also including ISV and OEMs may assist in reviewing and validating the new workflows required - assuming vbscript deprecation is in effect, as planned. Without further ado, I am sharing my observations in regard to VBScript deprecation. I will try to keep this blogpost updated as soon I am aware about public facing changes. Third-Party AMD Chipset drivers so far is one of the major non MSFT related blockers. Suggestions: Microsoft should initiate talks with AMD and other ISV and OEMs fixing their dependencies, also offering other solutions, see below. Currently AMD Chipset drivers silently using vbscript calls checking for OS and HW platform compatibility. The installer fails when vbscript optional feature is removed. OEM, ISV and Enterprise Potentially affected: expected dependencies for imaging, deployment and management workflows. Related or unrelated to Microsoft products. LOB apps custom Office Integration logon and logoff scripts setup and installers Recommendation: Please observe vbscript related events in Windows Event Viewer at scale using PowerShell, Remoting or Windows Event Subscriptions: VBScriptDeprecationAlert Event ID 4096 VBScript is scheduled for deprecation. Our telemetry indicates that your system is currently utilizing VBScript. We strongly recommend identifying and migrating away from any VBScript dependencies at the earliest. The following process has been detected as using VBScript. The associated process tree and call stack are provided below to assist in identifying the scenario in which VBScript was invoked. Microsoft Windows Server and Client OS affected: slmgr.vbs / printer management vbscripts / product activation logic and UX, setup.exe, slui.exe Office 2024 LTSC affected: slmgr.vbs / ospp.vbs / Office deployment toolkit / product activation logic Microsoft has placed a new PowerShell based script into the respective OSPP folder. This script however is rather offering on checking licensing and cannot activate the Office product at this time. Microsoft 365 Business, Enterprise, Home, Family Affected: ospp.vbs despite being subscription based will also trouble with activation once vbscript is removed Sconfig Related to product activation. no changes so far, relies on external changes. The script itself is safe to comply with the change, now it has been reworked and updated using PowerShell , starting Windows Server 2022. WinRM Affected: the whole WinRM configuration command, e.g. winrm qc Windows Server Roles and Features: KMS / ADBA Potentially affected as they rely on slmgr for adding and removing CSVLK keys. Windows Server Roles and Features: IIS legacy IIS extension management. Windows Server Roles and Features: WSUS related deployment and configuration scripts. System Center Products incl. ConfigMgr there might be depencendies for OS deployments in regard to OS imaging. ADK, esp. Windows Imaging Tools and VAMT 3 potentially affected. Need to adopt changes in regard to activation and other operations. Suggestions: Recommending all these scripts being converted using Claude or Copilot from vbscript to PowerShell. Providing a serviceable PS modules, especially for printer management, product activation, which enables enterprises to automate their activations and printers, even though Microsoft is going to remove vbscript. The modules should be improved for existing day two adminstration tasks and workflows. slmgr, in particular, had some nuances that were tedious such as identifying and removing (stale) activation keys. Existing tools like slmgr and other will not work well in remoting. They do something but their interactive parts and outputs are reserved for interactive user sessions. Example: you can use slmgr in a remote PowerShell session for installing and activating a key but therer is no result return to the shell. Combining slui.exe and slmgr.vbs into aforementioned improvements in functionality and syntax. Consider support for PowerShell 7 in WinRE and Offline Setup phase. Many thanks for your consideration! Directory: C:\Windows\System32\Printing_Admin_Scripts\en-US Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 10:43 AM 98756 prncnfg.vbs -a--- 4/16/2026 10:43 AM 66172 prndrvr.vbs -a--- 4/16/2026 10:43 AM 62698 prnjobs.vbs -a--- 4/16/2026 10:43 AM 95908 prnmngr.vbs -a--- 4/16/2026 10:43 AM 71616 prnport.vbs -a--- 4/16/2026 10:43 AM 44278 prnqctl.vbs -a--- 4/16/2026 10:43 AM 22612 pubprn.vbs Directory: C:\Windows\System32 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 4119 CallUxxProvider.vbs -a--- 4/16/2026 9:14 AM 145712 slmgr.vbs -a--- 4/16/2026 9:14 AM 1720 SyncAppvPublishingServer.vbs -a--- 4/16/2026 9:14 AM 204072 winrm.vbs Directory: C:\Windows\SysWOW64\Printing_Admin_Scripts\en-US Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 10:43 AM 98756 prncnfg.vbs -a--- 4/16/2026 10:43 AM 66172 prndrvr.vbs -a--- 4/16/2026 10:43 AM 62698 prnjobs.vbs -a--- 4/16/2026 10:43 AM 95908 prnmngr.vbs -a--- 4/16/2026 10:43 AM 71616 prnport.vbs -a--- 4/16/2026 10:43 AM 44278 prnqctl.vbs -a--- 4/16/2026 10:43 AM 22612 pubprn.vbs Directory: C:\Windows\SysWOW64 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 145712 slmgr.vbs -a--- 4/16/2026 9:14 AM 204072 winrm.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-a..nagement-appvclient_31bf3856ad364e35_10.0.29574.1000_none_0895f7c27f109b8a Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 1720 SyncAppvPublishingServer.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-iis-legacyscripts_31bf3856ad364e35_10.0.29574.1000_none_ba69ed912e209e30 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 98133 adsutil.vbs -a--- 4/16/2026 9:14 AM 41401 IIsExt.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-p..inscripts.resources_31bf3856ad364e35_10.0.29574.1000_en-us_ 4ad0e09e0339f1ef Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 10:43 AM 98756 prncnfg.vbs -a--- 4/16/2026 10:43 AM 66172 prndrvr.vbs -a--- 4/16/2026 10:43 AM 62698 prnjobs.vbs -a--- 4/16/2026 10:43 AM 95908 prnmngr.vbs -a--- 4/16/2026 10:43 AM 71616 prnport.vbs -a--- 4/16/2026 10:43 AM 44278 prnqctl.vbs -a--- 4/16/2026 10:43 AM 22612 pubprn.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-s..r-core-mgmtprovider_31bf3856ad364e35_10.0.29574.1000_none_62cec50667f8da2a Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 4119 CallUxxProvider.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-security-spp-tools_31bf3856ad364e35_10.0.29574.1000_none_81bcc6c67609fdb9 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 145712 slmgr.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-w..for-management-core_31bf3856ad364e35_10.0.29574.1000_none_0688f60763f16bc8 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 204072 winrm.vbs Directory: C:\Windows\WinSxS\amd64_updateservices-services_31bf3856ad364e35_10.0.29574.1000_none_bae89f3176313538 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 8332 DynamicCompression.vbs -a--- 4/16/2026 9:14 AM 4289 SetAppPool.vbs -a--- 4/16/2026 9:14 AM 5813 SetMimeMap.vbs Directory: C:\Windows\WinSxS\wow64_microsoft-windows-iis-legacyscripts_31bf3856ad364e35_10.0.29574.1000_none_c4be97e36281602b Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 41401 IIsExt.vbs Directory: C:\Windows\WinSxS\wow64_microsoft-windows-p..inscripts.resources_31bf3856ad364e35_10.0.29574.1000_en-us_ 55258af0379ab3ea Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 10:43 AM 98756 prncnfg.vbs -a--- 4/16/2026 10:43 AM 66172 prndrvr.vbs -a--- 4/16/2026 10:43 AM 62698 prnjobs.vbs -a--- 4/16/2026 10:43 AM 95908 prnmngr.vbs -a--- 4/16/2026 10:43 AM 71616 prnport.vbs -a--- 4/16/2026 10:43 AM 44278 prnqctl.vbs -a--- 4/16/2026 10:43 AM 22612 pubprn.vbs Directory: C:\Windows\WinSxS\wow64_microsoft-windows-security-spp-tools_31bf3856ad364e35_10.0.29574.1000_none_8c117118aa6abfb4 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 145712 slmgr.vbs Directory: C:\Windows\WinSxS\wow64_microsoft-windows-w..for-management-core_31bf3856ad364e35_10.0.29574.1000_none_10dda05998522dc3 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 204072 winrm.vbs related announcements: https://techcommunity.microsoft.com/blog/Windows-ITPro-blog/vbscript-deprecation-timelines-and-next-steps/4148301
KB5094128 ntoskrnl.exe version wrong?
For update KB5094128 The list of updated files contains an ntoskrnl.exe with file version 10.0.20348.5257 which in my opinion should be 10.0.20348.5256. https://go.microsoft.com/fwlink/?LinkId=2368532 We use scanning tools which rely on this list of updated files. But the installed file version is different and therefore our scanning tools report these installations as "vulnerable" After applying patch KB5094128 the version of \windows\system32\ntoskrnl.exe is 10.0.20348.5256 Does anybody know if the information in this .csv is wrong?in-place upgrade fails from b29574 to latest vnext b29595
Hi all, is anyone facing the same issue IPU fails on a fresh b29574 upgrading to latest using WU? provided more information in feedback hub. Thanks for sharing your experience. as a next attempt I will mount ISO and upgrade. mind b29574 was the base bare metal installation so no previous IPUs involved. related feedback https://aka.ms/AA11g03n Installed roles: - Hyper-V Specialities: tried SysWOW64 removal but failed to do so https://aka.ms/AA11eyy5 OS Drive is ReFS, potientially related https://aka.ms/AA11eyy8 <?xml version="1.0" encoding="utf-16"?> <SetupDiag xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag"> <Version>1.7.0.0</Version> <ProfileName>FindRollbackFailure</ProfileName> <ProfileGuid>3A43C9B5-05B3-4F7C-A955-88F991BB5A48</ProfileGuid> <FailureData>0xc1900101-0x20017 Error: SetupDiag reports rollback failure found.Last Phase = FinalizeLast Operation = Cleanup external drivers after installationError = 0xC1900101-0x20017</FailureData> <FailureData>LogEntry: </FailureData> <FailureData>Refer to "https://docs.microsoft.com/en-us/windows/desktop/Debug/system-error-codes" for error information.</FailureData> <FailureDetails>RollbackErrorCode = 0xC1900101, ExtendedCode = 0x20017, LastOperation = Cleanup external drivers after installation, LastPhase = Finalize</FailureDetails> <Setup360Result>0xc1900101</Setup360Result> <Setup360Extended>0x20017</Setup360Extended> <SetupPhaseInfo> <PhaseName>Finalize</PhaseName> <PhaseStartTime>06/06/2026 13:16:53</PhaseStartTime> <PhaseEndTime>06/06/2026 13:17:35</PhaseEndTime> <PhaseTimeDelta>0:00:00:42.0000000</PhaseTimeDelta> <CompletedSuccessfully>true</CompletedSuccessfully> </SetupPhaseInfo> <SetupOperationInfo> <OperationName>Cleanup external drivers after installation</OperationName> <OperationStartTime>06/06/2026 13:17:35</OperationStartTime> <OperationEndTime>06/06/2026 13:17:35</OperationEndTime> <OperationTimeDelta>0:00:00:00.0000000</OperationTimeDelta> <CompletedSuccessfully>true</CompletedSuccessfully> </SetupOperationInfo> </SetupDiag> also noticing uncommon links in root as if I were using FAT32.
Windows Server 2025 24H4 is not useable anymore after Nov. Update KB5068861
Hello, currently, on several Windows Server 2025 Datacenter systems, version 24H2, I am experiencing severe issues accessing network resources after the automatic installation of update KB5068861. This affects network access from Windows Server 2025 24H2 to Windows Server 2025 24H2. Access from these servers to older Windows Server 2016 systems works without any problems. When entering a UNC path—whether by name or by IP—I am always prompted for my credentials, even as a domain administrator. No matter which credentials I enter, I always receive the message that the username or password is incorrect. Under “Change advanced sharing settings,” the two switches “Network discovery” and “File and printer sharing” are set to OFF in the domain network after the update. Re-enabling these two options, which are normally enabled by default, does not improve the situation. Since this patch, I also have an issue on a Windows Server 2025 RDS host where a logged-in user cannot type in the “Search” field. Additionally, the performance on the RDS host feels extremely sluggish. Unfortunately, uninstalling the patch is not possible. The patch KB5067036 is not installed. I have already performed a restore to the day before KB5068861 was installed, but without the desired improvement in performance. Even after the restore, I still cannot access the network via UNC through File Explorer as a user. In the search window, I can access via UNC path. As an administrator, access via UNC path works both in File Explorer and in the “Search” field. Everything worked fine before 11/11/2025. Has anyone had similar experiences or already found a solution? Is a patch for the patch planned? Currently, troubleshooting feels like groping in the dark! In this state, the 24H2 server is no longer usable. What was Microsoft even thinking, releasing such faulty patches—and for weeks now? Is there still any quality control at Microsoft for such critical updates and patches? Thanks for every support, idea, and comment.
Server flighting not being offered on 29595 on 3 VMs
Hi, I'm on not getting build 29602 offered as a flight through Windows update on any of my VMs and I can figure out why, it has not been offered in the last couple of builds. Is anyone else experiencing this or have any ideas of how to fix this? Optional diagnostics are on and they are connected to my account under insider setting in Windows update settings. I am just not getting offered the build flight. Thanks Kevin
Windows server 2025 Application Crashing Events
I have installed a Windows Server 2025 and after starting it in about 30 minutes the following error appears in the Windows application log . ======================================= Log Name: Application Source: Application Error Date: 4/6/2026 1:51:06 μμ Event ID: 1000 Task Category: Application Crashing Events Level: Error Keywords: User: SERVER\Administrator Computer: SERVER.efarmacy.internal Description: Faulting application name: backgroundTaskHost.exe, version: 10.0.26100.1, time stamp: 0x5bc61463 Faulting module name: biwinrt.dll, version: 10.0.26100.32230, time stamp: 0xb950595a Exception code: 0xc000027b Fault offset: 0x0000000000012713 Faulting process id: 0x1964 Faulting application start time: 0x1DCF4100B5B371A Faulting application path: C:\WINDOWS\system32\backgroundTaskHost.exe Faulting module path: C:\Windows\System32\biwinrt.dll Report Id: a0fa5d15-b026-4d12-a047-d965195ac338 Faulting package full name: MicrosoftWindows.Client.CBS_1000.26100.275.0_x64__cw5n1h2txyewy Faulting package-relative application ID: Global.Accounts Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" /> <EventID>1000</EventID> <Version>0</Version> <Level>2</Level> <Task>100</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000000</Keywords> <TimeCreated SystemTime="2026-06-04T10:51:06.2935992Z" /> <EventRecordID>7473</EventRecordID> <Correlation /> <Execution ProcessID="1984" ThreadID="6560" /> <Channel>Application</Channel> <Computer>SERVER.efarmacy.internal</Computer> <Security UserID="S-1-5-21-4001248846-3127524418-1814302027-500" /> </System> <EventData> <Data Name="AppName">backgroundTaskHost.exe</Data> <Data Name="AppVersion">10.0.26100.1</Data> <Data Name="AppTimeStamp">5bc61463</Data> <Data Name="ModuleName">biwinrt.dll</Data> <Data Name="ModuleVersion">10.0.26100.32230</Data> <Data Name="ModuleTimeStamp">b950595a</Data> <Data Name="ExceptionCode">c000027b</Data> <Data Name="FaultingOffset">0000000000012713</Data> <Data Name="ProcessId">0x1964</Data> <Data Name="ProcessCreationTime">0x1dcf4100b5b371a</Data> <Data Name="AppPath">C:\WINDOWS\system32\backgroundTaskHost.exe</Data> <Data Name="ModulePath">C:\Windows\System32\biwinrt.dll</Data> <Data Name="IntegratorReportId">a0fa5d15-b026-4d12-a047-d965195ac338</Data> <Data Name="PackageFullName">MicrosoftWindows.Client.CBS_1000.26100.275.0_x64__cw5n1h2txyewy</Data> <Data Name="PackageRelativeAppId">Global.Accounts</Data> </EventData> </Event> =========================================== I have already done the actions to check the files. The check does not find any problems but the problem continues to appear. "DISM.exe /Online /Cleanup-image /Restorehealth" "sfc /scannow". I would like to know if anyone else has faced this problem and if there is a solution for it. Thanks in advance .
SCCM- Upgrade from 2409 to 2509 WSUS timeout issue
Had a working task sequence on 2409 that performed software updates at the end of the task sequence. Upgraded to 2509 - I get a timeout issue when getting to that point on the task sequence. Ive performed maintenance on the WSUS Server, (obsolete, expired etc) I removed the Software Update Point - and re installed it selected the Products of Server 2016,2019, server operating system 21h2 , Windows 10 1903 or later and Windows 11. rebooted both the SCCM and SQL Server. after doing the above but the HRESULT 0x80244010 still persists. "Exceeded max server round trips" — client couldn't retrieve all updates in one cycle. Software centre updates in the OS seem to be unaffected or unknown if clients are affected, only in a task sequence this occurs. Blog posts refer to older items, what would cause this to fail after a upgrade from 2409 to 2509? AI help repeats about reducing metadata and updates but for weird reason i keep getting 700+ updates for the above categories!
RDP Client - incorrect keyboard shortcut action in German localization
In the above dialog, when any of the checkbox controls has the focus, ALT+V toggles the state of the checkbox. ALT+V obviously should trigger "Verbinden" (Connect) instead. But not when the dialog first appears, i.e. none of the controls has the focus. Then ALT+V does nothing. As long as any chekbox control has the focus, ALT-V toggles its state. If the command button "Abbrechen" has the focus, ALT-V does nothing, i.e. ALT-V never triggers "Verbinden" except the command button "Verbinden" itself has the focus. Steps to reproduce: Start RDP client to connect to a remote machine Press ALT-Z -> "Zwischenablage" will be checked as expected Press ALT-Z again -> "Zwischenablage" will be unchecked as expected After any of the two steps above, press ALT-V -> "Zwischenablage" will be toggled instead of triggering "Verbinden" Same goes for "WebAuthn". Depending on the devices on the local machine an the RDP settings for sharing those, their might be more options with checkbox. I suspect those to behave similarly wrong when pressing ALT-V. The OS doesn't seem to make a difference. I see the same behavior on both Windows 11 and Windows Server 2022. RDP client version:
PowerShell counterpart for Failover Cluster Manager "Live Migration Settings"
In Failover Cluster Manager, there's "Live Migration Settings" where I can define what cluster networks I want to carry live migration traffic. Even after some research, I cannot find a PowerShell cmdlet that lets me do the same...Windows Server vNext cannot be activated
Error Code 0xC004F012 when trying to activate WS vNext Datacenter with Key 2KNJJ-33Y9H-2GXGX-KMQWH-G6H67. vbscript is removed, implying the future removal of this component from the OS. It appear that Windows Activation still relying on vbscript. Is this something that is on the roadmap? Would wish for native PowerShell support / module instead of vbscript.Shared Connections not deleting
Hi there - I have Windows Admin Center v1.5.2306.14001 installed and have 1142 shared connections. When I attempt to delete all shared connections, WAC looks like it goes through deleting them - but then gets to a specific number and just stops. If I then refresh the browser, it returns 1142 shared connections again - so, it looks like no shared connections have actually been deleted. If I try to delete just one shared connection, I get the same outcome. I've also tried re-importing some connections again with the below PowerShell command in the hope it'll remove any connections not specified in the csv, but it's still the same outcome. Import-Connection <WAC URL> -fileName WAC.csv -prune FYI - the above is being done with my user account, which has gateway administrator permissions in WAC. Has anyone else experienced this issue? Thanks
Remote desktop app hangs when opening a new process
I have a windows remote desktop server, windows server 2022. We have a few programs we allow access to people published as remote apps. One of the programs exports to Excel by opening excel, creates the workbook/worksheet, but the window does not show and the program hangs waiting for excel to close. The user can't see excel and therefore can't close excel so they are stuck. as an admin, I can connect to the remote desktop server and end task on their excel instance and then they can continue working. Is there a way to allow the excel window to show when opened by a remote app? We prefer to only allow our users access to the one app they need to run instead of a desktop.Windows Server 2025 DC — LSASS handle leak identified via WinDbg — authz!AuthzpDeQueueThreadWorker
Hello All!! Im having a problem, LSASS crashes on a Windows Server 2025 Domain Controller, I identified what appears to be the root cause using WinDbg memory dump analysis. Sharing this hoping someone else has seen it or Microsoft can confirm. The Problem LSASS handle count grows continuously over time and eventually crashes with a 0xC0000005 access violation (Event ID 1015). After a reboot the cycle repeats. The growth rate correlates with authentication load and faster during peak hours, slower overnight. WinDbg Dump Analysis Captured LSASS dump at high handle count and ran !handle 0 f: Token handles: overwhelmingly dominant Everything else: negligible Every leaked token shows: GrantedAccess: 0x8 (TOKEN_QUERY only) PointerCount: overflowed to negative integer Running !findstack authz 2 shows multiple worker threads all sitting in: authz!AuthzpDeQueueThreadWorker What Was Tested And Eliminated Stopped or disabled each individually and measured handle growth rate — zero meaningful difference from any: - Antivirus (all components) - Backup software - Application services - VSS snapshots - Hardware management agents etc.. Environment OS: Windows Server 2025, fully patched with the latest updates including April LSASS update. Role: Domain Controller DNS PAM: Not active. Conclusion Token handles are opened with TOKEN_QUERY access inside authz!AuthzpDeQueueThreadWorker and never released. Reference counter overflows to negative integer. Growth rate scales directly with authentication load. Current workaround: reboots during off hours. Has anyone else seen this pattern on Windows Server 2025? Is there a known fix or Microsoft acknowledgment for this specific authz token handle leak?Modernized Gateway Extension Support via WAC SDK
Hello, I would like to build a gateway plugin for the latest WAC v2511 but according to this documentation, the latest SDK package does not support the latest modernized gateway extensions. Is there a way to workaround this without downgrading WAC version? https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/extend/develop-gateway-plugin “The Windows Admin Center SDK and developer tools have not yet been updated to support development of gateway plug-ins compatible with the Windows Admin Center modernized gateway. Following this guide will not result in a .NET 8 extension compatible with the modernized gateway.Windows Server Datacenter: Azure Edition preview build 29595 now available in Azure
Hello Windows Server Insiders! We welcome you to try Windows Server vNext Datacenter: Azure Edition preview build 29595 in both Desktop experience and Core version on the Microsoft Server Operating Systems Preview offer in Azure. Azure Edition is optimized for operation in the Azure environment. For additional information, see Preview: Windows Server VNext Datacenter (Azure Edition) for Azure Automanage on Microsoft Docs. For more information about this build, see Announcing Windows Server vNext Preview Build 29595 | Microsoft Community Hub.
Recent Blogs
- Today, we’re excited to announce that DoH support for Windows DNS Server is generally available on Windows Server 2025 for client-to-server DNS traffic. When we first introduced DNS over HTTPS (DoH...Jun 11, 2026
- Thank you for your continued support and engagement with the Virtualization Mode (vMode) public preview! Your testing and feedback are integral to making a better product. The public preview buil...Jun 10, 2026
