Installing DPLens on one machine is a double-click. Installing it on a thousand is a decision about where the configuration, the licence and the secrets come from — and about which tool carries the package to the machines.
The short version
Configure one machine. Capture it into a deployment MSI with dp-deploy. Hand that MSI to whatever already installs software on your machines, or let dp-deploy push it to a list of hosts itself. See The deployment MSI, or let the wizard take you through it.
Choosing
| Your situation | Use |
|---|---|
| A handful of machines, scripted | Silent installation with properties on the command line |
| A fleet — with or without secrets, domain or not | The deployment MSI, delivered by one of the routes below |
| … installed by Group Policy | Group Policy |
| … installed by Intune, Configuration Manager, an RMM, or built from a cloud image | Intune, Configuration Manager, RMM and cloud images |
| … installed or updated from your workstation, no management tool | Pushing to hosts |
| A configuration with no secrets, deployed by Group Policy with a transform and no key to deliver | The transform bundle |
| A golden image or VDI template | Golden images and VDI clones |
| Not sure | The deployment wizard asks, then does it |
Every route installs the same signed package. The difference is what the package carries and how it reaches the machine.
The problem with secrets
A configuration file never contains a secret value — it contains a handle, and the value lives in the machine's sealed store. That is what makes one file safe to put on every machine.
It also means the values have to arrive some other way, and that is the main thing the deployment MSI solves. It carries the secret values encrypted, under a deployment key that is shown to you once at capture and never stored by the tool or the package. The package can sit anywhere; the key must arrive on each machine by a path only administrators can read, and the installer checks that it did, uses it, and deletes it.
| Route | How secrets arrive | Trade-off |
|---|---|---|
| Deployment MSI | Encrypted inside the package; the key by an administrators-only path | One package for everything. You have to get one line of text — the key — onto each machine correctly, and the tool checks that you did. |
| Transform bundle | They do not. The configuration must refer to no secrets. | Simplest possible Group Policy deployment. Only for secret-free configurations. |
| Silent install | On the msiexec command line, as hidden properties | Fine for a script on a few machines. Not for a policy object or a package on a share. |
Earlier preview releases offered a Group Policy startup script that fetched secret values from your own vault at boot. That recipe is withdrawn: the deployment MSI replaces it for every estate, domain-joined or not.
Licences across a fleet
A machine-bound key licenses one machine. A domain-bound key licenses every machine joined to the domain, which is what makes fleet deployment practical: one key, valid everywhere.
The deployment MSI can carry several keys — a domain key and machine keys for the odd host outside it — and each machine keeps the one that binds it. See Licensing.
A domain key is also the only kind that survives cloning. See Golden images and VDI clones.
A sensible order
- Configure one machine the way you want it, using the console, and let it run until you are satisfied with what arrives at your destination.
- Capture it —
dp-deploy capture— and put the deployment key in your secrets manager. - Build the package —
dp-deploy build-msi— with your licence keys, and sign it. - Deploy to a pilot group — enough machines to be representative, few enough to fix by hand. A push with a canary batch is built for this.
- Check the pilot: healthy sources, delivery arriving, nothing unexpectedly dropped,
deploy.jsonon each machine naming your bundle. - Roll out.
What every machine ends up with
However you deploy, each machine gets the same thing: the executable, the service, the folders with their permissions, your configuration, and — if you supplied them — the certificates, the secrets, the console password and the licence.
Machine-specific state such as collection positions and the agent's own identity is created on the machine, not copied to it.
Upgrading a fleet
Deploy the newer package the same way you deployed the first. An upgrade keeps configuration, licence, secrets and collection positions; a newer deployment MSI also applies its own capture. See Upgrading and uninstalling.
Downgrades are refused, so a rollback of the version means uninstalling first — worth knowing before you need it. A rollback of the configuration is a push of the previous bundle.