Distribuire Notepad++ con SCCM: guida completa

Distribuire Notepad++ con SCCM sembra banale finché non devi farlo bene su più versioni di Windows, con aggiornamenti controllati, detection robusta e nessuna dipendenza inutile dal desktop dell’operatore. La differenza non la fa il pacchetto in sé, ma come lo prepari: installazione silenziosa, regole di rilevamento affidabili, gestione degli upgrade e una strategia chiara per evitare che l’app si reinstalli a ogni ciclo di valutazione.

Il punto di partenza è semplice: Notepad++ è un’app leggera, ma in ambiente SCCM va trattata come qualsiasi software distribuito in produzione. Quindi niente improvvisazioni con EXE lanciati “a mano” nel wizard e niente detection basata solo sulla presenza di un file casuale. Se vuoi un deployment stabile, devi ragionare su tre livelli: packaging, installazione e verifica post-installazione.

Scelta del metodo: Application, non Package

In SCCM, per Notepad++ conviene usare Application e non il vecchio modello Package. Il motivo è pratico: l’Application model ti dà detection method, supersedence, requisiti, dipendenze e un ciclo di vita più pulito. Per un software che cambia spesso versione, questa è la strada giusta.

Il Package ha ancora senso per script semplici o distribuzioni dove non ti interessa sapere se il client è già conforme. Qui invece la conformità è il punto: vuoi sapere se Notepad++ è installato, quale versione c’è e se l’upgrade deve partire o no.

Scaricare il pacchetto giusto e preparare la sorgente

Prima cosa: scarica la versione ufficiale di Notepad++ dal sito del progetto e conserva il binario in una share sorgente dedicata, con permessi di sola lettura per gli account di distribuzione. Evita di usare una cartella condivisa generica piena di materiale misto. La sorgente deve essere prevedibile, versionata e facile da ripristinare.

Una struttura sensata può essere questa:

\SCCM-SRCy-app
otepadplusplus
un
otepad++
pp.8.7.8.x64.exe

Se gestisci più release, separa le versioni in sottocartelle numerate. Così puoi mantenere storico, rollback e confronto rapido tra una build e l’altra. Non mischiare installer diversi nella stessa directory senza naming coerente: in SCCM, prima o poi, paghi il debito con la confusione nelle detection.

Installazione silenziosa: il comando che non ti tradisce

Notepad++ usa un installer NSIS, quindi l’installazione silenziosa è lineare. Il punto è verificare sempre i parametri della versione specifica che stai distribuendo, perché i vendor cambiano comportamento e switch tra una major release e l’altra non sono un dettaglio da ignorare.

Il flusso tipico è questo:

npp.8.7.8.x64.exe /S

In molti casi basta questo. Se vuoi testare localmente prima di incapsulare in SCCM, lancia il comando da una shell elevata su una macchina di test e controlla che non apra finestre interattive. Il comportamento atteso è un’installazione senza prompt e con ritorno del processo in tempi brevi. Se compare una UI, hai già un problema: non è deployabile in modo affidabile.

Per evitare errori in fase di packaging, conviene preparare anche uno script di installazione minimale che registri l’esito in un log locale. Non serve fare teatro: basta una traccia leggibile che ti dica se l’EXE è partito e se ha terminato con codice coerente.

@echo off
set LOG=%WINDIR%\Temp\notepadpp-install.log
echo [%date% %time%] start >> "%LOG%"
start /wait "" "%~dp0npp.8.7.8.x64.exe" /S
echo [%date% %time%] exitcode=%errorlevel% >> "%LOG%"
exit /b %errorlevel%

Questo approccio aiuta soprattutto quando devi distinguere tra problema di rete, problema di permessi sulla share, fallimento dell’installer o detection sbagliata. Il log locale ti dà un primo appiglio prima di andare a cercare nei log SCCM lato client.

Detection rule: il punto dove molti deployment si rompono

La detection è il cuore del deployment. Se la imposti male, SCCM vedrà Notepad++ come non installato anche quando c’è già, oppure lo considererà installato quando la versione è vecchia. Entrambi i casi sono fastidiosi, ma il secondo è peggio perché ti lascia una falsa sensazione di conformità.

