Scénario
Vous utilisez Outlook classique et un déploiement côté serveur. Vous avez activé la fonctionnalité Mise à jour des éléments envoyés dans Exclaimer.
Cependant, vous remarquez que certains éléments envoyés ne montrent pas de signatures.
Raison
Cela peut être dû à deux problèmes : le mode Exchange mis en cache et l’accès aux services Web Exchange (EWS).
En mode Exchange mis en cache, Outlook stocke localement les messages envoyés et les synchronise ensuite avec la boîte aux lettres Exchange Online. En raison de ce délai de synchronisation, Exclaimer peut ne pas trouver l’élément envoyé lorsqu’il tente d’appliquer la signature côté serveur. En conséquence, la mise à jour des éléments envoyés peut échouer.
Ce comportement est causé par la manière dont Outlook classique met en cache et synchronise les données de la boîte aux lettres, et cela échappe au contrôle d’Exclaimer.
Lorsque le mode Exchange mis en cache est désactivé, les éléments envoyés sont enregistrés directement dans la boîte aux lettres du serveur, ce qui permet à Exclaimer de les mettre à jour avec succès. Si les messages n’apparaissent toujours pas correctement dans Outlook sur le web, cela peut indiquer un problème de profil ou de boîte aux lettres plutôt qu’un problème de traitement de signature.
Les restrictions d’accès aux services Web Exchange (EWS) peuvent entraîner une authentification réussie de la requête mais un refus d’autorisation.
Cela correspond généralement à l’un des cas suivants :
- EWS désactivé au niveau de l’organisation
- EWS désactivé au niveau de la boîte aux lettres
- Accès à EWS restreint via une politique (par exemple, politique d’accès aux applications)
L’accès aux services Web Exchange peut sembler désactivé ou indisponible dans les locataires Microsoft 365 même lorsqu’aucune modification de configuration intentionnelle n’a été effectuée. Dans ces cas, la fonctionnalité de mise à jour des éléments envoyés peut échouer car Exclaimer ne peut pas accéder aux services Web Exchange nécessaires pour récupérer et mettre à jour le message envoyé. Pour plus d’informations, consultez les ressources de Microsoft sur ce problème.
Résolution
• Le délai de synchronisation du mode Exchange mis en cache est inhérent à Outlook classique et ne peut pas être contrôlé par Exclaimer.
• Les mises à jour des éléments envoyés avec des signatures côté serveur ne sont pas garanties lors de l’utilisation du mode Exchange mis en cache.
• La solution ci-dessous ne s’applique pas à New Outlook.
Sélectionnez une option ci-dessous pour afficher les instructions associées :
Pour vérifier si le mode Exchange mis en cache est la cause de l'absence de signatures côté serveur dans les éléments envoyés, vous devez configurer un nouveau profil, puis désactiver le mode Exchange mis en cache dans les paramètres du compte d’Outlook.
Pour désactiver le mode Exchange mis en cache :
- Ouvrez le Panneau de configuration et sélectionnez Courrier (Microsoft Outlook).
- Sélectionnez Afficher les profils, puis sélectionnez Ajouter pour ajouter un nouveau profil.
- Saisissez le nom du nouveau profil et sélectionnez OK.
- Suivez les instructions à l’écran pour configurer votre compte de messagerie dans le nouveau profil. Sélectionnez Terminer lorsque la configuration est terminée.
L’utilisation d’un profil neuf garantit qu’aucun problème de cache existant ou paramètre corrompu n’affecte le test.
- Ouvrez Outlook classique en utilisant le nouveau profil.
- Dans le menu Fichier, sélectionnez Paramètres du compte, puis sélectionnez à nouveau Paramètres du compte.
Dans l’onglet Courrier électronique, sélectionnez votre compte Exchange dans la liste.
Sélectionnez Modifier…
Cela ouvre la fenêtre Paramètres du compte Exchange.
Décochez la case Utiliser le mode Exchange mis en cache pour télécharger les e-mails dans un fichier de données Outlook.
Sélectionnez Suivant, puis Terminer.
Redémarrez Outlook pour appliquer la modification.
-
Rédigez un nouvel e-mail. Vérifiez le dossier Éléments envoyés dans la boîte aux lettres en ligne (par exemple, via Outlook sur le web) pour confirmer si la signature côté serveur apparaît.
Si la signature apparaît maintenant dans les éléments envoyés, le problème était causé par le mode Exchange mis en cache et est résolu.
Si la désactivation du mode Exchange mis en cache ne résout pas le problème, vérifiez la disponibilité et les autorisations d’EWS.
-
Vérifiez le paramètre EWS au niveau de l’organisation en exécutant la commande suivante dans PowerShell :
Get-OrganizationConfig | fl EwsEnabled -
Si le résultat indique que le paramètre est désactivé, activez EWS au niveau de l’organisation en exécutant la commande suivante dans PowerShell :
Set-OrganizationConfig -EwsEnabled:$true
Selon votre configuration, vous pourriez avoir besoin des vérifications supplémentaires suivantes :
- Vérifiez qu’EWS n’est pas désactivé au niveau de la boîte aux lettres
- Confirmez qu’aucune politique d’accès aux applications ne restreint l’accès au service Exclaimer
- Examinez les politiques d’accès conditionnel qui pourraient bloquer Exchange Online EWS
Si chaque élément envoyé dans Classic Outlook doit toujours afficher la signature, envisagez d’utiliser les signatures côté client à la place.
Avec les signatures côté client :
La signature est appliquée avant l’envoi de l’email.
L’élément envoyé est enregistré avec la signature déjà incluse.
Aucune mise à jour post-envoi ou remplacement dans la boîte aux lettres n’est nécessaire.
Il n’y a aucune dépendance au timing de synchronisation.
Pour plus d’informations, consultez la Différence des fonctionnalités entre les signatures côté client et côté serveur.
Cela évite les limitations causées par le mode Exchange mis en cache et garantit que les éléments envoyés affichent les signatures de manière cohérente sur tous les clients.
Si les résolutions ci-dessus ne résolvent pas le problème, notre équipe de support peut vous aider si vous fournissez certaines informations de diagnostic.
Pour obtenir une aide supplémentaire :
-
Exécutez la commande suivante dans PowerShell :
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass; Invoke-WebRequest -Uri "https://raw.githubusercontent.com/exclaimerltd/Internal-Support-Scripts/master/AddInChecks.ps1" -OutFile "$env:TEMP\AddInChecks.ps1"; & "$env:TEMP\AddInChecks.ps1" - Suivez les instructions à l'écran.
-
Une fois terminé, un rapport nommé AddInChecks.html sera généré.
REMARQUE : Emplacement du rapport :
Par défaut : C:\Users\<VotreUtilisateur>\Downloads\AddInChecks.html
Solution de secours (si le dossier Téléchargements n’est pas disponible) : C:\Temp\AddInChecks.html - Ouvrez un ticket de support. Ajoutez le fichier généré à l’étape 3 dans la section Pièces jointes du formulaire de ticket. Nous recommandons également de signaler vos résultats pour les solutions précédentes.
Si votre demande de support concerne l’authentification, incluez une exportation des journaux de connexion Entra ID de l’utilisateur concerné avec votre ticket de support.
Pour exporter les journaux :
- Connectez-vous au centre d’administration Microsoft Entra.
- Accédez à Surveillance & santé > Journaux de connexion.
- Dans l’onglet Connexions interactives, filtrez par UPN de l’utilisateur concerné et la plage de dates couvrant le problème, puis exportez au format CSV.
- Passez à l’onglet Connexions non interactives, appliquez le même filtre, et exportez au format CSV.
- Joignez les deux fichiers CSV à votre ticket de support.