Our university has roughly 70 Linux desktops used mainly by academics in the Engineering and Science departments. These machines were previously maintained by local IT teams that no longer exist, so their current patching, configuration, and security status is largely unknown. Most are running Ubuntu LTS, primarily versions 20.04 and 22.04, but we have limited physical access to many of the rooms.
We already manage research computing, and I've been asked to build a proof of concept for bringing these desktops into a centrally managed state. The central endpoint team does not support Linux, so I'm evaluating Landscape for provisioning 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 for discovery, patching, configuration, security monitoring, and eventually reinstalling or replacing machines?
4 Answers
There are several products that can provide parts of this, including FleetDM, Uyuni or SUSE Multi-Linux Manager, commercial RMM tools, and Ubuntu Landscape. The important question is which one covers your actual requirements without adding another disconnected console.
Since you already know Ubuntu and are considering Ansible, Landscape plus Ansible is probably the simplest starting point. Add a separate monitoring or security product only where it fills a specific gap. Before choosing anything, test deployment on both a cooperative machine and a badly maintained one, and make sure the process can discover, remediate, or clearly quarantine systems that are too far out of compliance.
The general direction is reasonable, but I’d treat these more like servers with a desktop workload than like conventional MDM-managed endpoints. Start with inventory and a minimum baseline: supported Ubuntu releases, disk encryption status, local administrators, update state, logging, backups, and basic hardware health.
Landscape can handle Ubuntu-specific patching and fleet visibility, while Ansible or Puppet can enforce configuration. A pull-based configuration model is useful when machines are intermittently connected. For new or rebuilt systems, automated installation through PXE or another imaging process will make recovery much easier. Central logging, vulnerability reporting, monitoring, and identity integration are also worth including from the beginning.
For a Linux-heavy fleet, a server-style operating model works well: a small package or role establishes the baseline, Ansible applies more complicated configuration, and changes are kept in version control with review and rollback. Send logs to the existing logging and SIEM infrastructure, use centralized authentication with limited group access, and monitor the machines with an encrypted monitoring agent.
For new installations, an immutable or image-based Linux approach can reduce configuration drift, but it probably isn’t worth forcing onto all of the existing desktops immediately. Use it for new deployments and rebuilds while gradually retiring the unknown systems.
Build-time configuration is attractive for fresh machines, but converting an existing fleet that has years of academic software and custom setups can consume more staff time than it saves. I’d make that the long-term direction rather than the first migration step.
Be careful about thinking of this as Linux MDM. If users have unrestricted sudo or root access, they can disable agents, alter configuration, or bypass compliance checks. The goal should be honest visibility and a defensible baseline rather than pretending the controls are tamper-proof.
For machines that handle sensitive work, prioritize full-disk encryption, secure boot where practical, supported releases, centralized authentication, audit and system logs, endpoint telemetry, and a documented break-glass process. If a device cannot be validated or remediated remotely, the safest answer may be to replace or wipe it rather than spend unlimited time trying to trust it.
In our environment, reporting encryption status and hardware information is more valuable than trying to block every action by a privileged user. It’s a reasonable balance when the users need Linux for legitimate technical work.
That approach also makes it easier to separate the unknown legacy machines from the clean baseline. I’d avoid trying to make the first configuration perfect before getting reliable inventory and a supported rebuild path.