La regola più pulita è basata su registro o versione file, ma in ambiente Windows enterprise il registro è spesso più stabile. Per Notepad++ verifica la chiave di uninstall e la versione del prodotto. Il percorso può variare tra installazione per macchina e per utente, quindi conviene testare sul tuo target reale prima di fissare la regola.

Un controllo pratico da fare sul client è questo:

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s /f "Notepad++"

Se la tua build è a 64 bit su sistemi 64 bit, ricorda che alcune chiavi possono finire nel ramo Wow6432Node. Non dare per scontato che il percorso sia identico su tutti i dispositivi. La detection corretta deve essere testata su almeno un client a 64 bit e, se presente nel parco, su un client con scenari particolari di redirezione.

Se preferisci la detection basata su file, usa un eseguibile con versione coerente e controlla la proprietà file version. In ogni caso, evita condizioni troppo lasche come “esiste la cartella dell’applicazione”: quella non dimostra nulla, perché una directory vuota o parzialmente corrotta può ingannare SCCM.

Creare l’Application in console SCCM

In console, il percorso operativo è quello classico dell’Application model. Crea una nuova Application, definisci il contenuto sorgente, imposta il comando di installazione e aggiungi la detection rule. Se il tuo ambiente usa categorie o collection di test, fai partire il deployment solo su una raccolta pilota prima di allargare la distribuzione.

Il vantaggio di passare da Application è che puoi anche definire requisiti minimi, ad esempio architettura x64 o versione di Windows supportata. Per Notepad++ di solito non hai vincoli stretti, ma se nella tua infrastruttura vuoi evitare installazioni inutili su sistemi non target, i requisiti sono la maniera più pulita per bloccare il deployment prima ancora che parta.

Se il pacchetto deve convivere con versioni precedenti, valuta subito la supersedence. È la scelta migliore quando vuoi trasformare un aggiornamento in una transizione controllata e non in una giungla di detection sovrapposte. In pratica: la nuova Application sostituisce la vecchia, la vecchia viene marcata come superseded e puoi decidere se disinstallarla o no.

Gestione degli aggiornamenti: supersedence e ciclo di vita

Notepad++ riceve aggiornamenti frequenti, e in un ambiente gestito questo ha un effetto diretto sulla manutenzione. Se non pianifichi gli upgrade, ti ritrovi con varie versioni sparse e una detection che deve inseguire la realtà. Il modo pulito per evitare il caos è trattare ogni nuova release come una nuova Application e usare la supersedence per governare la migrazione.

Un errore comune è aggiornare la sorgente del pacchetto lasciando invariata la stessa Application. Funziona solo finché non ti serve sapere chi ha installato cosa e quando. Dopo qualche ciclo, perdi lo storico e ti complichi il rollback. Con una Application nuova per release, invece, il tracciamento resta leggibile.

Se vuoi ridurre il rumore, puoi mantenere una convenzione di naming coerente, per esempio con versione nel titolo e nel contenuto della deployment type. Questo aiuta anche chi deve fare troubleshooting a distanza: leggere “Notepad++ 8.7.8 x64” è molto più utile di un generico “Notepad++ Latest”.

Distribuzione pilota: prima i sintomi, poi la scala

Prima di spingere in produzione, distribuisci su una collection pilota con pochi client rappresentativi. Non basta che l’installazione funzioni sul tuo PC amministrativo: devi verificare sistemi con profili diversi, magari un laptop in VPN, una macchina sempre accesa in LAN e un client con policy più restrittive.

Le cose da osservare sono poche ma concrete: esito del deployment, comparsa della versione corretta, assenza di finestre interattive e tempi di completamento ragionevoli. Se Notepad++ si installa ma il client SCCM continua a segnare “Required”, la causa è quasi sempre una detection debole o un path non coerente.

Per verificare lato client puoi guardare i log del sistema SCCM e incrociarli con il tuo log applicativo. I nomi dei file possono variare in base al componente, ma il punto non cambia: vuoi vedere il comando lanciato, il codice di uscita e la valutazione della detection. Se uno di questi tre pezzi manca, il troubleshooting si allunga inutilmente.

Strategia di rollback: semplice, esplicita, recuperabile

Ogni deployment serio deve avere un rollback, anche se l’app è piccola. Con Notepad++ il rollback può essere banale: tieni disponibile la release precedente e conserva il pacchetto sorgente finché la nuova versione non è stabilizzata. Se l’upgrade introduce un comportamento inatteso, puoi tornare indietro senza ricostruire tutto da zero.

