This patch5 is not functioning properly, If breaks the access protection
In our case , we use the "Anti-spyware Maximum protection" rule to prevent files from being executed from temp directories. We have set a bunch of exclusions for known applications/installers .
Up and until patch 4 it works fine but from patch5 is is broken : no matter what exclusions you set , everything gets blocked as if there are no exclusions
We noticed this behaviour in the hotfix needed for TIE which we sent to 6000 PC's . 2 weeks ago they gave us VSE88LMLRP5 to try to fix the situation but to no avail : the bug still exists.
We called , logged tickets, tried everything to explain this to McAfee but they don't seem to understand the problem And now they release this buggy thing to the world
this is what we see :
VSE8.8P4 version 1247 -> all ok
with hotfix for TIE version 1263 -> AP no longer works correctly
with patch5 version 1385 -> AP still not working correctly
A very simple test (using teamviewer as an example):
-take a PC , and install VSE88P4
-Download the teamviewer installer
-enable the anti-spyware max protection
-try to run the teamviewer installer
It will not work and in the McAfee log you'll see a Deny Execute for the teamviewer installer
-Set an exclusion fot the teamviewer installer
Now Teamviewer will install (abort the installer , you don't need to actually install the thing)
-Update VSE to Patch5
-enable the anti-spyware max protection and set an exclusion for teamviewer
-try to run teamviewer installer
It will install in 50% of the cases
-try to run teamviewer instalerl again
it will no longer install , despite the exclusion
In the log it gives a deny READ instead of a deny Execute so there is something wrong with the access protection
You can see that to reproduce the problem all you need is a simle PC and VSE . It has nothing to do with ePO , network , environment, .... (support kept asking questions about our ePO , network,... which was very frustrating)
Because it happened with the TIE hotfix , we have no way to uninstall (our PC's have version 1263) so we have to use 4 steps :
-Uninstall vse , but then the 'newer' files remain and stay in memory -> we can't run scripts in this phase
-Install the VSE88LMLRP5 so the v1263 get overwritten with the v1385 files
-Uninstall VSE88LMLRP5 so all files are gone
-Install VSE88LMLRP4 so we get back to v1247
I would advise to not use this version.
It is the TIE hotfix part that breaks the access protection , you won't be able to use custom rules or work with exceptions . I just reverted 6000 PC's back to 220.127.116.117 , after they got the TIE hotfix (18.104.22.1683) which broke the AP .
We are looking into this odd behavior. And, I can see that you did report this to us months ago.
I'm sure we'll be kicking ourselves if this turns out to require a code change.
Since I'm privy to the internal investigation I will post any shareable outcomes here (and to our Known Issues article too if appropriate).
It is good that finally someone looks into it.
I spent the past couple of weeks uninstalling the hotfix (HF929019) on 6000 PC's in our company .
We tried all kinds of utilities (vsecleaner,VSEripper...) but to no avail, Even worse : PC's that were running HIPS gave no more ping reply after the utility and we were unable to send tasks to them.
Maybe useful for those who have the hotfix and experience the same problems :
To restore to the good old P4 level (vse 22.214.171.1247) you need to perform four steps (see my first post here)
1) send a VSE uninstall task to the pc's with VSE 126.96.36.1993 (Hotfix HF929019)
This uninstalls only the files that originally were installed with VSE 188.8.131.527. Some newer drivers keep running which results in a PC that will no longer run VBS and Java scripts.
2) send a VSE 184.108.40.2065 (that's the patch 5 version) install task to the PC's . (We need a version higher than 1263 so the drivers would get overwritten and added to the installcache)
3) send an uninstall task to uninstall the VSE 220.127.116.115 -> only way to remove the drivers that kept running in step 1 because now they get recognised .
4) Install the VSE 18.104.22.1687 (tha's the 'old' VSE with patch 4 )
Following these 4 steps is the only way to roll back to the pre-hotfix state. The time between each step should be as short as possible. In our case, with 6000 PC's affected it meant that at any given time there are PC's which are stranded between 2 steps because the user went home , or undocked to get to a meeting,... Also : during the uninstall steps , the OS will notify the user that there is no AV installed on the system. This prompts some users to try to fix their McAfee. Communication on beforehand is crucial. After the 1st step, the users can't run scripts which results in webpages only load partially, loginscripts not running,...
The day after we found the bug , we proposed a simple clean fix , but no one would listen (or understood the problem) : re-issue patch 4 with a higher internal version number so the system thinks it is an update and overwrites everything. That would have saved me weeks of work and user frustration.
Now I still have a couple of hundred PC's in various states of install/uninstall from users who work from home/vacation/sick/...
I'm still hoping someone re-issues Patch4 with a higer internal version number so I can go to sleep Shouldn't be too hard , and it doesn't need much testing ...
So, you know those troubles you had with trying to downgrade the product - that is the main motivation point behind my Blog articles about Patching VSE.
On of the goals being, avoid having to encounter a scenario where you have to downgrade.
It is really difficult to revert to an older release.
Because of the driver code being shared by multiple products, the drivers do not remove or downgrade when you remove the product - shared files stay on the system if other products are installed that still need them. Therefore, to properly downgrade to an older release you must uninstall _all_ products that use the shared code, then you can reinstall your products to their desired version.
For example, if VSE + HIP is installed then you would have to remove both VSE + HIP (they share our driver code). Then install them and make sure you're installing the desired version.
This is the cleanest way to downgrade.
Yes, and if it had been me , then I would have tested it. I always do.
But in this case it was someone (from the company where we buy our licences) who was unfamiliar with our ePO and checked in the hotfix without stopping/checking the update tasks (or asking me if anything should be stopped) . (they were setting up a TIE POC , they already rolled it out to other customers ). The idea was to set up the TIE server , and then install the hotfix on 10 PC's and do tests.
By may 2nd I figured out that I had to uninstall HIPS for the shared drivers/file reason. We had HIPS running in test on 500 PC's so we didn't lose anything there.
We tried to contact McAfee but we got nowhere (call center talk , people who kept yapping about the length of our passwords, others who wanted all info about our ePO server altough we tried to explain that they could reproduce it in 5 minutes on any PC , ..... )
also : all companies running TIE have the bug because they had to use the hotfix . It only shows when you use the exceptions and not many companies use that feature. Unfortunately , we rely on it to have some control over what users can install.
"We tried to contact McAfee but we got nowhere (call center talk , people who kept yapping about the length of our passwords, others who wanted all info about our ePO server altough we tried to explain that they could reproduce it in 5 minutes on any PC ."
Well that sound nice and familiar....
What the heck is wrong with you guys at Mcafee. This seems to be an Enterprise customer with HIPS, EPO, TIE and maybe ATD for 150'000 a year? Because he has allmost all you offer
why is nobody helping the persons like? Since you force promote ATD and TIE because of RANSOMWARE this has to work!
Finall give a direct escalation line for such people and partners.