Intune, Configuration Manager, RMM and cloud images

Every management tool that can run a PowerShell script and an msiexec command can deploy the deployment MSI. The recipe is the same everywhere, and it has three parts:

1. Stage the key on the host with Stage-DeployKey.ps1, reading the key from your tool's secret store on standard input.
2. Run msiexec /i dplens-1.0.912-deploy.msi /qn /norestart /l*v <log>.
3. Detect the install by the dplens service or, better, by the applied marker %ProgramData%\DPLens\state\deploy.json, which names the bundle.

Sign the deployment MSI with your code-signing certificate first; it is built unsigned.

The one rule that matters is where the key comes from. Every tool below has a way to hold a secret and hand it to a script at run time; use that, and pass it to the staging script on standard input. Never write the key into the script's text or its command line: script text is logged and synchronised, and command lines are audited.

The installer deletes the key after use, so a host that has installed holds nothing to protect. A host on which the install failed has also had its key deleted — stage it again when you retry.

Intune (Win32 app)

Package the bundle folder as a Win32 app (.intunewin) with:

• Install command:

  powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -File Install.ps1

where Install.ps1 obtains the key from your secret store (Key Vault via a managed identity, or however your tenant hands secrets to devices), pipes it to Stage-DeployKey.ps1 -Target ProgramData, and then runs msiexec.

• Uninstall command: msiexec /x {ProductCode} /qn — the product code is in bundle.json.
• Install behaviour: System.
• Detection rule: file exists %ProgramData%\DPLens\state\deploy.json, or the service dplens exists.

A newer bundle is a new app version with a supersedence relationship; the newer package updates the configuration in place and keeps the working licence.

Configuration Manager (SCCM / MECM)

Either an application whose deployment type runs the same Install.ps1 (detection: the marker file), or a task sequence with two steps:

1. Run PowerShell Script — the key from a task-sequence variable or your secret store on standard input, into Stage-DeployKey.ps1 -Target ProgramData.
2. Install Application or Run Command Line — msiexec /i dplens-1.0.912-deploy.msi /qn /norestart /l*v %TEMP%\dplens.log.

Put the bundle on a distribution point like any other content; the package carries only encrypted material.

RMM tools

Any RMM that can run a script as SYSTEM or as an administrator: the script reads the key from the RMM's secret or variable store, stages it, runs msiexec, and reports the marker's bundle id back. Most RMMs log a script's output; the staging script prints only where it staged the key, and msiexec prints nothing, so the key never reaches the RMM's log.

Cloud images and user-data

For a machine built from a cloud image, the same script runs from user-data or the platform's first-boot hook, taking the key from the platform's secret service (a managed-identity call, an instance metadata secret). Do not bake the key into the image, and do not bake a staged key file into it either: an image that carries deploy.key hands it to every machine built from it. See Golden images and VDI clones.

Retrying and updating

• Retry: stage the key again and run msiexec again. The marker is only written when the install succeeded, so a detection rule on the marker retries a failed host naturally.
• Update the configuration: deploy the newer deployment MSI the same way. A newer package over an installed agent applies the new capture and keeps the working licence. For the same version with a new capture, use a push or the manual apply step described under The deployment MSI.