Il rollback operativo più pulito è questo: disabiliti la distribuzione della nuova Application, reabiliti la precedente e, se hai usato supersedence con disinstallazione, controlli che il comportamento sia quello atteso nei client pilota. Non serve inventarsi script aggressivi di rimozione se non hai un requisito preciso.

Se devi verificare manualmente la presenza della versione installata, controlla il pannello applicazioni oppure la chiave di uninstall nel registro. Questo ti evita di dipendere solo dallo stato riportato da SCCM, che può essere in ritardo rispetto alla realtà del client.

Errori tipici da evitare

Il primo errore è usare un detection method troppo generico. Il secondo è non testare il comando silenzioso su una macchina reale prima di pubblicarlo. Il terzo è distribuire la nuova versione senza una strategia chiara per la precedente. Tutti e tre si traducono nello stesso risultato: ticket aperti e tempo perso a inseguire falsi positivi.

Un altro errore frequente è ignorare il contesto di esecuzione. Se il client SCCM gira con privilegi diversi da quelli con cui hai fatto il test manuale, il pacchetto può comportarsi in modo differente. È qui che i log diventano fondamentali: senza una traccia locale o lato client, stai solo indovinando.

Infine, non sottovalutare la parte organizzativa. Un pacchetto ben fatto ma senza naming chiaro, senza storico e senza ownership resta fragile. In un team IT, la leggibilità del deployment conta quanto la tecnica: chi subentra deve capire in pochi minuti cosa sta guardando.

Flusso operativo consigliato

Se vuoi un percorso lineare, usa questo schema: scarica la release ufficiale, prepara la share sorgente, testa il comando silenzioso, definisci la detection, crea l’Application, pubblica su una collection pilota, osserva i client, poi scala alla produzione. È un flusso noioso, ma proprio per questo è quello giusto.

In termini pratici, la metrica che ti interessa non è “il pacchetto è stato creato”, ma “il client installa la versione corretta e la detection la riconosce senza ambiguità”. Se questo è vero su un campione realistico di macchine, allora puoi considerare il deployment sano.

Per chi gestisce ambienti grandi, il vero guadagno è la manutenzione nel tempo. Un pacchetto Notepad++ ben costruito oggi ti evita di rincorrere eccezioni, reinstallazioni e versioni incoerenti nei mesi successivi. In SCCM la qualità si vede dopo, quando il ciclo di vita del software resta sotto controllo e non si trasforma in una serie di eccezioni manuali.

Snippet di controllo rapido sul client

Quando devi fare verifica veloce su una macchina, questi controlli ti danno un quadro immediato:

where notepad++
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s /f "Notepad++"
wmic product get name,version | findstr /i "notepad++"

Il primo comando ti dice se il binario è nel PATH, il secondo se c’è una chiave di uninstall coerente, il terzo può aiutare in ambienti legacy ma non va preso come fonte primaria: in certi sistemi è lento e non sempre rappresenta bene lo stato reale. Usalo come supporto, non come base unica della detection.

Se il tuo scenario richiede anche controllo delle impostazioni utente, separa chiaramente ciò che è installazione da ciò che è configurazione. Notepad++ può avere preferenze nel profilo utente, ma SCCM non deve confondere un profilo locale con il successo dell’installazione dell’applicazione.

Quando fermarsi e correggere il pacchetto

Se in fase pilota vedi installazioni riuscite ma detection incoerente, fermati e correggi la regola prima di aumentare il rollout. Se invece il comando silenzioso fallisce su una parte dei client, non forzare la distribuzione: prima capisci se il problema è architettura, permessi, path sorgente o comportamento dell’installer.

La regola pratica è questa: modifica una sola variabile per volta. Cambia la detection, rilancia il test. Cambia il comando, rilancia il test. Cambia la sorgente, rilancia il test. Se fai tre modifiche insieme, poi non sai più quale ha risolto o rotto il flusso.

Distribuire Notepad++ con SCCM è un buon esercizio di disciplina operativa: un software semplice mette in evidenza subito se il tuo processo è solido o se vive di assunzioni implicite. E proprio per questo è un caso utile da fare bene, non da fare in fretta.