Automate Configuration Manager Application Creation

A simple example to automate the application creation process in ConfigMgr.

RebootBehavior set to NoAction, Accepted values: BasedOnExitCode, NoAction, ForceReboot, ProgramReboot
AutoInstall $true – indicates whether a task sequence action can install the application
Added Action to Distribute the Content to the DP Group at the end


  • Application Name
  • With a deployment type: Same application name
  • Content Location
  • Installation Program
  • Uninstall program
  • Repair Program
  • Detection method (a specific MSI Product code)
  • User expierence: Install for system if resource is device; otherwise install for user
  • Logon requirement: weather or not a user is logged on

    Published on Github:

New Microsoft Edge based on Chromium – error status: 1603

I recently ran into to an issue deploying the New Microsoft Edge, for some reason it kept failing with Error status 1603 on most of the systems.

The deployment version was version: 87.0.664.47
It kept failing on a lot of systems with build: 1803, I did suspect a missing KB of some kind, but did not find any apparent prerequisites missing.

Tried the same method for the latests version – 87.0.664.60, both downloaded from: and everything seem to be working, now deployed to more then 2000 systems.

CustomAction DoInstall returned actual error code -2147219187 (note this may not be 100% accurate if translation happened inside sandbox)

Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action DoInstall, location: C:\WINDOWS\Installer\MSI9085.tmp, command: /silent /install "appguid={56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}&appname=Microsoft Edge&needsAdmin=True&usagestats=0&ap=stable-arch_x64" /installsource enterprisemsi /appargs "appguid={56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}&installerdata=%7B%22distribution%22%3A%7B%22msi%22%3Atrue%2C%22system_level%22%3Atrue%2C%22verbose_logging%22%3Atrue%2C%22msi_product_id%22%3A%2292749E40-069E-3467-BB1F-78BB266190E2%22%2C%22allow_downgrade%22%3Afalse%2C%22do_not_create_desktop_shortcut%22%3Afalse%2C%22do_not_create_taskbar_shortcut%22%3Afalse%7D%7D" 

MSI (s) (10:A8) [13:21:48:649]: Product: Microsoft Edge -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action DoInstall, location: C:\WINDOWS\Installer\MSI9085.tmp, command: /silent /install "appguid={56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}&appname=Microsoft Edge&needsAdmin=True&usagestats=0&ap=stable-arch_x64" /installsource enterprisemsi /appargs "appguid={56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}&installerdata=%7B%22distribution%22%3A%7B%22msi%22%3Atrue%2C%22system_level%22%3Atrue%2C%22verbose_logging%22%3Atrue%2C%22msi_product_id%22%3A%2292749E40-069E-3467-BB1F-78BB266190E2%22%2C%22allow_downgrade%22%3Afalse%2C%22do_not_create_desktop_shortcut%22%3Afalse%2C%22do_not_create_taskbar_shortcut%22%3Afalse%7D%7D" 

MSI (c) (C4:44) [13:21:48:771]: Windows Installer installed the product. Product Name: Microsoft Edge. Product Version: 87.0.664.47. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 1603.

Any ideas, other then deploying latest and greatest? Let me know

Deploy Microsoft Edge Chromium Using PowerShell App Deployment Toolkit (PSADT)

The new Microsoft Edge  is based on Chromium and was released on January 15, 2020. It is compatible with all supported versions of Windows. Installing the browser will replace the legacy version of Microsoft Edge on Windows 10.

PowerShell App Deployment Toolkit (PSADT) is a great framework to deploy and manage application deployment – it is free of charge and can be downloaded from

The script is published here on Github

This deployment script example does the following within the PSADT framework:

If Microsoft Edge is open, it will prompt the user to close it or delay the deployment 3 times (Comment line 120 if you prefer to just shut it down)
As a Pre-installation task it searches the add/remove program list for any version of Microsoft Edge and uninstalls it.

It then installs the MSI file from the Files directory – MicrosoftEdgeEnterpriseX64.msi
The latests version of Microsoft Edge for Business version can also we downloaded from –

