Download and Install PowerShell Script for Windows OS

Objective

To provide a reusable Windows Worklet script that downloads software installers (such as MSI files) from an external URL and executes the installation locally, bypassing Automox console payload file size limits.

Overview

When deploying large software packages (such as installers that exceed Automox file upload thresholds), administrators can host the installer on a secure internal repository, cloud bucket, or CDN.

This Worklet uses Invoke-WebRequest to download the target file directly to the endpoint and initiates a quiet background installation using Start-Process. While configured for .msi installers by default, the script can be adapted for executable binaries (.exe) or Windows update packages (.msu).

Script Configuration Variables

Before deploying the Worklet, update the following parameters in the Remediation Code block:

Variable NameDescription & Example Value
$sourceDirect download URL of the hosted installer (e.g., '[https://repo.domain.com/installers/app_v2.msi](https://repo.domain.com/installers/app_v2.msi)').
$destinationLocal target directory and file name (e.g., 'C:\Windows\Temp\installer.msi').

Worklet Setup Instructions

 

1.Create a New Windows Worklet:

  1. In the Automox console, navigate to Policies > Create Policy.
  2. Select Worklet and set the OS target to Windows.
  3. Enter a descriptive policy name (e.g., Windows - Download and Install Application via URL).

2.Configure Evaluation Code:

To force execution during a scheduled maintenance window or manual policy run, set the Evaluation Code block to return exit code 1 (Non-Compliant):

# Automox Worklet Evaluation Code: Force Execution
exit 1

3.Configure Remediation Code:

Paste and customize the following script in the Remediation Code block:

# Automox Worklet Remediation Code: Download & Silent Install

$scriptblock = {
    # Define remote download source and local file destination
    $source      = 'https://YOUR_SECURE_URL_HERE/installer.msi'
    $destination = 'C:\Windows\Temp\installer.msi'

    try {
        Write-Output "Downloading package from $source ..."
        Invoke-WebRequest -Uri $source -OutFile $destination -UseBasicParsing -ErrorAction Stop

        Write-Output "Initiating installer execution ..."
        # Quiet MSI installation with no restart
        $process = Start-Process msiexec.exe -ArgumentList "/i `"$destination`" /qn /norestart" -Wait -PassThru -ErrorAction Stop

        if ($process.ExitCode -eq 0) {
            Write-Output "Successfully installed application."
            
            # Cleanup local installer file
            if (Test-Path $destination) { Remove-Item -Path $destination -Force }
            exit 0
        } else {
            Write-Error "Installer exited with non-zero status code: $($process.ExitCode)"
            exit 1
        }
    }
    catch {
        Write-Error "Software deployment failed: $_"
        exit 1
    }
}

# Execute inside 64-bit PowerShell context wrapper
& "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -NonInteractive -Command $scriptblock

4.Assign Device Groups & Execute:

Assign the Worklet policy to your target Windows Device Groups and run the policy manually or on a scheduled maintenance cycle.

 

Adapting for Other Installer Types

Modify the Start-Process call in the Remediation block to accommodate alternative installer formats:

  • Executable Files (.exe):

    Start-Process $destination -ArgumentList "/S /quiet" -Wait -PassThru
    
  • Windows Update Packages (.msu):

    Start-Process wusa.exe -ArgumentList "`"$destination`" /quiet /norestart" -Wait -PassThru
    

Key Operational Considerations

  • 64-bit Execution Wrapper: The $env:SystemRoot\sysnative\... wrapper ensures PowerShell executes in a native 64-bit environment, avoiding WOW6432Node path redirection or 32-bit registry/file-system limitations.

  • Basic Parsing: Adding -UseBasicParsing to Invoke-WebRequest avoids errors on Windows endpoints where Internet Explorer / DOM rendering engines are disabled or uninitialized under NT AUTHORITY\SYSTEM.

Was this article helpful?
0 out of 0 found this helpful