1 10/05/2026 9 min

In SCCM 2103, l’hotfix KB10036164 per Cloud Attach non va trattato come una semplice correzione cosmetica: tocca il punto in cui Configuration Manager si aggancia ai servizi cloud Microsoft e, se qualcosa è fuori posto, il sintomo non è quasi mai “il pulsante non funziona”, ma piuttosto sincronizzazioni che si fermano, stati incoerenti nel tenant attach, errori di provisioning o funzionalità cloud che sembrano abilitate ma non completano il ciclo operativo.

Il punto pratico è questo: se stai usando Cloud Attach su 2103 e hai già osservato comportamenti anomali nell’integrazione con Microsoft Endpoint Manager, l’hotfix serve a ridurre il rischio di bug già noti nel ramo 2103. Non è un upgrade di versione, quindi non cambia il modello di gestione, ma modifica componenti e logica di integrazione lato site server e console. Per questo va installato come change controllato, non come patch “da mettere e basta”.

Quando ha senso applicare KB10036164

La domanda giusta non è “è uscito un hotfix?”, ma “il mio ambiente dipende davvero da Cloud Attach?”. Se la risposta è sì, KB10036164 entra nella stessa categoria delle patch che conviene valutare prima che il problema diventi operativo. In pratica, ha senso applicarlo quando usi una o più di queste funzioni:

  • tenant attach verso Microsoft Endpoint Manager;
  • integrazione con co-management;
  • sincronizzazione dello stato dei dispositivi nel portale cloud;
  • funzionalità che si appoggiano al canale cloud per reporting o azioni remote;
  • console che mostra un’integrazione formalmente attiva ma non coerente con il comportamento reale.

    • Se invece il tuo site è ancora on-prem puro, senza Cloud Attach e senza co-management, l’urgenza scende. Non significa che l’hotfix sia inutile in assoluto, ma il valore operativo è più basso e la finestra di manutenzione può aspettare una release successiva o una finestra più ampia.

    Cosa controllare prima di toccare il site

    Prima di installare l’hotfix, verifica lo stato reale dell’ambiente. Qui si evita il classico errore: applicare la patch mentre il problema originario è un certificato scaduto, un proxy che blocca l’uscita, un tenant disallineato o una console che gira su componenti già instabili. L’hotfix non deve diventare il tappeto sotto cui nascondere un guasto di rete o identità.

  • Controlla la versione esatta del site. In console apri Administration → Site Configuration → Sites e verifica che il primary site sia effettivamente su 2103.

  • Conferma che Cloud Attach sia attivo e che il tenant sia quello corretto. Se hai più tenant o ambienti di test, il rischio qui è applicare la patch su un site che non usa la stessa integrazione che stai cercando di correggere.

  • Esamina i log principali del site server e del componente cloud per capire se il problema è già visibile a livello di autenticazione o connessione. I file da tenere d’occhio, in modo generale, sono i log del site control, del cloud management e del tenant attach.

    • Se manca uno di questi dati, non andare a intuito. Il minimo sindacale è avere: versione del site, stato del tenant attach e un estratto del log in errore. Senza questo, ogni diagnosi sull’hotfix è debole.

    Prerequisiti operativi e rischio di blast radius

    KB10036164 non è una modifica isolata al singolo client: tocca il site server, la console e i componenti che orchestrano l’integrazione cloud. Il blast radius quindi è medio, perché il rischio non è soltanto “una funzione non parte”, ma anche “la console mostra dati non coerenti” o “l’attività cloud si interrompe finché il componente non si riallinea”.

    Prima dell’installazione, prepara un rollback minimo: snapshot della VM se il site è virtuale, backup del database del site se il tuo processo lo prevede, e comunque esportazione delle impostazioni critiche se hai personalizzazioni o integrazioni esterne. Non sto dicendo che servirà, ma se il change impatta il control plane è il tipo di operazione in cui il rollback va pensato prima, non dopo.

    In più, tieni presenti questi prerequisiti pratici:

  • accesso amministrativo al site server;
  • finestra di manutenzione per la console e per eventuali servizi correlati;
  • spazio disco sufficiente sul volume di sistema e sul path temporaneo usato dal setup;
  • connessione stabile verso i servizi Microsoft necessari al tenant attach;
  • possibilità di riavviare i componenti necessari senza impatto improvviso sugli operatori.

    • Installazione: sequenza prudente

    La sequenza corretta è semplice: prima osservi, poi installi, poi verifichi. Saltare la parte di osservazione significa non sapere se il problema si è risolto o si è solo spostato.

  • Scarica l’hotfix KB10036164 dal canale Microsoft previsto per Configuration Manager. Evita copie non tracciate o pacchetti recuperati da repository non ufficiali.

  • Verifica che il site server non stia già eseguendo un’altra attività critica di manutenzione o aggiornamento. Se il site è già impegnato in un deployment, l’installazione dell’hotfix va spostata in una finestra più pulita.

  • Esegui il setup dall’ambiente amministrativo previsto, seguendo il percorso del product update in console o il meccanismo standard di installazione della hotfix per Configuration Manager.

  • Lascia completare la distribuzione dei componenti e non fermarti al primo messaggio di successo. In questo tipo di patch conta anche la propagazione interna del pacchetto verso console e site components.

  • Se il setup richiede riavvio di servizi o del server, pianificalo e registralo. Un riavvio non documentato in un site SCCM può sembrare banale, ma è il genere di cosa che poi complica il post-change review.

    • Un esempio pratico: se il tenant attach risultava “attivo” ma senza aggiornare correttamente lo stato dei device, dopo l’installazione devi aspettarti almeno una nuova sincronizzazione coerente, non solo la scomparsa dell’errore visibile in console. Se la situazione resta identica, il problema potrebbe essere altrove: autenticazione cloud, proxy in uscita o componenti già degradati prima della patch.

    Verifiche post-installazione che contano davvero

    Non fermarti al fatto che l’update sia “installed”. La verifica utile è funzionale. Devi dimostrare che il Cloud Attach torna a comportarsi in modo coerente. Le verifiche minime sono queste:

  • Controlla in console che la hotfix risulti applicata e che il site sia in stato stabile.

  • Verifica il tenant attach e l’eventuale co-management status.

  • Osserva i log del site server per messaggi di errore nuovi o residui legati a cloud integration, autenticazione o sincronizzazione.

  • Forza, se previsto dal tuo processo, una sincronizzazione o un refresh del dato cloud e controlla che il risultato sia coerente con lo stato atteso.

    • Qui il comando non è sempre la via principale, perché SCCM si controlla spesso meglio da console e log. Però lato sistema operativo puoi comunque raccogliere evidenze utili con strumenti standard di Windows, ad esempio per vedere servizi e stato generale del site server.

    Get-Service | যেখানে {$_.Status -eq 'Running'} | Sort-Object Name

    Il punto non è il cmdlet in sé, ma la verifica che il site server non abbia perso servizi chiave durante o dopo il change. Se trovi un servizio fermo o in restart loop, non inseguire subito il Cloud Attach: prima risolvi il blocco locale.

    Log e segnali da leggere senza farsi ingannare

    Quando una patch SCCM sembra non fare effetto, il problema spesso è nel modo in cui stai leggendo i log. Il rischio è vedere un errore cloud e attribuirlo all’hotfix, mentre in realtà il componente sta fallendo per un token scaduto, un certificato non valido o un DNS che non raggiunge il servizio Microsoft corretto.

    I segnali da cercare sono tre:

  • errori di autenticazione o autorizzazione verso il tenant;
  • timeout o fallimenti di connessione outbound;
  • stato incoerente tra console e comportamento reale del device o del site component.

    • Se il tuo ambiente usa proxy, il dettaglio decisivo è capire se il site server esce davvero verso i domini richiesti. Un controllo rapido del layer di rete è spesso più utile di una reinstallazione. Ad esempio, puoi verificare la raggiungibilità TCP e la risoluzione DNS verso l’endpoint previsto dal tuo tenant e dalla tua configurazione di cloud services.

    nslookup login.microsoftonline.com
    Test-NetConnection login.microsoftonline.com -Port 443

    Se uno di questi test fallisce, non stai guardando un problema di SCCM puro: stai guardando un problema di connettività o di egress. L’hotfix può restare corretto, ma non risolverà un blocco fuori dal perimetro applicativo.

    Rollback ragionato se qualcosa va storto

    Su una patch di questo tipo il rollback non è sempre “disinstalla e torna indietro” in modo pulito, quindi la preparazione è parte del change. Se dopo l’installazione noti regressioni concrete, l’approccio prudente è:

  • ferma ulteriori modifiche al site;

  • raccogli i log del momento in cui è iniziata la regressione;

  • verifica se il problema è correlato alla sincronizzazione cloud o a un servizio locale del site;

  • se previsto dal tuo processo, ripristina la VM o il backup del site server/database in un punto precedente al change;

  • riapri il tenant attach solo dopo aver validato che la base del site sia tornata coerente.

    • Se non hai snapshot o backup coerenti, il rollback diventa un problema di processo, non di patch. In quel caso la vera correzione è sistemare la tua strategia di change management, non insistere con tentativi di uninstall improvvisati.

    Come leggere il valore reale dell’hotfix

    Il valore di KB10036164 si misura su due piani: stabilità del componente cloud e riduzione del tempo perso a inseguire anomalie già note del ramo 2103. Se il tuo ambiente è esposto a Cloud Attach, il costo di una finestra di manutenzione controllata è normalmente inferiore al costo di restare fermi con un’integrazione che si comporta male.

    Ma c’è un limite importante: l’hotfix non sostituisce una verifica strutturale dell’architettura. Se hai un proxy che rompe TLS inspection, un DNS interno incompleto, certificati scaduti, un account con permessi insufficienti o un site server sovraccarico, la patch non è una cura universale. È una correzione puntuale dentro una catena che va comunque tenuta pulita.

    In sintesi operativa: applica KB10036164 se usi Cloud Attach su SCCM 2103, fallo con osservabilità prima del change, verifica il tenant attach dopo il deployment e tieni pronto un rollback coerente con il tuo livello di rischio. È il tipo di aggiornamento che funziona bene quando lo tratti come parte della piattaforma, non come un file da eseguire e dimenticare.