Il problema non è la mancanza di strumenti, è l’ordine in cui si usanoWindows include più utility diagnostiche di quante un amministratore ne userà mai tutte. Eppure la causa più comune di sessioni di troubleshooting infruttuose non è l’ignoranza dei tool, ma la sequenza sbagliata: si parte da un comando di riparazione (sfc /scannow, un reset di Windows Update, un DISM al buio) prima ancora di aver capito quale sottosistema sta effettivamente fallendo. Il risultato è tempo perso, evidenze diagnostiche distrutte dal riavvio, e spesso la causa radice che resta lì, pronta a ripresentarsi la settimana successiva.Vale la pena fermarsi a formalizzare un metodo, perché è quello che separa un troubleshooting efficace da un’accozzaglia di tentativi casuali. Di seguito un processo in cinque passi, seguito da una rassegna degli strumenti chiave e da una tabella sintesi sintomo → strumento che può diventare un riferimento rapido da tenere a portata di mano durante un incidente.Un processo ripetibile prima di toccare qualsiasi comandoLa maggior parte delle sessioni di troubleshooting falliscono prima ancora che venga lanciato il primo comando. Un amministratore vede un errore, prova un comando di riparazione che conosce, riavvia, e scopre che il problema originale è ancora lì. Un approccio più solido richiede di rallentare abbastanza da stabilire una baseline:Confermare o riprodurre il problema: è cronico o è stato un episodio isolato?Registrare il sintomo esatto: messaggio di errore, orario, utente coinvolto, dispositivo, modifiche recenti.Raccogliere le evidenze dal sistema più probabilmente coinvolto.Applicare una modifica alla volta, partendo dall’opzione meno invasiva.Verificare il risultato e documentare cosa è effettivamente cambiato.Un esempio concreto: se Windows Update fallisce con un errore generico, la tentazione è resettare tutti i componenti di aggiornamento in blocco. Il primo passo corretto è invece capire in quale fase è avvenuto il fallimento — scan, download, staging, installazione o riavvio — perché questa distinzione determina se bisogna guardare i log di Windows Update, i log di servicing, lo stato del disco, la configurazione delle policy o la connettività di rete.Event Viewer: il primo posto dove cercare quando c’è un timestampEvent Viewer è il punto di partenza quando il sintomo ha un orario preciso: un crash applicativo, un riavvio inatteso, un servizio che si ferma, un problema di driver, un’installazione fallita. Si parte dai Windows Logs, filtrando Application, System e Setup per eventi Critical, Error e Warning nell’intorno temporale del problema, per poi individuare l’event source, l’event ID, il modulo che genera il fault, il nome del servizio o del driver coinvolto.Il criterio per separare il segnale dal rumore è la ripetibilità: un warning isolato di ieri è quasi sempre rumore; un errore che compare sistematicamente ogni volta che si apre una determinata applicazione è un segnale affidabile. Le evidenze diagnostiche più utili sono quelle correlate nel tempo e riproducibili, non gli eventi isolati.SFC prima, DISM solo se SFC non bastaSystem File Checker (SFC) è uno strumento di riparazione mirato per i file di sistema protetti. Si usa quando una feature nativa di Windows si comporta in modo anomalo, un componente integrato non parte, oppure Event Viewer punta a file del sistema operativo mancanti o corrotti:sfc /scannowSFC è utile perché verifica e sostituisce i file protetti senza richiedere una reinstallazione, ma dipende dal component store locale come sorgente di riparazione. Se quello store è danneggiato, SFC può segnalare corruzione trovata ma non riparabile del tutto. A quel punto il passo successivo è DISM, non ripetere SFC all’infinito sperando in un risultato diverso.Deployment Image Servicing and Management (DISM) opera a livello di image e component store, uno strato sotto SFC. Va usato quando SFC non riesce a completare le riparazioni, quando l’installazione di Windows Update o di una feature fallisce ripetutamente, o quando il problema è a livello di servicing. Il comando di riparazione online più comune:DISM /Online /Cleanup-Image /RestoreHealthIn ambienti enterprise, DISM può aver bisogno di una sorgente di riparazione affidabile — supporto di installazione, un’immagine montata, o una posizione di contenuto gestita — soprattutto quando gli endpoint non possono scaricare i contenuti di riparazione da Windows Update. Dopo che DISM completa con successo, conviene rilanciare SFC, così i file protetti possono essere riparati da un component store ormai sano.Windows Update: capire in quale fase fallisce prima di resettare tuttoIl troubleshooting di Windows Update deve partire dall’identificazione della fase fallita. Un fallimento nello scan suggerisce problemi di policy, rete, proxy o sorgente di aggiornamento. Un fallimento nel download indica problemi di connettività, disponibilità dei contenuti o cache. Un fallimento nell’installazione punta spesso allo servicing stack, al component store, allo spazio su disco, a un riavvio pendente o a un driver in conflitto.Sulle versioni moderne di Windows, Windows Update si basa su dati Event Tracing for Windows (ETW) piuttosto che scrivere un semplice log testuale in continuo. Per generare un log leggibile quando serve un dettaglio più approfondito lato client, si usa PowerShell:Get-WindowsUpdateLogVale anche controllare Event Viewer nei log operativi del client di Windows Update e il Setup log per gli eventi di installazione. Se lo stesso pacchetto KB fallisce ripetutamente, conviene verificare se l’aggiornamento è applicabile, se esiste un aggiornamento che lo sostituisce, e da quale sorgente il dispositivo riceve gli update — Windows Update diretto, Microsoft Update, WSUS, oppure una piattaforma di gestione come Intune o Configuration Manager.Un reset completo di Windows Update dovrebbe essere un passo tardivo, non il primo. Resettare i servizi e svuotare le cache può sbloccare client incastrati, ma distrugge anche evidenze utili. Meglio catturare prima il codice di errore, i log e la cronologia degli aggiornamenti.“La rete non funziona” è quasi sempre DNS o configurazioneI sintomi di rete richiedono un punto di partenza diverso, perché gli utenti spesso descrivono come “la rete è giù” un problema che in realtà è DNS, routing, autenticazione, policy del firewall o un singolo endpoint applicativo che non risponde. È corretto partire dalla configurazione TCP/IP locale prima di testare i servizi remoti.Un errore comune tra amministratori meno esperti è dare per scontato che “il ping non risponde” equivalga a “la rete è giù”. In ambienti enterprise questa assunzione è spesso sbagliata: molti sistemi sono configurati per ignorare le richieste ICMP pur continuando a erogare regolarmente il servizio previsto. Un firewall può bloccare ICMP, una policy di sicurezza può disabilitare le risposte, un servizio cloud può non rispondere mai al ping. La domanda giusta non è se un dispositivo risponde al ping, ma se il servizio richiesto è effettivamente raggiungibile: bisogna sempre testare ciò che l’utente sta effettivamente cercando di usare, con strumenti come ipconfig, nslookup e tracert mirati sul servizio specifico.Tabella di riferimento rapido: sintomo → strumentoSintomoPartire daPerchéApp che va in crash o si chiude inaspettatamenteEvent Viewer, poi Reliability MonitorIdentifica moduli in fault, errori applicativi e pattern di modifiche recentiWindows Update fallisce ripetutamenteLog di Windows Update, Setup log, DISMSepara i fallimenti di scan, download, installazione e servicingFeature di Windows mancanti o instabiliSFC, poi DISM se SFC non riparaRipara i file di sistema protetti e il component store sottostanteUtenti non raggiungono risorse di reteipconfig, ping, nslookup, tracertValida configurazione locale, raggiungibilità, DNS e routing in ordineLe performance degradano improvvisamenteTask Manager, Resource Monitor, Event ViewerCorrela la pressione sulle risorse con servizi, driver ed erroriReliability Monitor merita una menzione a parte perché offre una vista a timeline di crash applicativi, fallimenti di Windows, installazioni di driver ed eventi di aggiornamento. È meno dettagliato di Event Viewer, ma resta eccellente per individuare rapidamente cosa è cambiato immediatamente prima che iniziasse un problema ricorrente.Costruire il proprio toolkit di troubleshootingPer un professionista IT, l’abilità di troubleshooting più preziosa non è memorizzare comandi, ma sapere quale fonte di evidenza fidarsi per una determinata classe di problema. Event Viewer dice cosa Windows ha registrato; Reliability Monitor mostra quando i problemi sono iniziati. Una checklist pratica da seguire durante un incidente:Registrare sintomi esatti, orario, dispositivo, utente e modifiche recenti.Controllare i log più rilevanti prima di applicare riparazioni ad ampio raggio.Eseguire i comandi di riparazione da un terminale elevato e catturarne l’output.Cambiare una variabile alla volta, per sapere con certezza cosa ha risolto il problema.Verificare dal punto di vista dell’utente, non solo dalla console amministrativa.Questa disciplina previene due errori tipici: eseguire riparazioni distruttive troppo presto, e dichiarare vittoria prima di aver verificato il flusso di lavoro reale. Se un utente non riesce ad aprire una condivisione di rete, un ping riuscito non è il traguardo: il traguardo è l’utente che apre la condivisione, accede ai file attesi e conferma che il problema non si ripresenta.ConclusioneLa differenza tra una sessione di troubleshooting produttiva e una frustrante raramente sta nella conoscenza di comandi avanzati. Sta nel partire dal sintomo invece che dal comando, chiedersi quale evidenza confermerebbe o smentirebbe la causa più probabile, e solo a quel punto scegliere lo strumento che fornisce quell’evidenza nel modo più veloce. È questa disciplina che trasforma una collezione di utility in un vero toolkit diagnostico.Fonte: Critical Windows Troubleshooting Tools: Stop Wasting Time on the Wrong Fixes, Petri IT Knowledgebase

