Blog: Symantec

I was attempting to install SEP on a server that was local to me, but remote to the SEP manager. The problem here is that the SEP manager generates a 90 MB package before pushing it out to the machine and starting the install. This would’ve taken a good bit of time to copy over the VPN to the server here so I decided to take a different approach. I had the installation media for an unmanaged copy of SEP that I installed on the server. From there, I opened the SEP manager, went to clients, and exported the communications settings into a file I named “sylink.xml”. Then I copied the sylink.xml file to the server here and opened the SEP client. Inside Help & Support, click Troubleshooting, and then import communication settings. This tells the client where to look for management. After waiting for a minute or two, I went back into Troubleshooting and saw that the client was looking in the correct location for the server policies.


 

Not too long ago I had a problem updating my virus definitions on a VMware virtual machine.  When I tried to update my Symantec virus definitions on my virtual machine, I kept getting an error message saying my machine could not access a long-named vmdk file.  It said if this file was on a remote computer, I should check my connection, and if it was not, I should check my hard drive (or something along those lines).  The message gave me the option to Retry, Abort, or Continue.  Retry and Continue both made the same error message pop up, and Abort shut my vm down (without deleting some lck files, preventing me from restarting my vm until I manually deleted those).  I tried running different versions of VMs (XP and two Windows 7 machines) and got the same error.   I also didn’t get the error when running Microsoft Updates…only Symantec LiveUpdate.  I had to reinstall VM Workstation to get it to work and I haven’t gotten that error since.


 

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.