Disattivare Copilot in Windows 11 con Intune e GPO

Disattivare Copilot in Windows 11 non significa sempre ottenere lo stesso risultato operativo. In alcuni casi lo si rimuove dalla barra delle applicazioni, in altri si impedisce l’avvio dell’app o dell’esperienza integrata, in altri ancora si blocca la disponibilità della funzionalità a livello di policy. La differenza conta, perché in ambiente aziendale il punto non è solo “nasconderlo”, ma evitare che l’utente lo riattivi o che la configurazione venga sovrascritta da una policy più debole.

Se l’obiettivo è gestire Windows 11 in modo coerente su più postazioni, le due strade da considerare sono Intune e Group Policy. Intune è la scelta naturale per dispositivi gestiti da cloud e scenari ibridi; la GPO resta utile per domini Active Directory tradizionali o dove la precedence delle policy è già consolidata. In entrambi i casi conviene distinguere tra rimozione dell’icona, disabilitazione della funzionalità e blocco della riattivazione.

Che cosa stai davvero disattivando

Su Windows 11 Copilot può comparire come esperienza integrata nel sistema, come app o come elemento richiamabile dalla barra delle applicazioni. Prima di applicare una policy, chiarisci quale comportamento vuoi ottenere:

In pratica, la sola rimozione del pulsante non basta se vuoi una disabilitazione amministrativa. Al contrario, una policy di blocco può essere più invasiva e richiede più attenzione al rollback, soprattutto se hai pilot, ring di validazione o dispositivi condivisi.

Intune: blocco centralizzato con policy e profili

Con Intune la strada più pulita è usare una policy di configurazione che agisca sulle impostazioni supportate dal tenant e dalla versione di Windows 11. Il vantaggio è evidente: assegnazione per gruppi, reporting, conflitto tra profili visibile nel portale e rollback più semplice rispetto a molte configurazioni locali.

In ambienti moderni, la regola pratica è questa: prima verifica se la tua build di Windows 11 espone un’impostazione nativa nel catalogo impostazioni o nei template amministrativi importati in Intune. Se l’impostazione non è disponibile o non è coerente con la versione del client, il fallback più affidabile resta il deployment di una policy equivalente via ADMX ingest o tramite script di remediation, ma solo se hai già validato il comportamento nel pilot.

Percorso operativo in Intune

Il percorso può variare in base al tenant e ai template disponibili, ma il flusso di lavoro resta sostanzialmente questo:

Se il tuo obiettivo è evitare che l’utente veda il pulsante, verifica anche le impostazioni della taskbar nel medesimo profilo o in uno separato, perché la sola disabilitazione della feature può non rimuovere l’elemento visivo se una policy precedente lo ha già fissato.

Quando lavori con Intune, il controllo più utile non è “la policy è assegnata”, ma “la policy è stata applicata sul device”. Per questo conviene usare il report di stato del dispositivo e, sul client, controllare i log di MDM e la presenza del valore atteso nel registro o nel provider di configurazione gestita, in base al tipo di policy adottata.

Verifica lato client

Su una macchina di test, dopo la sincronizzazione, controlla almeno tre elementi:

Se il risultato non è stabile dopo il riavvio, non forzare subito ulteriori modifiche. Prima verifica se un’altra policy, magari più vecchia, sta reintroducendo l’impostazione. Nei tenant grandi il conflitto tra profili è una causa molto più frequente di quanto sembri.

GPO: controllo classico con criteri di gruppo

In un dominio Active Directory, la Group Policy è ancora il metodo più lineare quando vuoi una disattivazione coerente su OU ben definite. Il vantaggio principale è il comportamento prevedibile nei sistemi joined al dominio; il limite è che richiede attenzione alla precedence, alla replica e alla corretta applicazione lato client.

Se stai lavorando con Windows 11, assicurati di avere i template amministrativi aggiornati. Senza ADMX recenti potresti non vedere l’impostazione corretta nel Group Policy Editor, oppure potresti applicare un criterio che non corrisponde alla build reale del sistema.

