1 18/05/2026 3 min

Se il database risponde ma le query sono lente, non forzare subito rebuild o manutenzioni pesanti in produzione. La mitigazione minima è verificare spazio libero, stato dei file di log e crescita anomala. Se serve, programma un intervento controllato con finestra e rollback, perché toccare SUSDB senza osservabilità adeguata può peggiorare il problema invece di risolverlo.

Policy SCCM e sincronizzazione: configurazione coerente o guasto garantito

Una parte dei problemi nasce da configurazioni non allineate tra il ruolo Software Update Point e il server WSUS. Versione del prodotto, prodotti classificati, lingue, punti di sincronizzazione, proxy e modalità SSL devono essere coerenti. Se cambi un parametro in SCCM e non lo replichi nel punto corretto di WSUS o nel sito IIS, ottieni uno stato ibrido che spesso sopravvive ai primi test ma fallisce alla sincronizzazione successiva.

Qui conviene ragionare come su un change controllato: una modifica alla volta, verifica dopo ogni step, e nessuna assunzione implicita. Se la sincronizzazione fallisce dopo una variazione recente, il rollback più pulito è riportare il ruolo alla configurazione precedente e confermare che il problema sparisca. Questo ti dice subito se il guasto è introdotto dal change o se era già presente e solo reso visibile dal cambio di carico.

Sequenza pratica di troubleshooting senza perdere tempo

Un ordine sensato evita di fare interventi casuali. Prima validi la raggiungibilità della porta e il nome host. Poi controlli IIS e il certificato. Solo dopo guardi i log di SCCM e WSUS. Se tutto è formalmente corretto ma il sync fallisce ancora, passi al database e alle risorse del server. Questo ordine riduce i falsi positivi e ti evita di “curare” il sintomo sbagliato.

  1. Verifica DNS e connettività verso il nome usato da SCCM, non verso un IP preso a mano.
  2. Verifica binding IIS, stato del sito e dell’application pool.
  3. Conferma certificato, chain e corrispondenza del nome.
  4. Leggi i log del ruolo SCCM SUP e quelli di WSUS/IIS per l’errore originario.
  5. Controlla SUSDB, spazio disco e saturazione risorse se i primi quattro livelli sono sani.

Se vuoi una scorciatoia utile, cerca di rispondere a una sola domanda per volta: “la richiesta parte?”, “arriva a IIS?”, “viene accettata dal certificato?”, “WSUS riesce a processarla?”, “SCCM riceve un esito coerente?”. Quando una di queste risposte è no, hai già il perimetro del problema.

Mitigazione rapida e rollback pulito

Se il problema impatta produzione, la priorità non è la rifinitura architetturale ma la mitigazione. Se possibile, riportare temporaneamente il ruolo a una configurazione nota e stabile è meglio che inseguire una correzione incompleta. In ambienti con più SUP, il failover operativo verso un nodo sano può ridurre l’impatto mentre si lavora sul nodo guasto.

Il rollback deve essere concreto: backup del binding IIS, export del certificato, copia della configurazione del ruolo SCCM e nota dei cambiamenti recenti. Se devi tornare indietro, devi sapere esattamente cosa ripristinare e in che ordine. Senza questo, ogni tentativo di rollback rischia di diventare un secondo incidente.

Controllo finale: cosa deve essere vero prima di chiudere il ticket

La chiusura non si fa quando “sembra tutto ok”, ma quando hai una prova tecnica che il flusso è tornato sano. La sincronizzazione deve completarsi, il ruolo SUP deve risultare operativo, i log non devono mostrare errori ricorrenti e un client di test deve ricevere policy e catalogo aggiornamenti secondo i tempi attesi. Se usi HTTPS, il certificato deve essere valido anche nel percorso reale usato dai servizi, non solo nel test manuale.

Assunzione: l’ambiente è un’istanza di produzione o pre-produzione critica, quindi ogni modifica a IIS, certificati, permessi o SQL va trattata come change controllato con verifica e rollback disponibili.