Adopting a fleet that already has software

This page holds the detail behind the trust page’s answer about software that is already on your fleet.

Adoption, one level of confidence at a time

Adoption brings a copy that is already installed under management without reinstalling it: Attestree subscribes the package, ties the existing install to it, and converges without a reinstall. Adopted copies count toward the package’s ring rollout, so day one is not a fleet-wide uninstall-and-reinstall of software that was already fine.

How a copy is recognised decides what you can do with it:

• By a product code. An MSI product code, or an Inno Setup or NSIS uninstall key confirmed by name and version, is collision-resistant. These copies can be adopted in bulk, or by the auto-adopt policy.
• By winget. A copy winget itself identifies by id and version, but that Attestree did not install, can be adopted one row at a time only.
• By name and version alone. This is a guess, and it is never offered for adoption, because acting on a guess here means removing something a person actually needs.

Adopting warns that a later managed update may reinstall the app. Un-adopting uninstalls nothing: the copy on the endpoint stays and simply leaves management. A package already healed forward stays managed through its own install record.

Software nobody deployed on purpose

There is usually more of it than anyone expects. Inventory has a fleet-wide filter that sorts every reported row against your catalog as match, drift or foreign. Foreign lists the software your catalog does not carry, with the endpoints carrying each one: the copies that arrived by browser download, a vendor updater, or an image you inherited.

One caveat: the filter matches by package id alone, so every plain uninstall entry counts as foreign, including hand-installed copies the endpoint’s own page recognises. It is not a count of purely unknown software.