Meilleur auteur de réponses
Outlook anywhere probleme d'authentification (RPC sur HTTP)

Question
-
Bonjour ,
Ca fait trois jours que je galère sur un problème de paramétrage d'Outlook anywhere en utilisant un certificat SSL acheté.
Quelqu'un pourrait m'aider svp , je désespère. Merci Beaucoup
Test de la connectivité Outlook.
Le test de la connectivité Outlook a échoué.
Détails supplémentaires
Temps écoulé : 1792 ms.
Étapes de test
Test de la connectivité RPC sur HTTP au serveur serveur.mondomain.com
La connectivité RPC sur HTTP a échoué.
Détails supplémentaires
Temps écoulé : 1792 ms.
Étapes de test
Tentative de résolution du nom d'hôte serveur.mondomain.com dans DNS.
Le nom d'hôte a été résolu correctement.
Détails supplémentaires
Adresses IP renvoyées : xx.xx.xx.xxTemps écoulé : 9 ms.
Test du port TCP 443 sur l'hôte serveur.mondomain.com pour s'assurer qu'il écoute/est ouvert.
Le port a été ouvert correctement.
Détails supplémentaires
Temps écoulé : 144 ms.Test du certificat SSL pour confirmer sa validité.
Le certificat a transmis toutes les exigences de validation.
Détails supplémentaires
Temps écoulé : 325 ms.
Étapes de test
L’analyseur de connectivité de Microsoft tente d’obtenir le certificat SSL depuis le serveur distant serveur.mondomain.com sur le port 443... Merci de patienter.
L’analyseur de connectivité de Microsoft a obtenu avec succès le certificat SSL distant.
Détails supplémentaires
Sujet du certificat distant : CN=serveur.mondomain.com, OU=mondomain, O=mondomain, L=Paris, S=Paris, C=FR, Émetteur : CN=Thawte SSL CA, O="Thawte, Inc.", C=US.Temps écoulé : 282 ms.
Validation du nom du certificat.
Le nom de certificat a été correctement validé.
Détails supplémentaires
Nom d'hôte trouvé serveur.mondomain.comdans le nom commun sujet du nouveau certificat.Temps écoulé : 0 ms.
Les certificats de confiance sont en cours de validation.
Le certificat est approuvé et tous les certificats sont présents dans la chaîne.
Étapes de test
L’analyseur de connectivité de Microsoft tente de construire une chaîne de certificats pour le certificat CN=serveur.mondomain.com, OU=mondomain, O=mondomain, L=Paris, S=Paris, C=FR... Merci de patienter.
Une ou plusieurs chaînes de certificats ont été correctement construites.
Détails supplémentaires
1 chaînes ont été créées au total. La chaîne de qualité optimale se termine dans le certificat racine CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US.Temps écoulé : 19 ms.
Analyse d'éventuels problèmes de compatibilité des chaînes de certificats avec des versions de Windows.
Des problèmes de compatibilité potentiels avec certaines versions de Windows ont été identifiés.
Détails supplémentaires
L’analyseur de connectivité de Microsoft peut uniquement valider la chaîne de certificats à l’aide de la fonctionnalité de mise à jour des certificats racine de Windows Update. Il se peut que votre certificat ne soit pas approuvé sur Windows si la fonctionnalité « Mettre les certificats racine à jour » n’est pas activée.Temps écoulé : 2 ms.
Test de la date du certificat pour confirmer sa validité.
Validation de la date correcte. Le certificat n'a pas expiré.
Détails supplémentaires
Le certificat est valide. NotBefore = 9/29/2014 12:00:00 AM, NotAfter = 9/29/2015 11:59:59 PMTemps écoulé : 0 ms.
Vérification de la configuration IIS pour l'authentification du certificat client.
L'authentification du certificat client n'a pas été détectée.
Détails supplémentaires
Paramètres Accepter/Requérir les certificats clients non configurés.Temps écoulé : 570 ms.
Test des méthodes d'authentification HTTP pour l'URL https:serveur.mondomain.com/rpc rpcproxy.dll?serveur.mondomain.com:6002.
Le test d'authentification HTTP a échoué.
En savoir plus sur ce problème et sa résolution
Détails supplémentaires
Erreur 401 reçue du serveur mais aucune méthode d'authentification n'est prise en charge.Temps écoulé : 742 ms.
- Type modifié Teodora Sharkova lundi 20 octobre 2014 09:24 fusionnement de deux threads
- Type modifié Teodora Sharkova lundi 20 octobre 2014 10:23 fusionnement de deux threads
Réponses
-
Votre certificat acheté correspond t-il à un enregistrement A présent sur la zone DNS de votre nom de domaine ?
Cet enregistrement A pointe t-il sur l'IP publique derrière laquelle se trouve votre serveur Exchange ?
Testez d'abord l'accès OWA (utilisation du port 443) Si ça ne fonctionne pas : le port est bloqué. Si le browser donne une alerte concernant le certificat, vérifier le certificat et le nom. Si ça fonctionne sans alerte, la redirection est OK.
Créez un enregistrement SRV sur la zone DNS de votre nom de domaine externe avec les renseignements suivants :
Nom du service : _autodiscover._tcp
Server : nom utilisé pour certificat. (doit être identique à l'enregsitrement A qui pointe sur l'IP publique du seveur Exchange)
Priority : 0
Weight : 0
Port : 443
TTL : 3600Ajoutez le nom de domaine externe dans les suffixes UPN, modifiez le nom de domaine dans la partie Account" du compte de l'utilisateur dans l'AD de manière à ce qu'il puisse se connecter en utilisant son adresse email.
Faites un test de connectivité, ça doit fonctionner. Et vous pouvez configurer votre Outlook depuis n'importe où dans le monde comme avec Office365
- Modifié R2-Lionel mercredi 15 octobre 2014 12:36
- Proposé comme réponse rcarre.tsibille jeudi 16 octobre 2014 14:02
- Marqué comme réponse Teodora Sharkova vendredi 17 octobre 2014 14:16
-
Sedos,
Vers où pointe l'enregistrement A xxxxxx.fr ?
Vers où pointe l'enregistrement A autodiscover.xxxxxx.fr ?
Dans les 2 cas ils doivent pointer vers l'IP publique de votre serveur Exchange. S'il y a une différence, ce ne sont pas les mêmes serveurs qui sont contactés et vous avez un port 443 ouvert pour l'un et fermé pour l'autre.
Est-ce que l'URL que vous utilisez pour accéder à votre OWA correspond au nom de votre certificat SSL ?
Est-ce bien un certificat provenant d'une autorité de certification publique ?
Merci,
- Modifié R2-Lionel mercredi 15 octobre 2014 14:09
- Proposé comme réponse sedos lundi 20 octobre 2014 07:45
- Marqué comme réponse Teodora Sharkova lundi 20 octobre 2014 09:04
-
Bonjour, Sunspark7,
Vous avez publié l'explication du même souci dans le forum Microsoft Exchange Server, vous pouvez retrouver les solutions proposées dans:
Cordialement,
Téodora
- Proposé comme réponse Teodora Sharkova lundi 6 octobre 2014 08:24
- Marqué comme réponse Teodora Sharkova mardi 7 octobre 2014 09:24
-
OK, si ce n'est déjà fait, créez un enregistrement A portant le nom de votre certificat sur votre zone DNS et qui pointe sur l'IP publique de votre serveur Exchange.
Votre CNAME autodiscover ne sert à rien car votre certificat ne s'appelle pas autodiscover.xxxxx.fr, vous pouvez donc le supprimer.Créez ensuite un enregistrement SRV comme je vous l'ai expliqué plus haut, pointant vers l'enregistrement A que vous aurez créé précédemment.
Il n'est pas utile d'avoir à la fois : xxxxx.fr, autodiscover.xxxx.fr et l'enregistrement SRV. A partir du moment que l'un d'eux fonctionne, c'est OK.
Créez l'enregistrement SRV et refaites un test de connectivité. Il n'y a pas de raison que ça ne fonctionne pas. J'utilise cet enregistrement pour nos clients et ça fonctionne parfaitement (configuration de boîte mail directement depuis l'Asie, USA, Afrique, Europe). Le client n'utilise que son adresse email comme login et son mot de passe. Outlook fait tout le reste avec le serveur Exchange et le compte est configuré automatiquement. Comme avec Office365.
- Proposé comme réponse Teodora Sharkova dimanche 19 octobre 2014 15:45
- Marqué comme réponse Teodora Sharkova lundi 20 octobre 2014 09:05
-
Bonjour Sedos,
Il y aura toujours les 3 tests. Comme je t'ai dis plus haut, laisse tomber XXXXX.fr:443 et autodiscover.xxxxx.fr:443. Utilises directement un enregistrement SRV ça t'évitera des problèmes. A partir du moment qu'un des 3 tests est concluant, le test de connectivité est validé.
- Modifié R2-Lionel lundi 20 octobre 2014 08:36
- Proposé comme réponse Teodora Sharkova lundi 20 octobre 2014 09:06
- Marqué comme réponse Teodora Sharkova mercredi 22 octobre 2014 11:25
Toutes les réponses
-
Bonjour, Sunspark7,
Vous avez publié l'explication du même souci dans le forum Microsoft Exchange Server, vous pouvez retrouver les solutions proposées dans:
Cordialement,
Téodora
- Proposé comme réponse Teodora Sharkova lundi 6 octobre 2014 08:24
- Marqué comme réponse Teodora Sharkova mardi 7 octobre 2014 09:24
-
-
Bonsoir,
Après un test de mon Exchange avec https://testconnectivity.microsoft.com/ (
J'ai une erreur " Tentative de test de l’URL potentielle de découverte automatique https://xxxxx.fr:443/Autodiscover/Autodiscover.xml
Le test de cette URL de découverte automatique éventuelle a échoué.
"Tous les tests sur le site https://testconnectivity.microsoft.com provoque cette erreur.
Savez vous svp l'origine de cette erreur et comment résoudre cela ?
MErci
Synchronisation, notification, disponibilité et réponses automatiques des services web Exchange.
Certains tests de tâches de services web Exchange n'ont pas été effectués.
Détails supplémentaires
Étapes de test
L’analyseur de connectivité de Microsoft essaie de tester la découverte automatique pour xxx@xxxx.fr... Merci de patienter.
Découverte automatique testée correctement.
Détails supplémentaires
Étapes de test
Essai de chaque méthode pour contacter le service de découverte automatique.
Le service de découverte automatique a été testé correctement.
Détails supplémentaires
Temps écoulé : 4450 ms.
Étapes de test
Tentative de test de l’URL potentielle de découverte automatique https://xxxxx.fr:443/Autodiscover/Autodiscover.xml
Le test de cette URL de découverte automatique éventuelle a échoué.
Détails supplémentaires
Temps écoulé : 1776 ms.
Étapes de test
Tentative de résolution du nom d'hôte xxxx.fr dans DNS.
Le nom d'hôte a été résolu correctement.
Détails supplémentaires
Adresses IP renvoyées : 1.1.1.1
Temps écoulé : 358 ms.
Test du port TCP 443 sur l'hôte xxxx.fr pour s'assurer qu'il écoute/est ouvert.
Le port spécifié est bloqué, n’écoute pas ou ne produit pas la réponse attendue.
En savoir plus sur ce problème et sa résolution
Détails supplémentaires
Une erreur réseau s'est produite lors d’une communication avec l'hôte distant.
Temps écoulé : 1418 ms.Synchronisation, notification, disponibilité et réponses automatiques des services web Exchange. Certains tests de tâches de services web Exchange n'ont pas été effectués. Détails supplémentaires Étapes de test L’analyseur de connectivité de Microsoft essaie de tester la découverte automatique pour d.sottin@brochot.fr... Merci de patienter. Découverte automatique testée correctement. Détails supplémentaires Étapes de test Essai de chaque méthode pour contacter le service de découverte automatique. Le service de découverte automatique a été testé correctement. Détails supplémentaires Temps écoulé : 4450 ms. Étapes de test Tentative de test de l’URL potentielle de découverte automatique https://brochot.fr:443/Autodiscover/Autodiscover.xml Le test de cette URL de découverte automatique éventuelle a échoué. Détails supplémentaires Temps écoulé : 1776 ms. Étapes de test Tentative de résolution du nom d'hôte brochot.fr dans DNS. Le nom d'hôte a été résolu correctement. Détails supplémentaires Adresses IP renvoyées : 193.34.130.72Temps écoulé : 358 ms.Test du port TCP 443 sur l'hôte brochot.fr pour s'assurer qu'il écoute/est ouvert. Le port spécifié est bloqué, n’écoute pas ou ne produit pas la réponse attendue. <label for="testSelectWizard_ctl12_ctl06_ctl00_ctl00_ctl00_ctl01_tmmArrow">En savoir plus sur ce problème et sa résolution</label>
Détails supplémentaires Une erreur réseau s'est produite lors d’une communication avec l'hôte distant.
Temps écoulé : 1418 ms.Synchronisation, notification, disponibilité et réponses automatiques des services web Exchange. Certains tests de tâches de services web Exchange n'ont pas été effectués. Détails supplémentaires Étapes de test L’analyseur de connectivité de Microsoft essaie de tester la découverte automatique pour d.sottin@brochot.fr... Merci de patienter. Découverte automatique testée correctement. Détails supplémentaires Étapes de test Essai de chaque méthode pour contacter le service de découverte automatique. Le service de découverte automatique a été testé correctement. Détails supplémentaires Temps écoulé : 4450 ms. Étapes de test Tentative de test de l’URL potentielle de découverte automatique https://brochot.fr:443/Autodiscover/Autodiscover.xml Le test de cette URL de découverte automatique éventuelle a échoué. Détails supplémentaires Temps écoulé : 1776 ms. Étapes de test Tentative de résolution du nom d'hôte brochot.fr dans DNS. Le nom d'hôte a été résolu correctement. Détails supplémentaires Adresses IP renvoyées : 193.34.130.72Temps écoulé : 358 ms.Test du port TCP 443 sur l'hôte brochot.fr pour s'assurer qu'il écoute/est ouvert. Le port spécifié est bloqué, n’écoute pas ou ne produit pas la réponse attendue. <label for="testSelectWizard_ctl12_ctl06_ctl00_ctl00_ctl00_ctl01_tmmArrow">En savoir plus sur ce problème et sa résolution</label>
Détails supplémentaires Une erreur réseau s'est produite lors d’une communication avec l'hôte distant.
Temps écoulé : 1418 ms.Synchronisation, notification, disponibilité et réponses automatiques des services web Exchange. Certains tests de tâches de services web Exchange n'ont pas été effectués. Détails supplémentaires Étapes de test L’analyseur de connectivité de Microsoft essaie de tester la découverte automatique pour d.sottin@brochot.fr... Merci de patienter. Découverte automatique testée correctement. Détails supplémentaires Étapes de test Essai de chaque méthode pour contacter le service de découverte automatique. Le service de découverte automatique a été testé correctement. Détails supplémentaires Temps écoulé : 4450 ms. Étapes de test Tentative de test de l’URL potentielle de découverte automatique https://brochot.fr:443/Autodiscover/Autodiscover.xml Le test de cette URL de découverte automatique éventuelle a échoué. Détails supplémentaires Temps écoulé : 1776 ms. Étapes de test Tentative de résolution du nom d'hôte brochot.fr dans DNS. Le nom d'hôte a été résolu correctement. Détails supplémentaires Adresses IP renvoyées : 193.34.130.72Temps écoulé : 358 ms.Test du port TCP 443 sur l'hôte brochot.fr pour s'assurer qu'il écoute/est ouvert. Le port spécifié est bloqué, n’écoute pas ou ne produit pas la réponse attendue. <label for="testSelectWizard_ctl12_ctl06_ctl00_ctl00_ctl00_ctl01_tmmArrow">En savoir plus sur ce problème et sa résolution</label>
Détails supplémentaires Une erreur réseau s'est produite lors d’une communication avec l'hôte distant.
Temps écoulé : 1418 ms.- Fusionné Teodora Sharkova lundi 13 octobre 2014 11:11 fusionnement de thread
-
Bonsoir,
D'après les erreurs remontés, il semblerait que vous le port 443 ne soit pas accessible depuis l'exterieur.
Votre serveur (et son nom d’hôte) sont correctement résoud coté DNS mais l’accès ne semble pas autorisé.
Vous pouvez regarder du coté de votre parefeu et/ou reverse proxy pour la publication des services web de votre serveur Exchange.
Merci
Hakim Taoussi - Consultant Exchange - http://exchangediscover.blogspot.fr
-
Bonjour, sedos,
Veuillez consulter l'article suivant:
Une erreur réseau s’est produite lors d’une communication avec l’hôte distant
Cordialement,
Téodora
Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.
- Modifié Teodora Sharkova mercredi 8 octobre 2014 06:47
-
-
Bonjour,
La redirection du port du parefeu vers votre serveur Exchange est correcte ?
Coté Exchange, tous les serveurs sont démarrés correctement, aucun message particulier dans le journal?
Merci
Hakim Taoussi - Consultant Exchange - http://exchangediscover.blogspot.fr
-
Bonjour,
Oui la redirection est correcte.
Au niveau du serveur j'ai des erreurs
Échec de la cmdlet. Cmdlet Get-MailboxDatabaseCopyStatus, paramètres {Identity=Public\*, Active=True}.
L’alerte fatale suivante a été générée : 10. L’état d’erreur interne est 1203.
Merci,
-
tu peux utiliser un lister sans authentification plutôt qu'avec un formulaire. si l'adresse DNS existe dans la zone publique et pointe bien vers ton serveur TMG qui redirige le flux vers ton Exchange ça devrait fonctionner.
Essaye déjà de vérifier la connectivité avec un Telnet sur le port 443.
- Proposé comme réponse Stéphane Mendez jeudi 9 octobre 2014 12:40
- Modifié Stéphane Mendez jeudi 9 octobre 2014 12:41
- Non proposé comme réponse Bruce JDCModerator vendredi 10 octobre 2014 09:32
-
Bonjour Stephane,
Je n'ai pas compris la première partie de ton message mais j'ai essayé telnet sur le 443 mais j'ai le message
Microsoft Telnet> open 10.1.1.4 443
Connexion à 10.1.1.4...
Appuyez sur une touche pour continuer...Perte de la connexion à l'hôte.
Merci,
-
-
Bonjour,
Je viens de lire la réponse ci dessous sur ce forum http://community.office365.com/en-us/f/158/t/42734.aspx
Pensez vous que cela justifie mon problème aussi ?
Hi Tony,
You said you got two errors in the Autodiscover testing for your email account. One is it's failed on the testing of https://yourdomain.com/AutoDiscover/AutoDiscover.xml and one is failed on the testing ofhttps://autodiscover.yourdomain.com/AutoDiscover/AutoDiscover.xml. It's normal, you didn't do anything wrong. The reason is you create CNAME in your host provider and re-point your Autodiscover service to xxx.outlook.com. The testing tool will follow the default process to test the connection. First it will find the original domain to test whether autodiscover can pass, and then will test autodiscover.yourdomain.com. Finally it will check whether there are some CNAME setting for you domain to re-point autodiscover.
If you are using xyz@yourdomain.com, the primary SMTP domain is yourdomain.com. It will first check the primary SMTP domain, then check the secondary Autodiscover service URLhttps://autodiscover.yourdomain.com/autodiscover/autodiscover.xml. For more information about how the Autodiscover Service Work you can refer to: http://technet.microsoft.com/en-us/library/bb124251.aspx#works.Best Regards
Martin Xu
Microsoft Office 365 Support
-
-
Bonjour, sedos,
Je vous remercie pour toute l'information partagée par vous, concernant votre souci et les resultats des solutuons proposées.
Je vous suggère d'ouvrir en parallele un ticket aupres du support O365, une bonne partie des actions d'analyse et de résolution ne peuvent se faire qu'au niveau de l'infrastructure, ce à quoi seul le support officiel à accès.
Cordialement,
Téodora
Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.
- Marqué comme réponse Teodora Sharkova mardi 14 octobre 2014 10:39
-
-
-
Votre certificat acheté correspond t-il à un enregistrement A présent sur la zone DNS de votre nom de domaine ?
Cet enregistrement A pointe t-il sur l'IP publique derrière laquelle se trouve votre serveur Exchange ?
Testez d'abord l'accès OWA (utilisation du port 443) Si ça ne fonctionne pas : le port est bloqué. Si le browser donne une alerte concernant le certificat, vérifier le certificat et le nom. Si ça fonctionne sans alerte, la redirection est OK.
Créez un enregistrement SRV sur la zone DNS de votre nom de domaine externe avec les renseignements suivants :
Nom du service : _autodiscover._tcp
Server : nom utilisé pour certificat. (doit être identique à l'enregsitrement A qui pointe sur l'IP publique du seveur Exchange)
Priority : 0
Weight : 0
Port : 443
TTL : 3600Ajoutez le nom de domaine externe dans les suffixes UPN, modifiez le nom de domaine dans la partie Account" du compte de l'utilisateur dans l'AD de manière à ce qu'il puisse se connecter en utilisant son adresse email.
Faites un test de connectivité, ça doit fonctionner. Et vous pouvez configurer votre Outlook depuis n'importe où dans le monde comme avec Office365
- Modifié R2-Lionel mercredi 15 octobre 2014 12:36
- Proposé comme réponse rcarre.tsibille jeudi 16 octobre 2014 14:02
- Marqué comme réponse Teodora Sharkova vendredi 17 octobre 2014 14:16
-
Bonjour R2,
Le OWA marche bien et arrive bien à configurer Outlook depuis n'importe ou dans le monde.
La question est pourquoi la première tentative de L’URL échoue et le deuxième réussi et comment remédié à ça ?
----
Essai de chaque méthode pour contacter le service de découverte automatique.
Le service de découverte automatique a été testé correctement.
Détails supplémentaires
Temps écoulé : 4766 ms.
Étapes de test
Tentative de test de l’URL potentielle de découverte automatique https://xxxxx.fr:443/Autodiscover/Autodiscover.xml
Le test de cette URL de découverte automatique éventuelle a échoué.
Détails supplémentaires
Temps écoulé : 1817 ms.
Étapes de test
Tentative de résolution du nom d'hôte xxxxx.fr dans DNS.
Le nom d'hôte a été résolu correctement.
Détails supplémentaires
Test du port TCP 443 sur l'hôte xxxxx.fr pour s'assurer qu'il écoute/est ouvert.
Le port spécifié est bloqué, n’écoute pas ou ne produit pas la réponse attendue.
En savoir plus sur ce problème et sa résolution
Détails supplémentaires
Une erreur réseau s'est produite lors d’une communication avec l'hôte distant.
Temps écoulé : 1492 ms.
Tentative de test de l’URL potentielle de découverte automatique https://autodiscover.xxxxxx.fr:443/Autodiscover/Autodiscover.xml
Le test de l'URL de découverte automatique a réussi.Merci,
- Modifié sedos mercredi 15 octobre 2014 13:49
-
Sedos,
Vers où pointe l'enregistrement A xxxxxx.fr ?
Vers où pointe l'enregistrement A autodiscover.xxxxxx.fr ?
Dans les 2 cas ils doivent pointer vers l'IP publique de votre serveur Exchange. S'il y a une différence, ce ne sont pas les mêmes serveurs qui sont contactés et vous avez un port 443 ouvert pour l'un et fermé pour l'autre.
Est-ce que l'URL que vous utilisez pour accéder à votre OWA correspond au nom de votre certificat SSL ?
Est-ce bien un certificat provenant d'une autorité de certification publique ?
Merci,
- Modifié R2-Lionel mercredi 15 octobre 2014 14:09
- Proposé comme réponse sedos lundi 20 octobre 2014 07:45
- Marqué comme réponse Teodora Sharkova lundi 20 octobre 2014 09:04
-
Bonsoi R2r,
xxxxxx.fr et autodiscover.xxxx.fr pointe sur deux adresses publiques différentes. autodiscover.xxxxxx.fr est un cname du OWA.
On vient juste de renouveler notre certificat mais il porte pas le nom du owa et le certificat provient bien d'une autorité de certification.
L’échec du test est toujours présent.
Merci ...
-
OK, si ce n'est déjà fait, créez un enregistrement A portant le nom de votre certificat sur votre zone DNS et qui pointe sur l'IP publique de votre serveur Exchange.
Votre CNAME autodiscover ne sert à rien car votre certificat ne s'appelle pas autodiscover.xxxxx.fr, vous pouvez donc le supprimer.Créez ensuite un enregistrement SRV comme je vous l'ai expliqué plus haut, pointant vers l'enregistrement A que vous aurez créé précédemment.
Il n'est pas utile d'avoir à la fois : xxxxx.fr, autodiscover.xxxx.fr et l'enregistrement SRV. A partir du moment que l'un d'eux fonctionne, c'est OK.
Créez l'enregistrement SRV et refaites un test de connectivité. Il n'y a pas de raison que ça ne fonctionne pas. J'utilise cet enregistrement pour nos clients et ça fonctionne parfaitement (configuration de boîte mail directement depuis l'Asie, USA, Afrique, Europe). Le client n'utilise que son adresse email comme login et son mot de passe. Outlook fait tout le reste avec le serveur Exchange et le compte est configuré automatiquement. Comme avec Office365.
- Proposé comme réponse Teodora Sharkova dimanche 19 octobre 2014 15:45
- Marqué comme réponse Teodora Sharkova lundi 20 octobre 2014 09:05
-
Bonjour Lionel,
Merci pour tes réponses. Tes questions m'ont aidé à savoir pourquoi on l'échec sur https://xxxxx.fr:443/Autodiscover/Autodiscover.xml .
En faite notre https://xxxx:443 pointe sur l'adresse ip publique du site web et non du serveur exchange alors que le https://autodiscover.xxxxxx.fr:443/Autodiscover/Autodiscover.xml qui a réussi pointe bien sur l'adresse ip publique du serveur exchange. Ce qui m’amène à une autre question comment peut on faire pour que au ment du test de connectivité d'exchange, qu'il ne test pas le https://xxxxx.fr:443/Autodiscover/Autodiscover.xml et va directement à https://autodiscover.xxxxxx.fr:443/Autodiscover/Autodiscover.xml .
Merci ,
-
Bonjour Sedos,
Il y aura toujours les 3 tests. Comme je t'ai dis plus haut, laisse tomber XXXXX.fr:443 et autodiscover.xxxxx.fr:443. Utilises directement un enregistrement SRV ça t'évitera des problèmes. A partir du moment qu'un des 3 tests est concluant, le test de connectivité est validé.
- Modifié R2-Lionel lundi 20 octobre 2014 08:36
- Proposé comme réponse Teodora Sharkova lundi 20 octobre 2014 09:06
- Marqué comme réponse Teodora Sharkova mercredi 22 octobre 2014 11:25
-
-
Bonjour, Sunspark7,
Je suis ravie de voir que vous avez trouvé une solution à votre souci dans:
Exchange 2010 : problème d'outlook anywhere avec un certificat SSL
N'hésitez pas à poser des questions complémentaires, en cas de besoin.
Cordialement,
Téodora
Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.
- Marqué comme réponse Teodora Sharkova lundi 20 octobre 2014 09:21