How to prepare Symantec Endpoint Protection clients on virtual disks for use with Citrix Provisioning Server

Article:TECH123419  |  Created: 2010-01-23  |  Updated: 2012-11-14  |  Article URL http://www.symantec.com/docs/TECH123419
Article Type
Technical Solution


Issue



 

Using Citrix Provisioning, you can set up a "base" computer (physical or virtual) and associate it with a vDisk (virtual disk). The vDisk can eventually be shared  with multiple computers. When the vDisk is shared among several different machines using Citrix Provisioning, those machines perform a network boot to the vDisk and overlay their unique identities (MAC address, machine name, etc).

This appears to be a type of cloning operation, but standard cloning preparations do not work as expected.

How can the Symantec Endpoint Protection (SEP) client best be prepared for this type of deployment?


Error



Difficulties encountered may include:

  • Loss of communication between provisioned Symantec Endpoint Protection clients and manager.
  • Duplicate client entries appearing in the Symantec Endpoint Protection Manager (SEPM) every time a provisioned client is rebooted.
  • Provisioned Endpoint Protection clients switching between SEPM client groups, receiving wrong policies, not maintaining current definitions, etc.

 


Environment



Citrix Provisioning Server is typically used in conjunction with other Citrix and third-party products, such as:

  • XenApp (also known as Citrix Presentation Server)
  • XenDesktop (using XenServer, Microsoft Hyper-V, or VMware virtual machine infrastructures)

Cause



When you create a vDisk and switch to it, it is set to "Private Image" mode (exclusive access). The SEP client behaves as expected in this mode, because changes can be made to the vDisk and are saved between reboots. When the vDisk is ready for provisioning, the base machine is shut down and the vDisk is usually set to "Standard Image" mode. In this mode, multiple computers can use this same vDisk, but changes are not saved. Any changes are temporary and are lost when the machine using the vDisk is rebooted. The usual cloning preparations for a SEP client installed to a vDisk (deleting SEP HardwareID and sephwid.xml) are not sufficient, because clients provisioned with standard image mode are starting from the same base image after every reboot—all changes made in between to that disk are lost. Typically, this causes a provisioned SEP client to reappear in the SEPM as a duplicate on reboot, when a new random SEP HardwareID is generated. Not only is the SEPM registration lost on reboot, but definition and policy updates are also lost--you potentially have a mass of clients downloading large updates every time they reboot.


Solution



 

To solve the content update problem, see Citrix's Provisioning Services Antivirus Best Practices. Citrix can assist you in regularly updating the base image. You may also minimize the size of Endpoint Protection client definition downloads from the Endpoint Protection Manager by ensuring that the Manager keeps a large number of definition revisions. Finally, the network impact of simultaneous client downloads from the Manager can be addressed by randomizing the update schedule.

Other solutions for managed SEP clients on provisioned virtual machines:

Use "Difference Disk" Image Mode

Use the third vDisk mode ("Difference Disk Image") on the provisioned clients. SEPM registration, definition updates and such are saved in between reboots. The base vDisk is still not changed—changes that are made by a client computer are saved in a linked cache. Any undesired changes will be purged the next time you update the underlying vDisk.

Use an Unmanaged SEP Client

Use an unmanaged SEP client for provisioned computers, and provide new definitions in regular updates to the base vDisk.

Use a startup script to set a fixed HardwareID at boot

Some customers insist on being able to manage provisioned SEP clients and don't like the idea of using difference disk images based on performance, future Citrix supportability or other concerns.


It is possible in these cases to use a script to set the HardwareID to a fixed unique value during system startup. This must be done during the startup process before the Symantec service starts, otherwise the old ID is used if present or a random one is generated. Note that this startup script helps only with problems caused by random or duplicate HardwareIDs; virus definition updates must be addressed separately.

