Distribuire applicazioni utente con SCCM 1910

Distribuire applicazioni utente con SCCM 1910: il punto critico è il contesto, non il pacchetto

Con SCCM 1910, distribuire un’applicazione all’utente non significa semplicemente “pubblicare un software”. La differenza vera sta nel contesto: l’app deve essere valutata, installata e, se serve, riparata in relazione all’identità dell’utente, non solo del dispositivo. È qui che molti deployment diventano fragili: funzionano in test, ma falliscono appena entrano in gioco più sessioni, device shared, collezioni dinamiche o requisiti legati al profilo dell’utente.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

La regola pratica è semplice: se l’applicazione contiene logica che dipende da impostazioni personali, credenziali, associazioni utente o scritture in un profilo, va progettata pensando all’utente come target primario. SCCM 1910 lo supporta bene, ma non perdona i setup approssimativi. L’errore tipico è usare una distribuzione device-based e poi cercare di compensare con script, variabili o detection clause troppo permissive. Funziona finché non cresce il parco macchine.

Quando conviene assegnare all’utente invece che al dispositivo

La distribuzione user-based ha senso quando il software deve seguire la persona su più endpoint, quando l’installazione dipende dal profilo, oppure quando l’accesso all’app deve essere governato da criteri di business più che da inventario hardware. Un classico è una suite di strumenti per tecnici, un client VPN con impostazioni personali, un plugin per browser o un’applicazione line-of-business che salva dati nel profilo utente.

Il vantaggio operativo è che la policy segue l’utente, non la workstation. Se l’utente accede a un nuovo PC gestito, l’app può comparire automaticamente, purché la valutazione della collezione e la distribuzione siano coerenti. Il limite è altrettanto chiaro: se il requisito è installare un servizio di sistema o scrivere in aree protette, il contesto utente non basta. In quel caso il software va comunque installato in machine context, anche se l’assegnazione è guidata dall’utente.

La scelta del modello: Available, Required e Install behavior

In SCCM 1910, il tipo di deployment cambia il comportamento percepito dall’utente. Available è il modello più prudente: l’app appare nel Software Center e l’utente decide quando installarla. Required forza l’installazione secondo la pianificazione definita. Per applicazioni utente, Available è spesso la scelta migliore quando vuoi evitare installazioni invasive o vuoi un rollout progressivo. Required ha senso quando l’app è necessaria per il ruolo e non deve dipendere dall’iniziativa dell’utente.

Il punto da non sottovalutare è il parametro di installazione. Se l’applicazione deve girare nel contesto dell’utente, il programma di installazione e le detection rules devono rifletterlo. Un installer MSI lanciato come SYSTEM può scrivere in posizioni diverse rispetto a quando viene eseguito in sessione utente, e una detection clause che guarda solo `HKLM` può risultare corretta per il device ma sbagliata per l’utente. In pratica: il deployment funziona sul server di test, poi si rompe sulle postazioni condivise.

Preparare il pacchetto: content, detection e requisiti

Prima di creare il deployment, vale la pena sistemare tre punti: contenuto, rilevazione e requisiti. Il contenuto deve essere realmente installabile dal Distribution Point e non dare per scontato un path locale. La detection method deve rispondere a una domanda precisa: “come capisco che l’app è già presente nel contesto corretto?”. I requisiti devono essere minimi ma realistici, altrimenti la collezione si gonfia e la valutazione diventa lenta.

Per un’app utente, la detection spesso non può limitarsi al file exe in `Program Files`. Se l’app è per-user, il marker giusto può stare nel profilo, in `HKCU`, o in una directory sotto `AppData`. Il problema è che SCCM valuta la detection nel contesto del client, non con la fantasia dell’amministratore. Se il client esegue la valutazione come SYSTEM, una chiave in `HKCU` può non essere quella dell’utente attivo. Questo è il punto in cui bisogna decidere se l’app è davvero user-context o se conviene trasformarla in machine-context con impostazioni post-installazione.

Per i requisiti, evita condizioni decorative. Se l’app richiede Windows 10 o successivo, versione del .NET Framework, spazio disco minimo o architettura specifica, dichiaralo chiaramente. Se invece il requisito è “solo utenti del reparto amministrazione”, meglio usare una collezione basata su query o su membership diretta, non una logica nascosta nello script di installazione.

