Using PowerShell and Ivanti UWM API for Machine Polling

I was working on a project where we built a complex Environment Manager config. It made sense to have this config start doing its magic on the workstation during the SCCM build Task sequence, but we didn’t want to have to maintain a config package in SCCM.

I decided to search around to find out how to force a poll at the time of install for the Ivanti Client Communication Agent during the SCCM task sequence. Forcing a poll ensures that the EM Config is downloaded to the endpoint after establishing communication with the management server.

Unfortunately, this was not as straight forward as it looked, and doing it manually through the management center console was not an option.

Ivanti provides a document titled “AppSense Management Center v10.0 Web Services API Guide” which is the latest version I could find in their Knowledge Base. This document lays out what services and functions are available through a set of APIs designed for this type of solution.

An additional resource I used was a blog article on Ivanti’s web site:  

This article showed me how to perform a Machine move and provided a template for how to load the API objects using libraries that are installed with the console.

The following PowerShell snippet is an example of calling the WebServices API:

While the blog article explains how to find machines using the WebServices API, it doesn’t provide much information on how to execute a poll.

I discovered that a method for executing a poll involves a process by creating “instructions” and executing them:

Notice the parameter “Initiating Script Client Poll”. This will show up in the console when the action executes.
You also need to make sure that there are no existing instructions. The console automatically takes existing instructions into account, so you’ll need to make sure to delete any existing instructions before adding a new one.

And then it’s a matter of performing an “activate” function which will run the loaded instruction as shown below:

If you want a simple PowerShell script to poll a machine in your Ivanti Management Center, use my script below!

Make sure to run the script on a computer with the Management Center Console installed. Info-wise, you just need the name of your Management Server, the Port that’s configured to receive Web Service requests, and the name of the Machine that you want to poll.

An easy way to get this info is to see how you’re connecting to your management server with the MC Console.

Your script call should look something like this:

When the script is run, you’ll see this message in the console for the machine:

There are a lot of these great little functions hidden away in the Ivanti Management Server Web Services, so check in again soon to see the other scripts we’ve come up with.


	This script will run a poll on a workstation in the Ivanti Management Center
    This script will run a poll on a workstation in the Ivanti Management Center
.PARAMETER ManagementServerName
    The name of the Ivanti Management Center Server
	Default is 80. Can also be set to 443
	Machine Name
    .\Poll-MCMachine.ps1 -ManagementServerName "" -Port 80 -Name "Win10-2"


