Setting up a scan is pretty straight forward, you tell Protect what machine to scan via FQDN, IP or netBIOS then Protect attempts to resolve the machine's DNS. The test existence only fast pings the target machine to see if there is 'something' there, it doesn't ensure proper DNS resolution or is all prerequisites are met.
What version of Protect are you running and did this work in the past?
Are you able to scan other machines on the same sub-domain?
Have you tried scanning the machine via IP or netBIOS?
The error you received would indicate a DNS resolution issue with that machine. For troubleshooting, open a CMD prompt on the Protect server and perform a nslookup by FQDN, IP and netBIOS.
Do they all come back with the correct information? (not sure what type of lookups you performed)
Do you have any host file entries on the Protect server that would be casing a conflict?
Hi Charles -
Thanks for getting back to me. I agree, there really isn't much here to go wrong - but I've been hitting every snag possible it seems!
From the server, I can do an nslookup for the host name, and the FQDN, and they both resolve. NbTStat also returns the expected host name. There are no other host file entries on the protect server - just a vanilla hosts file. From the workstation I can telnet to port 3121 on the server and connect without issue as well.
I was able to scan when I enabled the remote registry on one host - but that's not the way we can proceed here. I installed the agent on the target pc (local install from the the workstation) and was able to get the generic policy I created from the server, but scans still failed. I went to try and install the agent from the console (which would be the bets method) but now it fails as well with the error 'Target machine not found'.
Scans work ok in the parent domain though.
The scans still say connected to a machine with the wrong hostname or domain name and fail almost immediately - but are resolving without issue. It's the 'scan for patches' step in the operation that is bombing.
If I enable remote registry - this all works magically. When I disable it - everthing fails....Did I read it wrong that installing the agent would get us around having to enable the remote registry?
Any thoughts welcome!
I think I have a better understanding of what is going on here. I think we are dealing with a misleading error and the issue most likely has nothing to do with DNS resolution and everything to do with the remote registry being disabled.
The remote registry is required In order to perform scans or agent installs from a Machine Group. In other words, any action from the Machine Group would ignore the fact an agent is installed on the target machine and attempt to directly connect to it. And in your case fail due to the Remote Registry service being disabled.
"Did I read it wrong that installing the agent would get us around having to enable the remote registry?"
No, you didn't read it wrong, I think the issue is the way you are trying to initiate the scan or task. You need to work through the View > Machines when managing machines with agents installed on them. You can locate a machine with an agent installed on it by looking at the Agent State column. (the view is dynamic so you can drag columns to the left to group machines the way you want) Right-click on a machine or machines that has Active in the column and delve down into the Agents options. Here you can perform various tasks like including initiating a scan on the machine under 'Run tasks from Policy' if you need to run a scan outside it's schedule time. Normally, you would set the a task to run on a schedule and not have to manually start a scan, but the option is there when you need it.
More information on how to install agents: How To Install Agents
Creating an Agent Policy: Agent Policy
I can't thank you enough! That was the missing link I needed! I must have completely missed the part where that was discussed in the documentation! Of course that means that deployment to the sub-domain will be kind of a pain - but at least I know what I'm dealing with now.
a million thank yous!!!!
I'm happy that turned out to be the culprit, apologies for the frustration it caused you!
I would have to agree with you about managing machines that have the Remote Registry Service disabled. I definitely understand the need though. Security!
I'm not sure if this will help, but we have an article related to different ways to install the agent: Agent Installs Of course the Push Method in the article would require the Remote Registry service to be enabled. The document also discusses the manual install method or a scripting technique.
More information can also be found in the admin guide and the help files in Protect.
(hyperlinks for you)
Please let us know if you need anything else.
Hi Charles -
Thanks so much for the additional links! I had one more question with regards to grouping these machines that have remote registry disabled. Since I can't manage these guys throught the Machine Groups - can I make any sort of group to organise them? Would this be most likely achieved through an agent policy - or am I just out of luck?
thanks again for everything -
After you have an agent installed on these machines, you can create Smart Filters for the View > Machines. Some ideas for Smart Filters:
Show all machines with an Active agent on it. This would be simply Agent State - contains - Active.
Show all machines with a specific Agent Policy on it. This would make highlighting these machines and running and agent tasks to them. This would be simply Assigned Agent Policy - contains - PolicyName.
You can pretty much create a filter based off of anything you can see in the View - Machines.
Please note: You can right-click on the columns in View - Machines and add additional columns that are not shown by default. I believe the option is Column Chooser when you right-click on the main bar.
I hope that answers your questions.