Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

RDP 6.9 server works for 4 hours then stops deploying jobs

Created: 17 Mar 2014 | 2 comments

Hello all,

I can't seem to figure this out but when I reboot my server I can then deploy jobs for 4 hours. After that period it fails to deploy jobs. It seems it can no longer communicate with clients. Nothing shows up in the jobs status or anything. Everything is blank. Once I reboot it then it all works. Anyone have any ideas? Where can I find the logs on the servers to see if there is an error. Nothing shows up on the client logs.

Operating Systems:

Comments 2 CommentsJump to latest comment

SK's picture

The engine is most likely becoming overloaded.

What OS is the DS running on?

What DS service pack is it?

How many clients?

Are they running the aclient or the dagent? What version and how have they been configured?

What are the DS's global options set to?

How has the DS's control panel applet been configured?

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

Maymne's picture

Sorry, lost my earlier post because our web filter is terrible. Here goes at another attempt.

Post from 2010 with a similar situation:
https://www-secure.symantec.com/connect/forums/altiris-ds-must-be-restarted-often

Solution which was linked there from 2005 (updated in 2006):
http://www.symantec.com/business/support/index?page=content&id=TECH10489

Same solution provided in 2011:
https://www-secure.symantec.com/connect/articles/deployment-console-why-are-computers-offline-troubleshooting#comment-6190531

Basically, if you have this sort of thing happen, one of the major reasons is SQL database bloat. Especially if you have recovery mode set to Full or Bulk, you can have your transaction logs expand to huge levels - one person posted 32 gigs of database of which 31.9 gigs were their logs. The KB article suggests changing your database recovery mode to Simple unless you actually want to properly maintain it.