Se la vostra organizzazione ha già spostato la maggior parte dei carichi rivolti agli utenti su Microsoft 365, Intune e Microsoft Entra ID, è lecito chiedersi perché esista ancora un Domain Controller che gira in produzione. La risposta più comune è “così abbiamo sempre fatto”, ed è esattamente la definizione di debito tecnico: un’infrastruttura che continua a costare in manutenzione, superficie di attacco e complessità operativa senza generare più un valore proporzionato. L’identità ibrida, con Entra Connect che sincronizza un Active Directory locale verso il cloud, è diventata per molte aziende proprio questo tipo di debito.Non si tratta di demonizzare l’ibrido: per organizzazioni con applicazioni legacy pesantemente dipendenti da NTLM, LDAP o Kerberos, mantenere un ponte con l’on-premise è spesso l’unica scelta razionale. Il punto è che la decisione va presa consapevolmente, dopo un inventario reale delle dipendenze, e non per inerzia.Perché il cloud-only conviene, quando è applicabilePer un’organizzazione che gira già prevalentemente su Entra ID, Microsoft 365 e client Windows moderni, il modello cloud-only centralizza la gestione IT e accelera l’accesso a nuove funzionalità di sicurezza che spesso arrivano prima, o esclusivamente, sui tenant che non dipendono più da sincronizzazione ibrida. I vantaggi concreti che spingono in questa direzione sono quattro:Riduzione del carico operativo: patching, alta disponibilità e scalabilità dei Domain Controller passano al provider cloud.Postura di sicurezza migliore: funzionalità come Conditional Access granulare, Identity Protection e governance degli accessi privilegiati sono nativamente più semplici da applicare senza il vincolo di compatibilità con AD locale.Costi più prevedibili: si eliminano hardware ridondante, licenze Windows Server per i DC e il tempo ingegneristico dedicato a mantenerli in salute.Velocità di adozione: nuove capacità (passkey, agenti AI con identità propria, automazioni Conditional Access) arrivano più rapidamente su tenant che non devono conciliarsi con un’infrastruttura ibrida.L’errore più comune: migrare l’infrastruttura prima di validare le dipendenzeIl fallimento tipico di un progetto cloud-only non è tecnico, è di sequenza: i team iniziano a spegnere server e migrare workload prima di aver mappato davvero cosa dipende ancora da Active Directory. Un approccio più solido segue queste fasi.1. Mappare i carichi di lavoro che bloccano il cloud-onlyPartite da un audit completo di infrastruttura, applicazioni, dati e dipendenze. Non fermatevi alla lista delle VM: cercate esplicitamente le dipendenze che raramente compaiono nei piani di migrazione di alto livello, perché sono quelle che tengono in vita Entra Connect molto più a lungo del necessario:Applicazioni che richiedono ancora query LDAP diretteService account legacy non documentatiApplicazioni con autenticazione NTLM hard-codedImpostazioni di Group Policy che nessuno ha mai rivistoServizi certificati (ADCS) che presuppongono un Domain Controller sempre raggiungibile2. Definire l’architettura cloud che volete davvero gestireStabilite obiettivi chiari su performance, disponibilità, sicurezza e compliance prima di scegliere gli strumenti. Decidete se una strategia single-cloud o multi-cloud è coerente con la vostra tolleranza al rischio e con le competenze del team, non solo con il marketing del vendor.3. Modernizzare l’identità prima di spegnere Active DirectoryQui sta il cuore del progetto. Rivedere la strategia IAM significa garantire autenticazione robusta, accesso a privilegio minimo e protezione dell’identità sfruttando gli strumenti nativi di Entra ID per unificare la gestione utenti su tutti i servizi, invece di replicare in cloud le stesse logiche pensate per un dominio locale.4. Ridisegnare la connettività attorno all’accesso cloud, non al data centerMolte architetture di rete sono ancora progettate assumendo che il traffico debba passare da un data center centrale. Un modello cloud-only ribalta la logica: la connettività va progettata per l’accesso diretto ai servizi cloud, sfruttando le backbone dei provider e i servizi di sicurezza integrati, sia per utenti in ufficio sia da remoto.5. Trattare le applicazioni legacy come il vero collo di bottigliaFile share, servizi di stampa, applicazioni gestionali interne e integrazioni con piattaforme di terze parti datate sono i blocchi reali dei progetti cloud-only, molto più della migrazione di VM o storage. Un’applicazione finance che si aspetta autenticazione Windows integrata, un sistema di magazzino che dipende da query LDAP o una file share con permessi ereditati da anni possono rallentare il progetto più di qualunque altro fattore. Per ciascuna, valutate lift-and-shift, refactoring o riscrittura in base a complessità e valore strategico.6. Ricostruire la governance per un modello operativo cloud-firstAggiornate le policy per riflettere una postura cloud-first, automatizzate il reporting di compliance e sfruttate strumenti di sicurezza nativi cloud per cifratura, rilevamento minacce e incident response, invece di adattare policy pensate per l’on-premise.7. Preparare il team IT al cambio operativoInvestite nella formazione sulle competenze cloud-specifiche, comunicate i cambiamenti con chiarezza e create canali di supporto e feedback per intercettare problemi prima che diventino bloccanti.Cosa si rompe per primo in una migrazione cloud-onlyAnche con una pianificazione accurata, alcuni punti critici emergono quasi sempre:Dipendenze nascoste da Active Directory: connessioni LDAP hard-coded, service account non gestiti, applicazioni dipendenti da NTLM o flussi di autenticazione mai documentati. Vanno inventariati prima di ritirare i Domain Controller o disattivare la sincronizzazione.Blocchi operativi da Conditional Access e MFA: l’enforcement di Conditional Access e multi-factor authentication migliora la sicurezza, ma una sequenza sbagliata può bloccare fuori gli amministratori o interrompere l’accesso a servizi critici. Testate sempre account di emergenza, opzioni di rollback e flussi di accesso privilegiato prima di un enforcement ampio.Resistenza culturale: il cambiamento comporta rischio percepito; serve chiarezza sui benefici e sui nuovi ruoli per ridurre lo scetticismo dei team.Interruzioni di servizio: pianificate la migrazione a fasi, con pilot e backup, per minimizzare l’impatto sul business.Il test pratico per capire quanto siete lontani dal cloud-onlySe la vostra organizzazione ha già adottato Microsoft 365, Intune ed Entra ID per la maggior parte dei carichi rivolti agli utenti, l’identità ibrida va trattata come debito tecnico, a meno che non abbiate una ragione precisa e documentata per mantenerla. Prima di pianificare una migrazione cloud-only, identificate ogni dipendenza residua da Active Directory: se la maggior parte supporta già l’autenticazione moderna, probabilmente siete più vicini al cloud-only di quanto pensiate.Per i sistemisti che gestiscono ambienti Microsoft, il consiglio pratico è iniziare da un inventario mirato: interrogate Entra Connect per capire quali oggetti sincronizzati sono ancora effettivamente in uso, verificate quali applicazioni autenticano ancora tramite Kerberos/NTLM controllando i log di sicurezza dei Domain Controller, e mappate le Group Policy applicate per capire quali impostazioni di sicurezza andranno ricreate tramite Intune prima di spegnere l’ultimo controller di dominio.ConclusioneLa migrazione a cloud-only non è un progetto infrastrutturale, è un progetto di identità. Le organizzazioni che falliscono di solito partono dal lato sbagliato del problema, migrando VM e storage prima di aver capito cosa dipende ancora da un dominio Active Directory che nessuno ha mai documentato del tutto. Chi parte invece dall’inventario delle dipendenze di identità, tratta l’ibrido come uno stato temporaneo e non come un’architettura permanente, arriva a un ambiente più semplice da gestire, più sicuro per costruzione e meno costoso da mantenere nel tempo.Fonte: Why Hybrid Identity Becomes Technical Debt and How to Move to Cloud-Only, Petri IT Knowledgebase (Dean Ellerby).

