Tuesday, April 29, 2008

Symantec Endpoint Protection...again

Wow. I've really had LOTS of hits generated on this blog, since I posted some info about SEPM and my related issues, so I've decided to share some tips and other interesting findings.

My guess is that many of you that hit my blog don't have the luxury of having a DEV environment to test in, so PLEASE do yourself a favor, and if you do nothing else, follow #7 and #8. This will prevent you from having to invest in the Hair Club for Men after you yank all yours out.

Tips:

  1. SEPM doesn't like to be installed on custom HTTP ports, but it is possible. See 'Configuring the Symantec Endpoint Protection Manager to run with a custom HTTP port' Document ID: 2007111212591048 here. It's a pretty simple process.
  2. SEPM will not show graphics from RDP sessions....seriously. So don't put yourself in a situation as I did, and hang on the helpline-from-hell with someone that didn't know, nor did the knowledge-base. DOH!
  3. If you have to upgrade SEPM, God help you. I used their database backup tool to back up my configuration, and when I imported using the same tool, it created a second instance of my server that wouldn't go away. Also created issues with client packages from the previous version that wouldn't be removed. It was far simpler to export my policies to individual files, then import them into my groups I created by using the AD Import wizard. SPECIAL NOTE: Don't forget to manually clean out your deployment directories as well as your installation dirs.
  4. The SEPM console won't work on Linux or Mac. Sorry, but those are the facts. It looks for IE to populate specific areas of the UI, and for now, there is no fix on the horizon, and that sucks, because I'm not letting go of my SuSE workstation. Thanks to VMWare for providing server.
  5. Sylink.xml files, which you will learn much about if you installed SEPM more than once, as I did, can easily be replaced using scripting, if you don't want to run around using the SylinkDrop.exe utility (found on CD1, under tools, unsupported). Here is an example I put together:
    @ECHO OFF
    IF EXIST "%ProgramFiles%"\"Symantec\Symantec Endpoint Protection"\sylink.xml (
    @SET SAV="Symantec\Symantec Endpoint Protection"
    ) ELSE (
    @SET SAV="Symantec Antivirus"
    )
    %COMSPEC% /c start /wait "Stopping SMC..." "%ProgramFiles%"\%SAV%\Smc.exe -p symantec -stop
    copy /Y \\MYFILESERVER\netlogon\sylink\sylink.xml "%ProgramFiles%"\%SAV%
    %COMSPEC% /c start /wait "Importing settings..." "%ProgramFiles%"\%SAV%\Smc.exe -p symantec -import "%ProgramFiles%"\%SAV%\sylink.xml
    "%ProgramFiles%"\%SAV%\Smc.exe -start
    EXIT
    You'll notice I check for two different directories. That's because if you do an upgrade of the clients, they retain the legacy directory structure. You can also see that there are switches used to issue the stop [-stop] and send the password [-p symantec] to the client.
  6. MOST IMPORTANT: Don't use Symantec's default configurations. COPY theirs, and edit it to your liking. Much like you wouldn't edit the Default Domain policy in AD, you don't want to edit these default policies, especially if you screw something up.
  7. EVEN MORE IMPORTANT: Don't roll out anything but the Anti-Virus and Proactive Threat Protection (TruScan) until you thoroughly test the other components out first. This will at least give you the enhanced AV/Malware/Spyware protection you want, without munging things up. This product is WAY different than SAV Corporate, and much more complex. Create a test environment in an OU, put a VM in there, and apply your policies to that unit. As an example, I initially removed all but AV, Live Update, and Centralized Exceptions from my Global Configuration object to ensure no other policies were applied.
  8. Unless you want to chase your tail, don't install anything but AV on your DC's and application servers. Nothing worse than your users reining in on you with complaints about file shares disappearing, and application connectivity issues.
  9. Java virtual machine exit code errors of -1 are almost always db connection issues. Re-run your Management Server Configuration Wizard to re-establish connectivity. This almost always works.
  10. I found that the vbs scripts used by the installer almost always broke my Symantec IIS virtual root. It never seemed to be able to correctly re-install that web unless I completely removed SEPM and reinstalled. I'd even taken time to try and debug their code, and it just got to time consuming. It was just easier to take a tip from Riley in Aliens..."I say we take off and nuke the entire site from orbit."
  11. Drive Space getting eaten up by log files? Upgrade to MR2. That is all....
  12. Sign up to Symantec's forums. If you haven't, you are really missing the boat. There are many bits of advice, fixes, and folks who are quite eager to help.
These are certainly not in any particular order, but they are all issues I've dealt with, and remember/regurgitate at this momentito...

4 comments:

John Croson said...

I failed to mention another point. I've got the SEPM installed on my Terminal Server with no issues. Works like a champ. I know, some of you tin-foil-hat wearing admins out there might shudder to think of server apps running on a client to be bad juju, but my TS is locked down so tight, it squeaks...

Anonymous said...

I found your site by search for people with problem with SEPM. Great read. Thanks. I'm in the process of migrating (not upgrade) to Endpoint from SAV 10.x. New server. Hopefully, I won't run into much trouble. But I see that I will be, with WSUS and other applications running on the same box...

Anonymous said...

I love you. You just made my weekend. Symantec's site is horrible.

Free Antivirus Download said...
This comment has been removed by a blog administrator.