Can only ping by Netbios name, not FQDN

This is what I know so far:
Name resolution is only partially working. We have 6 VLANs associated with DHCP scopes. Users in some VLANs (IT, VPN, etc) are functioning normal using the same DNS/WINS/DHCP/Domain Controller servers as the other five.

Most users (not all) in the Employee and wireless VLANs can do an NSLOOKUP on FQDNs but they can’t ping by FQDN. They CAN ping by Netbios and IP.

Other users in the same VLANs are able to ping by FQDN.

The affected users' NICs in the employee/VPN VLANs are showing in Network settings as being part on the wireless VLAN but are getting their IP from the Employee VLAN.

DHCP scopes have not been changed except after the fact to take DC01 out of the mix due to issues with CPU saturation.
In DNS,  there are no errors other than an old one which is not related.
WINS has no errors and appears to be functioning properly.
There are no entries in AD logs about broken trusts or anything other than our typical assortment of entries. There is nothing unusual in there.

I have no idea how to even troubleshoot this from this point. Please help.
LVL 12
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Rob CambraManager of InfrastructureCommented:
I think this might be a reverse DNS lookup issue.  Make sure you have a reverse lookup zone in DNS.
GusGallowsAuthor Commented:
We do have reverse lookup zones for each subnet and those have not changed.
When the name address resolution takes place are they all resolving to the same address?

nslookup Server1
ping Server1

If they don't resolve to the same address the place to look is name resolution.  Don't forget that there are local files that are part of the name resolution process.  The files can be found in %windir%\system32\drivers\etc.  Both files do NOT have a file extension (. )

   hosts          for tcp/ip standard name to address resolution
   lmhosts     for Netbios over TCP/IP (netbt) name to address resolution

If they resolve to different addresses you will need to determine WHY they resolve to different addresses, and also perform a tracert (or pathping) to those other addresses.

Good luck.
Webinar: Miercom Evaluates Wi-Fi Security

It's not just about Wi-Fi connectivity anymore. A wireless security breach can cost your business large amounts of time, trouble, and expense. Plus, hear first-hand from Miercom how WatchGuard's Wi-Fi security stacks up against the competition in our upcoming webinar!

GusGallowsAuthor Commented:
They all resolve to the same place and the only items in the hosts file are for a test environment with different names (they don't exist in the production environment/DNS).

I think the NIC showing the wrong network name is a red herring as it appears to be a manually adjustable field. It does not appear to be part of the issue since the IP addresses assigned are for the appropriate network/VLAN/DHCP scope. This little tidbit just came in as well. It appears that this has happened before. Always on a Friday and the first symptom is an inability to access internet sites through proxy. My mind is blown. I am hoping come Monday that everything just starts working, but then I need to find out what is causing this and prevent it going forward.

Could a domain controller that is a primary DNS server for the dhcp scope and has it's CPUs maxed to 100% due to a logging tool cause issue like this? It was the first thing we found while troubleshooting. Killed the process and the domain controller normalized, but the problem did not correct.
Sandeep GuptaConsultantCommented:
first I would suggest to check thoroughly your DHCP scope configs and IPs associated.

check your vlan ip ranges as well.

it would be good if you come up with your configurations so we can find the solution more effectively?
What IP addresses does the wrong FQDN resolve to?

Have you tried adding a trailing "." after the FQDN, to avoid suffixing the name?
For instance, instead of pinging do ping "", with the training .

Of course, if your DNS server fails for a reason or another, the ping command will fail too when using FQDN.
So, we should have an idea of the reason why the ping command did fail (what was the error message?)
GusGallowsAuthor Commented:
Well, guys, it wound up having nothing to do with DHCP. The issue was with our NLS server. It's certificate had expired. This caused Direct Access to act up convincing all servers that were using direct access to think they were all external to the corporate network. Once we renewed the cert, and then updated the cert in IIS using the "netsh http add sslcert ipport= certhash=CERTTHUMBPRINT appid={GUID of IIS AP}". Soon as we did that, everything went back to normal. Thanks for all the advice, but this issue was too vague to diagnose properly. Sorry about that.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
GusGallowsAuthor Commented:
Found the resolution as listed in the ticket.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows 7

From novice to tech pro — start learning today.