Errore 1603 in SCCM: cosa significa davvero
L’errore 1603 durante l’installazione di SCCM non è una diagnosi, è un sintomo. In pratica il setup sta dicendo che l’installazione è fallita in modo generico, ma la causa reale va cercata nei prerequisiti, nei permessi, nello stato della macchina o nei log del componente che sta tentando di installarsi. In un contesto Microsoft, questo capita spesso con il client Configuration Manager, con i prerequisite checks del site server, con l’installazione di ruoli o con componenti collaterali come SQL, IIS o .NET.
La trappola classica è trattare il 1603 come un errore unico. Non lo è. Se il setup fallisce, la prima domanda non è “come lo disattivo?”, ma quale layer ha rotto la catena: permessi, reboot pendente, conflitto di versione, antivirus, file in uso, prerequisito mancante, oppure un’azione custom dell’MSI che è andata in timeout o ha restituito un codice non gestito.
Dove guardare prima: il layer che rompe l’installazione
In ordine pratico, il controllo va fatto così: sistema operativo, prerequisiti, servizio/installer, poi log SCCM. Se salti direttamente al setup di Configuration Manager, perdi tempo. Il 1603 arriva spesso quando Windows Installer non riesce a completare una transazione per motivi locali, non perché SCCM “non funziona” in astratto.
Se stai installando il client SCCM, i file più utili sono in C:\Windows\CCMSetup\Logs\ccmsetup.log e, dopo l’installazione, in C:\Windows\CCM\Logs\. Se invece il problema è su un site server o su un ruolo, i log da leggere dipendono dal componente, ma il pattern è lo stesso: prima il log del bootstrap, poi il log del prerequisito, infine il log del componente vero e proprio.
Diagnosi rapida: le 3 cause più probabili
1. Reboot pendente o installazione precedente incompleta. È la causa più comune. Un aggiornamento Windows, un driver, un MSI precedente o un componente SCCM già parzialmente installato possono lasciare il sistema in uno stato non coerente. Il setup vede il problema e chiude con 1603.
2. Permessi o contesto di esecuzione insufficienti. Anche se l’account sembra amministratore, il setup può essere lanciato senza elevazione corretta, da un task schedulato, o con policy che bloccano l’accesso a cartelle e registry key richieste dall’installer.
3. Conflitto con antivirus, EDR, file in uso o prerequisito mancante. Molti setup SCCM toccano file, servizi e registry in modo intenso. Se un processo tiene un file aperto, o se un prodotto di sicurezza blocca una scrittura in Program Files o nel registry, il risultato può essere un 1603 senza messaggi chiari nella GUI.
Verifiche immediate sui log e sullo stato del sistema
Qui serve evidenza, non supposizioni. Prima di cambiare qualcosa, raccogli i segnali minimi.
Controlla il log del setup. Per il client SCCM:
type C:\Windows\CCMSetup\Logs\ccmsetup.log | moreCerca stringhe come Return code 1603, MSI failure, Prerequisite check failed, pending reboot, access denied, file in use.
Verifica se il sistema ha un reboot pendente. In ambiente Windows, un controllo rapido può essere fatto così:
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequiredSe una delle chiavi esiste, hai una pista forte. Non è una prova assoluta, ma è abbastanza per fermarsi e pianificare il riavvio.
Controlla i servizi coinvolti e il motore MSI:
sc query msiserver
sc query ccmexecSe il servizio Windows Installer non è avviabile o il client è in uno stato incoerente, il setup può fallire a cascata.
Verifica spazio disco e stato base della macchina:
wmic logicaldisk get caption,freespace,sizeUno spazio insufficiente su C: è un classico sottovalutato. Anche con decine di GB liberi, alcune installazioni falliscono se la cartella temporanea o la directory di staging non sono disponibili o sono bloccate.
Guarda Event Viewer se il log applicativo non basta. I canali utili sono Application e System, con eventi di MsiInstaller, errori di servizio o blocchi da parte di security software.
Soluzione consigliata passo-passo
La regola è semplice: fai la correzione minima reversibile che elimina la causa più probabile, poi rilancia il setup e verifica se il codice cambia. Se resta 1603, non insistere alla cieca: passa alla pista successiva.
Pulisci lo stato pendente senza toccare dati applicativi. Se trovi un reboot pendente, esegui il riavvio in una finestra controllata. È l’intervento meno invasivo e spesso il più efficace. Dopo il riavvio, rilancia il setup e controlla se il log prosegue oltre il punto di errore precedente.
Esegui l’installazione con privilegi elevati e da percorso locale. Evita share di rete instabili o path lunghi. Copia il pacchetto in una directory locale semplice, ad esempio C:\Temp\SCCM, poi lancia il setup da una sessione elevata.
mkdir C:\Temp\SCCM
copy \\server\share\setup.exe C:\Temp\SCCM\
cd /d C:\Temp\SCCM
setup.exe /? Se il setup supporta parametri di logging, attivali. Il punto non è “farlo partire”, ma ottenere un log utile.
Disattiva temporaneamente la componente di sicurezza solo se il contesto lo consente e con rollback chiaro. Se l’EDR o l’antivirus sta bloccando l’installer, crea una finestra di esclusione limitata a processo, cartella o hash del pacchetto, non un bypass globale. Il blast radius deve restare ridotto. Annotare la modifica è obbligatorio: chi la applica, quando, e come viene rimossa.
Ripara prerequisiti o componenti mancanti. Se il log mostra errori legati a .NET, VC++ runtime, IIS, Windows ADK, SQL Native Client o altri prerequisiti, correggi solo quello che manca. In un deployment SCCM, installare “tutto” senza leggere il prerequisito fa perdere tempo e introduce rumore.
Controlla permessi e path di lavoro. L’account che esegue il setup deve avere accesso in scrittura alle directory di staging, ai log e alle chiavi di registry usate dall’installer. Se il setup gira tramite task o automazione, verifica il contesto del servizio e non solo l’account nominale.
Se il client SCCM è già presente ma rotto, rimuovi in modo pulito prima di reinstallare. Non sovrascrivere uno stato corrotto senza capire cosa è rimasto. Verifica se ccmsetup, ccmexec e le cartelle C:\Windows\CCM e C:\Windows\CCMSetup sono coerenti. Se devi intervenire, fallo con cautela e documenta il rollback.
Rilancia il setup con log dettagliato. L’obiettivo è vedere un cambio di comportamento nel log, non solo “riprovare”. Se il codice resta 1603 ma la riga precedente cambia, sei più vicino alla causa reale.
Esempio pratico di lettura del log
Un log utile non dice solo “failed”. Dice dove e perché. Per esempio, se trovi una sequenza del tipo:
MSI (s) (34:10) [12:45:21:123]: Product: Configuration Manager Client -- Installation failed.
Action ended 12:45:21: InstallFinalize. Return value 3.
Error 1603. Fatal error during installation.questa parte da sola non basta. Devi risalire alle righe precedenti. Se subito prima compare Access denied, il problema è di permessi. Se compare Another installation is in progress, il problema è un conflitto MSI. Se compare Pending reboot, il problema è lo stato del sistema. Se compare un codice di una custom action, il problema è nel componente chiamato dal setup, non nel setup in sé.
Se usi Microsoft Support tools o verbose logging, cerca sempre il primo errore significativo, non l’ultimo. Il 1603 è spesso la conseguenza finale di una catena di errori precedenti.
Quando il problema è nel site server e non nel client
Se l’errore avviene durante l’installazione di SCCM su un server, la logica cambia poco ma cambiano i punti di verifica. Il focus va su IIS, SQL, ADK, .NET, permessi del service account e prerequisiti di Windows Server. Un 1603 in questo scenario può derivare da un ruolo non installabile, da una feature Windows disallineata o da un componente già presente in versione incompatibile.
Qui i controlli utili sono:
Se il setup fallisce su un prerequisito, non andare avanti “a tentativi”. Correggi il prerequisito, verifica con il log che sia davvero risolto, poi riparti. In ambienti di produzione, ogni retry non motivato aumenta il rumore e il rischio di lasciare il sistema in uno stato parziale.
Errore 1603 e sicurezza: cosa non fare
La soluzione sbagliata tipica è disattivare in modo permanente antivirus, UAC o controlli di sicurezza “per vedere se va”. È una cattiva pratica operativa. Se devi ridurre la protezione per isolare il problema, fallo con una modifica temporanea, documentata e limitata al minimo indispensabile. Dopo il test, ripristina tutto.
Stesso discorso per le credenziali: non inserire password in chiaro in script o file di log. Se il setup richiede un account di servizio, usa il meccanismo previsto dalla piattaforma o un vault appropriato. Se hai già esposto un segreto, ruotalo prima di andare oltre.
Rollback e verifica finale
Ogni intervento che tocchi servizi, prerequisiti o policy deve avere un rollback chiaro. Se hai creato esclusioni sull’EDR, rimuovile. Se hai riavviato, verifica che il sistema torni nello stato atteso. Se hai modificato un pacchetto o un path, conserva la versione originale per confronto.
Rilancia il setup e conferma che il log non si fermi più allo stesso punto.
Verifica che il servizio SCCM, se previsto, sia in esecuzione:
sc query ccmexecControlla che i log successivi alla fase di installazione mostrino completamento e non retry continui o errori di auto-riparazione.
Se il problema persiste, confronta il nuovo log con il precedente. Se il punto di arresto cambia, hai ristretto il campo. Se resta identico, torna alla causa più probabile e valida un prerequisito alla volta.
Assunzione operativa: il codice 1603 viene trattato come errore di installazione locale fino a prova contraria; la correzione parte sempre da log, stato del sistema e prerequisiti, non da reinstallazioni cieche.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.