Endpoint Protection

Hello-

I have used patch files to jump from a particular version of SEP client to another.  This has worked well for me for some time.  Last week, I applied patches to go from 5337 to 6608.  The patch appeared to have behaved as expected, creating new version subdirectories, and the client showed a Windows restart was necessary to complete.  This group of systems was restarted, and none of the clients started!  When I went to services and attempted to start the service, I notice the program path is still 12.1.5337...I hit start (on two of them), and the shield never shows and now I cannot stop the service.  These servers are all part of a mission critical app that takes a several hour downtime to complete a restart.  Is there a way to fix the registry entries to point to the correct bin folder and get this started without reboots?  I tried to replicate the problem using the same VM template, installer for 12.1.5, same patch file, same domain/OU/GPO, and it behaves as expected. 

When starting the service, there are no errors logged in the system or app logs.  I don't see error logs indicating where the patch went wrong.

Thanks,
Joel

Can you run the symhelp tool on it to see if any addtional errors/problems come up:

Troubleshooting computer issues with the Symantec Help support tool

Comes back with several services are set to demand start and they are not started.  Also, "There is more than one Symantec Endpoint Proection product lised in MSI: Symanted Endpoint Protection(12.1.6608.6300), Symantect Endpoint Protection(12.1.5337.5000).

When clicking "Click here for solution", it leads me to... https://support.symantec.com/en_US/article.TECH228174.html

After opening a support case (and getting my profile corrected, hence change in identity), I ended up figuring out my problem on my own.  Turns out, there was a group policy to modify HKLM\System\CurrentControlSet\Control\Session Manager.  Someone had pushed a BootExec key to accomplish something, only they set it as a String Value instead of a Multi String value as it should have been.  By setting it to a String Value, SEP wasn't writing "sisnat{GUID}", or if it was, Group Policy was refreshing and overwriting this key.  As part of an upgrade of the SEP client, whether it be by patch file provided by Symantec or pushing the full version from SEPM, the final step is to create "sisnat{GUID}.exe" to C:\Windows\System32, and add data to the BootExec key.  During a reboot, "sisnat{GUID}" executes, setting all the correct reg values for the new version of SEP.

Luckily, I was able to fix this group policy to push the key as a mult string value, and only run once.  I was then able to add the appropriate "sisnat{GUID}" to this key, restart the server and complete the upgrade process of the SEP client without having to run cleanwipe and reinstall the latest SEP client.  I was also able to find additional OU's with similar Group Policies and fix them before they become an issue for the next person to upgrade SEP!

Glad you've found a way to fix it.

That's why server documentation & change management are very important in our part of our job as IT administrators, as it will help you/others to see what has been changed, avoiding a 'wild goose chase' trying to resolve the issue. :)