Il 9 luglio 2026 Microsoft ha rilasciato la correzione per RoguePlanet, una vulnerabilità zero-day nel Malware Protection Engine di Microsoft Defender che permetteva a un attaccante con accesso locale di ottenere privilegi SYSTEM su qualsiasi macchina Windows 10 o Windows 11 completamente aggiornata. Il dettaglio che rende questo bug particolarmente istruttivo per chi amministra flotte Windows non è tanto la gravità – con un CVSS 4.0 di 7.8 non è la falla più critica dell’anno – quanto il fatto che a essere vulnerabile sia proprio il componente che dovrebbe proteggere il sistema, e che il proof-of-concept pubblico funzioni indipendentemente dallo stato della protezione in tempo reale.Cos’è RoguePlanet (CVE-2026-50656)RoguePlanet è tracciata come CVE-2026-50656 ed è una vulnerabilità di elevazione dei privilegi locale nel Microsoft Malware Protection Engine, il motore di scansione condiviso da Defender e da altri prodotti Microsoft di sicurezza. La causa tecnica è una improper link resolution before file access, in pratica una race condition simile alle classiche TOCTOU (time-of-check to time-of-use): il motore di scansione risolve un percorso o un link simbolico/junction in un momento diverso da quello in cui accede effettivamente al file, e questa finestra temporale può essere sfruttata per far operare il processo, che gira con privilegi SYSTEM, su un file diverso da quello previsto.Il ricercatore che ha scoperto e divulgato pubblicamente il bug, noto con lo pseudonimo Chaotic Eclipse (in alcune fonti riportato come Nightmare-Eclipse), ha pubblicato dettagli tecnici e codice exploit già a giugno 2026, prima che Microsoft rilasciasse una patch, nel contesto di una disputa pubblica con l’azienda sulle tempistiche di risposta alle segnalazioni di vulnerabilità. Questo ha reso RoguePlanet una vulnerabilità “N-day pubblica” per diverse settimane, con Microsoft che ha classificato lo sfruttamento come “Exploitation More Likely” sul proprio Exploitability Index.Perché disattivare Defender non è una mitigazione validaUn dettaglio operativo importante per chi ha dovuto gestire l’incidente: il proof-of-concept pubblicato funziona indipendentemente dal fatto che la protezione in tempo reale sia attiva o meno. Questo significa che la contromisura “tampone” spesso adottata in scenari di zero-day – disattivare temporaneamente il modulo vulnerabile finché non arriva la patch – non era efficace in questo caso, perché il motore di scansione resta comunque presente e invocabile sul sistema anche a protezione realtime disattivata.Come funziona l’attacco in praticaRoguePlanet è un exploit post-compromise: non è una falla che consente l’accesso iniziale a un sistema, ma serve ad ampliare i privilegi una volta che l’attaccante ha già ottenuto un punto d’appoggio, ad esempio tramite credenziali rubate, malware, phishing o un’altra vulnerabilità. Lo schema tipico è:L’attaccante ottiene accesso come utente standard (senza privilegi amministrativi) su un endpoint Windows.Sfrutta la race condition nel Malware Protection Engine per far scrivere, sostituire o manipolare un file in un percorso controllato dall’attaccante mentre il motore opera con privilegi SYSTEM.Ottiene l’esecuzione di codice arbitrario con privilegi SYSTEM, uscendo di fatto dal sandbox dei permessi utente.Da lì può disabilitare protezioni, esfiltrare dati, installare impianti persistenti o muoversi lateralmente nella rete.È lo schema classico che trasforma una compromissione limitata (un singolo account utente) in una compromissione totale della macchina, ed è per questo che le vulnerabilità di questo tipo vengono trattate con priorità alta anche quando il CVSS non è altissimo: il vettore di attacco (locale, bassa complessità, nessuna interazione utente richiesta) le rende un tassello estremamente efficiente nelle catene di attacco moderne, specie quelle assistite da AI dove le fasi di privilege escalation e lateral movement vengono automatizzate.Cosa fare subitoLa buona notizia è che la correzione è già disponibile e, trattandosi di un aggiornamento del motore antimalware, viene distribuita automaticamente tramite gli aggiornamenti regolari delle definizioni, senza richiedere un intervento manuale sugli endpoint. La versione corretta del Malware Protection Engine è la 1.1.26060.3008 o successiva. Ecco però una checklist di verifica utile in ambienti gestiti:# Verifica la versione del Malware Protection Engine su un endpoint Windows Get-MpComputerStatus | Select-Object AMEngineVersion, AMProductVersion, AntivirusSignatureLastUpdated # Forza un aggiornamento immediato delle definizioni e del motore Update-MpSignature -UpdateSource MicrosoftUpdateServer # In ambienti con Configuration Manager / WSUS, verifica la data # dell'ultimo aggiornamento delle definizioni su tutta la flotta Get-MpComputerStatus | Select-Object ComputerID, AMEngineVersion | Export-Csv -Path C:\Reports\defender-engine-status.csv -NoTypeInformationSe gestisci endpoint tramite Microsoft Defender for Endpoint, puoi verificare la copertura a livello di flotta dal portale Security, sezione Reports > Microsoft Defender Antivirus, filtrando per versione del motore. In ambienti air-gapped o con aggiornamenti WSUS ritardati, questo è il momento di controllare che la cadenza di distribuzione delle definizioni non stia introducendo un ritardo superiore a qualche giorno rispetto al rilascio Microsoft.Indicatori di compromissione da monitorarePer chi sospetta un possibile sfruttamento avvenuto prima della patch, Microsoft e i ricercatori indipendenti suggeriscono di dare priorità ai seguenti segnali in fase di threat hunting:Processi SYSTEM anomali generati da MsMpEng.exe o da altri componenti del Malware Protection Engine, specialmente se seguiti dall’avvio di una shell (cmd.exe, powershell.exe).Modifiche non pianificate alle impostazioni o ai servizi di Microsoft Defender, incluse disattivazioni temporanee della protezione in tempo reale non riconducibili a policy note.Creazione di attività pianificate (scheduled task) sospette nella stessa finestra temporale di scansioni antimalware.Nuovi meccanismi di persistenza (servizi, chiavi di avvio, WMI event subscription) creati con privilegi SYSTEM da processi non abituali.Al di là del singolo CVE, RoguePlanet è un buon promemoria di un principio generale di hardening: restringere i privilegi standard degli utenti, limitare l’esecuzione di codice non autorizzato tramite AppLocker o Windows Defender Application Control, e mantenere una cadenza di patching aggressiva restano le difese più efficaci contro l’intera classe di vulnerabilità di elevazione dei privilegi, indipendentemente dal componente specifico coinvolto.ConclusioneRoguePlanet dimostra ancora una volta che anche i componenti di sicurezza non sono immuni da vulnerabilità e possono, paradossalmente, diventare essi stessi superficie d’attacco. Per i sistemisti la buona notizia è che la correzione è già in distribuzione automatica: il compito principale è verificare che la propria flotta stia effettivamente ricevendo gli aggiornamenti del motore in tempi ragionevoli e, per gli ambienti a rischio più elevato, effettuare una verifica retrospettiva degli indicatori di compromissione descritti sopra.Fonte: Petri IT Knowledgebase – Microsoft Patches Zero-Day RoguePlanet Defender Flaw