1 16/10/2026 9 min

Correggere l’errore di installazione del portale BitLocker SCCM

Quando il portale BitLocker in SCCM fallisce in fase di installazione, il problema raramente è “il portale” in sé: quasi sempre il blocco è a monte, tra prerequisiti mancanti, permessi sulla site server, configurazione IIS, SQL, certificati o componenti ADK/WinPE non allineati. Il modo più veloce per arrivare alla causa è trattare l’errore come un guasto di catena: prima si identifica il layer che sta fallendo, poi si corregge il singolo anello rotto, evitando di toccare tutto il resto a caso.

In pratica, il sintomo tipico è uno di questi: il setup si interrompe con errore generico, il wizard non completa la pubblicazione del sito web, la console mostra componenti installati ma il portale non risponde, oppure l’installazione finisce ma l’accesso al portale restituisce 500, 403 o pagina vuota. Il punto è distinguere tra errore di deployment, errore IIS, errore applicativo e problema di autorizzazione. Se non separi questi quattro casi, rischi di passare ore su SQL mentre il vero blocco è un binding HTTPS mancante.

Che cosa controllare prima di rilanciare il setup

Prima di rifare l’installazione, raccogli evidenza minima. Serve perché il portale BitLocker non si diagnostica bene “a sensazione”: servono log, stato IIS e stato dei prerequisiti. Se mancano questi dati, non conviene improvvisare.

  • Log del setup o del componente, di solito sotto C:\Program Files\Microsoft Configuration Manager\Logs oppure nella cartella di installazione del portale.
  • Stato del sito IIS con binding, application pool e risposta HTTP.
  • Esito dei prerequisiti: account di servizio, permessi SQL, certificato TLS, feature IIS, .NET, URL rewrite, Windows Authentication.

Se il portale è già stato installato e non risponde, il test più rapido è un controllo HTTP locale sul server stesso. Se fallisce anche in locale, il problema è quasi certamente origin, non DNS o firewall esterno.

curl -k -I https://localhost/

Atteso: codice 200, 302 o comunque una risposta coerente con l’applicazione. Se ottieni 500, 403 o timeout locale, il portale non è sano lato IIS/applicazione. Se invece in locale funziona ma da remoto no, guarda DNS, certificato pubblico, reverse proxy, firewall o WAF.

Errore più probabile: prerequisiti IIS o permessi mancanti

La causa più frequente è una combinazione di feature IIS incomplete e permessi insufficienti sull’account usato dal setup. Il portale BitLocker non tollera bene un IIS “quasi pronto”: se mancano autenticazione Windows, ASP.NET, estensioni necessarie o un application pool con identità corretta, il setup può terminare ma il sito resta inutilizzabile.

Verifica in ordine:

  1. Le feature IIS richieste sono installate.
  2. Il sito ha un application pool dedicato e non usa un’identità troppo restrittiva.
  3. L’account del setup ha permessi sufficienti su IIS, cartelle applicative e, se previsto, SQL.
  4. Il certificato usato per HTTPS è presente nello store corretto e la chiave privata è accessibile.

Un controllo utile è confrontare i moduli IIS caricati con quelli attesi. Se il portale usa autenticazione Windows ma il modulo non è presente, il login non funzionerà anche se il setup sembra concluso.

Get-WindowsFeature Web-Server, Web-Windows-Auth, Web-Asp-Net45, Web-Mgmt-Tools | Format-Table DisplayName, InstallState

Atteso: tutti i componenti necessari in stato Installed. Se uno manca, installalo prima di riprovare il setup. Questo è un cambio reversibile e a basso rischio: il blast radius è limitato al server IIS interessato.

Verifica del setup log: dove si rompe davvero

Il log è la prova più importante. In ambiente Microsoft il setup spesso riporta un errore generico a video ma lascia dettagli utili nel file di log. Cerca stringhe come access denied, cannot create virtual directory, SQL login failed, certificate not found, application pool identity o HTTP 500. Sono indizi molto più affidabili del messaggio finale del wizard.

Select-String -Path "C:\Program Files\Microsoft Configuration Manager\Logs\*" -Pattern "Access denied|SQL|certificate|application pool|500|virtual directory" -SimpleMatch

Se il log mostra un errore di accesso negato, non inseguire subito SQL: prima verifica l’account del servizio e i permessi NTFS. Se invece compare un errore di database, controlla che il server SQL sia raggiungibile e che l’account applicativo abbia almeno i diritti richiesti dal progetto. Se il log segnala certificato mancante o binding fallito, il problema è nel layer TLS/IIS.

Controllo SQL: quando il portale arriva al database ma non riesce a scrivere

Un errore di installazione può essere causato da SQL anche se il database esiste già e il servizio risponde. Il caso tipico è un login che connette ma non ha privilegi sufficienti per creare oggetti, scrivere tabelle o leggere lo schema richiesto dal portale. In questi casi il setup parte, magari crea parte dei file, poi si interrompe quando deve inizializzare la persistenza.

Controlla lato SQL tre elementi: connettività, autenticazione e autorizzazioni. Se il portale usa un account dedicato, verifica che non sia stato cambiato, disabilitato o privato di ruoli. Se il database è su istanza remota, verifica che il firewall non blocchi la porta e che il nome DNS risolva correttamente.

Test-NetConnection sqlserver.contoso.local -Port 1433

Atteso: TcpTestSucceeded : True. Se fallisce, il setup non potrà completarsi. Se la rete è ok ma SQL rifiuta login o autorizzazioni, il messaggio di errore nel log sarà spesso più utile del wizard. In quel caso correggi il mapping dell’account o il ruolo necessario, poi rilancia il setup senza cambiare altre variabili.

