Perché la gestione delle identità viene prima di tutto

In un tenant Microsoft 365 ogni oggetto utente vive in Microsoft Entra ID: l’account è il contenitore, la licenza è ciò che gli dà accesso ai carichi di lavoro (Exchange Online, SharePoint, Teams, Microsoft Purview, Microsoft Intune). L’esame MS-102 verifica soprattutto la capacità di scegliere il meccanismo giusto per la scala giusta.

Creazione utenti in bulk

Tre strade, con criteri di scelta netti:

Metodo Quando usarlo Limiti
Microsoft 365 admin center → Users → Add multiple users (CSV) Onboarding una tantum, poche centinaia di righe Il CSV deve usare le intestazioni del template Microsoft; colonne obbligatorie Username e First name/Last name.
Microsoft Graph PowerShell (New-MgUser in un ciclo Import-Csv) Automazione ripetibile, campi custom, attributi di estensione Richiede User.ReadWrite.All; la password va passata come oggetto PasswordProfile.
Entra Connect Sync Identità già presenti in Active Directory on-premises Gli utenti sincronizzati sono read-only nel cloud per la maggior parte degli attributi.

Regola pratica: se il dominio è ibrido, non creare l’utente in cloud — creandolo si genera un duplicato che poi va risolto via soft-match su proxyAddresses/UPN.

Gruppi assegnati vs dinamici

  • Assigned (assegnato): l’appartenenza è manuale. Costo zero di licenza, controllo totale, ma manutenzione umana.
  • Dynamic (dinamico): l’appartenenza è calcolata da una membership rule sugli attributi. Richiede Microsoft Entra ID P1 per ogni utente che ne beneficia.

Esempi di regola:

(user.department -eq "Vendite") -and (user.country -eq "IT")
(user.userPrincipalName -contains "@contoso.com") -and (user.accountEnabled -eq true)
(device.deviceOSType -eq "Windows")

Punti operativi da ricordare:

  • Un gruppo dinamico non può contenere membri aggiunti a mano: la regola è l’unica fonte di verità.
  • Le regole per utenti e per dispositivi non si mescolano nello stesso gruppo.
  • Dopo la modifica della regola l’intero gruppo viene rivalutato, non solo il delta: su tenant grandi può richiedere ore.
  • I gruppi dinamici sono ideali per Intune (assegnazione policy) e Conditional Access; i gruppi assegnati per eccezioni e ruoli privilegiati.

Group-based licensing

Si assegna la licenza al gruppo (security group o Microsoft 365 group, anche cloud-only o sincronizzato); Entra ID propaga l’assegnazione a tutti i membri e la revoca automaticamente quando l’utente esce dal gruppo.

Passi tipici: Microsoft Entra admin center → Billing → Licenses → All products → selezione SKU → Assign → scelta del gruppo → Turn off/on services per disabilitare i singoli service plan (es. escludere Yammer/Viva Engage o Sway lasciando attivi Exchange Online e Teams).

Quando usare cosa:

Scenario Scelta corretta
Tutto il tenant riceve la stessa base Gruppo dinamico “All users” + licenza al gruppo
Un reparto o una filiale Gruppo dinamico su department/city + licenza al gruppo
Un singolo consulente con SKU aggiuntivo temporaneo Licenza diretta all’utente
Utente che deve avere un service plan in più rispetto al reparto Licenza diretta in aggiunta a quella ereditata

Nota chiave: la licenza ereditata dal gruppo non è rimovibile dall’utente. Va tolta agendo sul gruppo o rimuovendo l’utente dal gruppo. Il group-based licensing inoltre non supporta i gruppi annidati: solo i membri diretti vengono processati.

Trappole tipiche d’esame

  • Scenario: dopo l’assegnazione al gruppo alcuni utenti restano in errore “License cannot be assigned” → risposta: manca la usage location. Va impostata sull’utente (o via Settings → Org settings → Profile come default) prima che la licenza possa essere applicata; alcuni servizi sono inoltre bloccati in certi paesi (ProhibitedInUsageLocationViolation).
  • Scenario: il gruppo ha 300 membri ma solo 250 licenze disponibili → risposta: errore CountViolation; nessuna assegnazione parziale “intelligente” — vanno acquistate le licenze mancanti, poi si usa Reprocess sul gruppo. Non serve ricreare il gruppo.
  • Scenario: un utente riceve due SKU che includono lo stesso service plan incompatibile → risposta: MutuallyExclusiveViolation; si risolve disabilitando il service plan duplicato su una delle due assegnazioni. Il caso simmetrico è DependencyViolation (es. un piano che richiede SharePoint Online mentre SharePoint è stato disattivato).
  • Scenario: viene rimossa la licenza Exchange Online a un dipendente uscente e il manager chiede la posta 45 giorni dopo → risposta: i dati sono persi. La finestra di grazia della mailbox è di 30 giorni dalla rimozione della licenza; per conservarli occorreva applicare prima una Litigation Hold o una retention policy di Microsoft Purview, oppure convertire la casella in shared mailbox (fino a 50 GB non richiede licenza).
  • Scenario: si vuole preservare OneDrive di un utente eliminato → risposta: la retention di OneDrive parte dall’eliminazione dell’account (default 30 giorni, configurabile 30–3650 nel SharePoint admin center), non dalla rimozione della licenza; va designato un secondary owner o spostato il contenuto prima della scadenza.