Make SEP Manager Console Suck a Little Less

27. June 2011 · Write a comment · Categories: Hack, Software · Tags: , , ,

My biggest complaint about Symantec End Point is that the manager console is slow. On a dual quad-core server with 16GB of RAM, it simply crawls. Sometimes, even when the system load is basically zero, the console is almost unusable. I did a little digging and found that the manager console is, in fact, written in Java –  that explains a lot.

Fortunately, because it’s written in Java there’s a little trick you can you to speed things up a little, assuming you have a decent amount of free RAM. The manager console is typically launched through sesm.bat, which is located (in a default install on an x64 server) in “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\bin\”. Open that .bat file in notepad, and you’ll see this:

@start “SESM” “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jdk\bin\javaw.exe” -Xms128m -Xmx1024m -XX:MinHeapFreeRatio=30 -XX:MaxHeapFreeRatio=40 -Dscm.console.conf=”C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\etc\conf.properties” -jar “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\webapps\scm\clientpkg\scm-ui.jar”

Note the bit that I’ve highlighted above in red. Boost that up a little (I set it to 512m), save, and then re-open the management console. You should notice a significant difference in how fast the console operates now.

From the Search Results: Product Reviews

24. May 2010 · Write a comment · Categories: Meta, Short, Software · Tags: , , ,

To the person who found my blog with the search, “is endpoint good“:

Meh.

(Seriously, though, it’s a matter of perspective — I use Symantec EndPoint 11 (SEP) because I can’t stand McAfee and most of the other enterprise-level antivirus suites, but yeah, it’s not that great).

Symantec Endpoint: Good at Giving Me Heart Attacks

04. May 2010 · 4 comments · Categories: "It's a Feature", Rants, Servers, Software, Troubleshooting · Tags: , ,

Oi. Symantec is definitely giving me a lot to blog about recently.

I logged in to one of our public file servers today for a weekly inspection, and as is someone common was greeted with a dozen reports from Symantec Endpoint 11 of infected files being deleted. It’s not uncommon for our clients to open malicious attachments, visit shady websites, and generally make a mess of things, but a combination of good ACL’s, Deep Freeze, and SEP 11 on the server have kept things clean.

So, after reading through the alerts and verifying SEP cleaned all of the detected files, I ran Live Update followed by a Full System Scan, as is standard procedure. Out of curiosity, I watched the first part of the scan process, when I noticed it pause on these files:

c:windowshide_evr2.sys

c:windows9129837.exe

d:autorun.inf

The first two file names made me worried, and the third a little more so, if only because D: is another RAID array and therefore has no reason to have an Autorun.inf. After a little digging, however, I found that none of these files seemed to exist on the server. Now I started thinking ‘rootkit’.

Sure enough, a quick Google later showed that yes, these files are common to a number of different rootkit variants. As such, I busted out my usual toolkit of malware detection/removal utilities and took the server offline.

As I dug deeper in to the server, though, I still couldn’t find any traces of the mentioned files. I tried several different rootkit tools, browsing the hard drive contents from a Linux LiveCD, and even a few tools to check ADS (Alternate Data Streams), but had no luck.

At this point, I was fairly convinced that the server was clean, however why would Symantec report those files as present, unless…. Digging a little further in to the results from Google, I found this forum thread: http://www.antionline.com/showthread.php?t=278671 – apparently, during the initial part of the scan, Endpoint doesn’t actually report just the files that it’s scanning, it also reports the name of the files it’s looking for.

So, a little life lesson - don’t assume that Symantec will do anything that makes sense. And, when in double, Google is still you’re friend – you just need to look harder.

Sample Symantec Endpoint scan showing a non-existent file

Sample Symantec Endpoint scan showing a non-existent file

The TL;DR version: The scan status on Symantec Endpoint 11 doesn’t just show the actual files on the computer, but it also shows non-existent files that it’s looking for. When in doubt – verify manually!

Low on Server Disk Space? Have Symantec Endpoint? There’s Your Problem

29. April 2010 · 3 comments · Categories: "It's a Feature", Servers, Short, Troubleshooting · Tags: , , ,

This morning, I received an email from a charity I do some consulting for saying that they were getting a Low Disk Space warning on their primary terminal server. After remoting in, I confirmed that on the 120GB primary partition, there was less than 100MB free. Odd, considering that the server only has about 40GB worth of user files on it.

A quick check (done by selecting likely folders in the root of the drive and opening the properties window) confirmed that C:ProgramData was using an extra 40GB space that it shouldn’t. Further digging revealed that C:ProgramDataSymantecSymantec Endpoint ProtectionXfer contained somewhere in the neighbourhood of 48,000 file, each ~20KB in size.

Solution? Delete and recreate the Xfer folder, then run Live Update again. Low disk space problem solved, but would someone at Symantec care to explain just what the hell happened?

Update: Found a temporary fix here: http://www.symantec.com/connect/forums/symatec-ep-making-alot-files-under-xfer-folder

Apparently, the issues results from EndPoint rescanning files in quarantine every time new definitions arrive. If you have a lot of files in quarantine, your disk space will disappear that much faster. Go figure. Apparently they’ve fixed some instances of this, but not others, as it was supposed to have been solved in MR4, but is still present in MR4 and MR5.

Backup EXEC, the Bane of my Existence

11. September 2009 · Write a comment · Categories: Servers, Support, Troubleshooting · Tags: , , ,

Okay, so maybe it isn’t the bane, but it’s certainly a bane. Probably in the top three right now.

Environment: Backup EXEC 12.5 SP2 (fully updated) running on Windows Server 2008 SP2, backing up, among other things, Exchange Server 2007 SP2 x64, running on Windows Server 2003 x64.

Setup: Due to horrible issues with Backup EXEC’s (referred to as ‘BE’ from now on) handling of GRT (Granular Restore Technology) with tape backups, BE runs a B2D (Backup to Disk) job to backup the Exchange mailboxes, and then a second B2T (Backup to Tape) job does the standard backup, plus grabs the B2D directory.

Problem: The B2D job fails intermittently with the following error:

Cannot extract mailbox messages from the Exchange backup. V-79-57344-759. -1213 The database page size does not match the engine on the backup to disk job.

Troubleshooting: According to this article, Hotfix 319699 is supposed to resolve the issue, in most cases. According to the article, though, it only applies to 12.0 and Service Packs, 12.5, and 12.5 SP1. The issue is supposed to be resolved in SP2, which I’m currently running.

After spending an hour on the phone with Symantec support, as the article says to call them if the Hotfix doesn’t resolve the issue (it didn’t for me), I was basically told that the version of BERestore.exe in the C:Program FilesSymantecBackup ExecRAWS directory was older than the version on the BE Server (12.5.2213.101 compared to 12.5.2213.144).

Resolution: So far, the fix seems to be to manually copy the C:\Program Files\Symantec\Backup Exec\Agents\RAWSX64\Updates directory to the Exchange server, then sort by date and apply RAWSx642213RSP2.msp, plus every update newer than that. Once the updates are complete (it took me about 10 minutes to run all 8 applicable patches), reboot the server.

After doing so, I ran the B2D job and it completed, however that isn’t necessarily proof that this worked – as the problem is intermittent, it’ll take another week of scheduled jobs to tell for sure whether that resolved the problem.

For the time being, my fingers are crossed.