Recent Discussions
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
Secure Boot update still pending on deadline day
After checking the registry keys on 2x VMs which run services for a number of important customers I found they both have: UEFICA2023Error 2147942750 Apparently this means they're pending a reboot. https://blog.mindcore.dk/2026/04/secure-boot-certificate-update-intune/ I can't reboot the VM inside working hours, can they be rebooted after the deadline or do I need to disable Secure Boot on the VMs? I'm concerned I'll have to disable Secure Boot before they're next rebooted for Windows updates.Save the date: Secure Boot Q&A in July
To help, Microsoft is continuing its Q&A series with several opportunities to connect directly with Microsoft experts. Whether you're managing physical servers, virtualized workloads, or working with your hardware partners on firmware readiness, you can get answers to the questions that matter most to your environment. Learn more and add the events to your calendar: 8:00 AM PDT July 1 - Windows Server Secure Boot AMA 8:00 AM PDT July 8 - Secure Boot Office Hours for virtualized environments 7:00 AM - 7:00 PM PDT July 15 - OEM Secure Boot Office Hours If there's a question that's been holding up your rollout—or one you simply want to validate before moving forward—this is a great opportunity to ask. Feel free to post questions ahead of time or join the conversation live. We look forward to seeing you there.Event 4768 for one user
Hi all, We have two domain controllers running server 2019 with Domain Functional Level 2016. We have one user who has been with us for almost a year, and they were suddenly getting a message in the last week that username or password were incorrect even though we confimed they were not. They were able to initally switch to another user and re-enter their username and log in, but now it won't allow that. On the domain controller I see events for the user Audit Failure 4768 with Result Code 0x6. This result suggests the username doesn't exist which isn't true. The account isn't being locked. Has anyone seen this before and know what the issue might be? thanks jm
Windows Crash During NVMe Over TCP Disk Disconnect
While evaluating the Windows NVMe Initiator, we have observed that disconnecting an NVMe disk frequently results in a Windows system crash. This occurs during the disconnect operation and appears to be reproducible in our test environment. Questions: Has anyone else encountered similar behavior? Are there any known issues related to NVMe/TCP disconnect handling? Are there recommended troubleshooting steps, logs, or diagnostics that we should collect to help identify the root cause? Any insights would be greatly appreciated.Multiple Namespace Detection in Windows NVMe Over TCP Initiator
We are evaluating the Windows NVMe Initiator and have observed an issue with namespace handling. Our NVMe subsystem contains multiple namespaces. When we connect to the subsystem over TCP and establish connections to all namespaces, they are all shown as connected under the controller. However, only one namespace (shared block device) is exposed and accessible within Windows. Based on our testing, it appears that the initiator may be mapping only the first namespace associated with a given Friendly Name. We were able to connect another subsystem, whose friendly name was different. Questions: Is support for multiple namespaces within a single subsystem currently available in the Windows NVMe Initiator? If so, are there any configuration requirements or known limitations related to namespace discovery and mapping? Is the initiator expected to expose all connected namespaces as separate disks within Windows? We would appreciate any guidance or clarification on the expected behavior.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.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
Static IP Issue with Windows Server 2022
Hi Community, I installed my first Windows server to learn about the server and Active Directory. I installed Windows Server 2022. I configured a static IP and disabled IPv6. Then I installed Active Directory/DNS. After the reboot, the system is up, and I can access the internet and ping hosts. However, there is a world icon (No internet access) instead of a computer icon (internet access). In the static IP config, it replaced the DNS with 127.0.0.1, I know it'll use the local host as DNS. When I click on Network & Internet settings and Troubleshoot, I see an error 'DHCP is not enabled for "Ethernet"'. The only way it goes away is if I change the static to automatic. How can I fix this issue? Thanks, Also, I added forwarders such as 1.1.1.3 and 1.1.1.2 to DNS.
WAC vMode fails validating SMB
Hi Reviewing vMode and try add a Hyper-V 2025 (non hyperconverged) cluster with a FC SAN. Fails on Validating "SMB port accessibility". Have gone through firewall settings and opened all neccesary ports that i can find mentioned. Even tried without FW turned off without any success so hit the wall now. WAC vMode is installed on a vm running Win2025std and in same domain as the cluster (and hosts) i try to add. Probably some obvious thing i have missed so any suggestions?
Certificate Error Connecting to only to some of the Cluster's resources
Latest version of WAC, winrm configured to connect over HTTPS. No issues connecting to the servers that are members of the cluster, or clients and other servers in our AD. No issues connecting to the cluster Dashboard (I can see health, CPU usage, etc.) and some of the resources (such as Drives, Volumes, Servers). Configuration -> Settings or Security works fine. It's only when I go to some resources, such as virtual switches, GPU's or a handful of others that I get errors connecting to member servers; Specifically, the error will state that for each server: Connecting to remote server servername.local failed with the following error message : The server certificate on the destination computer (servername.local:5986) has the following errors: The SSL certificate contains a common name (CN) that does not match the hostname. The one oddity I see is that .local is being added to the end of the server name. Also, servername will not contain the domain extension, just the name. Here's what I've checked so far: DNS is correct for the member servers and the cluster, both with Host (A) and PTR entries, can be pinged and resolved. As far as I can tell the certificates are setup correctly, no issues connecting to the member servers individually, or the cluster at first. The AD entry for the cluster is in place with the correct permissions for the cluster's service account I've read that .local is appended if the server/cluster is not part of AD, but that's not the case. We have two additional clusters and this issue does not appear on them. I also have not been able to identify any obvious differences between the setup of the two fully functioning clusters and this one. In the Event Viewer on the WAC server, under Applications and Service Logs _> WindowsAdminCenter, I can see Error Entries ID 304 for each member server with a similar message as above: Unable to create PowerShell session on node, status: 400, error code:PSRemotingTransportException, error message:Connecting to remote server server.local failed with the following error message : The server certificate on the destination computer (server.local:5986) has the following errors: The SSL certificate contains a common name (CN) that does not match the hostname. For more information, see the about_Remote_Troubleshooting Help topic.. As a side note, opening a remote Powershell session to each member server via WAC works fine and by contrast, in the WAC Event viewer there will be corresponding Information entries list the server's FQDN. Here's an example Category: Microsoft.AspNetCore.Hosting.Diagnostics EventId: 2 SpanId: 50d2635d1f6eb737 TraceId: b8c8e1de80ac2f84f1230c5ec3305b38 ParentId: 3e0619ce2c5decca ConnectionId: 0HNMB39BE0AS7 RequestId: 0HNMB39BE0AS7:0000009F RequestPath: /api/PowerShell/nodes/serverFQDN/invokeCommand Request finished HTTP/2 POST https://WACserverFQDN:6601/api/PowerShell/nodes/serverFQDN/invokeCommand - 200 - application/json;+charset=utf-8 230.3283ms It seems that when it comes to accessing only some of the cluster's resources WAC no longer has the member servers FQDNs, and I'm not sure where to look for changing that. Anyway, any guidance would be appreciated.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?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.
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.
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