Param (

If($Port = 80) {
    $Protocol = "http"
}Else {
    $Protocol = "https"

$ManagementServerUrl = "$($Protocol)://$($ManagementServerName):$($Port)/ManagementServer"

If(Test-Path "${Env:ProgramFiles}\AppSense\Management Center\Console\ManagementConsole.WebServices.dll"){
    Add-Type -Path "${Env:ProgramFiles}\AppSense\Management Center\Console\ManagementConsole.WebServices.dll"

$ConnectionCredentials = $([System.Net.CredentialCache]::DefaultCredentials).GetCredential($ManagementServerUrl, "Basic")

[ManagementConsole.WebServices]::Connect($ManagementServerUrl, $ConnectionCredentials)

$MachinesWebService = [ManagementConsole.WebServices]::Machines
$DeploymentWebService = [ManagementConsole.WebServices]::Deployment

$TargetMachineObject = $MachinesWebService.FindMachines('%').Machines | Where-Object {$_.NetBiosName -eq $Name}
$TargetMachineKey =  $($TargetMachineObject | Select-Object MachineKey).MachineKey

$DeploymentWebService.GetDeploymentInstructionsFromDiscoveredMachineKey($TargetMachineKey).Instructions|Foreach-Object {$DeploymentWebService.DeleteInstructions($_.InstructionKey,$Null)}

$PollActionGuid = [guid]::newguid()

$DeploymentWebService.CreateInstructions($PollActionGuid,129,$Null,"DeployNowPlugin.dll",$TargetMachineKey,"Initiating Script Client Poll")|Out-Null


Aman Motazedian
Senior Consultant
Critical Design Associates

LinkedIn Profile

Securing an Existing ADFS Environment with Okta MFA

Since the introduction of Active Directory Federation Services (ADFS) in 2015, companies have been widely adopting the idea of using this technology to leverage claims-based authentication…

How Ivanti Development Broke My Start Menu

There was a post on the Ivanti forums that I started reviewing in October ( This post was about the Edge icon on the taskbar reappearing each time.

From my past experience, this was an easy fix, you needed to add the “StartMenuInit” value as a managed item in personalization. The “StartMenuInit” value acts much like “Active Setup” and runs at first logon to customize the users profile by adding the browser (based on your OS) to the start menu as well as the taskbar.

It also adds Windows Media Player or Server Manager shortcuts depending on your OS. For the customer in this forum post the fix was easy, capture “StartMenuInit” to prevent this from happening at every logon. The customer responded that this recommendation broke the start menu.

I’ve never used the XML method mentioned in the thread above to capture the start menu. Historically, personalization worked fine, using my baseline templates and the built-in functionality… so managing the start menu via PowerShell didn’t make sense to me. “XML Method Reference”: James Rankin first talked about this method on his blog over 3 years ago.

I decided to give the “XML method” a try and found out that it is also controlled by “StartMenuInit” value and is designed to run once per user. This being the case, you can capture “StartMenuInit” and prevent IE or Edge from re-pinning over and over or you can personalize your start menu via the XML method but not both.

Critical Design is hiring ITSM Consultants with Ivanti Experience. Learn more at our career opportunities page.

During this testing, I tried reverting back to my “old tried and true” templates that have always worked. Basically, my template is an out of the box configuration with “StartMenuInit” and the “UserSignedIn” values added. What I found was that on the second logon the start menu was completely broken. I was able to reproduce these results on every recent build of Windows 10 (1607, 1703, 1709). I was “stumped”… why is this issue is occurring all of the sudden?

Come to find out this is a new undocumented “feature” in FR3. This new functionality handles the start menu using the XML method that isn’t documented in any release note that I could find.

This little-hidden gem was found in the out of box templates on my personalization server. See the image below:

When the layoutmodification.xml file is included it breaks the functionality in my template. Since I cannot update the out of box settings I had to create a new custom setting and replace it.

Now I had my start menu working again on Win10 1607 and properly managing the taskbar personalization by capturing “StartMenuInit”.

I was fired up until I started testing this fix on other Win10 builds. On Windows 10 1709 the implementation with FR3 was rather simple. In 1709 Microsoft stopped using the “TileDataLayer” and completely replaced it with the “CloudStore” registry key.

After some success with Windows 10 1709 and the updated Windows Setting Group I moved on to testing Windows 10 1703. This turned out to be a “mess”. I began to suspect that Ivanti development must be doing something in the code with 1703 and the TileDataLayer that does not make sense to me.

Much like the new XML method, that I mentioned earlier, it isn’t documented in the release notes.
When testing Windows 10 1703, At logoff, the copy of the TileDataLayer folder fails. Not only does it fail with some completely weird reason but the path is completely wrong and is referencing my temp folder, as shown in the highlighted output below:


After witnessing these results the issue is becoming apparent. In my opinion it appears that FR3 has had some major overhauls, which are causing a lot of issues. I decided to test FR2 on the exact same machine. FR2 was able to copy the entire folder without any issues. This led me to the conclusion that the issue cannot be the endpoint OS but the version of Environment Manager that is not allowing the “TileDataLayer” folder to be copied out on 1703.

So rollback to FR2? Not exactly…. See there is a known issue in FR2 with the “CloudStore” key. This article written in Ivanti’s own words proves that all that was needed was the “CloudStore” key.

The issue in the article DOC-48236 has been resolved in FR3. While FR3 fixes one (or many) issue(s) it appears to also unintentionally broke some features that worked before. I cannot rollout FR3 due to the “TileDataLayer issue” in Win10 1703 and the workaround in the article is inconsistent due to it using the desktop created trigger.

It seems to me that if the issue with the CloudStore key was resolved in FR3, which it has, and development didn’t add changes with the “XML Method” and “TileDataLayer” functionality we would be in good shape. The start menu and taskbar functionality would be working if the “out of the box” templates were modified to use the proper includes (referenced above).

At the present time I am being told that this issue would need to be addressed as a feature request. Since we know the issue exists and have at least one possible solution to fix the issue, I need some support from the community to get this feature request prioritized.

If you would like to help get this issue resolved please vote on this request here:

Stay tuned for updates!

Landon Winburn
Principal Architect
Critical Design Associates