यह समस्या आउटलुक की ऑटोडिस्कवर सेवा, आउटलुक एनीवेयर फंक्शनलिटी का हिस्सा है । ऑटोडिस्कवर एक्सचेंज द्वारा दी जाने वाली विभिन्न सेवाओं पर एंड-यूज़र के आउटलुक क्लाइंट को विभिन्न जानकारी प्रदान करता है और ये कहाँ स्थित हो सकते हैं; इसका उपयोग विभिन्न उद्देश्यों के लिए किया जाता है:
आउटलुक के पहले-रन पर आउटलुक प्रोफाइल का ऑटोकैफिगरेशन, जो केवल उपयोगकर्ता के ईमेल पते और पासवर्ड का उपयोग करके एक एक्सचेंज खाते को कॉन्फ़िगर कर सकता है, क्योंकि अन्य जानकारी स्वचालित रूप से स्थित और पुनर्प्राप्त की जाती है।
आउटलुक क्लाइंट द्वारा एक्सेस की गई वेब-आधारित सेवाओं की डायनामिक लोकेशन, जिसमें आउट-ऑफ-ऑफिस असिस्टेंट, यूनिफाइड मैसेजिंग फंक्शनालिटी, एक्सचेंज कंट्रोल पैनल (ईसीपी) का स्थान और इसके बाद के संस्करण शामिल हैं।
यह RFC 6186 का Microsoft का स्वामित्व कार्यान्वयन है । दुर्भाग्य से, उन्होंने आउटलुक एनीवेज़ के डिज़ाइन में उस RFC की सिफारिशों का वास्तव में पालन नहीं किया, लेकिन HTTPS कार्यक्षमता पर एक्सचेंज और RPC के बाद से संभवतः इसकी उम्मीद की जा रही है, यह एक पारंपरिक IMAP / SMTP सर्वर नहीं है।
ऑटोडिस्कवर कैसे काम करता है (बाहरी * उपयोगकर्ताओं के लिए)?
ऑटोडिस्कवर क्लाइंट एक्सेस सर्वर पर एक वेब सेवा के साथ संचार करता है (इस मामले में, सभी भूमिकाएं एसबीएस सर्वर पर हैं) /Autodiscover/Autodiscover.xml, इसकी डिफ़ॉल्ट वेब साइट से रूट की गई हैं। सर्वर के FQDN के साथ संवाद करने का पता लगाने के लिए, यह डोमेन (यानी @ companyB.com) को छोड़कर, ईमेल पते के उपयोगकर्ता भाग को हटा देता है। यह निम्न में से प्रत्येक URL का उपयोग करके ऑटोडिस्कवर के साथ संवाद करने का प्रयास करता है:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
यदि ये विफल होते हैं, तो यह एसएसएल को अक्षम करके और पोर्ट 80 (HTTP) पर संचार करने का प्रयास करके एक गैर-सुरक्षित कनेक्शन का प्रयास करेगा, आमतौर पर उपयोगकर्ता को यह पुष्टि करने के लिए संकेत देने के बाद कि यह स्वीकार्य कार्रवाई है (मेरी राय में एक त्रुटिपूर्ण विकल्प है, चूंकि क्लूलेस उपयोगकर्ता। आम तौर पर इसे स्वीकार करते हैं और जोखिम को सादा पाठ पर क्रेडेंशियल्स भेजते हैं - और क्लूलेस सीसडैमिन जिन्हें क्रेडेंशियल्स के सुरक्षित संचार की आवश्यकता नहीं है और व्यवसाय-संवेदनशील डेटा व्यवसाय निरंतरता के लिए एक जोखिम है)।
अंत में, DNS में एक सेवा रिकॉर्ड (SRV) का उपयोग करके एक फॉलो-ऑन चेक बनाया जाता है, जो नाम स्थान से एक प्रसिद्ध स्थान पर मौजूद है companyB.comऔर Outlook को उचित URL पर पुनर्निर्देशित कर सकता है जहां सर्वर सुन रहा है।
क्या गलत हो सकता हैं?
इस प्रक्रिया में कई मुद्दों में से एक उत्पन्न हो सकता है:
कोई DNS प्रविष्टियां नहीं
सामान्यतया, डोमेन का रूट ( companyB.com) DNS में होस्ट रिकॉर्ड के लिए हल नहीं हो सकता है। अनुचित DNS कॉन्फ़िगरेशन (या आउटलुक एनीवेयर सेवा को उजागर नहीं करने का एक सचेत निर्णय) का अर्थ हो सकता है कि autodiscover.companyB.comरिकॉर्ड मौजूद ही नहीं है।
इन मामलों में, कोई बड़ा मुद्दा नहीं है; आउटलुक केवल अंतिम ज्ञात कॉन्फ़िगरेशन का उपयोग करके एक्सचेंज के साथ संवाद करना जारी रखता है, और कुछ वेब-आधारित कार्यों के संबंध में अपमानित किया जा सकता है, जिसके लिए ऑटोडिस्कवर (जैसे आउट-ऑफ-ऑफिस सहायक) के माध्यम से यूआरएल को पुनर्प्राप्त करना होगा। इस तरह के कार्यों का उपयोग करने के लिए आउटलुक वेब एक्सेस का उपयोग करने के लिए एक समाधान है।
नए आउटलुक प्रोफाइल में एक्सचेंज खातों का स्वचालित कॉन्फ़िगरेशन भी स्वचालित नहीं है, और HTTPS सेटिंग्स पर RPC के मैनुअल कॉन्फ़िगरेशन की आवश्यकता होती है। हालाँकि, यह आपके द्वारा बताई गई समस्या का कारण नहीं होगा।
दोषपूर्ण एसएसएल प्रमाणपत्र
यह पूरी तरह से संभव है कि एक्सचेंज सर्वर से संपर्क करने का प्रयास करने के लिए URL आउटलुक एक मेजबान को हल करता है, जो क्लाइंट एक्सेस सर्वर हो सकता है या नहीं। यदि आउटलुक पोर्ट 443 पर उस सर्वर के साथ संवाद कर सकता है, तो निश्चित रूप से आउटलुक और रिमोट सर्वर के बीच एक सुरक्षित चैनल स्थापित करने के लिए प्रमाण पत्र का आदान-प्रदान किया जाएगा। यदि URL आउटलुक का मानना है कि यह उस प्रमाणपत्र पर सूचीबद्ध नहीं है - तो इसे सामान्य नाम या किसी विषय वैकल्पिक नाम (SAN) के रूप में सूचीबद्ध करें - यह आउटलुक को आपके प्रारंभिक पोस्ट में आपके द्वारा वर्णित संवाद को प्रस्तुत करने के लिए हटा देगा।
यह कई कारणों से हो सकता है, यह सब नीचे है कि DNS कैसे कॉन्फ़िगर किया गया है और मैंने ऊपर वर्णित URL कैसे Outlook द्वारा जांचे हैं:
यदि https://companyB.com/... URL एक होस्ट रिकॉर्ड के लिए हल होता है, और उस पते पर वेब सर्वर पोर्ट 443 पर सुनता है, और इसमें एक एसएसएल प्रमाणपत्र होता है जो सामान्य नाम या विषय वैकल्पिक नाम में सूचीबद्ध नहीं होता है companyB.com, तो समस्या उत्पन्न होगी। यह महत्वपूर्ण नहीं है कि मेजबान एक एक्सचेंज सर्वर है या नहीं; यह एक वेब सर्वर हो सकता है जो कंपनी की वेबसाइट की मेजबानी कर रहा है जो ठीक से कॉन्फ़िगर नहीं है। Corrige या तो:
companyB.comज़ोन के रूट पर होस्ट रिकॉर्ड को अक्षम करें (वेबसाइट या अन्य सेवा में आगंतुकों को प्रवेश करने की आवश्यकता है www.companyB.com, या समकक्ष; याcompanyB.comपोर्ट 443 पर मशीन तक पहुंच को अक्षम करें , जिससे companyB.comप्रमाणपत्रों के आदान-प्रदान और आगे बढ़ने से पहले आउटलुक यूआरएल को अस्वीकार कर देगा; या- पर प्रमाण पत्र को ठीक
companyB.comसुनिश्चित करने के लिए companyB.comकि प्रमाण पत्र पर सूचीबद्ध है, और है कि यात्रा करने के लिए प्रयास करता है https://companyB.comएक मानक ब्राउज़र असफल नहीं में।
companyB.comएक्सचेंज सर्वर के लिए चाहे जो भी हो, उपरोक्त लागू होता है ; यदि आउटलुक इसके साथ संवाद कर सकता है, तो उसे बाद में पता चलेगा कि /Autodiscover/Autodiscover.xmlपथ HTTP 404 त्रुटि देता है (मौजूद नहीं है) और आगे बढ़ता है।
यदि https://autodiscover.companyB.com/... URL एक्सचेंज सर्वर (या किसी अन्य सर्वर) पर हल होता है, लेकिन, फिर से, autodiscover.companyB.comसामान्य नाम या एक विषय वैकल्पिक नाम के रूप में सूचीबद्ध नहीं है, तो आप इस व्यवहार का निरीक्षण करेंगे। यह प्रमाण पत्र फिक्सिंग से जैसा कि ऊपर निर्धारित किया जा सकता है, या के रूप में आप ठीक ही संकेत मिलता है, तो आप एक का उपयोग कर सकते SRV रिकॉर्ड एक URL, जिस पर आउटलुक रीडायरेक्ट करने के लिए है प्रमाण पत्र और जो आउटलुक पर सूचीबद्ध कर सकते हैं के साथ संवाद।
इस मुद्दे पर आपका संभावित समाधान
इस मामले में, बाद में करने के लिए विशिष्ट फिक्स है; आउटलुक को पुनर्निर्देशित करने के लिए नए DNS प्रदाता में SRV रिकॉर्ड बनाएं autodiscover.companyA.com, जो (किसी भी अन्य मुद्दों को एक तरफ) सफलतापूर्वक काम करेगा क्योंकि यह प्रमाणपत्र पर एक SAN के रूप में सूचीबद्ध है। यह काम करने के लिए, आपको निम्न करने की आवश्यकता है:
- प्रलेखन के
_autodiscover._tcp.companyB.com अनुसार SRV रिकॉर्ड कॉन्फ़िगर करें ।
autodiscover.companyB.comयदि यह मौजूद है, तो आउटलुक को रोकने और इस तरह से ऑटोडिस्कवर तक पहुंचने का प्रयास करने के लिए, होस्ट रिकॉर्ड को हटा दें ।- HTTPS तक पहुंच के साथ किसी भी समस्या को हल करें
https://companyB.com, क्योंकि आउटलुक SRV रिकॉर्ड दृष्टिकोण पर गिरने से पहले उपयोगकर्ता के ईमेल पते से प्राप्त यूआरएल को फिर से जोड़ देगा।
* ऑटोडिस्कवर कैसे काम करता है (आंतरिक, डोमेन से जुड़े ग्राहकों के लिए)?
मैं इसे केवल पूर्णता के लिए जोड़ता हूं, क्योंकि यह इन प्रमाण पत्रों के होने का एक और सामान्य कारण है।
डोमेन-ज्वाइन किए गए क्लाइंट पर, जब यह एक्सचेंज वातावरण (यानी आंतरिक लैन पर) के लिए स्थानीय होता है, तो उपरोक्त तकनीकों का उपयोग नहीं किया जाता है। इसके बजाय, Outlook सक्रिय निर्देशिका में एक सेवा कनेक्शन बिंदु (एक्सचेंज क्लाइंट एक्सेस सेटिंग्स में सूचीबद्ध) के साथ सीधे संवाद करता है, जो उस URL को सूचीबद्ध करता है जहां Outlook ऑटोडिस्कवर सेवा का पता लगा सकता है।
इन परिस्थितियों में सर्टिफिकेट चेतावनी देना आम बात है, क्योंकि:
- इस उद्देश्य के लिए कॉन्फ़िगर किया गया डिफ़ॉल्ट URL एक्सचेंज के आंतरिक URL को संदर्भित करता है , जो अक्सर सार्वजनिक URL से भिन्न होता है।
- SSL प्रमाणपत्र उन पर आंतरिक URL को सूचीबद्ध नहीं कर सकते हैं। वर्तमान में, आपका करता है, लेकिन यह भविष्य में सक्रिय निर्देशिका डोमेन के लिए एक समस्या बन सकता है जो
.localगैर-वैश्विक gTLD डोमेन नाम प्रत्यय का उपयोग करता है और समान है, क्योंकि ICANN का एक निर्णय ऐसे डोमेन के लिए SSL प्रमाणपत्र को प्रतिबंधित करता है, जो 2016 के बाद जारी किए जा रहे हैं।
- आंतरिक पता उचित सर्वर पर हल नहीं हो सकता है।
इस मामले में, स्विच के Set-ClientAccessServerसाथ cmdlet चलाकर उचित, बाहरी पते (प्रमाण पत्र में सूचीबद्ध) को संदर्भित करने के लिए रिकॉर्ड किए गए URL को सही करके मामला हल किया जाता है -AutodiscoverServiceInternalUri। ऐसा करने वाली पार्टियाँ आमतौर पर विभाजित-क्षितिज DNS को भी कॉन्फ़िगर करती हैं , या तो क्योंकि उन्हें अपने नेटवर्क कॉन्फ़िगरेशन और / या अपस्ट्रीम रिज़ॉल्वर / कनेक्शन आउटेज की स्थिति में रिज़ॉल्यूशन की निरंतरता के लिए ऐसा करना आवश्यक है।