1 26/10/2026 8 min

Su Linux, “disinstallare l’app Intune” non significa sempre la stessa cosa. In molti casi non esiste una vera applicazione desktop da rimuovere, ma un agente, un connettore MDM, un pacchetto aziendale o un’integrazione con Microsoft Defender for Endpoint e l’Enrollment Manager. Il primo passo è quindi capire che cosa è stato installato davvero, perché la procedura cambia parecchio tra Ubuntu, Debian, RHEL, SUSE e derivati.

Se l’obiettivo è togliere il dispositivo dalla gestione Intune, bisogna distinguere tra disinstallazione del client e retirement/unenroll del device. Se invece vuoi solo rimuovere il componente locale lasciando intatta la registrazione aziendale, la strada è diversa e può lasciare residui in `/etc/opt`, `/var/opt`, unità systemd o repository configurati dal vendor.

Capire cosa è stato installato

Prima di toccare qualsiasi cosa, verifica nome pacchetto, servizio e percorso dei file. Questa fase evita di disinstallare il componente sbagliato o di lasciare il sistema in uno stato incoerente.

Su sistemi Debian e Ubuntu, cerca i pacchetti con un nome riconducibile a Intune o Microsoft:

dpkg -l | grep -Ei 'intune|microsoft|mde|mdm|companyportal|endpoint'

Su RHEL, CentOS, Rocky o AlmaLinux usa il gestore nativo:

rpm -qa | grep -Ei 'intune|microsoft|mde|mdm|companyportal|endpoint'

Controlla anche i servizi systemd attivi o installati:

systemctl list-unit-files | grep -Ei 'intune|microsoft|mde|mdm|companyportal|endpoint'
systemctl list-units --type=service | grep -Ei 'intune|microsoft|mde|mdm|companyportal|endpoint'

Se trovi un servizio, annota il nome esatto dell’unità. È il riferimento più utile per capire come è stato integrato il componente e per fermarlo in modo pulito prima della rimozione.

Disinstallazione del pacchetto locale

Se Intune è arrivato come pacchetto installato localmente, la rimozione segue il normale flusso del package manager. L’obiettivo è eliminare il software senza cancellare subito dati o configurazioni, così da poter verificare lo stato del sistema prima della pulizia finale.

Su Debian e Ubuntu, prima verifica il nome esatto del pacchetto e poi rimuovilo:

apt-cache policy nome-pacchetto
sudo apt remove nome-pacchetto

Se il pacchetto è stato installato con dipendenze che non servono più, puoi valutare anche la rimozione completa delle configurazioni residue:

sudo apt purge nome-pacchetto
sudo apt autoremove --purge

Su RHEL e derivati:

sudo dnf remove nome-pacchetto

oppure, su sistemi più vecchi:

sudo yum remove nome-pacchetto

Blast radius: la rimozione del pacchetto può interrompere l’enrollment, la telemetria o eventuali policy di sicurezza applicate dal tenant aziendale. Rollback: conserva il nome esatto del pacchetto e la versione, così da reinstallarlo con lo stesso repository o con il file `.deb`/`.rpm` originale se necessario.

Fermare e disabilitare il servizio prima della rimozione

Se il componente gira come servizio, è buona pratica fermarlo prima di disinstallare. Così riduci il rischio di file in uso, hook incompleti o log confusi durante la verifica.

sudo systemctl stop nome-servizio
sudo systemctl disable nome-servizio
systemctl status nome-servizio --no-pager

Il controllo atteso è uno stato inactive o disabled. Se il servizio torna attivo da solo, potrebbe esserci un timer, un’unità socket o un agente di gestione superiore che lo rilancia. In quel caso controlla anche:

systemctl list-timers | grep -Ei 'intune|microsoft|mde|mdm|companyportal|endpoint'
systemctl list-unit-files | grep -Ei 'intune|microsoft|mde|mdm|companyportal|endpoint'

Se trovi un timer o una dipendenza indesiderata, disabilita anche quella. Non fare pulizie aggressive finché non hai capito chi riattiva il servizio.

Rimozione dell’enrollment dal tenant Intune

Se il dispositivo è registrato in Intune, la semplice disinstallazione del software locale non sempre basta. Il device può restare visibile nel portale come device managed, compliant o stale. In questi casi devi rimuovere anche la registrazione lato tenant, seguendo la procedura prevista dall’organizzazione.

Dal lato Linux, spesso la parte più utile è cercare file di enrollment e cartelle di stato. Percorsi tipici, se presenti, includono directory sotto `/etc/opt`, `/var/opt`, `/var/lib` e file specifici del vendor. Non dare per scontato il nome: controlla con una ricerca mirata.

sudo find /etc /var -maxdepth 4 \( -iname '*intune*' -o -iname '*microsoft*' -o -iname '*mdm*' \) 2>/dev/null

Se trovi un file di configurazione o di enrollment, leggilo prima di cancellarlo. L’obiettivo è capire se contiene solo riferimenti locali oppure token, endpoint, tenant ID o parametri sensibili da rimuovere con attenzione.

Se il tenant prevede una procedura di retire o wipe, esegui quella prima della rimozione locale. In un contesto aziendale, è il modo corretto per evitare che il dispositivo resti “orfano” nel portale e continui a comparire nelle assegnazioni di policy.

