Creare applicazioni Win32 con Patch My PC in Intune

Creare applicazioni Win32 con Patch My PC in Intune conviene quando vuoi ridurre il tempo speso a impacchettare software, mantenere coerenza tra ambienti e tenere sotto controllo installazione, aggiornamento e disinstallazione senza inseguire ogni singolo installer a mano. Il punto non è “fare tutto da Intune”: il punto è usare Patch My PC come strato operativo per trasformare applicazioni tradizionali in distribuzioni più governabili, con logica standard, detection affidabile e manutenzione meno fragile.

La differenza pratica rispetto al packaging manuale è semplice: invece di costruire da zero ogni profilo Win32, definisci il comportamento dell’app nel catalogo Patch My PC e lasci che il flusso generi gran parte della struttura necessaria per Intune. Questo non elimina il lavoro tecnico, ma lo sposta su decisioni che contano davvero: prerequisiti, parametri silenziosi, regole di rilevamento, dipendenze, supersedence e finestra di aggiornamento.

Quando ha senso usare Patch My PC con Intune

Ha senso soprattutto in tre scenari. Primo: hai molte applicazioni standard da distribuire su parco endpoint eterogeneo e vuoi una base uniforme. Secondo: devi gestire aggiornamenti frequenti e non vuoi rifare ogni volta il ciclo di packaging, test e pubblicazione. Terzo: vuoi ridurre gli errori umani nei dettagli ricorrenti, come detection sbagliate, comandi di installazione incoerenti o icone mancanti.

Non è invece la scelta giusta se l’applicazione è molto custom, richiede trasformazioni particolari, o se il vendor cambia spesso comportamento senza documentazione affidabile. In quei casi conviene tenere il controllo manuale del pacchetto e usare Patch My PC solo dove il catalogo e le regole supportate coprono davvero il caso d’uso.

Prerequisiti minimi prima di partire

Prima di creare la prima applicazione, conviene verificare quattro aspetti: l’integrazione tra Patch My PC e Intune, i permessi dell’account che pubblica, la strategia di naming e il modello di gruppi di assegnazione. Se uno di questi pezzi è lasciato “alla buona”, il risultato è quasi sempre una libreria di app difficile da mantenere.

In pratica, controlla che l’ambiente sia già pronto per il flusso di pubblicazione, che l’account abbia diritti sufficienti sulla tenant e che tu abbia deciso prima come distinguere versioni, canali e ambienti. Se non lo fai, finisci con nomi simili, supersedence poco leggibile e distribuzioni che diventano opache già dopo pochi mesi.

Se ti manca un dato tecnico del tenant o del connettore, non inventarlo: verifica nel portale Intune o nel pannello Patch My PC la sezione di integrazione e annota i campi effettivi, perché l’esperienza cambia in base alla licenza, al prodotto e alla modalità di pubblicazione attiva.

Flusso operativo: dal catalogo alla Win32 app

Il flusso reale è meno “magico” di quanto sembri. In genere selezioni l’app nel catalogo Patch My PC, definisci le opzioni di packaging e poi pubblichi verso Intune come app Win32. Da lì in poi Intune gestisce la distribuzione agli endpoint secondo assegnazioni e policy, mentre Patch My PC si occupa della parte di preparazione e aggiornamento del contenuto.

Il vantaggio operativo è che la struttura dell’app tende a essere più consistente tra un rilascio e l’altro. Il rischio, però, è credere che ogni applicazione sia automaticamente “giusta” solo perché pubblicata con un tool affidabile. No: detection, exit code e silent install restano punti da validare sempre, perché sono loro a determinare se Intune vede davvero l’installazione come riuscita.

Qui sotto c’è il tipo di attenzione che fa risparmiare ore dopo il rollout: controllare il comando di installazione effettivo, il comportamento in silent mode e la regola di detection con almeno un test su macchina pilota. Se l’app si installa ma Intune non la rileva, il problema non è “Intune che non funziona”: è quasi sempre una detection troppo debole o troppo specifica.

Scelte che fanno la differenza nel packaging Win32

La parte più importante non è caricare il file, ma definire il comportamento dell’app in modo che sia stabile nel tempo. Le quattro decisioni che impattano di più sono: silent install, detection, uninstall e requisiti di sistema. Se una di queste è fragile, l’app funzionerà “a tratti”, cioè solo su alcune macchine o solo per alcune versioni.

Per i comandi di installazione, preferisci sempre il parametro realmente supportato dal vendor e non quello “che sembra andare”. Un installer che si completa ma mostra dialog nascosti o lascia processi figli aperti crea problemi di timeout e di stato finale ambiguo. Meglio un test su endpoint pulito con log locale che una pubblicazione fatta in fretta.

Per la detection, la regola è banale ma spesso ignorata: deve identificare in modo univoco la presenza dell’app senza dipendere da dettagli troppo variabili. Se usi file version, product code o chiavi di registro, verifica che il criterio sopravviva anche agli aggiornamenti successivi. Se la detection cambia a ogni release, ogni upgrade diventa una scommessa.

Per la disinstallazione, tieni separati i casi “rimozione pulita” e “rollback di emergenza”. Un uninstall che lascia residui può essere accettabile in certi software, ma va dichiarato e monitorato. Se invece l’app è sensibile alla pulizia completa, devi sapere in anticipo quali cartelle, servizi o chiavi di registro restano sul sistema.

Assegnazioni, gruppi e blast radius

