[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 607
  • Last Modified:

Server is in the domain but can not find it in ADUC or dsquery

We have a server that is in our domain.  Authentication works no problem however when we look for in in AD using ADUC or the dsquery command we do not find it.  Any ideas on how to begin to troubleshoot this?  This is a production server so taking it out of and put it back in the domain is not trivial.
0
amnhtech
Asked:
amnhtech
  • 8
  • 7
  • 6
  • +1
1 Solution
 
Joseph MoodyBlogger and wearer of all hats.Commented:
Can you ping the server by FQDN? Ex:

ping server.DOMAINNAME.local
0
 
amnhtechAuthor Commented:
interesting, I can not ping the server.  We did move this server behind a firewall for PCI compliance purposes.  However, I did not consider this an issue till just now since AD authentication continued to work without issue after that.  The firewall does some funky IP address translation and may block ICMP packets. This would explain the inability to respond to PING
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
If you are behind the firewall, can you ping it by FQDN?

If so, try pinging just the common name (SERVERNAME) to see if it appends the domain suffix to the name.
0
Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

 
amnhtechAuthor Commented:
However, while ping does not work, DNS is resolving properly for this server.  I am able to reach it via RDP using the FQDN.  
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
That is good news then! Open up a command prompt and type echo %logonserver%

Now open up Active Directory users and computers. Right click on your domain (top right side of screen) and select Change Domain Controller. Choose the domain controller that is your logon server.

Then go to Actions - Find. Make sure the top two fields are set to:

Find: Computers in: Entire Directory

Search for the server now.
0
 
amnhtechAuthor Commented:
No dice.  I still am unable to find this server.  As stated I tried ADUC (active directory users and computers) and also from the command line I ran the command "dsquery computer forestroot -name <servername>" even so I am unable to locate this computer in AD.  
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
That rules out replication issues. Let me do a bit of research over here and I'll get back with you.

In the mean time, have you ran dcdiag yet?
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
One other thing you may want to do is go through the network wizard on the server.

Just to make sure the domain computer account is created, run:

NETDOM /Domain:MYDOMAIN /user:adminuser /password:apassword MEMBER MYCOMPUTER /JOINDOMAIN
0
 
amnhtechAuthor Commented:
DCDIAG only returned an error on the systemLog test.  The netdom binary is not installed on the server in question.  Did you mean for me to run it on one of the Domain Controllers?  If so the syntax is different from what you showed here.  Will this require a reboot of the server if I run the command?  I ask because that is one of the switches (/reboot)
0
 
Renato Montenegro RusticiIT SpecialistCommented:
If the computer is not in the Active Directory database, then it's not a valid domain member and you should just add it (someone removed the account by accident?). You can go ahead and remove the server from domain (if the account does not even exist, you don't have to supply a username and password when asked), let it restart and then rejoin.

Make a full system state backup prior to removing the computer from the domain. If anything becomes missing after the procedure, you can go back and restore the system state.
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
It will require a reboot.
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
And you run this on the server that isn't showing up in AD. If that command doesn't work, you may want to remove it from the domain and add it back (so that a domain account is created).

That wouldn't explain why you can still use domain cred. to connect though.
0
 
Renato Montenegro RusticiIT SpecialistCommented:
It will require a restart. Try to schedule it with the users.
0
 
amnhtechAuthor Commented:
Just to add some complexity to this :) the server in question hosts an application that uses MSSQL backend. All the users who use this app are using domain authentication for sql.  Neither the users nor the application administrator has indicated any issues.  I state this to say that I thought it could be cached credentials that allow me to continue logging on to the server but the users who connect to the database do not cache their credentials at all.

0
 
amnhtechAuthor Commented:
Thanks to all for commenting.  It seems that I found the problem.  We cloned the server for archiving purposes and my coworker was told by a consultant visiting us that sysprep was over rated and unnecessary.  So we did not run sysprep.  The cloned server was renamed and readded to the domain to act as a test environment.  It seemed that the duplicate SID cause the account to be renamed in ADUC.  We are going to  run sysprep on the clone and then take the original out of the domain and re-add it.  

I will keep the question open for a few days in case someone has some other thoughts.

0
 
Renato Montenegro RusticiIT SpecialistCommented:
The consultant is half right and used the information the wrong way. You really don't have to run sysprep in computers that will become domain members, but it's mandatory to run it if they will become domain controllers.

The Machine SID Duplication Myth (and Why Sysprep Matters)
http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx

The problem is that the server already was a domain member. In that case, you should remove the domain member, make the clone, rename it and then join both of them to the domain. Doing that, the Active Directory will append a different RID (remenber the RID Master FSMO role?) to each SID, making each machine unique. If you clone a computer that is a domain member, both (the original and the clone) are in fact the same thing with the same SID and RID.
0
 
Renato Montenegro RusticiIT SpecialistCommented:
Just to clarify, as I said in my first post, if you had removed the server from the domain and then rejoined, it would have worked just fine, because they would have been totally different computer accounts (same SID, but different RIDs).

If it was not there, it was invalid in some way.
0
 
amnhtechAuthor Commented:
Ah that makes lots of sense
0
 
Azeem PatelSystem AdministartorCommented:
If the machine is behind the firewall then your team must have open standard TCP/UDP ports on the firewall to communicate with the server hence you are not facing the problem for authenticating.

You will have to open IP to IP communication from the server to machine from which you are trying to run DSquery which will be better, or open port 389 for ldap query or as FW admin to monitor the hit from the machine on which you are running dsquery so he can open the port accordingly.
0
 
Renato Montenegro RusticiIT SpecialistCommented:
He was trying to run dsquery in the domain controller in order to find the "lost computer". There's a firewall between this "lost computer" (now, "found computer" :) ) and the domain controller.
0
 
amnhtechAuthor Commented:
I am only awarding a "B" because it was not the answer to the original question but it clarified the why re: what I found in our environment.  Thanks for your assistance
0
 
Renato Montenegro RusticiIT SpecialistCommented:
It's always a pleasure and.. a challenge!
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 8
  • 7
  • 6
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now