Hi all

I have a problem that I've been trying to solve for a few days now, as the title suggests; I can access my file server using the IP but I have no access if I use the FQDN. A college of mine usually deals with these network related issues as it's not my strong point but he away on annual leave so you may have to go easy on me.

A point I must make is that just before I started having these issues I was in the server room and accidently tripped over an Ethernet cable which just so happened to be connected to the problem server, but I re-connected it right away!!!

If anyone has any questions or advice please don’t hesitate to post.

Kind regards
Gary

Dani AI

Generated

Brief summary and focused checklist based on the thread: the server (hydra) was reachable by IP but name-based access prompted for credentials and failed; DNS A record for hydra existed on the secondary DC but not the primary; some clients were using the router as their DNS. Good direction from — this looks like a DNS/DHCP/AD replication mismatch rather than a simple SMB fault.

What to check (in order) and why:

  • Confirm every client’s DNS servers and primary DNS suffix (clients must point to your internal DCs, not the router). This determines which DNS zone is authoritative for name lookups.
  • Verify forward and reverse records for the server in the internal zone; forward (A) and PTR must be consistent and use the AD domain name.
  • Check AD/DNS replication between DCs so that a record present on the secondary appears on the primary too — replication issues will leave some machines resolving differently.
  • Re-register the server’s DNS and refresh client caches so stale or incorrect entries are cleared.
  • If name resolution is correct but authentication prompts continue, check Kerberos/SPNs and domain membership — name-based auth relies on correct SPNs and time sync.

Quick commands to run (on appropriate machines):

ipconfig /all
ipconfig /flushdns
ipconfig /registerdns
dcdiag /test:DNS
repadmin /showrepl
setspn -L hydra

Practical follow-ups: if the A/PTR mismatch or missing record is confirmed, remove the stale entry, force replication (repadmin /syncall), and restart the DNS service on the primary DC. If auth still fails, review Security and System logs on hydra for Kerberos or Netlogon errors and re-register SPNs or reset the machine account only after verifying DNS is clean. This sequence targets the root causes discussed by and the responders and avoids needless server restarts while isolating DNS/replication and authentication issues.

Recommended Answers

All 15 Replies

I'm not extremely good at this are but what I can say is that for networks, tripping over a cable could be as simple as "Just plug it back in" or it may escalate to even more server weaknesses but the point is I believe it had something to do with that cable.

For a better answer, we'll your gonna have to wait for morning

Thanks Pilot122x

It is morning time here in Ireland lol, anyway your probably right since the problem started right after that cable was disconnected and reconnected, what I forgot to mention is that there were two cables beside each other and I connected the wrong one first before connecting the right one.

Also, I've just noticed that if RDP onto our ISA server and type \serverName into the run box it works fine but this doesn’t work for any of the client machines.

I also tried \serverName on our DC server but to no avail, however if I use the IP instead of serverName then it works fine albeit a lot slower than normal.

Hope that makes sense!!!

Naturally the IP would work since using the IP means your directly connecting to it, It might be that there is no longer a "serverName" because of the little accident you had with the wires.

My suggestion is you try to contact your college friend to assist.

If that is to no avail you can restart the server but this is entirely up to you and it is only a suggestion. Also if you restart the server warn any users first.

I can access my file server using the IP but I have no access if I use the FQDN

If you can access the target server by IP address but not by name, the problem is generally one of two things...

1) Check your computer's DNS settings. Are they pointing to a DNS server that has the ability to resolve the target server's host name? Have you tried to open a command prompt and use the NSLOOKUP utility?

Open a command prompt, type NSLOOKUP (hit enter). type in the FQDN (hit enter). What is the result?

Dont know how to use NSLOOKUP? --> Using NSLOOKUP to Troubleshoot DNS Issues

2) if you (from your client) or anyone else is no longer able to access the server by host name, contact the DNS administrator that manages the zone for that domain name to make sure the DNS record for the server is still present in the zone.

commented: good one my friend... +3

Somehow - Jorge always beats me to the answers.... OP, do follow JorgeM's post, it's spot on.

Thanks for the advice, I'll try that out when I get a chance (I'm not in the office at the moment) and I'll get back to you with the results.

Regards

1) OK, here's what I got by running NSLOOKUP in command prompt.

C:\Windows\system32>nslookup hydra
Server: wl.capricorn.local
Address: 192.168.2.1

Name: hydra.capricorn.local
Address: 172.16.1.11

C:\Windows\system32>

The problem server is called Hydra and the domain is called Capricorn, it is returning the correct IP.

