Configuring Inventory Solution for Better Notification Server Performance

This article covers how to configure Inventory Solution to minimize the impacts on the Notification Server. Inventory generally causes load issues at certain times when Inventory tasks are scheduled to execute, thus all systems send Inventory at those times almost simultaneously. Other events also increase load on the server. Use the following items to tweak the way Inventory is running, reporting events, and sending Inventory to avoid costly resource impacts on the Notification Server.

Understanding the Impact

What load does Inventory cause on the Notification Server? Understanding this, and understanding what Inventory needs you have, can allow you to configure Inventory Solution to only impact the Notification Server as needed. The key is to scale down or eliminate those items that will not be utilized by your environment. Inventory impacts the following areas on the Notification Server:

• Package Download and Update Events
• Task Status Events
• Execution Events
• Delta versus Full Inventories
• Inventory Event files and Data Loading
• Database size

Package Download and Update Events

Any standard Notification Server Package (whether internal to a Solution like the Inventory Agent Package or otherwise) is downloaded through a series of steps, many of which involve the sending of a status NSE (of type AeX SWD Package). Each download or update of the package involves multiple small status NSEs being sent to the Notification Server and are logged in the table Evt_AeX_SWD_Package. While this can be completely disabled across all Solutions, Inventory provides the option to disable these just for the Inventory Agent Package. Unless you have a good business case to keep these enabled, for optimization purposed it is recommended to disable these. It can always be enabled again should a need arise to track the status of this package being downloaded.

See this screenshot for the option:

Click to view.

By taking out the checkmark on this box you disable the sending of these package events. The corresponding status events will not be sent through the evtqfast data processing queue.

Task Status Events

Not to be confused with the execution return code of the Inventory Tasks, Status events include the following event types:

• New Job - The Altiris Agent has received a new Task.
• Job Updated - The Agent received an update to an existing Task.
• Download Complete - Agent has completed downloading the Package associated with a Task.
• Job Activated - A Task previously disabled has been reactivated.
• Job Removed - A Task has been removed after successful completion.
• New Package - The Agent has received notice of a New Package associated with a Task.
• Package Removed - A package has been deleted from the client system.
• Package To Be Removed - A package is no longer active and is scheduled to be delete after the time set according to the Package's settings.
• Package Updated - A Package has been updated due to changes to the snapshot.
• Unable to check package - Unable to check the status of a Package.

All these events are captured in the 'Evt_AeX_SWD_Status' table.

Depending on the business needs and environment, these statuses may be unnecessary if it's the execution status or lack thereof that is the prime events for tracking. These events are by default disabled on each of the Inventory Tasks, eliminating all of these types of events being sent to the Notification Server.

The UI does not provide a checkbox or other UI element to enable these status events, though if the XML of a task is exported it can be manually changed.

1. Right-click on the Inventory Task in question and choose Export. It will save as an XML file.
2. Using a true XML editor, open the exported Inventory Task XML and search for <statusEvents enabled="false"/>.
3. Change "false" to "true".
4. Save the document.
5. Right-click on the 'Inventory Tasks' folder wherein resides the Inventory Tasks and choose 'Import'.
6. Choose the modified XML file.
7. Status events will now be enabled.

Execution Events

Execution Events should not be disabled; however on a truly taxed Notification Server there is a method to disable Execution Events.

1. Apply NS SP3 R4 to upgrade the install dir\Altiris\Altiris Agent\AeXSWDAgent.dll version to 6.0.1524.0 (You must upgrade the Altiris Agent to apply this new DLL version).
2. On the client machines create a new registry value "ConsiderExecutionEventsAsVerbose" at the location "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Software Delivery" and set the value to "1". This will consider the execution events as a part of verbose reporting.
3. For Inventory the Status events are already disabled (as previously indicated) so no further steps are required.
4. A registry update can be rolled out to machines via Software Delivery Solution to apply this.

It is recommended to keep execution events activated as that is how you can track what machines have run Inventory or not, and if not, what occurred during the execution.

Delta versus Full inventories

There are two different types of Inventory Tasks: Delta and Non-delta. See this list to see what are of which type:

