Troubleshooting Shadow Protect and Symantec Endpoint Protection Manager

If you're using Shadow Protect and Symantec Endpoint Protection Manager, then you've probably run into the issue that SEP generates several Gb per day in diffs, none of which are required for backups. Worse, it ends up costing you more in storage, and if you're trying to synchronise your backups offsite using Image Manager FTP or ShadowStream then good luck - trying to keep up with 10Gb per day of deltas just for the Antivirus component alone over imperfect ADSL just doesn't work.

So, how do you deal with this?

Before we get going, you need to be very clear that these suggestions are completely, and totally unsupported by Symantec, ShadowProtect, ourselves or any other vendor. This really and truly is use at your own risk; and the risk is that you will substantially break your antivirus installation, set fire to your computer and call forth the plague. You have been warned.

There are a few things that you need to do.

  • Move the Content cache. This is the easy part. If you "just happen" to have a spare partition lying around, then you can setup a hardlink to move the Content Cache to a different disk / partition. In short you mount the partition as the target folder (generally c:\program files\Symantec\Symantec Endpoint Protection Manager\Inetpub\content ). For detailed instructions head here: ).
  • If you don't happen to have the luxury of a spare chunk of disk lying around... then what do you do? A symbolic link (symlink) is the answer... A symlink is essentially a shortcut. Linux users should be familiar with the concept, Windows users are less likely to be so.
  • The short version:
    • stop symantec services
    • cd c:\program files\symantec\Symantec Endpoint Protection Manager\Inetpub\
    • move content content.old
    • mklink /d Content \\mynas\myshare
    • move files & directories from content.old --> content
    • start services
    • verify that AV real time protection is working, and that updates are being downloaded and published correctly
  • Longer version:
    • In this example we're using a network share for the extra desired space. This has a few advantages a) it works b) it's generally easier to provision extra NAS than DAS. Virtual environments may be an exception here. VAS as a new phrase anyone?
    • I've only tried to use it with shares that don't require authentication, and are instead locked down to the host in question. You might be able to try this by using an authenticated share but the mklink syntax doesn't appear to support passing a user/pass, and there are no notes on whether it saves the credentials. The other potential issue with this is that this location is required *before* a user logs in - i.e. it's generally starting as a service before any user can login, so you can't for example have a mapped drive to the NAS that does store the credentials, so that any subsequent connections use the already-in-place authenticated session (as you would if you were operating in user space, for example). If anyone's tried this and has any information on it please let me know and I'll update this accordingly...
    • I've tried this successfully with: Win2k8 32bit SP1 / SP2, SEP 11.0. Having read many other posts out there I imagine the same strategy should work for newer versions of SEP, but as always YMMV (you did read the warning, right?).

Now, the next one is a doozy. You also need to move the Definitions folder. This is generally stored in c:\programdata\symantec\Definitions . This can be several Gb in size, and generate Gb of delta per day. This folder is much harder "to fix". A more accurate description would be butcher into submission. The problem with the Definitions folder is that it's far more protected by SEP, and is consequently harder to move. If you're planning on installing SEP you could create the directory required above beforehand using the mklink /d command. If you're doing this after the event... then you need to:

Short version:

  • Read this . It has good background on the definition folder, and what you need to do, to be able to move it / work with it. In my case I could not "unlock" the folder using the methods described in the post, so resorted to registry hacking (which worked). If you can get away with not having to reghack then that is of course vastly superior. As before YMMV.
  • Do This:
    • Turn off tamper protection from within SEP (the client)
    • Follow the instructions above so that you should be able to move the content
    • Make sure all Symantec related services are stopped (including Live Update)
    • Run smc -stop from the command line to stop the manager.
    • Look for any Symantec processes hanging around. Kill them.
    • Move Definitions --> Definitions.old
    • mklink /d Definitions \\mynas\mydefinitionshare
    • copy contents of Definitions.old --> Defintions
    • Start symantec services
    • Test. Make sure Live Update is working, and that it's correctly pulling new definitions.
  • If you can't move Definitions --> Definitions.old, then you need to resort to come hackery.
    • Make an alternate symlink "mklink /d Definitions2 \\mynas\mydefinitionshare"
    • Look for all instances in the registry pointing at either:
      • c:\programdata\symantec\definitions ; or
      • c:\progra~2\symantec\defin~1
    • and change them to point at:
      • c:\programdata\symantec\definitions2 ; or
      • c:\progra~2\symantec\defin~2
    • Depending on which flavour of entry you have in the registry.
    • Copy the content.
    • Start services.
    • Test test test.
  • If you've done it right, then what you should expect to see is the new Definitions folder getting new files / folders placed in it (for the new definitions that it's downloading). And then these being pushed out to clients.

Did I mention test?

Last question: So why can't you just install Symantec to another partition, and not worry about it? Because you need the program installed - if you try to reboot with Symantec "missing" your server will probably fail to boot. What you don't need is all of the accompanying data, because this is generated regularly throughout the day, as it refreshes itself (and which it will do upon your first reboot).

I haven't tested, but I expect that this strategy would also work for Acronis and other block based imaging software.

This here is a specific example of a generic problem with Storage Craft / ShadowProtect - that the client has no way of excluding paths or file types. I'll talk more about how you deal with this problem is server layout in a blogpost coming soon!


Linking Confluence to SBS Active Directory and fil...
Handling ShadowProtect and file systems with high-...

Related Posts


No comments made yet. Be the first to submit a comment
Mobile Version | Desktop Version