Endpoint Protection

 View Only

SEP on non-persistent VDI  

Mar 12, 2012 10:39 AM

 

 

If you are planning to implement SEP11 on a non-persistent VDI, you will face some challenges with duplicated SEP entries in SEP Manager, and outdated definitions and repeated download of definitions after restarting VDI. You will find many Symantec's KBs mentioning best practice, workarounds and tips on how to handle SEP on virtualized enviroment and "VDI". But these KBs don't really provide a root solution.

With a help from VDI expert, we ended up with a solution that will save us a lot of efforts to mange the VDI environment. All what was need is the addition of another persisten drive, small on size (around 1GB) to handle all non-persistent issues. The steps are as follows:

 

  • Make sure there is additional presistent drive in the image, eg. D.
  • Create the following symbolic links with “MKLINK /J” from command prompt:

o   “C:\Program Files\Common Files\Symantec Shared” -> “D:\Program Files\Common Files\Symantec Shared”

o   “C:\Program Files (x86)\Common Files\Symantec Shared” -> “D:\Program Files (x86)\Common Files\Symantec Shared”

o   “C:\Program Files (x86)\Symantec” -> “D:\Program Files (x86)\Symantec”

  • Install Symantec Endpoint Protection client.
  • Move "C:\ProgramData\Symantec" directory and its contents to "D:\ProgamData\Symantec", and create a symbolic link between both directories.
  • Delete "HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink\HardwareID" value.
  • Delete "C:\Program Files (x86)\Common Files\Symantec Shared\HWID\sephwid.xml". The first time that a new virtual desktop startup, SEP will create a unique new sephwid.xml. This file will be persistent, because is located in write cache disk (D). Every time the same virtual desktop startup, SEP read sephwid.xml file from write cache disk (D) and set the value for HardwareID registry key. This value is always the same for this virtual machine.
  • Created local scripts to export (at shutdown) and import (at startup) definitions registry keys, to preserve them and ensure that SEP point to the last downloaded definitions (for NTP and PTP definitions only):

o   HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Symantec\SyKnAppS

o   HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\Content\IPS  

 

Now, you can follow Symantec's KBs for SEP performance on VDI, summarized in:

  • No scheduled scan
  • No startup scan
  • No active scan
  • Don't allow users to run on-demand scan
  • Increase heartbeat and download randomization

 

What I couldn't find answer for, wherether NTP components affect the streaming perfomance of VDI...!!!

 
 

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Jan 30, 2014 10:43 AM

Nope. The plan for the defs is as per your original post, using MKLINK and a persistent D drive.

 

The customer I'm at is using LUA to distribute out to IIS based distribution points. However, if they were using SEPM for defs then something that has been rumoured to work (I've not tested this myself) is to create a dummy LiveUpdate Content policy that is set to use a specific revision i.e. the same one as in the image as this revision will not get deleted from the SEPM as it's in use.

Jan 24, 2014 03:07 AM

Good testing, but don't forget that all VDIs are sharing one or more physical host. if the host is busy with something, it will affect the performance as well on VDIs.

Jan 24, 2014 03:05 AM

I guess you have no plan for the definition. What will you do when you have over 1K VDI updating from SEPM, where the image definition is older than SEPM oldest revision?!

Symantec had 4 RUs since this article been created, but what they have added for VDI, is only cosmatic. To be more accurate, they still don't have a solution for VDIs, only tweaks and workarounds. And one of their workarounds for definitions, is to updated the golden image weekly. Are you planning to do that?!

Jan 23, 2014 09:18 AM

No need to remove SEP serialization as they provide a clone prep tool that removes all traces of SEP specific ID from the gold or master image.

We have never at all seen duplications or any "mess" with linked clones from the same gold image.
Our VDI gold image has SEP in it and has been "certified" via VIE. The gold image is then prepped with the clone prep tool as the VERY last thing done just immediately prior to shutting the gold image "off".

when clones launch they each then have a totally new and different serial number. So far we've not had issues but then the gold image has defs that aren't all that old and the SEPM servers are sitting in the same hosts as the VDI client/desktop. That will change as this is only testing and we'll have hosts/servers dedicated to serving up the vdi desktops so we can keep the current VM hosts for our servers and such.

The VDI desktop environment will be under different VM hosts, so it will be interesting to see how it works with the SEPM servers under the hosts that hold the virtual servers and VDI desktops under different VM hosts which serve up only VDI desktops. Still, the gigabit network should handle this ok.

I'm no pro on VDI - I know the server part pretty well but that's not linked clones or gold images and so on. You have specific servers which always exist and never go away or change - which is so much like a physical server it's easy to forget they are NOT real "machines".

We are at SEP and SEPM 12.1.4 and this is 2014 so the original post is 2 years old and several revisions back as far as SEP and SEPM, and Symantec has included a whole basket full of tweaks and enhancements for VDI and virtualization in general so honestly, I can't take the above and really apply it as things are so different now, and the clone prep tool does all the work of removing specific identities there is no need to remove any xml files or purge the registry of SEP serialization (whcih I call the SEP SID for some odd reason)

Jan 23, 2014 05:41 AM

Thank you :)

 

Re NTP components; IPS will have a small impact as it's performing SPI on all traffic. Not had a chance to test that in this scenario but I did some file copy tests with SEP12.1RU3 with Download Insight, IPS and SONAR enabled and the result ranged between 4 and 30 additional seconds over the same test with SEP11 AV only (I was unable to isolate from production so network congestion skewed results). Test data was 4GB containing 2 1GB files and the remainder was a variety of 100MB, 10MB, 1MB, 500KB and 10KB files. NIC was 100Mbps on both systems, also they both had the same versions of SEP in the same configuration for each test.

This doesn't really answer your question but may be of some use.

Jan 23, 2014 04:24 AM

This was tested with the first release of SEP12.1. Didn't have a chance to test it with the latest RU.

Dec 16, 2013 06:17 AM

Hi Yahya,
Have you tested this with SEP12.1?
I am currently faced with exactly the same requirements to persist hardware ID, content, logs etc... across non-persistent PVS reboots and your solution appears to address all of these, however several file and registry paths changed with SEP12.1.
Thanks in advance,
Mike

Related Entries and Links

No Related Resource entered.