App Distribution Package Actions and Detection Rules
Package actions define how app distribution will deploy your packages. Package detection rules help app distribution decide whether an app should be deployed to a device.
Package actions
Configure package actions in App distribution > App catalog. Add or edit an app, and select the Package tab. Drag the actions you want to use and drop them in the builder tree. Select an action in the builder tree to configure it.
The available package actions include:
These can help determine whether the app is already installed and therefore should not be installed again.
IMPORTANT: If any detection step resolves as true, package processing stops and the device's app state will display as compliant.
See Package detection rules later in this topic for more information on the available detection rules.
Downloads a file to the Ivanti app distribution default working path:
C:\Program Data\Ivanti\Ivanti Cloud Agent\Agent\SWD\working
Any action that accepts a file path will assume this path unless you specify otherwise. This folder is cleared before and after each package is run.
You can specify multiple files here and you can have multiple download file actions if necessary. Files can be hosted on any HTTP(S) location that does not require authentication and that clients you are deploying to can access.
You can type or paste a URL in the From URL field. The URL you provide must link directly to the file you want to download. The file name detected from the URL will appear next to the Choose file button.
Use the Add new file button to add additional download file URLs if necessary. If your files are stored in Microsoft Azure Blob Storage or Amazon Web Services Buckets, use Choose file button to open the cloud file explorer.
Cloud file explorer
The Choose file button opens the Cloud file explorer, where you can choose files from your organization's Microsoft Azure Blob Storage or Amazon Web Services Buckets. Azure and Amazon storage accounts are not included with Ivanti Neurons.
- For information on how to create a storage container in Azure, see this Microsoft article.
- For information on how to create a Bucket in Amazon S3, see this Amazon article.
Before using the cloud file explorer, you must add your Azure Blob Storage or Amazon S3 credentials in Admin > Credentials. For more information, see Credentials. With Azure, we recommend you create credentials in Ivanti Neurons for both your Azure key1 and Azure key2 to allow for Azure key rotation. You can then select the account you want in the cloud file explorer.
These credentials are used to populate the folder and file list so the download file action can get Shared Access Signature URLs (Microsoft Azure) or Presigned URLs (Amazon Web Services) for the files you select. Clients will not use these credentials.
Once you have added credentials, you can select your cloud storage Account and Container or Bucket in the cloud file explorer. The container browser shows files and folders stored there. Add one or more files by selecting the check box next to them and selecting the Add button. URLs for the files you added then appear in the Download file action properties.
Cloud storage providers require that generated URL tokens have an expiration. App distribution sets the token expiration to seven days, and every five days it renews the token to prevent loss of access from targeted clients.
Cloud file filtering in the Filter by prefix text box is limited by the Microsoft and Amazon S3 APIs. The filter is limited to the folder you have selected and does not include subfolders. The filter text you enter must be an exact filename (case-sensitive) match and start with the first character of the filename you want. You do not have to include the full filename, just the initial characters.
Selecting Delete will delete the selected object (a file or folder). Make sure you have only one object selected before clicking delete. You will see an error message if you try deleting multiple objects at once. If you want to delete a folder, you must first delete the folder's contents (one object at a time).
Ivanti cloud storage
In version 2024.4 Ivanti added support for Ivanti cloud storage, which you can use to store packages and files that you want to distribute. This is helpful for customers who do not already have Azure Blob Storage or Amazon S3 storage accounts.
There is no additional configuration or credentials required to use Ivanti cloud storage. Each Ivanti Neurons tenant has their own Ivanti Azure storage container.
In the app distribution Download file action, you can access the cloud file explorer. There you can select Ivanti Storage under Account. You can then use the Upload files button to upload files you want to distribute. You can also use the Delete button to remove files.
Keep these items in mind while using Ivanti cloud storage:
- Ivanti cloud storage is limited to 10 GB, and the cloud storage explorer will show you how much of that space you are using. There is no option to expand this storage amount.
- File sizes here cannot exceed 2 GB.
- Ivanti includes a service that scans uploaded files for malware. If malware is detected, the file will be deleted and an Ivanti Neurons notification message will indicate that this has happened.
- If you are only using Ivanti cloud storage, you do not need to configure Cross-Origin Resource Sharing (CORS).
- Creating folders is not supported.
Uploading files
Use the Upload files button to browse for and upload files you select. Uploaded files are put in the folder you have selected in the explorer. Uploaded files cannot be larger than 2 GB. You can only upload one file at a time. It can take a while for large files to finish uploading, so you may not see uploaded files immediately in the explorer.
A progress bar displays while the file you have selected is prepared for upload. While the upload is happening you will see a work in progress indicator. Once the upload completes you will see a message indicating upload success or failure.
If you want to upload files larger than 2 GB, use native Amazon or Azure management tools to do the upload.
You must configure Cross-Origin Resource Sharing (CORS) before you can upload files. If you try to upload a file and CORS is not configured, you will see a message saying you first need to configure CORS.
Azure Blob Storage upload configuration
Azure configures CORS at the account level, not the container level. Microsoft has information about configuring CORS here.
- Allowed methods: PUT
- Allowed headers: content-type,x-ms-client-request-id,x-ms-useragent,x-ms-version
- Exposed headers: Etag
- Allowed origins: The domain shown in the browser URL at your Ivanti Neurons login page (not the URL once you are logged in). This varies depending on where your tenant is hosted. Examples include https://nvuprd-sfc.ivanticloud.com, https://ukuprd-sfc.ivanticloud.com, and so on.
Amazon S3 upload configuration
Amazon S3 configures CORS at the bucket level, not the account level. Amazon has information about configuring CORS here.
- Allowed methods: PUT
- Allowed headers: content-type
- Exposed headers: Etag
- Allowed origins: The domain shown in the browser URL at your Ivanti Neurons login page (not the URL once you are logged in). This varies depending on where your tenant is hosted. Examples include https://nvuprd-sfc.ivanticloud.com, https://ukuprd-sfc.ivanticloud.com, and so on.
SHA256 hash value
The download file option also includes an optional hash value field. If you provide a hash value, app distribution will validate the downloaded file's hash value. If the values do not match, app distribution will delete the downloaded file and stop the distribution. If you want app distribution to use advanced distribution technologies like peer download, you must provide a hash value.
The plain Execute action allows you to specify a file to execute, a command line, and what user the installer should run as. The Execute MSI and Execute MSIX actions let you select MSI, MSP, and MSIX-specific operations and display options.
Includes create folders; move, copy, and delete files; zip or unzip.
Reboots the device according to the device's agent policy. When an app requires a reboot, no other apps can be installed to that device until it reboots.
Create or delete registry keys. Set or delete registry values.
Execute a batch file or PowerShell script. The PowerShell Core option does not install PowerShell Core if it is missing. The Auto option will first try PowerShell Core, and if that isn't installed it will fall back to PowerShell. A script editor is built in to this action. Your script code needs to be added inside this editor.
Pauses package execution for the number of seconds you specify. Use this if earlier actions need additional time to complete.
Manages a package using Windows Package Manager (winget).
This action is automatically configured when you select Add application > Windows Package Manager (winget) in the App catalog main page and select a package. This action does not require any other actions or modifications to work.
If necessary, you can add and configure this action manually. This action can also be used in combination with other actions and detection rules.
For more information on using winget, see this Microsoft topic.
Package Manager requires a recent version of winget on managed devices. If you have disabled the Microsoft Store on managed devices, their winget version may be old and package manager distributions to them may fail. To fix this, deploy a package updating the winget version or enable the Microsoft store.
The Package manager options panel includes a Choose package button that shows available packages in the winget catalog. This is the same catalog shown when you use the Add application button in the App catalog main page.
The app catalog only includes apps in the winget repository, not the msstore repository. If you have an msstore app ID, you can manually specify it on the command line after the --id parameter as described later in this section.
Entering text in the Search packages box searches all metadata in all packages in the catalog. If you want to search for package text in a specific metadata category, begin your search with name:, publisher:, and so on, as the example shows when you select the search field.
App distribution will install the latest available version of a package you select, regardless of the version shown in the catalog. You may also manually configure the action to install a specific version.
Choosing a winget package in the catalog populates the Command line arguments to install that package. You can modify the command line if necessary.
Here is a typical winget command line:
install -e --id GitHub.GitHubDesktop --accept-package-agreements --accept-source-agreements --silent
If you want to install a package that is not listed in the app catalog, you can create your own winget command line. In a Windows command prompt, the winget search <query> command returns a list of matching packages. Find the Id column string for the package you want, and on the winget command line add it after the --id parameter.
The author of a winget package may include installers in the package scoped to either user (logged in user), machine (all users), or null (not specified). By default winget will attempt to pick the best match for the device, which often is user.
You can override this automatic selection by specifying a scope in the command line with the --scope parameter. For example, if you want the package to be installed for all users on a device, you can include --scope machine on the winget command line. Note that if the package does not support a machine scope and you include the parameter on the command line, the package installation will fail.
As always, make sure to test your command line before deploying your package.
Package detection rules
Package detection rules can help determine whether a package is already installed and therefore should not be installed again.
Configure package detection rules in App distribution > App catalog. Add or edit an app, and select the Package tab. Add the Detection pre-deployment action to the builder tree and select it to configure it.
Detection rules are only checked at the beginning of processing a package, and so a detection action will always be the first item in the builder if it is used. Detection rules run in the order that they are defined.
IMPORTANT: If any detection step resolves as true, package processing stops and the device's app state will display as compliant.
The available detection rules include:
Provide the full file path and file name. Select either Exists or Does not exist.
File version information is generally only available for executable files. App distribution uses the "File version" value, not the "Product version" value. Provide the full file path and file name. The operator can be variants of less than or greater than, equal, or is between. If the file and path you specify does not exist or if the file does not have a parsable version, it returns false.
For details on how version and comparison operators work, see this article from Microsoft.
Provide the full file path and file name. Specify the file size in bytes. App distribution uses "Size" and not "Size on disk." If the file and path you specify does not exist, it returns false.
Provide the full file path and file name. Select the SHA-2 bit length you are comparing. If the file and path you specify does not exist, it returns false. You can use PowerShell to generate a hash digest:
-
Get-FileHash -Algorithm SHA256 -Path C:\MyApp\myfile.exe
This rule looks only at the date, not the time. Provide the full file path and file name. Select an operator, like Equals. The file date must be specified in UTC (coordinated universal time), matching your locale's equivalent of mm/dd/yyyy format. App distribution uses the "Modified" date, not the "Created" date. If the file and path you specify does not exist, it returns false. You can use PowerShell to retrieve the file date in UTC:
-
(Get-Item C:\MyApp\myfile.exe).LastWriteTimeUtc
Provide the MSI product code GUID and select whether the MSI Is installed or Is not installed. Use Microsoft's Orca tool to view the "ProductCode" GUID. You can also see installed MSI GUIDs under these registry keys:
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
- HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
- HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall
Provide the MSIX package full name and whether the MSIX Is installed or Is not installed. Use the PowerShell Get-AppxPackage command to find the package full name, as Microsoft describes here.
Provide the registry key information for the key you want to detect.
- Registry version: Select 32-bit or 64-bit as appropriate, or you can select System if you want to automatically match the version that the targeted device is using.
- Root key: Select the root key containing the key you want to detect, such as HKEY_LOCAL_MACHINE.
- Key: Enter the full path (do not include the root key you already specified) to the registry key name you want to detect.
- Specify Exists or Does not exist
Provide the registry key and value information for the value you want to detect. If the key or value does not exist or is not accessible by the user, the rule will return false (unless the comparison operator is Does not exist).
You must specify a value name, unless you want to check the "(Default)" value, in which case it must be left blank.
When doing a version comparison, the comparison operand(s) and the data associated with the registry value must be in the version format described here. If any of those is not, the detection rules (and the package) will generate an error.
For details on how version and comparison operators work, see this article from Microsoft.
String comparison is case-sensitive. If the registry value has data that is not of type REG_SZ (String), it is converted to a string as follows:
- REG_DWORD: The decimal form (as shown in regedit.exe) is used.
- REG_QWORD: The decimal form (as shown in regedit.exe) is used.
- REG_BINARY: The byte pair form used by regedit.exe is used, but capitalized (e.g. "46 AA 6C 6B 65 6E").
- REG_MULTI_SZ: The lines are concatenated together with spaces to form a single line (for example, "Line1 Line2 Line3").
- REG_EXPAND_SZ: All environment variables are expanded.
Detection scripts can use PowerShell (not PowerShell Core) or batch syntax. Detection success is based on the script's numeric exit code. An exit code of "0" (zero) equals true. Any other exit code is considered false. The exit code must be numeric and not the word "True". Use the built-in script editor to create your script.
Use the built-in script editor to create a script, or you can use the Select file option and browse for a file. The file and path you provide must exist on the target system. If the script file is not already on the device, use the Download file action to place it there. When you do this, the downloaded file is placed in a default path and you can just specify the file name.
Since detection rules run before other package actions, this places detection rule scripts at a unique stage in the app installation process. It is possible to do more complex things here, such as runnning a customized upgrade script that looks for an older app installation and if it finds it, uninstalls it before proceeding on with the rest of the package.
Detection rule and action logging
App distribution creates a log file for each app deployed to a device. The log has entries for each detection rule and other package actions. If detection rules are not working as expected, use the log file to help determine why. Logs are stored on each device in this folder:
- C:\ProgramData\Ivanti\Ivanti Cloud Agent\Logs\SWDApps
Each log file name includes the package GUID. If you edit a package in the App Catalog, you can see its package GUID in the web browser URL. This will help you find the log file you are interested in.
You can view a simplified log remotely from the App Distribution > Deployment Status page. Find the device and package you want to see, and on the right, select the action menu's View log option.