Come trovare le applicazioni SCCM senza distribuzioni

Se in SCCM vuoi capire quali applicazioni esistono ma non risultano distribuite, la prima cosa da chiarire è che cosa intendi per “applicazione”. In Configuration Manager il termine può indicare una Application creata nel nodo Software Library, un deployment assegnato a una collection, oppure un software rilevato dall’inventario ma non ancora gestito con una distribuzione. Se non separi questi tre livelli, finisci facilmente a leggere dati incompleti e a confondere “non distribuita” con “non installata”.

La risposta pratica è questa: le applicazioni senza distribuzioni si individuano confrontando l’elenco delle Application presenti in SCCM con l’elenco dei Deployment effettivi. In mezzo ci sono però vari casi particolari: applicazioni disabilitate, supersedence, deployment verso collection vuote, contenuti non distribuiti ai distribution point, e applicazioni presenti solo come metadati ma mai usate in una policy. Quindi la ricerca va fatta per livelli, non con un solo filtro magico.

Il punto di partenza giusto: Application, Deployment e Collection

In SCCM una Application è l’oggetto logico che descrive software, requisiti, detection method, contenuto e comportamento di installazione. Un Deployment è invece la pubblicazione di quell’oggetto verso una o più collection, in modalità Available o Required. Se un’applicazione non ha alcun deployment, esiste nel catalogo ma non raggiunge i client tramite policy.

Questo distingue due scenari molto diversi:

Se l’obiettivo è trovare le applicazioni senza distribuzioni, devi concentrarti sul primo caso. Il modo più pulito è interrogare SCCM tramite console, SQL o PowerShell, a seconda di quanto vuoi essere preciso e di quale accesso hai.

Metodo rapido da console: quando basta un controllo operativo

Se ti serve una verifica veloce, dalla console di Configuration Manager vai in Software Library > Application Management > Applications. Qui vedi tutte le applicazioni create. Per ciascuna puoi controllare la scheda Deployments: se è vuota, l’applicazione non è distribuita.

Questo approccio è utile se devi fare triage su pochi oggetti, ma non è il migliore quando devi trovare in massa tutte le applicazioni non distribuite. Il limite è evidente: la console va bene per l’ispezione manuale, non per costruire un elenco affidabile di decine o centinaia di oggetti.

Un controllo utile lato UI è anche la vista Monitoring > Deployments. Qui vedi i deployment esistenti e puoi filtrare per applicazione, collection o stato. Se un’app non compare mai in questa vista, è un indizio forte che non ha deployment associati.

Query SQL: il modo più preciso per elencare le applicazioni senza deployment

Quando vuoi un elenco affidabile, la strada più diretta è una query sul database del site server. La logica è semplice: prendi tutte le applicazioni e togli quelle che hanno almeno un deployment. Il risultato sono le applicazioni non distribuite.

La struttura delle tabelle può variare leggermente in base alla versione, ma il concetto resta lo stesso: unire la tabella delle applicazioni con quella dei deployment e filtrare i record senza corrispondenza. Se hai accesso al database SCCM, una query di questo tipo è il punto di partenza più pragmatico.

SELECT a.ModelName, a.LocalizedDisplayName
FROM v_ApplicationModelInfo a
LEFT JOIN v_DeploymentSummary d
    ON a.ModelName = d.AppModelName
WHERE d.AppModelName IS NULL
ORDER BY a.LocalizedDisplayName;

Il vantaggio è evidente: ottieni una lista pulita delle applicazioni senza deployment. Il limite sta nel fatto che alcune installazioni usano viste diverse o naming leggermente differente tra oggetti applicativi e summary dei deployment. Se la query non torna risultati, non dare per scontato che non esistano applicazioni orfane: verifica i nomi delle viste disponibili nel tuo ambiente.

Per chiudere il gap senza andare a tentativi, fai una verifica preliminare con le viste presenti nel database e con i campi effettivi della tua versione. Se vuoi confermare i nomi, puoi usare una ricerca sulle viste di sistema o consultare la documentazione del tuo build specifico.

SELECT name
FROM sys.views
WHERE name LIKE 'v_%Application%'
   OR name LIKE 'v_%Deployment%';

PowerShell: utile per automatizzare e confrontare i risultati

Se preferisci lavorare in modo ripetibile, PowerShell è spesso la scelta migliore. Puoi estrarre l’elenco delle applicazioni, poi confrontarlo con i deployment registrati. È una soluzione comoda quando devi generare report periodici o quando vuoi integrare il controllo in una pipeline di amministrazione.

La logica è questa: interrogare il provider di Configuration Manager, recuperare le applicazioni e filtrare quelle che non hanno oggetti di deployment associati. In molti ambienti è più semplice usare la console per individuare il site code e poi operare dal prompt di PowerShell del Configuration Manager console module.

Import-Module ConfigurationManager
cd XYZ:
Get-CMApplication | Where-Object {
    -not (Get-CMDeployment -ApplicationName $_.LocalizedDisplayName -ErrorAction SilentlyContinue)
} | Select-Object LocalizedDisplayName

