10 Essential PowerShell Commands Every Active Directory Administrator Should Know

Active Directory sits at the heart of every enterprise environment. When it breaks — or when you suspect it might — you need to move fast. These 10 PowerShell commands cover the daily reality of AD administration: finding locked users, auditing groups, checking replication health, and reading the event logs that tell you exactly what went wrong and when.

1. Get-ADUser — Finding Users, Checking Account Status, Locked Accounts

Get-ADUser is the most-used command in any AD admin's toolkit. It queries the AD database via LDAP, returning user objects with the properties you request. Without -Properties * it returns only a default subset — you will miss LockedOut, PasswordExpired, and LastLogonDate unless you ask for them explicitly.

Under the hood: AD stores lockoutTime as a 64-bit Windows file time. When PowerShell returns LockedOut: True, it is reading that attribute against the domain's LockoutObservationWindow. LastLogonDate is replicated — LastLogon (non-replicated) is more accurate but only valid on the DC you queried.

Real-world scenario: Three people call the helpdesk on Monday morning saying they cannot log in. Run the filter above first — you will see all locked accounts in one shot, then pipe to Unlock-ADAccount.

2. Get-ADComputer — Querying Computer Objects, Finding Stale Devices

Stale computer objects are a security liability. They can have valid Kerberos tickets, open SMB shares, and group memberships granting access they should not have. Get-ADComputer lets you find and act on them before they become a problem.

Under the hood: Get-ADComputer translates to an LDAP query against the domain. The filter converts to an LDAP filter string sent as an LDAP Search Request. Properties not in the default set require a second round-trip to retrieve.

Real-world scenario: Before a device lifecycle review, generate this CSV for the IT asset team. Disable objects first — move to a "Disabled" OU, wait 30 days for complaints, then delete.

3. Get-ADGroup / Get-ADGroupMember — Group Membership Auditing

Group membership sprawl is one of the most common causes of over-privileged accounts. Users accumulate memberships over years and nobody removes them. Get-ADGroupMember lets you audit who is in what, recursively.

4. Search-ADAccount — Locked, Expired, and Disabled Accounts

Search-ADAccount is purpose-built for bulk account state queries. Where Get-ADUser -Filter requires knowing LDAP attributes, Search-ADAccount gives you readable switches that map to the correct underlying queries.

Under the hood: -LockedOut queries the msDS-User-Account-Control-Computed bit flags. -AccountInactive uses lastLogonTimestamp which replicates every 9–14 days — not exact for very recent activity.

Real-world scenario: Before a major migration, run -AccountInactive with a 90-day timespan. Disable those accounts before cutover — they reduce your attack surface without being missed.

5. Get-ADDomain / Get-ADForest — Domain Health Information

These two commands give you the structural overview of your AD environment: who is the PDC emulator, what is the functional level, which DCs exist, and how forest trusts are wired. Run them when joining a new environment or diagnosing a forest-wide issue.

Real-world scenario: A user reports their password reset is not propagating across offices. Check which DC is the PDC Emulator — it must be reachable from all branches for immediate password propagation. If it is down or unreachable from a site, that is your root cause.

6. Test-ComputerSecureChannel — DC Connectivity and Secure Channel Check

The secure channel is the authenticated connection between a workstation and a domain controller. When it breaks, the machine cannot authenticate users, apply Group Policy, or process Kerberos tickets. This command tests and can repair it without a domain rejoin.

Under the hood: The machine account password stored in HKLM\SECURITY\Policy\Secrets\$MACHINE.ACC must match what AD holds. After a VM snapshot restore they diverge — the channel breaks. -Repair calls NetrServerAuthenticate3 to reset the machine password in both places simultaneously.

Real-world scenario: A developer restores a VM from a 3-month-old snapshot. Group Policy stops applying, network shares fail. Run this — repair takes seconds, no rejoin required.

7. Get-ADDomainController — Listing DCs, Checking Roles and Site Assignments

When diagnosing AD issues you need a DC inventory — roles, site assignments, Global Catalog status. Get-ADDomainController gives you all of this in a single query.

8. Sync-ADObject / repadmin — Forcing Replication

When a change on one DC is not showing up on another, force replication rather than wait. Sync-ADObject replicates a single object immediately. repadmin /syncall triggers a full cycle across all DCs.

Real-world scenario: A password was reset on DC01 but the user still cannot log in at the London office which authenticates against DC02. Sync-ADObject pushes that specific user immediately — no waiting for the scheduled replication interval.

9. Get-ADReplicationFailure — Spotting Replication Errors Before They Become Disasters

Replication failures accumulate silently. By the time users notice problems, a DC may have been out of sync for hours or days. Get-ADReplicationFailure surfaces failures explicitly — error code, failing partner, and consecutive failure count.

Under the hood: Error 8606 typically means a Kerberos issue — the DC's machine account password is out of sync, or DNS is returning the wrong IP for the partner DC. Error 8453 means the replication account lacks permissions. Each error code maps to a specific root cause — always look them up rather than guessing.

Real-world scenario: After replacing a failed DC, set up replication then immediately run Get-ADReplicationFailure -Scope Domain. Catching errors at day 1 is far easier than diagnosing a split-brain AD database two weeks later.

10. Get-WinEvent — Reading AD Event Logs (4740 Lockout, 4625 Failed Logon)

The Security event log is the ground truth for what happened on a DC. Event ID 4740 tells you exactly which machine locked an account. Event ID 4625 shows every failed logon with the source workstation. Without these you are guessing at the cause of lockouts.

Under the hood: Event ID 4740 is written on the PDC Emulator because all lockout processing flows there. The CallerComputer in Properties[1] is the machine that sent the failed authentication — this is how you trace whether it is an Outlook credential cache, a mapped drive, a scheduled task, or a phone with an old password.

Real-world scenario: jsmith is getting locked out repeatedly even after a password reset. The 4740 events show LAPTOP-HR-022 every time. You remote in and find a mapped drive in File Explorer using cached credentials from the old password. Clear it in Windows Credential Manager — lockouts stop immediately.

Pipeline Combos — Three Commands to Save Right Now

The real power of PowerShell is composing these commands. Here are three pipelines that solve common AD problems in a single shot.

Combo 1 — Find and unlock all locked accounts

Combo 2 — Export all Domain Admins with last logon and enabled state

Combo 3 — Check replication health and email alert on failure

Schedule Combo 3 as a Windows Scheduled Task on each DC, running every 4 hours. You will know about replication failures before the helpdesk does.

References

• Get-ADUser — Microsoft Learn
• Get-ADComputer — Microsoft Learn
• Get-ADGroupMember — Microsoft Learn
• Search-ADAccount — Microsoft Learn
• Get-ADDomainController — Microsoft Learn
• Sync-ADObject — Microsoft Learn
• Get-ADReplicationFailure — Microsoft Learn
• Test-ComputerSecureChannel — Microsoft Learn
• Get-WinEvent — Microsoft Learn
• AD DS Audit Policy Recommendations — Microsoft Learn
• AD Replication Error 8606 — Microsoft Learn
• Ask the Directory Services Team — Microsoft Tech Community