Video Screencast Help

SEPM is killing my server

Created: 17 Jan 2008 • Updated: 21 May 2010 | 11 comments

I installed SEPM on my SBS 2003 box about two months ago and then pushed SEP itself out to a few of my client computers (I did not install SEP on the server itself).  In terms of performance, everything was running fine--there was no notable slowdown and all applications still ran correctly.  Yesterday, however, users began to complain about losing their connection to the network (not losing their shares entirely, but briefly losing the connection).  I opened up the task manager and the server's normal ~5-10% CPU usage had shot up to somewhere around a constant fluctuation from 70-95%.  I looked at the processes to see what was causing it and noticed "javaw.exe", which had never caused any issues before.  It would continually appear, sap CPU power for a few seconds, then disappear.  I remembered that SEPM used Java, so I killed the SEPM process and the server immediately settled down to its normal operating range.  As a test, I then started SEPM again and my server went back to maximizing its CPU.

Figuring that this might be an MR0 issue, I upgraded to MR1 this morning but it hasn't fixed anything.  As things stand, SEPM is shut down and none of my workstations are receiving updates (not that they were anyway, but that's a different issue entirely).  If nothing else I could just install it standalone on the individual workstations but that would be an administrative nightmare and I'm not particularly fond of that route.  Any ideas or suggestions?

Comments 11 CommentsJump to latest comment

guidoelia's picture
But are you sure the SEPM console  should be running when you don't use it ? Jawa is used when you connect IMO
bull_kad's picture
My best suggestion is call support! Tthey have developed a really great FIX, its called clean_wipe.
Clean_wipe uninstalls their software through this nifty DOS program.
Once you uninstall the Symantec software, everything is back to normal and works fine.
0WN3D's picture
Guys, simple fix:
1) Set Live Update to 4 hour mode for updates - both at the Client policy level (Live Update policy) and especially at the Server.  If you need more frequently than that, support has a script you can run that you can put in Windows Scheduled tasks.  This will allow you to set your own custom schedule. 
2) Get a DUAL CPU Server.  Not Dual Core, DUAL or QUAD CPU's.  LiveUpdate and the Definition parsing, updating process are very CPU intensive.
Aaron H's picture

The server is a dual Xeon 3.20 Ghz, so it should be sufficient.  Granted, it's also running Exchange and SQL Server, but SEPM was running fine alongside them until a few days ago.

As for the update schedule, I'll have to check that the next time I turn SEPM on.  At one point I had left it on overnight but the problem still persisted in the morning; I don't think it would take that long to parse and update new definitions so I don't know that that's truly the problem.

Frankly, I think something's broken.  I don't know how the program works, but I don't think it should be calling and killing javaw every few seconds, especially when (as guidoelia said) I'm not even using the SEPM console.

I'll let it run again tonight and see what happens.

Aaron H's picture

Seems something really is wrong.  I took a look at the logs and scm-server is filling up with this:

2008-01-23 12:41:57.500 SEVERE: Unknown Exception in: com.sygate.scm.server.task.PackageTaskjava.lang.NullPointerException at com.sygate.scm.util.GUIDGenerator.convertGUIDToHyphenFormat( at com.sygate.scm.server.publisher.compiler.logicaobject.AvPolicyCompiler.getAVCommandScan( at com.sygate.scm.server.publisher.compiler.logicaobject.AvPolicyCompiler.getAVCommandScanOptions( at com.sygate.scm.server.publisher.compiler.logicaobject.AvPolicyCompiler.getAVCommandScanOptionsLink( at com.sygate.scm.server.publisher.compiler.logicaobject.AvPolicyCompiler.compile( at com.sygate.scm.server.publisher.compiler.Spa50ProfileCompiler.buildAVPolicy( at com.sygate.scm.server.publisher.compiler.Spa50ProfileCompiler.compile( at com.sygate.scm.server.task.PackageTask.updateProfile( at com.sygate.scm.server.task.PackageTask.updateGroup( at com.sygate.scm.server.task.PackageTask.getChildGroups( at com.sygate.scm.server.task.PackageTask.getChildGroups( at com.sygate.scm.server.task.PackageTask.checkGroupDirectory( at at java.util.TimerThread.mainLoop( at

 Perhaps a call to support is in order.

0WN3D's picture
With respect to definition processing, there is more work than you may think.  There are 10 versions stored on the SEPM by default and sub versions for various OS types and 32/64bit.  Essentially, defs are "built" each time a new set comes in for each platform, and then there is re-ordering/housekeeping, cleanup, etc. done.  Also, LiveUpdate will run back to back to back to back...get the idea?  It does eat up alot of CPU...I ran various memory utilities against it and changing the update schedule helped tremendously.
austria's picture
Hello - Dear Aaron
We have the same problem on our server a view weeks ago. Have found a reason for this problem.
Please look at the following forum thread - post 7
Hope it works.  Since fix on our server works fine.
Aaron H's picture

ludbfix said it couldn't find "javaw" and dbisqlc wouldn't let me into the database, so I pretty much hit a wall.  Fortunately, my installation was small enough that I could just wipe SEPM from the server and reinstall it starting at MR1 (instead of upgrading), so instead of wasting more time trying to fix it that's what I did.  So far it's running fine.

Thanks for the help, everyone.

Aaron H's picture

The key words in that previous post being "so far"; it's back to its old behavior.  Interestingly, the problem seems to have occurred right around when I added a new client group, added policies for it and renamed existing policies.  Something like that breaking it is ridiculous, but it's the only change I've made since my re-install almost two weeks ago.  It can't be a coincidence.

I'm not re-installing this again.  If I can't fix it this time, I'm looking elsewhere.  On that note, does anybody have any suggestions?  I don't think this has anything to do with the "ludbfix" problem, given what I've stated.

kornholio's picture

Do you have replication enabled?  I found in our setup that replication ("auto replicate" is default) was the cause of the high processor utilization (60-70% all the time with spikes to 100% on both management servers).  Once I changed replication to 'daily', processor usage dropped off within 10 minutes to 15-20% (primary server) and 5-10% (secondary server, in place only for recovery purposes- no clients).

Aaron H's picture

I'm fairly certain that the cause of everything is the Java error, not a setting.  Both times it ran smooth until the error appeared.  Now it just contiually tries to crank out a package (or whatever it's doing), but because it keeps failing it just keeps trying.  The NullPointerExceptions that fill the log attest to this.