Discovery and Inventory Group

 View Only

Inventory Solution Troubleshooting Tips and Tricks 8 - Policy Advanced Run Options 

Nov 19, 2018 03:57 PM

Inventory Policy Advanced Run Options

Many of the Advanced options were discussed in the previous section. This section covers those options under the Run Options tab, and expands on what was listed earlier. Some of the Advanced Run Options have significant impact on how the Inventory Policy executes.

 

Delta Inventory

This option makes a huge difference on what is sent to the Notification Server. If checked, after data is gathered it will be compared to what has already been sent.

NOTE: Having a policy that sends full data can help avoid situations where data classes are missing altogether, as covered previously.

This is done in the following ways:

  • For the Hardware, Operating System, User, and Server Inventory data classes, the data is checked against what is stored in the NSI fragment files. These are located at C:\Program Files\Altiris\Inventory\NSI. If the data is the same, nothing will be sent up to the server for that particular data class.
  • File Scan data is gathered, and then checked against what is listed in the InvData.mdb database file, located at C:\Program Files\Altiris\Altiris Agent\Agents\Inventory Agent, or C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent (the drive letter may be different if a different install path was chosen for the Symantec Management Agent). Files not previous recorded are compiled into the NSE, and files that have been removed are compiled in a separate NSE. These are then sent as the delta updates to file data.
  • For the Software – Windows Add / Remove Programs option, after the data is gathered it is compared to the softwarecache.xml file, located at C:\Program Files\Altiris\Altiris

Agent\Agents\Software Management\Data. Software both added and removed is compiled into a single NSE to be sent to the Notification Server for processing.

 

System Resource Usage

This option only refers to the File Scan. Low has been found to be sufficient for most environments, and is the default setting. Very Low has been used when impact to targeted machines has been noted. The side-affect is to increase the time it takes for the file scan to run. Hardware, OS, User, Server, and Software inventories are not affected by this setting. An algorithm is used to determine how much CPU is being used by our process, and by other processes. The scan will be throttled back if a system is in heavy use, and will increase resource usage if a system is idle. How throttled or how much utilization to use is determined by the setting. Development did create a chart on what the projected usage is, however due to so many factors it was not published as it is too difficult to predict.

 

Throttle Inventory Scan

This option provides a much needed tool to avoid both network clogs and Notification Server load balancing issues. The text indicates: Throttle inventory scan evenly over a period of: X hours. The throttling refers to the overall execution of the Policy on all target systems. Not only can network and NS loads be alleviated, virtual environments can avoid stressing the host servers that run the virtual machines. For example if all virtual machines started running a file scan, the I/O on the host server would hit the roof and bring the server down.

Please take into consideration the following items when using this feature:

  1. WARNING: Do not exceed the typical uptime for your computers. Read through the below options for the technical details behind this warning. If the random time selected exceeds the uptime of the computer, when the computer is shutdown or restarted the inventory policy, held in a running state, will fail and inventory will not be gathered and sent.
  2. When this setting is consulted, the Inventory Policy is already executing according to the client Task state. You’ll see the policy executing in the Client Task History. It will remain in this state until it has waited and finally gathered and sent inventory.
  3. The clients will use an algorithm to determine how long it will wait to gather inventory with the window provided. For example if 8 hours is chosen, the client will randomly generate a wait time within that timeframe. If 4 hours and 30 minutes is randomly selected, it will wait that amount of time before beginning the gathering process. The law of averages typically spread out the executions to throttle when those clients gather and send inventory.
  4. When the gathering is complete the data will be sent to the Notification Server, ending the policy’s execution with a success. In the above example if the gathering took 20 minutes, the entire length of the policy execution would be 4 hours and 50 minutes.
  5. Since the execution is active during the wait period, if the machine restarts, or the Symantec Management Agent service is stopped or restarted, the execution is then considered a failure when the Agent reloads. When this happens the policy is considered failed and will not retry. Use caution on when policies execute and how long they can wait based on this potential adverse effect.

 

Run Inventory User

Typically this should be left alone. The System account, and the impersonation it is capable of, provides the access it needs to gather the pertinent inventory. There are a few items that may require this to be changed. For example if you want to gather what drives are mapped, and what shares are open for a user the policy needs to run under the Logged in user. Mapped drives are typically user-based, so this would be required to gather this data properly.

 

Another example is in situations where the System Account has been locked down. In those cases selecting a specified user that has administrator rights on target systems may be required.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.