Privileged Account Discovery Script: Reduce Privilege Escalation Attacks


Privileged accounts are accounts on computer systems with more access than standard user accounts. These accounts, for example, can execute processes in the system context, run system-wide services, or modify system configuration files.

Privileged accounts are often targets for privilege escalation attacks, where attackers are able to gain access to network-wide resources after making a beachhead on a system using a standard user account.

The Story of the Discovery Script

There are several great tools out there for discovering and managing privileged accounts. I was determined to find a free tool that would provide the level of detail I was looking for.

After conducting research, I could not find what I was looking for so I decided to write a custom script.

Download Script: Privileged Account Scanner V1

This script focuses on six main types of Windows privileged accounts:

  1. Windows Local Administrator Accounts
  2. Windows Service Accounts
  3. Windows Scheduled Task Accounts
  4. Windows COM+ Application Service Accounts
  5. Windows DCOM Application Service Accounts
  6. Microsoft SQL Accounts

The Script requires Windows PowerShell Remoting to be enabled.

Furthermore, the account you execute the script with must have Local Administrator privileges on the target system, and GRANT CONTROL SERVER on SQL servers.

“I could not find what I was looking for so I decided to write a custom script”

Provide an array of computer names to the parameter ListOfTargets and the script will gather privileged account information on each of the target computers.

The result will be a CSV file generated in the TEMP folder. That path can be modified with the ReportExportPath parameter, as seen in the below command.

.\PrivilegedAccountScanner.ps1 -ListOfTargets “DB01”,”ERPM01” -ReportExportPath “C:\users\SuperAman\desktop\”

Running this command produces a report that looks like this:

In this example report you see examples of most of the types of accounts the script scans for. Below are the columns found in the report and a brief description of each:

  • ComputerName – The computer targeted for scanning.
  • Account – The name of the discovered privileged account.
  • Type – Shows which of the six types of account this account falls under.

The data in the name and note columns will change depending on the type of account.

Additionally, below is an outline of how different account types affect other columns:

  • Local Admins
    Shows “N/A” for name, and the type of account discovered. Above you see that the account is actually a group.
  • Service Accounts
    The Name column shows the service name and the note column shows the service description.
  • Scheduled Tasks
    The name column is the name of the Scheduled task and the note column will display “N/A”.
  • COM+ and DCOM
    Application accounts, the Name column shows the application name and the note column is the application key.
  • SQL Accounts
    The name column shows the associated SQL Instance and the Note column shows a summation of what roles and explicit permissions are assigned to the account./

Customizing Data

You can do further customization of the data your collecting by modifying array variables defined near the top of the script, as shown below.

Broaden or Focus Discovery Scan

The following are arrays that can be modified depending on your reporting needs.

  • The $FilterArray is a list of accounts that are ignored during the discovery scan
  • The $FilterSQLBuiltinAccounts is the list of built in SQL Account to ignore
  • The $SQLPermissions is a list of SQL permissions to look for when scanning SQL
  • The $SQLRoles is a list of SQL roles to look for when scanning. Any SQL users that are members of these roles will be captured

“By adding or removing elements of these arrays, you can broaden or focus your discovery scan.”

Let’s Continue the Conversation

I set out to develop a flexible scanning script that can provide actionable data on privileged accounts in your environment. However, I am sure there are scenarios, configurations, and use cases that I missed.

I look forward to feedback and any requests for additional functionality. Do you have a suggestion? Please leave it in the comments below and we will continue the conversation.


Aman Motazedian
Senior Consultant
Critical Design Associates

LinkedIn Profile

Optimizing Windows 10 Upgrades with Ivanti Endpoint Manager (EPM)


In a recent customer engagement, the client had requested to upgrade Windows 10 workstations within their environment using Ivanti Endpoint Manager (EPM.)

Ivanti has a recommended method to upgrade Windows 10 workstations to newer versions through their service pack definitions.

The service pack definitions are found in the Patch and Compliance tool and can be used to determine if an endpoint can receive the upgraded version of Windows. The service pack definition defines an ISO for the deployment, which cannot be downloaded via the Patch and Compliance tool.

The ISO must be downloaded separately and renamed to match what is configured in the definition. There are both pros and cons to using the recommended method:

