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

Can you ping the server by FQDN? Ex:

ping server.DOMAINNAME.local

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

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.

However, while ping does not work, DNS is resolving properly for this server.  I am able to reach it via RDP using the FQDN.  

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.

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.  

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?

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

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)

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.

It will require a reboot.

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.

It will require a restart. Try to schedule it with the users.

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.

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.

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.

Ah that makes lots of sense

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.

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.

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

It's always a pleasure and.. a challenge!