Distribuire GitHub Desktop con Intune e SCCM

Distribuire GitHub Desktop con Intune e SCCM: cosa conviene fare davvero

GitHub Desktop è un client piuttosto semplice da distribuire, ma in ambiente aziendale il punto non è tanto installarlo quanto farlo in modo ripetibile: rilevazione corretta della presenza, aggiornamenti gestibili, disinstallazione pulita e nessuna sorpresa sui profili utente. Con Intune e SCCM il nodo principale è quasi sempre lo stesso: il pacchetto deve essere costruito pensando a come il software si presenta nel sistema, non solo a come si lancia il setup.

La scelta pratica è questa: se gestisci endpoint moderni e vuoi una distribuzione cloud-first, Intune è la strada più lineare. Se hai ancora una base forte di client on-prem e vuoi controllare meglio collezioni, maintenance window e reporting locale, SCCM resta perfettamente sensato. In molti casi la soluzione migliore è preparare un solo artefatto installativo ben fatto e poi adattare solo il metodo di delivery.

Prerequisiti: verifica il pacchetto e il comportamento dell’installer

Prima di creare una Win32 app in Intune o un Application in SCCM, conviene capire che tipo di installer hai tra le mani. GitHub Desktop per Windows viene distribuito normalmente come installer per utente o per macchina, e il dettaglio cambia parecchio il modo in cui scrivi detection e comandi di installazione.

Il controllo minimo da fare è semplice: scarica il pacchetto da una fonte ufficiale, verifica se il setup supporta installazione silenziosa e osserva dove scrive i file principali. Se il vendor aggiorna il formato del pacchetto, la detection basata su file o registro può rompersi senza preavviso. Per questo è meglio partire da un’installazione manuale in una VM di test e annotare subito percorso, versione e chiavi di registro effettive.

Se devi costruire la distribuzione in azienda, tieni presente un punto operativo: GitHub Desktop non è un software “server-side”, quindi non ha senso inseguire una configurazione complessa lato sistema. La parte delicata è il contesto utente, perché alcune applicazioni desktop salvano impostazioni e cache nel profilo dell’utente e non nel Program Files.

Packaging consigliato per Intune: Win32 app con detection affidabile

Per Intune, in genere, la scelta più robusta è confezionare GitHub Desktop come app Win32. Questo ti permette di controllare installazione, disinstallazione, detection rule e supersedence in modo più ordinato rispetto a un semplice LOB app, soprattutto se devi standardizzare il rollout.

Il flusso base è il seguente: prepari il pacchetto con IntuneWinAppUtil.exe, carichi il file .intunewin, imposti il comando di installazione silenziosa e definisci una regola di rilevamento solida. Se il software scrive una versione nel registro, quella è quasi sempre la strada migliore; in alternativa, usa un file in un percorso stabile, ma solo se sei certo che l’installer non cambi layout tra release.

Creazione del pacchetto

In una cartella di staging, tieni separati sorgente, output e script. Esempio di struttura:

.\\Source\GitHubDesktop\setup.exe
.\Output\
.\Scripts\

La conversione in formato Intune Win32 avviene con lo strumento Microsoft dedicato. Un esempio tipico:

IntuneWinAppUtil.exe -c .\Source\GitHubDesktop -s setup.exe -o .\Output

L’output atteso è un file .intunewin nella cartella di destinazione. Se non compare, controlla che il percorso sorgente sia corretto e che il file indicato con -s esista davvero.

Command line di installazione e disinstallazione

Qui serve precisione. Non dare per scontato che il setup supporti gli stessi switch di altri installer basati su Electron o NSIS. Devi verificare la documentazione del pacchetto specifico o testare i parametri in una VM. Se il software supporta una modalità silenziosa standard, usala; altrimenti, cerca il wrapper o il parametro ufficiale previsto dal vendor.

In Intune, l’obiettivo è arrivare a un comando di installazione che non apra finestre e non richieda interazione. Il comando di disinstallazione deve essere altrettanto pulito e, se possibile, idempotente. Se il setup crea un entry in Apps & features, annota il nome esatto perché spesso è quello che finisce anche nella detection o nella policy di rimozione.

