Outlook का कैश किया मेल खुलता है पर कुछ भी सिंक नहीं होता: क्या जाँचें

पुराना मेल खुलता है, फ़ोल्डर सूची सामान्य दिखती है, और आज सुबह भेजा गया संदेश आउटबॉक्स से कभी नहीं निकलता। यह संयोजन कहता है कि स्थानीय कैश ठीक है और Exchange से कनेक्शन नहीं, और यह इस पूरे क्षेत्र में सबसे अधिक गलत समझा जाने वाला लक्षण है। कुछ भी क्रैश नहीं हुआ, इसलिए रिपोर्ट आमतौर पर Outlook के धीमे होने के रूप में आती है, Outlook के डिस्कनेक्ट होने के रूप में नहीं।

जाँचें क्रम में करें, और कुछ और करने से पहले लिख लें कि आप कौन-सा Outlook बिल्ड देख रहे हैं, क्योंकि नियंत्रण अलग-अलग होते हैं।

निश्चित करें कि कौन-सा क्लाइंट और कौन-सा खाता प्रकार

Windows के लिए क्लासिक Outlook, नया Outlook और वेब पर Outlook तीन अलग क्लाइंट हैं जिनके तीन अलग कनेक्शन पथ हैं, और एक के लिए दी गई सलाह दूसरे के लिए अक्सर गलत होती है। क्लासिक Outlook के भीतर, सर्वर तक पहुँच न होने पर Exchange खाता और POP या IMAP खाता अलग व्यवहार करते हैं, क्योंकि केवल Exchange खाते में MAPI ट्रांसपोर्ट और कैश किया मेलबॉक्स स्टोर होता है। किसी भी स्थिति की व्याख्या करने से पहले खाता सेटिंग्स में खाता प्रकार पहचानें। IMAP सेटअप से कॉपी किया गया समाधान Exchange कनेक्शन का वर्णन नहीं करेगा।

क्लाइंट का नाम और संस्करण लिखें। सहायता थ्रेड में इन्हें नियमित रूप से मिला दिया जाता है, और स्क्रीनशॉट आधे रास्ते में मेल खाना बंद कर देते हैं।

विफल होते समय कनेक्शन स्थिति पढ़ें

क्लासिक Outlook चालू होने पर Ctrl दबाए रखें और सूचना क्षेत्र के आइकन पर राइट-क्लिक करें, फिर कनेक्शन स्थिति खोलें। यह विफल हो रहे ऑपरेशन के दौरान करें, रीस्टार्ट के बाद नहीं, क्योंकि यह दृश्य बताता है कि उस क्षण क्लाइंट क्या करने का प्रयास कर रहा है। सर्वर का नाम, प्रोटोकॉल और स्थिति दर्ज करें, फिर उस सर्वर की तुलना उससे करें जिसका उपयोग खाते से आप अपेक्षा करते हैं। Microsoft के निदान संबंधी मार्गदर्शन में यह दृश्य और वह अधिक विस्तृत लॉगिंग शामिल है जो सारांश पर्याप्त न होने पर एकत्र की जा सकती है।

आधुनिक Exchange परिनियोजन Outlook ट्रैफ़िक को MAPI over HTTP पर ले जाते हैं, इसलिए SMTP सबमिशन पोर्ट खोलना मेलबॉक्स कनेक्शन के लिए मरम्मत नहीं है। यदि ट्रांसपोर्ट सेवा तक पहुँचता है, तो HTTP या प्रमाणीकरण त्रुटि को सहेजें और उस चरण पर काम करें, ऐसा पासवर्ड रीसेट करने के बजाय जो कभी समस्या नहीं था।

एंडपॉइंट की ब्राउज़र के पथ से तुलना करें

कार्यशील वेब मेलबॉक्स साबित करता है कि कोई ब्राउज़र एक नाम और एक प्रॉक्सी कॉन्फ़िगरेशन के माध्यम से एक एंडपॉइंट तक पहुँच सकता है। यह साबित नहीं करता कि Outlook ने वही पता हल किया, वही मार्ग इस्तेमाल किया या वही प्रमाणपत्र स्वीकार किया। VPN होने पर स्प्लिट DNS Outlook का नाम आंतरिक पते पर भेज सकता है जबकि ब्राउज़र सार्वजनिक पता इस्तेमाल करता है, और यही अंतर अकेले टूटे क्लाइंट के बगल में काम करते वेब सत्र को समझाता है। दोनों पथों पर हल किया गया पता, चुना गया मार्ग और TLS पहचान की तुलना करें।

प्रशासनिक पोर्टल और रिमोट PowerShell उपयोगकर्ता मेलबॉक्स परीक्षण के विकल्प नहीं हैं, क्योंकि वे अलग प्रमाणीकरण वाली अलग सेवाएँ हैं।

नए ऑपरेशन के सामने कैश का परीक्षण करें

कैश्ड Exchange मोड स्थानीय प्रतिलिपि रखता है और सर्वर के साथ सिंक करता है, जो इसे रुकावट के प्रति सहनशील बनाता है और सर्वर से स्वतंत्र नहीं बनाता। पुराना कैश किया संदेश पढ़ना नेटवर्क परीक्षण नहीं है, और ऑफ़लाइन काम करें टॉगल भी नहीं। नया संदेश भेजें या सिंक बाध्य करें और उस विशिष्ट ऑपरेशन को देखें। यदि छोटे आदान-प्रदान सफल हों जबकि बड़े स्थानांतरण अटक जाएँ, तो पैकेट आकार और पथ MTU ध्यान देने योग्य हैं, विफल ऑपरेशन से लिए गए साक्ष्य के साथ।

कैश मोड बदलने से लक्षण हट सकता है पर मार्ग या सेवा ठीक नहीं होती।

किसी भी समर्थित सुधार के बाद मूल ऑपरेशन दोहराएँ और पुष्टि करें कि नया डेटा सर्वर तक पहुँचता है और वापस आता है। उस परिणाम को डिस्क पर पहले से मौजूद मेल पढ़ने की सुविधा से अलग दर्ज करें।