Blog: Endpoint Protection

Recently, I was pushing out an upgrade to Symantec Endpoint Protection (SEP) when I came across an issue with a machine that caused the upgrade to fail, though I don’t believe it was caused by the upgrade itself. Basically, the older version of SEP didn’t quite uninstall completely and the new version of SEP didn’t quite install completely. There was just enough stuff broken in SEP so that it was effectively useless. Virus definitions were not downloading and active scan was simply not functioning. The easiest way to resolve this problem, naturally, is to uninstall both versions and reinstall.

Unfortunately, the uninstall failed with a “fatal error”. At this point, I could’ve gone to CleanWipe and had it remove SEP completely for me, but I’ve had instances where CleanWipe doesn’t get rid of all the registry keys and a new install will fail. Below are two links for the manual uninstall document for SEP. [more]

http://www.symantec.com/business/support/index?page=content&id=TECH102261 – How to manually uninstall Symantec Endpoint Protection client from Windows 2000, XP and 2003, 32-bit Editions

http://www.symantec.com/business/support/index?page=content&id=TECH102286 – How to manually uninstall Symantec Endpoint Protection client from Windows Vista, Windows 7, and Windows 2008 32-bit

It’s a long document, but it will effectively let you remove all traces of SEP from your PC.

Conditions:

1. Machines that used to run ISA Firewall client
2. Uninstallation of ISA Firewall client
3. New PROXY settings configured
4. SEP 11.5 installed.

Many machines began getting errors in the application logs from Event Source: crypt32, Event ID: 8.  The description of the error says “Failed auto update retrieval of third-party root list sequence number from: [more]http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt”.

I eventually stumbled across a few forums that eventually led me towards this issue happening after installing SEP 11.5.  What seemed to be happening is that the machines attempted to update its root certificates from Microsoft Update at two hour intervals.  The machine will attempt to connect using the SYSTEM account, so it is important that this account also has the correct PROXY settings.  It is likely that after removal of ISA Firewall client, the settings for the SYSTEM account were left in the registry pointing to the old PROXY server. 

The SYSTEM account can always be found in the registry at HKEY_USERS\S-1-5-18. I found that on machines that were not working, the registry keys under HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings were pointing to the old PROXY script whereas the working ones were pointing to the correct PROXY wpad.dat configuration file.  I had to pull the settings from a newer system because this registry key is a binary key, so you cannot simply type the value.

Be sure that the machine also has unauthenticated user access allowed through any web filtering appliance to www.download.windowsupdate.com also.  
 
More information can be found at http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/1f626f1854285036802574e4002de4c7?OpenDocument

An issue has been identified in the Symantec Endpoint Protection Manager (SEPM) which causes Security Content newer than 12/31/2009 11:59 PM to be considered older than content previous to that date/time. As a temporary workaround, Symantec is currently not incrementing the date on Symantec Endpoint Protection (SEP) Security Content and instead is only incrementing the revision number of the content. A message from Symantec provides this more detailed explanation: "As of early Sunday, January 3, 2010, the Symantec Endpoint Protection antivirus definition version "12/31/2009 rev. 114" has been published. Rev 114 includes all the latest definitions through Jan-2-2010."

As of today, January 5, 2010, CoNetrix definitions are showing a revision number of 116. The revision number should continue to increase as evidence of ongoing updates. [more]

This issue has been identified in the Symantec Endpoint Protection Manager (SEPM) and effects the following products:

• Symantec Endpoint Protection v11.x Product Line
• Symantec Endpoint Protection Small Business Edition v12.x Product Line
• Products which rely on Symantec Endpoint Protection for definition updates (e.g. Symantec Mail Security for Microsoft Exchange or Symantec Mail Security for Domino)

There are no required customer actions for this issue. More specifically, there are no changes an administrator needs to apply in order for the above mitigation to be successful.

For more information, see the following Symantec Knowledge Base article: http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2010010308571348

Symantec Endpoint Protection (SEP) allows additional locations to be defined per client-group.  The main purpose of these is usually to define LiveUpdate settings when the client is not on the network.  Although there are many rule variations to define when the client auto-switches to a secondary location, one common rule-setting is to switchover when the client simply cannot communicate with the management server.  Occasionally, you may have reason to define a second location for your server group(s).  If so, be careful not to have an additional location using the rule mentioned above for your terminal-server group (either explicitly or through inheritance).  Doing so can make your terminal-server SEP clients go 'partially offline' - meaning they show offline locally and do not seem to enforce some policy settings, but continue to apply definition updates and show online in the management console.  A symptom of this behavior that is easy to spot is the SEP icon not displaying in the system tray (assuming you don't have policies defined to intentionally hide it).  Rebooting the terminal server or restarting SMC will resolve the issue temporarily, but it will come back randomly.  This issue has been seen in a production environment using SEP 11.0.4-builds on Windows 2003 SP2 Terminal Services.

The Symantec Endpoint Protection Manager seems to have a few quirks.

While trying to push out a machine using the Find Unmanaged Computers tool, I kept seeing the machine in the unknown computers (example shown below). Pushing clients out to these machines would consistently fail. After disabling the firewall, I hit Search Now and tried the scan again. Once again, the machines would appear in the unknown computers tab.

On a whim, I closed the Find Unmanaged Computers tool and reopened it, filled in all the information, and hit search now. Much to my surprise, it appeared under the correct tab and I was successfully able to push out and install the clients.

I was testing Symantec Endpoint Protection for a short while. After uninstalling endpoint protection I began receiving an error every time that I opened outlook. The error said something to the effect of “Unable to load Add-on please uninstall”.

In Outlook 2003 you should be able to simply remove the add-on within the add-on manager. In Outlook 2007 though it requires a different method. I had to delete a file called Extend.dat (location: C:\Documents and Settings\%username%\Local Settings\Application Data\Microsoft\Outlook) which is the file that stores the cached add-ons. After running Outlook again this file was recreated but this time Outlook did not give me an add-on error.  This seems to apply to other add-ons as well. While searching the web I saw people report that this also works for similar errors after uninstalling AVG antivirus.