Any admin knows that there are always computer and user accounts in AD that become stale and unused. It’s good practice to remove these old accounts from AD.
Here’s how I do it.
From any Domain Controller, open a command prompt and try the following.
dsquery computer -inactive 8 -limit 3000
Dsquery is an invaluable tool and can do much more than just this. We tell dsquery to look for computer accounts that are currently inactive for 8 weeks and to limit the display to 3000 entries. Setting the -limit to 0 would return all entries.
If you would simply like to count them:
dsquery computer -inactive 8 -limit 3000 | find /c "-"
This example should also return inactive computer accounts, older than 8 weeks. In this case, we query for stale passwords on computer accounts instead. This should return the same results as the ‘inactive 8’ flag in the previous example.
dsquery computer DC=domain,DC=com -stalepwd 56 -limit 0
Now that we know what computers need to be removed, lets disable them instead of deleting them. Just in case.
Just pipe the information to dsmod to modify their status:
dsquery computer DC=domain,DC=com, -stalepwd 56 -limit 1400 | dsmod computer -disabled yes
Now just sit and wait for maybe a week or two, if no-one calls to report problems, you’re OK to delete the accounts.
To remove the disabled accounts:
dsquery computer DC=fs31,DC=vwf,DC=vwfs-ad –disabled | dsrm
And You’re done!
My business closed one of their remote branches recently. The ex-employees took their time packing and sending the hardware back to our HQ. The Domain Controller was offline for more than a month. When we finally got it back, I recreated the routing and plugged the server back in so that I could run a DCPROMO and take it down gracefully. However, since the server was offline for so long, when I ran DCPROMO, the server complained that it could not sync up with the Domain Controllers. This is the same thing for other windows hosts that have been offline for 30 days. The Event Viewer showed Event ID 3210 and 5722 related to this issue.
This error is also seen when using the AD sites and services snap in to force a replication between domain controllers. I would get the following error window stating “The Target principal name in incorrect”.
How how to fix it:
From any DC, open command line (CMD) and run
netdom query fsmo
That will list out the servers in your Domain with the Domain roles. Look for the server running the PDC role.
Next, on the server that is having the issues we need to disable Kerberos.
1) Click Start -> Programs -> Administrative Tools -> Services
2) Double click the Kerberos service (KDC) and change the startup type to Disabled.
When the machine starts back up, get back to a Command Line (CMD) and reset the secure channel to the PDC with the following command:
netdom resetpwd /server:server_name /userd:domain_nameadministrator/passwordd:administrator_password
Where server_name is the server holding the PDC role. administrator/administrator_password can be substituted for any account that is a Domain Admin.
Restart the troubled DC. Reset the Kerberos Service back to Automatic Startup.
Everything should now be back to normal.
This is a quick and easy way to get a Tabbed list of Usernames and emails from a Windows Domain while on the domain controller.
By using the dsget and dsquery commands, we can list users and then send the output to a file.
dsquery user cn=Users,dc=domain,dc=com -name * -limit 0 | dsget user -display -email > userlist.txt
Dsquery hits ldap and pulls the records, dsget pulls the interesting info from those records and we just use plain old CLI to sent the output to a file.