Certificato e binding HTTPS: l’errore che sembra applicativo ma non lo è

Molti portali BitLocker si appoggiano a HTTPS per ragioni di sicurezza e integrazione con il resto della piattaforma Microsoft. Un certificato errato produce sintomi ambigui: il sito sembra installato, ma l’accesso fallisce, il browser segnala errore TLS, oppure il setup non riesce a registrare il binding. Non serve sostituire subito il certificato: prima va verificato che esista davvero nel negozio giusto e che la chiave privata sia accessibile dal processo IIS.

Controlla questi punti:

  1. Il certificato è in Local Computer\Personal.
  2. La chiave privata è presente.
  3. Il nome soggetto o SAN corrisponde al nome usato dal portale.
  4. Il binding HTTPS di IIS punta al certificato corretto.
netsh http show sslcert

Se il binding è sbagliato, il portale può continuare a non rispondere anche se i file applicativi sono corretti. Questa verifica ha blast radius basso: riguarda solo il binding locale del sito. Il rollback è immediato, basta ripristinare il binding precedente o il certificato precedente se era quello funzionante.

Application pool e identità del servizio

Un’altra causa molto comune è l’application pool configurato con identità non compatibile con l’applicazione. Il setup può completarsi, ma il portale non avviarsi perché il pool non riesce a leggere file, accedere al database o caricare moduli .NET. Se il problema è qui, nel log compaiono spesso errori 503, 500.19 o access denied legati a IIS.

Verifica il pool nel gestore IIS e confronta l’identità con quella prevista dal vendor o dalla tua baseline interna. Se è stata cambiata per hardening, assicurati che siano stati concessi i permessi minimi necessari sulle directory dell’app e sui secret eventualmente usati dall’integrazione. Evita di risolvere tutto mettendo l’identità su un account troppo privilegiato: funziona, ma sposta il rischio invece di eliminarlo.

Import-Module WebAdministration
Get-ItemProperty IIS:\AppPools\* | Select-Object name, processModel

Se trovi un pool inattivo o con identity non coerente, correggilo, poi riavvia solo il pool, non l’intero server. Questo mantiene il blast radius minimo e ti permette di capire se il problema era effettivamente limitato a IIS.

Sequenza consigliata di correzione

La sequenza giusta è importante quanto la correzione. Se modifichi più componenti insieme, non saprai più quale cambiamento ha risolto o peggiorato il problema. Qui sotto c’è un percorso reversibile, pensato per ridurre il rischio e isolare la causa.

  1. Salva i log attuali e lo stato IIS prima di cambiare qualsiasi cosa.
  2. Verifica e correggi le feature IIS mancanti.
  3. Controlla il certificato e il binding HTTPS.
  4. Correggi l’identità dell’application pool e i permessi NTFS.
  5. Testa la connettività SQL e i privilegi dell’account del portale.
  6. Rilancia il setup o riavvia il solo servizio interessato.

Se il tuo ambiente usa anche proxy inverso, WAF o load balancer, escludi temporaneamente il layer esterno solo per la diagnosi. Non è una correzione definitiva, ma serve a capire se il problema arriva davvero dall’app o viene alterato in transito.

curl -k -I https://localhost/
curl -k -I https://nomepubblico.portale.contoso.local/

Se il primo comando funziona e il secondo no, il problema è fuori dall’origin: DNS, proxy, certificato pubblico o WAF. Se entrambi falliscono, resta su IIS/app/SQL. Questa distinzione evita di perdere tempo su livelli sbagliati.

Rollback e controlli finali

Ogni modifica fatta per correggere l’installazione deve avere un rollback chiaro. Per le feature IIS, il rollback consiste nel rimuovere solo i componenti aggiunti se creano conflitti. Per certificati e binding, ripristina il binding precedente. Per application pool e identità, torna alla configurazione di partenza. Per SQL, ripristina i privilegi solo se la modifica ha introdotto regressioni, ma fai attenzione a non lasciare account sovrapermessi come soluzione permanente.

Dopo la correzione, verifica questi punti:

  1. Il setup termina senza errori nel log.
  2. curl -k -I restituisce una risposta valida in locale.
  3. Il sito risponde con il nome corretto e il certificato atteso.
  4. L’account applicativo accede a SQL senza errori di login o autorizzazione.
  5. Non compaiono più errori 500, 503, 403 o 500.19 nei log IIS.

Se il portale torna online ma il login o il flusso BitLocker non funzionano ancora, il problema non è più l’installazione: sei passato alla fase applicativa o di integrazione. A quel punto conviene verificare policy, autorizzazioni lato SCCM, gruppi AD e eventuali dipendenze con componenti esterni. Assunzione: ambiente Windows Server recente, IIS e SQL già presenti, portale BitLocker integrato in una site architecture SCCM standard.

Nota operativa per ambienti SCCM reali

In campo, il difetto più frequente non è la mancanza di un singolo prerequisito, ma la combinazione di due errori piccoli che si sommano: un certificato valido ma non legato al sito giusto, oppure un account con permessi quasi corretti ma non abbastanza per creare la struttura iniziale. Per questo conviene lavorare sempre per esclusione, con una modifica alla volta e una verifica immediata dopo ogni passo.

Se vuoi chiudere il problema alla radice, documenta la baseline funzionante: feature IIS, binding, identità del pool, account SQL, path dei log e versione del componente. La prossima volta che il setup fallisce, avrai un confronto oggettivo invece di una caccia al colpevole a memoria. In ambienti Microsoft complessi, questo fa la differenza tra un fix di mezz’ora e una giornata persa.