Active Directory - "Domain Controller Not Found"

TechLarry

RIP [H] Brother - June 1, 2022
Joined
Aug 9, 2005
Messages
30,481
I seem to spend way too much time removing and re-adding user machines to the domain because the user starts getting the "Domain Controller Not Found" error message at login.

Is there a quicker way to do this? Maybe a utility that will 'refresh' the AD configuration instead of having to remove it, go back to a workgroup, reboot, go back to AD configuration, etc....

The latter always works, but it's getting on my nerves :)
 
First thing I'd look at, ensure the TCP/IP settings....including DHCP, are correct.

Server MUST look at itself as the DNS server in it's TCP/IP properties (or if more than 1 server...should be the DC)

DHCP MUST hand out the IP address of the DC as the DNS server to the clients...not the router, not the ISPs DNS servers, not OpenDNS, etc.

Perhaps DHCP on a router got enabled by accident?
 
Make sure all your FSMO roles are in tact and the servers holding FSMO roles are available.

If not, computers will drop out of the domain
 
Um, check the name of the machines. I bet you have more than one client with the same name. They connect and it boots the other one.

What we have had to do recently due to the other guy here not renaming machines when he swaps out a shell, then sets up the shell as a new machine (we use serial numbers of the machine as the machine name), is remove the machine from the domain, rename the machine (usually adding a letter A, B, C, D, etc) to the end of the name, run SIDFix (just as a precaution), then re-join the domain.

We also verify the serial number with the machine name to make sure it is named correctly till we find the offending one.
 
First thing I'd look at, ensure the TCP/IP settings....including DHCP, are correct.

Server MUST look at itself as the DNS server in it's TCP/IP properties (or if more than 1 server...should be the DC)

DHCP MUST hand out the IP address of the DC as the DNS server to the clients...not the router, not the ISPs DNS servers, not OpenDNS, etc.

Perhaps DHCP on a router got enabled by accident?

This isn't true. The domain controllers, or AD replicators do NOT have to provide the IP addresses. I've set this up plenty of times.
 
DNS or DHCP issues will NOT drop a computer account out of the domain!

Without knowing the configuration as well as seeing the configuration we are going at this blind.
 
DNS or DHCP issues will NOT drop a computer account out of the domain!

Without knowing the configuration as well as seeing the configuration we are going at this blind.

A FSMO issue would,

What are you known role holders?

DCdiag /test:Knowsofroleholders /v
 
Are you talking about the source of the DHCP service?

Well souce of DHCP doesn't really matter, you can have the router handle DHCP and DNS but its not really standard. Best is to have the server handle it.

If the router handles it, you may have extended logon period depending on DNS, but that alone is not enough to drop a computer from the domain
 
Well souce of DHCP doesn't really matter, you can have the router handle DHCP and DNS but its not really standard. Best is to have the server handle it.

If the router handles it, you may have extended logon period depending on DNS, but that alone is not enough to drop a computer from the domain

Correct...you "can" have a router or other device handle DHCP, I prefer not to for other reasons I'll get to in a second. But for the purpose of this thread....how many of us have seen a router, set fairly standard, handle DHCP for a network and mess things up? //I see quite a few hands raised by experience SMB techs...yup. As some of us may know...a routers defaults may be to hand out itself as the DNS (forwarder)..or the ISPs DNS servers. And...this naturally makes for some wonky and long workstation logins.

Now...yes many routers will allow you to customize their DHCP properties so they can hand out the DNS server that you enter, and even may have WINS options. So yes you can have the router handle DHCP...and things may "appear" to run fine for a long time...but I prefer to have the DC handle it because clients will more properly register themselves with DNS and thus active directory, as the log in. Keeps AD tighter, lets the server more properly do it's job...running the network.

And how many of us have seen servers...domain controllers...with their TCP/IP settings incorrect..such as having the router as their DNS server, or the ISPs DNS servers as its DNS? //looks around while more people raise their hand
Yup..that will break active directory on the DC itself..it'll be useless. This can cascade to more and more issues.

Also I'm sure people have seen cases where a router somehow get reset..and it's DHCP service became enabled. Now...a Windows server that normally runs DHCP will stop its DHCP service on the next reboot (or it can stop by itself) if it detects another DHCP service is present on the network. So a router with default DHCP properties starts blasting incorrect DNS info on the network..makes for little bit of a mess. I've walked into network hiccups where I've seen this happen before.

With DNS and AD screwey on both sides of the coin...weird issues like this can happen. So I'm trying to ensure the OP has the basic best practices in place before moving on.
 
Well souce of DHCP doesn't really matter, you can have the router handle DHCP and DNS but its not really standard. Best is to have the server handle it.

If the router handles it, you may have extended logon period depending on DNS, but that alone is not enough to drop a computer from the domain

Right. It's not normal, but I've set it up before and it can surely be done that way.
 
That's what I guessed you meant, see my above reply as to why I don't like that method.

I completely understand. It is not the best practice, but it can be done. One of the clients I support has their system setup like that. (For reasons unknown to me.)
 
That's what I guessed you meant, see my above reply as to why I don't like that method.

Right, we all have said that isn't the preferred method, but it can be done, thats the point.

However! It should NOT cause a computer to drop from the domain even if the router does have it setup incorrectly. You will just have excessive login times, but you will authenticate to the domain just fine.
 
Right, we all have said that isn't the preferred method, but it can be done, thats the point.

However! It should NOT cause a computer to drop from the domain even if the router does have it setup incorrectly. You will just have excessive login times, but you will authenticate to the domain just fine.

the computer isn't necessarily "dropping from the domain" either. It's just being band-aided by disjoining/rejoining the domain.

he says it simply gives an error message of "domain controller not found"