Uninstalltion is performed using the name from Add/remove programs (same as for the pre-install step) so this will require no changes. (Line 181)

If needed repair can be enabled (or updated for other versions)
(Modify line 203 if deploy other versions)

Microsoft Edge follows the Modern Lifecycle policy. Learn more about supported Microsoft Edge releases.

MSiX Insider Preview Build 1.2019.522.0

First insider preview release for the upcoming public release in July.

New Features:

  • Support for desktop installers that require restart – read more
    • Auto-login option for restart
  • New options in app settings
    • Specify a default cert to sign packages with
    • Specify exit codes for installers that require restart

Known “bugs/features”

  • Negative reboot exit codes are currently not supported
  • If Default cert is specified, you still need to select to sign your package
  • During remote or VM restarts, there might be an extra login prompt
  • Restore defaults button doesn’t remove certificate password or installer exit codes
  • There are some UI incongruencies

You can find the full history of MSIX Packaging Tool release notes here.

List Packages that run in user context (Run with user’s rights)


After last weeks post with the script sample to list Packages that run in user context, there where some good feedback from people still using packages, and requiring a list of packages that install within the user context (Run with user’s rights / Execution mode as user)

It seemed that many was still using Packages, either as a result of legacy migration or to avoid some application re-packaging.

So here is the followup post, with a new script to list all packages and package with programs that run in user context.

From my point of view, its still the same; Using PSADT pretty much any package can be converted to be installed as system, and the needed stuff (registry keys, files etc) in the user context can be added in a structured and controlled way.

I do still come across some applications that i would prefer to have in MSI with all settings etc added, at least for simplicity, for those packages I still prefer to use Advanced Installer.
When talking Advanced Installer, they also have a great support for MSIX, that makes to process so much easier and cost efficient.

This script will list all packages with programs, that is configured to install as user (within the user context)

All you need to do is configure the path to your import module and set the site code.

A file will be created in “C:\TEMP\Packages_and_Programs_Run_Mode_List.csv” with the following format:

“Package Name”,”Package ID”,”Program Name”,”Run with USER’s right”
“My Application”,”BB10001D”,”execute”,”TRUE

With the example above we have a package ‘My Application’ that has a run mode configured: Run with user’s rights

Properties on the program, where the program run enviroment is configured to Run with Users’s rights

Download the script from TechNet Gallery

List Applications that run in user context (Install for User)


When deploying applications sometimes they are created to install within the active users context.
This means that the actual installation requires the users to have the needed permissions to the filesystem, registry and etc.
In some cases local administrative rights are needed to perform the application installation, this is not a good practice.

As applications mature for the modern design of the Windows Operating System or we choose to remove the users administrative rights due to security reasons, we may need to list and change the behavior of existing Applications.

This script was created to list applications that is configured to run with Installation behavior: Install for User

The actual output will end up in the export csv file

Script Download Get_Application_USER_Context_List

Today with the modern management tools and applications, the users should not have local administrative rights on a permanent basis.
Most, if not all applications can be repackaged to deploy without the need for administrative rights.

Useful links:

PowerShell Application Deployment Toolkit:
Advanced Installer:
Access Director Enterprise:

Cleaning up shortcuts

So the issue at hand;
I was replacing a Office application on Windows systems, where i noticed that shortcuts created by the users, was not upgraded/removed when the new office version was installed.

The issue seems to be related to users creating custom shortcuts, directly to exe files.
I some cases the shortcut name was clear, but in other cases the users had chosen something they found fit.

The following PowerShell script was created to remove shortcuts (lnk files) based on the executable. This means you can specific the exe or use a wildcard if there is multiple executable files releated to an application.

$ShortcutLocations = Get-ChildItem -Recurse (“C:\Users”,”C:\ProgramData\Microsoft\Windows\Start Menu”) -Include *.lnk -Force -ErrorAction SilentlyContinue