Qui c’è un punto importante: i cmdlet possono cambiare in base alla versione del modulo e alla modalità con cui identifichi l’applicazione. Se il filtro per nome non è stabile nel tuo ambiente, usa un identificatore univoco disponibile nel modello dati o passa da un mapping più robusto tra applicazione e deployment. Non forzare il comando “finché funziona”: in SCCM i nomi possono essere ambigui e il risultato va validato.

Per chiudere il gap, verifica sempre l’output con un campione manuale: prendi un’applicazione che sai essere distribuita e una che sai essere non distribuita, poi controlla che il filtro le separi correttamente. È un test banale, ma evita report sbagliati.

Non confondere “nessuna distribuzione” con “nessuna installazione”

Questo è l’errore più comune. Un’applicazione può avere deployment validi e comunque non comparire mai come installata sui client. Succede se il detection method è errato, se i requisiti non sono soddisfatti, se il contenuto non è disponibile, o se la collection non contiene i dispositivi attesi. In quel caso l’applicazione è distribuita, ma il deployment non produce effetti.

Se invece stai cercando applicazioni senza distribuzioni, non devi fermarti al dato “nessun client la installa”. Devi verificare che non esistano deployment in nessuna collection, né Required né Available. Altrimenti stai leggendo un sintomo diverso.

Un controllo utile è quello sulla vista di monitoring dei deployment: se un’applicazione compare lì, è già distribuita. Se non compare, devi comunque distinguere tra oggetto non distribuito e oggetto distribuito in modo indiretto tramite supersedence o dipendenze. Alcune strutture più complesse non saltano subito all’occhio nella sola lista base delle applications.

Supersedence, dipendenze e oggetti apparentemente “inermi”

In ambienti maturi, non tutte le applicazioni senza deployment sono davvero inutili. Alcune servono come base per una catena di supersedence, altre sono dipendenze richiamate da un’applicazione principale. In questi casi un oggetto può sembrare non distribuito, ma in realtà è usato indirettamente da un altro deployment.

Per questo, prima di cancellare o archiviare, controlla se l’applicazione è referenziata da altri oggetti. La domanda non è solo “ha un deployment?”, ma anche “è usata come dependency o superseded item?”. Se elimini un componente condiviso, puoi rompere installazioni già in produzione.

Una buona pratica è classificare le applicazioni in tre gruppi:

Come costruire un elenco affidabile senza fare danni

Se devi lavorare in produzione, il metodo corretto è sempre reversibile. Prima estrai i dati, poi li validi, e solo dopo eventuali cambiamenti. Non cancellare nulla sulla base di un filtro non testato. Il flusso giusto è: inventario, confronto, verifica manuale, eventuale pulizia documentata.

Un approccio solido è esportare l’elenco delle applicazioni e quello dei deployment in CSV, poi confrontarli offline. È meno elegante di una query perfetta, ma ti permette di vedere subito eventuali incongruenze tra nomi, scope e oggetti duplicati.

# esempio di esportazione lato PowerShell, da adattare al tuo ambiente
Get-CMApplication | Select-Object LocalizedDisplayName, CI_ID | Export-Csv .\applications.csv -NoTypeInformation

Se fai pulizia, conserva sempre un riferimento del motivo per cui un’applicazione è stata lasciata senza deployment. A volte è un oggetto di test, a volte è un pacchetto storico, a volte è un placeholder per future release. Senza note operative, dopo qualche mese nessuno ricorda più perché esista.

Un caso pratico: trovare le app “orfane” dopo una migrazione

Un caso tipico è la migrazione da un vecchio site a uno nuovo, oppure il passaggio da pacchetti legacy a Application model. Ti ritrovi con decine di applicazioni create in massa, ma solo una parte effettivamente pubblicata. In questi ambienti, la lista delle applicazioni senza deployment è spesso lunga e piena di oggetti intermedi.

Qui il lavoro utile non è solo scoprire quali mancano di deployment, ma capire se il loro stato è intenzionale. In pratica devi rispondere a tre domande: esiste un owner? esiste un piano di distribuzione? esiste una dipendenza verso altri oggetti? Se la risposta è no a tutte e tre, l’applicazione è candidata a rimozione o archiviazione.

Un buon criterio operativo è assegnare uno stato di revisione: “da distribuire”, “da mantenere”, “da archiviare”. Questo evita il classico cimitero di oggetti SCCM creati una volta e mai più toccati. Anche solo un tag nel nome o una nota interna può aiutare più di una pulizia aggressiva.

Controlli finali prima di considerare chiuso il lavoro

Prima di dire che hai trovato tutte le applicazioni senza distribuzioni, fai questi controlli minimi:

La metrica di qualità qui non è la quantità di righe prodotte, ma la coerenza tra console, query e stato reale. Se i tre livelli coincidono, hai un elenco utile. Se divergono, il problema è quasi sempre nel mapping tra oggetti o nel contesto della query, non nel concetto di base.

In pratica, trovare le applicazioni SCCM senza distribuzioni è semplice solo in apparenza. La parte difficile non è estrarre i nomi, ma capire cosa stai davvero misurando. Se lavori con criterio, la console basta per i controlli rapidi, SQL dà la fotografia più pulita e PowerShell ti permette di automatizzare senza perdere controllo sul dato.