Come risolvere l'errore di verifica prerequisiti in ConfigMgr

Quando in ConfigMgr la verifica prerequisiti fallisce, il punto non è “riprovare finché passa”. Il controllo blocca un passaggio perché una condizione tecnica non è coerente con ciò che il setup si aspetta: ruoli mancanti, permessi insufficienti, rete non raggiungibile, SQL non allineato, componenti client in stato sporco o, più banalmente, un requisito del wizard non soddisfatto. La lettura corretta è questa: l’errore non va trattato come un messaggio generico, ma come un indice che rimanda a una specifica dipendenza dell’ambiente.

In pratica, la risoluzione efficace segue sempre la stessa logica: capire quale prerequisito sta fallendo, verificare l’evidenza nel log giusto, correggere la causa minima e solo dopo rilanciare il controllo. Saltare direttamente alla reinstallazione o a modifiche invasive di site system e database allunga il fermo e rende più difficile capire cosa abbia davvero rotto il flusso.

Che cosa significa davvero “verifica prerequisiti” in ConfigMgr

Il prereq check è un filtro di compatibilità prima di una modifica importante: installazione del sito, aggiunta di un ruolo, upgrade, estensione di componenti o aggiornamento della console. Non controlla solo la presenza del software; valida anche l’ambiente circostante. Per questo un errore apparentemente “di installazione” può dipendere da DNS, AD, SQL, certificati, versioni di .NET, spazio disco, connettività RPC o da un vecchio residuo di una precedente installazione fallita.

La conseguenza pratica è semplice: il messaggio a video spesso è troppo sintetico. La diagnosi vera si fa nel log locale del setup e nei log del ruolo o del server coinvolto. Senza quei file si finisce a tentativi, e i tentativi in ConfigMgr costano tempo perché ogni retry può cambiare sintomi senza rimuovere la causa.

Dove guardare per primo: i log che contano davvero

Il primo passo utile non è il pannello, ma il log. Il file più importante dipende dallo scenario, ma nella maggior parte dei casi conviene partire da ConfigMgrSetup.log o dal log relativo al ruolo che stai installando. Se stai eseguendo un upgrade o una manutenzione del sito, spesso il dettaglio utile è in CMUpdate.log, hman.log o nei log di prerequisito generati dal setup. Se il problema tocca il client, il riferimento diventa CcmSetup.log e, a seconda del caso, anche Client.msi.log.

Il criterio non cambia: cerca la riga con failed, error, prerequisite, warning o il nome preciso del requisito che manca. Se il setup mostra un codice di errore, annotalo insieme all’orario. Poi confrontalo con il log nello stesso minuto. Questo è il modo più rapido per evitare di inseguire sintomi collaterali.

Le cause più frequenti, in ordine pratico

Nella maggior parte degli ambienti il problema rientra in una di queste tre famiglie. La prima è la mancanza di un prerequisito software o di sistema: versione non supportata, feature Windows assente, .NET non conforme, riavvio in sospeso, spazio disco insufficiente. La seconda è la connettività o l’identità: il server non raggiunge SQL, DNS non risolve come previsto, l’account usato dal setup non ha i diritti necessari, oppure il dominio non risponde in modo coerente. La terza è l’ambiente ConfigMgr già sporco: residui di installazioni precedenti, componenti parziali, ruoli già registrati ma non funzionanti, certificati scaduti o binding incoerenti.

Un dettaglio che spesso viene sottovalutato: il prereq check non sempre fallisce per una causa “grave”. A volte segnala un warning che il wizard considera bloccante in quello specifico contesto, ad esempio perché stai tentando di collocare un ruolo in una topologia che non rispetta il support matrix. In questi casi la soluzione non è forzare, ma riallineare l’architettura al modello supportato.

Metodo rapido di diagnosi: dal sintomo al layer giusto

Se il setup fallisce, ragiona per layer. Prima verifica se il problema è locale al server, poi se coinvolge rete e directory, quindi se tocca SQL o i servizi ConfigMgr. Questo approccio evita di partire da ipotesi troppo alte quando il guasto è banale.

Controlli minimi utili:

• Stato del servizio e riavvio in sospeso: un reboot non eseguito può bloccare molti prerequisiti.
• Spazio libero sulle unità coinvolte: il setup di ConfigMgr è sensibile a C: e alla directory di installazione.
• Connettività verso SQL e domain controller: se il wizard non risolve o non autentica, il prereq check può fermarsi prima del dettaglio utile.
• Versioni dei componenti richiesti: .NET, Windows ADK, SQL client, PowerShell, feature IIS o ruoli server.

Per una verifica rapida da shell, usa comandi non distruttivi e annota il risultato. Ad esempio, per controllare connettività e nome host:

ping server-sql.example.local
nslookup server-sql.example.local

Se il nome non risolve o punta all’indirizzo sbagliato, non ha senso proseguire con altre prove prima di sistemare DNS o file hosts, se presente una deroga controllata. Se invece la rete risponde ma il setup continua a fallire, sposta l’attenzione su permessi, servizi e prerequisiti software.

Correzione minima: sistemare la causa, non il sintomo

La regola operativa è correggere il requisito minimo che sblocca il controllo, non fare pulizie generiche. Se manca una feature di Windows, installa solo quella. Se il problema è un riavvio pendente, completa il reboot e ripeti il check. Se il setup non riesce a raggiungere SQL, verifica account, firewall e naming senza toccare l’istanza database. Se il prereq check segnala un componente ConfigMgr residuo, rimuovi in modo mirato quel residuo e non l’intero stack.