# This script searches for all *.lnk files to "C:\Program files (x86)\App\My Application.exe" or "C:\Program Files\App\My Application.exe"
# It searches in C:\users\* profiles paths, including Users Desktops, %AppData%\Microsoft\Internet Explorer\Quick Launch and in ProgramData...StartMenu
# The name of the link file can have many different names, therefore we must find each shortcut based on path to target exectuable and not on lnk name.
# Then the lnk file must be deleted.
# The script should be run with admin rights, otherwise shortcuts will only be deleted for the user running the script.

### Specify shortcut's target executable here.
$AppExecutable = "C:\Program files*\Microsoft Office\Office15\*.exe"
# * Due to mask it contains "Program files" and "Program files (x86)" paths both.

### Paths to browse and search for shortcuts.
$ShortcutLocations = Get-ChildItem -Recurse ("C:\Users","C:\ProgramData\Microsoft\Windows\Start Menu") -Include *.lnk -Force -ErrorAction SilentlyContinue
# * -Recurse = Includes all subdirectories.

### Get properties for shortcuts in the locations

Function Get-ShortcutsProperties {
$Shell = New-Object -ComObject WScript.Shell 
Foreach ($Shortcut in $ShortcutLocations)
$Properties = @{
ShortcutName = $Shortcut.Name;
ShortcutFullName = $Shortcut.FullName;
ShortcutLocation = $shortcut.DirectoryName
ShortcutTarget = $Shell.CreateShortcut($Shortcut).targetpath
New-Object PSObject -Property $Properties
[Runtime.InteropServices.Marshal]::ReleaseComObject($Shell) | Out-Null

$ShortcutsList = Get-ShortcutsProperties

### Compare shortcut's target path with $AppExecutable and delete it in case of corresponding one
Foreach ($item in $ShortcutsList) {

if ($item.ShortcutTarget -like $AppExecutable) {

Remove-Item -Path $item.ShortcutFullName -Force -ErrorAction SilentlyContinue
######## End of the script

Download the PowersShell Script here: DeleteApplicationShortcuts

MSiX – Remote machine conversions

The MSiX Packaging Tool (1.2019.226.0) Preview now has the ability to connect to a remote machine, where you can run the conversion.
This is great news, and solves the normal issue with contamination on “non-sanitised” machines.

I have always preferred to do my packaging and re-packaging on Hyper-V Virtual Machines
This gives a total control and clean enviroment, with easy ability to get back to a controlled point of reference, using checkpoints.

Getting started with remote machine conversions? Fear not! It is quite simple to get started.

– PowerShell remoting must be enabled for secure access to the remote machine.
– You must be logged on with administrative privileges on the machine.

To enable PowersShell remoting on the machine, run the following command in an elevated PowerShell prompt: Enable-PSRemoting -Force -SkipNetworkProfileCheck

If network/firewall restrictions are in place, remember to allow inbound traffic on port 1599 (MSiX Packaging Tool default port, it can be changed with the settings tab)

If you are connecting using a non-domain joined machine, you must use a certificate to connect over https.
To enable PowerShell remoting and allowing WinRM over https run the following commands in an elevated PowerShell prompt

Enable-PSRemoting -Force -SkipNetworkProfileCheck

New-NetFirewallRule -Name "Allow WinRM HTTPS" -DisplayName "WinRM HTTPS" -Enabled True -Profile Any -Action Allow -Direction Inbound -LocalPort 5986 -Protocol TCP

To generate a self-signed certificate, configure WinRM secure configuration and export the certificate, you can run this script: (or download: GenerateSelfsignedWinRMHTTPS)

$thumbprint = (New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation Cert:\LocalMachine\My -KeyExportPolicy NonExportable).Thumbprint
$command = "winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=""$env:computername"";CertificateThumbprint=""$thumbprint""}"
cmd.exe /C $command
Export-Certificate -Cert Cert:\LocalMachine\My\$thumbprint -FilePath <path_to_cer_file>

On your locale Machine, copy the exported certificate and install it into the Trusted Root Store.
It can be imported with the following command: Import-Certificate -FilePath <path> -CertStoreLocation Cert:\LocalMachine\Root