Policies versus Tasks

Both policies and tasks have their pros and cons. I recommend using Policies for most use-cases, but there may be times when a Task is the right choice to be used. The following table provides the pros and cons for each type.

Highlights for a Policy – With a policy you can enable and then let it go. Clients will get the policy and run it per the schedule regardless of connection state. For a situation where data is needed immediately, a policy may take time to propagate down and return data. Policies cannot be added to a Managed Delivery from Software Management.

Highlights for a Task – Computers must be online at the scheduled time or they will not run it. For situations where data is needed immediately, tasks will very quickly run on active computers. Tasks can also be added as part of a Managed Delivery policy.

An example of a Managed Delivery Policy running Inventory was provided in the section 32-bit Plugin failing on 64-bit. This gives you more capabilities per what a Managed Policy can do.

Inventory Policy

This section will cover most options and advanced options relating to running Inventory. The Policy will be the main focus as opposed to viewing a Gather Inventory Task.

Policies offer the best option for most Inventory scenarios. Once a policy is setup, clients will download their client configuration XML to obtain the policies, and will thus have it ready to execute on the client when the scheduled time arrives, regardless of what connection state the system is in. Note that Inventory Policies ignore Maintenance Windows due to the nature of inventory capture. Each section here covers areas of the Policy configuration.

Policy Scheduling

Scheduling is an important part of Inventory Solution. To ensure Inventory remains relevant and up-todate, how policies are scheduled should take careful consideration.

Default Schedules

Each Inventory Policy has 3 default schedules that can be used. The default schedules execute at 6:00pm (18:00 military time). The Weekly schedule executes on Monday, and the Monthly schedules executes on the first Monday of every month. Note the following items concerning these default schedules:

• If a computer misses the scheduled time, it will execute as soon as possible afterwards.
• There is an ASAP function built into the schedules. The first time a computer receives the policy, regardless if it is a designated day or time, it will execute the policy.
• Default is Agent time for these times.

Custom Schedules

A custom schedule changes the rules. These schedules are determined by the user when Custom schedule is selected. The Custom schedule is also a hyperlink that opens the page to create and edit the schedules associated with the policy.

Note the following items when using a custom schedule:

• If a computer misses the scheduled time, it will execute as soon as possible afterward unless the Advanced option “Only run at the exact scheduled time” is checked. Also note that if the policy is added to the queue at the scheduled time, it may not execute until later if other jobs are being run. For Inventory, it is not advised to use the exact scheduled time option as it will create the possibility of missing a scheduled inventory run.
• Reoccurring schedules (one with a repeat selected) do not have an ASAP function built in. This means if a monthly schedule arrives at the client the day after the scheduled time, it will wait until the next month to run inventory. To avoid this, a run once schedule with no repeat should be created. The start date in the Advanced options should be set in the past. This way when a client first gets the policy, the client will see it is after the scheduled time and run it immediately. The screenshot above shows how the two schedules can be configured to act this way.
• The Start date should be the day the policy is enabled or earlier. For Inventory it does not make sense to use an End date unless this is a special policy you only want to run for a limited duration.
• Most of the Advanced options should be left as they are when the policy is created.
  

Scheduling Considerations

For most schedules another major factor to consider is how other Inventory policies are scheduled. There are considerations that must be taken into account to avoid bad inventory integrity. Please review these when setting up your Inventory Solution schedules.

1. Full Inventory – Should be scheduled often enough to avoid out-of-sync issues. The default is weekly due to issues encountered where inventory would not be in sync from client to server. In many instances a full inventory capture will resolve these issues. Full Inventory should at least be run Monthly.
2. Client-Server integrity – One current limitation with how inventory works is a lack of confirmation or validation from the client to server, and vice-versa. The client keeps track of what Inventory it has sent, but has no way to validate if the server received it, or if that inventory has been lost in some way on the server. At the same time the server keeps track of what data it has inserted into the database, which may not match what the client thinks it has sent. The following list include ways inventory can get out of sync:
   1. Computers merged – The merging process can delete inventory data from a record. Only one record’s inventory is kept.
   2. Duplicate Guids – If a system shares a GUID with another, inventory is overwritten at the server, so the inventory will be inaccurate or nonexistent when the duplicate issue is resolved.
   3. Computer record deleted from the database – Through Purging Maintenance or a deliberate delete action a record’s inventory is deleted. Once deleted, the computer can be added again, but that inventory is now gone.
   4. Data deleted from tables – without a deletion or update to the ResourceUpdateSummary table. This table contains a hash-check. The data sent from the client includes a hash that the server will compare to what is in the ResourceUpdateSummary table. If they match, that data is not inserted into the database. At this point the server does not check to see if the data is actually in the table or not.

The first 3 issues are resolved when a full inventory is run. The 4^th one requires additional work to resolve (covered in the troubleshooting section).
NOTE: Starting in 8.5, We now detect and remediate outdated inventory. This will be covered in later articles.

3. Schedule Overlap – Inventory has intelligence to avoid capturing inventory simultaneously for two policies. Each time a policy executes, it checks to see if another inventory thread is running. If

so, it puts its own thread to sleep and waits for the first one to finish. This can be avoided, and should be. Consider the following when scheduling multiple inventory policies:

1. 1. Do no schedule different Inventory Policies to run on the same day.
   2. Account for the weekend where systems are typically turned off so multiple policies don’t execute Monday morning.
   3. Judge performance to see how often inventory should be running in the environment. Too aggressive inventory can cause the server to be busy, affecting general and console performance.

Delta Inventory – Delta inventories should be limited to specific data points. For example, running a frequent Delta with only the option “Windows Add / Remove Programs…” checked can yield good results in keeping track of what software is being installed. If this included all other data classes, it would send more data each time it ran. By limiting the scope of what is collected, it can be scheduled more often to meet specific requirements, as for software tracking in this example.