Policy instance

Each time a software package is assigned, the system creates a policy instance (derived from a policy) for every computer. This also applies if a software package is assigned to a user. As soon as a user logs on to a computer, the system creates a computer-related policy instance. The properties of the policy instances can be customized later.

Policy instances are created automatically. The system requirements (based on the inventory) are also checked. They can be specified in the Packaging Workbench for every software package. The system can only create a policy instance if these requirements for a computer are fulfilled.

The system distributes both the policy instance and the associated policy to the computers where the DSM Client evaluates them. The policy instance is needed for installing the packages; the DSM Client also checks the activation status and the activation time of the "parent" policy. This guarantees that the policy instances are only executed if their respective policies are also active. In addition, policies contain the priority of a package which is especially important for solving conflicts in case of multiple assignments.

All of a computer's active policy instances together can be defined as its desired state. The system controls the execution of the policy instances on a computer and the DSM Client reports the current state to the DSMDB. By comparing the desired and the current state you are always current on the "degree of compliance" of a policy, which can be tracked in the DSMC (see also: Compliance).

The following diagram shows the dependencies between the package, the installation target, the policy and the policy instance

Policy instances are displayed in the DSMC in the context of the individual computer and in the context of the policy, from which the policy instance is derived. The actual policies are only displayed in the context of packages, domains, groups or OUs.

Relationship between Policy and Policy Instance

The policy instance contains the actual values for executing a package on a computer. These values are passed on from the policy at first but can be customized per policy instance. A policy's active/inactive status and the time settings also influence the associated policy instances.

The assigned configuration, the desired configuration and the installed configuration are all stored in the policy instance:

Assigned configuration	The assigned configuration contains the package and the parameters, which are supposedly installed on the computer, according to the associated policy. The assigned configuration is only installed on the computer if it becomes the desired configuration of the policy instance. The assigned configuration becomes the desired configuration each time a policy is updated, when the Installer either runs a critical update or an uncritical update and then updates the policy instance separately later. The installation parameters of a policy instance can be changed in the assigned configuration. Note that the changes are only applied when the system updates the respective policy instance, applies the changes to the desired configuration and executes them.
Desired configuration	The desired configuration contains the package and the parameters, which are supposedly installed on the computer, according to the valid assignment. The DSM Client compares the installed and the desired configurations and then calculates the compliance from that information. If the instance is not compliant yet, the system automatically sets the corresponding execution mode (e.g. update) to reach the compliance. The compliance status remains compliance pending until the desired and the installed configuration are the same.
Installed configuration	The installed configuration contains the package and the parameters that are actually installed on the computer.

The following diagram shows the desired, the assigned and the installed configuration

Creating Policy Instances

Depending on the type of policy, the system creates the policy instances at different times.

Policy instances for Standard policies

Policy instances for computer installation targets are created immediately after creating the policy.
Policy instances for user installation targets are created when the respective user logs on to a computer as policy instances for this specific computer.
Policy instances for computers in groups and OUs are updated automatically when the respective computers are modified.

Policy instances for Shop policies

The system creates policy instances for Shop policies as soon as a user installs the associated software in the Software Shop.

Policy instances for Job policies

Job policy instances act like standard policies. The only difference is that they are executed repeatedly.

No policy instances for Deny policies

Deny policies do not have policy instances. They are valid independent of a software package's revision.

Updating Policy Instances

When you update a policy, you can specify whether the policy instances that have been executed already are updated as well.

There are two scenarios:

• Critical update: All instances are updated; you have the option of deactivating the policy instances
• Uncritical update: The existing instances are not updated

In turn, changing the values of a policy instance does not affect the policy itself.

Deleting Policy Instances

Deleting policy instances automatically

If a policy no longer applies to a computer, the system automatically deletes the policy instances that were created earlier, if the following requirements are fully met:

• the instance is planned to be uninstalled
• the associated package has been uninstalled successfully or has not been installed at all yet
• the date of the last execution (if this date is not stored: the server rollout date) is 24 hours older than the current date (based on UTC). If none of the dates are available, this criteria is considered fulfilled.

The following applies to Software Set instances:

• the instances of all components meet the requirements above
• if the instance of an individual component meets the above requirements, the system deletes it if it belongs to another revision of the Software Set than the actual Software Set instance does. This does not apply to uninstalled optional components because they belong to the Software Set instance.

Deleting policy instances manually

Policy instances can be deleted manually if they meet the following requirements:

If the package property Uninstallation supported is set, the software package can be uninstalled and its associated policy instance can be deleted in the following cases:

• The software package has been uninstalled (status compliant)
• The software package's uninstallation failed (status not compliant)

If a software package cannot be uninstalled, the associated policy instance can be deleted any way if its server rollout status is invalid.

Characteristics of Software  Sets

Creating and updating policy instances

Policies and policy instances are always created separately for each component of the Software Set. Generally, the same rules apply that apply to "normal" packages.

Deleting policy instances manually

The general requirements for deleting policy instances also apply to the policy instances that are components of a Software Set. However, note the following additional conditions:

• The policy for the parent Software Set is set to Delete: The policy instance of the Software Set must be deleted. The component's policy instance cannot be deleted.
• The software package is an optional component of the Software Set: the component's policy instance can be deleted if it meets the general requirements mentioned above.
• The software package is no longer contained in the current revision of the Software Set: he component's policy instance can be deleted if it meets the general requirements mentioned above.