active directory
1045 TopicsSettings 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.22Views0likes1CommentWindows 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.628Views0likes3CommentsCómo delegar la administración de DNS y DHCP en Windows Server 2025 sin dar permisos de Domain Admin
Hola a todos. Soy estudiante de un ciclo de informática y estoy montando un laboratorio con Windows Server 2025 (Standard con entorno gráfico) como controlador de dominio con los roles de DNS y DHCP instalados. Quiero que un segundo usuario pueda gestionar las zonas DNS y los ámbitos DHCP, pero sin que forme parte del grupo Domain Admins. He visto los grupos integrados DNSAdmins y Administradores de DHCP, pero he leído que DNSAdmins puede suponer un riesgo de escalada de privilegios. ¿Cuál es la forma recomendada de hacerlo aplicando el principio de mínimo privilegio? ¿Delegar permisos sobre la zona, usar una unidad organizativa aparte u otra opción?156Views0likes1CommentKerberos 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.145Views0likes1CommentADFS migration issue from 2016 OS to 2025 OS.
We have an ADFS 2016 farm (10.0.14393.6078, Farm Behavior Level 3) using a gMSA service account. We are trying to add an ADFS 2025 node (10.0.26100.33158) using Add-AdfsFarmNode. HTTP SPNs are correctly registered and visible in Active Directory, yet Add-AdfsFarmNode fails with "There were no SPNs set on the service account". Is direct Windows Server 2025 federation server expansion into a Windows Server 2016 ADFS farm supported, and are there known issues with gMSA-based farms?259Views0likes2CommentsClarification Regarding msDFSR-Options After Authoritative SYSVOL Synchronization
Hello, I had a SYSVOL synchronization issue between my domain controllers, so I had to perform an authoritative synchronization of DFSR-replicated SYSVOL. The procedure starts by setting msDFSR-Options=1 on the healthy domain controller. However, after completing the procedure and returning the other DFSR-related values on all domain controllers to their default settings, I could not find any clear information about whether msDFSR-Options should also be returned to its default value. Could you please clarify the following points? Should msDFSR-Options=1 remain configured on DC01 after the authoritative synchronization has been successfully completed, or should the attribute be returned to its default/not-set value? Does keeping msDFSR-Options=1 mean that DC01 will remain the authoritative/source domain controller for future SYSVOL replication? If we later migrate our domain controllers to new servers running Windows Server 2022 or Windows Server 2025, do we need to configure msDFSR-Options=1 on one of the new domain controllers? Or is msDFSR-Options=1 only required temporarily when performing an authoritative SYSVOL synchronization? Thank you in advance for your clarification.Solved293Views0likes5CommentsForce a specific default lock screen and logon image
Dear, I currently have a DC deployed on Windows Server 2019. i want to configure a specific default image on lock screens on Windows 10 pro clients via group policy. Is this possible or is it only compatible with Enterprise or Education editions? Thanks in advance,2.4KViews0likes3Comments¿Cómo podemos mejorar la seguridad de un servidor Windows Server 2025?
Hola, tengo una duda sobre la seguridad en Windows Server 2025. ¿Qué medidas recomendáis para proteger un servidor frente a accesos no autorizados? Por ejemplo, ¿es suficiente con configurar el Firewall de Windows y utilizar políticas de contraseñas, o sería recomendable añadir otras medidas como MFA, auditorías y políticas de grupo (GPO)?284Views0likes1CommentHA 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)304Views0likes1Comment