PowerShell Extensions for Ivanti DSM

Using Policies

Among managing objects of the Organization Directory using Policies and Policy-Instances, resp. the accounting and analysis of their states is one of the main fields of the PowerShell Extensions for Ivanti DSM.

Creating Policies

The cmdlet New-EmdbPolicy is used to create new Policies. It does not make any difference whether you want to perform a Pilot Installation (the involved software package is not released) or if you want to create a standard policy. The distinction is only made in the DSM Management Console. From the perspective of the SOAP interface both are equal.

A Policy is an association between a Software Package and one or more target objects (e.g. one or more groups or computers). Therefore Policies might be interpreted as a property of a Software Package (a Software Package is assigned to a target) or as a property of objects in the Organization Directory (objects are assigned to a Software Package).

In the following example a Policy assigning the Software Package "Adobe Reader 9.0"  to the Static Computer Group"Laptops Rom" is created:

You might have noticed that the values of the parameters "MyTargetpath" and "MyPackagename" are of string type. This is for convenience only. Of course, you can use the appropriate objects, too:  

Retrieving Policies

You can use the cmdlet Get-EmdbPolicy to determine the Policies of an object. The cmdlet is parametrised with the object for which the policies should be determined and optionally the type of policies you are interested in. In the example all Software Policies of the group "Laptops Rom" are retrieved:

The execution result of the above command is an array of Policy objects containing all Policies assigned to the given target. Unfortunately only the ID, not the name, of the associated Software Package is a direct property of the Policy object itself. To gain a more readable output you might request the values of the additional properties AssignedObjectName and TargetObjectName. The next example prints all Policies of the given object. Therefore it is handy to print the types of the retrieved policies, too. The type corresponds to the property Schematag of a Policy-object.

Notice that the cmdlet only retrieves Policies, not Policy-Instances. E.g. if you call the cmdlet with a single computer object as a parameter, you will only get Policies that are assigned directly to the computer. Assignments that are inherited from group memberships or from structure objects of a higher level are not considered in that case. Policy-Instances are discussed later in this section.

Deleting Policies

In order to delete a Policy, rhe method Delete() of a Policy-object or, alternatively, the cmdlet Remove-EmdbPolicy is used. So if you want to delete Policies you first have to retrieve the corresponding Policy-objects. If you want to delete a certain Policy it is likely that you want to use the name of the associated Software Package to find the Policy. The next example illustrates such a use case:

With this command, the Policy is deleted in a way, that the corresponding Software-Package will be uninstalled - just like it is done when deleting in the DSMC. You can force the deletion of the Policy if you use the method with a parameter::

The following example shows the deletion of the same Policy-object via the Delete()-method:

Analogical, when you want to force the deletion, you use the method with a parameter:

Using Policy-Instances

More often you might be interested in Policy-Instances than in the Policies itself, that act as blueprints for the Policy-Instances. Only Policy-Instances have a compliance state and only Policy-Instances contain the information if a software rollout is due, if it is running or if it is completed with success.

The following example retrieves all Policy-Instances associated with the computer named "XP99":

As we have seen while retrieving Policies, only basic information like the IDs of the Policy-Instances and their compliance status and the IDs of the 

assigned Software Package and the target object are printed. Again, you can request more useful information. But keep in mind that you might trading convenience with an increasing execution time: 

In the above example we have omitted the property TargetObjectName, because we listed only Policy-Instances of the computer "XP99".

The creation and deletion of Policy-Instances is hardcoded in the business logic of the DSM 2022.2 environment. There is no possibility for the PowerShell Extensions for Ivanti DSM as well as for the DSMC to create or delete Policy-Instances directly. Consequently there are no cmdlets or methods to perform such tasks.

Reinstalling Software Packages - re-executing Policy-Instances

A common scenario is the reinstallation of a Software Package on a certain computer. In the context of the DSMC this functionality is associated with the task "Reinstall" on an existing Policy-Instance. To gain the same result via the PowerShell Extensions for Ivanti DSM, you either have to call the Policy-Instance's  Reinstall()-method or you increment the ReinstallRequestNumber-property of the Policy-Instance and write the changes back to the database. The next example illustrates this with the Policy-Instance of the package "Adobe Reader 9.0":

Other tasks like activating or deactivating Policy-Instances or the repair of an installation are possible, too. Also you can manage Installation-Parameters of Software Packages. Refer to the section Advanced topics for more information.