ISO Method


  • Easy to deploy
  • Simple configuration


  • Space requirements (2x ISO size)
  • Large performance impact
  • Poor end-user awareness

When deploying any patch or distribution package, it is important to do so consistently each time to achieve expected results.

For this reason, I developed a Software Distribution method that would offer versatility and consistency with any Windows 10 upgrade. There are pros and cons to this method as well:

Software Distribution Method


  • Fewer space requirements (1x ISO size)
  • Full end-user awareness
  • No performance impact


  • More involved configuration
  • Leaves machine unusable for the duration of the deployment

Deploying Windows 10 Upgrades via Patch and Compliance

Ivanti’s recommended method for upgrading Windows 10 is fairly straightforward for the setup and deployment.

After the ISO is named according to what is configured in the definition file, all that is left to do is deploy it to targeted endpoints.

The Patch and Compliance deployment, after scheduling the repair and starting the task, is as follows:

  1. Copy the ISO to the machine (download ISO here)
  2. Mount the ISO and extract the contents
  3. Unmount the ISO and start the upgrade process with the now local files

As previously mentioned, Ivanti’s recommended method for deployment has some cons.

First, it is required to have twice the disk space on the endpoint for storing the ISO and the extracted contents; that can easily amount to 8GB or more.

Once the installation starts, a large performance impact will be seen as the upgrade will start using most of the machine’s resources.

Lastly, there is poor end-user awareness as to what is actually happening. EPM does have the capability to provide prompts to the end user with the correct agent settings; however, when using those settings there is still no indication of the progress of the deployment.

Deploying Windows 10 Upgrades via Software Distribution

Ivanti’s Windows 10 upgrade method using Patch and Compliance works, but in this case, the customer needed something that was more user friendly and did not have any impact on performance.

This is how the Software Distribution method ensued. The Software Distribution method makes use of two custom batch files.

The first batch file used in the deployment, in this case, named GetUserName.bat, is used to simply get the username of the currently logged-in user if there is one; the username will be output into a temporary text file called Username.txt.

By default, when creating a distribution package, it will run under the SYSTEM account.

This particular package, however, will run under the current user account; this is important for the next batch file in the process. The contents of the GetUserName.bat file can be seen below.

REM -- If C:\Temp doesn't exist, create it and output the current user to Username.txt
REM -- Since the task is running under the current users context, a file will only get
REM -- created if there is a user logged in