Il modo più rapido per trasformare un buon pacchetto in un incidente è assegnarlo troppo in fretta a un gruppo grande. La regola pratica è partire con un gruppo pilota piccolo, idealmente composto da macchine rappresentative e non da dispositivi “fortunati” sempre aggiornati. Solo dopo aver verificato installazione, detection e impatto utente ha senso allargare.

Il blast radius, qui, non è solo tecnico: è anche operativo. Se distribuisci una versione difettosa a un gruppo largo, il rollback non è sempre immediato, soprattutto quando l’app è già stata rilevata come installata da Intune. Per questo conviene avere una strategia di ripristino prima della pubblicazione: supersedence corretta, gruppo escluso pronto e, se serve, una versione precedente già disponibile.

Un buon approccio è separare i gruppi per funzione: test, pilot, broad. Non serve complicare il modello, basta che sia leggibile. Se dopo tre mesi non sai più perché un dispositivo è in un gruppo e non in un altro, il problema non è Intune: è la governance dei gruppi.

Supersedence e aggiornamenti: il punto dove molti si inceppano

Con Win32 in Intune, l’aggiornamento non è solo “pubblicare una nuova versione”. Devi decidere se la nuova app sostituisce la precedente, come viene trattata la versione vecchia e se la migrazione dell’endpoint deve essere trasparente o forzata. Patch My PC aiuta molto qui, perché rende più ordinato il ciclo di aggiornamento, ma non elimina la necessità di una policy chiara.

Se usi supersedence, controlla sempre che la nuova versione sia davvero rilevata come successore della precedente e che il comportamento di uninstall sia quello atteso. Un errore comune è pubblicare la nuova app e dimenticare che la detection della vecchia continua a essere valida, con il risultato di vedere coesistenza apparente o stato non coerente nel portale.

Qui conviene ragionare come in un change controllato: prima test, poi osservazione, poi estensione. La metrica utile non è solo “ha installato”, ma anche “quanti endpoint hanno completato l’upgrade senza errori”, “quanti sono rimasti in pending” e “quanti hanno richiesto intervento manuale”. Se non misuri questo, stai navigando a vista.

Verifiche pratiche su un endpoint pilota

Prima di fidarti della pubblicazione, fai sempre almeno una verifica locale. Su Windows, i log di Intune Management Extension sono il primo posto da guardare quando l’installazione non torna. Il percorso tipico è il seguente:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

Nel log cerchi tre cose: il comando eseguito, il codice di uscita e il risultato della detection. Se il pacchetto parte ma la detection fallisce, il problema è quasi sempre nella regola di rilevamento. Se invece il pacchetto non parte, controlla parametri, prerequisiti e compatibilità architetturale.

Se vuoi un controllo rapido lato sistema, puoi verificare anche l’installazione locale dell’app, i servizi eventualmente creati e la presenza di file o chiavi note. Non serve un audit complesso per il primo giro: basta confermare che il comportamento osservato corrisponda a quello dichiarato dal pacchetto.

Errori tipici da evitare

Il primo errore è dare per scontato che il catalogo equivalga a compatibilità assoluta. In realtà ogni app va letta come un caso a sé: alcuni installer sono lineari, altri hanno prerequisiti, riavvii impliciti o componenti secondarie che complicano tutto. Il secondo errore è pubblicare senza naming coerente: quando le app crescono, i nomi diventano la tua prima forma di documentazione.

Il terzo errore è non distinguere tra installazione riuscita e stato desiderato raggiunto. Intune può vedere un’app come installata mentre, lato utente, mancano componenti o l’app non si avvia correttamente. Per questo non basta la spunta verde nel portale: serve almeno un controllo funzionale minimo dopo il deployment.

Un altro punto debole è il reporting preso alla leggera. Se non definisci in anticipo quali esiti ti interessano, finisci per leggere solo gli errori evidenti e ignorare i casi ambigui. È lì che si nascondono i problemi veri: installazioni parziali, detection intermittente, riavvii differiti, versioni vecchie ancora presenti.

Un modello operativo semplice che regge nel tempo

Se vuoi una linea pratica che funziona, tieni questo schema: catalogo selezionato con criterio, test su endpoint pilota, detection verificata, assegnazione progressiva, monitoraggio dei log e rollback già pronto. Non serve complicare oltre. La qualità del risultato dipende molto più dalla disciplina del processo che dal numero di opzioni abilitate.

Per ambienti con più team, conviene anche documentare chi può pubblicare cosa e con quale frequenza. Le app “semplici” spesso diventano critiche perché nessuno si sente responsabile del ciclo di vita. Un flusso chiaro evita che patch e upgrade si accumulino fino a diventare un blocco unico ingestibile.

In sintesi operativa: Patch My PC in Intune è utile quando vuoi standardizzare il packaging Win32 senza perdere controllo tecnico. Funziona bene se tratti ogni app come un oggetto da validare, non come un clic da completare. Se curi detection, gruppi, rollback e osservabilità, il vantaggio è concreto: meno manutenzione ripetitiva e meno sorprese in produzione.

Checklist finale prima del rollout

Prima di andare in broad, verifica almeno questi punti: comando di installazione testato, regola di detection stabile, percorso di uninstall definito, gruppo pilota funzionante, log Intune puliti e piano di rollback disponibile. Se uno di questi manca, non sei pronto a scalare.

Assunzione: il lettore ha già accesso amministrativo a Intune e a Patch My PC, e vuole pubblicare applicazioni Win32 con un processo ripetibile, osservabile e reversibile.