If you install Symantec Enterprise Protection in a Citrix Provisioning Services vDisk in standard mode, you will notice that your clients will create duplicate entries in the Symantec Endpoint Protection Manager at every reboot.
Just like most other centrally managed anti-virus products (see my other post on Trend Micro OfficeScan), Symantec uses hardware id’s to uniquely identify clients and this causes issues with read-only vDisks.
Symantec provides a knowledge base article in which they go into detail on the problem and propose a workaround that creates unique id’s for every client.
You can find more information here: http://www.symantec.com/docs/TECH123419
The workaround and batch file that Symantec uses is a “one size fits all” solution, meaning it will work for SEP 11 and 12 and for 32 and 64 bits.
The environment I was implementing this for uses Windows 2008 R2 and SEP 11 only and I like to standardize all my scripts to PowerShell, so I extracted only the actions I needed and translated them to PowerShell.
A summary of the steps needed to be taken first (the Symantec article outlines them in more detail):
- Disable tamper protection (very important!)
- Stop the Symantec Management Client service by navigating to the Symantec Endpoint Protection installation directory and use the command: smc -stop
- Set the Symantec Management Client service to start manually in the registry: HKLM\SYSTEM\CurrentControlSet\services\SmcService\Start=3
After these changes the Symantec Management Client service can’t contact the Symantec Endpoint Protection Manager automatically anymore.
The following PowerShell script must be configured to run at boottime to change the hardware id and manually start the Symantec Management Client service.
# Change Symantec Endpoint Protection Hardware ID
# Created by Michel Stevelmans - http://www.michelstevelmans.com
# Delete sephwid.xml
Remove-Item "C:\Program Files (x86)\Common Files\Symantec Shared\HWID\sephwid.xml"
# Delete registry entries
reg delete "HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink" /v HardwareID /f /reg:64
reg delete "HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink" /v HostGUID /f /reg:64
# Get the MAC address of the first NIC
$Nics = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IpEnabled = TRUE"
foreach ($Nic in $Nics)
{
$Mac = $Nic.MacAddress
Break
}
# Remove colons from MAC Address
$Hwid = $Mac.Replace(":", "")
# Add new HardwareID registry entry
reg add "HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink" /v HardwareID /d "00000000000000000000$Hwid" /f /reg:64
# Start Symantec Management Client
Start-Service SmcService
Like I mentioned earlier: This script is for 64-bit with SEP 11, but with the help of the original Symantec article it is very easy to make this work for SEP 12 or 32-bits.
Thanks Michel, just what my customer needed!
Graham
Thanks for info Michel! I had a couple comments.
We use dual-homed PVS devices. Wouldn’t this logic set the MAC to the wrong NIC since only the first nic is network bootable? We use a dedicated, unrouteable PVS network that has everything but basic tcp/ip unbound to it.
Also we use EM for everything we can. Can you provide an EM snippet for this? Or would you just use EM to kick off this PS logic under Computer | Startup?
Hi Richard,
It doesn’t really matter which NIC the script uses, that’s the cool part of it.
The script just needs a MAC address that is the same every time the machine boots to generate a unique Hardware ID.
Running it from an AppSense custom action under Computer-Startup should be fine.
There’s an example on how to do that at the end of this post: http://www.michelstevelmans.com/local-profiles-appsense-personalization-powershell/
The script works great. It even is using the MAC of the proper, public NIC!
However I have hit a snag. We are using 12.1 and apparently even when you disable tamper protection, SEP still disallows molesting the SEP services. Symantec says this is expected behavior. Our AV owner is going to meet with a contact on their escalation team to see if their devs have a workaround. I will report results.
I actually addressed this issue by mounting the disk in the PVS console and using regedit to mount the SYSTEM registry file and performing the edit to set SEP service to manual. Work awesome!
Hi Richard,
Excellent, thanks for sharing!
Richard,
thanks for sharing.
I am planning a new PVS implementation with virtual targets each with its own cache disk. I want to use the cache disk to store data like Windows Event Log, EdgeSight Firebird DB, and – guess what – antivirus pattern
Do you know if it is possible to redirect SEP client’s antivirus pattern path to another location, that is in my scenario the disk dedicted for the PVS Target Cache?
Thanks in advance
Peter