Settings Crashes After DC Promotion; Windows Update Unavailable (Server 2016/2022)
Objective Resolve the issue where the Windows Settings app crashes immediately upon opening, so that I can access Settings and install Windows updates normally. Environment and Problem Description We have two domain controllers in our Active Directory domain, named AD and DC. Both are running Windows Server 2016. - AD holds all five FSMO roles and runs as a Hyper-V virtual machine hosted on another server. - DC is a physical server. Both domain controllers have the same problem. Control Panel opens normally, but the Settings app does not. When I click Settings, a window briefly flashes on the screen without displaying any content (or only the gear icon appears), and then the window immediately closes. I cannot open Settings-related pages, including Windows Update. As a result, I cannot use the normal Windows Update interface to install updates. The issue also affects monthly updates downloaded manually from the Microsoft Update Catalog. When I run an update package, the following error appears: Windows Update Standalone Installer: Installer encountered an error: 0x80070005 Access is denied. I performed the following test in an isolated environment: 1. Restored a backup of AD and installed a fresh Windows Server 2022 machine named AD3. AD3 was not connected to any other hosts or networks during the test. 2. Before AD3 was promoted to a domain controller, the Settings app worked normally. 3. Immediately after promoting AD3 to a domain controller, Settings stopped opening and began closing immediately. 4. I then transferred all five FSMO roles to AD3 and demoted AD, so that AD was no longer a domain controller. 5. Surprisingly, the Settings app on AD started working again after AD was demoted. This behavior strongly suggests that the problem is related to the domain controller role or something that changes when a server is promoted to a domain controller. However, I have not identified the underlying cause. Is there a recommended diagnostic procedure or a known issue that could explain this behavior? I would appreciate any technical guidance on how to identify the root cause and resolve the problem without having to demote the domain controllers. Thank you.
Profile Bloat in Azure VM and VMware VDI: A Policy-Driven Strategy for Reducing Storage Growth
OneDrive profile bloat is one of those issues that often starts as a minor desktop optimization discussion, but quickly becomes a storage, performance, and governance problem at enterprise scale. In Azure Virtual Machines and VMware VDI environments, when OneDrive is tied to the user profile, the sync cache, local file state, and stale content can accumulate over time and create unnecessary growth in profile containers, VHD/VHDX files, and backup overhead. The result is higher infrastructure cost, slower login and logoff times, and inconsistent user experience across pooled or multi-session desktops. This is not a problem that should be solved by disabling OneDrive. In most enterprise scenarios, OneDrive remains a critical collaboration workload, but it must be managed as a controlled service rather than a user-local convenience. The most effective strategy is to install OneDrive at the machine level, enforce policy by user class and device context, and use Files On-Demand and cloud content dehydration to minimize local persistence. This approach preserves user productivity while reducing the operational impact on virtualized desktop infrastructure. A policy-driven design is particularly important in multi-user environments where not all workloads should be treated the same. Developer desktops, standard business users, and restricted or consultant user groups have different productivity needs and different data-risk profiles. For example: General business users may benefit from a balanced policy with Files On-Demand enabled and moderate dehydration thresholds. Developer or QA environments may require more local flexibility while still controlling profile growth. Restricted or external-user populations should have strong sync boundaries, personal account restrictions, and minimal local persistence. To support this model, organizations should align their deployment around a few core principles: install OneDrive at the machine level in the standard image or build pipeline use group policy and loopback processing to apply user-specific policy based on OU or security group enable Files On-Demand by default configure Storage Sense and cloud content dehydration based on workload profile restrict personal Microsoft account sync in higher-risk scenarios use FSLogix compaction and profile optimization as secondary controls, not as the primary solution This model is especially relevant for organizations running Azure Virtual Desktop, Azure VM-based workloads, VMware Horizon, and other multi-user Windows desktop environments. The benefits are practical and measurable: lower local storage consumption, reduced VHD/VHDX growth, improved desktop performance, lower backup cost, and stronger governance over enterprise data movement. As IT and endpoint engineering teams continue modernizing virtual desktop environments, I would encourage us to think of OneDrive not as a user-profile feature, but as an enterprise-managed workload with policy boundaries. When implemented properly, this gives us the best balance between productivity, storage efficiency, and security. I’d be very interested in hearing how others are handling this in their environments: Are you deploying OneDrive at the machine level? Are you enforcing Files On-Demand by default? How are you segmenting policy by user class or device type? Have you measured the impact on VHD/VHDX growth or profile size after enforcement? Source document: https://github.com/RodrigoACriscuolo/criscra/blob/main/Home.Profile-Bloat
Windows server 2022 is not updating with latest patch KB5126655
Windows server 2022 is not updating with latest patch KB5126655. However, successfully installed 2026-10 Cumulative update for .Net framework. Last successful Cumulative update for the operating system version 21H2 is 2026-06. Try to update the latest patch manually, the server is rolling back the patch.KB5122882 and Intel SATA RAID boot problem
There is a bigger issue on Supermicro motherboards when Intel SATA RAID is configured: the system fails to boot after an update. I have verified this on three different boards; X9SCL-F, X11SCW-F, X11SSL-F, after a second restart : A disk read error occurred The array is functioning correctly; I can see it when running the system from an ISO, and I have tested all possible boot repair options.
Windows Server 2025 – DHCP Failover con dos controladores de dominio: el ámbito no se sincroniza
Hola buenas a todos. Recientemente he configurado una implementación de DHCP Failover entre dos controladores de dominio con Windows Server 2025 (DC1 y DC2), utilizando el modo Hot Standby. La configuración del ámbito se replica correctamente después de la configuración inicial, pero después de realizar cualquier cambio manual en las opciones del ámbito (por ejemplo, modificar la puerta de enlace predeterminada o añadir una nueva reserva), los cambios no se sincronizan automáticamente con el servidor asociado. Cada vez tengo que ejecutar manualmente «Replicar ámbito». Ambos servidores están en la misma subred y pueden comunicarse sin problemas. ¿Se trata de un problema conocido de DHCP Failover en Windows Server 2025, o hay alguna configuración específica que pueda estar pasando por alto para habilitar la replicación automática de los cambios realizados en el ámbito? Gracias.
Error install Cumulative Update for .NET on Server 24H2 (0x80070bc9)
Hello everyone, I became the problem first during the .NET updates in 08/2026 and it persists until now. During the installation of KB5127690 came an error 0x80070bc9. What I have tried: - run the WSUS troubleshooter - check EFI partition space (200MB / 100% free) - rename the update cache folders - run DISM and SFC - check pending reboot registry keys Unfortunately I did not find solution how to solve this problem. There is link to CBS.log from the server (Windows Server 24H2 (26100.33650), VM on Hyper-V). Many thanks for an answer in advance. R.Announcing Native NVMe in Windows Server 2025: Ushering in a New Era of Storage Performance
We’re thrilled to announce the arrival of Native NVMe support in Windows Server 2025—a leap forward in storage innovation that will redefine what’s possible for your most demanding workloads. Modern NVMe (Non-Volatile Memory Express) SSDs now operate more efficiently with Windows Server. This improvement comes from a redesigned Windows storage stack that no longer treats all storage devices as SCSI (Small Computer System Interface) devices—a method traditionally used for older, slower drives. By eliminating the need to convert NVMe commands into SCSI commands, Windows Server reduces processing overhead and latency. Additionally, the whole I/O processing workflow is redesigned for extreme performance. This release is the result of close collaboration between our engineering teams and hardware partners, and it serves as a cornerstone in modernizing our storage stack. Native NVMe is now generally available (GA) with an opt-in model (disabled by default as of October’s latest cumulative update for WS2025). Switch onto Native NVMe as soon as possible or you are leaving performance gains on the table! Stay tuned for more updates from our team as we transition to a dramatically faster, more efficient storage future. Why Native NVMe and why now? Modern NVMe devices—like PCIe Gen5 enterprise SSDs capable of 3.3 million IOPS, or HBAs delivering over 10 million IOPS on a single disk—are pushing the boundaries of what storage can do. SCSI-based I/O processing can’t keep up because it uses a single-queue model, originally designed for rotational disks, where protocols like SATA support just one queue with up to 32 commands. In contrast, NVMe was designed from the ground up for flash storage and supports up to 64,000 queues, with each queue capable of handling up to 64,000 commands simultaneously. With Native NVMe in Windows Server 2025, the storage stack is purpose-built for modern hardware—eliminating translation layers and legacy constraints. Here’s what that means for you: Massive IOPS Gains: Direct, multi-queue access to NVMe devices means you can finally reach the true limits of your hardware. Lower Latency: Traditional SCSI-based stacks rely on shared locks and synchronization mechanisms in the kernel I/O path to manage resources. Native NVMe enables streamlined, lock-free I/O paths that slash round-trip times for every operation. CPU Efficiency: A leaner, optimized stack frees up compute for your workloads instead of storage overhead. Future-Ready Features: Native support for advanced NVMe capabilities like multi-queue and direct submission ensures you’re ready for next-gen storage innovation. Performance Data Using DiskSpd.exe, basic performance testing shows that with Native NVMe enabled, WS2025 systems can deliver up to ~80% more IOPS and a ~45% savings in CPU cycles per I/O on 4K random read workloads on NTFS volumes when compared to WS2022. This test ran on a host with Intel Dual Socket CPU (208 logical processors, 128GB RAM) and a Solidigm SB5PH27X038T 3.5TB NVMe device. The test can be recreated by running "diskspd.exe -b4k -r -Su -t8 -L -o32 -W10 -d30 testfile1.dat > output.dat" and modifying the parameters as desired. Results may vary. Top Use Cases: Where You’ll See the Difference Try Native NVMe on servers running your enterprise applications. These gains are not just for synthetic benchmarks—they translate directly to faster database transactions, quicker VM operations, and more responsive file and analytics workloads. SQL Server and OLTP: Shorter transaction times, higher IOPS, and lower tail latency under mixed read/write workloads. Hyper‑V and virtualization: Faster VM boot, checkpoint operations, and live migration with reduced storage contention. High‑performance file servers: Faster large‑file reads/writes and quicker metadata operations (copy, backup, restore). AI/ML and analytics: Low‑latency access to large datasets and faster ETL, shuffle, and cache/scratch I/O. How to Get Started Check your hardware: Ensure you have NVMe-capable devices that are currently using the Windows NVMe driver (StorNVMe.sys). Note that some NVMe device vendors provide their own drivers, so unless using the in-box Windows NVMe driver, you will not notice any differences. Enable Native NVMe: After applying the 2510-B Latest Cumulative Update (or most recent), add the registry key with the following PowerShell command: reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides /v 1176759950 /t REG_DWORD /d 1 /f Alternatively, use this Group Policy MSI to add the policy that controls the feature then run the local Group Policy Editor to enable the policy (found under Local Computer Policy > Computer Configuration > Administrative Templates > KB5066835 251014_21251 Feature Preview > Windows 11, version 24H2, 25H2). Once Native NVMe is enabled, open Device Manager and ensure that all attached NVMe devices are displayed under the “Storage disks” section. Monitor and Validate: Use Performance Monitor and Windows Admin Center to see the gains for yourself. Or try DiskSpd.exe yourself to measure microbenchmarks in your own environment! A quick way to measure IOPS in Performance Monitor is to set up a histogram chart and add a counter for Physical Disk>Disk Transfers/sec (where the selected instance is a drive that corresponds to one of your attached NVMe devices) then run a synthetic workload with DiskSpd. Compare the numbers before and after enabling Native NVMe to see the realized difference in your real environment! Join the Storage Revolution This is more than just a feature—it’s a new foundation for Windows Server storage, built for the future. We can’t wait for you to experience the difference. Share your feedback, ask questions, and join the conversation. Let’s build the future of high-performance Windows Server storage together. Send us your feedback or questions at nativenvme@microsoft.com! — Yash Shekar (and the Windows Server team)
Kerberos Event ID 4771 (0x18) across multiple users while interactive logons succeed
Users are able to perform interactive/manual logons successfully with their current credentials. The failures are also generated outside normal working hours. The Client Address in the 4771 events corresponds to the workstation/IP of the respective user. We have observed many different Client Addresses (at least 15 different source IPs), so the failures are not originating from a single host. As an initial troubleshooting step, we executed: klist purge for one affected user. The Kerberos ticket cache was cleared successfully, but the Event ID 4771 failures continued afterward with no noticeable change. Previous guidance suggested checking for stale/stored credentials, scheduled tasks, Windows services, Credential Manager entries, mapped resources, proxy authentication, or background applications that might be attempting authentication with outdated credentials. Another recommendation was to use Sysmon on an affected workstation and correlate outbound Kerberos traffic on port 88 with the timestamp of the 4771 event in order to identify the process or executable generating the request. Before making changes or deploying additional monitoring software in the client's environment, we would like to determine the safest and most appropriate troubleshooting approach. Given that: interactive logons work normally; 0x18 failures occur for many users; each user's Client Address generally corresponds to their own workstation; the issue occurs across many different workstations; and clearing the Kerberos ticket cache did not change the behavior, what would be the recommended Microsoft troubleshooting method to identify the exact process, service, application, or stored credential generating these failed Kerberos pre-authentication requests? Thank you.
Windows Server 2025 DC with two network adapters registers the NAT IP in DNS
Hi everyone, I'm a student of IT systems administration and I'm practicing with a Windows Server 2025 domain controller in a virtual machine on my laptop. The DC has two network adapters, one in NAT mode to have internet and another one in an internal network 192.168.10.0/24 where I have a Windows 11 client joined to the domain.
Hyper-V Ubuntu VM: Memory Demand Different at Hyper-V and OS Level
Hello all, Looking for advice and insight for a strange problem we are experiencing. We have a cluster of Windows Server 2025 hosts, on which we are using Hyper-V manager to run mostly Windows VMs. To access these VMs, we are using Apache Guacamole which is hosted on a Ubuntu VM on our cluster. We originally assigned 32GB memory to this VM. Recently, we have noticed an increased memory demand for this VM at the Hyper-V level which prompted us to increase the assigned memory of the VM to 64GB. Despite this, the memory demand has continued rising despite no apparent change in the usage of Guacamole. When logging into the VM and observing the memory usage here, the VM is using no where near the amount that is assigned. As shown in the attached images which were taken at the same time: Memory Demand Hyper-V Level (And seems to be continuing to increase...): Memory Demand OS Level: This morning, the memory demand spiked to 95GB on Hyper-V but at OS level was only 12GB and we were forced to restart the VM. The biggest concern is where this discrepancy is coming from and the potential unnecessary disruptions that will be caused from having to restart/rebuild the VM. Has anyone experienced this sort of issue before and found a fix? Can anyone suggest how to debug this issue? TIA
