How to suppress a custom action to run
Hi All,
We have a weired issue with SEP (Symantec Endpoint Protection) 11.0 upgrade to MR4MP2 (from MR2MP2). Initially, we have used the vendor given MSI to deploy SEP MR2MP2 to all our office machines. But, we have modified the vendor given MSI to include a VBScript custom action to remove the stale folders and registry as part of uninstallation.
Now, we are in the process of upgrading SEP MR2MP2 to MR4MP2 and now also we are planning to use the same vendor given MSI. The problem here is, we can't uninstall the old version and then install the new version since the old version removal requires a machine reboot and we can't avoid this at all (confirmed the same with Symantec Support).
But, rebooting the machine after the old SEP removal will be a security hole as it wont be having any version of AntiVirus till the lates version is installed, especially this is big problem on home computers where they connect to our office via a software VPN line. Hence, we decided to go with the in-place upgrade where we will be installing the latest SEP on the existing version. But, unfortunately, while installing the latest SEP MSI, it's removing the existing version at the end of the latest version installation as part of which the removal custom action is getting executed and the installed folders and registry is being removed by this. And hence SEP is keep on trying to reconfigure the missing files and registry (self healing) and it's a never ending process. We tried modifing the old SEP MSI by removing the custom action, but again, the modified MSI is restarting the SEP services as part of the reconfiguration and it's causing BSOD issues (due to some problem).
So, I am eagerly looking for an option to stop the post removal custom action to run during the in-place upgrade without modifying the old MSI.
Any help on this request will be a great great help for us.
Thanks in advance.
Chetan
+91 9885917768
We have a weired issue with SEP (Symantec Endpoint Protection) 11.0 upgrade to MR4MP2 (from MR2MP2). Initially, we have used the vendor given MSI to deploy SEP MR2MP2 to all our office machines. But, we have modified the vendor given MSI to include a VBScript custom action to remove the stale folders and registry as part of uninstallation.
Now, we are in the process of upgrading SEP MR2MP2 to MR4MP2 and now also we are planning to use the same vendor given MSI. The problem here is, we can't uninstall the old version and then install the new version since the old version removal requires a machine reboot and we can't avoid this at all (confirmed the same with Symantec Support).
But, rebooting the machine after the old SEP removal will be a security hole as it wont be having any version of AntiVirus till the lates version is installed, especially this is big problem on home computers where they connect to our office via a software VPN line. Hence, we decided to go with the in-place upgrade where we will be installing the latest SEP on the existing version. But, unfortunately, while installing the latest SEP MSI, it's removing the existing version at the end of the latest version installation as part of which the removal custom action is getting executed and the installed folders and registry is being removed by this. And hence SEP is keep on trying to reconfigure the missing files and registry (self healing) and it's a never ending process. We tried modifing the old SEP MSI by removing the custom action, but again, the modified MSI is restarting the SEP services as part of the reconfiguration and it's causing BSOD issues (due to some problem).
So, I am eagerly looking for an option to stop the post removal custom action to run during the in-place upgrade without modifying the old MSI.
Any help on this request will be a great great help for us.
Thanks in advance.
Chetan
+91 9885917768
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
ghosh.kunal
14 years ago
NOT REMOVE~="ALL" will run during repair, I am not sure you want that to happen, if you dont want a custom action to run during upgrade, you can implement the following.
Your old application might be writing a key in its GUID under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. Have a System search for that entry, which if found will set a Property. You can include your CA under the condition when that Property is NULL. So in other words your CA will not work when doing an upgrade.
Your old application might be writing a key in its GUID under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. Have a System search for that entry, which if found will set a Property. You can include your CA under the condition when that Property is NULL. So in other words your CA will not work when doing an upgrade.
Posted by:
anonymous_9363
14 years ago
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\UninstallThat's quite a convoluted way to get to what the 'Installed' property already tells you :)
The dilemma is always, where does one stop in providing advice like this? A major upgrade will of course set the UPGRADINGPRODUCTCODE property. Should I have included that? Perhaps it would have been apposite to mention that I wasn't accounting for repair or upgrade scenarios so, fair point.
Posted by:
ghosh.kunal
14 years ago
With all due respect, any application that does not have an entry in that registry key has to be of the era of stone age, and that being the case is quite unlikely.
And with regards to your second point, that could be an approach, but I suggested an alternative way out. Not to say that the easier and simpler way is ALWAYS the right way out, but in case there is nothing wrong with that approach.
And with regards to your second point, that could be an approach, but I suggested an alternative way out. Not to say that the easier and simpler way is ALWAYS the right way out, but in case there is nothing wrong with that approach.
Posted by:
anonymous_9363
14 years ago
Whoa! Easy, tiger! There was no criticism intended in my response. It just seemed to me that detecting the Uninstal key was a long way to go about getting information which is already available using an existing property. On point 2, again, there was no critical intent (indeed, didn't I add "fair point"?) but merely the intent to cover my ommision :)
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.