I looked for a while for a command to let me find a DC on the domain if I didn't know the name of one. I wanted to be able to do this from any PC on the domain. I found a few eamples of using Netdom and DSquery, but what really solved it for me was

echo %logonserver%

It's simple and easy to do at the command line!

I remembered too that you could Ctrl-Right click on Outlook's system tray icon and choose "Connection status" if Outlook was running, but I was looking for a barebones solution. Maybe this will help someone out there...

Looking at the subject to the post that was going to be my answer. I found that command recently, and have used it a bunch of time since. It's simple and effective for finding out what a clients logon server is. However. Doesn't work for remote command prompt. I wounder if there's a good command for this.

This presumes that your domain is auto-appended behind the scenes, which is often the case. If not, just fully qualify the names (e.g. if your domain is some.local, the above samples would be _gc._tcp.some.local )

Obviously, spending 30 seconds in the Windows DNS zone editor will yield a bunch of other things to look at, such as _msdcs.some.local, and other fun spots.

1st Post

A quick one folks..so what happens when you do an echo %logonserver% and find that the machine you're checking is reading from the DC on it. I have two DCs 1. TRINITY (Primary). 2. LCSEXCH (Secondary)...in this case, it's a secondary DC, but has issues with the AD, and so it's reading from itself upon running echo %logonserver%, rather than the primary. How do I correct that?

A quick one folks..so what happens when you do an echo %logonserver% and find that the machine you're checking is reading from the DC on it. I have two DCs 1. TRINITY (Primary). 2. LCSEXCH (Secondary)...in this case, it's a secondary DC, but has issues with the AD, and so it's reading from itself upon running echo %logonserver%, rather than the primary. How do I correct that?

%logonserver% is going to return the AD DC it authenticated to.... In your situation, I believe you're stating LCSEXCH always look at itself as a DC vs TRINITY as an authentication DC... You're also stating there's a communication issue between the two DC's I believe; regardless, logging onto LCSEXCH will always authenticate it's own AD vs Trinity (ie: imagine there's an issue where TRINITY's hardware fails and LCSEXCH AD will take over as the other DC to do logon authentication).... If there's a communication issue between the two AD's, workstations may vary on which controller they hit depending on the specific issue like DNS, etc... If my assumption is correct, the solution is to fix the issue as to why the DC's won't replicate, which is normally DNS related...