Tom's Guide | Tom's Hardware | Tom's Games
 |
 |
 |
Guy's I got a computer that cant access the domain controller and has the message:
"Windows cannot connect to the domain , either because the domain controller is down or otherwise unavailable,or because the computer account was not found"the weird part is none of this is true cause the computer is there in my active directory and my server is up and running.
please help
Sups...
If the computer can ping the DC, remove the computer from AD. Add the client back into a Workgroup, reboot, then re-add the client to the Domain. Then reboot again to login to the Domain.
Life is more painless for those who are brainless.
0 
Sho 'nuff! :-)
"Enough, enough bowing down to disillusion!
Hats off & applause to rogues & evolution!
The ripple effect is too good not to mention.
If you’re not affected, you’re not paying attention!"
0
Pinging the DC doesn't tell you anything. The problem is probably a DNS problem. Make sure the client has the proper DNS settings. Try using NSLOOKUP and see if it can resolve the name that way.
Even if the DNS settings are incorrect on the client, you will still be able to ping, but you won't be able to find the proper services on that server without the proper DNS settings.
0
"Pinging the DC doesn't tell you anything."
Confirming basic connectivity to the DC rules out many things that could be a problem. It tells you quite a bit actually.
Hard to believe a client's DNS settings would magically change out of nowhere. Chances are the client is configured for DNS with DHCP anyway, so more likely if there was a DNS misconfig, it would have been more pervasive than a single computer.
Sure it's possible, but the issue described here is a common problem that the machine account's password between it and AD is out of sync, or the computer's account may have gotten corrupted somehow.
Even the idea that the client failed to get a lease is ruled out because if it did fail, it would be configured with APIPA and would therefore fail to ping the DC.
At the very least, it can't be said that "the problem is probably a DNS problem". It could be, but given the information, it's more likely what Jennifer is alluding to, and her solution would have helped identify it being a DNS problem if the computer couldn't rejoin the domain.
"Enough, enough bowing down to disillusion!
Hats off & applause to rogues & evolution!
The ripple effect is too good not to mention.
If you’re not affected, you’re not paying attention!"
0
I should have been more clear - pinging the DC will tell you nothing in regard to whether it will authenticate a user or not. I will tell you the server is up and the NIC is working but that is about it.
To remove the computer from the domain, add it to a workgroup then re-adding it to the domain it like throwing parts at something until it works. The troubleshooting steps would be check the DNS settings since DNS is how the client finds the DC in the first place. That would be the logical place to start and only takes 5 seconds. NSLOOKUP will also tell you if DNS is set correctly and working - another 5 second test.
No one mentioned anything about DHCP.
"Hard to believe a client's DNS settings would magically change out of nowhere." He didn't say they changed, and he never said it had worked in the past.
If the DNS tests check out, then I'd agree to recreate or reset the computer account and re-add it to the domain. Ignoring the DNS tests first misses the most obvious and most likely problem.
But, if you've got a lot of time on your hands then go ahead and readd it to the domain. When that doesn't work, take 10 seconds and fix the DNS problem.
0
"He didn't say they changed, and he never said it had worked in the past."
I think the computer account in AD already is indicative it worked prior to the issue.
"To remove the computer from the domain, add it to a workgroup then re-adding it to the domain it like throwing parts at something until it works."
Except that is EXACTLY what could be done in this case to fix an issue, and doesn't hurt anything. Are you saying that error message CANNOT be caused by a corrupted computer account in AD? The proposed solution isn't a completely blind thing. This is a very common issue among people who have worked with plenty of AD experience."He didn't say they changed"
OK, so how could this be a DNS problem on the client then?! ROFL! I volunteered the possibility that DHCP isn't working right to attempt to explain the sudden change in the client's DNS settings you are claiming is the issue, but then showed how even that doesn't fit the scenario.
"Ignoring the DNS tests first misses the most obvious and most likely problem."
You're failing to show how this is likely to be the issue. You can't explain how the client's DNS settings magically changed that would be more likely than an out of sync computer account password or corrupted account.
The error message is very indicative of what Jennifer's advice fixes. At best, it's a crap shoot if this is a DNS issue or a computer account issue, and as I've illustrated it's more likely to be an account issue.
The original poster hasn't responded back in over a week. Posting here correcting a completely valid solution is pointless, and only aggravates people in the way you did it. Instead of saying...
"Pinging the DC doesn't tell you anything. The problem is probably a DNS problem."
There is no way you can possibly say this is probably the problem.
How about...
"This could be a DNS problem. Run NSLookup."
"Enough, enough bowing down to disillusion!
Hats off & applause to rogues & evolution!
The ripple effect is too good not to mention.
If you’re not affected, you’re not paying attention!"
0
Heropsycho, your inexperience and youth are showing. Let me try to explain a few things to you.
First of all, a computer account in AD is not indicative at all that it worked in the past. Computer accounts are very often created ahead of time by administrators in larger environment because the person adding the computer to the domain may not have permission to add computer accounts.
Which makes more sense - taking 10 mins. to remove a computer from the domain, reboot, add it back to the domain, reboot again - or take 10 seconds to test for proper DNS settings? If you say the first option, you are probably a consultant being paid by the hour. And, if I correct, your method still doesn't fix the problem.
I didn't say Jennifers solution COULDN'T be the problem, in fact if you took the time to read my post, I said I agreed that could be the problem.
If you don't see how this could be a DNS issue, then you have no right even responding to the question. There isn't enough information provided to answer the question positively, but since there is no mention of DHCP, I'll assume there isn't one. I'll assume there aren't Exchange servers, multiple subnets, routers, firewalls, and a whole host of other things he didn't mention either.
You obviously like to argue but there is no question to anyone who has any experience in AD troubleshooting, that when you get a message saying a computer cannot find a DC, you check IP and DNS settings before removing and adding a machine back into the domain.
0
"Heropsycho, your inexperience and youth are showing."
You don't know anything about my background nor my age. I have worked for Microsoft Premier Product Support resolving complex Active Directory and Exchange issues that would make your head spin. I've deployed Active Directory and supported it for over six years from small businesses to large multidomain, multi-site corporations and government agencies, and am an MCSE 2000 & 2003.
You picked the wrong person to say something that idiotic to.
"Computer accounts are very often created ahead of time by administrators in larger environment because the person adding the computer to the domain may not have permission to add computer accounts."
That's not why computer accounts are prestaged. Prestaging is usually because the client was built using RIS, and prestaging allows the client to automatically join to the domain as a part of the RIS routine. While that certainly is possible in this case, I doubt that since he said "*the* domain controller" has the account, which implies one DC. Sounds like a smaller environment, which most likely doesn't prestage their computer accounts.
Nice try.
"Which makes more sense - taking 10 mins. to remove a computer from the domain, reboot, add it back to the domain, reboot again - or take 10 seconds to test for proper DNS settings?"
What makes more sense? Portraying someone who has a perfectly valid solution to a possible cause of the problem as wrong, or just suggest DNS issues could be the cause instead? If you say the later, you're just being a jerk who can't recognize a valid solution when you see one just so you can inflate your ego.
"I didn't say Jennifers solution COULDN'T be the problem, in fact if you took the time to read my post, I said I agreed that could be the problem."
Actually, you corrected her a week after her post was put up, saying her solution is probably wrong. It's been over a week. Chances are her solution is what worked.
"If you don't see how this could be a DNS issue, then you have no right even responding to the question."
I said at best it's 50-50 which problem it was, so for you to say it's probably a DNS problem is not true. You don't know which it is. You're the one who came into this thread a week after the fact to correct Jennifer.
"no question to anyone who has any experience in AD troubleshooting, that when you get a message saying a computer cannot find a DC, you check IP and DNS settings before removing and adding a machine back into the domain."
Personally, I'd have tried to ping the DC by IP and then by FQDN, but chances are, Jennifer is probably right about this. Just can't see how the client machine's DNS settings would magically change.
And there's no question it's completely rude to come into a stale thread to correct someone's solution, claiming what you're guessing is the root cause is probably correct, when you have no way of knowing that.
"I didn't say Jennifers solution COULDN'T be the problem, in fact if you took the time to read my post, I said I agreed that could be the problem."
You just said her solution is probably not going to fix the issue. I read what you wrote, and never even attempted to twist your words into saying she was definitely wrong. You said she was probably wrong, which is a claim you can't justify. At best it's 50-50.
"You obviously like to argue..."
Yeah, I don't appreciate people coming into a thread that's been stale over a week to correct someone who doesn't need to be corrected. And who started this whole mess? You did, by correcting someone else's perfectly viable solution to the problem.
It's pretty clear you like to argue, which is probably why you posted in a stale thread in the first place.
"Enough, enough bowing down to disillusion!
Hats off & applause to rogues & evolution!
The ripple effect is too good not to mention.
If you’re not affected, you’re not paying attention!"
0  |
 |
 |
This post is quite old and has been locked from receiving new replies. Please create a new posting instead.
| Ads by Google |