Struttura consigliata della GPO

La configurazione tipica segue questa logica:

Separare la policy dedicata è utile per il rollback: se in futuro vuoi riattivare Copilot per un reparto specifico, devi poter scollegare o invertire una sola GPO senza toccare il resto della baseline.

Comandi utili per verifica lato client

Su una workstation di test, i controlli minimi sono questi:

gpresult /h C:	emp
eport-gpo.html

Nel report HTML verifica che la GPO dedicata sia elencata tra quelle applicate e che non ci siano filtri che la escludono. Se la policy non compare, il problema non è Copilot: è la catena di applicazione della GPO.

Per una verifica più rapida della sessione utente, puoi anche usare:

gpupdate /force

Questo non sostituisce il riavvio o il logoff quando la policy richiede un refresh completo, ma aiuta a capire subito se la GPO viene letta senza errori evidenti.

Scelta tra Intune e GPO: quando usare l’una o l’altra

Se i dispositivi sono gestiti da Intune e vuoi una distribuzione progressiva, usa Intune. Ti dà reporting migliore, targeting più flessibile e rollback meno traumatico. Se invece hai un dominio on-prem con OU già strutturate e la gestione cloud è parziale o assente, la GPO resta la soluzione più semplice da mantenere.

Ci sono però scenari misti in cui le due modalità convivono. In quel caso la regola è semplice: definisci quale sistema ha autorità sulla configurazione. Se Intune e GPO impostano lo stesso comportamento in modo diverso, il risultato finale dipende dalla precedence e dalla sincronizzazione dei criteri. Senza una governance chiara rischi di vedere Copilot riapparire dopo una sync, un reboot o un aggiornamento delle policy.

Versioni di Windows 11 e variabilità del comportamento

Qui serve prudenza: non tutte le build di Windows 11 trattano Copilot allo stesso modo. Le funzionalità cambiano nel tempo, e Microsoft ha già modificato sia la disponibilità del componente sia il modo in cui viene esposto all’utente. Per questo una procedura valida su una versione può non essere identica su una build successiva.

Se devi documentare la procedura internamente, la cosa giusta da fare è indicare esattamente la build testata, il canale di aggiornamento e il metodo di gestione usato. Senza questo dato, la documentazione diventa fragile e il supporto si trasforma in tentativi ripetuti.

Validazione operativa prima del rollout

Prima di estendere la modifica a tutta l’organizzazione, valida almeno questi punti su un gruppo pilota:

Se qualcosa non torna, non partire dal presupposto che il problema sia la policy Copilot. Più spesso il guasto è nella catena di applicazione: filtro gruppo errato, conflitto con un altro profilo, ADMX non aggiornato, oppure client non allineato alla build prevista.

Rollback e blast radius

Il blast radius dipende dal metodo scelto. Con Intune, se assegni il profilo a un gruppo ristretto, l’impatto resta contenuto; se lo applichi a un gruppo globale o a tutti i device, il rollback coinvolge subito una base ampia di utenti. Con GPO, il rischio principale è estendere il criterio a OU più grandi del previsto o ereditare la policy su sottostrutture non testate.

Il rollback corretto è sempre quello più semplice e reversibile: rimuovi l’assegnazione del profilo in Intune, oppure disabilita o scollega la GPO dedicata. Non modificare subito altre policy collegate, perché così perdi la possibilità di capire quale impostazione aveva effettivamente prodotto l’effetto desiderato.

Prima di fare rollback, annota il gruppo target, la data di applicazione e il comportamento osservato sul client. Questo ti serve se devi ricostruire il cambio o confrontare due build di Windows 11 con risultati diversi.

Checklist finale di controllo

Se vuoi una verifica rapida e ordinata, usa questa sequenza:

Assunzione operativa: il dispositivo è in gestione centrale e la modifica deve essere reversibile senza interventi manuali su ogni singola macchina.