Distribuire applicazioni su dispositivi Windows gestiti da Microsoft Intune significa scegliere il tipo di pacchetto corretto per ogni scenario. Un amministratore endpoint deve saper decidere quando usare un’app Win32, quando basta un’app dello store e quando serve un pacchetto LOB (line-of-business), oltre a governare correttamente detection, requirements e dipendenze.

Il formato .intunewin e le app Win32

Le app Win32 sono il tipo più flessibile: gestiscono installer complessi (EXE, MSI, script) con logica di rilevamento e disinstallazione personalizzata. Prima del caricamento, i sorgenti vengono impacchettati con il Microsoft Win32 Content Prep Tool in un file .intunewin cifrato, che contiene il payload e i metadati.

In fase di creazione dell’app definisci:

  • Install/uninstall command: la riga di comando effettiva (es. setup.exe /quiet o msiexec /i app.msi /qn).
  • Install behavior: System (contesto SYSTEM, nessun utente richiesto) o User (contesto dell’utente loggato). Per la maggior parte delle app aziendali si usa System.
  • Return codes: la mappatura dei codici (0, 3010 = soft reboot, ecc.) che determina successo, fallimento o riavvio.

Detection rules

Le detection rule dicono a Intune se l’app è già installata, evitando reinstallazioni inutili. Sono la parte più critica del packaging Win32. Puoi usare:

  • MSI: rilevamento automatico tramite il product code dell’MSI. Semplice e affidabile per installer MSI puri.
  • File: presenza di un file/cartella, con verifica opzionale di versione o data.
  • Registry: presenza di una chiave/valore, con confronto su versione, stringa o intero.
  • Custom script (PowerShell): massima flessibilità. La logica deve scrivere STDOUT ed exit code 0 per segnalare “installato”; nessun output = “non installato”.

La detection deve puntare a un artefatto che esiste solo dopo un’installazione riuscita e che riflette la versione corretta.

Requirements, dependencies e supersedence

  • I requirements (OS minimo, architettura, spazio disco, o script custom) determinano se l’app è applicabile al dispositivo. Se non soddisfatti, l’app resta in stato “not applicable” e non viene installata.
  • Le dependencies impongono un ordine: Intune installa prima le app prerequisite (con opzione auto-install) e solo dopo l’app principale. Utile per runtime e librerie condivise.
  • La supersedence gestisce aggiornamenti e sostituzioni: una nuova app può aggiornare (senza disinstallare) o sostituire (disinstallando la precedente) una versione più vecchia. Consente catene di update controllate, ma va progettata con detection coerenti per non generare loop.

Store app, winget e LOB

  • App dello store (nuovo Microsoft Store): Intune integra il catalogo tramite winget. Non serve impacchettare né gestire detection: l’aggiornamento è delegato allo store. Scelta ideale per app pubbliche standard (browser, tool comuni) quando non serve personalizzazione.
  • App LOB: caricamento diretto di un singolo installer (.msi, .appx/.msix, ecc.) senza wrapping .intunewin. Semplici ma con logica limitata (niente detection/requirements custom, niente dependencies). Adatte a MSI/MSIX lineari.
  • Win32: da preferire quando servono comandi custom, detection complesse, dependencies o supersedence.

Assignment e Company Portal

Le app si assegnano a gruppi con tre intent:

  • Required: installazione forzata e automatica sui dispositivi/utenti del gruppo.
  • Available for enrolled devices: l’app compare nella Company Portal, dove l’utente sceglie se installarla on-demand.
  • Uninstall: rimozione forzata dai target.

La Company Portal (app o web) è il self-service store aziendale: mostra le app available, avvia installazioni, e riflette lo stato (installata, in corso, fallita) che deriva proprio dalle detection rule. Le app required invece non richiedono interazione. Nota: le app available possono essere assegnate solo a gruppi di utenti, non di dispositivi.

Trappole tipiche d’esame

  • L’app si reinstalla a ogni check-in (loop) → la detection rule non rileva l’installazione riuscita (percorso/chiave sbagliati o versione non corrispondente): correggi la detection, non l’installer.
  • Installazione riuscita ma Intune la segna “failed” → falso negativo della detection (es. script che non emette STDOUT+exit 0): verifica la logica di rilevamento.
  • Serve pubblicare Chrome/Edge senza mantenere pacchetti → usa un’app store via winget, non un Win32.
  • App con prerequisito da installare prima → usa una dependency con auto-install, non due assegnazioni separate.
  • Aggiornare una versione senza disinstallare la precedente → configura la supersedence in modalità update, con detection allineata alla nuova versione.
  • Rendere un’app scaricabile on-demand dagli utenti → assegnala come Available a un gruppo utenti; comparirà nella Company Portal.