Been trying for hours to resolve an issue where failed updates in the past had put the agent into a not behaving state (wont take updates, deployments from ePO, wont enforce new policies, using the uninstall by command wont work even with the /forceuninstall option.
The issue is two part, 1 of a known issue and one that is not. The known part of this is the issue where naprdmgr (product manager) has been running for greater than 7 days. By design, the service tries to restart itself, but VSE stops it from restarting due to the “Prevent McAfee Services from Being Restarted” option being on in policy. Yes, that’s correct, It didnt even even trust itself to restart the service lol. Only resolution for the known issue from McAfee is “This does not occur with McAfee Agent 5.x. Well that’s great, but once the system is in this state, the Agent stops listening to ePO and therefore you can’t push the new agent 5.x to it (or install locally etc.). In some cases restarting the McAfee Framework Service will resolve it locally, in most cases it will not. McAfee released VSE P9 and said it greatly improved the validation process of trusted services (which tells me basically to expect inconsistent validations without). Again, this is great but how do you get the new policy\patch to apply to the machine if its not responding as described above? The other part to this is this can happen when trying to upgrade a older agent\product to a new one without following the recommended upgrade path. Failed installations\upgrades leave file mismatches and can\will create the agent to be in a funky state.
Well, here it is!
Open a command prompt on the local machine and enter this….
REG ADD "HKLM\Software\Wow6432Node\McAfee\SystemCore\VSCore\On Access Scanner\BehaviourBlocking" /v APEnabled /t REG_DWORD /d 0 /f
This will turn off the Access Protection\Self Protection, thus allowing the agent to now restart the services needed to perform upgrades\updates from ePO. This can also be performed to remote machines by psexec, sms task, or any other remote admin tool you want to use.
Behaviors to look for this to be as a fix
Agent log can\will show “failed to restart Product Manager”. This is naPRDmgr.exe
Agent log can\will show agent sub system is in a failed state, or failed to restart agent subsystem
Agent fails to enforce new policies defined on the Epo that is assigned to the agent
Deployments of products\agent installs fail even with the force install option
I don't believe that will work. The AP rule Common Standard Protectionrevent modification of McAfee files and settings will block manually editing the key. If you have an enterprise support contract you can request a ripper tool which is the best method to resolve install issues. It can also be used with the development kit (eedk) to create a package that will rip everything, reboot and then perform a fresh agent install.
I can guarantee this works as I have performed this multiple times today. This WILL NOT work if you open regedit GUI to perform the registry modification (because of the prevent modification protection), but does work if using command shell with elevated permissions.
We also tested this by deploying this using SMS as part of a task sequence (task 1 create the registry mod, task two send package deployment). One thing we found using SMS though was it did not work using the credentials SMS by default uses to initiate package installs, but did work when specifying a Network Access Account in SMS of a elevated user account.
For reference, these machines this worked on were running MA 4.8.x, and various patch levels of VSE 8.8
I tested with CMA 5.0.6 and VSE 8.8p9 and was not able to change the value of the key via an elevated command prompt and running with local admin privileges. I'm glad you found a solution that works for you but there appears to be more to it which will prevent others from replicating.
I have seen this scenario when attempting to install CMA 5.x on a system running 8.7. The default AP policies for 8.7 don't have the CMA 5.x processes included as exclusions since VSE 8.7 doesn't even know about the changes made in CMA 5.x. This doesn't seem to be your exact issue as you're not running 8.7 but may still be similar.
Since the issue is resolved when AP is disabled I recommend checking the AP rules locally on a machine. Verify everything that's set to block is also set to report. Then retry the install without attempting to disable AP. If AP made a block it should be listed in the AP log or displayed in epo. If something is discovered update the policy with this new process exclusion.
Also verify the version epo, and extensions for CMA and VSE.