How to prepare Symantec Endpoint Protection clients on virtual disks for use with Citrix Provisioning Server
|Article:TECH123419|||||Created: 2010-01-23|||||Updated: 2014-10-08|||||Article URL http://www.symantec.com/docs/TECH123419|
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?
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.
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)
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.
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.
- Disable Tamper Protection on the SEP client; this must be done to allow the file and registry changes in steps below.
- 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
- 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
- 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 if 32-bit OS is remotely accessing 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 set hwidkey=Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink rem ### SEP 12.1 RU5 moved this key and its values to Wow6432Node on 64-bit systems 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:\" "C:\Program Files\Common Files\Symantec Shared\HWID" "C:\Documents and Settings\All Users\Application Data\Symantec\Symantec Endpoint Protection\CurrentVersion\Data\Config" "C:\Documents and Settings\All Users\Application Data\Symantec\Symantec Endpoint Protection\PersistedData" "C:\ProgramData\Symantec\Symantec Endpoint Protection\PersistedData" "C:\Users\All Users\Symantec\Symantec Endpoint Protection\PersistedData" "C:\Windows\Temp" ) do ( del /f "%%~d\sephwid.xml" del /f "%%~d\communicator.dat" ) 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" rem ### navigating to Users\*\Local Settings is usually unsuccesful (it is a junction) rem ### ... but Users\*\Local Settings\temp is correctly routed to Users\*\AppData\Local\temp ) reg delete "HKLM\SOFTWARE\%hwidkey%" /v ForceHardwareKey /f %reg64switch% reg delete "HKLM\SOFTWARE\%hwidkey%" /v HardwareID /f %reg64switch% reg delete "HKLM\SOFTWARE\%hwidkey%" /v HostGUID /f %reg64switch% rem ### SEP 12.1 RU5 moved this key and its values to Wow6432Node on 64-bit systems reg delete "HKLM\SOFTWARE\Wow6432Node\%hwidkey%" /v ForceHardwareKey /f %reg64switch% reg delete "HKLM\SOFTWARE\Wow6432Node\%hwidkey%" /v HardwareID /f %reg64switch% reg delete "HKLM\SOFTWARE\Wow6432Node\%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 "HKLM\SOFTWARE\%hwidkey%" /v HardwareID /d %hwid% /f %reg64switch% rem ### SEP 12.1 RU5 moved this key and its values to Wow6432Node on 64-bit systems reg add "HKLM\SOFTWARE\Wow6432Node\%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--
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.
XenDesktop 4 -- enterprise product evaluation steps:
Evaluation software can be downloaded here after free registration and login:
Citrix eDocs Library:
Article URL http://www.symantec.com/docs/TECH123419