Deployment guide

One installer for every method

MuonInsightSetup.exe installs, upgrades and removes the toolkit. Every deployment tool runs the same file with the same options, so there is one thing to build, sign and test:

/org is display-only: it is shown in the toolkit’s reports. It never changes where the toolkit installs, which is always %ProgramFiles%\Muonix Labs\Muon Insight. Omit it to keep the name already recorded on the device or the one built into the package. Add /removedata (or -RemoveData) to an uninstall to also delete every user’s logs, reports, task history and preferences.

The full option and exit-code list is in deployment/installer/README.md.

The deployment folder

Why the install script exists

Tools that run PowerShell rather than a program need Invoke-MuonInsightSetup.ps1. Setup is a windowed program, and PowerShell does not wait for one by itself; the script waits, copies setup’s log into the output the tool records, and exits with setup’s exit code. It also finds setup’s own cached copy for uninstall, so removal needs no package.

Running from a network share

SCCM and Intune copy content to the device before running it. Other tools often run setup straight from a share. Setup handles both: when it is started from a network path it copies itself, and a repositories.json beside it, to the local temporary folder and runs from there. A dropped connection therefore cannot interrupt an install part-way.

The identity running setup needs read access to the share. Run as SYSTEM, the file server sees the computer account (DOMAIN\COMPUTER$); grant read access through an approved device group. Do not embed share credentials in a script.

Prepare the package

Build with scripts/build.ps1 (see BUILD_AND_PACKAGING.md), then prepare one folder per version:

