Erreur 0x80070005 Outlook : résoudre l’envoi depuis une boîte partagée après les mises à jour Exchange 2024

Vous tentez d’envoyer un e‑mail depuis (ou au nom de) une boîte aux lettres partagée Outlook et l’opération échoue avec le code 0x80070005‑0x000004dc‑0x00000524. Cet article détaille minutieusement les causes possibles, les correctifs récents et une méthodologie pas à pas pour éliminer définitivement l’erreur—inclus un script PowerShell complet et une foire aux questions pour aller plus loin.

Sommaire

Erreur 0x80070005‑0x000004dc‑0x00000524 lors de l’envoi à partir d’une boîte aux lettres partagée

Nature du problème

Outlook renvoie un refus d’accès (Access Denied) lorsqu’un utilisateur tente d’envoyer un message « En tant que » (Send As) ou « De la part de » (Send on Behalf) d’une boîte aux lettres partagée ou d’un groupe Microsoft 365. Le message reste bloqué dans Éléments envoyés (ou en brouillon) et l’utilisateur reçoit instantanément un rapport de non‑remise (NDR) faisant référence à la triple suite d’erreurs.

Causes typiques

Cause	Explications & indices
Droits insuffisants	Le compte ne possède pas les autorisations Send As, Send on Behalf ou Full Access sur la boîte partagée.
Carnet d’adresses hors‑ligne (OAB) non à jour	Les nouveaux droits existent côté serveur, mais ne sont pas encore répercutés dans le fichier OST local.
Profil Outlook corrompu ou obsolète	Outlook continue d’utiliser un cache mal synchronisé, empêchant la prise en compte des permissions corrigées.
Correctifs Exchange manquants	La Security Update (SU) de mars 2024 pour Exchange 2016/2019 introduit un bug cassant l’envoi depuis les nouvelles boîtes partagées.

Parcours de résolution recommandé

Vérifier ou attribuer les autorisations – Centre d’administration Exchange (EAC) ou PowerShell :
Add-MailboxPermission "SharedMBX" -User User1 -AccessRights FullAccess Add-RecipientPermission "SharedMBX" -Trustee User1 -AccessRights SendAs
Forcer le rafraîchissement Outlook :
- Télécharger le carnet d’adresses hors‑ligne (Envoyer/Réception ▸ Télécharger le carnet).
- Relancer Outlook ou exécuter outlook /cleanprofile.
Tester en mode en ligne : désactiver la mise en cache Exchange. Si l’envoi fonctionne, le problème vient du fichier OST ou du bug SU mars 2024.
Réinitialiser le profil : nouveau profil Outlook ou Réparer Office.
Mettre à jour Outlook et, sur Exchange on‑premise, installer le Hotfix Update (HU) d’avril 2024 décrit plus bas.

Incident lié à la mise à jour Exchange de mars 2024

Symptômes observés après la SU mars 2024

Recherche Outlook mise en cache inopérante.
Impossibilité d’envoyer au nom de nouvelles boîtes ou groupes malgré les droits corrects.
Multiples erreurs 0x80070005 sur les postes configurés en mode Exchange mis en cache.

Raison

La SU mars 2024 pour Exchange 2016/2019 modifie le moteur de recherche et la gestion Send As des objets récents ; les boîtes partagées créées après l’installation de la SU ne reçoivent plus correctement les ACL.

Contournement rapide

Basculer Outlook en mode en ligne ou désactiver la mise en cache de la boîte problématique. L’envoi redevient possible, mais les performances hors‑ligne et la recherche instantanée se dégradent.

Correctif officiel

Le Hotfix Update (HU) du 23 avril 2024 corrige la régression. Il peut être appliqué par‑dessus la SU de mars ou directement (la SU sera alors incluse).
Action : installer le HU sur chaque serveur Exchange, redémarrer les services, réactiver la mise en cache et régénérer l’index de recherche si nécessaire.

Quand Outlook individuel ne peut plus envoyer malgré tout

Mettre Outlook à jour : passer au dernier build du canal mensuel ou LTSC.
Démarrer en mode sans échec (outlook /safe) pour écarter les compléments tiers.
Nouveau profil : créer un profil provisoire et tester.
Analyser l’OST/PST avec scanpst.exe.
Contrôler antivirus, pare‑feu et règles de transport locales ou côté Exchange/tenant.
Tracer (cmdlets Test-OutlookConnectivity, MessageTrace) pour repérer un blocage dans le pipeline de transport.

