Active Directory troubleshooting: dcdiag, repadmin, nltest and lockouts

Start DC01, DC02, SRV01, NODE1 and CL01. Work as SAATLAB\adm.rahul in PowerShell as administrator.

1Run a five-minute health check

On DC01:

dcdiag /s:DC01 /q
dcdiag /s:DC02 /q
repadmin /replsummary

You’ll see something like this:

Replication Summary Start Time: 2026-10-19 15:10:04

Beginning data collection for replication summary, this may take awhile:
  ....

Source DSA          largest delta    fails/total %%   error
 DC01                      08m:41s    0 /   5    0
 DC02                      06m:12s    0 /   5    0

Destination DSA     largest delta    fails/total %%   error
 DC01                      06m:12s    0 /   5    0
 DC02                      08m:41s    0 /   5    0

dcdiag /q printed nothing, which is what you want: quiet mode only shows failures. Zero fails in the summary means both DCs replicate every partition. A large delta (hours or days) or a number in the error column is your first lead.

✅ Checkpoint: dcdiag /q is silent for both DCs and repadmin /replsummary shows 0 fails.

2Check the DC locator and secure channel

On CL01:

nltest /dsgetdc:saatlab.internal
nltest /sc_query:saatlab.internal
Test-ComputerSecureChannel

You’ll see something like this:

           DC: \\DC01.saatlab.internal
      Address: \\10.0.0.10
     Dom Name: saatlab.internal
     Our Site Name: HQ
     Dc Site Name: HQ
The command completed successfully

Flags: 30 HAS_IP  HAS_TIMESERV
Trusted DC Name \\DC01.saatlab.internal
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

True

CL01 is in site HQ and found DC01 in the same site. The secure channel (the computer account’s trust with the domain) is healthy. If Test-ComputerSecureChannel returns False, users see “The trust relationship between this workstation and the primary domain failed”.

✅ Checkpoint: nltest finds DC01 in site HQ, the secure channel status is NERR_Success, and Test-ComputerSecureChannel returns True.

3Read Kerberos tickets and check time

On CL01, clear tickets, use a share, then list tickets and the time source:

klist purge
Get-ChildItem \\SRV01\Departments | Out-Null
klist | Select-String 'Server:'
w32tm /query /source
w32tm /stripchart /computer:DC01 /samples:3 /dataonly

You’ll see something like this:

	Server: krbtgt/SAATLAB.INTERNAL @ SAATLAB.INTERNAL
	Server: cifs/SRV01 @ SAATLAB.INTERNAL
DC01.saatlab.internal
Tracking DC01 [10.0.0.10:123].
Collecting 3 samples.
The current time is 19/10/2026 15:14:02.
15:14:02, +00.0021433s
15:14:04, +00.0018807s
15:14:06, +00.0020112s

You got a TGT (krbtgt) and a service ticket for cifs/SRV01, so Kerberos works. CL01 syncs from DC01 and is about 2 ms off, well inside the 5-minute limit. If you only see NTLM (no cifs ticket), check the name you used, the SPN and time.

✅ Checkpoint: klist shows krbtgt and cifs/SRV01 tickets, and the time offset to DC01 is a few milliseconds.

4Lock out an account and trace the source

On CL01, use a wrong password 11 times (the lockout threshold from Lesson 19 is 10):

1..11 | ForEach-Object { net use \\SRV01\IPC$ /user:SAATLAB\kiran.das WrongPass1 2>$null }
net use \\SRV01\IPC$ /user:SAATLAB\kiran.das WrongPass1

You’ll see something like this:

System error 1909 has occurred.

The referenced account is currently locked out and may not be logged on to.

On DC01 (the PDC emulator), find the lockout and its caller:

(Get-ADDomain).PDCEmulator
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4740 } -MaxEvents 1 | ForEach-Object {
    $x = [xml]$_.ToXml()
    [pscustomobject]@{
        Time   = $_.TimeCreated
        User   = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
        Caller = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetDomainName').'#text'
    }
}
Search-ADAccount -LockedOut | Select-Object SamAccountName

You’ll see something like this:

DC01.saatlab.internal

Time                User      Caller
----                ----      ------
19/10/2026 15:18:40 kiran.das SRV01

SamAccountName
--------------
kiran.das

In event 4740, the TargetDomainName field holds the caller computer name: here SRV01, because CL01 authenticated to SRV01 and SRV01 checked the password with the DC. So you’d look next at SRV01’s 4625 events, which show CL01 (10.0.0.150) as the source. Follow the trail until you reach the device or process with the wrong password.

Clear the lockout:

Unlock-ADAccount kiran.das
(Get-ADUser kiran.das -Properties LockedOut).LockedOut

You should see this:

False

✅ Checkpoint: Event 4740 named the caller computer, and kiran.das is unlocked.

5Follow one change from DC02 to DC01

On DC01, create a user on DC02, check DC01, then force replication:

New-ADUser test.repl -Path 'OU=Staff,OU=SAATLAB,DC=saatlab,DC=internal' -Server DC02
Get-ADUser test.repl -Server DC01
repadmin /syncall DC02 /AdeP | Select-String 'SyncAll terminated'
Get-ADUser test.repl -Server DC01 | Select-Object Name
repadmin /showobjmeta DC01 'CN=test.repl,OU=Staff,OU=SAATLAB,DC=saatlab,DC=internal' | Select-String 'whenCreated'

You’ll see something like this:

Get-ADUser : Cannot find an object with identity: 'test.repl' under: 'DC=saatlab,DC=internal'.
SyncAll terminated with no errors.

Name
----
test.repl
     1    Branch\DC02        1081736       19/10/2026 15:22:31      1 whenCreated

The user existed on DC02 but not yet on DC01, because inter-site replication runs on a schedule (Lesson 31). After the forced sync, /showobjmeta proves the change came from Branch\DC02. Delete the test user when you’re done with Remove-ADUser test.repl -Confirm:$false.

✅ Checkpoint: test.repl appeared on DC01 after repadmin /syncall, and showobjmeta shows DC02 as the originating DC.