Le operazioni bulk del portale, e le righe del CSV da non toccare
Finché gli utenti sono dieci, il portale basta. Quando diventano trecento, cambia tutto. Nel Microsoft Entra admin center le operazioni massive sugli utenti stanno sotto Entra ID > Users > Bulk create: scarichi il template CSV, lo compili, lo carichi e il portale valida il file prima di lasciarti premere Submit. Servono almeno i diritti di User Administrator. Il template è rigido: la riga con il numero di versione (version:v1.0), quando c’è, va lasciata dov’è; l’intestazione delle colonne va mantenuta identica a come l’hai scaricata; la riga di esempi va rimossa e sostituita con le tue voci. Le uniche quattro colonne obbligatorie sono Name, User name, Initial password e Block sign in, tutte le altre sono facoltative, e le colonne che aggiungi tu vengono ignorate. Il formato cambia da operazione a operazione — quello dei membri di gruppo, per esempio, inizia direttamente dall’intestazione e non ha riga di versione — quindi scarica sempre il template dell’operazione che stai per eseguire.
Oltre alla creazione, il portale supporta l’eliminazione massiva e il download degli elenchi di utenti. Qui si annida la confusione più comune: la bulk create crea account membri interni con le password scritte nel CSV e non invia nessuna email di invito, quindi le credenziali le devi comunicare tu con un processo tuo; invitare ospiti esterni in blocco è un’operazione diversa, documentata come bulk invite di utenti B2B. Cambia anche il punto di ingresso a seconda dell’oggetto: i membri di un gruppo si importano dal gruppo stesso, in Members > Bulk operations > Import members (ruolo Groups Administrator, oppure il proprietario del gruppo), mentre gli utenti si aggiungono a un’administrative unit da Entra ID > Roles & admins > Admin units, selezionando Users > Bulk operations > Bulk add members, e lì serve Privileged Role Administrator. L’administrative unit limita l’ambito dei permessi di un ruolo: è un contenitore, non un ruolo.
L’esito non lo leggi nella notifica, lo leggi nella pagina Bulk operation results, dove ogni job mostra lo stato (In Progress, Succeeded, Failed), i contatori # Success, # Failure e Total Requests, e da dove scarichi il file con il motivo di ogni errore. Se un’operazione non si chiude entro l’ora, la raccomandazione ufficiale è spezzare il numero di record per batch.
Perché i moduli precedenti non ci sono più
I moduli Azure AD, Azure AD Preview e MSOnline sono deprecati: il modulo da usare per interagire con Microsoft Entra ID è Microsoft Graph PowerShell. Non è un rebranding. I cmdlet cambiano prefisso — al posto di AzureAD o AzureADMS si usa Mg, quindi Get-AzureADUser diventa Get-MgUser — ma cambiano anche parametri, filtri e oggetti restituiti, per cui gli script vecchi non funzionano così come sono. Il guadagno è che un solo endpoint e un solo token coprono anche SharePoint, Exchange e gli altri servizi, che il modulo gira su PowerShell 7 oltre che su Windows PowerShell 5.1, su Windows, macOS e Linux, e che l’autenticazione passa per MSAL.
Il cambiamento più importante riguarda i permessi: quelli di Microsoft Graph PowerShell non sono preautorizzati, quindi vanno richiesti esplicitamente. Qui casca il candidato distratto. Gli scope che passi a Connect-MgGraph autorizzano l’applicazione ad agire per tuo conto, ma non ti concedono niente che il tuo ruolo in Entra ID non ti dia già: sono due controlli distinti e devono essere soddisfatti entrambi.
Installare e capire con quale identità sei connesso
L’installazione avviene dalla PowerShell Gallery con Install-Module Microsoft.Graph -Scope CurrentUser -Repository PSGallery -Force; esiste anche Microsoft.Graph.Beta per l’endpoint beta, che la documentazione sconsiglia in produzione. Installare il modulo principale tira dentro oltre 47 sotto-moduli: puoi installare i singoli moduli che ti servono, tenendo presente che Microsoft.Graph.Authentication viene comunque installato. Verifichi con Get-InstalledModule Microsoft.Graph e aggiorni con Update-Module Microsoft.Graph.
Connect-MgGraph va invocato prima di qualunque altro comando. In accesso delegato dichiari gli scope della sessione: Connect-MgGraph -Scopes "User.Read.All", "Group.ReadWrite.All", con -UseDeviceAuthentication quando il browser non è disponibile. Per gli scenari non presidiati c’è l’accesso app-only, con certificato (-CertificateThumbprint), con client secret (-ClientSecretCredential) o con managed identity (Connect-MgGraph -Identity). Get-MgContext mostra account, tenant, scope consentiti e tipo di autenticazione (Delegated oppure app-only); Disconnect-MgGraph chiude la sessione. Se non sai quali permessi chiedere, Find-MgGraphCommand li elenca per un dato cmdlet.
I cmdlet di base su utenti, gruppi e licenze
Il punto di partenza è Get-MgUser, che senza parametri elenca gli utenti e con -Filter isola quello che cerchi: Get-MgUser -Filter "userPrincipalName eq 'MeganB@contoso.onmicrosoft.com'", oppure Get-MgUser -Filter "UserType eq 'Member'" per verificare che un caricamento massivo abbia funzionato davvero. Per contare e cercare sui grandi numeri serve -ConsistencyLevel eventual. Sui gruppi valgono Get-MgGroup e Get-MgGroupMember, con -All quando vuoi tutte le pagine e non solo la prima. Quando per l’API che ti serve non esiste ancora un cmdlet, Invoke-MgGraphRequest chiama direttamente l’endpoint REST.
Le licenze sono il caso d’uso che ti riguarda più da vicino. Get-MgSubscribedSku elenca gli SKU del tenant con il loro SkuPartNumber, Set-MgUserLicense aggiunge o rimuove licenze su un singolo utente, Set-MgGroupLicense assegna una licenza a un gruppo e quindi a tutti i suoi membri: è il pattern del group-based licensing, e Get-MgGroupMemberWithLicenseError ti dice chi è rimasto indietro. Le licenze add-on come Microsoft 365 Copilot si assegnano dal Microsoft 365 admin center, ma restano oggetti licenza come gli altri, quindi il gruppo è il punto di controllo naturale quando il rollout dell’AI segue popolazioni di utenti.
L’esame — che è in beta, con soglia di superamento a 700 — su questo obiettivo verifica soprattutto la scelta dello strumento e del permesso: quale ruolo serve per una data operazione massiva, quale scope devi consentire prima che un cmdlet risponda, e quando conviene un CSV validato dal portale invece di uno script che legge e corregge ciò che il portale non mostra.