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

How to Create an MSI with SCCM Standalone Remote Control Viewer Components

SCCM Remote Control Viewer Standalone

In most large organizations, first tier support, like the Help Desk, will require remote control access to user’s workstations. While Microsoft has provided an excellent tool for full remote viewing and control, the administrative components are only provided by Microsoft as a part of the SCCM administrative console.

Providing Help Desk users with access to the SCCM administrative console is likely overkill and unnecessary given the only component that they may require is remote control.

Since Microsoft does not provide an easily deployable remote control client, this article demonstrates how an administrator can bundle the Configuration Manager remote control components together into a Windows Installer (MSI) application package.

In order to be able to run the Configuration Manager Remote Control, there are three files that must be installed on the workstation:

  • CmRcViewer.exe
  • RdpCoreSccm.dll
  • 00000409\CmRcViewerRes.dll

In addition, if the Remote Control Viewer is going to report back to the SCCM Site Server with which client is remote controlled and by whom, the registry key

Server=”<Site Server Name>”

Server=”<Site Server Name>” must also be included.

While this sounds simple enough, the better approach will be to create an application package that contains these components and deploy it to each workstation that needs it.

What are the challenges of doing this manually?

The biggest issue to just copying the files manually to workstations are maintenance and compatibility.

First, these files will change multiple times a year, always with each major SCCM release and possibly with any SCCM hotfix release.

Second, if the components are copied manually, they may not be compatible if one day, the full SCCM administrative console is deployed to that system in the future.

Building the SCCM Remote Control Viewer Standalone Package

What I’ve provided here is the complete solution to this problem. I wrote a PowerShell script that can be run to automatically create a new MSI with the standalone Remote Control Viewer components.

The PowerShell script requires one command line option pointing to the SCCM Primary Server and uses the exact same components that are used by the native installer. Since the same components are used, installing the SCCM administrative console in the future on the same workstation will not cause any issues.

A new version can be built at any time there is a requisite SCCM upgrade, and each new version will automatically upgrade the previous Remote Control Viewer version. If your organization uses digital signing, there is an additional command line option to digitally sign the code with your organization’s code signing certificate.

To get started, download the file: SCCM_RCV

Extract the contents to your working directory. All required support files are included in the zip file.

What is in the script? How does it work?

The PowerShell script and the supporting binaries were co-developed with Microsoft Premier Field Support. There are some basic functions for updating the MSI PackageCode and multiple MSI Properties. The first script parameter is to define the Site Server. And the second script parameter will define your digital certificate.

The update-PackageCode function will update the PackageCode which is unique to every build.

The update-MSIProperty function will update several MSI Property table entries, when called.

This part of the script will create the build folder and copy the necessary files to that folder. This includes all the required files for the Remote Control Viewer.

This part of the script will build the new RemoteControl.msi. There is a “rebuild check” in the code that ensures the existing version is not accidentally rebuilt.

The script uses msidb to execute table import functions. It also uses two vbScripts, one to update all the file properties and the MsiFileHash Table, and the other to compile the cab file and import the cab as an embedded stream.

This part of the script will copy the completed MSI to the build folder and begin file and folder cleanup.

This last part of the script is optional. It will digitally sign the MSI

Running the script
To run the script, execute it from an elevated PowerShell command prompt.

NOTE: Like any other script, this one can be signed with your own digital signature if necessary

Create an MSI containing the ConfigMgr Remote Control Viewer

.\msi.ps1 -siteserver “”

Create an MSI containing the ConfigMgr Remote Control Viewer that is digitally signed

.\msi.ps1 -siteserver “” -codesigningcert “C:\certs\mycert.p12”

This completes the process. We hope this information makes it useful for you to contruct a Windows Installer (MSI) Application Package that includes Configuration Manager remote control components.

Is your organization looking to upgrade ITSM efforts? Contact us for a 30-minute consultation to anwser your questions.

Mike Doneson
Senior Consultant
Critical Design Associates


Deploying Office 365 using SCCM

The deployment of Office 365 applications (Word, Excel, PowerPoint, Outlook, etc..) just became much easier. Beginning with SCCM version 1702, from the Office 365 Client Management dashboard, the Office 365 application Installer can be automated.

From this console the following can be performed:
• Office 365 installation settings can be configured
• Files from Office Content Delivery Networks (CDNs) can be downloaded
• Office 365 can be deployed as an application

What is the Office 365 Client Installer?

The Office 365 client installer is the SCCM installation wizard for the Office 365 client applications installer. This wizard will automate the deployment of the Office 365 applications to client devices like Windows 10, Windows 8.1 and Windows 7.

The Office 365 Client Installation Wizard

The Office 365 client installation wizard is started from with the SCCM console. Navigate to

\Software Library\Overview\Office 365 Client Management

and click on the title. The Office 365 dashboard will launch. Click on the “+ Office 365 Installer” to launch the Office 365 installation Wizard.

Application Settings: This is the initial window. The wizard will prompt for the Name of the deployment, a Description, and the Content Location.

The Office 365 client installation files will be downloaded to the location specified in the wizard if they do not already exist.

NOTE: In order to proceed, either SCCM must be connected to the Internet or the Office 365 installation must have already been downloaded offline and placed in the selected directory.