Detection rule: meglio registro che file casuali

La detection è il punto in cui molte distribuzioni falliscono. Una regola troppo debole produce falsi positivi, una troppo rigida manda in loop installazioni già presenti. La scelta più stabile è la detection basata su chiave di registro dell’applicazione, se disponibile, con verifica della versione installata.

Se il prodotto espone una chiave sotto HKLM\\Software\Microsoft\Windows\CurrentVersion\Uninstall o in HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall, usa il nome esatto della voce e la versione come criterio. In alternativa, puoi impostare una detection su file come GitHubDesktop.exe, ma solo se il percorso è stabile e non dipende dal profilo utente.

Un controllo rapido in una macchina di test è questo:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall /s /f "GitHub Desktop"

L’output atteso è una chiave con nome coerente e, idealmente, un valore DisplayVersion. Se non trovi nulla, prova anche il ramo WOW6432Node. Se ancora non compare, la detection su file diventa la soluzione di ripiego, ma va validata con attenzione.

Assegnazione e rollout

Una volta caricata l’app, assegna prima a un gruppo pilota ristretto. Non partire con il parco macchine completo: GitHub Desktop è semplice, ma i problemi veri emergono quando il software incontra ambienti con restrizioni, utenti senza privilegi locali o policy di hardening più aggressive. Il blast radius corretto, in questa fase, è il minimo indispensabile: un gruppo di test con 5-20 dispositivi, a seconda della maturità del tenant.

Se la distribuzione fallisce, guarda subito l’install behavior, il return code e la detection. In Intune i log utili sono quelli del client Management Extension; quando serve, il percorso classico da controllare è C:\\ProgramData\Microsoft\IntuneManagementExtension\Logs. Non serve aprire mille file: basta capire se il problema è in fase di download, installazione o verifica finale.

Distribuzione con SCCM: Application model, non package legacy

Su SCCM, per un software desktop come questo, conviene usare il modello Application. I vecchi package possono ancora funzionare, ma perdi granularità su detection, supersedence e reporting. Con Application puoi definire regole di rilevazione chiare e costruire una catena di aggiornamento più gestibile.

Il flusso corretto è: creare l’application, definire il deployment type, impostare il content location, scegliere il comando di installazione silenziosa e costruire una detection method affidabile. Se il software è installabile per utente, devi decidere se distribuirlo nel contesto user o system. In azienda, quasi sempre è meglio preferire il contesto system, salvo dipendenze specifiche del profilo.

Metodo di detection in SCCM

In SCCM la detection può essere basata su file, registry o MSI product code, se l’installer lo espone. Per GitHub Desktop, se il setup non è MSI, il product code potrebbe non esserci. In quel caso, la strada più pulita è il registro uninstall con versione o un file in un path stabile.

Un esempio di verifica lato client, utile prima di pubblicare la detection definitiva:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object { $_.DisplayName -like '*GitHub*Desktop*' } |
Select-Object DisplayName, DisplayVersion, InstallLocation

Se il comando restituisce una riga coerente con la versione installata, hai una base forte per la regola di detection. Se non restituisce nulla, guarda il ramo WOW6432Node o verifica se il prodotto viene installato nel profilo utente.

Comando di installazione e return code

Nel deployment type, imposta il comando di installazione con gli switch silenziosi confermati nei test. I return code devono essere allineati al comportamento reale del setup: alcuni installer restituiscono 3010 per indicare riavvio richiesto, altri usano codici diversi per successo con reboot o successo senza reboot. Se non li mappi bene, SCCM può segnare come falliti installazioni corrette.

Per la disinstallazione, prepara un comando che rimuova l’app senza lasciare residui critici. Se il software salva dati utente, non cancellarli automaticamente a meno che la policy aziendale lo richieda. In quel caso, serve una scelta esplicita e un rollback chiaro, perché i dati del profilo non sono sempre ricostruibili.

