Come risolvere l'errore 1603 nella disinstallazione di SCCM Management

Errore 1603 in disinstallazione SCCM Management: dove si rompe davvero

L’errore 1603 durante la rimozione di SCCM Management non dice quasi mai “la causa”. Dice solo che l’installazione MSI è fallita in modo generico e che bisogna risalire al punto preciso del blocco. Nella pratica, le cause più frequenti sono tre: prerequisiti ancora in uso, servizi o processi che tengono occupati file e chiavi di registro, oppure un problema di permessi o stato corrotto del componente da disinstallare.

La lettura corretta è questa: non trattare il 1603 come un errore di SCCM “in sé”, ma come un sintomo del motore MSI o dello stato locale del client/server. Se il sistema è in produzione, considera l’impatto come potenzialmente esteso al management plane finché non hai verificato che la disinstallazione non stia lasciando servizi, agenti o policy in uno stato ambiguo.

Prima verifica: stato atteso vs osservato

Stato atteso: il componente SCCM Management si rimuove pulitamente, i servizi legati al ruolo si fermano, le chiavi MSI vengono rimosse e il sistema torna in uno stato coerente senza residui operativi.

Stato osservato: la disinstallazione si interrompe con codice 1603, spesso senza un messaggio utile nella GUI. In quel caso devi usare i log MSI e i log specifici del componente per capire se il blocco avviene su un file in uso, su un servizio attivo, su un permesso negato o su una configurazione corrotta.

Come leggere il 1603 senza andare a tentativi

Il punto chiave è raccogliere evidenza minima prima di cambiare qualcosa. Se mancano i log, stai lavorando al buio. I riferimenti utili sono quasi sempre questi: il log MSI in `%TEMP%`, i log del prodotto SCCM se presenti, e l’Event Viewer per eventi applicativi e di Windows Installer.

Su Windows, per una disinstallazione MSI, il log più utile si ottiene quasi sempre rilanciando il comando con verbose logging. Se hai il file MSI o il prodotto è removibile via GUID, usa una traccia completa. Se non hai il pacchetto originale, verifica prima il nome esatto del prodotto installato e l’entry Uninstall nel registro.

msiexec /x {PRODUCT-GUID} /L*v C:\Temp\sccm-uninstall.log

Se il comando viene lanciato da una console amministrativa, controlla subito il file di log per le righe finali: spesso il vero errore è qualche riga prima del 1603. Cerca termini come Return value 3, Access denied, file in use, service, custom action failed.

Diagnosi probabile

Nella maggior parte dei casi l’errore 1603 in disinstallazione SCCM Management nasce da uno di questi scenari, in ordine di probabilità:

1. Un servizio o processo del componente è ancora attivo e blocca file, driver o chiavi di registro.
2. La disinstallazione non ha privilegi sufficienti o il contesto utente non è amministrativo.
3. Il pacchetto è già parzialmente corrotto e il motore MSI non riesce a completare le custom action di cleanup.

La falsificazione rapida è semplice: se il log mostra Access denied, il problema è permessi; se mostra un handle su file o servizio, il problema è lock; se il log si interrompe su una custom action, il problema è quasi sempre stato inconsistente o prerequisito mancante.

Verifiche immediate

Prima di fare modifiche, verifica questi punti. Sono controlli reversibili e ti dicono subito se vale la pena fermarsi o procedere con una rimozione controllata.

1. Apri il log MSI generato con `/L*v` e cerca l’ultima occorrenza di Return value 3. Le righe precedenti indicano il vero motivo del fallimento.
2. Controlla i servizi legati al componente con services.msc oppure con PowerShell. Se il servizio è ancora in esecuzione, prova a fermarlo in modo pulito prima della disinstallazione.
3. Verifica se il prodotto compare in appwiz.cpl o nel ramo di uninstall del registro. Se non compare o compare in modo anomalo, il problema potrebbe essere un’installazione spezzata.
4. Controlla Event Viewer in Windows Logs > Application e System per eventi di Windows Installer nello stesso timestamp del fallimento.
5. Se il nodo è un server, verifica che non ci siano processi o console aperte che tengono il componente in uso, inclusi tool di management o snap-in MMC.

Comandi utili per raccogliere evidenza minima:

Get-Service | Where-Object {$_.DisplayName -like '*SCCM*' -or $_.Name -like '*ccm*'} | Select-Object Name, Status, DisplayName
wevtutil qe Application /q:"*[System[Provider[@Name='MsiInstaller']]]" /f:text /c:10

Se non trovi alcun evento utile, il gap è nei log: chiudilo con una disinstallazione ripetuta in modalità verbose. Senza quel file, ogni ipotesi resta debole.

Soluzione consigliata passo-passo

Questa sequenza minimizza il rischio e mantiene un rollback pratico. Non partire da cleanup aggressivi o da rimozioni forzate se non hai già dimostrato che il componente è bloccato in modo irreversibile.

1. Raccogli un log completo della disinstallazione. Se hai il GUID del prodotto, usa il comando MSI diretto con logging verbose.

msiexec /x {PRODUCT-GUID} /L*v C:\Temp\sccm-uninstall.log

Atteso: il log termina con una riga di successo o con un errore più specifico del 1603. KO: il file non viene creato o si interrompe subito, segno che il problema è nel contesto di esecuzione.

1. Ferma i servizi collegati al componente, ma solo dopo averli identificati. Se il nome del servizio non è chiaro, usa il filtro su ccm o sul nome del vendor.

Get-Service | Where-Object {$_.Name -match 'ccm|sms|sccm'} | Stop-Service -Force -PassThru

Atteso: i servizi scendono in stato Stopped. KO: il servizio torna subito in esecuzione o non si ferma, segno di dipendenze o protezioni operative.

