(imported topic written by SystemAdmin)
BigFix is still using NMAP 4.52 which was released 1/1/08. NMAP 5 has been out a while now 7/16/09 and has better detection capabilites. Is an updated NMAP fixlet on the horizon? Has anyone manually updated the Bigfix NMAP scan point?
John
(imported comment written by SystemAdmin)
Asset Discovery will be updated to use NMAP 5 by early October. The changes are currently undergoing testing.
-Anna
(imported comment written by SystemAdmin)
Excellent! Our Cisco Switches that are detected as HP Digital Senders under NMAP 4 will be happy!
(imported comment written by JackCoates91)
It’s done today, announcement will be sent shortly.
(imported comment written by SystemAdmin)
Jack,
We did the update today (after the WinMo eval webex) and our scan is scheduled for tomorrow, so I will report back how it goes. Thanks!
John
(imported comment written by SystemAdmin)
So we’ve found only minimal improvement with NMAP 5 
Perhaps I will visit the NMAP forums and see if there is any hope for better detection. If I get some answers, I’ll post them here.
BigFix, thanks for the effort in getting this update out the door.
(imported comment written by JackCoates91)
Can you scan the devices with a standalone nmap 5 and post the xml output? That would determine if it’s NMAP or our integration at fault.
(imported comment written by JackCoates91)
Found out today that there’s a problem with upgrading. Until we can publish a fix, you should uninstall and reinstall the importer service on your bigfix server, that should fix it.
(imported comment written by SystemAdmin)
I haven’t gotten around to scanning with plain old NMAP yet. Hopefully by the end of the week.
Sooo, we didn’t realize that the NMAP 5 update required us to recreate our NMAP 4 jobs. We thought we had bigger issues when no data was coming in after the upgrade. Was that documented anywhere?
So we recreated the jobs today and ran a test scan. It failed with this relevance being the cause:
continue if {(exists file whose (name of it starts with “nmap-” AND exists line whose (((exists key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\BESScanner-NMAP” whose (value “NmapVersion” of it as string as version < ") of registry) AND it as lowercase contains “nmap run completed at”) OR ((exists key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\BESScanner-NMAP” whose (value “NmapVersion” of it as string as version >= “4.52”) of registry) AND it as lowercase contains “nmap done at”)) of it) of folder (pathname of windows folder & “\temp\nmap”))}
Here is the NMAP XML Output file from the scan point:
<?xml version="1.0" ?> <?xml-stylesheet href="file:///C:/Program Files (x86)/BigFix Enterprise/BES Client/BESScanner-NMAP/NMAP/nmap.xsl" type="text/xsl"?>Any ideas why this is now failing?
(imported comment written by SystemAdmin)
It’s been a while but we finally got back to this. We started from scratch, uninstalling the Nmap Asset Discovery Import Serivce and the Nmap Scan Point. We then reinstalled. We submitted a test scan and it worked (xml file with valid content in the windows\temp\nmap dir). But the data did bot show up in the BES console under the Unmanaged Assets tab. We then ran another scan with the same parameters as are old scans that were working under Nmap 4. It too seemed to complete successfully but again no data in the console.
So now we are troubleshooting why the data is not making it to the console.
On another note, the version of winpcap BigFix distributes has known issues under Windows 2008, which is what we are using. The latest version (4.1) fixes those issues. We have manually updated to the latest version after the tests above. There was no change in seeing data in the console, which is what we expected since the action was completing successfully before the winpcap update.
I have the standalone output from winpcap, but I’d rather not post it here. Can you tell me where to send it?
(imported comment written by SystemAdmin)
With Jack and his groups help, we found the issue. The NMAP remove / install tasks removed the service account information the task was running under. So upon reinstall, the service had no access to the database. Once we were given the settings to turn on debug logging, the problem was found and corrected within 10 minutes. Hopefully future tasks will flag such potential issues and / or provide a way to preserve settings. Big thanks to all involved!