Creazione dell’application in SCCM 1910

Il flusso classico parte dalla console di Configuration Manager. Nel nodo Software Library, sotto Application Management, si crea una nuova application. SCCM 1910 consente di importare molte informazioni da MSI, ma questo non basta per applicazioni utente con comportamento non standard. L’import MSI è utile per velocizzare, non per delegare il progetto.

Il passaggio più importante è definire il deployment type corretto. Qui decidi se il contenuto viene installato via MSI, script, package wrapper o comando personalizzato. Per software che deve adattarsi all’utente, spesso uno script ben fatto è più affidabile di un MSI trattato come scatola nera. Non perché lo script sia “più moderno”, ma perché ti dà controllo esplicito su log, exit code, percorsi e detection.

Nel wizard, cura con attenzione il programma di installazione e il programma di disinstallazione. Se il prodotto ha un uninstall ufficiale, usalo. Se non esiste, valuta molto bene se vale la pena procedere: un’app che non si disinstalla pulitamente è un debito tecnico che poi si paga in ticket e remediation manuali.

Contesto di esecuzione: user, system o ibrido

Qui si gioca gran parte della riuscita del deployment. Il contesto di esecuzione non è un dettaglio amministrativo: determina cosa vede l’installer, dove scrive e quali risorse può toccare. Se l’app deve leggere o scrivere dati nel profilo dell’utente, il contesto user è il candidato naturale. Se invece il setup richiede privilegi elevati, ma l’esperienza finale è personale, serve un approccio ibrido: installazione come SYSTEM e configurazione iniziale per utente, oppure installazione per device con post-configurazione tramite script nel profilo.

In pratica, la domanda da farsi non è “posso farla girare come utente?”, ma “cosa cambia se la faccio girare come utente?”. Se il risultato cambia in modo sostanziale, allora il contesto è parte del requisito e non un’opzione. Se invece serve solo per comodità operativa, è meglio lasciare il motore di installazione nel contesto macchina e limitare al profilo utente solo la parte di personalizzazione.

Per molte applicazioni moderne, la soluzione pulita è separare installazione e configurazione. L’app viene installata come sistema, ma il primo avvio o un logon script applica impostazioni specifiche per utente. Questo riduce i problemi di permessi e rende più semplice il rollback. La controparte è che devi documentare bene la dipendenza tra i due passaggi, altrimenti il supporto si ritrova con utenti che “vedono l’app ma non funziona”.

Collezioni e targeting: non forzare l’intuizione

Per distribuire applicazioni utente con SCCM 1910, il targeting è spesso il punto dove si crea confusione. Le collezioni utente e le collezioni dispositivo non sono intercambiabili. Se l’obiettivo è seguire l’utente, la collezione deve riflettere criteri di membership legati all’account, al gruppo AD o a query affidabili. Se il deployment è su device ma l’app è user-aware, il risultato può essere incoerente: l’installazione si avvia sulla macchina ma l’utente non riceve ciò che si aspettava.

Una buona pratica è separare le collezioni per funzione: una collezione base per il pubblico destinatario, una collezione di test e una collezione pilota. Non fare il pilot sulla collezione finale. È una scorciatoia che sembra risparmiare tempo ma complica la diagnosi quando i requirements cambiano o un deployment type fallisce solo per un sottoinsieme di utenti.

Se hai bisogno di escludere utenti o gruppi, fallo nella collezione o nella fase di deployment, non infilando eccezioni nello script. Le eccezioni nello script diventano presto un elenco non governato e nessuno ricorda più perché un utente riceve l’app e un altro no.

Distribuzione e scheduling: evitare l’effetto sorpresa

Con applicazioni utente, il calendario di distribuzione conta più del solito. Se imposti un Required troppo aggressivo, l’utente percepisce il deployment come invasivo. Se lasci tutto Available senza una finestra ragionevole, il rollout si trascina e i ticket si accumulano. Il compromesso tipico è un Available iniziale sul pilot, seguito da Required in produzione solo dopo aver verificato detection, uninstall e comportamenti in sessione reale.

