This content has been marked as final. Show 14 replies
The data is kept in the file, firenetprefs.txt. It won't matter that you know the name of the file, it's not readable. That file is encoded and if you change it, HIP will think it's corrupted and replace it with a backup copy.
What's the problem?
I'm in a pretty large environment, and we use another product (from CA) to inventory our software and settings on our workstations. Our CA people are wanting to be able to determine the LearnMode setting via that capability. Since the data is encoded, we won't be able to do it. However, in meantime, we've determined that we can report these settings via a direct SQL query of our EPO databases.
What's happened is that we are currently deploying in Adaptive Mode, and occasionally that file must be getting corrupted and being placed in default mode. In default mode, it is interfering with our CA products and we are trying to be proactive in finding those machines and getting them back into regular mode.
I thought that I was right about the firenetprefs file, but it is good to get confirmation.
If the firenetprefs is getting corrupted, it sounds like your experiencing the CMA policy corruption problem. What version of CMA are you running?
You've got patch 3 installed but did you perform the mitigation?
KB article 614122
All you really have to do is disable HIPS and delete the firenetprefs.txt file. Re-enable HIPS and send an agent wakeup call. This will create another firenetprefs.txt.
The server.xml and compiled.xml are the source of the corrupted firenetprefs.txt.
They have to be removed prior to ASCI or CMA won't request a new policy from the ePO server.
server.xml and compiled.xml should have already been recreated. If you look in the directory you will see the corrupt xml files and the newly created xml files. The only thing that doesn't get recreated is the firenetprefs.txt. If you delete it, it will pull the new policies.
If you want peace of mind you can delete the corrupt files.
If the server and compiled XML's don't need to be deleted, why would McAfee create a KB article telling you to do that. Wouldn't you think that if it wasnt' necessary they wouldn't put it in the article?
BTW, once you get corrupted, you'll keep getting corrupted due to the fact that if CMA performs 2 ASCI's within 1 minute, the second ASCI will be ask for an incremental policy.
HIP requires a full policy with every ASCI. If HIP receives an incremental policy, it will lose all it's firewall rules and quarantine the system. The only way to recover from that is to boot into safe mode disable the firesvc. SeaWalker has been lucky enough that HIP sees empty firenetprefs and replaces it with the backup, fireknownprefs.txt.
If you doubt the KB article's instructions, open a support ticket with McAfee.