Video Screencast Help

Booting SEP client machine takes 3x as long as without SEP

Created: 31 Jan 2008 • Updated: 21 May 2010 | 22 comments

    I've gotten around to working with our updated software from SAV 10.x. I installed the console on our Dell PowerEdge 1800 Win2003 Server SP2, installed a client on the same server and a client on another local machine. Booting the server doesn't take much longer than normal but the local machine went from a startup time of ~4 min to ~12 minutes. It takes 5 minutes just to get to the desktop and it still hasn't finished booting so you can't do anything.

Any first thoughts? I can't put this on any other machines until I know it will work flawlessly on them. So far 50% ain't so great...



Comments 22 CommentsJump to latest comment

tpi's picture
I'm having the same issue within our IT dept. I haven't had the nerve to roll it out onto the servers yet. I also haven't done a ton of configuration, so there is probably something I'm missing...
bctmike's picture

Well, I've manually uninstalled it using the long instructions found elsewhere in this forum and reinstalled it as a stand alone version. Now instead of 3x the boot time it's 2x the boot time. I'm glad my machine is on all the time or I'd be pissed...

Matt Pierce's picture

We have noticed this behaviour since moving to MR1.  The machine will sit at the blank desktop after entering domain credentials on login.  We've so far isolated the issue to machines with wireless interfaces.  If you turn off the wireless interface the machine boots fine.  Were working to get more details as we go.  We have AV, Spyware, and Proactive Threat Scan enabled.  Network Threat Protection is not enabled.

SKlassen's picture
Two things I can think of to look at:
1)  Check in your scheduled scans.  If there's an active entry for doing a quick scan on startup you may want to consider turning it off.
2)  Is Network Threat not installed or installed and disabled?  If you have it installed and just aren't using it, uninstall that component or it will use some system resources.
bctmike's picture

I was not able to find any "scheduled scans." Is this because I've got it currently installed as a stand alone? I'm pretty sure I've seen it before...

I did see the "Scan files on network drives" under the "Auto-Protect" settings and just disabled it. I'll restart and see what happens.

I have all components of SEP installed and active.

10987654321's picture
Have you disabled scanning the computer every time someone logs in? After I disabled this feature and set scans to take place when people are not logged in, rebooting went back to normal. We have older machines with only 512 GB Ram - scanning on logins were crippling us.
bctmike's picture

I'm almost positive I DID disable that. I've just searched through every screen and can't find any option for scheduled scans. I'm gonna have to uninstall this and reinstall with the EXE the console made to get SEP back with the Server and make sure it's disabled, right?

bctmike's picture

Well, nothing really new to report. I downloaded MR1 and installed the MC on the server and a client on the server and my workstation. Haven't yet found out if the shares will stop dropping.

But, as to speed... I was getting excited as I booted up my machine after installing the client package with MR1. The desktop came up rather quickly (1:30 min). But, it was close to another 8 or 9 minutes after that that I was actually able to do anything. It was a good 3 minutes from the time I clicked my Outlook icon before it popped up and just as long before it began to check for mail.

Don't really know where to go from here. From everything I've read Symantec support is nice but rarley comes up with an answer or solution. I guess I'll find out in the next day or so...

Bored Silly's picture

We migrated to SEP 11 to our entire client base by the end of 2007 (roughly 8,500 workstations and laptops) since our old AV licenses were going to expire.  We haven't rolled it out to our servers yet.  One of the developers of SEP stayed onsite for 3 weeks to get to the bottom of the boot issues. 

Here's what we found about boot slowness or no desktop appears at all after entering credentials:

1.  Condition: After entering username and password, you get nothing but your background desktop picture and are able to use your mouse.  The desktop will never show up.  You can CTRL+ALT+DEL and launch Task Manager which in turn will allow you to manually run Explorer.exe to jump start the desktop.  After which, the PC will run normal.  You can also log out and log back in which normally results in a normal bootup.  Cause: The cause of this turned out to be a Microsoft glitch in the Userinit.exe.  Microsoft actually took responsibility for the issue after 3 months of us thinking it was a SEP issue.  Solution/Workaround: They are trying to come up with a fix but in the meantime, Microsoft mentioned that you can enable "Run Login Scripts Synchronously" which will avoid the situation all together.  The downside to that setting is that it will add time to the bootup process which we were already suffering longer boot times than normal.

2. Condition: The bootup of the system is significantly slower than normal.  Cause:  There are several causes but it appears to be (according to the Symantec developer that came on site) that the location of the definition files on the physical disk makes all the difference in the world.  We defragged the drive which moved the definition files closer to the center which made the bootup near normal (he verified that it moved via a tool) .  Systems with less than 512 MBs (even some with 512 MBs), conflicting applications, infected systems, and unstable operating systems will also play a major role.  Solution/Workaround:  The SEP MR2 (due out soon) is supposed to help fix this.  Assuming the system isn't infected or has an unstable OS or conflicting applications, the easiest/quickest way to help alleviate this is to dump all temporary files, internet cache, tmp*.tmp folders in the virusdef folder, system restores, etc and then defrag the drive.  After which, as an optional step, you can make a static sized page file (to avoid swap file fragmentation).    This fixed most of the issues.  In the cases it didn't, we reimaged the systems and/or we upgraded the RAM to at least 1 GB.  This seemed to fix the issue 99% of the time.  Though the minimum requirement of RAM for SEP 11 is 256 MBs, it seems to work much better with 1 GB.

bctmike's picture

Hmmm... I find it INCREDIBLY DIFFICULT to believe that the fragmentation of data for ONE program would cause my machine to take 3x as long as normal to boot.

