Environment Manager Configuration Part 2

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

So in my last blog I introduced you to the Configuration API, I explained how to create the basic structure of a configuration with associated options and settings.  In this blog I will cover creating actions and conditions on various triggers.  Covering the whole conditions & actions set in this blog will be just too long and drawn out, so to keep things interesting I’ve compacted it down to just cover the most common we see in configuration files.  Hopefully this will keep you interested and more importantly will allow you to learn as you go.

So to kick things off lets pick up where we left off last time.

Let’s recall our basic structure.

In a standard configuration the Parent-Child relationship needs to be maintained and is maintained with the use of GUID’s throughout the configuration.  Therefore each condition or action is created using its Parents GUID.

Conditions

Getting to the nitty gritty of it all, let’s create a UserIsAdmin condition under the child node of the ‘User Pre-Desktop’ trigger

[code lang="powershell"]
#  Add a node to the User Pre-Desktop trigger named 'Node Pre-Desktop'
$userpredesktopnodeid = $config.AddNodeToTrigger("UserPreDesktop", "Node Pre-Desktop")

#  Add a child node to the node created above using its NodeID variable.
$predesktopchildnode1 = $config.AddNodeToParent($userpredesktopnodeid, "Child Node")

#  Create as IsAdministrator Condition
$config.AddActionOrCondition($predesktopchildnode1, $isAdminCondition_true)
[/code]

To explain this code above lets break it down line by line.  First things first we need to create the ‘UserIsAdministrator’ API constructor in which we declare what parameters are passed.  In this case it simply is as follows:-

UserIsAdministrator(bool isAdministrator, bool evaluateOnce, bool stopIfFails)

**Remember PowerShell is ran line by line as opposed to compiled, so constructors have to be declared in code before they can be called.  This seems obvious, however it is quite easy to miss structure your code and fall into this trap.

Translating to the following line of code:-

[code lang="powershell"]
#  Create the Condition Object
$isAdminCondition_true = New-Object EMConfigAPI.Conditions.UserIsAdministrator($true, $true, $false)
[/code]

Next we have to add the Condition to the node we want:-

[code lang="powershell"]
#  Add a child node to the node created above using its NodeID variable.
$predesktopchildnode1 = $config.AddNodeToParent($userpredesktopnodeid, "Child Node")

#  Create as IsAdministrator Condition
$config.AddActionOrCondition($predesktopchildnode1, $isAdminCondition_true)
[/code]

So to look at this programmatically, we call the AddActionOrCondition API with the first parameter being the parent node of the node you wish to add the object to and the second is the actual variable of the condition or action.

Actions

The same logic is used for actions.  Firstly using the API constructor we create the object variable

DriveMap(string driveLetter, string remotePath, bool unMapAtLogoff, ConnectAs connectAs, string userFriendlyName, bool stopIfFails)

or

DriveMap(string driveLetter, string remotePath, bool unMapAtLogoff)

Notice this API uses a ‘Connect As’ Enumerator.  In instances like these only a pre-defined input can be used.  In this case it is CurrentUser, System, AsUser or Default

[code lang="powershell"]
$driveMap_E = New-Object EMConfigAPI.Actions.DriveMap("E", "\\server\share", $true)
[/code]

Finally we add the action to the appropriate parent object.  In this example I have added it to the ‘UserIsAdministrator’ condition created earlier.

[code lang="powershell"]
$childnode1_drivemap = $config.AddActionOrCondition($childnode1_isAdmin_true, $driveMap_E)
[/code]

Reuseable Nodes & Conditions

Reuseable’s work in much the same way, however utilize a slightly different API.

[code lang="powershell"]
$reusable_osIs81Condition = $config.InsertReusableConditionNode("OS is Windows 8.1")

$w81Condition = $config.AddActionOrCondition($reusable_osIs81Condition, $osIsW81)

$reusable_OS81Node = $config.InsertReusableNode("OS Check 8.1")

$osCondition = $config.AddReusableCondition($reusable_OS81Node, $reusable_osIs81Condition)
[/code]

This time the extra step is to Insert the reusable object in the library, using the InsertReusableConditionNode & InsertReusableNode API’s.  Then we create the action object and then link it to the appropriate object in the configuration.

I hope everyone has followed up until this point, however I appreciate just reading isolated lines of code can be difficult to relate to real world examples.  That is why I have bundled together a script which contains a lot more working examples for actions and conditions.

Once again this is not a fully optimized script, just an example of how objects are linked together and to show what is required to generate a configuration.

Again I hope that this has given you some food for thought and please feel free to comment if there is any need for clarification.