Endpoint Protection

Hello, 

I have a Windows Server 2008 R2 SP1 production environment with Citrix User Profile Management installed. On these servers we are running Symantec Endpoint Protection version 14.0.2349.0100. This in essence utilizes the Windows Roaming profile mechanism and local user profiles are created under C:\Users. Occasionally, I observe the following behavior: 

When a user logs off from Citrix, the corresponding local profile folder under C:\Users is not deleted thus creating issues with Citrix profile properties not being retained as a temporary profile is created on subsequent logon. After having carried out in-depth troubleshooting, the issue is narrowed down to the following folder/file not being deleted. 

• C:\Users\[username]\AppData\Local\Symantec\Symantec Endpoint Protection\Logs\xxyyzz.log

If i try to manually delete these folders I get an "Access is Denied" error and I cannot change the owner of the folders to any domain administrator or local administrator user. 

The above file/folder cannot be deleted due to permissions/security reasons and they are only deleted after server reboot or if I temporarily disable the Symantec client on the affected servers, which of course is not an acceptable fix to the issue. We have tried applying MS hotfix https://support.microsoft.com/en-us/help/2661663/stale-user-profile-folders-are-not-deleted-completely-in-windows-7-or on the affected servers but to no avail.

Do you have any ideas or thoughts? Is this is a known issue with Symantec Endpoint Protection? Is there a Symantec or Microsoft specific patch which fixes this issue?

You may want to try MP2 as a similar issue was fixed in it:

http://www.symantec.com/docs/TECH246860

Hello, 

We have applied MP2 update to one of the affected servers and issue seemed to have been resolved for a while but after a few days the exact same issue re-surfaced. We are running SAP Business One on the affected servers.

Is there another Symantec fix related to this issue (WER and log files being locked and Citrix profiles cannot be deleted)?

Could this be caused due to insufficient Antivirus exclusion/exception policies set in the Symantec server?

Thank you in advance for your feedback. 

We have the exact same problem. We have the SEP 14 MP2 on Windows 2016 servers, and we have a problem with the profiles not being deleted fully on Xenapp servers when a user logs off.

If you start Resmon on the server, select CPU, then search for the username, you will see that ccsvchst.exe handles are keeping the folders locked. Once you kill the handles, the folders can be deleted. This is just a terrible work arround ofcourse, so i was wondering if there are settings we need to look at? Why are these folders locked by Symantec?  Obviously MP2 did not fix this issue.

Tnx in advance.

We have the same problem too. Citrix XenApp 7.15 LTSR with Server 2016 VDAs, and using Citrix Profile Management. SEP 14 MP2 recently installed and seeing one or two users logging on with UPM giving their %USERPROFILE% folder to be c:\users\username.domain instead of c:\users\username 

Bit of an issue when their third party app relies on the latter path to exist. 

Hoping that someone can come up with a resolution - it's only affecting 2 users currently, but there's 45 that log onto that server for this particular 3rd party app so has the potential to bring this company to a grinding halt. 

Thanks

Hello Everyone,

I am not aware of any cases being opened describing this beavior after SEP 14 MP2.  If you are still experiencing an issue please open a support case.  The support technician should ask you for low alt process monitor boot logging, and WPP boot logging run at the same time as well as a Symdiag.  Please post your case numbers once opened and I will make sure they get the necessary attention needed.

Thanks,

John

Same issue, profile can't be deleted due to a log file at C:\Users\[username]\AppData\Local\Symantec\Symantec Endpoint Protection\Logs\. Windows 2012 R2 server with Citrix XenDesktop 7.16 running SEP  14.0.3752. Symantec keeps screwing things up. Not too long ago we had a company wide outage due to a faulty engine update, then there was the issue with high CPU utilization on file servers. All this in less than 6 months, "good job" Symantec. Evaluating other AV options now, 2018 will probably be the last year we use Symantec.

Sorry about that. We have not received cases regarding what you are explaining after we fixed a similar issue in SEP 14 MP2.  Without customers creating cases and providing the log data we need to investigate there is little we can do.  Please open a case if you are experiencing this issue.

Thanks,
John Owens

@John_Owens

If you have received no cases after the fix in MP2, why is the same fix mentioned again in the release notes for RU1, explicitly stating that installing MP2 does not help?

Citrix roaming profiles cannot be deleted with SEP 14 MP2 installed

Fix ID: 4099309

Symptoms: Citrix roaming profiles cannot be deleted due to roaming Windows Error Reporting folders locked by Symantec Endpoint Protection 14 MP2.

Solution: Fixed the code to allow the roaming profiles to be deleted.

https://support.symantec.com/en_US/article.INFO4623.html

@All

We're experiencing the same issue with MP2 even though it was allegedly fixed. Looks like we need to try RU1 where it has been fixed. Again. We'll test it at the beginning of next month and I'll report back. And definitely take a look at the release notes of the upcoming RU1 MP1. Maybe it will be fixed there. Again. -.-

Nice find @Neo44.  I missed that.  I took a look at the fix 4099309.  It appears this happens when the following setting has been disabled:

SEPM -> Site Properties -> Data Collection ->
Troubleshooting "Let clients send troubleshooting

This was fixed in a release of Symqual that we picked up only in SEP 14 RU1.  Please upgrade to resolve the issue.  SEP 14 RU1 MP1 will be available in the next week or so.  I took a look at the fix notes for SEP 14 RU1 MP1 (internal only until public release) and I did not see anything having to do with this issue.

Thanks,
John

Here is the document as well:

https://support.symantec.com/en_US/article.TECH248291.html