MuonInsight-0.26.0\
|-- MuonInsightSetup.exe         the application and its installer, in one file
|-- Invoke-MuonInsightSetup.ps1      only for script-based tools
`-- repositories.json                    optional; exported from the Administration page

Export repositories.json with Export client bootstrap on the Administration page for the intended channel; setup applies a repositories.json placed beside it automatically. Keep separate packages or deployment types for pilot and production so each receives the right bootstrap, or set the repository with Group Policy instead.

Content repository through Group Policy

The Content repository policy sets which repository and channel a computer synchronizes from, and takes precedence over the repositories.json installed with the toolkit. Use it to change a repository or channel without reinstalling.

1. Copy deployment/GroupPolicy/MuonInsight.admx to the PolicyDefinitions folder, and en-US/MuonInsight.adml to PolicyDefinitions\en-US, in the domain’s central store.
2. In a Group Policy object linked to the computers, open Computer Configuration > Administrative Templates > Muonix Labs > Muon Insight > Content repository.
3. Enabled: enter the DFS or UNC repository path and choose the channel. Disabled: turn synchronization off. Not configured: use repositories.json.

The policy writes ContentSyncEnabled, RepositoryPath and Channel under HKLM\SOFTWARE\Policies\MuonixLabs\MuonInsight, which only administrators and policy processing can change. Limit who can edit the Group Policy object as tightly as the repository share. Intune can deliver the same template by importing the ADMX and assigning an administrative templates profile.

Each technician can see the repository in use and whether Group Policy set it under Settings > Module Updates.

Sign MuonInsightSetup.exe and the PowerShell scripts with the enterprise code-signing service. Sign the setup executable only after Build-Installer.ps1 has produced it: the application is appended to the executable during packaging, and setup reads it from beside the signature.

Detection

Setup records the installed version and location under HKLM\SOFTWARE\MuonixLabs\MuonInsight. Both SCCM and Intune detect it with built-in rules; no script is needed.

• Registry rule: key HKEY_LOCAL_MACHINE\SOFTWARE\MuonixLabs\MuonInsight, value Version, string, Equals the packaged version. It is not a 32-bit application’s key.
• File rule (recommended as well): MuonInsight.exe exists in %ProgramFiles%\Muonix Labs\Muon Insight. Together with the registry rule it catches a version key left behind by a partly removed install. Omit it if you install elsewhere with /dir.

SCCM

Create a manually specified Windows application with a Script Installer deployment type.

• Installation program: MuonInsightSetup.exe /silent /org:"Organisation name"
• Uninstall program: MuonInsightSetup.exe /uninstall /silent
• Detection method: the registry setting and file clauses above, joined with And.
• Install for system, whether or not a user is logged on, with hidden visibility.
• Requirements: 64-bit Windows 10 or Windows 11 with .NET Framework 4.8.
• Estimated runtime: five minutes. No forced restart.

SCCM records the command and exit code in C:\Windows\CCM\Logs\AppEnforce.log.

Intune

Wrap the package folder with the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) using MuonInsightSetup.exe as the setup file, then add it as a Windows app (Win32).

• Install command: MuonInsightSetup.exe /silent /org:"Organisation name"
• Uninstall command: MuonInsightSetup.exe /uninstall /silent
• Install behavior: System. Device restart behavior: No specific action.
• Return codes: add 6 as Retry. It means another setup or uninstall was still running after setup had waited ten minutes.
• Detection rules: manually configure the registry and file rules above; Intune requires all of them.

Nerdio, RMM tools and Group Policy

Add Invoke-MuonInsightSetup.ps1 as the script and point -SourcePath at the package folder on the share. These tools usually run a copy of the script from a temporary folder, so the default of the script’s own folder does not find setup. If the tool cannot pass parameters, set the defaults at the top of the copy you upload.

.\Invoke-MuonInsightSetup.ps1 -SourcePath '\\server\Apps\MuonInsight\0.26.0' -Organization 'Contoso'
.\Invoke-MuonInsightSetup.ps1 -Uninstall

The script exits with setup’s exit code, or 10 when it cannot find setup. For Nerdio, run the scripted action as SYSTEM on the session hosts or the image.

Logs

What setup does

Setup extracts the application into a staging folder, applies the repository bootstrap and organisation name, runs the packaged health check, swaps the staged copy into place, removes any earlier install at a different location, creates all-user shortcuts, and writes the detection registry key. A failed health check leaves the existing install untouched. Per-user preferences, reports, logs, and content cache are retained.

Supersedence and rollout

1. Deploy the new version to an IT development group as Available.
2. Validate launch, health check, repository sync, remote execution, and rollback.
3. Supersede the previous version without uninstalling it first; setup performs the local staged replacement.
4. Deploy to a representative pilot group.
5. Review installation failures and repository compliance.
6. Promote to production in phased required deployments.
7. Retain the previous package until the health window closes.

The executable version and the content snapshot are intentionally independent. An application rollout is needed only when a snapshot or module declares a minimum application version newer than the endpoint.

Repository sync compliance

Test-MuonInsightRepositorySync.ps1 reads the repository state file in every user profile on the device and reports whether each profile that has used the toolkit is current on the expected channel, and optionally on an exact snapshot during a controlled rollout.

Neither platform passes parameters to these scripts, and they read results differently, so edit the defaults at the top of the copy you upload: $ExpectedChannel, $ExpectedSnapshot, and $Platform.

SCCM ($Platform = 'ConfigMgr', the default). The script writes one word, Compliant or NonCompliant, and always exits 0, because Configuration Manager treats a non-zero exit as a script error rather than non-compliance.

1. Create a Configuration Item for Windows with a Script setting, data type String, and this script as the discovery script (Windows PowerShell).
2. Add a compliance rule: the value returned Equals Compliant, reporting non-compliance.
3. Add the Configuration Item to a Configuration Baseline and deploy it to the device collection. Results appear under Monitoring > Deployments and in the compliance reports.

Intune ($Platform = 'Intune'). The script writes the profiles that are not current as JSON, then a one-line summary, and exits 1 when any profile is not current. Add it as the detection script of a Remediations script package, run in 64-bit PowerShell as System; the summary line appears as the detection output. It makes no changes, so no remediation script is needed.

A device where no user has ever launched the application is reported as compliant, so report installation compliance and content-adoption compliance separately.

Share and NTFS permissions

Recommended access:

• Publishing administrators or release service identity: Modify.
• Domain computers and approved technician identities: Read and Execute.
• Everyone/Authenticated Users: no write permission.

Clients use the Windows identity launching the toolkit. Use a UNC/DFS path rather than a mapped drive, because elevated and standard sessions do not necessarily share drive mappings. Ensure the selected identity can read the repository when connected through the expected corporate network or VPN.

Rollback

For a configuration or module problem, activate the previous channel snapshot on the Administration page. No deployment action is required. For an executable problem, redeploy or supersede with the previous version. Do not delete the last known-good package or repository snapshot.