Skip to main content

Windows - Windows Logon Service

The logon process for how a system connects to a DC is pretty striaghtforward (read: Simple, but not easy)

  1. Workstation comes online and queries DNS SRV records to find all DCs

  2. Workstation attempts LDAP connection to ALL DCs found.

  3. Workstation queries DNS for site information.

  4. Workstation compares site information received with its own network ID.

  5. Workstation attempts LDAP connection to all DCs in its site

  6. If no DCs in its site respond, Workstation attempts LDAP connection to all DCs in the domain

  7. First DC to respond is where the Workstation attempts to authenticate.

If this is giving odd results - workstations routinely log onto DCs not in their site - check out where the DCs reside in Sites and Services and correct as needed.

It’s also possible the Workstation is on a subnet that isn’t defined to Sites & Services and this also would need to be corrected.

 

Check

I would recommend to ensure the below IP settings on each domain controller:

  1. Each DC / DNS server points to its private IP address as primary DNS server and other internal DNS servers as secondary ones

  2. Each DC has just one IP address and one network adapter is enabled (disable unused NICs).

  3. If multiple NICs (enabled and disabled) are present on server, make sure the active NIC is on top in NIC binding.

  4. Contact your ISP and get valid DNS IPs from them and add it in to the forwarders, Do not set public DNS server in TCP/IP setting of DC.

 

How To Fix DFS Replication Event 4012 on Domain Controller

1. Verifying Server Promotion Status

The first crucial step in resolving DFS replication Event ID 4012 is to verify the server’s promotion status. Any discrepancies in the promotion process can lead to issues with DFSR. Administrators can use tools like Active Directory Users and Computers (ADUC) or PowerShell commands to ensure that the server has been successfully promoted to a domain controller.

2. Adjusting MaxOfflineTimeInDays

An easy fix for Event ID 4012 involves adjusting the MaxOfflineTimeInDays parameter. This parameter determines the maximum duration a server can remain offline before triggering the error. If the server was offline for an extended period, increasing this threshold can resolve the issue.

Using WMIC Commands for MaxOfflineTimeInDays

To check the current MaxOfflineTimeInDays value, administrators can use the following command:

wmic.exe /namespace:\\root\microsoftdfs path dfsrMachineConfig get MaxOfflineTimeinDays

To increase the MaxOfflineTimeInDays value, use the following command, setting it to a value higher than the time the server was offline:

wmic.exe /namespace:\\root\microsoftdfs path dfsrMachineConfig set MaxOfflineTimeinDays=400

These commands provide a quick and efficient way to address the time constraint set by MaxOfflineTimeInDays, ensuring that the DFS Replication service can resume without encountering the 4012 error.

3. Initiating DFS Replication Partnerships

Starting DFS Replication Partnerships involves establishing connections to enable the synchronized replication of data between servers. One method to achieve this is by manually running DFS replication using the repadmin /syncall /AeD command or initiate it through the Active Directory Sites and Services console.

The repadmin cmd provides a direct and efficient way to trigger synchronization across all domain controllers, aiding in the resolution of replication interruptions and maintaining consistent data distribution.

4. Set MaxOfflineTimeInDays Back to Default 60 Days

Once the replication is complete set MaxOfflineTimeInDays value back to default 60 Days

wmic.exe /namespace:\\root\microsoftdfs path dfsrMachineConfig set MaxOfflineTimeinDays=60
Back to top