Video Screencast Help
Symantec Secure Login will be live on Connect starting February 25. Get the details here.

Request For Virus Definitions to Be Moved to a Different Drive

Created: 12 Jul 2013 | 2 comments
mjbourne's picture
3 Agree
0 Disagree
+3 3 Votes
Login to vote

We have an urgent need to have the ability to change where the definitions are stored in our Citrix Environment due to drive space filling up on our virtual C: disks.  Please implment this idea in a future release.  We had opened a case for this (04534209)  Here are the details:

Citrix VM’s run on Virtual Disk (RAMCache) and do not have an physical storage. The RAMCache run in server memory and we are limited to 8GB. If that 8GB fills, it is as if the server runs out of drive space and it would Blue Screen.

SEP 12.1 made a change that only allowed definitions to be saved on the C: drive; in our case, this is our RAMCache. As the new definitions come in, they consume more RAMCache. In previous SEP 11 version we had the ability to put the SEP definitions on a persistent disk, vs. the RAMCache.

Because of this change in SEP 12 and how the RAMCache works, our drives are filling up faster than normal. To alleviate the RAMCache, the Citrix team has to reboot the Citrix servers; which we are now getting about 8 -9 days before a reboot is needed. In previous versions, we were able to get 3+ weeks before a reboot was needed.
Recommended creating a feature enhancement request. It is not possible to move definition content in SEP 12.1 to a different drive than C:\.

Comments 2 CommentsJump to latest comment

Cwooddell's picture

Are you familiar with junction points? They are an advanced NTFS feature analogous to symbolic links in the Linux/Unix world. It should in theory let you do an end-run around this limitation.

For instance, I have volume "E:" which is an empy 100GB volume. And you have c:\Virusdefs (path shortened for simplicity of explanation.)

You would in theory:

  1. Shut down SEPM.
  2. Move the contents of the virus defs folder to E:\somefolder. (This would leave c:\virusdefs as an empty folder.) We'll use e:\virusdefs for the purposes of illustration.
  3. Use a program like junction.exe to create a junction point redirecting c:\virusdefs to e:\virusdefs\
  4. Restart SEPM with your new, lighter c:

Now the NTFS filesystem itself would tell any program that c:\virusdefs contains the virus definitions by the magic of junction points, even though the files actually live on e:\virusdefs. I've used this trick on the past with other programs with hard-coded paths before with success.

The caveats to be aware of are:

Because the redirection happens at the kernel level, any program that is not junction-point aware can potentially treat the same set of data as two sets. For example, a non-enterprise class software might perform an operation like a twice. To make a silly example, a bashed-together vbscript that was told to delete the 10 oldest files in certain folders might actually end up deleting 20 out of e:\virusdefs - once as "c:\virusdefs" and once as e:\virusdefs.

In practice I have found that any utility that is designed to work with files at that level, such as backup, antivirus, etc that is worth its salt knows what a junction point is and handles this situation gracefully and correctly.

Please always test in a QA/Dev environment before trying anything advanced like this. Windows workstations can use junction points too, if that's all you have for QA.

Login to vote
Cwooddell's picture

An addendum:

junction.exe is a part of what was formerly Mark Russinovich's Sysinternals tools (and is now an official part of Microsoft.) Downloads and instructions can be found here:

Junction would let you make a junction point to a non-empty folder under the root of another volume. In my example above e: was an empty volume but could have as easily been a 1TB volume shared with lots of other files.

If, on the other hand, you want to dedicate a whole volume as the target of a juction point, you don't need the sysinternals tool. The disk management snap-in supports this. Just add a formatted volume to the server in question, but instead of assigning it a drive letter, you have the option "Mount in the following empty NTFS folder" - this does the same thing, only mounts the entire volume itself as the junction point target rather than a subfolder of that volume.

There are advantages to either approach.

Login to vote