Explorer Locks Up when accessing setup.exe install packages on network share
Kind of a weird issue going on and I wanted to see if anybody else was having this issue. All of our clients only have AV/AS installed, and we are not using device or software control. The clients I tested from below all were RU5. A mix of 32 and 64 bit.
We have several groups in our management console, and we create single setup.exe's for each group and put them out in network shares for people of that group to access when they want to install SEP. Each setup.exe that we create with the console goes into it's own folder. For example:
HR (would have a setup.exe in it)
Payroll (would have a setup.exe in it)
And etc...
Basically ever since we started deploying SEP, there has been a delay when accessing this folders and the user tries to right click to copy it to their local desktop, or simple just doulbe click to install it. Usually after 15-20 seconds, the right click menu would finally show up or the install would finally kick off and I never really gave it much throught until I started getting complaints lately on the lag.
I looked into figuring out the issue and it ONLY happens with the network shares with the SEP exported setup.exe files in them. Any other network folder, and multiple servers that have any files, (even .exe's) does not have this problem. It only happens from Vista, Windows 7, Server 2008, or Server 2008 R2 machines. XP, or Server 2003 can access these folders, right click the setup.exe files and copy them to their desktop with no lag what so ever.
Things I tried that had no affect.
1. Moving the files to a different share on a different server
2. Renaming the files to something other than setup.exe
3. Disabling Windows Search to see if it ws maybe tyring to index the file
I started thinking maybe it was SEP itself. Everybody with this problem already had some sort of SEP running on their machine. And older version and they were simple accessing the share to get a new version, or copy the file to their desktop to put on their flash drive for easy access to install it on other clients (mostly our help desk staff do this).
I played around and set up a new group that would only scan files on modify, that didn't help. It tired a few more things with the network share cache setting and using Process Monitor and TCPview to try to see if something else was going on.
Then I just disabled the SEP client on a machine and then accessed the share. NO PROBLEMS WHAT SO EVER! Re-enabled SEP,a nd the problem came back.
I have a laptop that has a default unamanged client on it with on AV/AS on it and it had the lag to, until I disabled SEP on it. So even the unmanged client has the problem, so it's not a management server setting.
Has anybody else seen this kind of issue at all? I know it's weird, but I really think there is something with SEP and it wanting to scan the setup.exe files that is causing the lag. Once the scan/verification check is complete on the file, Explorer works fine until you exit the folder and come back, or go to another folder with a setup.exe in it from a exported client install package.
Comments
There was a known issue with
There was a known issue with older version of SEP client and it was with File system autoprotect that used to cause this issue and should have been fixed with Mr4MP1.Would suggest calling Symantec Technical Support to know the root cause.
High Explorer.exe CPU usage when touching exported Symantec Endpoint Protection client package.
Fix ID: 1470577
Symptom: Explorer.exe has high CPU usage in Task Manager.
Solution: Fixed in an update to the Auto-Protect component.
The Client from where you are accessing this share are they MR4 or older ?
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
Mixed. MR5, MR4, MR4MP1A,
Mixed. MR5, MR4, MR4MP1A, MR3
Thanks for pointing that fix out. At least I have something to report to Symantec.
Most would have been updated from older versions. I just installed Win 7 on a clean VM and put MR5 on it, problem is still there even when a older version was never installed.
As you are facing this issue
As you are facing this issue only on the newer OS's can you try turning off User Account Control ( UAC ) and see if there is any improvement.
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
Only on newer OS's. Vista,
Only on newer OS's. Vista, Server 2008 Server 2008 R2, and Win 7. Turning off UAC has no affect
The problem doesn't exist anymore on XP or 2003.
I have submitted a case to
I have submitted a case to symantec to try to see if they can figure out why it is still happening just on the newer operating systems.
Case: 320-230-457
Whatever may be the
Whatever may be the Solution/WorkAround do update us..
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
We have a very similar
We have a very similar problem with RU5. Explorer appears to totally freeze up when Windows Search searchfilterhost.exe is indexing. The Windows Search executable is not indicating excessive CPU or resource use, however the machine completely freezes up - eventually the task manager cannot even be run.
The solution in this case was to remove the Application and Device Control element of Symantec Endpoint Protection client. Control Panel -> Add & Remove Programs. Select Symantec Endpoint Protection. Choose Change. Choose Modify. Select the drop-down menu beside Application and Device Control and choose This Feature Will Not Be Available (X). Restart.
It may be worth attempting this. We have experienced the Application and Device Control component of SEP 11 RU5 causing similar problems with other processes. Nothing is logged by SEP during these instances.
Try this
Disable Network Drive Scanning:
Please don't forget to mark your thread solved with whatever answer helped you : ) Thanks & Regards Aravind
Noticed same problem with
Noticed same problem with Win7+SEP RU5, NTP and Application and Device control installed, Network scanning disabled and package created with that policy used.
Double-clicked setup.exe, explorer freezes but everything else works. Killed explorer from task manager and started again, setup.exe successfully copied to client's desktop and installation was successfull.
SEP RU5 was allready installed with problematic computers, just needed to run it again to change some settings.
We are not using application
We are not using application and device control at all, and it happens even with the package isn't on a network drive. I have logged my case, and they haven't made much progess with it. All they keep updating the case with is the following info:
ISSUE:Known issue
STATUS:researching
ACTION:Research solution
If I get a solution, I will surely post it for everybody, but I think this will just have to be included in an update to the client in the next version from what I can tell.
Symantec has updated me
Symantec has updated me stating that this will need to be addressed at the code level. Fix will be in an upcoming release it looks like.
Would it be in MR5Mp1 or
Would it be in MR5Mp1 or MR5MP2 ?
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
I've seen the same problem
I've seen the same problem few week's ago one of the network administrator changed the ip and name of the SEPM manager after that all the users stopped to communication with the SEPM, and i've tried many ways to restore the communication but didn't work at all, so i decide to create the packages with the functions to remove the old polices and reset the communication and I exported the packages to a network share and I went on some machines to try install the client and I faced the same problem with the explore, and it used to happen only on the folder that the packages was on it. Something I noticed on this machines was if I remove and if I stop the service I could open the Network Share quick again.
So guys if u get a easy solution for that please put on the forum, I would like to know!!!
Thank's
Rodrigo Benedik
The work around would be
The work around would be temporarity turn off File-System AutoProtect
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
I am still waiting from
I am still waiting from Symantec on what version the fix wil be in. They reported to me just today that they are seeing it on Windows XP clients as well in internally testing. I can't find one XP client, or 2003 Server client in my enviroment having this problem. Only Vista, Sever 2008, Windows 7, and 2008 R2.
Finally got the final
Finally got the final response from the Symantec report team, very very dissapointed in their answer:
"After extensive testing and review of the information on our case the team has determined that the behavior you are seeing appears to be normal functioning of the SEP software."
NORMAL!? no way. Guess we won't be seeing this fixed in a future release after all, removing this as solved.
Hey,
I agree with you. This is NOT something normal... There is a catch .... By the way, apart from UAC, one thing which is common to the mentioned OS is the bitlocker driver encryption... Any possibilites of that coming in the picture?
Cheers,
Visu.
I came, I saw, I err ;)
Visu, Bit Locker drive
Visu, Bit Locker drive encryption is not coming into play here. Some people are using it here, but hardly any really to be honest. I myself am not using it and the problem is still there. Simply disabling Auto-Protect temporary should not be the solution they are trying to push. I have gave my disapproval to the front line support tech and hopefully it will motivate them to look at actually getting it fixed in the future.
Well,
Like I said, that was just a shot in the dark... :D ... Anyway, I'm still guessing that this is NOT working as per design.. We haven't had any such problems, or at least I haven't see them personally.... And check this out, Symantec claims this as a known issue and also says that it has been fixed in MR4 MP2.. :)
Windows 2008 dropping network shares with AutoProtect enabled
Fix ID: 1290133
Symptoms: Network shares become unresponsive after installing Symantec Endpoint Protection MR2 with AutoProtect enabled on a Windows 2008 server.
Solution: Modified Auto-Protect to address the problem.
Cheers,
Visu.
I came, I saw, I err ;)
OK, I have been working with
OK, I have been working with Symantec since October on this issue, and they FINALLY are giving up.
They tell me this is simply "normal" behavior of their client due to "the agressive nature of the scanning engine." What? Once again, I have been dissapointed by their efforts to fix simple performance issues.
They even posted a article about it:
Computer performance slow when right-clicking on packed file with an unmanaged Symantec Endpoint Protection client installed
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2009030210091848
However, I pointed out to them I have running a manged client, and a newer version of what the article says is the problem (11.0.4). I am running the latest (11.0.5002)
Would you like to reply?
Login or Register to post your comment.