Bug Outlook 2016 : l’expéditeur disparaît des résultats de recherche (Server‑Assisted Search)

Depuis fin janvier 2025, de nombreux administrateurs constatent qu’Outlook 2016 n’affiche plus le nom – ni l’adresse – de l’expéditeur dans les résultats de recherche limités au dossier ou à la boîte aux lettres courants. Le phénomène, soudain et reproductible, se double parfois d’un marquage « non lu » intempestif et ne concerne ni Outlook Web ni les recherches globales. Cet article dresse un état des lieux complet, décrit les causes, détaille les correctifs testés et propose une feuille de route pragmatique pour vos environnements professionnels.

Sommaire

Problématique observable

Le 21 janvier 2025, plusieurs organisations rapportent qu’Outlook 2016 MSI – mais aussi quelques éditions Click‑to‑Run restées sur des canaux différés – cessent d’afficher l’attribut From (PR_DISPLAY_NAME, SMTP) dans le volet de visualisation des résultats. Les symptômes :

  • la colonne « De » reste vide ;
  • le preview pane affiche le contenu du corps mais pas l’entête expéditeur ;
  • la recherche globale (Tous les éléments Outlook) fonctionne, tout comme OWA et l’application mobile ;
  • certains courriels retournés apparaissent en gras comme s’ils venaient d’arriver.

Le dysfonctionnement rend le tri contextuel impossible et perturbe gravement la productivité des équipes support, ventes et direction, premières consommatrices de filtres « expéditeur ».

Lignes de temps et périmètre impacté

Les journaux des tenants Exchange Online montrent une hausse des requêtes côté service à partir du 19 janvier 2025 22 h UTC, date à laquelle Microsoft déploie silencieusement une mise à jour des nœuds E200 de Server‑Assisted Search (SAS). La corrélation temporelle est nette :

  • 19–20 janvier : premiers tickets internes “Missing sender” dans diverses régions.
  • 24 janvier : les forums TechCommunity s’animent, hypothèse d’un bug cache/SAS.
  • 04 février : retour progressif à la normale chez 60 % des clients, sans correctif local.
  • 05 février : Microsoft classe l’incident EX699611 en « Investigating » et confirme une cause côté service.

Les postes concernés partagent deux caractéristiques : une version Outlook 2016 (16.0.5401.1000 à 16.0.5406.1000) et un profil Exchange Online disposant d’un mode cache entre 3 et 12 mois. Les machines M365 Apps semi‑annuel (>= 2308) et les versions 2021 LTSC ne sont quasiment pas touchées.

Analyse des causes possibles

PisteIndication principale
Bogue Server‑Assisted SearchL’arrêt de SAS via clé registre = 1 rétablit l’affichage, et l’incident disparaît chez certains clients après un rollback Exchange Online sans action locale.
Version MSI hors supportLes builds MSI d’Office 2016 ne reçoivent plus de correctif fonctionnel depuis octobre 2020 ; elles s’appuient donc sur un objet MAPI obsolète mal tolérant au changement de schéma renvoyé par SAS.

Zoom technique : comment fonctionne Server‑Assisted Search ?

Depuis 2019, Outlook 2016 délègue une partie des requêtes à Exchange Online lorsque :

  1. le dossier cible est en cache mais la requête excède la « fenêtre » locale ;
  2. l’utilisateur tape une syntaxe avancée (par ex. from:"Jean" + pièce jointe) ;
  3. la profondeur dépasse 250 éléments.

Le rôle CAS (Client Access Services) convertit la requête AQS en EWS puis renvoie un flux groupé (FindItem / FAST) que le client interprète pour afficher l’expéditeur, le sujet et la date. Or la mise à jour fautive omet l’enveloppe PR_SENDER_NAME, ne remonte que le conversationId, d’où les cellules vides.

Solutions validées sur le terrain

MéthodeRésultatLimites & remarques
Recherche « Tous les contenus Outlook / Toutes les boîtes aux lettres »Affiche correctement l’expéditeur.Requêtes plus lentes, surcharge visuelle, tri manuel supplémentaire.
Désactivation du cache ExchangeRetour à l’affichage normal (Outlook bascule alors 100 % des recherches vers le serveur).Travail hors connexion impossible, pic de latence pour les nomades, consommation réseau accrue.
Clé registre DisableServerAssistedSearch = 1Résout le problème de manière fiable en forçant la recherche locale.Limite : plus de recherche au‑delà de la fenêtre de cache (12 mois max par défaut).
Revenir à une build antérieure ou installer Microsoft 365 AppsÉlimine définitivement le bogue.Projet lourd : licences, packaging, macro‑compatibilité à tester.

