Assegnazione diretta e group-based licensing

Nel Microsoft 365 admin center una licenza si assegna in due modi. Il primo è l’assegnazione diretta: da Users > Active users apri l’utente, selezioni Licenses and Apps ed espandi la sezione Licenses; in alternativa parti dal prodotto in Billing > Licenses e usi Assign licenses. Per farlo serve almeno il ruolo License Administrator o User Administrator. In entrambi i percorsi puoi restringere i servizi inclusi con Turn apps and services on or off, perché una licenza è un contenitore di service plan e non sei obbligato ad accenderli tutti.

Il secondo modo è la group-based licensing: assegni la licenza a un gruppo — un security group, un mail enabled group o un Microsoft 365 group — e i membri la ereditano. Il percorso è sempre Billing > Licenses > Assign licenses, ma nel pannello cerchi il gruppo invece dell’utente, poi scegli la subscription da cui prelevare le licenze; qui il ruolo minimo è Groups Administrator, License Administrator o User Administrator. Cambia anche come leggi la pagina dopo: se la licenza arriva da un gruppo, nell’elenco delle assegnazioni compare il nome del gruppo e non i singoli utenti, e per sapere chi la riceve devi passare da Teams & groups > Active teams & groups. Le assegnazioni dirette, invece, mostrano l’utente individualmente.

Due dettagli documentati che l’esame ama. Primo: la group-based licensing non supporta i gruppi annidati; se assegni licenze a un gruppo che ne contiene altri, ricevono la licenza solo gli utenti del primo livello. Secondo: la usage location va impostata prima, perché non tutti i servizi sono disponibili ovunque; con la group-based licensing gli utenti senza una location specifica ereditano quella del tenant, il che in un’organizzazione multi-paese produce assegnazioni sbagliate in silenzio. Quando qualcosa non va, la scheda Errors & issues sul prodotto elenca gli utenti falliti e la ragione — licenze esaurite, service plan in conflitto, usage location non valida — e da lì puoi lanciare Reprocess dopo aver risolto la causa.

Il caso che ricorre più spesso nelle domande è lo spostamento di un utente fra due gruppi licenziati: l’ordine delle operazioni conta. Prima aggiungi l’utente al gruppo di destinazione, poi verifica che la nuova licenza risulti sulla pagina Licenses dell’utente, e solo alla fine lo rimuovi dal gruppo di origine. Se togli prima, l’utente resta senza licenza per tutto il tempo di elaborazione, che in tenant grandi o sotto carico può essere più lungo del previsto.

Pay-as-you-go: un secondo modo di pagare

La licenza per utente non è l’unico modello. Con il pay-as-you-go colleghi il consumo di Microsoft 365 a una Azure subscription e paghi solo quello che usi. La configurazione ha due passi distinti che non vanno confusi: prima crei una billing policy — un identificatore di fatturazione che associa una subscription Azure a un insieme di utenti — poi la connetti al servizio Copilot. Creare la policy non completa la configurazione. Lato Copilot i servizi disponibili in pay-as-you-go sono Microsoft 365 Copilot Chat, gli SharePoint agents e la Microsoft Copilot Retrieval API in preview. I ruoli che possono gestirlo sono Global administrator, Billing administrator, AI administrator e Global reader in sola lettura.

Sul controllo dei costi c’è la confusione più insidiosa. Un budget si imposta solo a livello di billing policy, mai per singolo utente, agente o sito, da Copilot > Billing & usage > scheda Budget, con reset mensile, trimestrale o annuale e avvisi email verso mail-enabled security group. Ma un budget avvisa, non blocca: la documentazione è esplicita nel dire che raggiungere il 100% del budget non ferma il servizio né la fatturazione. L’unico modo per fermare la spesa è disconnettere il servizio pay-as-you-go.

Le licenze dei servizi AI

Microsoft 365 Copilot è un piano add-on: richiede una subscription Microsoft 365 o Office 365 idonea e si assegna per utente come qualsiasi altra licenza. Va tenuto distinto da Microsoft 365 Copilot Chat: la chat basata sul web è inclusa automaticamente con una subscription idonea senza costo aggiuntivo, mentre la chat sui dati di lavoro richiede la licenza Microsoft 365 Copilot.

Microsoft Agent 365 è una subscription a sé, utilizzabile con subscription Microsoft 365 idonee e inclusa in Microsoft 365 E7. Qui l’errore classico è pensare che si licenzino gli agenti: la documentazione Entra dice che Agent 365 richiede una licenza per ciascun utente. E vanno separati tre oggetti diversi: Microsoft Entra Agent ID è la piattaforma delle identità degli agenti, l’agent registry è l’inventario in Agents > All agents > Registry nell’admin center, e Agent 365 è la suite di gestione. Inventario e azioni di governance di base sono disponibili con i piani Microsoft 365; policy template, osservabilità, controllo dei tool e Graph API richiedono E7 o Agent 365.

Microsoft Copilot Studio ha una logica ancora diversa: la valuta comune sono i Copilot Credits, ottenibili con meter pay-as-you-go, prepurchase plan o prepaid pack. La user license di Copilot Studio è gratuita ma presuppone una subscription prepaid a livello tenant. Attenzione: la billing policy pay-as-you-go di Copilot Studio si crea nel Power Platform admin center, non in quello di Microsoft 365.

Monitorare e che cosa verifica l’esame

Il monitoraggio vive in due posti. Il Microsoft 365 Copilot usage report (Reports > Usage) distingue Enabled Users, cioè gli utenti con licenza Copilot, da Active Users, chi ha davvero usato una funzionalità: è la metrica che dice se le licenze acquistate stanno rendendo. Il consumo a credito si legge invece nel Cost Management dashboard, con le schede Overview e Consumption.

L’esame — che è in beta, con soglia di superamento 700 — tende a verificare proprio i confini: se sai distinguere una licenza per utente da un modello a consumo, se ricordi che il budget non è un blocco, e se conosci l’ordine corretto nello spostamento fra gruppi licenziati.