Forum Widgets
Latest Discussions
Unable to Build Switchless Storage using Network ATC
3-Node HV/S2D Cluster using Switchless Storage and Network ATC getting Network HUD Error I have a Dell 3-node server cluster being used to host Hyper-V with S2D. Each node is identical and certified to pass S2D requirements. The networking consists of 2 onboard 1 Gbps and 2 quad-port PCI(e) NICs at 10/25 Gbps. The 2 onboard ports are being used for the management intent, 2 ports from each of those NICs are being connected to 2 top-of-rack switches for the compute intent at a total of 12 10 Gbps connections, and the other 2 ports from each of those NICs are being connected directly to the other nodes in a dual mesh method for the storage intent at a total of 6 25 Gbps connections. Very similar to the Microsoft diagram for a three-node storage switchless, dual TOR, dual link deployment network reference pattern for Azure Local, but I am using Windows Server 2025 Datacenter, not Azure Local. The problem I am encountering is when I attempt to create the switchless storage intent, I get an error (shown below) that reads "Failed to fetch physical NIC mapping from the Network HUD service. Please diagnose..." If I leave off the switchless option, it builds without issue. The error only occurs when I attempt to use the switchless option. I tried without configuring the NIC IP addresses first, as well as trying configuring the NIC IP addresses beforehand. I tried without having a cluster built first, as well as building a failover cluster without storage before running the network intent command. The error I posted below shows my last attempt after having the NICs configured with IP addresses and having a failover cluster established before running the command. The error has remained the same throughout the process. Has anyone else run into an issue like this with switchless storage? It seems like everything that I am trying to do is within scope and should be a supported solution. My fallback plan is to use my existing switches, but that drops my connection speeds down from 25 Gbps to 10 Gbps due to hardware limitations.
PowerShell DSC Pullserver stops working with SQL database
After updating Windows Server 2025, our DSC Pull Server stopped communicating with its SQL backend database. The issue was not present before the update, and reverting to the previous version of Microsoft.PowerShell.DesiredStateConfiguration.Service.dll immediately restored normal functionality. With the newer DLL version, the service starts successfully and the endpoint remains available, but no connection is established to the SQL Server database. As a result, database initialization does not occur, required tables are not created or updated, and node registration fails. No database sessions are observed on the SQL Server during registration attempts, indicating that the service does not reach the SQL connection phase. We compared the previous working DLL version with the updated version and confirmed that the regression is introduced by the newer DLL. Replacing the updated DLL with the earlier version consistently restores SQL database connectivity and normal Pull Server Operation.
Windows Server 2022 File Server Cluster | Network Teaming
Hello Microsoft Community, I have a Windows Server 2022 File Server Cluster (all physical nodes) running with SMB shares. At present, it is not configured with NIC teaming. We are planning to setup NIC teaming. I am going to add an additional network adapter to achieve this. Since this is a production file server server. It tried to perform NIC teaming in a test environment. Upon setting up network teaming, File server clustered roles do not come online and fail. It registers an Event ID 1049 about duplicate IPs despite the fact that I have deleted old network adapter via device manager (show hidden devices). New network adapter comes online without any previous knowledge of IPs. When setting up old IP scheme on a new individual network adapter, File server clustered roles come online successfully. However, setting up the old IP scheme on teamed network adapter, it registers Event ID 1049 about duplicate IPs and roles shows a status of Failed instead of Stopped. Duplicate IPs are only registered for clustered file server roles. They are not registered for node IPs and cluster management IPs. What would be a best way to achieve network teaming on an existing file server cluster without setting up the cluster from scratch?
Enforcing LDAP Signing breaks ADDS Replication (repadmin.exe)
Hi All, After months of auditing Event ID 2889 and remediating application simple binds (clear text usernames/passwords over the wire), I was left with only SASL binds (that do not use signing). I proceeded to set LDAP signing to 'negotiate' as per the GPOs below, and several dozen Microsoft KBs and from the community e.g.. https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server Default Domain Controllers Policy Domain controller: LDAP server signing requirements: None: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it Default Domain Policy Network security: LDAP client signing requirements: Negotiate signing: If Transport Layer Security/Secure Sockets Layer (TLS\SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the options specified by the caller. If TLS\SSL has been started, the LDAP BIND request is initiated with the options that are specified by the caller. I still noted 1,000s of Event ID 2889s (0 – SASL Bind that does not use signing), primarily from DCs, and ::1 addresses I proceeded with enforcing LDAP signing ("Require Signing" for both GPO settings above) and noted: LDAP authentication was occurring via Kerberos (SASL/SPNEGO) with simple binds blocked as per tracing (and ldp.exe) confirmations: Error <8>: ldap_simple_bind_s() failed: Strong Authentication Required Error 0x2028 A more secure authentication method is required for this server. However, I came to work the next day and performed a manual replication: Repadmin /Syncall /APeD LDAP error 8 (Strong Authentication Required) Win32 Err 5. So I had to revert back to Negotiate. How can customers enforce LDAP signing if common Microsoft ADDS executables like repadmin.exe still use Simple Binds? Any ideas appreciated, thank you in advance. Steve
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?
Creating parent reverse lookup zone when child zones already exist — what happens?
We have an AD-integrated DNS environment that has accumulated a large number of reverse lookup zones over time, created without any parent zone — essentially DNS sprawl from years of admins creating individual subnet zones rather than working from a parent. We currently have approximately 80+ reverse lookup zones including: Dozens of x.10.in-addr.arpa zones covering various 10.x.x.x subnets Multiple x.172.in-addr.arpa zones A handful of others including 100.192.10.in-addr.arpa, 168.192.in-addr.arpa, 204.167.in-addr.arpa, 215.204.167.in-addr.arpa, 135.7.in-addr.arpa None of these were ever delegated from a parent zone — they were just created independently. The 10.in-addr.arpa zone does not exist. Domain controllers are a mix of Windows Server 2019 Standard (majority) and Windows Server 2025 Standard. Our goal is to create 10.in-addr.arpa as the consolidation point going forward — new registrations go there, and we migrate existing child zones into it one at a time, deleting old ones as we go at a pace we're comfortable with. Before touching anything, we need to understand what creating 10.in-addr.arpa will actually do to the existing child zones. Specifically: Will existing records in the child zones be deleted? We've seen the TechNet article documenting records vanishing when creating a child zone under an existing parent — does the same destructive behaviour occur in the reverse direction? Will auto-delegations be created in the new parent zone pointing to the existing child zones, and if so how quickly? Will the child zones continue to function normally for queries while the parent exists alongside them? Will dynamic registration start hitting the parent zone for subnets not covered by an existing child zone, or will something unexpected happen? We can't test this in a lab as we don't have a replica environment available, and can't risk touching production without understanding the behaviour first. Pointers to any documentation covering this specific scenario would also be appreciated — we've been unable to find anything that addresses creating the parent after the children already exist independently.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 .
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:
