Outlook-ის ქეშირებული ფოსტა იხსნება, მაგრამ არაფერი სინქრონიზდება: რა უნდა შემოწმდეს

ძველი ფოსტა იხსნება, საქაღალდეების სია ნორმალურად გამოიყურება და დღეს დილით გაგზავნილი შეტყობინება არასოდეს ტოვებს გამავალ საქაღალდეს. ეს კომბინაცია ამბობს, რომ ლოკალური ქეში კარგია, ხოლო Exchange-თან კავშირი არა, და ეს არის ყველაზე ხშირად არასწორად გაგებული სიმპტომი ამ მთელ სფეროში. არაფერი ჩამოვარდა, ამიტომ ანგარიში ჩვეულებრივ მოდის როგორც ნელი Outlook, და არა როგორც გათიშული Outlook.

შეასრულეთ შემოწმებები თანმიმდევრობით და პირველ რიგში ჩაიწერეთ, Outlook-ის რომელ ვერსიას უყურებთ, რადგან კონტროლი განსხვავდება.

დაადგინეთ რომელი კლიენტი და რომელი ანგარიშის ტიპი

კლასიკური Outlook Windows-ისთვის, ახალი 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 იმსახურებს ყურადღებას, წარუმატებელი ოპერაციიდან აღებული მტკიცებულებებით.

ქეშის რეჟიმის შეცვლამ შეიძლება სიმპტომი გადაიტანოს მარშრუტის ან სერვისის შეკეთების გარეშე.

ნებისმიერი მხარდაჭერილი შესწორების შემდეგ გაიმეორეთ საწყისი ოპერაცია და დაადასტურეთ, რომ ახალი მონაცემები სერვერამდე აღწევს და უკან ბრუნდება. ჩაიწერეთ ეს შედეგი ცალკე იმ სიმარტივისგან, რომ წაიკითხოთ ფოსტა, რომელიც უკვე დისკზე იყო.