Si Internet Explorer est lent, cliquer sur les liens à partir d'Office sera également lent, même si vous n'utilisez pas Internet Explorer comme navigateur par défaut. Donc: vérifiez si Internet Explorer fonctionne toujours bien.
Bien que vous sembliez convaincu que DDE est à blâmer, Office a une fonctionnalité étonnamment étrange: il utilise d' abord un composant Internet Explorer pour voir si l'URL sur laquelle vous cliquez est valide. Il ne s'identifie pas comme Internet Explorer; dans les journaux d'accès, on peut voir:
User Agent: Microsoft Office Existence Discovery
Après cela, il remet l'URL résultante au navigateur par défaut. C'est:
Si l'appel caché à l'URL génère une redirection, le navigateur par défaut ne reçoit même pas l'URL d'origine, mais l'URL redirigée.
Si le site Web pour une raison quelconque bloque l'agent utilisateur "Microsoft Office Existence Discovery", ou si vos paramètres Internet Explorer empêchent en quelque sorte l'accès approprié au site, alors le lien peut sembler mort alors qu'en fait en utilisant un navigateur normal, cela fonctionnerait bien.
Vous êtes-vous déjà demandé pourquoi votre navigateur vous redirige vers une page de connexion lorsque vous cliquez sur des liens depuis Office? À droite: si Internet Explorer n'est pas authentifié sur le site Web (surtout si ce n'est pas votre navigateur par défaut), certains sites peuvent répondre avec une redirection vers une page de connexion, faisant oublier à Office l'URL sur laquelle vous avez réellement cliqué ...
Plus de détails sur cette drôle de "découverte de protocole Microsoft Office" ennuyeuse dans la description de Microsoft du billet de blog Microsoft Office Existence Discovery Protocol :
Lors de l'ouverture de documents à partir d'un emplacement d'URL dans Microsoft Office 2007, la bibliothèque Office peut faire une demande HTTP HEAD au serveur Web pour l'URL d'ouverture. Cette demande est envoyée avec un User-Agent défini sur «Microsoft Office Existence Discovery». Cet appel est nouveau pour Office 2007.
Le but de la requête HEAD est de vérifier que le contenu existe à l'emplacement de l'URL en tant que document, et pas simplement en tant que ressource temporaire diffusée pour une session en lecture seule. L'appel tentera également d'obtenir la dernière heure modifiée du contenu tel que renvoyé par le serveur Web dans la réponse HEAD.
[...]
Cet appel se produit sur toutes les tentatives d'ouverture d'URL, même si la modification n'est pas demandée en soi. Par conséquent, il est possible que l'appel Web supplémentaire (effectué à partir de l'espace de processus de l'application Office dans sa session réseau et non du navigateur Web dans une session distincte) puisse faire en sorte que certains utilisateurs voient des invites supplémentaires s'authentifier (401) ou une perte d'état de session et une redirection inutile (302) vers une page de connexion ou un autre formulaire de rétroaction. Il s'agit d'un comportement attendu.
Il semble que cela puisse être désactivé à l'aide du registre; voir ma réponse sur MS Word validant les liens après avoir cliqué .