We`ve been troubleshooting slow login and poor application performance on our Non Persistent VDI for a while now. App Volumes and Symantec Endpoint Protection 14.x doesn`t seem to like each other.
Without a SEP client installed everything is performing well and user experience feels like a persistent VDI. When SEP is installed including all obvious exceptions and even using the virtual image exception tool no significant change in performance is noticed. We`ve been testing all scenario`s disabling components of SEP. Only disabling "Application & Device Control" seems to improve login and application performance.
By accident we found out that SEP didn't work at all !! Everything looked fine from SEPM and SEP side.The SEP GUI indicated that there were no problems detected "Your computer is protected", but stopping and then starting the smc.exe resulted in a crash. It may seem that the service is running, but in reality the Symantec client has crashed see image below. The only way to start the SEP client was rebooting. We also saw that a simple EICAR test virus was not detected even when the SEP client was running and the GUI indicating that the computer was protected. Then we discovered that this behavior only occurs when an app stack is attached.
![]()
With the knowledge we had that this behavior only occurs when an app stack is attached, we added exceptions for Symantec in the snapvol.cfg of the App Stack. These exceptions have solved the problem that the client could be restarted/stopped and also a EICAR test virus was detected again.
Since Symantec is working now we see better startup times of thinapps in an app stack . Login times unfortunately not. We declared all the collected log files to be unreliable before the exceptions in snapvol.cfg, because the SEPclient did not work at all. And so we believe that specific non-persistent SEP policies and exceptions may not have worked at all. We collected a large set of logs and offered it to Symantec for a second review.
Another Interesting fact that is noticed by 'Scarlito' on the VMware forum (see link at the end of this post) is that this problem only appears after I applying Microsoft Security KB4056897 or later (and of course, with SEP agent installed and AppStacks mounted)
This means the problem is not only with SEP + AppVolumes, but SEP + AppVolumes + MS Updates (starting january 2018 and all the Intel security breaches fixes).
If I remove ANY ONE of these 3 elements, everything works well.
Until now, no Monthly security updates from Microsoft has solved anything.
These are the standard exceptions in the snapvol.cfg:
>
exclude_path=\ProgramData\Symantec
exclude_path=\Program Files\Symantec
exclude_path=\Program Files\Common Files\Symantec
exclude_path=\Program Files (x86)\Symantec
exclude_path=\Program Files (x86)\Common Files\Symantec
These are the custom exceptions we added to the snapvol.cfg:
Disclaimer: I would like to warn you and everyone else that this is at your own risk. On the other hand, without these exclusions the virus scanner probably didn't work at all !
For validation of these exceptions we opened a PR at VMware. Please report to VMware if you're facing the same problem.
>
# Custom Exclusion Symantec Performance Issues
exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Symantec
exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Wow6432Node\Symantec
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\BHDrvx64
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\eeCtrl
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\EraserUtilRebootDrv
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\IDSVia64
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SepMasterService
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SNAC
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SRTSP
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SRTSPX
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SyDvCrtl
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SymEFASI
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SymELAM
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SymEvent
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SymIRON
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SYMNETS
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SysMain
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\SysPlant
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\Teefer2
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\Eventlog\Application\Symantec Antivirus
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\Eventlog\Application\Symantec Endpoint Protection
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\Eventlog\Application\Symantec Network Protection
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\Eventlog\Application\Symantec WSS Traffic Redirection
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\Eventlog\Symantec Endpoint Protection Client
exclude_path=\Program Files\Common Files\Symantec Shared
exclude_path=\Program Files (x86)\Common Files\Symantec Shared
exclude_process_name=ccSvcHst.exe
exclude_process_name=SmcGui.exe
exclude_process_name=SISIDSService.exe
exclude_process_name=SISIPSService.exe
exclude_process_name=SISIPSUtil.exe
exclude_process_name=sepWscSvc64.exe
>
This is the link of the topic we posted on the VMware forum.
https://communities.vmware.com/thread/617203
I'm curious if there are more people who have this problem. Hopefully this post has also made people aware of the fact that their security may not function without them noticing.
Currently we have cases for these problems ongoing at Symantec and Vmware