Pulizia dei residui locali

Dopo la disinstallazione, controlla se restano directory di configurazione, cache o log. La pulizia va fatta con criterio: prima verifica, poi rimozione selettiva. Non cancellare tutto a occhi chiusi se il sistema è gestito da strumenti di compliance o EDR che possono riutilizzare quei percorsi.

Le aree da ispezionare sono in genere queste:

  • /etc/opt per configurazioni persistenti
  • /var/opt per dati applicativi e stato
  • /var/lib per database locali o metadati
  • /var/log per log di enrollment o troubleshooting

Per capire cosa è rimasto, usa un elenco mirato:

sudo ls -la /etc/opt
sudo ls -la /var/opt
sudo ls -la /var/lib
sudo ls -la /var/log | grep -Ei 'intune|microsoft|mde|mdm|companyportal|endpoint'

Se trovi directory chiaramente legate al componente rimosso e non servono più, elimina solo quelle identificate. Prima fai un backup o uno snapshot del path se il sistema è in produzione o se la macchina è soggetta a audit.

Rollback: se hai cancellato per errore una directory utile, il ripristino dipende dal backup o dallo snapshot. Senza una copia precedente, non c’è un rollback affidabile sul contenuto locale.

Verifiche dopo la rimozione

Dopo aver rimosso il pacchetto e pulito i residui, verifica che non restino processi, servizi o repository attivi. Questo passaggio evita ritrovi successivi del componente dopo un aggiornamento o un reboot.

ps aux | grep -Ei 'intune|microsoft|mde|mdm|companyportal|endpoint' | grep -v grep
systemctl list-units --type=service | grep -Ei 'intune|microsoft|mde|mdm|companyportal|endpoint'

Se il sistema usa un repository Microsoft o un file di configurazione dedicato, controlla anche che non restino sorgenti inutilizzate:

ls -1 /etc/apt/sources.list.d/
ls -1 /etc/yum.repos.d/

Qui non devi rimuovere tutto in automatico: verifica prima il contenuto del file e assicurati che serva solo al componente disinstallato. Un repository condiviso con altri prodotti Microsoft potrebbe essere ancora necessario.

Se Intune è stato installato dentro un pacchetto più grande

In alcuni ambienti Linux, Intune non è un pacchetto autonomo ma una parte di una suite più ampia: onboarding per Microsoft Defender for Endpoint, connettori di gestione, script di bootstrap o profili aziendali installati da strumenti MDM terzi. In questi casi la disinstallazione “vera” va fatta sul componente madre, non sul singolo file binario.

Se trovi script di installazione in cron, in unità systemd o in configurazioni di provisioning cloud-init, rimuovi anche il meccanismo che potrebbe reinstallare automaticamente il componente al prossimo provisioning:

systemctl list-unit-files | grep -Ei 'provision|bootstrap|enroll|microsoft|intune'
crontab -l
sudo ls -la /etc/cron.*

Se il reinstall automatico è attivo, la disinstallazione locale durerà poco. In questo scenario, la vera correzione è intervenire sul profilo di gestione o sull’immagine di base usata per il provisioning.

Rimozione sicura in ambiente aziendale

In un contesto gestito, la disinstallazione va coordinata con chi controlla il tenant, la compliance e l’inventario. Il rischio non è solo tecnico: un device rimosso male può restare in stato ambiguo, perdere policy importanti o essere reinserito in modo incoerente al primo sync.

La sequenza più prudente è questa:

  1. Identificare il nome esatto del pacchetto o del servizio.
  2. Verificare se il device è ancora registrato nel tenant Intune.
  3. Eseguire il retire o la rimozione dal portale, se previsto.
  4. Fermare e disabilitare il servizio locale.
  5. Rimuovere il pacchetto con il package manager.
  6. Controllare residui in `/etc/opt`, `/var/opt`, `/var/lib` e repository.
  7. Riavviare solo se serve a verificare che non si riattivi nulla.

Questa sequenza riduce il blast radius: prima togli la gestione lato cloud, poi il componente locale, infine i residui. È il modo più pulito per evitare che l’agente si reincarni al primo aggiornamento o che il portale continui a mostrare un device mezzo rimosso e mezzo attivo.

Checklist rapida finale

Se vuoi una verifica minima ma sensata, controlla questi punti prima di considerare chiusa l’operazione:

  • dpkg -l o rpm -qa non mostrano più il pacchetto Intune-correlato.
  • systemctl status nome-servizio restituisce un servizio assente o inattivo.
  • Non ci sono unità, timer o cron job che lo reinstallano.
  • Le directory residue in `/etc/opt`, `/var/opt` e `/var/lib` sono state verificate prima della cancellazione.
  • Il portale Intune mostra il device ritirato o rimosso, se la procedura aziendale lo prevede.

Se uno di questi punti non torna, fermati lì: il problema non è la disinstallazione in sé, ma la persistenza del meccanismo di gestione. In quel caso conviene risalire al metodo di enrollment originale, perché è lì che si chiude davvero il ciclo.

Assunzione operativa: il sistema è Linux recente con systemd, e Intune è presente come pacchetto, servizio o componente di enrollment aziendale; il nome esatto del pacchetto/servizio va confermato prima della rimozione definitiva.