2) He is on annual leave but I had a look myself in the primary DC but I can't find the entry anywhere however it does exist in the secondary DC for what it's worth!!!

So, you can assume that DNS is set up correctly.

Your PC seems to be setup correctly as well because you only typed "hydra" and your system appended the primary DNS suffix (as it normally would for a PC joined to an Active Directory Domain).

This resource that you are trying to access by name...

Neither of these work?

Open the start, Run box...type

\\hydra\ [hit enter]

\\hydra.capricorn.local\ [hit enter]

Any luck seeing the windows file server window open showing the file shares available on that system?

Hi JorgeM

Both of those inputs give the same result, a blank white screen and a window popping up with the heading "Windows security" and two input boxes for username & password!!! However if I swap \hydra\ for \172.16.1.11\ it works fine.

Also, when I input \hydra\ and try to use my credentials they are not accepted.

Regards

I ran the NSLOOKUP command again on a few servers and this time I got different results.

RESULTS FROM ISA SERVER
C:\Documents and Settings\CVLService>nslookup hydra
*** Can't find server name for address 172.16.0.4: Server failed
Server: UnKnown
Address: 172.16.0.4

Name: hydra.capricorn.local
Address: 172.16.1.11

C:\Documents and Settings\CVLService>nslookup 172.16.1.11
*** Can't find server name for address 172.16.0.4: Server failed
Server: UnKnown
Address: 172.16.0.4

Name: hydra.logix.ie
Address: 172.16.1.11

C:\Documents and Settings\CVLService>

RESULTS FROM PRIMARY DOMAIN CONTROLLER
C:\Users\cvlservice>nslookup hydra
Server: UnKnown
Address: 172.16.0.4

Name: hydra.capricorn.local
Address: 172.16.1.11

C:\Users\cvlservice>nslookup 172.16.1.11
Server: UnKnown
Address: 172.16.0.4

Name: hydra.logix.ie
Address: 172.16.1.11

C:\Users\cvlservice>

RESULTS FROM SECONDARY DOMAIN CONTROLLER
C:\Documents and Settings\cvlservice>nslookup hydra
*** Can't find server name for address 172.16.0.4: Server failed
Server: UnKnown
Address: 172.16.0.4

Name: hydra.capricorn.local
Address: 172.16.1.11

C:\Documents and Settings\cvlservice>nslookup 172.16.1.11
*** Can't find server name for address 172.16.0.4: Server failed
Server: UnKnown
Address: 172.16.0.4

Name: hydra.logix.ie
Address: 172.16.1.11

C:\Documents and Settings\cvlservice>

For what it's worth, the IP 172.16.0.4 is the IP of our primary domain controller, also the domain called logix is an old domain that's not used anymore.

Something else I just noticed is that the run command \hydra\ actually worked on our ISA server and our secondary domain controller but not on our primary domain controller.

Regards

It looks like, based on your NSLOOKUP results, that you have different settings for DNS. In the first post that you included NSLOOKUP results, your computer was communicating with the DNS service at 192.168.2.1. I assume that is your router.

On the second post with results, you are pointing to 172.16.0.4 from the various machines, but you are seeing results with a different DNS domain (hydra.logix.ie vs hydra.capricorn.local). This is very important especially when you are trying to access resources based on NetBIOS name because the computer you are performing this query from will simply append its primary DNS suffix. If the suffix is incorrect, you'll get unexpected results.

My first advice to you is to have every maching on your network point to your internal DNS servers which are likely to be your primary and secondary domain controllers running DNS. Both DNS server should have one zone called capricorn.local which sounds like your domain name for your internal Active Directory instance.

If you have DHCP services running on your router, you should disable them and ensure that all hosts on the internal network are using your DCs for name resoultion. You can configure DHCP server on your internal server with custom scope settings.

Make sure that all computers on the network are configured with the correct primary DNS suffix (capricorn.local). They should all be joined to your internal AD domain.

Once you have your name resultion running correctly, you can continue to troubleshoot as needed, but i think that your AD, DNS, and DHCP services are the foundation of your network that need the correct config.

Thanks for that, I'll apply the changes you suggested and will report back soon.

In Tamil there is statement,"Manusana ivan!!!"

I hope that suits you well ...

It means, You are a beast in knowledge...

Sorry for the delay, I have a bit of an emergency here at the moment involving our nortel phone system, all the phones are making a weird constant ring noise and all the clocks on the phone displays are showing the same incorrect time but the time is not advancing forward either!!!

I'll have to sort this out first before continuing with the file server issue, maybe they are related???

OK, got the phones sorted and followed the advice given by JorgeM and everything seems to be working fine now.

Thanks a million JorgeM.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.