The Windows package enrols by itself

Open a group, press Create deployment token under Windows - MSI for software distribution, and what you copy is this:

msiexec /i wegweiser-agent-windows-amd64.msi TOKEN=<token> SERVER=app.wegweiser.tech /qn /norestart

That is a complete install. The package lays down the files, registers the device with your server using the token, installs the Windows service and starts it. The MSI itself is downloaded once from your server's download link and handed to whatever pushes software in your estate: Symantec, Intune, a group policy, or the image you build machines from.

What changed

Until now the Windows install was a PowerShell block: download the MSI, run it, call the registration tool, install the service, start it. The block worked, and it is still there, but it assumed a person with an elevated prompt on the machine. A distribution system does not have one of those. It has a package and a command line, and everything it cannot express as those two things becomes a script it has to carry, sign and maintain.

So the enrolment moved into the package. When the MSI is given TOKEN= and SERVER=, an action runs at the end of the install, as SYSTEM, and does the three steps the script used to do. Without those two properties the package behaves exactly as it always has, files only, which is what the agent's own self-update relies on.

The two PowerShell commands in the console now pass the same properties and keep their old steps as a fallback, so they keep working against a server whose package predates this release.

When things go wrong

A wrong or expired token fails the install. The package returns exit code 1603 and rolls its files back, so your distribution system shows a failure rather than a green tick over a machine that never enrolled. The reason is written to C:\ProgramData\Wegweiser\enroll.log, the one file a deployment admin can read without knowing anything else about the product.

Running the package again on a machine that is already enrolled is harmless. It keeps the device identity, spends no token, and makes sure the service is installed and running. Distribution systems re-push packages; a re-push must never create a second device.

The token does not appear in the msiexec log, even a verbose one, so the log can be shared.

Two kinds of token

The command a person copies for one machine still embeds a single-use token that expires after fifteen minutes, and that is deliberate: a token that leaks from a script or a ticket should be worthless by the time anyone finds it. For a distribution system pushing to fifty machines over a week, single-use and fifteen minutes is the wrong shape, so the MSI block mints a different kind.

A deployment token can enrol many machines. It expires, thirty days by default, and you can choose a week, a quarter, a year, or, as an explicit choice the panel asks you to make, never. It can be capped at a number of enrolments. It can be revoked from the group page at any time, and every enrolment made with it is listed under it: the device name, the address it came from and the time. Machines already enrolled are unaffected by a revocation; the token simply stops enrolling new ones.

Revocation and the use log are what make a long-lived token acceptable to a security reviewer; the expiry date is there to bound an incident that nobody noticed. Golden images get rebuilt for patches at least monthly anyway, so a thirty-day token is a step that already exists in that process. If you bake a token into an image, make it a deployment token, and give it a label that says which image, so the list under it reads as an inventory of what that image built.

What this was tested on

Two Windows Server 2022 machines. One was already enrolled and took the new package with a token on the command line: it upgraded in place, kept its identity, and the token was never spent. The other was wiped, refused with a bad token (1603, files rolled back, the reason in enroll.log), then enrolled cleanly with a good one and appeared in the console under its group with the service running. The deployment token was proved the same way: one token enrolled both machines through the package, the panel listed both under it, a wiped machine was refused with 1603 after the token was revoked, and a token capped at one enrolment showed as exhausted after it.