The following instructions are provided as an example of using a startup script to set a HardwareID based on the machine's MAC address.  Please note that the script provided here is intended as an example only for the customer's convenience.  The customer is responsible for its implemenation and Symantec can offer only limited support in the event that the script does not work as expected. 

  1. Disable Tamper Protection on the SEP client; this must be done to allow the file and registry changes in steps below.
     
  2. Close any open SEP Client GUIs, go to the command line, navigate to the Symantec Endpoint Protection program files directory and stop the SEP Smc service

    smc -stop 
     
  3. Set SEP service to start manually. 

    In SEP 12.1, set HKLM\SYSTEM\CurrentControlSet\services\SepMasterService\Start=3

    In SEP 11.x, set HKLM\SYSTEM\CurrentControlSet\services\SmcService\Start=3
     
  4. On the base disk image for the provisioned clients, create startup batch file "c:\sephwid.bat". This startup script will clear any existing SEP hardware identifiers, set a fixed Hardware ID based on the first available MAC address on the machine, and start the SEP service. Note that this must be a machine startup script, not a login script, so that it runs before any logon. Use the following example, edit/comment/uncomment as appropriate, and be aware of line wrapping:
     
    rem ### Check If Computer Is Running A 32 Bit or 64 Bit Operating System:
    rem ### http://support.microsoft.com/kb/556009
    rem ###
    rem ### registry commands must use "/reg:64" switch on 64-bit OS
    rem ### this switch is supported in Server 2008 & Win7,
    rem ### but a hotfix is necessary for older 64-bit systems:
    rem ### http://support.microsoft.com/kb/948698
    
    set reg64switch=
    reg query "HKLM\Hardware\Description\System\CentralProcessor\0" | find "x86"
    if errorlevel 1 set reg64switch=/reg:64
    
    rem ### registry location for SEP HardwareID--this is the same on 32- or 64-bit systems
    
    set hwidkey="HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink"
    
    rem ### delete any current SEP hardware identifiers, various possible locations
    rem ### ref: How to prepare SEP 12.1 client for cloning: www.symantec.com/docs/HOWTO54706
    
    for /d %%d in (
    "C:\Program Files\Common Files\Symantec Shared\HWID"
    "C:\Documents and Settings\All Users\Application Data\Symantec\Symantec Endpoint Protection\PersistedData"
    "C:\ProgramData\Symantec\Symantec Endpoint Protection\PersistedData"
    "C:\Windows\Temp"
    ) do del /f "%%~d\sephwid.xml"
    
    for /d %%d in (
    "C:\Documents and Settings\*"
    "C:\Users\*"
    ) do (
    del /f "%%~d\Local Settings\Temp\sephwid.xml"
    del /f "%%~d\Local Settings\Temp\communicator.dat"
    )
    
    reg delete %hwidkey% /v ForceHardwareKey /f %reg64switch%
    reg delete %hwidkey% /v HardwareID /f %reg64switch%
    reg delete %hwidkey% /v HostGUID /f %reg64switch%
    
    rem ### set HardwareID prefix
    rem ### this can be any 20-digit hexadecimal string (using digits 0-9,A-F) in all CAPS
    
    set myprefix=00000000000000000000
    
    rem ### get first MAC address from "getmac" command
    
    for /f "tokens=1" %%a in ('"getmac /nh"') do (
    set addr=%%a
    goto :endfor
    )
    :endfor
    
    rem ### if "getmac" fails, try exchanging the line below into the for loop above
    rem ### for /f "tokens=12" %%a in ('"ipconfig /all | find "Physical""') do (
    
    rem ### remove hyphens from MAC addr
    
    set addr=%addr:-=%   
    
    rem ### for HardwareID, concatenate MAC addr to end of custom prefix 
    rem ### hwid must be a 32-digit hexadecimal string (using digits 0-9,A-F)
    set hwid=%myprefix%%addr%
    
    rem ### Set SEP HardwareID in registry
    reg add %hwidkey% /v HardwareID /d %hwid% /f %reg64switch%
    
    rem ### start SEP services 
    sc start SepMasterService
    sc start SmcService
    

     

sephwid.bat can be debugged by calling it from a second script which simply calls the first and redirects stderr/stdout to a log file. For example--

debug.bat:

c:\sephwid.bat >c:\sephwid.log 2>&1 

It is not necessary to prepare the base image for cloning, since sephwid.bat will automatically remove any previous SEP hardware identifiers every time the machine starts. The SEP client on the base image should be assigned to a SEP Manager group that has a short heartbeat and/or "push" communication so that provisioned clients can quickly re-establish a connection with the SEP Manager. When the provisioned client shuts down, the SyLink LastServer and RegCSN values will revert to those of the base image. This may cause a delay of up to two heartbeats when the provisioned client starts up again and the SEP Manager reconciles its saved CSN value with those of the client. After the provisioned client checks in it can receive new policy (including a longer heartbeat) according to its hardware ID and group membership or location awareness.



References
XenDesktop 4 -- enterprise product evaluation steps:
http://support.citrix.com/proddocs/topic/xendesktop-bdx/cds-eval-task1-install-vmi-bdx.html

Evaluation software can be downloaded here after free registration and login:
http://www.citrix.com/English/ss/downloads

Citrix eDocs Library:
http://support.citrix.com/proddocs

 

 



Legacy ID



2010022314105448


Article URL http://www.symantec.com/docs/TECH123419


Terms of use for this information are found in Legal Notices