Content repository administration

Administrators publish enterprise configuration and modules to a protected content repository from the Administration page of Muon Insight. The deployment tool (SCCM, Intune, Nerdio or similar) remains responsible for installing and upgrading the application itself. Endpoints never execute modules from the share; they validate and copy a complete snapshot into their per-user local cache.

Who sees the Administration page

The page appears in the navigation only for accounts listed in security.administrators. An entry is a group or user written as DOMAIN\name, a bare name, or a SID. DOMAIN\name or a SID is the precise form; a bare name matches that name in any domain. Membership is read from the Windows logon token, so a group change takes effect the next time the person signs in.

The list can only come from packaged defaults or enterprise configuration: the installed config\enterprise.json until a snapshot is published, and the published configuration after that. A computer’s machine.json or a technician’s preferences cannot add anyone, whether or not the setting is marked Locked.

The list decides who sees the page, not who can publish. Technicians run the toolkit as local administrators and could change files on their own computer, so two controls do the real work:

• Share permissions. Only the publishing group has write access to the repository. Anyone else who reaches the page can review it, but connecting, importing and publishing fail with an explanation.
• Snapshot signing. With updates.require_signatures enabled, endpoints accept only snapshots signed by a pinned publisher certificate, so write access alone cannot push content.

First setup

Before the first snapshot exists, nobody’s list comes from the repository. Put the first administrators in the site’s config\enterprise.json before building, for example:

{
  "security": {
    "administrators": ["EXAMPLE\\Muon Insight Administrators"]
  }
}

After publishing, manage the list on the Configuration tab like any other setting. A published list replaces the installed one, so keep at least one working entry in it.

How a computer finds its repository

Each computer reads, in order of precedence:

1. Group Policy: the Content repository policy under Computer Configuration > Administrative Templates > Muonix Labs > Muon Insight, written to HKLM\SOFTWARE\Policies\MuonixLabs\MuonInsight. The template is in deployment/GroupPolicy. Enabled sets the repository path and channel; Disabled turns synchronization off.
2. config\repositories.json in the installation folder, which setup writes from a repositories.json placed beside it in the deployment package.

Group Policy is the way to change a repository or channel without reinstalling, for example to move a set of computers to the pilot channel. Only administrators and policy processing can write that key; restrict who can edit the Group Policy object as tightly as the share itself. Published content can change neither source: a snapshot able to repoint computers could strand all of them on a share nobody controls.

The Administration page shows which repository this computer follows and whether Group Policy or repositories.json set it. Module Updates under Settings shows the same for every technician.

Create the repository

1. Create a stable DFS or UNC location, for example \\example.com\SupportApps\MuonInsight.
2. Grant endpoint and technician identities read access.
3. Grant write/change access only to the small publishing group.
4. Open Administration in Muon Insight.
5. Enter the UNC path, select development, and choose Connect or create.
6. Choose Import all packaged modules to seed the repository from the matching application build.
7. Review the Configuration tab, validate it, and publish the first development snapshot.
8. Point computers at the repository: set the Group Policy, or export repositories.json with Export client bootstrap and place it beside MuonInsightSetup.exe in the deployment package.

The exported bootstrap allows up to 60 seconds for synchronization. The check returns immediately when the channel is current; the longer ceiling accommodates first-run DFS referral, antivirus inspection, and initial population of the complete local module cache.

Use a stable DFS namespace, so the share behind it can move without changing any computer.

Configuration editor

The editor starts with every packaged default and enterprise value. Double-click a value to edit it. Lists use JSON array syntax, such as ["Field Support", "Service Desk"]. Check Locked when a machine setting or technician preference must not override that value.

The editor validates the complete result against config.schema.json. Publication is blocked until all values are valid. The published file contains a complete configuration, not a partial fragment. Credentials must never be entered in configuration; store them using the integration’s approved credential provider.

Module intake

Choose Import module folder or ZIP. Intake performs schema, path, file-count, size, entry-point, semantic-version, application-version, Python syntax, transport, and prohibited executable checks. Modules are copied to an immutable modules/<id>/<version> directory. Reusing the same ID and version with different content is rejected.

An automated compatibility result is not a security approval. Before production:

1. Review all PowerShell or Python source.
2. Run the test suite and scripts/audit_remote_modules.ps1.
3. Exercise local and remote branches using representative delegated credentials.
4. Publish to development and then pilot.
5. Promote only after findings, cancellation, confirmation, and rollback behavior have been verified.

Publishing and rollback

Publication writes immutable content first and atomically replaces only the selected channel pointer. A snapshot contains the complete enterprise configuration and the latest compatible version of every module in the repository.

Channels are independent:

• development: administrator and module-author testing;
• pilot: representative field technicians and devices;
• production: approved general deployment.

The History tab lists snapshots for the selected channel. Activate selected snapshot repoints the channel to a previous immutable snapshot; clients activate it on their next successful startup sync. Do not edit files inside an already published module or snapshot.

What the repository status shows

The Repository status tab reports publication state: share accessibility, active snapshot, configuration version, module inventory, validation, and history. It does not claim that every endpoint has synchronized. Use deployment/Test-MuonInsightRepositorySync.ps1 through SCCM or Intune to inventory per-user client state without granting clients write access to the content share.

Client behavior

At normal startup, an enabled client launches a bounded synchronization subprocess. The client:

1. reads the selected channel pointer;
2. validates the snapshot-manifest hash;
3. validates configuration and every module file hash;
4. enforces minimum application versions;
5. stages and validates the complete module set;
6. atomically activates the snapshot state file; and
7. loads configuration and modules from the local snapshot.

If the share is unavailable or validation fails, startup continues with the last known-good snapshot. The Module Updates page shows the repository, channel, active snapshot, last check, and error.

Sign published content

Per-file SHA-256 detects corruption and partial copies. It cannot tell a legitimate publisher from anyone else able to write to the share, because an attacker who replaces the manifest simply recomputes the hashes. Signing closes that gap.

1. Obtain a code-signing certificate for the publishing identity and install it, with its private key, into Cert:\CurrentUser\My on the publishing workstation.
2. Copy its thumbprint into Signing certificate on the Repository status tab. Snapshots published from then on carry a detached snapshot.json.p7s alongside the manifest.
3. In the enterprise configuration, set updates.require_signatures to true and add the same thumbprint to security.trusted_publishers.

Endpoints then refuse any snapshot that is unsigned, altered after signing, or signed by a certificate outside that list. Trust is the pinned thumbprint, not a certificate chain, so a certificate authority issuing another code-signing certificate does not become a trusted publisher.

Roll the order out in the right sequence. Publish a signed snapshot before enabling require_signatures, or endpoints will reject the current content and hold their last known-good snapshot. Because signatures are not timestamped, re-sign and republish before the publishing certificate expires.

The trust policy is read only from configuration installed on the endpoint by the deployment tool. It is deliberately not read from the synchronized snapshot — content cannot be allowed to switch off its own verification — nor from user preferences, so a technician cannot opt out.