Après une mise à jour de Windows, certains utilisateurs perdent l’accès à Outlook Web App (OWA) avec l’erreur UserHasNoMailboxAndNoLicenseAssignedError. Voici un guide d’entreprise complet pour diagnostiquer et corriger la situation rapidement et sans perte de données.
Vue d’ensemble de la question
Le symptôme typique est un accès OWA impossible alors que l’authentification Microsoft 365 réussit. Le message d’erreur indique que l’utilisateur n’a « pas de boîte aux lettres et aucune licence attribuée ». En pratique, cela correspond presque toujours à l’un des cas suivants :
- La licence Exchange Online (ou un SKU qui l’englobe) a été retirée, expirée, ou n’a jamais été attribuée.
- La licence est bien présente, mais le provisioning de la boîte aux lettres n’a pas terminé (latence) ou a échoué.
- La boîte aux lettres a été supprimée/convertie (ex. boîte partagée) puis l’état n’a pas été correctement répercuté.
- Le compte se connecte à un mauvais locataire (multi‑tenants, comptes invités) ou à un domaine non routé.
- En environnement hybride, un attribut critique (ExchangeGUID, RemoteRoutingAddress) est incohérent.
La coïncidence avec une mise à jour Windows est généralement fortuite : le problème se situe côté service (licences/attributs), pas sur le poste.
Réponse & Solutions (récapitulatif)
Étape | Action | Objectif |
---|---|---|
1. Vérifier l’attribution de licence | Centre d’administration Microsoft 365 → Utilisateurs actifs → Licences & Applications | S’assurer que l’utilisateur possède bien une licence Exchange Online ou Microsoft 365 valide. Désactiver puis réactiver la licence force parfois une reprovision. |
2. Contrôler la création du mailbox | Centre d’administration Exchange → Destinataires → Boîtes aux lettres | Si aucune boîte n’existe pour l’utilisateur, en créer une ou laisser la reprovision s’exécuter automatiquement (quelques minutes). |
3. Réparer la boîte aux lettres | PowerShell Exchange Online :New-MailboxRepairRequest -Mailbox user@domaine.com | Corrige des corruptions d’attributs qui bloquent l’accès OWA. |
4. Valider la licence côté Azure AD | Azure AD PowerShell :Get-MsolUser -UserPrincipalName user@domaine.com | Select IsLicensed | Confirmer que l’état IsLicensed = True est bien remonté au tenant. |
5. Écarter les causes locales | Navigateur privé, autre poste, purge des identifiants Windows (Credential Manager) | Vérifie qu’aucun cache ou cookie ne bloque l’authentification, même si le problème est généralement côté service. |
6. Vérifier l’état du service | Microsoft 365 Admin Center → Health → Service Health | Détecter un incident de provisioning ou Exchange signalé par Microsoft. |
7. Escalade si nécessaire | Centre d’administration → Support → New Service Request | Les ingénieurs Microsoft disposent d’outils internes (ex. forçage de provisioning) non accessibles via le forum. |
Procédure détaillée (avec commandes)
1) Vérifier et réappliquer la licence Exchange Online
GUI : dans le Centre d’administration Microsoft 365, ouvrez l’utilisateur, onglet Licences et applications, puis contrôlez les plans actifs (Exchange Online Plan 1/Plan 2 ou inclus dans Microsoft 365 Business/E3/E5). En cas de doute :
- Désactivez le plan Exchange Online pour l’utilisateur, enregistrez.
- Réactivez le plan Exchange Online, enregistrez.
- Demandez à l’utilisateur de se déconnecter/reconnecter à OWA après un délai de propagation (voir plus bas).
PowerShell (Microsoft Graph, recommandé) :
# Pré-requis : Module Microsoft.Graph installé
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
# Vérifier l'utilisateur et les licences
$upn = "[user@domaine.com](mailto:user@domaine.com)"
Get-MgUser -UserId $upn | Select-Object Id,UserPrincipalName,AccountEnabled
Get-MgUserLicenseDetail -UserId $upn | Select-Object SkuPartNumber,ServicePlans
PowerShell (MSOnline historique) :
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domaine.com |
Select-Object DisplayName,IsLicensed,Licenses
Bon à savoir : retirer puis réattribuer uniquement le service plan Exchange (sans toucher aux autres services) provoque souvent un reprovisionnement plus rapide qu’un retrait du SKU complet.
2) Contrôler l’existence et l’état de la boîte aux lettres
PowerShell Exchange Online (EXO V2) :
# Pré-requis : Module ExchangeOnlineManagement
Connect-ExchangeOnline
# La boîte aux lettres existe-t-elle ?
Get-EXOMailbox -Identity [user@domaine.com](mailto:user@domaine.com) -ErrorAction SilentlyContinue
# Obtenir des indicateurs utiles
Get-EXOMailbox -Identity [user@domaine.com](mailto:user@domaine.com) |
Select-Object DisplayName,PrimarySmtpAddress,RecipientTypeDetails,WhenCreated
# Statistiques (confirme la matérialisation de la boîte)
Get-EXOMailboxStatistics -Identity [user@domaine.com](mailto:user@domaine.com) |
Select-Object ItemCount,TotalItemSize,LastLogonTime
- Si aucune boîte aux lettres n’est retournée mais que la licence est active : laissez jusqu’à 30 minutes pour la création automatique. La plupart des locataires créent la boîte en quelques minutes.
- Si l’utilisateur a été récemment supprimé/restauré : vérifiez l’existence d’une soft-deleted mailbox (récupérable pendant la période de rétention) :
Get-EXOMailbox -SoftDeletedMailbox -Identity user@domaine.com
Si une boîte supprimée est trouvée, restaurez-la vers l’utilisateur recréé (selon le scénario, Mailbox Restore peut être nécessaire). - En cas d’environnement hybride : confirmez les attributs côté Active Directory local (ExchangeGUID, cible distante) et leur synchronisation vers le cloud.
3) Réparer la boîte aux lettres et les attributs
Dans Exchange Online, les réparations profondes sont gérées par des processus internes du service. Historiquement, la commande New-MailboxRepairRequest
est disponible sur les serveurs Exchange sur site. En ligne, privilégiez :
- La désactivation/réactivation du plan Exchange Online au niveau de l’utilisateur (déclenche un reprovisionnement).
- La vérification des alias SMTP (doublon d’adresse empêchant la création) :
Get-EXORecipient -ResultSize Unlimited -Filter "EmailAddresses -like 'SMTP:user@domaine.com'"
- La validation du domaine du PrimarySmtpAddress (domaine accepté et correctement routé).
Cas hybride : si vous disposez d’un Exchange Management Shell sur site et que la boîte est hébergée localement, alors New-MailboxRepairRequest
peut s’appliquer côté on‑premises.
4) Valider l’état de licence côté Azure AD / Entra ID
Confirmez que l’annuaire voit l’utilisateur comme licencié :
# MSOnline
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domaine.com | Select-Object IsLicensed
# Microsoft Graph (détails par service plan)
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
Get-MgUserLicenseDetail -UserId [user@domaine.com](mailto:user@domaine.com) |
ForEach-Object {
$*.ServicePlans | Where-Object {$*.ServicePlanName -match "EXCHANGE"} |
Select-Object ServicePlanName, ProvisioningStatus
}
Le statut ProvisioningStatus
doit idéalement être Success/Enabled. Un état Pending ou Disabled justifie la bascule du plan (off → on) et/ou l’ouverture d’un ticket.
5) Écarter les causes locales
- Testez en navigation privée et sur un autre navigateur/poste.
- Réinitialisez les identifiants (Windows → Gestionnaire d’identifiants → Identifiants Windows → supprimer les éléments Microsoft Office/Workplace s’ils existent).
- Supprimez les cookies/cache liés à Microsoft 365 puis reconnectez-vous.
Note : ces actions ne corrigent pas un problème de serveur, mais évitent de fausses pistes côté client.
6) Consulter l’état du service
Dans le Centre d’administration Microsoft 365, section État du service, vérifiez la présence d’incidents Exchange/Provisioning. En cas d’incident, la résolution est côté Microsoft et aucun changement local ne sera efficace.
7) Escalade
Ouvrez un ticket depuis le Centre d’administration. Fournissez : UPN impacté, heure/date du dernier changement de licence, résultat des commandes Get-EXOMailbox
et Get-MgUserLicenseDetail
, et captures d’écran d’OWA. Ces éléments accélèrent un reprovisionnement forcé par l’ingénierie Microsoft.
Informations complémentaires utiles
- Délai de propagation : l’affectation ou la réactivation d’une licence Exchange peut prendre jusqu’à 30 minutes avant que la boîte aux lettres soit reprovisionnée. Attendez ce délai avant de tirer des conclusions.
- Impact des mises à jour Windows : un patch système n’influence pas directement la présence d’un mailbox ; l’erreur relève plutôt d’attributs Azure AD/Exchange perdus ou corrompus.
- Commande de diagnostic (on‑prem/hybride) :
Test-ActiveSyncConnectivity -MailboxCredential (Get-Credential) -UserPrincipalName user@domaine.com
Si le test échoue avec le même message, la boîte n’est pas provisionnée côté messagerie. (Commande disponible sur les serveurs Exchange sur site.) - Bonne pratique : documentez la date/heure du dernier changement de licence ; cela aide Microsoft lors de l’ouverture d’un ticket.
Diagnostic express (arbre de décision)
Question | Oui | Non |
---|---|---|
L’utilisateur est‑il IsLicensed=True ? | Étape suivante : vérifier la boîte (Get-EXOMailbox ). | Attribuez/activez la licence Exchange Online et attendez la propagation. |
Get-EXOMailbox retourne‑t‑il une boîte ? | Contrôlez les attributs (alias SMTP, domaine, stats) puis retestez OWA. | Attendez le provisioning ; si rien après 30 min, basculez le plan Exchange off→on. |
Après bascule du plan, OWA fonctionne‑t‑il ? | Incident résolu → clôture. | Vérifiez soft‑deleted mailbox ; sinon, ouvrez un ticket Microsoft. |
Scripts prêts à l’emploi
Script 1 : état licence + boîte (Graph + EXO)
# Requiert : ExchangeOnlineManagement + Microsoft.Graph
$upn = "user@domaine.com"
Write-Host "=== Connexion Graph ==="
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All" | Out-Null
Write-Host "=== Connexion Exchange Online ==="
Connect-ExchangeOnline | Out-Null
$user = Get-MgUser -UserId $upn
$lics = Get-MgUserLicenseDetail -UserId $upn
$mailbox = Get-EXOMailbox -Identity $upn -ErrorAction SilentlyContinue
$stats = $null
if ($mailbox) { $stats = Get-EXOMailboxStatistics -Identity $upn }
$result = [PSCustomObject]@{
UPN = $user.UserPrincipalName
AccountEnabled = $user.AccountEnabled
IsLicensedExchange = ($lics.ServicePlans.ServicePlanName -match "EXCHANGE") -contains $true
ExchangePlans = ($lics.ServicePlans | ? {$*.ServicePlanName -match "EXCHANGE"} | % {$*.ServicePlanName + ":" + $_.ProvisioningStatus}) -join "; "
MailboxFound = [bool]$mailbox
RecipientTypeDetails = $mailbox.RecipientTypeDetails
PrimarySmtpAddress = $mailbox.PrimarySmtpAddress
MailboxWhenCreated = $mailbox.WhenCreated
ItemCount = $stats.ItemCount
TotalItemSize = $stats.TotalItemSize
LastLogonTime = $stats.LastLogonTime
}
$result | Format-List
Script 2 : bascule du plan Exchange (reprovision)
Attention : exécutez sur un seul utilisateur et en heures creuses. Ne modifiez pas les autres services.
# Nécessite : MSOnline (pour exemple simple)
$upn = "user@domaine.com"
Connect-MsolService
# Identifier le service plan Exchange
$user = Get-MsolUser -UserPrincipalName $upn
$exchPlan = $user.Licenses.ServiceStatus | Where-Object {$_.ServicePlan.ServiceName -match "EXCHANGE"}
# Récupérer le SKU de l'utilisateur
$sku = $user.Licenses[0].AccountSkuId
# Désactiver uniquement Exchange
Set-MsolUserLicense -UserPrincipalName $upn -LicenseOptions (New-MsolLicenseOptions -AccountSkuId $sku -DisabledPlans $exchPlan.ServicePlan.ServiceName)
# Petite pause (15-60s), puis réactiver
Start-Sleep -Seconds 30
Set-MsolUserLicense -UserPrincipalName $upn -LicenseOptions (New-MsolLicenseOptions -AccountSkuId $sku -DisabledPlans @())
Cas particuliers et résolution ciblée
Boîte convertie en « Partagée »
Si le compte utilisateur a été converti en boîte partagée, OWA pour ce compte retournera l’erreur même si la licence est active. Vérifiez RecipientTypeDetails
: UserMailbox attendu. Si SharedMailbox, rebasculer en UserMailbox et/ou réattribuer une licence utilisateur.
Conflit d’alias SMTP / domaine non accepté
Un alias déjà utilisé par un autre objet (groupe, contact, autre utilisateur) bloque la création de la boîte. Contrôlez avec Get-EXORecipient
. Vérifiez également que le domaine @domaine.com est accepté et correctement configuré dans votre tenant.
Multi‑tenants et comptes invités
Les utilisateurs ayant plusieurs comptes (professionnel, invité, test) peuvent ouvrir OWA dans le mauvais tenant. Demandez à l’utilisateur de se déconnecter de tous les comptes dans le navigateur, puis de se reconnecter explicitement avec l’UPN attendu.
Hybride (AD synchronisé)
- Confirmez que l’objet utilisateur on‑prem a ExchangeGUID cohérent et, si la boîte est hébergée en ligne, qu’il s’agit d’un RemoteMailbox avec RemoteRoutingAddress tout à fait valide.
- Après correction on‑prem, forcez une synchronisation (Azure AD Connect) puis contrôlez le provisioning en ligne.
Bonnes pratiques et prévention
- Journaliser tout changement de licence (qui, quoi, quand). Un simple fichier CSV partagé suffit pour accélérer les diagnostics.
- Automatiser des contrôles quotidiens : un script qui liste les utilisateurs licenciés sans boîte et inversement, puis alerte (mail ou webhook).
- Éviter la suppression/recréation inutile d’utilisateurs : préférez la désactivation temporaire, sinon vous risquez de générer des soft-deleted mailboxes en doublon.
- Utiliser des groupes d’attribution de licences (via Entra ID) pour garantir la cohérence et réduire les erreurs manuelles.
Tableau d’aide-mémoire (commandes clés)
But | Commande | Résultat attendu |
---|---|---|
Connexion EXO | Connect-ExchangeOnline | Session Exchange Online ouverte |
Vérifier boîte | Get-EXOMailbox -Identity user@domaine.com | Retourne UserMailbox |
Statistiques | Get-EXOMailboxStatistics -Identity user@domaine.com | ItemCount, TotalItemSize, LastLogonTime |
Licences (Graph) | Get-MgUserLicenseDetail -UserId user@domaine.com | Plans actifs et statut de provisioning |
Licences (MSOnline) | Get-MsolUser -UserPrincipalName ... | IsLicensed=True |
Recherche d’alias | Get-EXORecipient -Filter "EmailAddresses -like 'SMTP:user@...'" | Détecte les doublons d’adresse |
FAQ
Faut‑il patienter longtemps après (ré)attribution d’une licence ?
Un délai de 5 à 30 minutes est normal. Au‑delà, une bascule du plan Exchange (désactiver → activer) et un nouveau test OWA s’imposent.
Perd‑on des données lors d’une bascule de plan ?
Non. La bascule ne supprime pas la boîte existante ; elle réinitialise le provisioning du service Exchange pour l’utilisateur.
Pourquoi l’erreur apparaît‑elle seulement dans OWA ?
OWA se base directement sur l’existence de la boîte. Des clients riches (Outlook) peuvent parfois présenter d’autres messages, mais la cause racine est identique.
Je suis en hybride : dois‑je réparer on‑prem ou online ?
Réparez là où la boîte « vit ». Si la boîte est en ligne, corrigez d’abord la licence et les attributs cloud ; si elle est locale, travaillez côté serveur Exchange on‑prem et synchronisez.
Checklist de clôture (qualité)
- La licence Exchange Online est active et le plan Exchange est Enabled/Success.
Get-EXOMailbox
retourne UserMailbox, avec une PrimarySmtpAddress valide.- Pas de conflit d’alias détecté (
Get-EXORecipient
). - OWA s’ouvre sans erreur et l’envoi/réception fonctionne.
- La date/heure du dernier changement de licence est notée pour référence future.
Conclusion
Dans l’immense majorité des cas, UserHasNoMailboxAndNoLicenseAssignedError se résout par la séquence suivante : confirmer la licence, valider l’existence de la boîte, corriger les attributs (si nécessaire), forcer un reprovisionnement en basculant le plan Exchange, puis tester OWA après propagation. En scénario atypique (soft‑deleted, hybride, multi‑tenants), appliquez les contrôles ciblés décrits ci‑dessus et, en dernier recours, ouvrez un ticket de support pour un reprovisionnement serveur.