We have a few hundred corrupted VSE clients which wa can't re-install nor remove
(The agent doesn't detect the currently installed versions nor can't (re)deploy the latest VSE)
In the past we were able to manully fix those by manually removing VSE as instructed in the KB71179 (How to manually remove VirusScan Enterprise 8.8)
But these processes only work for VSE8.8 with Patch 0 to 4, we're using Patch 6 (SYSCore 15.3 or later drivers)
I can't seem to find any instructions to get rid of the corrupted AV installations.
Where can I find instructions to remove these versions?
We need to fix these?
Is there an optional solution via epo to fix these clients (the agents are working (MA 22.214.171.124 & epo 5.3.1))
There is a tool we have been developing, commonly referred to as the Ripper tool. It has been used commonly for install related problems up to and including when Patch 5 came along. But with patch 6 the underlying technologies also carried with them additional protections that the Ripper tool could not bypass and thus required additional engineering work.
That has been a work in progress since the end of last year.
If you engage Support and work with them to quantify your present need, you can be added to a queue of customers who are waiting on a release of the Ripper tool that will work when SYSCore 15.4 (the underlying technology I referred to) is installed - since it might get installed by other products too, not just VSE; MA 5.0.2 for example also installs SYSCore 15.4.
Be aware though, the tool is an extremely dangerous tool. It removes our software whether the installation was healthy or not. As such, it is not to be handed out lightly.
We take measures to ensure the tool expires so it will not execute after a certain date. We do not claim it to be a supported tool, but naturally if it fails to do something we want it to do then we want to look into the issue and try to improve it. We test it internally but that testing is limited. Reboots are not always avoidable, so if you're facing a need to use the tool then expect to reboot the device afterwards.
Support's goal is not to hand you such a tool but rather to investigate the issue that led to your need for it, so that root cause can be identified and solved (or avoided somehow). This is rather challenging though, especially if the state of the machine has changed since the incident occurred, or the incident was transient in nature, or something environmental is at play etc. We've had success investigating these types of issues if they are reproducible in a Virtual Machine that can be shared with us.
Thx for the feedback it's good to know there is such a removal tool (in development), I probably come back to this later on.
Our main problem is that the issued clients do have VSE 8.8 (with or without Patch1) installed but do not report any VSE installed to the eposerver.
We do deploy Patch6 to our clients but Patch 6 cant be installed unless you have Patch 2 or higher installed (which is not the case here)
We can't add Patch 2 to our repository (complaints it alread contains Patch6)
I was able to fix (does not work on all) a few of them by manually install VSE8.8 incl Patch6
SetupVSE.exe REBOOT=R ADDLOCAL=ALL /q /l*v C:\Temp\VSEinstall.log
In a few case I manually installed Patch1 & 2 separately (to get patch6 installed automatically via epo)
But these manual interactions are not a good sollution as we have a few hundred of them
In that scenario , the goal I would shoot for is uninstall the incumbent product and then push down a full install package rather than trying to patch. If you can avoid patching numerous times, MSI will thank you for it (Patching again and again, as much as we try to make the result the same as a full install, the "how you got there" does matter)
That uninstall doesn't require ePO; if you have other system management tools available that can execute a command (the uninstall string). Or, do a quick check on why the systems aren't showing up in ePO - fix that - and use ePO to do the uninstall + install of the full package. If it's just the plugin flag being set to 8, hopefully that's an easy fix for you to reset it to 0. If in doubt, I trust Support can help.
Aye, removal of the software (and no reboot) means you'll still have some drivers loaded.
A subsequent install of a different version or differing patch level (and still no reboot) will mean both old and new drivers are in memory. And that can have consequences.
The best practice is to reboot a system after having made system-level changes (that applies to any software where kernel-level components, like drivers, are updated/modified). The functionality of the product almost never requires that a reboot occurs, but the stability of the system may and you won't know it (until it crashes, but then of course, reboot has been achieved).
Reboots should definitely be planned for after making a system change like patching our software. Microsoft make you reboot when you patch the kernel...
There's a special case scenario where a reboot needs to occur or you risk a broken installation, broken product etc. That is when downgrading SYSCore versions.
This is a fairly recent development in our code but it's unavoidable. If you have a product of ours that uses SYSCore (and there are more each year using this shared technology), should you encounter a situation forcing you to go down a path of downgrading that installed SYSCore version - which will mean removing all the installed products sharing that technology, and reinstalling them at a version+patch that avoids the issue which prompted the downgrade - then, a reboot after the removals is complete is required. If the reboot does not occur, the subsequent installations are likely to fail.
I can't uninstall my ENS 10 eval version. I even could not install it because I had MA 4.8 patch 3 still installed.
Now there a several ENS processes running and I can't uninstall them. I even can't reinstall anything from mcafee
I suggest taking the ENS discussion over to the ENS pages.
It wouldn't make sense to try and respond here... the short answer though is contact Support.
i confirm - i opened a ticket for about 45 vs 805 clients that aren't upgrading from vse 8.8 p6 to p7 and now they are stuck on every install uninstall action. 1st lvl support in not providing the ripper tool. they ask to "pay a tax".... upload MER files so they can internally escalate and then hopefully (for us , the client) we will receive the tool to attempt the VSE removal , to then attempt a reinstall.