I have recently installed BES 8 and I am trying to do a discovery using the BES Asset Discovery site.
I have followed all the instructions on the BigFix Asset Discovery Deployment Guide. I am able to execute a scan and I can even see the XML results on the “C:\Program Files\BigFix Enterprise\BES Server\AssetDiscovery\NMAP_ArchiveFolder” folder.
In the XML I see several resources which report as “running”, however, nothing shows up on the “Unmanaged Assets” tab on BES Console.
The UAImporter-NMAP service is running. I am running BES Server with a local Database. The database is configured for both Windows and SQL Authentication.
Try turning off the Importer and re-adding it. I had an issue in version 7 with the same thing happening and it seemed like our importer wasn’t working.
I’ll try and add an attachement but I’ve had problems in the past where it doesn’t want to add the file - could be our firewall and/or proxy settings.
Anyway, the xml file is from one of our subnets that has a mixture of (mainly) Windows XP, a couple of Solaris servers and some routers, etc.
The ‘sunsmpt1’ (161.2.124.61) server in the list is running the Bigfix client on port 1310 whereas the ‘bowling.uk.ba.com’ (161.2.124.244) servers isn’t.
I, also, had a quick look at the NMAP service. Should it be running as ‘Local System’ or the same account name as the Fill DB service?
cidermark - the NMAP Importer service should use the same account as FillDB. I know in the past that if you had the account set and then did an upgrade, it wiped out the account info. This bit us and only after a support call did we realize what had happened.
I have found out that NMAP is returning “open|filtered” for the BES Port (default UDP 52311) during the scan.
Because of this the importer service thinks that machines already have the BES client installed and discard them.
It seems that NMAP will always return “open|filtered” for UDP ports unless the firewall is rejecting the packets which is not a common behavior. I am not sure if this is a bug that should be corrected or not.
The workaround I am using so far is to disable the BES client check by setting the option “ignorebesclients” to 0 (off). In this case all the machines are imported including the ones that really have the client installed.
Yes… If the NMAP scan reports that UDP port 52311 is “open” or “open|filtered”, then it is an indication that the BigFix Agent is already installed and the default behavior is to ignore the computer… The idea behind this is that only the BigFix Agent should be using that port.
The problem you noted (and it might affect several people on this list) is that the way that a UDP scan works (based on my relatively limited networking knowledge) is that NMAP sends a UDP packet to the computer and if the port is closed (no BigFix Agent) then the OS is supposed to respond with a packet indicating it is closed… if NMAP doesn’t get an answer, it indicates that the UDP port is open… The problem with this method is that if the response message is filtered (by a firewall) or lost, then it looks like the system has the agent installed and thus is ignored by our scans… This is not necessarily a great behavior, but this is how UDP scans work and this is the only way we know how to look at a computer without credentials and guess if the BigFix Agent is running.
Are you running scans across subnets (with firewalls in between?)… If so, you might try adding a scanpoint in the same subnet and see if that changes the results.
I tried running a scan on the same subnet as the scan point (which also happens to be the BES Root server), it created a XML file, as before, but this time it did display some of the devices in the console! All the devices that
could
potentially run the agent are now present in the Unmanaged Assets branch - other devices, e.g. Cisco routers, aren’t in the list although they are in the XML file.
F.Y.I - the account that i’m using to log into the console with does have full Admin rights.
Do you happen to know if there’s a direct SQL query that I can use to see if these assets are actually in the DB but just not viewable to me? I’m a complete novice when it comes to MSSQL but if there is a query I can use, I’ll go and harrass our DBA’s.
Thanks,
Mark.
P.S. I’ve also changed the Log In account for the Importer service.
P.P.S. There are no firewalls between the subnet I’m trying to scan and the subnet that the Scan Point is on.
It all seems to be working now! After the ‘partial success’ in my last post which produced 40 U.A.'s. I re-ran nmap on the same subnet and this time it reports 83 U.A.'s
As I was ‘on a roll’ - I retried my original subnet (not on the same subnet as the scan point) and it has now reported 32 devices from that subnet too
Yes I followed your suggestion too. The rough timeline was:-
Corrected the ‘Log In’ account for the NMAP Importer service
Ran a NMAP discovery (Wizard) on a non-local subnet of the Scan Point --> Result : no U.A.'s reported although there were plenty of devices in the XML file on the BF server.
Change the ignorebesclients to 0
Ran a NMAP discovery (Wizard) on a non-local subnet of the Scan Point --> Result : no U.A.'s reported although there were plenty of devices in the XML file on the BF server.
Pulled out hair, gnashed teeth --> Result : went to pub for lunch and a pint
Armed with renewed hope…
Ran a NMAP discovery (Wizard) on the local subnet of the Scan Point --> Result : reported
some
U.A.'s to console - lots more devices reported in the XML file
Ran a 2nd NMAP discovery (Fixlet) on the local subnet of the Scan Point --> Result : reported even more U.A.'sto console
Ran a 3rd NMAP on a non-local subnet of the Scan Point --> Result : found all devices I expected !!!
