Configurare il tasto Copilot hardware con Intune

Il tasto Copilot hardware non si “accende” da solo in Intune: va trattato come una combinazione di firmware, layout tastiera, versione di Windows e policy di configurazione. Se il dispositivo supporta l’hotkey ma l’utente vede solo il comportamento predefinito, il punto non è l’interfaccia grafica del produttore, ma la catena che porta Windows a interpretare quel tasto e a consegnarlo alla funzione desiderata. In pratica, prima si verifica che il device esponga il tasto correttamente, poi si decide se mapparlo a Copilot, a una scorciatoia M365 o a un’azione personalizzata, e solo dopo si distribuisce la configurazione via Intune.

Qui il vincolo vero è semplice: non tutti i modelli usano lo stesso meccanismo. Su alcuni OEM il comportamento è gestito dal firmware o da un driver dedicato; su altri è Windows a intercettare il tasto e a legarlo a una funzione di sistema. Intune non “inventa” la funzione: distribuisce la policy o il profilo che abilita il mapping, e se sotto manca il supporto il risultato sarà un tasto morto o un fallback al comportamento nativo.

Che cosa deve essere vero prima di toccare Intune

Il primo errore è partire dalla console Microsoft senza aver validato il device. Prima di creare una policy, controlla questi tre punti:

1. Il PC è un modello certificato per il tasto Copilot o per la rimappatura OEM equivalente.
2. La build di Windows è coerente con la funzione che vuoi attivare, perché alcune opzioni richiedono release recenti e aggiornamenti cumulativi specifici.
3. Il device è gestito da Intune con un profilo che può applicare impostazioni di Experience, Keyboard o Settings Catalog senza conflitti con policy locali o di terze parti.

Se anche uno di questi tre punti è incerto, non andare avanti “a prova”. La verifica minima è questa: sul client, apri Impostazioni > Sistema > Informazioni e annota versione/build; poi controlla in Gestione dispositivi che la tastiera sia riconosciuta senza errori; infine, in Intune, verifica che il device sia Connesso e non solo registrato ma non conforme.

Come ragionare sulla mappatura: Copilot, ricerca, app o azione OEM

Il tasto può essere usato in modi diversi, ma la scelta va fatta in base al parco macchine e al rischio operativo. La casistica più pulita è quella in cui il tasto apre Copilot o una scorciatoia di assistenza integrata. Più delicata è la rimappatura verso un’applicazione interna, perché introduce dipendenze da URL, permessi e stato del servizio cloud. La soluzione più fragile è agganciare il tasto a un’azione che dipende da software OEM non standardizzato: funziona bene su una flotta omogenea, male su ambienti misti.

Se la tua flotta è eterogenea, la regola pratica è questa: usa una policy standard Microsoft solo per i modelli supportati nativamente; per il resto, segmenta con gruppi dinamici e profili separati. Mischiare tutto in un unico profilo aumenta i conflitti e rende più difficile capire perché il tasto non fa nulla su una parte dei dispositivi.

Policy e profilo: dove intervenire in Intune

In Intune il punto di partenza è la creazione di un profilo di configurazione destinato a Windows 11. Il percorso più pratico è usare Settings catalog o il tipo di policy specifico previsto dalla build e dall’opzione disponibile nel tenant. Il criterio non è “dove sembra più comodo”, ma dove trovi il controllo effettivo per il tasto. Se la voce non compare nel catalogo, spesso significa che il tenant o la versione del portale non espone ancora quel setting, oppure che il requisito lato OS non è soddisfatto.

1. Apri Intune admin center e crea un nuovo profilo per Windows 10 and later.
2. Scegli il canale di configurazione disponibile nel tenant: Settings catalog se la voce è esposta, altrimenti il template specifico per i controlli di esperienza o tastiera.
3. Cerca il controllo relativo al tasto Copilot o alla rimappatura del tasto dedicato, quindi imposta il comportamento desiderato.
4. Assegna il profilo a un gruppo pilota, non a tutta la flotta.

Il gruppo pilota deve essere piccolo ma rappresentativo: almeno un modello con firmware recente, uno con BIOS più vecchio e uno con eventuali driver OEM installati. Se il comportamento cambia tra i tre, non è un problema di Intune in sé: è una prova che il layer di input non è uniforme.

Verifica del lato client prima della distribuzione larga

La verifica va fatta sul client prima di estendere il profilo. Il controllo più utile è vedere se la policy è arrivata e se Windows l’ha applicata. In ambiente gestito, il primo indizio è in Impostazioni > Account > Accesso lavoro o scuola, dove il dispositivo deve risultare connesso al tenant. Il secondo indizio è la sincronizzazione riuscita dal client Intune o da Company Portal.

Se vuoi un controllo più tecnico, usa i log del management extension e dell’MDM. I percorsi più utili sono:

C:
ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
C:
ProgramData\Microsoft\DMClient\Logs\

Il nome del file può cambiare in base alla versione, ma il punto è cercare l’evidenza dell’arrivo della policy e dell’eventuale errore di parsing o di applicazione. Se non trovi riferimenti al profilo, il problema è a monte: assegnazione, filtro, gruppo dinamico o sync non completata.

Un test rapido e reversibile è questo: premi il tasto e osserva se si apre l’azione prevista, poi verifica se l’evento si riflette nell’Activity history del device in Intune. Se il tasto apre qualcosa di diverso, hai un conflitto locale o OEM; se non apre nulla, hai un problema di mapping o supporto hardware.

Impostazione pratica con profilo pilota e assegnazione controllata

La sequenza corretta è sempre la stessa: prima crei il profilo, poi lo assegni a un gruppo ristretto, poi osservi. Non partire con una distribuzione ampia perché il blast radius, in questo caso, è l’esperienza utente su tutta la flotta: un tasto che smette di funzionare o apre l’app sbagliata è un ticket immediato, anche se il resto del sistema è sano.

1. Crea un gruppo di test con 3-10 dispositivi rappresentativi.
2. Assegna il profilo solo a quel gruppo.
3. Forza una sincronizzazione dal device o attendi il ciclo MDM.
4. Verifica il comportamento del tasto su login screen, desktop e sessione bloccata, perché alcune configurazioni cambiano in base al contesto.
5. Se il risultato è coerente, estendi per anelli: pilota, reparto, produzione.

Il passaggio per anelli è importante perché riduce l’effetto sorpresa. Su hardware miscelato, il tasto può funzionare in sessione utente ma non prima del login, oppure il contrario. Questo dettaglio spesso viene ignorato e poi scambiato per guasto del profilo, quando in realtà è una limitazione del livello di input o del firmware.

Se il tasto non risponde: ipotesi ordinate per probabilità

Quando il comportamento non è quello atteso, ragiona in questo ordine:

1. Policy non applicata: il profilo non arriva al client o viene ignorato. Falsifichi in meno di 5 minuti con la verifica della sincronizzazione e con i log MDM.
2. Modello non supportato: il tasto esiste fisicamente ma non è esposto al layer Windows. Falsifichi confrontando modello, SKU e documentazione OEM del device.
3. Conflitto locale: utility OEM, driver di tastiera o software di remapping intercettano l’evento. Falsifichi disabilitando temporaneamente il software di terze parti o avviando in clean boot su un device di test.

Se vuoi una verifica sintetica lato client, usa PowerShell per raccogliere i dati di base del dispositivo e della build:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer, Model

Questi comandi non risolvono il problema, ma ti dicono subito se stai lavorando su una base compatibile. È molto più utile di una modifica cieca al profilo, perché ti evita di inseguire sintomi su hardware che non può applicare il mapping richiesto.

Rollback pulito: come tornare indietro senza lasciare residui

Il rollback in questo scenario deve essere banale: rimuovi l’assegnazione del profilo dal gruppo pilota o imposta il profilo su Not configured se il template lo consente. Non serve cancellare subito l’oggetto se stai ancora facendo test comparativi; basta togliere la distribuzione.

1. Rimuovi il device dal gruppo di assegnazione oppure disattiva la policy.
2. Forza la sincronizzazione dal client.
3. Verifica che il tasto torni al comportamento precedente entro il ciclo MDM successivo.
4. Se il comportamento resta alterato, controlla eventuali software OEM o impostazioni locali che hanno mantenuto la mappatura.

Il rollback va sempre pianificato prima del rilascio, perché una rimappatura errata può bloccare un flusso operativo quotidiano: pensiero, ricerca, assistenza, app aziendali. Se il tasto è usato dagli utenti come scorciatoia di accesso rapido, l’impatto percepito è immediato anche senza downtime tecnico.

Controlli finali da fare prima di chiudere il change

Prima di considerare concluso il change, fai almeno questi controlli:

1. Il profilo risulta Succeeded o equivalente nel report di Intune.
2. Il tasto apre la funzione prevista su almeno due modelli diversi del gruppo pilota.
3. Non compaiono errori nuovi nei log MDM o nell’event viewer relativo al management.
4. Le eventuali utility OEM non mostrano conflitti di hotkey o remapping.

Se devi documentare il risultato, conserva uno screenshot della policy assegnata, uno del device nel gruppo pilota e l’evidenza del test funzionale. In un parco endpoint, la memoria dell’operatore non basta: serve traccia verificabile di cosa è stato applicato, quando e su quali SKU.

Assunzione operativa: il tenant Intune ha già una baseline di gestione Windows attiva, i device sono Windows 11 compatibili e l’obiettivo è rimappare il tasto Copilot hardware senza introdurre software di terze parti non necessario.