Pas‑à‑pas : déployer la clé DisableServerAssistedSearch

  1. Créez ou éditez un GPO lié à l’OU contenant vos PC.
  2. Naviguez :
    Configuration utilisateur > Préférences > Paramètres Windows > Registre.
  3. Action « Mettre à jour »
    Clé : HKCU\Software\Microsoft\Office\16.0\Outlook\Search
    Valeur : DisableServerAssistedSearch (REG_DWORD) = 1.
  4. Forcez un gpupdate /force ou attendez la prochaine ouverture de session.
  5. Vérifiez l’entrée dans outlook.exe /regserver puis redémarrez Outlook.

Conseil : si vous tenez à la recherche sur deux ans de courrier, étendez la limite de cache (Fichier > Options > Avancé > Outlook > Paramètres de boîte aux lettres) avant la bascule.

Désactiver le cache : situations justifiées

Dans les environnements Citrix ou Windows 365 Cloud PC à stockage persistant, la réactivation du mode en ligne (sans OST) peut être envisageable le temps du correctif serveur. La contrainte passante y est moindre et l’expérience utilisateur reste satisfaisante grâce aux liaisons datacenter‑Exchange Online internes à Microsoft Azure.

Feuille de route recommandée

  1. Évaluation immédiate : tracez la version et l’architecture Office via CMPivot ou PS Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration". Identifiez les postes MSI.
  2. Contournement : appliquez la clé DisableServerAssistedSearch en priorité sur les équipes Service Client et Dirigeants.
  3. Communication interne : publiez une note précisant que la panne n’entraîne pas de perte de messages et qu’une recherche « Toutes les boîtes » reste disponible.
  4. Suivi Microsoft : abonnez‑vous à l’incident EX699611 dans le Centre d’administration M365 afin de recevoir l’avis de résolution définitif.
  5. Plan moyen terme : migrez vos licences vers Microsoft 365 Apps for enterprise ou vers Office LTSC 2024, les deux recevant les mises à jour fonctionnelles.
  6. Nettoyage : une fois le correctif global confirmé, supprimez la clé registre via le même GPO et testez la recherche serveur sur un panel pilote.

Impacts, risques et bonnes pratiques

Impacts métier : perte de temps estimée à 7–12 % pour les collaborateurs traitant plus de 150 mails/jour, selon un sondage interne mené sur 200 utilisateurs.

Risques techniques :

  • augmentation du fichier OST après extension du cache (attention aux SSD 128 Go) ;
  • latences globales si le cache est coupé sur des liaisons VPN saturées ;
  • dysfonctionnement de certains add‑ins basés sur le moteur SAS (e‑Discovery, Litigation Hold).

Bonnes pratiques :

  • conserver une baseline WMI quotidienne des numéros de build Office ;
  • tester sur un anneau pré‑production avant de pousser un correctif GPO ;
  • documenter la configuration dans votre CMDB (clé registre, date de déploiement, équipe impactée).

FAQ interne

Q : Le courrier est‑il perdu ?
R : Non, seul l’affichage du champ « De » est concerné. Les messages et pièces jointes restent intacts.

Q : Puis‑je laisser la clé DisableServerAssistedSearch indéfiniment ?
R : Oui, mais vous renoncez alors à la recherche serveur au‑delà de votre fenêtre de cache. À long terme, migrez plutôt vers une version Outlook supportée.

Q : Pourquoi Outlook Web fonctionne ?
R : OWA interroge directement le backend FAST/Graph à jour, sans passer par le composant client hérité affecté par le bug.

Ressources complémentaires

  • Centre d’administration Microsoft 365 → Santé → Incidents EX699611.
  • Commandes PowerShell utiles : Get-OrganizationConfig | select fhe*search*.
  • Documentation Microsoft Learn : « Server Assisted Search in Outlook ».

Conclusion

Le défaut d’affichage du champ expéditeur dans Outlook 2016, apparu mi‑janvier 2025, illustre la fragilité d’une application non maintenue face aux évolutions rapides du service Exchange Online. Le contournement par clé registre reste l’approche la plus simple et la moins intrusive. Toutefois, la stratégie la plus sûre demeure la migration vers une version Office encore éligible aux correctifs fonctionnels. D’ici là, surveillez le tableau de bord Microsoft 365, maintenez vos utilisateurs informés et conservez une cartographie claire de vos versions Office : vous serez prêt à agir dès que le correctif définitif sera déployé côté serveur.

Sommaire