Se vuoi ridurre gli errori operativi, testa il comando su una macchina di laboratorio con un account standard e una macchina con privilegi elevati. Il comportamento può cambiare se l’installer tenta di scrivere in aree protette o se il software si appoggia a componenti per-user.

Aggiornamenti: come evitare di rincorrere versioni diverse

Il problema più comune non è l’installazione iniziale, ma il ciclo di vita. Se distribuisci GitHub Desktop senza una strategia di update, nel giro di poche settimane ti ritrovi con versioni sparse tra i client. Questo non è solo un problema estetico: cambia anche la superficie di supporto quando devi fare troubleshooting o verificare compatibilità con policy e proxy.

Con Intune, la strada più ordinata è gestire una nuova Win32 app e usare supersedence o una logica di sostituzione basata su versione. Con SCCM, puoi pubblicare una nuova application o una revisione e usare supersedence per spingere l’aggiornamento. In entrambi i casi, la detection deve distinguere in modo netto tra vecchia e nuova release.

Se il vendor pubblica release frequenti, conviene verificare se l’installer supporta aggiornamenti in-place senza perdere configurazioni. Quando non hai questa garanzia, tratta ogni major update come un change controllato: pilota ristretto, verifica funzionale, poi estensione progressiva.

Controlli post-deploy: cosa verificare subito

Dopo il rollout, non limitarti a vedere “Installed” nel pannello. Serve almeno un controllo funzionale di base. L’app si apre? La versione corrisponde a quella prevista? L’utente riesce a collegarsi ai repository aziendali? Se usi proxy, TLS inspection o restrizioni di rete, verifica che il client riesca a raggiungere i servizi necessari senza errori evidenti.

Un controllo pratico su Windows è osservare la presenza del processo e la versione installata dalle proprietà dell’eseguibile o dal registro. Se il software non parte, controlla Event Viewer, eventuali log dell’app nel profilo utente e la presenza di blocchi da parte di Defender, AppLocker o policy equivalenti.

Se il problema è di rete, la distribuzione potrebbe essere perfetta ma l’app inutilizzabile. In quel caso il fix non è nel packaging: va cercato in proxy, certificati, DNS o policy di sicurezza. È un errore classico attribuire al deployment un difetto che in realtà è ambientale.

Rollback e gestione del blast radius

Ogni distribuzione aziendale deve avere un rollback leggibile. Se la nuova versione causa problemi, la prima mossa è sospendere l’assegnazione al gruppo colpito e riportare la baseline a una release precedente. In Intune questo significa ritirare o disabilitare l’assegnazione della Win32 app; in SCCM puoi disabilitare il deployment o sostituire la supersedence.

Il blast radius, in questo scenario, è generalmente basso se hai lavorato bene: si tratta di un software desktop, non di un componente core di sistema. Ma se lo hai distribuito come prerequisito di workflow di sviluppo, l’impatto operativo può essere più alto del previsto. Per questo il pilota è importante quanto il pacchetto.

Prima di qualsiasi update massivo, conserva sempre una copia del pacchetto precedente e della relativa detection. Se devi tornare indietro, devi sapere esattamente quale versione reinstallare e con quali parametri. Senza questa informazione, il rollback diventa un tentativo alla cieca.

Scelta pratica tra Intune e SCCM

Se l’ambiente è già in transizione verso il cloud, Intune è la scelta più pulita: packaging Win32, targeting per gruppi, reporting centralizzato e minore dipendenza dalla rete interna. Se invece hai una base on-prem consolidata e vuoi sfruttare collezioni, boundary group e maintenance window, SCCM resta più flessibile sul controllo fine del deployment.

La parte importante è non cambiare modello a ogni software. Una volta deciso il metodo standard per le app desktop, applicalo con disciplina: stesso approccio di detection, stessa logica di test, stessa procedura di rollback. È così che la distribuzione smette di essere artigianale e diventa davvero manutenibile.

Assunzione operativa: il pacchetto GitHub Desktop usato nei test supporta installazione silenziosa e lascia una traccia rilevabile in registro o in un percorso stabile; se non è così, va adattata la detection prima del rilascio in produzione.