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:
https://kb.altiris.com/display/1/kb/article.asp?aid=1859&n=19
https://kb.altiris.com/display/1/kb/article.asp?aid=17079&n=19
https://kb.altiris.com/display/1/kb/article.asp?aid=19750&n=19
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.
https://kb.altiris.com/display/1/kb/article.asp?aid=17950
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:
http://msdn2.microsoft.com/en-us/library/ms998549.aspx
http://msdn2.microsoft.com/en-us/library/ms998583.aspx
| 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. |