PDQ Inventory not resolving hostnames any more?
Hi
PDQ Inventory was working fine, but has stopped being able to resolve hostnames.
LAN is simple, basic router, no WINS, no DNS, no domain, just a simple stand-alone setup
Suspect a windows update changed something? All PCs latest Windows 10. All machines "fresh and clean" with the necessary firewall settings for PDQ.
The computer CAN resolve hostnames from the command prompt "e.g. ping PC2" will resolve IPv4 address. UNC from PDQ machine to any PC works fine etc.
PDQ tool, RDP and event viewer work fine, but manage with MMC does not (though if run compmgmt manually, and then connect to remote PC that works).
Adding a remote PC hostname/IP to the hosts file - and everything starts working (!) for that PC.
So.…
- Its NOT firewall related on local or remote hosts
- Its NOT remote host related
- Adding hostname/IP to local hosts on PDQ machine and it works fine
- Hostnames DO resolve from command prompt.
- If machine is removed from PDQ and re-added, we get a green tick on host name resolution on the add box, but then does not resolve for scanning/heartbeat
Its as if PDQ is now using DNS to resolve the hostname (which is router DNS, so internet only - no LAN resolution) - and it checks hosts file - but does not check NETBIOS cache or try NetBIOS name resolution.
As mentioned, it did work since install till a couple of months ago.
I don't really want to give things fixed IP and add them to the hosts file lol - so any ideas?
(I don't think its a PDQ issue - but hope someone here had the same and can help)
Thanks 😃
-
The timeline sounds similar to the issues we are seeing. I think the problem came around the time of the introduction of the Inventory Agent in version 16. Prior to that we didn't have any problems with heartbeat / waking / restart & shutdown commands. Can we get confirmation PDQ isn't checking NETBIOS?
-
Can we get an answer from PDQ on this? Highly frustrating that we can't utilize host files in emergency situations anymore.
With Covid everyone is still working off VPN, which is often not friendly with DNS. And historically host files have always been our saving grace in situations like this. But now there is no way to connect to a remote PC even if I know the IP address. Even if I hardcode the IP address in the host file on the central server, flush DNS, restart the PDQ services, PDQ still ignores the host file. The host file is supposed to the MASTER of hostname translation. Why is it being ignored?
And to reply to Jim. Yeah, Dynamic DNS is the first thing that should be implemented.
-
Hey Colby, thanks for chiming in!
Just by your message, I see I'm a version or two behind. I'll update to see if that helps. I've tried to squeeze as much helpful info as I could into one screenshot.
This is a central server, and for now, while troubleshooting this I'm using the console on the server (not remotely connecting from a workstation).
Server 2012 R2
PDQ 19.0.40.0 (Edit: It looks like this IS the latest version)
I've updated the host file (with a tab between the IP and hostname). The underlying OS picks up on this change just fine, and I'm able to ping the hostname just fine. It's resolving the IP in the host file, and bypassing Windows/AD DNS. All is good thus far.
But in PDQ, it's not picking up on the change. For good measure, I'll flush the DNS cache, restart the DNS Client service, and restart both PDQ services. All to no avail, PDQ is still picking up the stale IP from AD DNS, and not the host file.Yes... I know I should have a perfectly working DNS system for PDQ to work. That would be ideal and great in a perfect world. But we're a global company with about 60,000 endpoints. DNS is managed by an entirely separate team, I can't touch DNS. I'm just a sole SysAdmin at a site of about 40 users. Yes, they are aware that their Cisco ASA VPN DHCP server is not properly dynamically updating DNS when handing out DHCP leases to remote VPN clients. But it's a slow-moving process at a company this size. Nothing happens overnight, it takes months.
EDIT, direct link to screenshot, as it seems this forum compresses it and makes it a little hard to read the fine text: https://imgur.com/a/EhNOg4P
Please sign in to leave a comment.
Comments
11 comments