How can I reduce unnecessary processing load on my Notification Server?
Updated: 04 May 2007 | 4 comments
Some users have found that their Notification Server is taking a long time for console refresh and access. Learn how to speed it up here.
While there are certainly many reasons behind this, one simple reason is documented in a knowledge base article titled:
"How do I Turn off AEX SWD Status Summary Events?"
This KB article gives one option to reduce one area of processing load on the NS. There are some limited reporting tradeoffs here,
but for the most part, this is a setting that can easily be adjusted.
See KB 32172 for the full details.

The Endpoint Management Community Blog is the perfect place to share short, timely insights including product tips, news and other information relevant to the Endpoint Management community. Any authenticated Connect member can contribute to this blog.
Comments
Your server helps
I talked to someone on the Altiris help desk about the slowness of our Deployment Console. They said that a normal work station could handle the job. They also said the most important thing we could do is have 4 GB of RAM. The database requires a lot of RAM.
They also said that a similar configuration for a Notification Server (a normal work station with 4 GB of RAM) would do the trick.
Another trick they told me is to have Deployment Console and Notification Server on two different boxes. They both have heavy-duty databases.
-trb48
I find that hard to believe
Who told you that you can use a workstation to run DS and NS? These products are classed as server apps, because they require many connections to a database.
If you have about five computers to manage, then yes, use a workstation, but other than that, you need a NOS and not an OS.
If you are referring to HW, then yes you can use any type of HW as long as it provides the performance you require.
Having DS and NS on different boxes is the way to go, which is what I believe you were referring to when you said to have the DS Console on a different box. Please remember that DS allows you to install all of its components on different boxes if you so wish, and that it is wise to have the DS Server component on a separate box than the NS.
Just to understand when
Just to understand when this can be a problem, can you give an example of servers where can be seen this bad performance, such for example how many clients, etc.
Thanks
PM
RE: Just to understand when.....
Often, during a big Software Delivery push, this can be an issue.
Also, if your DB is having a hard time keeping up, changing this setting can reduce the number of events the DB has to process and post to the the DB.
While the number of solutions, and client config, etc, can have an effect, some experience has shown that a full CMS L3 with over 12K clients can sometimes display slower console behavior....but this is not written in stone....
Would you like to reply?
Login or Register to post your comment.