Endpoint Protection

Testing RU5 client update with the patch SEP32_75to333_clientMSPMSI.exe from the ftp site and also and upgrade from the SEPM.  I get SEP showing up in Add/Remove twice, both for 11.0.4202.75 and 11.0.5002.333.  Log attached if anyone from support looks at this.

Well, that makes what, 2 or 3 of us.
I had that happen on a server. When launching SEP on the computer, MSI installer service would launch and say it was installing. Then SEP would open. A couple things said they were not working or disabled, and you could not disable anything as if they were locked. Protection for outlook balked and errored about a file mis-match.
I had to spend a day manually tweaking to get the old trimmed down so that the new would finally properly install.
Now I've got a workstation doing similar - RU5 won't install but acts like it did, and there's a mix of old and new files in the Symantec folders.
Sort of points to some issues with the package upgrade using groups in SEM. At least that's what it looks like - but the last computer here was a push using the upgrade wizard which up to this point has never ever failed us.
Will be interesting to see what's up on this one - unfortunately, I'm not good at reading MSI or installer logs.

Just an update on this.  I called support to see if they had anything on this yet, they said no one else had reported it.  After testing a few things we found it came down to the policy I had on the machines requiring a password to uninstall the client.  Once I removed that password from the policy I was able to update several clients with RU5 without an issue.  Another thing I noticed with this was before this change the client services for sep would not restart after the upgrade on its own. After the password removal the services on the client restart fine as well. I'll get all the upgrades done and put the password policy back in place.  Just wanted to update this incase someone else has the same problem.

Greetings,

I checked out the install log, it would appear the install went fine. Based on what I am seeing, the duplicate entry for 11.0.4202.x is just a registry key that is not getting removed during the migration that is displaying in Add/Remove.

To test this, I would suggest getting a test box that won't matter if the install messes up due to this. Once you have that, try the following:

-Click Start > Run
-Type: regedit
-Navigate to the following keys:

HKEY_CLASSES_ROOT\Installer\Products\
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\

-On each key, highlight it and hit CTRL+F
-Type 11.0.4202 and hit search
-I am sure you will find an entry for this in one of the above keys, when you do delete the main folder that it is under on the left hand side. The folder you delete will be a hexidecimal type folder similar to {A4MSMA-3RVSDV-32GGDSV-325R23G}

After you remove any of these entries you can go to Add/Remove and verify if its there or not. If it is, select it and go to change. You should get an error saying it was already uninstalled and the entry will purge itself.

As far as a more permanent fix I would suggest getting a case opened with Symantec so we can get this information passed over to our engineering team.

I'm seeing the same problem Luce describes on the one machine that I upgraded. I do have a password in place for uninstalling.
Having a password and upgrading never used to be a problem with older versions.

Anyone have any other info on this problem?

If you're looking to clean up the add/remove list of dead or bogus entries, the registry cleaner in CCleaner will probably do the trick.  It is one of my favorite utilities.

I know how to clean out the entry, but I would rather not do anything extra than just upgrade the machines.