This machine has 1 gig of memory. It has always been protected with some form of SAV so the chances of it being infected are very, very slim. Conflicted programs is pretty open ended. I don't know what it would be conflicting with. The OS  has been in place for probably 4-5 years but I've been using it for 3+ of that time and it is as stable a machine as I've seen. I ALWAYS make a static page file to avoid fragmentation.

I learned years ago that manufacturer's specs on something are what it will take to run. Making the machine usable is always a different story.

I'm searched for the virusdef folder but came up with nothing. Would that be on the server with the console?

I will defrag but I'm not honestly holding my breath. I'll report back...

Bored Silly's picture

I had a hard time wrappign my brain around it but the developer was able to show the location change and the PC booted normal.  My guess is that it pulls the files closer to the center of the platter which makes the difference.  We've done it dozens of times but it's really only a work around until MR2 gets released.  My guess is that MR2 fixes how the driver level protection works with the definition files.  I'm supposed to test teh MR2 here in the next day or so, which I truly hope fixes the issue.  Defragging that many systems is a freakin pain.

Bored Silly's picture

Please excuse my cronic typing errors.  I'm multitasking so I apparently can't type and chew gum at the same time.

bctmike's picture

Sounds like defragging may not work for me. We only have a commercial version of DisKeeper on the Servers. All the workstations have the Windows built-in defragger which does not "optimize" the files position on the platter.

Bored Silly's picture

Also, the conflicting applications are those that have a hard time coexisting with SEP.  Older VPN clients, BD FacsDiva (database), Tempus (scheduling), and Toxicall were having issues with SEP that resulted in slowness, errors, etc. 

Bored Silly's picture

We used the Windows Defrag on the PCs.  We're not running it on the servers right now and won't be until MR2 comes out and is verified safe.

Also, keep in mind that defrag only helps the boot-up slowness.  If you are experiencing slowness after bootup then defrag the won't help.  I would use Process-explorer (from Sysinternals) to see what SEP is chewing on and then exclude it from scanning.  If that doesn't help then I'd open a ticket with Symantec since they've been responsive with troubleshooting applications. 

Just a thought.  Good luck.

bctmike's picture

Is there a list of "conflicting programs" somewhere? I have none of your listed programs installed.

Bored Silly's picture

Unfortunately, I haven't seen an official list.  These are the ones we found out the hard way.  We have an unusual amount of exclusions (compared to where I used to work) for applications so the list could even be bigger.

One the few servers we have SEP installed on for the pilot program (besides the management servers), we only have the Antivirus/Antispyware installed. 

bctmike's picture

Well, I downloaded Process Explorer but I can't see that it's anything more than a little more detailed Task Manager. I don't know how to figure out how to see what SEP is working on. The funny thing is that the machine, even when booting and really cranking on the hard drive, is usually 80%+ system idle.

I can that smc.exe, smcgui.exe, rtvscan.exe, ccsvchst.exe, ccapp.exe all intermitently gobble up 3%-5% of the processor. Even though I've set my policy up to DISABLE the onboot scan.

I'm looking at the Threads in Properties for rtvscan. Is this what I'm looking for? I see a lot of msvcr80.dll and kernel32.dll. If that's what I'm supposed to be looking for I guess I'll have to restart againi to watch it.

Sandeep Cheema's picture
This is what I would suggest :
1)Take out the startup scan.
2)Change autoprotect settings from computer starts to Symantec Endpoint Protection starts(In Policies-antivirus and antispyware policy-autoprotect-advanced)
Lock the icon and issue the command to the client.
The next time the client boots up , It should take significantly normal time

De facto when AV does something, it starts jumping up and down, waving its arms, and shouting...

"Hey!  I found a virus!  Look at me!  I'm soooo goooood!"

JimW's picture
I have also heard reports that deselecting the option to run an active/quick scan after definition download is improving the startup time. If a system is offline when new definitions are available, they will be pulled down during system load and a scan will run which has the side effect of slowing down the login.

Jim Waggoner Director Product Management, Symantec Endpoint Protection, Enterprise Security Group, Symantec

bctmike's picture

Sandeep_Cheema wrote:
1)Take out the startup scan.
2)Change autoprotect settings from computer starts to Symantec Endpoint Protection starts(In Policies-antivirus and antispyware policy-autoprotect-advanced)
Lock the icon and issue the command to the client.

There was/is NO startup scan.
I changed the Autoprotect setting to SEP starts.
I didn't see any way to "issue the command to the client" so I just restarted my machine assuming it would check the policy on boot.

It appears to be much, much better although rtvscan.exe and the two smc*.exe processes are still working away on bootup.

Am I incorrect in that rtvscan.exe is the actual scanning program? If it is running a virus scan is being conducted? If that's the case it shouldn't be running at all, should it? Here I am 12 minutes and counting after rebooting and rtvscan.exe is still working on something.


10987654321's picture
2 workstations that were taking 10-15 minutes to log in now take 3 full minutes (I uninstalled, ran the Symantec clearner, ran a registry cleaner and reinstalled Symantec). When I uninstall Symantec, it takes ZERO minutes. Granted I improved log in time, but 3 full minutes to get control of your computer is ridiculous. I already have Symantec set to not scan at startup and set the File System Autoprotect to start when Symantec starts.
Other problems we are having is that scheduled scans on some computers scan repeatedly when they are not supposed to. This has been an open ticket with Symantec for weeks.
I've been trying to make this software work right since December. If MR2 doesn't fix these problems, I am going to suggest to our I.T. Manager to "move on to something else". I've had it.