Le opzioni di notifica e riavvio vanno trattate con disciplina. Se l’app richiede logoff o restart, non mascherarlo dietro una scelta generica. Gli utenti tollerano male i riavvii improvvisi, soprattutto se l’app è legata alla produttività. Meglio prevedere una finestra, mostrare chiaramente l’impatto e verificare che il comportamento sia coerente con il policy set della tua organizzazione.

Log e diagnostica: dove guardare quando l’app non arriva

Quando una distribuzione utente non si presenta nel Software Center o non parte, la prima cosa da controllare non è il pacchetto ma lo stato della policy. I log lato client sono il punto di partenza: `AppEnforce.log`, `AppDiscovery.log`, `CIAgent.log` e `SCClient.log` danno un quadro molto più utile di una modifica a tentativi. Se l’app è stata assegnata ma non compare, il problema può stare nella valutazione della collezione, nella policy non ancora ricevuta o nella detection che la esclude.

Una verifica pratica consiste nel confrontare tre elementi: il deployment effettivo assegnato all’utente, la policy ricevuta dal client e la detection logic. Se uno dei tre non combacia, hai già trovato la direzione del problema. In ambiente reale, il punto debole più frequente non è il contenuto ma il criterio di rilevazione: l’app è installata, ma il detection rule non la riconosce nel contesto giusto.

Per la parte console, controlla lo stato del deployment e della collezione. Un errore comune è credere che un’app “non funzioni” quando in realtà è semplicemente non ancora stata valutata dal client. In SCCM 1910 la latenza di policy, soprattutto su endpoint non sempre connessi alla rete aziendale, può essere sufficiente a creare l’impressione di un guasto.

Un pattern pratico per applicazioni utente affidabili

Il pattern che regge meglio nel tempo è questo: packaging pulito, detection affidabile, collezione ben definita, pilot ristretto, poi estensione progressiva. Se l’app è per utente, documenta esplicitamente quale parte gira in user context e quale in system context. Se non puoi dirlo in una frase, probabilmente il deployment è più complesso del necessario.

Per esempio, un client di collaborazione può essere distribuito come application machine-based, mentre le impostazioni del profilo, i plugin o i file di configurazione vengono applicati con uno script eseguito al logon. Questo approccio riduce il rischio di fallimenti legati ai privilegi e mantiene separati installazione e personalizzazione. È anche più facile da supportare: se il problema è sul profilo, non devi reinstallare il software per ogni ticket.

Un altro vantaggio del modello ben separato è il rollback. Se una versione crea problemi, puoi ritirare il deployment o rimuovere il riferimento alla collezione pilota senza toccare tutta la base utenti. Questo è importante perché l’errore in un’app utente tende a diffondersi velocemente: basta che la policy sia corretta e il client faccia il resto.

Governance minima: versioni, change e ripristino

Anche in un contesto tecnico, la governance non è burocrazia. Per ogni application in SCCM 1910 conviene mantenere almeno il changelog del deployment type, il riferimento al contenuto distribuito e l’elenco delle collezioni coinvolte. Quando qualcosa si rompe, questi tre dati riducono drasticamente il tempo di diagnosi.

Se modifichi un deployment type, considera la modifica come un change controllato: esporta o annota il prima e il dopo, verifica il comportamento su un gruppo pilota, poi promuovi. Il rollback deve essere altrettanto esplicito: ripristino della versione precedente, rimozione della distribuzione o ritorno al deployment type stabile. Senza un punto di ritorno, il troubleshooting diventa una caccia al colpevole invece che una procedura operativa.

Conclusione operativa: pensa come un amministratore di contesto

Distribuire applicazioni utente con SCCM 1910 non è difficile quando si progetta il flusso partendo dal contesto corretto. Il software non va solo consegnato: va fatto comparire nel posto giusto, nel momento giusto e con il comportamento giusto. Se il target è l’utente, il deployment deve rispettare identità, sessione e profilo senza improvvisare scorciatoie.

La regola pratica che vale quasi sempre è questa: prima rendi il deployment osservabile, poi rendilo ripetibile, infine ottimizzalo. In SCCM 1910 questo significa log leggibili, detection solide, collezioni pulite e un rollback che non richieda acrobazie. Il resto è rumore operativo.