Blog: SEP

When attempting to access the SEP Management GUI, I got an error in my browser that said “ssl_error_weak_server_ephemeral_dh_key”. This is caused by weak ciphers which have been deprecated by browser updates.
 
To resolve this you have to modify the SEP server's "server.xml" file to exclude the weak ciphers and include newer and stronger ciphers, as well as replace the Java Cryptography Extension (JCE) files to support the stronger ciphers.

  1. Login to the SEP server and stop the Symantec Endpoint Protection WebService.
  2. Go to C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\conf and open server.xml.
  3. In the server.xml file, find the section with cipher= value under <Service name=”WebService”> and replace the current ciphers listed in the file with the following: ciphers="TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
  4. Download the new JCE files from Java’s website here.
  5. Unzip and save those files to C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jre\lib\security.  Overwrite the existing files in prompted.
  6. Start the Symantec Endpoint Protection WebService back up, and you should be all set.

 

I was curious how I could stop a virus scan in progress from the Symantec Endpoint Protection management console.  It’s a little hard to find, but here’s what I found.

  • Go to Monitors > Logs > Computer Status
  • Select the computer on the top-left Command drop-down 
  • Select Cancel all scans 
  • Select the computer
  • Click Start

 


 

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.


 

When installing or making changes to the Symantec Endpoint Protection client, be aware that the SEP firewall policy can cause Windows Firewall to 'reset' or change its configuration.  I've seen several versions of Windows OS change to an active firewall config with no exceptions under the following 2 conditions: [more]

  • SEP client with an enabled, default firewall policy is installed for the first time
  • Existing SEP client has its applied firewall policy withdrawn

This has been seen with several 11.0.6x builds of SEP, although it may be applicable to other builds as well.  This occurs even though the SEP firewall module (Network Threat Protection) is not installed.  When a Windows desktop has its firewall enabled with no exceptions and there is no group-policy in place to re-apply a previous config, it may become unreachable remotely via any protocol, while at the same time the user may notice no change and continue working normally.  If the Windows client happens to be a server, all connectivity to that server may be lost, except via console.

I suggest rolling out new SEP clients after the firewall policy in that group has already been withdrawn.  For existing clients where the firewall policy needs to be withdrawn or disabled (ie overriding Win7 firewall config), test a small subset of clients in a separate group before making the change to normal production groups.


 

When creating scheduled reports in the SEP Mgmt console, be sure to check your filter settings after creating (see image below).  The default filter is just for the past 24 hour period and also includes all clients SEPM can see.  If you want to set a different coverage interval, such as weekly or monthly, or apply the report just to specific clients or sub-groups, you need to create and save a custom filter. [more]


 

When I logged onto a customer’s terminal server/dc, the c: was completely out of space.  I loaded Space Monger and saw that most of the files taking up room were in c:\program files\sav in .xdb files.  I ran disk cleanup and compressed old files which freed up about 5 GB.

I then started researching what was downloading the xdb files.  I saw that they were dating back to almost 60 days ago and every day since.  Each file was approximately 100 MB. 

I looked at all of the Symantec products on their system and talked with the person who had updated Symantec Antivirus (SAV) to Symantec Endpoint Protection (SEP).  He asked me to check the scheduled tasks, and I discovered that there was a scheduled task that ran to download definitions to the old SAV program before they were upgraded to SEP.  I disabled the scheduled task and deleted the xdb files to finish cleaning up an additional 4 GB space.


 

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.


 

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.


 

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.