Howdy. Let me list vitals, first:
* ePO 5.3.1
* VSE 8.8p6+
* ePO Agent 184.108.40.206+
* Windows 7 64-bit Enterprise SP1 clients; fully updated
* ePO/AD Synch
So, my tale of woe:
I've got a custom Access Protection Policy that's worked fine for a couple years. A couple of months ago, I noticed that machines weren't getting any new blocked apps when I checked the McAfee Console on the local machines. There are a couple of very odd things to this:
* If I modify the items blocked, etc., in the APP, the changes won't trickle down to the client machines, even if I did Wake Up/Force Policy on the ePO side or hit Check New/Enforce Policies in the McAfee Agent Monitor on the client machine -- and I'd see activity in the McAfee Agent Monitor.
* If I play with the Check New/Enforce Policies in the McAfee Agent Monitor, I see activity in the Agent Status window, including things like "Enforcing Policies," but there's no change on the client side.
* If I change the APP on the OU, it'll say that the policy's changed in the ePO console, but, again, no policy change on the client computers. Again, as above, I see activity in the McAfee Agent Monitor.
* If I change the APP by using the "Modify Policies on a Single System" in the ePO console, it'll say that the policy's changed in the console, but, again, no policy change on the client computers. Again, as above, I see activity in the McAfee Agent Monitor.
* We use SCCM imaging. One of the steps before installing an OS, etc., is to add the computer to a Domain and OU. Even if I assign the computer to a Domain and/or OU that uses the McAfee Default APP, the computer gets assigned the custom APP. Really weird. (McAfee software's not on the image.)
The really fun thing is if I downgrade the McAfee Agent to 220.127.116.110, the APPs work great. No problems. Update to 5.0.2 or better? Start having the problem again. An extra fun thing is that I've got folks that are managed by a different server admin and they can switch back and forth to my custom APP without any problem. It's also not a network problem: if I take a freshly-imaged computer and put it on a different network segment, it still has problems.
I haven't had a chance to test on Windows 10 computers. I'm in the process of building an OS-only Windows 7 VM, as well. I'd love to say that this was a Windows Update that causes this problem. I'm also going to just wipe out my custom policy to see what happens.
I'd suggest getting off agent 5.0.2, just not a good product and the policies not applying issue is a known one. Roll back to 4.8 or move forward to 5.0.4 with vse88p8 being aware there is a specific order to do this.
Unfortunately, I have the same problem with the 5.0.4 Agent.
The only Agent that consistently works is 18.104.22.1680. I'd love to roll back everyone to 22.214.171.1240, but a) 4.8 is going to come up on EOL, soon and b) while the result is what we want (working computers), it doesn't fix whatever's causing the problem to begin with, thus it could crop up again.
Not knowing in what order things were done, I would suggest you try this:
Remove all products from a test device
Check in the latest extension for vse 88 as this will update all the access protection rules with the latest from McAfee
see if it applies
With the new syscore, it has made things a fair bit more complicated. If this test work, it might be the order you are doing things or that the AP rules (the default mcafee one) were not updated
Are your extensions up to date? This can happen with invalid characters in your AP policies if not.
If that's not relevant, try this. Open up a client where the Access Protection policy isn't applying. Force an ASCI from the client (not the server). Check the Access Protection log to see if you see block events, likely a block event for a process trying to modify McAfee files and settings. If so, then disable Access Protection on the client, then re-attempt the ASCI, and see if the correct AP policies apply based on the system's OU.
There have been several issues with P4+ and Agent 5+ getting policies to apply correctly, often because the AP rules don't correctly whitelist other McAfee process, and the internal trust between those McAfee processes is broken. Disabling AP may allow those updates to go through.
Thanks, Andre and tkinkead. Tried and didn't work. Here's some more interesting information. (APP = Access Protection Policy.)
* I eventually made a built-from-ISO-up copy of Win 7 Enterprise 64+all updates virtual machine. I made sure that there weren't even errors in Event Viewer. So, blank slate.
* I deleted my custom APP in ePO and switched the APP to "McAfee Default."
* Added VM to domain and into an OU that had the new APP applied to it. (Both ePO container and OU are named "Hawaii.")
* I installed direct-from-McAfee versions of Agent 126.96.36.199 and VSE 8.8p6, and in that order.
* Update from the client side.
Check. Yay. I see the new APP is applied. OK. Let's try changing the APP on only this computer through ePO. Set to "[Pete'sCompany] Default" APP. Update. Check. It now has my old custom APP. Which I deleted. Tested on three physical computers that had fresh (but not from scratch) images and all had the same problem: they start pulling the deleted APP. Further, I found that if I popped these machines into Lost & Found in ePO, then change the APP on either a single computer or the Lost & Found container, there'd be no problem. Even further, if I add a Windows 10 machine to the Hawaii container. It gets the new APP (McAfee Default). I change the APP on the computer or container and it pulls the deleted custom APP. Move the computer into Lost & Found, it pulls that container's APP, just like for a Windows 7 box. Move it back to the Hawaii container and, unlike the Windows 7 boxes, it immediately goes back to the deleted custom APP.
So, anyhow, I essentially tried a more nuclear version of Andre's suggestion and that unfortunately didn't work.
I tried tkinkead's suggestion and that didn't work, either, even using the McAfee Default APP -- and doing an ASCI from client or server. Also, to check if this was some bizarre Windows Update problem, I installed an archived Windows 7 image from March. Same problems.
So, my recommendation was to just add another ePO container and move a few machines into it to see what happens. I have a coworker checking on that.
Yikes, it applied a deleted AP policy? I've never seen that before. Do you use remote Agent Handlers? That's the only thing I could think of that might be caching a policy like that.
Yep. It's like something is caching the policy.
Anyhow, I did get the new ePO containers created. 4 physical machines and one VM to test. I plunked them all in Lost & Found and all but the VM got the Lost & Found APP. I then put them all in the new ePO container and did bunches of Check/Enforce policies from the client side and Agent Wake Up/Update Nows from the server side. They kept the APP from Lost & Found. The VM looks like it may have gotten the policy from the new ePO container, but unless I can duplicate that on a physical machine, I'm going to assume it didn't work.
We checked the external agent handlers. Only one of the 5 physical and 1 VM testers lists as hitting it. Once. That was the Windows 7 box I built from scratch.
I'll check for rogue GUIDs, MAC addresses, and/or duplicate entries. That sounds like something interesting.
I do really thank you folks for ideas.