if not exist C:\Temp (
mkdir C:\Temp
echo %username% > C:\Temp\Username.txt
) else (
echo %username% > C:\Temp\Username.txt

The second batch file, which will be named Windows10Upgrade.bat, will use the Username.txt output from the previous batch file if it exists.

If the Username.txt file exists, a scheduled task will be created to execute setup.exe that gets copied to the clients.

Setup.exe is the main executable in a Windows ISO that installs and configures the OS with the parameters you define.

The scheduled task will be created to run in the current user’s context with the highest privileges and will execute one minute from the time it is created.

Running the task with the highest privileges is a requirement, otherwise, the scheduled task will fail. The reason a scheduled task is created is to allow the user to see the GUI operation of the upgrade; if setup.exe was executed under the SYSTEM context, the currently logged in user would not see anything.

If there is no Username.txt file, setup.exe will just run under the SYSTEM context as that is the default for the distribution package. The contents of the Windows10Upgrade.bat file can be seen below.

REM -- Set the 'name' variable to whatever is in the text file, if it exists
REM -- This text file only gets created if there is a user currently logged in

set /p name=<C:\Temp\Username.txt

REM -- Get the time in 24 hour format, add one minute, and assign it to the 'hhmm' variable

set hh=%time:~0,2%
set mm=%time:~3,2%
set /A mm=%mm%+1
if %mm% GTR 59 set /A mm=%mm%-60 && set /A hh=%hh%+1
set P=00%mm%
if %mm% LSS 10 set mm=%P:~-2%
if %hh% == 24 set hh=00
if "%hh:~0,1%" == " " set hh=0%hh:~1,1%
set hhmm=%hh%:%mm%

REM -- If the Username.txt exists, that means a user is logged in, so create a scheduled task
REM -- Set the scheduled task to run with the highest privileges and under the currently logged in user
REM -- This will ensure an update prompt is seen by the user during the upgrade
REM -- Otherwise, just run setup.exe as SYSTEM since no user is logged in and Username.txt does not exist

if exist C:\Temp\Username.txt (
schtasks /create /s %computername% /tn "Windows Upgrade" /sc once /tr "%cd%\Setup.exe /Auto Upgrade /Telemetry Disable /ShowOOBE none /DynamicUpdate disable" /st %hhmm% /rl highest /ru %userdomain%\%name%
del C:\Temp\Username.txt
) else (
Setup.exe /Auto Upgrade /Telemetry Disable /ShowOOBE none /DynamicUpdate disable

While the batch files, along with the ISO itself, are the main components of this deployment method, below is a list of items and configurations needed for this deployment method:

  • Windows 10 ISO (Extracted to a folder)
  • GetUserName.bat (In the same folder as the Extracted ISO)
  • Windows10Upgrade.bat (In the same folder as the Extracted ISO)
  • IIS MIME type for Default Website
    • Type: application/octet
    • Extension: .

This method allows for a seamless, quick, and efficient deployment that will provide the end-users with a good experience if logged in during the deployment.

If they are logged in, they will have full insight into what is happening. The general process for the entire deployment is as follows:

  • The task starts and either begins the download on the client or starts executing the batch files if already downloaded
    • GetUserName.bat runs and outputs a Username.txt file to C:\Temp that contains the username of the currently logged-in user if there is one. A file does not get created if there is no user logged in.
    • Next, Windows10Upgrade.bat will run and determine if there is a Username.txt file
      • If there is a Username.txt file, a scheduled task will be created for the current user, obtained from the Username.txt file
      • If there is no Username.txt file, setup.exe will run under the SYSTEM context as is the default for the package
    • The machine will transition to a blue screen showing the progress of the installation after about 30-45 seconds and will make the computer unusable for approximately 45min-1.5h; time can also vary depending on hardware capabilities

As you can see, the process is fairly straight forward and if anything gets created, such as the Username.txt file and scheduled task, it will be cleaned up.

To make this process more user friendly, one can also pair this entire deployment with notification messages or deferment timers to provide more control to the end-user.

These are a few examples of the flexibility that EPM offers. Below is a short video of the deployment and demonstration of how it works and is setup.

Ivanti Endpoint Manager (EPM) Demo & Deployment Video

In Conclusion

Thank you for reading and please feel free to reach out if you have questions, comments, or concerns about the information presented in this article.

Zach Thurmond
IT Consultant
Critical Design Associates

LinkedIn Profile

Using PowerShell to Deploy Ivanti UWM Agents

The Ivanti Management Center PowerShell Module

The Ivanti Management Center provides a simple interface to deploy Ivanti UWM agents and configurations.

When installed, it exposes web services that are used by the Ivanti Management Center console to perform various functions.

I began developing functions to manipulate the Ivanti web services while on a project where I needed to automate the process of moving and polling machines.

After working with various functions, I assembled what I needed and created a module that works intuitively within PowerShell.

With this module administrators can automate certain management tasks that would ordinarily have to be performed through the UWM Management Center console.

A few examples of tasks that can be automated:

  • Moving machines between deployment groups
  • Installing the CCA
  • Polling machines
  • Removing the machines from the database

We will review the functions in the module and a simple script that allows users to pull machine information from the Management Center console.

There are two scripts that come with this module:

The IvantiManagementCenterModule.psm1 script is the module which contains all functions.

This is a basic template for accessing the module as shown below.

$PathToManagementCenterModule = "."

If(-not(Test-Path -Path "$PathToManagementCenterModule\IvantiManagementCenterModule.psm1")) {
    Write-Host "Unable to find the IvantiManagementCenterModule.psm1 module file, quitting."

Import-Module "$PathToManagementCenterModule\IvantiManagementCenterModule.psm1" -ErrorAction Stop

Connect-MCServer -ManagementServerName "uwm01.lab.local" -Port 80


Inside MCSCript.ps1 we define the variable:
$PathToManagementCenterModule = "."

The script can be modified to change the path containing the module. This is helpful if you paln on keeping it centrally on a workstation or server.

EX: $PathToManagementCenterModule = "C:\users\adminuser\documents\powershellstuff"

The MCScript will then load the module.

Let’s Get Started

First we call the Connect-MCServer function. This function is a prerequisite for all the functions in the module. Calling any other function without calling this one will cause the script to fail.

My lab management server is UWM01 and is configured to communicate with agents through port 80.

Connect-MCServer -ManagementServerName "uwm01.lab.local" -Port 80

After that we call the Get-MCMachine function.


This function returns an object or collection of objects that are the records for the machine in the Ivanti Management Center server.

You can then pipe this collection into the built-in PowerShell cmdlets Select-Object or Format-List to generate a simple report.

Additional Functions

Update-MCMachineList – Refreshes internal arrays that contain the machine list sent back by the Ivanti Management Server.

Get-MCDeploymentGroup – Returns a group or collection of groups in the Ivanti Management Center.

Move-MCMachine – Moves a machine or a collection of machines in the Ivanti Management Center.

Start-MCInstallCCA – Calls the Ivanti Client Communication Agent install function on a target machine.

Start-MCPollMachine – Starts a client poll on a target

Remove-MCMachine – Removes a client from the Ivanti Management Server. This function is designed to only delete one machine at a time. It does not work with wildcards.

A Few Aspects to Consider

Once the module is loaded, you can use Get-Help with the above functions to get more detailed information including examples.

You can also inspect the comments in the IvantiManagementCenterModule.psm1 file to get this information.

Additionally, most of these functions have been designed to work with PowerShell pipelines.

Real World Scenario

In my example I have two machines. Each machine is a member of a different deployment group. I also have a server and is a member of another deployment group.

Using the script, I acquire a list of machines that match these workstations and poll only the machines that start with “Win10”.

Get-MCMachine -Machine "Win10*" | Start-MCPollMachine

In the client access log, you’ll notice a custom message:

In Conclusion

I hope this script will help my fellow Ivanti admins with machine cleanups and periodic CCA pushes.

I also look forward to any new use cases, custom scripts, and suggestions for improvement.


Aman Motazedian
Senior Consultant
Critical Design Associates

LinkedIn Profile

Application Control for Enhanced Endpoint Security

[Video Transcription]
Hi, Trevor Prokop here with Critical Design Associates and today I’d like to demonstrate how you can leverage Ivanti Application Control to improve your endpoint security. Application Control is the security product within Ivanti User Workspace Manager Suite or UWM for short.

Application Control has many key features but today I’d like to focus on trusted ownership which is based on the core of Microsoft NTFS security permissions. Simply stated trusted ownership is a feature that prohibits software from launching if it was not placed on the workstation by a trusted owner by default if the NTFS file owner is not one of four trusted owners as seen in the screenshot to the right the application cannot run.

This list can also be populated with a service account for software delivery via Ivanti Endpoint Manager or Microsoft SCCM. Application Control uses secure filter drivers and Microsoft NTFS security policies to intercept all execution requests.

Execution requests go through the App Control, hook and any unwanted applications, and are blocked as you can see in the screenshot. Administrators install this application and therefore users will be permitted to execute it.

In addition to executable files, Application Control also manages entitlement to PowerShell batch, vbscript, registry files, a number of other items as well. So you can see here in this screenshot of the configuration validated PowerShell scripts here which will deny PowerShell.XE or PowerShell_ise.EXE or if a ps1 file is executed by a user. If the file is not owned by a trusted owner then it won’t be permitted to run.

Business cases around this I’d like to demonstrate are prohibiting users from installing and executing portable or third party applications. Prohibit malware execution from malicious attachments and also to prohibit file-less malware execution via PowerShell. These are a few business cases I’d like to demonstrate and also how to be protected using Ivanti Application Control.

So let’s get into the demo. What we have here I have two VMs. Both are Windows 10 64 bit, one has Application Control installed and one does not. Here is no Application Control just the normal environment that people would access.

So what I’d like to show is a user trying to download the uTorrent portable application to see if they can click it and install the application. As you see I already completed the installation. I can execute this UTorrent as a non-administrative as well.

So we have uTorrent running and switch over to an App Control managed system, you can see that uTorrent was downloaded and when I go to execute it is denied. This user is not authorized and when trusted ownership comes into play look at the properties and view the security tab. The Advanced tab you inform you that the owner is a user. This particular user was not one of the four trusted owners therefore will be unable to execute the application.

In our demo of how trusted ownership permits applications to run, we can launch Word and the user has no problem. The reason being is if we look at the office folder and look at windward and view the security tab and then view the advanced tab, you notice Word was placed there by the system account. This verifies the owner and therefore it’s able to run.

Another example to take a look at here is file-less malware a lot of times nowadays that PowerShell is used to download code from the internet and execute it on the workstations.

So you can see here in this instance I’m able to launch PowerShell. I have a PowerShell window waiting here it’s going to execute this line of code. This is a one-liner to invoke mimikatz. If we had App Control loaded, the user would not able to execute PowerShell. What also comes into play here is running the actual ps1 file since that file itself is not a trusted owner.

These are two examples. The last one I’d like to execute is a Word document we download that we received via Outlook. We want to execute it and we just enable macros.

We’re just waiting a few minutes there you notice the file name has changed. While we are waiting for that we could potentially have more payloads being downloaded. As you see we now have cryptolocker loaded our files are encrypted.

What I’d like to do is demonstrate what it would look like on a workstation with Application Control enabled. We can launch that same document and we will also enable content just the same and you see the file name did change. This user is not authorized to execute cryptolocker so there you can see how we can just close out of that document. Application Control protected us. If we switch over here these files here are encrypted.

Thank you that concludes my demo. Thank you for your time.

Trevor Prokop
Architect & Director of Professional Services
LinkedIn Profile

<<Back to CDA Blog

Ivanti UWM Application Network Access Control (ANAC)

[Video Transcripion]
Today we’re going to go over Application Control Application Network Access Control or ANAC. Application Network Access Control or ANAC is part of the UWM suite from Ivanti and we’re going to present a very specific use case.

You may have an older portal or some type of web site within your company that requires a particular version of Internet Explorer or some other browser. The biggest problem with using an older browser in your environment is that it’s most likely going to be unsupported and not regularly patched.

If you’re forced to use an older browser because of an incompatibility in the newer browsers, there is a way to limit your risk and we’re going to show you how to do that with application control.

First thing we’re going to do here is open up our application control console. We’ve had a brand new untitled configuration here, if you’re familiar with Application Control you know that there are different rules that you have available to you. The group rules, user rules, device rules, custom scripted, and process.

For what we are going to be doing we need a process rule. Let’s go down to process rule and we’re going to create a new process rule. We going to rename and the process itself is going to be the Internet Explorer process.

There are a couple of things that are important in this particular environment and that is that there are other versions of Internet Explorer that will need to be able to run normally while we restrict this special one.

We can’t exactly duplicate this kind of scenario on a Windows 7 machine because apparently it’s very difficult now to get the older versions of Internet Explorer installed on Windows. I’m just going to show you what the difference would be between two different versions of Internet Explorer, across two different platforms, so we’ll have a windows 7 with one version of Internet Explorer and then a slightly newer one obviously for Windows 10.

Were going to need to actually look at the file that’s on the endpoint itself. So we’re going to look at, in this case, our Windows 7 machine and we’re going to select the I explorer.exe. When we do that we’ve populated the metadata from that file.

Now what we’re going to do here is put a minimum and maximum for the metadata.

This will filter this particular rule so that it will only apply to this specific version of Internet Explorer. When we go back I can take that out we don’t want.

We’re going to click OK and now we’ve set our process rule the top-level rule for Internet Explorer and we put metadata to specify a particular version. We have to go in and put our allows and denies now by default and we want to deny access to all websites.

I’m going to go in and put a star in under host now that will block all web pages. It will only apply to this older version of Internet Explorer. I do need the user to be able to get to the portal the internal portal.

We’re going to just pretend that that internal portal is going to be Google so let’s go in we’re going to go to hostname again. This time just to make sure we catch it on both sides we’re going to do star star and we’re going to check this box here for text contains wildcard characters.

One of the basic rules that we have in Application Control is that if there is a conflict between an allow and a deny, the allow wins so we can deny broadly and allow narrowly.

Now that we’ve done that we’re going to go ahead and save this configuration into the management center. We will call this OBE Management Center and we’ll go into our packages section. We have an audit version of the config that’s deployed so we’re going to go ahead and change that configuration to old ie.

Normally in a production environment, you’re always going to use the exact revision and you don’t want these things to upgrade without your consent. We’re just going to go ahead and leave it at revision zero.

They always use the latest and greatest version for testing, but I wouldn’t use it in a production environment.

Let’s go to My Computer, I’ve already got this set for a very low poll period but I’m just going to go ahead and poll it right now.

Now that the pole is turned green we can go ahead and switch over to our Windows 7 machine. Now we’re just logged in as a regular user I’m going to go ahead and open up Internet Explorer. We’re going to see immediately that we’re going to get a lot of denies because Internet Explorer talks to a bunch of different sites being that there are all kinds of things here. Let’s go ahead and open up Internet Explorer or open up Google we’re only going to get what we’ve allowed which is

Okay now, this is the Internet Explorer version that is on Windows 7. What I’m going to show you is that if we go over to Windows 10 we’re logged in on the same account. I’m going to go ahead and open Internet Explorer. Notice that Internet Explorer is opening up with no problem at all and that is because this is a different version of Internet Explorer.

The file version is different and so it’s ignoring the rule for that version. Let’s go back over it to the Windows 7 machine and I’ll just show you that it is only affecting the Internet Explorer browser. We can go to other web pages here with no problem.

This is how we can block older versions of Internet Explorer or any other browser that you might use from running anything, but a very specific web page in your environment with ANAC. Thanks for joining us and I hope you found this helpful!

Ed Webster
LinkedIn Profile

<<Back to CDA Blog

Increasing Visibility to Ivanti Application Control Events with Xtraction


Ivanti’s Application Control has great built-in auditing features that provide insight to actions controlled within Application Control. Although historical auditing is useful, sometimes it can become overwhelming and noisy.

Common Auditing Events:

  • Applications allowed/denied execution
  • Applications running under elevated privileges
  • Self-elevation of applications to run as Administrator
  • Policy change requests

It is key to be able to separate the actionable events from the informational events and be able to present this information in a visible and readable format. Depending on the size of the environment and the number of devices reporting information, the sheer amount of data can become overwhelming.

Ivanti’s Xtraction is a powerful dashboard reporting tool that produces charts and tables in an organized format for better consumption. Xtraction can integrate with a plethora of products, including Application Control, to produce just about any imaginable report.

How Application Control Auditing works out-of-box

Application Control utilizes a configuration deployed on endpoints that determines what programs, websites, and actions a user can and cannot access. Each of these access controls, whether it is an allow or deny, the result can be audited to help refine policy and configuration. There are a number of defined audited events that can be enabled depending on the information that needs to be captured; some events produce more traffic than others, so be careful what is being captured and how long the events are retained.

Trusted ownership is a large part of Application Control. Trusted ownership only allows apps that were introduced by trusted administrators; the list of trusted administrators can be modified to suit any environment. Trusted ownership helps prevent unwarranted and unwanted execution of code, whether it’s good or bad. This code could be introduced into the environment from software a user downloaded or via other means.

Figure 1 – Denied Execution Template 

Upon execution, since the software was not downloaded by a trusted owner, or explicitly defined in the policy, they will get an execution denied prompt; as seen in Figure 1. This can be leveraged with auditing to know exactly who tried to execute untrusted software and what they were trying to execute.

Xtraction Integration with Application Control

Xtraction is a reporting software that uses Data Sources to communicate with databases for information extraction. Each Data Source establishes its own database connection which allows for individual, or compound reporting.

Xtraction uses Dashboards to present information in a clean format and utilizes graphs and charts depending on business needs; Xtraction can also create Documents and Reports.

Dashboard features:

  • Ability to customize components/multiple datasets into charts, graphs, or lists
  • Drill down for more in-depth data visibility
  • Filter based on specific criteria
  • View real-time or historical data
  • Generate and schedule reports for email delivery

Figure 2 – Event Monitor

All of these mechanisms can be used together to have a true understanding of the environment.

Application Control auditing is an important part of Application Control. Each audited event is useful for tweaking the configuration, for example, if there is a need to allow or deny a new item. Auditing helps to gain insight into the actions being performed on an endpoint within an environment.

Xtraction can be used to report on the auditing produced by Application Control, this can be coupled with a number of different charts or graphs depending on the need; figure 2 shows an example of a Dashboard produced from Xtraction for Application Control auditing events.

Figure 2 uses the following components and features to quickly display data for Application Control events:

  • Pivot Charts
    • Displays filtered event numbers compared with event description and user
  • Time Chart
    • Displays the number of events within the past week
  • Filters for specific event numbers that pertain to Application Control events

For optimal reporting, this Dashboard could be scheduled and sent out via email weekly to stay up to date on the events being produced by Application Control.


After a brief overview of Xtraction and Application Control, hopefully there is a better understanding of how they can be used together and the benefits they provide. Application Control is a very useful security tool that provides powerful auditing capabilities.

Leveraging Xtraction, the audited events can be utilized to produce customizable Dashboards in an organized format that will help you refine Application Control policies to create a better user experience. Each created Dashboard can be saved for reuse, sent out regularly via email, or customized at any time if the information needs to be changed.

Zach Thurmond
IT Consultant
Critical Design Associates

LinkedIn Profile

Creating Configured Deployment Packages with Ivanti Package Studio

Introduction to Ivanti Package Studio

Ivanti Package Studio is a customized version of the Liquit Setup Commander. This product is specifically designed to take the guesswork out of creating configured deployment packages by leveraging a collection of downloadable source software which has already been verified and reviewed by the software vendor.

This source software collection is referred to as the ‘Setup Store’. Package Studio can then download or create Import Wizards for all of these applications which enables the technician to quickly configure and create packages for most commercial off-the-shelf (COTS) applications.

The ‘Setup Store’ is a repository of Windows applications, similar to any other App Store. From the ‘Setup Store’ link within the application, queries can be sorted, searched and filtered based on Manufacturer Name, Product Name, Version Number, Setup Type, Category, Platform, Filename, Language or Date.

Readily available Windows applications and patches can then be downloaded to a pre-configured directory on a local drive or on a file share. After an installation has been downloaded, a package can easily be created using Packing Studio to be configured for enterprise deployment.

Ivanti states that the ‘Setup Store’ has grown to more than 2500 entries. Every day the repository is updated with the latest versions and releases of a listed application.

Ivanti Package Studio also supports every vendor MSI. If Package Studio does not have the installation in its repository, the tool will quickly auto-generate a new Configuration Wizard.

Configuration Wizards provide options to remove all Desktop and/or Start Menu shortcuts, suppress reboots, disable auto-update mechanisms, include licensing information, include database settings, and configure many other deployment options. These options are stored in a transform file (MST) for the selected MSI.

Configuration Wizard files are automatically downloaded for each application. When selected, the configuration options will be unique for each application.

In this example, the ‘Google Chrome Configuration Wizard’ can configure a myriad of options for the Google Chrome deployment as follows:

After launching Ivanti Package Studio, in the lower pane, navigate to the vendor install that will be configured.

Right click on the Windows Installer for Chrome Enterprise and select “Generate Transform”

The Google Chrome Configuration Wizard will then launch.
On the Options tab, select any options that are required for the configuration.

On the “Homepage preferences” tab, enter the default homepage.

On the “Distribution preferences” tab, select any distribution options that are required for the configuration.

On the “Features” tab, make any required feature changes.
When all options have been selected, click “OK”

A “Save Transform File” dialog box will open, prompting the user to save the MST file to disk. This file, in combination with the corresponding MSI and optional (CAB), will constitute the completed package.

Ivanti Package Studio can be configured to directly connect to Ivanti Endpoint Manager (formerly LANDesk), Microsoft System Center Configuration Manager, Microsoft Deployment Toolkit, and other software distribution tools for automatic creation of a deployable package.

In summary, Ivanti Package Studio can be a significant time saver in deploying many commercially available applications. Thanks to the ‘Setup Store’, it may be the most complete source for creating Windows Installer Transform files.

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

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…

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