Scripts PowerShell utiles

Audit rapide des permissions Send As

# Liste toutes les boîtes partagées et les comptes autorisés
Get-Mailbox -RecipientTypeDetails SharedMailbox | ForEach-Object {
    $mbx = $_.PrimarySmtpAddress
    Get-RecipientPermission $_.Identity | Where-Object { $_.AccessRights -match "SendAs" } |
        Select-Object @{n="SharedMailbox";e={$mbx}},
                      Trustee, AccessRights
} | Format-Table

Réattribution globale après la SU mars 2024

# Ré‑applique SendAs à toutes les boîtes partagées créées après le 12/03/2024
$cutoff = Get-Date "2024-03-12"
Get-Mailbox -RecipientTypeDetails SharedMailbox |
Where-Object {$_.WhenCreated -gt $cutoff } |
ForEach-Object {
    Add-RecipientPermission $_.Identity -Trustee "G-SharedMailboxEditors" -AccessRights SendAs -Confirm:$false
}

FAQ (Questions fréquentes)

Combien de temps faut‑il pour que les nouvelles permissions soient actives ?

En Exchange Online, les ACL se propagent en 1‑5 minutes ; côté on‑premise, prévoir la réplication AD (jusqu’à 30 min) puis la génération du carnet d’adresses hors‑ligne (OAB).
Que signifie exactement la portion « 0x000004dc‑0x00000524 » ?

Il s’agit de codes d’état internes à Exchange : 0x4dc (ERROR_INVALID_LOGON_TYPE) et 0x524 (ERROR_INVALID_ACCOUNT_STATE). Combinés, ils rappellent qu’un jeton de sécurité ne possède pas l’ACE attendue.
Les groupes Microsoft 365 sont‑ils également touchés ?

Oui : la création d’un groupe après la SU mars 2024 peut hériter des mêmes bugs de permission Send As. Appliquez le HU avril 2024 ou attribuez manuellement les droits via PowerShell.
Comment vérifier côté cloud qu’un attribut a bien synchronisé ?

Via Get-Mailbox en Exchange Online : l’attribut GrantSendOnBehalfTo doit contenir l’ObjectID du délégué, et Get-EXOMailboxPermission doit retourner la ligne NT AUTHORITY\SELF + SendAs.
Pourquoi un utilisateur avec « Full Access » ne peut‑il pas forcément envoyer « En tant que » ?

Les droits Full Access autorisent l’ouverture de la boîte et la modification des éléments, mais Send As doit être accordé séparément : deux ACL distinctes sont requises.

Bonnes pratiques pour éviter le retour de l’erreur

Documenter systématiquement les délégations Send As/Send on Behalf et leurs propriétaires.
Automatiser la vérification quotidienne des boîtes partagées créées la veille (script ci‑dessus).
Segmenter les rôles : un groupe universel par service (RH, Finance…) avec Send As, plutôt que des attributions directes.
Surveiller le canal Microsoft 365 Message Center pour tout correctif de sécurité Exchange.
Mettre en place un Change Management incluant le redémarrage planifié des services après chaque CU/SU/HU.

Annexe : commandes clés en un coup d’œil

Action	Commande PowerShell
Donner Full Access	`Add-MailboxPermission "MBX" -User John -AccessRights FullAccess`
Donner Send As	`Add-RecipientPermission "MBX" -Trustee John -AccessRights SendAs`
Vérifier Send As	`Get-RecipientPermission "MBX" \| ft Trustee,AccessRights`
Réparer un profil Outlook	`Outlook /profiles` → créer NouveauProfil
Forcer le téléchargement OAB	Outlook ▸ Envoyer/Recevoir ▸ Télécharger le carnet
Indexer la recherche	`ResetSearchIndex.ps1` (Exchange 2019 scripts)

Conclusion

En appliquant les vérifications de permissions, le rafraîchissement du cache Outlook et—le cas échéant—le Hotfix Update d’avril 2024, plus de 95 % des occurrences de la fameuse erreur 0x80070005‑0x000004dc‑0x00000524 disparaissent de façon pérenne. Gardez en mémoire que la source première demeure presque toujours :
« Les droits existent… mais ne sont pas encore visibles là où Outlook les cherche. »