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.
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 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.
HA Print Service Windows 2025 Server
There are two servers running Windows Server, both with the Print Spooler service enabled. They share the same printer queues. I created a CNAME alias named "printcore" pointing to Server01; the client can successfully connect to the printer using the UNC path `\\printcore\hpprincipal`, but if I change the alias to point to Server02, the client's connection to the printer fails. I enabled the Service Principal Name (SPN), but that didn't solve the issue. I need help setting up a High Availability (HA) environment for the print service. Alias: `printcore` (pointing to Server01 and Server02)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.Encrypted vhdx moved to new host, boots without pin or recovery key
Hyper-V environment. Enabled VTPM on guest Server, 2022 OS and encrypted OS drive C:\ with BitLocker. Host server 2022 has physical TPM. Shut down guest OS and copied vhdx file to another Hyper-V host server that is completely off network (also server 2022 with a physical TPM). Created a new VM based on the "encrypted" vhdx. I was able to start the VM without needing a PIN or a recovery key. Doesn't this defeat the whole point of encrypting vhd's? Searching says that this should not be possible, but I replicated it twice on two different off network Hyper-V host servers. Another odd thing is that when the guest boots on the new host and you log in, the drive is NOT encrypted. So, where's the security in that? Does anyone have any ideas on this or if I'm missing something completely? Or have I just made Microsoft angry for pointing out this glaring flaw??Server 2019 Domain Controllers BSOD After August/September 2026 CUs (KB5120238 / KB5122876)
Wondering if anyone else is seeing this. We've encountered a consistent issue across our environment where all Windows Server 2019 Domain Controllers fail to boot after installing the August and September 2026 cumulative updates. The behaviour is 100% reproducible and affects both writable DCs and RODCs. Updates are being deployed from MECM. Affected Updates KB5120238 - August 2026 Cumulative Update KB5121645 - August 2026 .NET Framework Update KB5122876 - September 2026 Cumulative Update KB5126144 - September 2026 .NET Framework Update Environment Windows Server 2019 (Build 17763) Hyper-V virtual machines Roles: Active Directory Domain Services DNS DHCP File and Storage Services Sophos Server Endpoint installed Sophos Core Agent 2026.2.1.3.0 Sophos Intercept X 2024.1.2.1.0 Affected Servers 2 x Windows Server 2019 writable Domain Controllers 3 x Windows Server 2019 Read-Only Domain Controllers Unaffected Servers 14 x Windows Server 2019 servers, which are not domain controllers This is what makes the issue particularly interesting. Every Server 2019 DC is affected, while all member servers install the same updates without issue. Symptoms Updates install successfully through MECM. After rebooting to complete installation, the server applies the update to 30%, then restarts, and when booting crashes during start-up with: CRITICAL_SERVICE_FAILED The machine then enters a boot loop and never completes start-up. Recovery The only successful recovery method we've found is: dism /image:C:\ /cleanup-image /revertpendingactions After rebooting, Windows rolls back the update and the server starts normally. Investigation Performed Analysed MEMORY.DMP using WinDbg Checked CBS.log Reviewed Code Integrity Operational logs Reviewed BCDEdit configuration Verified DCDIAG results after rollback Compared Secure Boot settings Compared Hyper-V configuration Sadly, nothing obvious stands out. Bugcheck Information Event ID 1001 reports: 0x0000005A Fourth bugcheck parameter: 0xC0000428 WinDbg analysis shows: CRITICAL_SERVICE_FAILED (0x5A) Crash occurs during driver initialization within: nt!IopLoadDriver nt!IopInitializeSystemDrivers nt!IoInitSystem The status code "0xC0000428", translates to "Windows cannot verify the digital signature for this file.". What We've Ruled Out Sophos versions are identical on affected and unaffected servers. Issue persists even after Sophos is removed. Secure Boot is enabled everywhere. Hyper-V platform is identical. No specific third-party driver has been identified in dump analysis. CBS logs don't identify a problematic package or driver. Current Assessment At this point the evidence seems to indicate a boot-time driver signature validation issue introduced by the August/September 2026 cumulative update chain that specifically impacts Windows Server 2019 Domain Controllers. I'm particularly interested to know: Has anyone else seen this on Server 2019 DCs? Any correlation with AD DS specifically? Has anyone identified the driver or component failing signature validation? Any successful workaround other than reverting pending actions?
Hyper-v Ubuntu 26.04LTS Multiple DHCP entries
Good evening, am running windows server 2022 datacenter edition, which is running multiple hyper-v machines. I have been installing a new instance of ubuntu 26.04.1LTS but have noticed something weird. Maybe you could assist. Issue: When fresh install Ubuntu 26.04.1 into a VM using hyper-v, I notice 2 IP addresses appear in windows DHCP (192.168.40.20, 192.168.40.21). When I shut down the instance only one disappears (192.168.40.21). If I delete 192.168.40.20 and restart the VM instance both Ip addresses reappear in DHCP. Points to note: Image was downloaded direct off the website with no changes (have redownloaded to make sure image is not broken) Have tried using a different name for the server Have noticed the ubuntu instance only picks up one address (192.168.40.21) for the adaptor. Am unable to ping 192.168.40.20 or connect to that address via ssh. Would anyone have any idea, where the second IP address would be coming from in DHCP?