this is generally due to incorrect DNS.

OP, next time this happens... log in to the machine via local admin account and do an ipconfig.
verify primary DNS is the IP address of the DC.


edit: and yes, I setup a lab with a Win2k3 DC and 2 VM's as workstations. When they did not have the DC's IP as primary DNS, they couldn't join or login to the domain.
 
the computer isn't necessarily "dropping from the domain" either. It's just being band-aided by disjoining/rejoining the domain.

he says it simply gives an error message of "domain controller not found"

this is generally due to incorrect DNS.

OP, next time this happens... log in to the machine via local admin account and do an ipconfig.
verify primary DNS is the IP address of the DC.


edit: and yes, I setup a lab with a Win2k3 DC and 2 VM's as workstations. When they did not have the DC's IP as primary DNS, they couldn't join or login to the domain.

Your right it "could" be, but if DNS was that jacked up that a PC could not log into the domain, then a detach/reattach would not work either due to said DNS issue.

An important note is are all computer affected. If so, you need to test the domain health before anything else.
 
Your right it "could" be, but if DNS was that jacked up that a PC could not log into the domain, then a detach/reattach would not work either due to said DNS issue.

An important note is are all computer affected. If so, you need to test the domain health before anything else.

unless there is a rogue router out there (as was stated somewhere in this thread).
it could be that it just so happens that after a couple reboots it gets the correct settings from the correct DHCP server. Since OP did state he reboots a couple times during said disjoin/rejoin.

hence why I asked to verify DNS settings the next time it happens
 
Since OP did state he reboots a couple times during said disjoin/rejoin.

Where, OP never stated anything about reboots, just that they can't locate the DC and he has to rejoin them.

OP said:
I seem to spend way too much time removing and re-adding user machines to the domain because the user starts getting the "Domain Controller Not Found" error message at login.

Is there a quicker way to do this? Maybe a utility that will 'refresh' the AD configuration instead of having to remove it, go back to a workgroup, reboot, go back to AD configuration, etc....

The latter always works, but it's getting on my nerves
 
I seem to spend way too much time removing and re-adding user machines to the domain because the user starts getting the "Domain Controller Not Found" error message at login.

Is there a quicker way to do this? Maybe a utility that will 'refresh' the AD configuration instead of having to remove it, go back to a workgroup, reboot, go back to AD configuration, etc....

The latter always works, but it's getting on my nerves :)

Where, OP never stated anything about reboots, just that they can't locate the DC and he has to rejoin them.

first post :)
 
Your right it "could" be, but if DNS was that jacked up that a PC could not log into the domain, then a detach/reattach would not work either due to said DNS issue.

An important note is are all computer affected. If so, you need to test the domain health before anything else.

I've seen weird things happen when a network has been running in a non-proper manner for some period of time.

Yes we all know that, if workstations had the incorrect DNS server from DHCP...the logins take a very long time. And same for the server itself...it's bootup/login would take a long time. But..say it's been a bit wonky for a while, and then patched up....but AD records could still be tanked..and it can take months for some problem to surface. Or the server may not have correct TCP/IP settings regarding DNS..and since it may not get rebooted often, the slow login problem may not happen..or perhaps they just think it's a slow server.

Not following best practices...problems sometimes can take a long time to surface. ;)
 
NO SHIT!!!! OMG i didn't know you had to reboot to rejoin a domain.

HOWEVER you indicated that rebooting would fix the issue

ummmm... yeah. I was talking about the reboots during the disjoin/rejoin process. Hence why I even mentioned reboots.

how can you not comprehend that?
 
Last edited:
So according to you guys, DNS is the only thing that could cause this issue?
 
So according to you guys, DNS is the only thing that could cause this issue?

No, but without knowing a heck of a lot of other details about this setup, if I were to walk into a network with these issues, one of the first things I would check is...
*Setup of the server(s)..specifically TCP settings, DNS.
*DHCP, workstations...DNS

I'd run some tests on the DC, ensure all the roles are good.
Naturally check event viewer.

We don't have details about the network...are there more than 1x domain controllers? If so, how are they setup? I've seen several DCs that were never setup properly..eventually you end up with "DNS islands" of data because they're not setup to replicate properly. That network ran for probably over a year before issues started creeping up.

There's a lot of "gotta look at this, look at that" that has to be done..but with the limited details given, that's the first place I'd sit down and look at. And the history of the network...what changed recently.
 
We had this happen the other day...

For some reason, when I moved the virtual machines form VS2005 to hyper-v, they wouldn't log onto the domain. Removing/adding back to domain did nothing. Eventually after deleting the account for the machine in ad it would work. IDK, DNS/WINS where correct, they had static IP's.
 
I've seen weird things happen when a network has been running in a non-proper manner for some period of time.

Yes we all know that, if workstations had the incorrect DNS server from DHCP...the logins take a very long time.

One trick is to pull the network cable. User will login with cached credentials and then re-plug in the NIC. Sometimes you have to this with remote office users that say logging in is taking a long time.
 
One trick is to pull the network cable. User will login with cached credentials and then re-plug in the NIC. Sometimes you have to this with remote office users that say logging in is taking a long time.

Yup I've done that many many times in the situations I've walked into over the years. Familiar with the symptoms and how to get around them....but the point is to find the cause, I'm not a fan of "bandaids...get past it today, worry about it tomorrow".
 
We had this happen the other day...

For some reason, when I moved the virtual machines form VS2005 to hyper-v, they wouldn't log onto the domain. Removing/adding back to domain did nothing. Eventually after deleting the account for the machine in ad it would work. IDK, DNS/WINS where correct, they had static IP's.

I would say your SID changed.
 
Back
Top