Environment Manager Configuration API (Post 1 of 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.
As any good software vendor knows, customers will always request feature improvements. Unfortunately it does take time to implement some of these new features. At AppSense by far the most requested feature for example is bulk operations for Environment Manager Personalization Server. As of version 8.6 bulk ops is not as yet implemented. Don’t fear though, we’re not too far off!
For the time being, the following API’s are available for your use to automate batch jobs and stretch the abilities of the products in order to further aid some of our more ‘creative’ customers:
- Environment Manager Configuration API
- Environment Manager Personalization Server API
- Management Server API
I’ll be touching on each of these APIs (some in more depth than others) in a series of blogs, starting off with the Configuration API. Each of the API definitions are fairly long, so I will be splitting the functionality up into multiple parts.
In their current form, the API’s may seem very intimidating, however they have been designed so that developers and administrators with programming knowledge can make the most out of them. Typically an abstracted layer is needed for a smoother experience, however with a bit forethought they can be easily utilized. Documentation included with the product gives you a starting point, but I hope these blogs will show how easy it is to get started using them and hopefully give you the incentive to start exploring the API capabilities.
To start us off, let’s begin with the Environment Manager Configuration API’s. They are easy to understand, but with the limitation of only being able to create a configuration in its current form. The easiest way to demonstrate this is with PowerShell, but theoretically the module can be used with any programming language.
Let’s begin by creating a simple configuration and setting up our advanced settings and personalization servers, along with a few condition and action examples.
- To start with we need to load the API module.
This loads the API functions from the EMConfigAPI.dll and creates a new object stored in the $config variable.
From here, all the API functions are available from within this variable. Using Intellisense with a compatible IDE will show you each available functional structure.
So, let’s start by adding some Advanced Settings:
- Let’s Enabled (or Disable) the Sub-Logon triggers using:
- Configure Mid-Session configuration change behaviour using:
- Custom Settings (Engineering Keys), add them using this function:
Repeat as necessary to add further settings.
- Now let’s add 2 Personalization Servers, demonstrating both HTTP and HTTPS servers.
- This firstly requires the ‘General Controls’ to be configured. These are as follows:-
**Note that this function requires an array. The easiest way to do this is by pre-defining an array of integers:
- Nodes and child nodes.
Before exploring the guts of ‘Actions and Conditions’ there is a need to understand the Parent, Child relationships. 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.
To put this into context I have drawn up a script which contains all of the above and included a save dialog function and a quick example of how to call a ‘Create Shortcut’ action.
The script could be optimized a great deal more, this is a literal/raw example of API usage. I will explore Actions and Conditions more in my next blog and also how further optimizations can be achieved.
I hope that this has given you some food for thought and please feel free to comment if there is any need for clarification.