Import Client Settings: This window offers a choice to Manually specify the Office 365 client settings or Import Office 365 client settings from a configuration file.
Choosing the Import option will automatically configure all the settings for the Office applications.

A Sample configuration.xml file can be found here: Download

If you choose to manually specify the Office 365 client settings, continue to the Client Products window.

Client Products: In this window, the initial option is to select the Office Suite.

Primarily, there are two office suites available as part of the installation wizard.
• Office 365 ProPlus
• Office 365 Business

NOTE: Microsoft may offer pre-release versions such as Office Professional Plus 2019 in the dropdown. This may also become the standard method of deploying Office in future versions.

Below the Suite dropdown list, a frame is shown where you can select the Office 365 applications installed for this deployment.In the example above, “OneDrive (Groove)” is not selected to be installed since it is obsolete. All other standard applications are selected.

Additional Office Products: There are additional dropdowns for Visio and Project.

For this deployment, Visio Pro for Office 365 and None have been selected. The default options are:
Visio Pro for Office 365
Project Online Desktop Client

NOTE: For those two products, they are licensed based on the associated Office 365 licensing.

Specify Settings for Office 365 Clients

Client Settings: In this window, there are options to specify settings for the Office 365 Clients.

At the top, there is a radio button to select the Architecture which can be either 32-bit or 64-bit.

In the Channel selection dropdown, there are four update channels listed. Recently, these choices have changed.

Currently the choices are:
Monthly Channel (formerly Current Channel)
Monthly Channel (Targeted)
Semi-Annual Channel (Differed Channel)
Semi-Annual Targeted (formerly First Release for Deferred Channel)

Below this is the Version dropdown. This will populate with numerous choices for each channel. Currently, the latest build in the Semi-Annual channel is 1803 Build 9126.2282.

There is an “Add/Remove…” button that is used to select additional languages. The default is English (United States).

At the bottom are options to configure Properties.

The four properties are:
Accept EULA
Pin Icons to the taskbar (Win 7/8.x only)
Shared computer activation

NOTE: Microsoft still recommends the 32-Bit version of Office. More information on why can be found here.

Deploying the Office 365 Client

Deployment: The next window is for deployment. It has a single question, “Do you want to deploy the application now?

If you choose “Yes”, the standard SCCM Deployment scheduling options are built into the wizard. There are windows for General (select the collection), Content (Distribution Points), Deployment Settings (Install, Required, etc.), Scheduling, User Experience, and Alerts.

If you choose “No”, the next window presented will be the Summary.

Clicking next will bring up Progress and ultimately Completion. At this point a new Office 365 application is available and ready to be deployed, or will be deployed on the schedule created in Scheduling.

Office 365 Client Management

After the wizard completes, SCCM will return back to the Office 365 Client Management window. From here, there is a graphical display showing all of the installed versions across the environment.

There are now new options on the right side of the window which include: Create an ADR and Create Client Settings.

This area of SCCM functionality continues to be upgraded and improved with each new release.

In Conclusion

This walkthrough is only the beginning of Office 365 management utilizing SCCM.

Mike Doneson
Senior Consultant
Critical Design Associates

SCCM Video: Creating a Device Collection from a list of Users

Most of the time, requests for deployments come in as vague lists of names or departments. And, although SCCM provides some great user-based deployment options, you may not feel fully comfortable targeting users for a required deployment. This means you’ll have to run a report, do some copying and pasting, and maybe manually enter some machines into a device collection.

Well, we’ve put together a little script which will help speed up that process. Download Script

The script relies on SCCM’s user device affinity information that is automatically collected if enabled in client settings. With this info, we can get device associations for users and then use those associations to create device collections for targeting deployments.

Step 1 – Pull in your list of users

We have three different options for inputting our list of users.
1) Text List
2) AD User Group
3) SCCM User Collection

The Text List should e a list of SamAccount Names as we’re going to query SCCM directly with this list

You can use any combination of the three, and the script will take it into account.

Step 2 – Create a targeting collection, or not

First, we check if the collection exists already. If it does not, we check to see if the -LimitingCollection parameter is used. If it is, we’ll create a new Collection, if not, we’ll exit out.
The limiting collection is a required collection to create any new Collection in SCCM.

This collection limits the scope of What your new collection can contain. The largest limiting collection is “All Systems”

Step 3 – Find all the devices associated with each user

We’re going to loop through our list of users, and with each one, run a WMI query to find all associated Devices. Then each of those devices will be added to an array and to the Targeting collection selected above.

Step 4 – Create a simple CSV report (optional)

If you used the -CSVPath parameter, the script will generate a report a CSV file in the location you designated.

Each row will show what devices were associated with each User and whether or not the devices was successfully added.

There are many reasons a device would not be added, we recommend generating the report and double checking to make sure everything looks right before targeting the collection with a deployment.

In Conclusion

Hopefully this helps make your deployments a little easier. Feel free to leave comments, requests, or inform us of issues on our GitHub page.


In this video we demonstrate a script that allows an SCCM administrator to create a “Device Collection” using a list of users from a text file as input. The script also supports active directory groups or a user collection.

Download Script

This PowerShell script uses the “User Device Affinity” feature in SCCM to determine which device belongs to which user.

Aman Motazedian
Senior Consultant
Critical Design Associates

LinkedIn Profile