Video Screencast Help
Symantec Secure Login will be live on Connect starting February 25. Get the details here.

Performance Tuning Notification Server

Created: 03 Dec 2007 • Updated: 03 Dec 2007 | 5 comments
bassings's picture
0 0 Votes
Login to vote

We recently upgraded our NS infrastructure and as part of the process we scripted most of the install. Here are a few snippets of what we did.

One of the goals of our Altiris Upgrade project was to automate as much of the Altiris installation process as possible. An important part of this initiative were some scripts we wrote to do some basic performance tuning of our NS infrastructure. Each of our Notification Servers could be managing up to 10,000 devices and the out-of-the-box settings for Notification Server cause a large number of deadlocks in the Altiris Database.

It's important to note that performance tuning the Notification Server is only a small part of the performance tuning of your Altiris infrastructure. Big performance gains can be made by performance tuning your SQL Server.

I highly recommend the following Altiris knowledge base articles when designing an Altiris management platform:

One other idea we came up with to improve performance on our Notification Server was to move the file-based disk queue to its own volume. We did this by creating a new raid 1 physical volume and then moved the contents of the nscap folder to this new volume (x:\Program Files\Altiris\Notification Server\NScap, where x: is the drive you installed Altiris on). We then used the linkd tool to link the old path of the nscap folder to the new drive. The syntax for this is:

linkd "x:\Program Files\Altiris\Notification Server\NScap" "Y:\Nscap"

Where x: is where you have notification server installed and y: is where you moved the nscap folder to.

The advantage of doing this is that Altiris and Windows still think the NScap (Notification Server client access point) folder is in the same location, and the operating system redirects the requests to the separate physical volume. As all the data coming from the clients lands in a folder under nscap folder (the evtq folders). In a large environment, this can result in a lot of disk activity. The Web pages for the Altiris server are on the same volume as the disk-based queue so in times of peak activity this can impact performance of the console.

The other 2 big performance changes we made are for coresettings.ini file which is where Altiris stores a large amount of its configurations settings. In the SetCoreSettings.vbs script attached we use WMI to query how many CPUs the Altiris Server has and then sets them based on the information in this article:

Recommended settings for updating the coresettings.ini.

The second script is SetMachineConfig.vbs which we use to fine tune .net based on the number of CPU's on the machine once again. .net uses a configuration file called machine.config. The original recommendations for this came from a white paper written by the now defunct Blue Willow Group. But good information can also be found from the following Microsoft Technet Articles:

Performance Tuning .net:

License: AJSL
By clicking the download link below, you agree to the terms and conditions in the Altiris Juice Software License
Support: User-contributed tools on the Juice are not supported by Altiris Technical Support. If you have questions about a tool, please communicate directly with the author by visiting their profile page and clicking the 'contact' tab.

Comments 5 CommentsJump to latest comment

faigi's picture

Valuable info !!!!


Login to vote
ArchY's picture

Interresting !


Login to vote
aroon's picture

Thanks man for Informative knowledge...

Login to vote
David Ekstrom's picture

So basically we should run these scripts on the NS and it will make the necessary changes in the files?

I'm not a .NET guy nor vbs guy.

Login to vote
scottwed's picture

Stumbled across this looking for another article in Juice. Two things NOT to do.

Don't modify the MaxConcurrent dispatcher threads based upon the number of CPUs present on the NS. That assumption was based upon a big leap in logic. The tuning of those settings should always be done based upon SQL performance. If anyone finds any other Altiris KB articles that still state this, please let me know. Increasing the number of threads has resulted in many trouble tickets to resolve SQL deadlocks.

For a pure CMS based NS, there is no value to increasing available .NET threads, and in some cases it actually hurts performance and can cause data loss due to SQL deadlocking. The primary bottleneck of the NS is always SQL. It's also not a supported configuration.

On the other hand, careful tuning of .NET threads for a pure Helpdesk server can be beneficial, but only for large implementations that have many concurrent helpdesk workers. Helpdesk, unlike the NS, appears to bottleneck first on CPU processing.

Scott Wedekind

Login to vote