After several rounds of restructuring at our university, roughly 70 Linux desktops used by academics in the Engineering and Science departments are currently unmanaged. They were previously maintained by local IT teams that no longer exist, and we have little visibility into their patch levels, configuration, or even their current physical locations.
Our research-computing team has been asked to build a proof of concept for bringing them under management. Most systems appear to be running Ubuntu LTS, mainly 20.04 and 22.04. I'm considering Ubuntu Landscape for inventory and patching, Intune for compliance reporting, and Puppet or Ansible for configuration management.
Does that sound like a sensible architecture, or are there simpler or more cost-effective approaches?
4 Answers
Landscape together with Ubuntu Pro and Ansible or Puppet is a reasonable, relatively straightforward approach—especially if your team already knows those tools. I’d keep the responsibilities clear: use Landscape for inventory, patching, and Ubuntu-specific management, then use Ansible for configuration and hardening. Adding several overlapping management platforms may create more operational work than value.
Be careful about assuming that Linux can be managed like a locked-down corporate laptop. If academic users retain unrestricted sudo or root access, they can disable or bypass almost any agent and configuration policy. In that situation, frame the tooling as visibility, patching, encryption verification, and access control rather than absolute enforcement.
Start by deciding what you actually need to prove: disk encryption, supported OS versions, recent security updates, hardware health, and access to institutional services. For users who need a highly customized environment, centralized Linux systems or remote compute hosts may be easier to secure than allowing every desktop to become its own unsupported platform.
There are dedicated Linux-capable endpoint and RMM products that can handle inventory, patching, scripts, and vulnerability reporting, and some have free tiers for smaller fleets. They may be worth evaluating alongside Landscape. However, avoid choosing a product solely because it advertises Linux support—check whether it supports your Ubuntu releases, offline or intermittently connected machines, compliance reporting, remote recovery, and the amount of administrative access its agent requires.
A sensible proof of concept would compare one integrated Ubuntu-focused stack with one independent RMM plus Ansible. Test both on a handful of representative desktops before committing to the whole fleet.
Treat these more like servers with a desktop workload than like conventional mobile-device-managed endpoints. A solid baseline could include a standard package or configuration role, centralized authentication, encrypted logging, monitoring, vulnerability reporting, backups for important user data, and a repeatable reinstall process using network boot or imaging. Keep the configuration in version control and make changes through reviewed, auditable automation.
For new or rebuilt machines, a pull-based configuration model is useful because it lets systems recover after being offline. You should also define what happens when a machine cannot be brought to a known state—often the safest answer is to reimage it rather than trying to repair an unknown configuration.
A centralized rebuild process may be more valuable than trying to perfect remote management. If a desktop can be reinstalled quickly and consistently, unknown or compromised systems become much less difficult to deal with.
That level of trust can still be practical when the goal is monitoring rather than preventing every change. Privileged users can bypass controls, but reporting encryption status, hardware information, and agent health may be sufficient for the risk you are trying to manage.