• Hardware Inventory -- Delta
• Recreate Full Inventory -- Full
• Recreate User Inventory -- Full
• Software Inventory -- Delta
• User Inventory -- Delta

While the actual client-side impact doesn't much differ between the types, the data sent across the wire to the Notification Server can differ greatly. In way of explanation, Inventory is collected by the different Inventory Agents into NSI files copied to C:\Program Files\Altiris\eXpress\Inventory. When Inventory is complete, the files are renamed to .BAK. If delta Inventory then runs, it will compare it's collected files with hashes against the .BAK files from the previous Inventory scan. Only those NSIs that have changed are collected and sent up to the Notification Server.

Click to view.

Inventory Event files and Data Loading

Noting the above details, the Inventory Tasks will generate an Inventory NSE off of the NSIs collected from the Inventory Agents to be sent to the server each time they are run, per task. With five default tasks running at regular intervals, the amount of data being sent up can vary depending on how often they are set to run. Also since Inventory Tasks execute company-wide there are also issues during the time Inventory is being collected and processed as a load on the Notification Server.

Recommendations:

1. Introduce AeXRunControl.exe into the Inventory Tasks.
2. AeXRunControl executes per a configured command-line and introduces a random 'waiting' period before the actual Inventory Task is executed in it's fullness.
3. In the Inventory Tasks, check the box 'Run this task on a random schedule (All machines at different times).
4. Now browse to the Program for that task by clicking 'Go To Program'
5. The command-line will now start with 'AeXRunControl' as in the following example:
   

   AeXRunControl.exe /mdschedule "Inventory Solution" AeXInvSoln.exe WEEKLY 1 5 /useHKCU 
   
   

6. The command-line can be configured to expand or contract the execution window. The above example will execute between the weekdays of Sunday and Thursday.

Other Recommendations:

1. Hardware Inventory does not often change, so this schedule can be set regularly depending on your business need for hardware tracking. Scaling this back to weekly or biweekly will help lower the amount of data sent up to the Notification Server.
2. Recreate Full Inventory should be left alone unless a situation arrives where it should be run more frequently. The default is at the beginning of every month. All data is sent and results in a significant impact to the Notification Server, especially if hundreds to thousands of machines are sending this amount of data over the wire to be processed by the NS.
   
   Note: If you ever have to use a new database, restore an old backup, migrate Agents, or delete computer records that are added again to the Notification Server you should schedule a Recreate Full Inventory for all machines shortly thereafter to update all records. Remember that Inventory deltas will not know that the server doesn't have the data that hasn't changed since the file hash comparison is conducted on the client-side.
3. Recreate User Inventory -- Similar to Recreate Full Inventory: see suggestions pointed in point #2
4. Despite being a delta inventory, Software Inventory almost always sends all data collected to the Notification Server. This is due to the audit data being collected to a single large NSI file named auditpls.nsi. Any change at all to any captured software, additions or subtracting, will trigger the entire data set to be sent. It is recommended to scale this back to at least weekly or to specific times before reports need to be run on installed software.
5. User Inventory -- Likely there isn't a need to run this daily. Scale this back to weekly or as required by your environment.

Other possible approaches include disabling the delta Inventory tasks and relying on the full at the time of reporting or audits. This reduces all traffic and inventory to those times when they are specifically required. Tweak with the schedules to find a fit for your environment.

Database Size

There are options that can bloat your database with Inventory information and potentially severely affect your Notification Server performance due to SQL impacts.

Resource History: This can severely bloat a database. Inventory Data Classes have an additional table created with a HIST in the front (ie: histInv_AeX_SW_Audit_Software). When a row is inserted into the regular tables, the previous row is backed up into the history table. This is NOT recommended on large data classes.

Click to view.

Also for database improvements, see the following article:
http://www.symantec.com/community/article/1630/imp...

Conclusion

It is highly recommended to understand the needs of your organization to understand what changes can be made in the environment without impacting how Inventory data is being used. For example if Software Inventory only runs once a week, but reports are run twice a week, there could be a discrepancy within one of the reporting periods.