Un caso ricorrente riguarda i ruoli site system. Se il prerequisito fallisce perché il server non risponde come atteso, controlla prima che il ruolo sia effettivamente installato e che il servizio sia in esecuzione. In secondo luogo verifica i log del ruolo, perché il setup può vedere il servizio presente ma il componente in errore. Questo distingue un semplice problema di stato da una configurazione davvero errata.

Se il problema riguarda il client, il classico errore di prerequisito si risolve spesso pulendo lo stato locale e rilanciando l’installazione con parametri coerenti. Qui la prudenza è importante: non cancellare directory o chiavi di registro a caso. Prima raccogli evidenza, poi applica una rimozione selettiva e reversibile. Se serve, disinstalla il client in modo controllato, salva il log e reinstalla con la policy corretta.

Esempio operativo: prerequisito bloccato da SQL o permessi

Uno scenario tipico è il setup che si ferma perché non riesce a completare il controllo verso SQL. In questi casi il wizard può mostrare un errore poco esplicito, mentre nel log compare il fallimento dell’autenticazione o della connessione. La causa reale può essere una delle seguenti: account di installazione senza diritti sufficienti, nome istanza errato, firewall che blocca la porta, TLS/cipher incompatibile, oppure una risoluzione DNS non coerente con l’endpoint che SQL espone davvero.

La sequenza corretta è:

1. Conferma il nome esatto del server SQL e dell’istanza nel wizard.
2. Verifica che l’account usato dal setup abbia i privilegi richiesti, senza assegnare diritti più ampi del necessario.
3. Controlla che la porta sia raggiungibile dal server ConfigMgr con un test di connettività.
4. Esamina il log del setup nello stesso timestamp dell’errore per capire se il problema è autenticazione, timeout o risoluzione nome.
5. Riesegui il prereq check solo dopo aver corretto il punto che fallisce davvero.

Questo approccio riduce il blast radius: tocchi solo credenziali, rete o configurazione dell’istanza, senza cambiare il database o il site server. Il rollback è semplice: ripristini il valore precedente del parametro o i permessi originari dell’account, se avevi già fatto una modifica temporanea documentata.

Quando il problema è l’ambiente e non il setup

Ci sono casi in cui il prereq check è corretto e il vero problema è l’ambiente sottostante. Succede spesso con server già usati in precedenza, con snapshot ripristinati male, con componenti AD modificati fuori finestra o con baseline di sicurezza che hanno inasprito TLS e cifrature. In questi casi il setup non può “aggirare” il blocco: devi riallineare il sistema al supporto richiesto.

Se sospetti un conflitto con hardening o policy, il controllo utile è confrontare lo stato reale con i requisiti supportati dalla versione di ConfigMgr che stai installando. La verifica può richiedere un audit minimale: versioni OS, patch level, componenti .NET, configurazione IIS, policy di sicurezza locali, stato dei certificati e compatibilità SQL. Non serve aprire tutto: basta isolare il requisito che non rientra nella matrice supportata.

Come evitare che l’errore torni al prossimo upgrade

La prevenzione in ConfigMgr è soprattutto disciplina operativa. Prima di un change, conserva uno snapshot logico dello stato: versioni, ruoli, patch, account di servizio, prerequisiti installati e dipendenze esterne. Non è un vezzo documentale: è il modo più veloce per capire se un nuovo blocco deriva da un cambiamento recente o da un problema latente che era già presente.

Conviene anche standardizzare tre verifiche prima di ogni installazione o upgrade: salute del sistema operativo, raggiungibilità dei servizi esterni e coerenza dei permessi. Se queste tre aree sono sane, la probabilità di incappare in un prereq check ambiguo cala molto. Se una di esse è già sporca, il setup diventa solo il punto in cui il guasto viene finalmente dichiarato.

Per gli ambienti più grandi, è utile tenere un runbook con il percorso dei log, i prerequisiti attesi e i comandi di verifica rapida. Non serve un documento lungo: bastano i riferimenti giusti per evitare di cercare ogni volta dove si trova l’informazione. In pratica, meno tempo perso a “navigare” e più tempo speso a correggere la vera causa.

Checklist finale da usare prima di rilanciare il controllo

Prima di ripetere la verifica, assicurati di avere un esito chiaro su questi punti:

• Il log mostra il prerequisito fallito in modo esplicito, non solo un errore generico.
• La correzione applicata è minima e reversibile.
• Hai verificato con un test concreto che la causa sia stata rimossa.
• Non hai introdotto un nuovo rischio su SQL, DNS, certificati o permessi.
• Hai conservato il riferimento al log e al timestamp per eventuale confronto post-change.

Se dopo queste verifiche il prereq check continua a fallire, il problema non è nel singolo requisito ma nella topologia o nella versione del componente che stai cercando di installare. A quel punto la strada corretta è confrontare il requisito con la matrice di supporto della release specifica e capire se stai cercando di applicare un ruolo o un aggiornamento in un contesto non compatibile.

Assunzione: i log e i nomi dei file citati possono variare leggermente in base alla versione di ConfigMgr e al tipo di operazione eseguita, quindi il primo passo resta sempre identificare il log che contiene il timestamp esatto del fallimento.