1. Rilancia la disinstallazione con privilegi amministrativi locali e, se possibile, da una sessione pulita senza software di gestione aperto.

Atteso: la procedura avanza oltre il punto di blocco. KO: compare ancora 1603 con riferimenti a accesso negato o file occupato.

1. Se il log mostra una custom action fallita, verifica se mancano file, DLL o componenti prerequisito. In questo caso il problema non è “il 1603”, ma l’azione specifica che non riesce a completarsi.

findstr /i "Return value 3 CustomAction Access denied file in use" C:\Temp\sccm-uninstall.log

Atteso: una riga ti porta al blocco reale. KO: nessun match utile, quindi il log è troppo corto o non verboso abbastanza.

1. Se il prodotto è chiaramente corrotto e la rimozione standard non va avanti, valuta una riparazione preventiva o una reinstallazione della stessa build per ripristinare l’entry MSI, poi disinstalla. Questa è una misura di contenimento, non il primo tentativo.

Questa strada ha blast radius limitato se il nodo è un client o un server secondario. Su sistemi critici, invece, va valutata in finestra di manutenzione perché un reinstall può toccare policy, agent e servizi di telemetria.

Se il componente è in uno stato tanto incoerente da impedire sia repair sia uninstall, il passo successivo è un cleanup manuale mirato: servizi, chiavi di uninstall, cartelle residue e task pianificati. Qui però serve attenzione, perché il rischio è rimuovere troppo e lasciare il sistema senza riferimenti per un eventuale rollback. Prima di toccare registro o filesystem, esporta sempre le chiavi coinvolte.

reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" C:\Temp\uninstall-backup.reg

Rollback: reimport del file .reg esportato e reinstallazione del pacchetto originale o della stessa build, se il cleanup ha rimosso riferimenti necessari. Questo è il punto in cui il backup non è opzionale.

Quando il colpevole è un servizio o un processo in uso

Molti 1603 nascono banalmente da un servizio che non si lascia chiudere. In ambienti SCCM, agent, console e componenti correlati possono mantenere handle aperti su file DLL, cartelle di lavoro o chiavi di configurazione. Il sintomo tipico nel log è una combinazione di file in use, return value 3 e fallimento su una custom action finale.

Per isolare il processo, puoi usare gli strumenti standard di Windows o l’Activity Monitor equivalente. Se vuoi andare diretto al punto, cerca il PID del servizio e verifica gli handle aperti. In ambiente server, una console ancora aperta da un amministratore può bastare a bloccare la rimozione.

tasklist /svc | findstr /i "ccm sms sccm"
handle.exe -a C:\Path\To\SCCM\Folder

Se hai conferma che il processo è innocuo e appartiene al componente da rimuovere, fermarlo è una misura reversibile. Se invece il processo è di sistema o di un servizio condiviso, non forzare: prima identifica le dipendenze. Il rischio qui è rompere altro mentre stai cercando di togliere un solo prodotto.

Quando il problema è permessi o contesto di esecuzione

Se il log mostra Access denied, la strada è più lineare: l’operazione non sta girando con il contesto corretto o qualche ACL è stata modificata. In questi casi non serve “riprovare ancora”: serve eseguire la disinstallazione come amministratore locale e verificare che il token abbia davvero privilegi elevati.

Controlla anche che il percorso temporaneo usato da MSI sia scrivibile e che antivirus o EDR non stiano bloccando la scrittura del log o la rimozione di file eseguibili. In ambienti molto protetti, il blocco può sembrare un errore generico quando in realtà è un controllo di sicurezza che ha intercettato la custom action.

Per verificare rapidamente il contesto, puoi aprire una shell elevata e controllare la membership del token, poi ripetere la disinstallazione nello stesso contesto. Se da prompt elevato funziona e da sessione standard no, la causa è chiusa.

Quando il pacchetto è corrotto o l’entry MSI è rotta

Qui il 1603 è spesso solo la fine di una storia già compromessa. L’installazione precedente potrebbe aver lasciato un ProductCode non più coerente, una cache MSI incompleta o una custom action che punta a file non più presenti. Il risultato è una disinstallazione che non riesce a ricostruire abbastanza stato per completare il cleanup.

La correzione più pulita, quando disponibile, è reinstallare la stessa versione del componente per ricostruire l’inventario locale e poi eseguire la rimozione. È una tecnica di ripristino, non un workaround casuale. Funziona bene quando il setup originale è disponibile e non ci sono vincoli di change freeze.

Se anche la reinstallazione fallisce, il sistema è probabilmente in uno stato che richiede cleanup manuale controllato. In quel caso devi documentare cosa rimuovi, salvare export del registro e mantenere una traccia dei servizi toccati. Senza questo, il rollback diventa improvvisazione.

Controlli finali e rollback

Dopo la correzione, verifica che il componente non compaia più nell’elenco applicazioni e che i servizi associati non siano rimasti in uno stato parziale. Controlla anche che non ci siano errori ricorrenti in Event Viewer e che il log della disinstallazione termini senza nuove occorrenze di Return value 3.

Get-Service | Where-Object {$_.Name -match 'ccm|sms|sccm'} | Select-Object Name, Status
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" | Out-Null

Se hai fatto export del registro prima del cleanup, il rollback è il reimport della chiave salvata e, se necessario, la reinstallazione del pacchetto originale. Se hai fermato servizi, il controllo finale è riportarli allo stato previsto solo dopo aver confermato che la rimozione è riuscita o che il sistema deve tornare operativo con il componente presente.

Assunzione operativa: questa procedura si applica a un host Windows con disinstallazione MSI o componente SCCM locale; se il prodotto è gestito da un wrapper vendor diverso, il ProductCode, i log e le custom action vanno identificati prima di usare i comandi qui sopra.