Blog: Symantec

Symantec Endpoint Protection clients that have been cloned and rolled out for production may be misconfigured. I recently found out that Sysprep does not remove the hardware ID for SEP. Which prevents the client from appearing in the SEP console properly. Since all the systems will have the same hardware ID, as they check in it will replace the previous system that checked in. The clients will still receive updates, but the console will not allow you to track all the clients. To fix the problem a new hardware ID for Symantec must be created. [more]

1. Delete %programfiles%\Common Files\Symantec Shared\HWID\sephwid.xml
2. Open the registry and navigate to HKLM\Software\Symantec\Symantec Endpoint Protection\SMC\Sylink\Sylnk
3. Edit the “HardwareID” value data to be blank
4. Restart the Symantec Management Client (SMC) service in the services snap-in

 The client will generate a new unique Hardware ID and sephwid.xml

I recently upgraded a Windows server to the latest version of Symantec Endpoint Protection and the server was no longer accessible on the network after the upgrade.  The server would not respond to network requests even though the console was working.  It turned out the full SEP feature set was installed, including the SEP firewall.  Additionally, now the firewall policy was applied to the server.  This caused the SEP firewall to isolate the server from the network. 

 To fix the problem I uninstalled Enpoint Protection and reinstalled without the firewall feature set.  I also applied a firewall policy just in case the firewall feature was installed on that server again.  My suggestion is to modify the SEP installation document, so that a firewall policy is not applied.

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

When logging into the Symanted Endpoint Protection Management Console (SEPMC) console, keep in mind that the username is case-sensitive.  This is true whether the account you're using is set for 'Symantec Management Server Authentication' or MS 'Directory Authentication'.  You have to match the case of the username as it is listed within the console. The case as set in the console does not have to match case of the username as shown in MS-ADUC when using Directory Authentication.

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

A user a one of our client's site was experienc an issue where a Symantec Antivirus full scan was started when the user logged in every morning.  The scan was scheduled to run at 1:00 AM, but it seemed to be ignoring the schedule.  The problem was caused by the computer being in sleep mode during the evening when the scan was scheduled to run.  The scheduled scan would not bring the computer out of sleep mode to run the scan at the scheduled time.  As soon as the started to login the computer would come out of sleep mode and the scan would start.  The power saving options are a per use setting.  Without group policies in place, this setting must be completed for each user on each computer.

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.

We recently ran into a problem where one of our customer's servers was randomly rebooting. It looked like the cause of this was the updates from Backup exec that were being downloaded and installed. We checked backup exec and it was not set to install updates at all. After some research we found that they updates were being installed even though it wasn't set to do so. [more]

We noticed the updates were occurring the same time as the SMSE updates. After researching with Symantec I found that by default Backup Exec is registered with LiveUpdate and is configured to receive updates ANYTIME LiveUpdate is run from ANY Symantec application configured to use LiveUpdate. Thus every time that SMSE started LiveUpdate it would install Backup Exec updates as well. I downloaded a utility (BeUpdateOps.exe) that I used to unregister Backup Exec from LiveUpdate and this stopped the random reboots.