סיכום
גילוי אוטומטי הוא התכונה שבה Outlook משתמש כדי לקבל פרטי תצורה עבור שרתים שאליהם הוא מתחבר. ב Outlook 2016 עם שרתי Exchange, גילוי אוטומטי נחשב לנקודה בודדת של אמת עבור מידע תצורה ויש לקבוע את תצורתו יפעלו כראוי כדי ש- Outlook יהיה פונקציונלי באופן מלא. מאמר זה מתאר את היישום של גילוי אוטומטי בהפצה הנוכחית של 'לחץ והפעל' של Outlook 2016. לקבלת מידע נוסף על המהדורות Office 365 לקוח, עיין באתרי האינטרנט הבאים של Microsoft:
מספרי גירסאות וגירסאות Build של מהדורות ערוצי עדכון Office 365 לקוחות
מידע נוסף
תזמון גילוי אוטומטי
גילוי אוטומטי פועל במועדים הבאים:
- במהלך יצירת החשבון.
- במרווחי זמן קבועים לאיסוף שינויים בכתובות URL המספקות תכונות של שירות אינטרנט של Exchange (מחוץ למשרד, שירות זמינות וכן הלאה). אם תהליך זה מצליח, ניתן לנסות שוב כשעה לאחר מכן. אם הניסיון אינו מצליח, הניסיון הבא יתבצע 5 דקות מאוחר יותר. תשתית המשימות ברקע המשמשת את כל יישומי Microsoft Office יכולה לתעד כל ניסיון אפשרי על-ידי עד 25 אחוזים.
- בתגובה לכשלים מסוימים בקישוריות. בתרחישים שונים, כאשר ניסיון חיבור נכשל, Outlook מפעיל משימה של גילוי אוטומטי כדי לאחזר הגדרות חדשות בכל ניסיון לפתור את בעיית החיבור.
- כאשר יישום אחר מפעיל אותו באמצעות MAPI. לקבלת מידע נוסף אודות MAPI, עיין במאמר MSDN הבא: חומר עזר בנושא MAPI ב- Outlook.
יעילות גילוי אוטומטי
השתמש בשם ראשי של משתמש (UPN) כדי לזרז את תהליך הגילוי האוטומטי.
במחשב המצורף לתחום, Outlook צריך לדעת את ה- UPN עבור משתמש כדי ליזום את תהליך הגילוי האוטומטי. ייתכן שה- UPN שימש לכניסה ל- Windows, במקרה זה ל- Outlook יש גישה ישירה ל- UPN מתוך אישורי הכניסה. אך אם משתמש משתמש ב- domain\username כדי להיכנס ל- Windows, Outlook כולל רק את אותו אישור עבור המשתמש. כדי לקבל את ה- UPN, Outlook חייב תחילה לחפש את המשתמש במדריך הכתובות. Outlook מבקש שבדיקת מידע זו תרדוף אחר הפניות. בסביבות מורכבות, הדבר עלול לגרום ליצירת קשר עם מספר רב של מחשבים לפני שנמצאת תוצאה. לאחר ש- Outlook מציין את ה- UPN עבור המשתמש, הערך מאוחסן במטמון בפרופיל, ובדיקת המידע לא אמורה להתרחש שוב עבור משתמש זה.
כדי להימנע מתרחיש זה, המשתמש יכול להיכנס באמצעות UPN במקום domain\username.
שיקולי ITAR
Microsoft Office 365 מספק תכונות ה יכולות לתמוך לקוחות עם התחייבויות ITAR. בהקשר של התכונה 'גילוי אוטומטי' ב- Outlook, ערכת תכונות זו כוללת הגדרות מדיניות ופעולות פעולה שמבטיחות שנקודות הקצה של השירות המשמשות עבור גילוי אוטומטי מצייתות לדרישות ענן ריבוניות. באופן ספציפי, בשלבים הספציפיים של Office 365 המפורטים בתהליך הגילוי האוטומטי (שלב 4 וצעד 11), בקרת מדיניות זמינה כדי להבטיח שנעשה שימוש בנקודות קצה מתאימות של השירות במהלך תהליך הגילוי האוטומטי.
תהליך גילוי אוטומטי בכל פעם ש- Outlook זקוק למידע גילוי אוטומטי, הוא משתמש בערכה של שלבים מסודרים כדי לנסות לאחזר תוכן מנה של XML המכיל הגדרות תצורה. רבים מצעדים אלה עשויים להיות נשלטים באמצעות מדיניות קבוצתית אובייקטים (GPO) וערך ה- GPO נכלל בתיאור השלב.
שלב 1: בדוק אם קיימים תרחישים של הפעלה מחדש
במקרים מסוימים, כגון בעת הוספת חשבון שני בזמן ש- Outlook פועל, תוכן המנה של הגילוי האוטומטי מאוחסן במטמון לקובץ מקומי שבו יש להשתמש במהלך הפעלה מחדש של לקוח Outlook. השלב הראשון של גילוי אוטומטי הוא לבדוק ברישום מידע "אתחול" מיוחד שמסביר ל- Outlook שאתה נמצא באמצע אחד מתרחישי הפעלה מחדש אלה ולקרוא את תוכן המנה של הגילוי האוטומטי מהקובץ המקומי המיוחד. זהו מקרה נדיר ובדרך כלל לא הגורם לבעיות כלליות בגילוי אוטומטי. עבור שלב זה, אם Outlook מחליט שאתה נמצא בתרחיש אתחול מיוחד זה והניסיון לאחזר את נתוני ה- XML של הגילוי האוטומטי נכשל, ניסיון הגילוי האוטומטי כולו נכשל. לא נעשה ניסיון לבצע שלבים נוספים.
אין בקרת מדיניות ספציפית עבור שלב זה.
שלב 2: בדוק אם יש העדפה של נתונים מקומיים
Outlook מספק GPO כדי לאפשר למנהלי מערכת לפרוס קובץ XML ספציפי של גילוי אוטומטי לשימוש עבור קביעת תצורה. אם מנהל המערכת פרוס ערך רישום זה ופרס קובץ autodiscover.xml, Outlook מקריא את תוכן המנה של הגילוי האוטומטי מקובץ זה. זהו שוב מקרה לא נפוץ ובדרך כלל לא הגורם לבעיות גילוי אוטומטי כלליות. אם שלב זה אינו מאחזר תוכן מנה, Outlook עובר לשלב 3.
לקבלת מידע נוסף אודות XML של גילוי אוטומטי, עיין במאמר TechNet הבא: תכנון קביעת תצורה אוטומטית של חשבונות משתמשים ב- Outlook 2010
הערה מאמר זה נוצר עבור Outlook 2010. עם זאת, היא עדיין רלוונטית עבור גירסאות מאוחרות יותר של Outlook.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: PreferLocalXML.
שלב 3: בדוק אם קיימים נתונים לגבי 'הטוב האחרון הידוע' (LKG)
כאשר 'גילוי אוטומטי' מאחזר מנה של XML בהצלחה באמצעות כל שלב, ייתכן שמטען המנה מאוחסן במטמון באופן מקומי כתצורה "האחרונה שהיתה ידועה כתצורות". השיטה הראשונה בדרך כלל הצליחה לקבל תוכן מנה של גילוי אוטומטי היא מקובץ טוב זה הידוע האחרון. הנתיב של קובץ ה- XML הטוב הידוע האחרון מגיע מפרופיל Outlook. השלב LKG משמש רק לגילוי תצורת תיבת הדואר הראשית. אם בדיקת המידע של הגילוי האוטומטי מיועדת לתיבת דואר שאינה ראשית (לסירוגין, לנציג, לתיקיה ציבורית, לתיבת דואר של קבוצה וכן הלאה), המערכת מדלגת באופן אוטומטי על השלב LKG. אם שלב זה אינו מאחזר תוכן מנה, Outlook עובר לשלב 4.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: ExcludeLastKnownGoodURL.
שלב 4: בדוק אם O365 נמצא בעדיפות
Outlook משתמש בערכת פריטים הטוריסטיים כדי לקבוע אם חשבון המשתמש שסופק מגיע Office 365. אם Outlook קובע בבטחה שאתה משתמש O365, נעשה ניסיון לאחזר את תוכן המנה של הגילוי האוטומטי מ נקודות הקצה הידועות של O365 (בדרך כלל https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml או https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). אם שלב זה אינו מאחזר תוכן מנה, Outlook עובר לשלב 5.
ערך בקרת המדיניות עבור שלב זה הוא כדלהלן:
ExcludeExplicitO365Endpoint.
שיקול ITAR
כברירת מחדל, Outlook בשאילתות נקודת הקצה מוכרת כדי לאחזר את תוכן המנה של גילוי אוטומטי. המדיניות הקיימת לעקיפת שלב זה עדיין חוקית ובאפשרותך להשתמש בה כדי לעבור לשלב 5 מבלי לנסות את נקודת הקצה. לחלופין, קיימת מדיניות חדשה שמפנה את Outlook לבצע שאילתה על שירות קביעת תצורה של Office 365 כדי לאחזר כתובות URL מתאימות שממנה יש לאחזר את תוכן המנה של הגילוי האוטומטי. באופן מושגי, התהליך פועל באופן הבא:
- אתה מגדיר את המדיניות החדשה.
- במהלך שלב 4 של תהליך הגילוי האוטומטי, Outlook בשאילתות השירות Office 365 Config.
- השירות קובע אילו צרכי ITAR מיוחדים (אם קיימים) נמצאים בתוקף עבור המשתמש שצוין, ומחזיר את כתובות ה- URL המתאימות עבור משתמש זה באמצעות פרטי התחום של ה- UPN.
- Outlook מנסה לאחזר את תוכן המנה של הגילוי האוטומטי מכתובות ה- URL שסופקו על-ידי השירות.
ערך בקרת המדיניות עבור התכונה החדשה לשימוש בשירות קביעת התצורה Office 365 EnableOffice365ConfigService.
הערה
החל מ- Build מס' 16.0.9327.1000, מדיניות EnableOffice365ConfigService אינה נמצאת עוד בשימוש.
שלב 5: בדוק אם קיימים נתוני SCP
אם המחשב מצורף לתחום, Outlook מבצע שאילתת LDAP כדי לאחזר נתונים של נקודת חיבור שירות שמחזירה נתיב של ה- XML של גילוי אוטומטי. לאחר מכן נעשה ניסיון לכל כתובת URL המוחזרת על-ידי בדיקת המידע של SCP כדי לנסות לאחזר את תוכן המנה של הגילוי האוטומטי. אם שלב זה אינו מאחזר תוכן מנה, Outlook עובר לשלב 6.
לקבלת מידע נוסף אודות SCP, עיין במאמר MSDN הבא: פרסום עם נקודות חיבור לשירות.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: ExcludeScpLookup.
שלב 6: בדיקת תחום הבסיס
עבור שלב זה, Outlook בונה כתובת URL משם התחום של הכתובת ההתחלתית בתבנית של https://< domain>/autodiscover/autodiscover.xml ומנסה לאחזר את תוכן המנה מכתובת ה- URL המתבצעת. מאחר שתצורת תחומי בסיס רבים לא נקבעה עבור גילוי אוטומטי, Outlook משתיק בכוונה את שגיאות האישור המתרחשות במהלך הניסיון לאחזור. אם שלב זה אינו מאחזר תוכן מנה, Outlook עובר לשלב 7.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: ExcludeHttpsRootDomain.
שלב 7: בדוק את תחום הגילוי האוטומטי
עבור שלב זה, Outlook בונה כתובת URL משם התחום של הכתובת ההתחלתית בתבנית https://autodiscover.<domain>/autodiscover/autodiscover.xml ומנסה לאחזר את תוכן המנה מכתובת ה- URL המתבצעת. מאחר שכתובת ה- URL הראשית היא בדרך כלל עבור נתוני גילוי אוטומטי, Outlook אינו משתיק שגיאות אישור המתרחשות במהלך הניסיון לאחזור. אם שלב זה אינו מאחזר תוכן מנה, Outlook עובר לשלב 8.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: ExcludeHttpsAutoDiscoverDomain.
שלב 8: בדוק אם קיימים נתונים מקומיים
בשלב 2, Outlook בדק אם מנהל המערכת פרוס מדיניות כדי לבדוק באופן ספציפי את תוכן המנה של הגילוי האוטומטי כהעדפה. אם לא קיימת מדיניות, אך השלבים הקודמים לא אחזרו תוכן מנה, Outlook מנסה כעת לאחזר תוכן מנה מהקובץ המקומי גם ללא ההגדרה PreferLocalXML במקומה. אם שלב זה אינו מאחזר תוכן מנה, Outlook עובר לשלב 9.
אין בקרת מדיניות עבור שלב זה.
שלב 9: בדוק אם קיימים ניתובים מחדש של HTTP
עבור שלב זה, Outlook שולח בקשה אל כתובת ה- URL של תחום הגילוי האוטומטי (http://autodiscover.<domain>/autodiscover/autodiscover.xml) ובדוק אם יש תגובות לניתוב מחדש. אם מוחזר תוכן מנה בפועל של XML של גילוי אוטומטי ולא מניתוב מחדש, Outlook מתעלם מתשובת ה- XML בפועל של גילוי אוטומטי מאחר שהוא אוחזר ללא אבטחה (http). אם התגובה היא כתובת URL חוקית של ניתוב מחדש, Outlook עוקב אחר הניתוב מחדש ומנסה לאחזר XML של תוכן מנה מכתובת ה- URL החדשה. Outlook יבצע גם בדיקות אישור כדי למנוע ניתוב מחדש לכתובות URL שעלולות להיות מזיקות בשלב זה. אם שלב זה אינו מאחזר תוכן מנה, Outlook עובר לשלב 10.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: ExcludeHttpRedirect.
שלב 10: בדוק אם קיימים נתוני SRV
עבור שלב זה, Outlook יוצר שאילתת DNS עבור "_autodiscover._tcp.<domain name>" ו- loops through the results looking for the first record that uses https as its protocol. לאחר מכן, Outlook מנסה לאחזר את תוכן המנה מכתובת URL זו. אם שלב זה אינו מאחזר תוכן מנה, Outlook עובר לשלב 11.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: ExcludeSrvRecord.
שלב 11: בדוק אם O365 נכשל
אם כל השלבים הקודמים לא החזירו תוכן מנה, Outlook משתמש בקבוצה פחות מגבילה של מידע כללי כדי להחליט אם ניסיון סופי ל נקודות הקצה של O365 עשוי להיות שימושי. אם outlook מחליט שניסיון כדאי, הוא ינסה את נקודות הקצה הידועות של גילוי אוטומטי של O365 למקרה שהחשבון הוא חשבון O365. ניסיון זה משתמש באותן כתובות URL המשמשות כיעד כמו שלב 4, והוא שונה רק מהעובדה שהוא ניסה כמו מוצא אחרון ולא מוקדם יותר בתהליך הגילוי האוטומטי.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: ExcludeExplicitO365Endpoint.
שיקולי ITAR
אם Outlook יגיע לשלב זה ולא אחזר בהצלחה תוכן מנה של גילוי אוטומטי, יתבצעו שתי בדיקות כדי לראות אם יש לנסות את נקודות הקצה Office 365 ידועות. תחילה, אם תיבת הדואר היא חשבון צרכן (לדוגמה outlook.com), נעשה ניסיון להשתמש ב נקודת הקצה מוכרת. שנית, אם תיבת הדואר נקבעת להשתייך לתחום שאינו כולל דרישות ITAR, נעשה ניסיון להשתמש ב נקודת הקצה מוכרת. אם תיבת הדואר נקבעת כמסחרית והיא שייכת לתחום בעל דרישות ITAR, לא נעשה ניסיון להשתמש ב Office 365 נקודות הקצה הידועות. למהדורות עתידיות, שלב 11 עשוי לעבור לאותה לוגיקה של שלב 4 ולבצע קריאה לשירות Office 365 Config. לאחר ביצוע שינוי זה, מאמר זה יתעדכן כדי לשקף את שלב התהליך החדש.
טיפול מחדש בשלב 9 במקטע 'תהליך גילוי אוטומטי' הוא שלב מפורש לטיפול בנתונים של ניתוב מחדש לא מאובטח. בכל אחד מהפעולות המאובטחות האחרות, עבור כל ניסיון לאחזר את תוכן המנה של XML של גילוי אוטומטי, תגובה אפשרית אחת מ נקודת הקצה היא תגובת ניתוב מחדש. תגובה זו מורה ל- Outlook לנתב מחדש לכתובת URL חדשה וש אחרת כדי לנסות לאחזר את תוכן המנה. בנוסף, נתוני הניתוב מחדש עשויים להכיל כתובת דואר אלקטרוני חדשה ושונות שתשתמש בה ככתובת היעד עבור ניסיון הגילוי האוטומטי. Outlook מחשיב שלוש תגובות נפרדות כ"תגובות לניתוב מחדש":
- קוד מצב HTTP (301, 302) עם כתובת URL חדשה
- קוד מצב HTTP של 200, אך עם XML של תוכן מנה שמסביר ל- Outlook לנתב מחדש לכתובת URL אחרת
- קוד מצב HTTP של 200, אך עם XML של תוכן מנה שמסביר ל- Outlook להשתמש בכתובת smtp אחרת ככתובת היעד.
במקרים 1 ו- 2, Outlook מנסה לאחזר את ה- XML של הגילוי האוטומטי מכתובת ה- URL החדשה, בתנאי שהפרוטוקול הוא https. כתובות URL לא מאובטחות (http) אינן ניסיון. בנוסף, גם אם הפרוטוקול בכתובת ה- URL החדשה הוא https, Outlook יבדוק את פרטי האישור כדי לספק מידה נוספת של אבטחה.
במקרה 3, Outlook מתחיל את תהליך הגילוי האוטומטי כולו מההתחלה. אם כל השלבים (1-11) ניסו ללא הצלחה באמצעות כתובת הדואר האלקטרוני החדשה, Outlook חוזר אל כתובת הדואר האלקטרוני המקורית, עובר לשלב 5 וממשיך לנסות לאחזר תוכן מנה של XML עם הכתובת המקורית.
חריגים השלבים במקטע תהליך גילוי אוטומטי הם הכללים הכלליים עבור האופן שבו Outlook מנסה להשיג את תוכן המנה של הגילוי האוטומטי. קיימים מיטובים שונים וניסיונות יוצאי דופן שעשויים לשנות את התהליך מעט. לדוגמה, בעת ביצוע יצירת חשבון חדש, Outlook מדלג באופן פנימי על שלב 3 (בדיקה אם קיימים נתונים של 'תקינות ידועה אחרונה' (LKG), מאחר שעדיין לא ניתן לכלול ערך טוב ידוע אחרון. באופן דומה, אם בוצע ניסיון כתוצאה משגיאה באמצעות פרטי התצורה הנוכחיים, Outlook מעוניין באופן בכוונה לגילוי אוטומטי שוב ולא להשתמש במידע ה- LKG מאחר שהמידע הטוב הידוע האחרון הביא לכשל.
בקרת מדיניות ערכי המדיניות המוגדרים במקטע תהליך גילוי אוטומטי יכולים להיות ערכי רישום מבוססי מדיניות או ערכים שאינם מבוססי מדיניות. כאשר הם נפרסים באמצעות GPO, או קביעת תצורה ידנית של מפתח המדיניות, ההגדרות מקבלות עדיפות על-פני המפתח שאינו מדיניות.
מפתח שאינו מדיניות: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
מפתח מדיניות: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover
כל ערך הוא מסוג DWORD.
ה- PreferLocalXML שונה מערכים אחרים של פקדים, מפני שהגדרה של 1 מגדירה את Outlook להפעיל שלב זה בתהליך. עבור הערכים הנותרים, הגדרה של 1 מורה ל- outlook לבטל או לדלג על השלב המשויך. לדוגמה, הגדרת הערך ExcludeHttpsRootDomain ל - 1 מגדירה את Outlook לא לבצע את שלב 6 בתהליך.
פקדי רישום נוספים
Outlook מספק כמה אפשרויות תצורה נוספות המבוססות על רישום שעשויות להשפיע על תהליך הגילוי האוטומטי:
שימוש בשירות Office 365 Config
מפתח: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
ערך: EnableOffice365ConfigService
ברירת מחדל: 0
Data: Set this DWORD data to 1 to force Outlook to call the Office 365 Config Service to retrieve appropriate Autodiscover URL.
הגדרות זמן קצוב של HTTP
מפתח: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
ערך: זמן קצוב
ברירת מחדל: 25 שניות
מינימום: 10 שניות
מקסימום: 120 שניות
מידע: הזמן הקצוב שצוין משמש כהגדרות WinHttpSetTimeouts . הנתונים שצוינו מועברים לכל ארבעת הפרמטרים של ה- API של WinHttpSetTimeouts. הדבר מאפשר לבקשת HTTP שאינה יכולה להגיע לזמן קצוב מהיר יותר, דבר שישפר את הביצועים הכוללים. ההגדרות עשויים גם לאפשר לבקשת HTTP שעולה על ברירת המחדל של 25 שניות להצליח על-ידי הגדלת הגדרת הזמן קצוב למשהו גדול יותר מ- 25 שניות.
Mapi/Http Protocol Control
מפתח: HKEY_CURRENT_USER\Software\Microsoft\Exchange
ערך: MapiHttpDisabled
ברירת מחדל: 0
Data: 1 = Protocol is Disabled; 0 = הפרוטוקול זמין
מידע: ערך זה אינו ממוקם תחת מפתח הגילוי האוטומטי. זוהי הגדרה כללית הקובעת אם Outlook יכול לנסות להתחבר ל- Exchange באמצעות ערימת הפרוטוקול Mapi/Http. ברירת המחדל Outlook 2016 אינה הפכה פרוטוקול זה ללא זמין. הדבר מאפשר לתהליך הגילוי האוטומטי להוסיף כותרת מיוחדת (X-MapiHttpCapability:1) לתהליך הגילוי כך שניתן יהיה להעריך ולעבד את הגדרות פרוטוקול Mapi/Http.
בקרת משא ומתן של אימות מדור קודם
מפתח: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC
ערך: AllowNegoCapabilityHeader
ברירת מחדל: 0
נתונים: 1 = כותרות נוספות; 0 = כותרות עליונות אינן נוספות
מידע: שים לב שערך זה אינו נמצא תחת מפתח הגילוי האוטומטי. הגדרה זו קובעת אם תתווסף כותרת משא ומתן של אימות לבקשות http. תוכן הכותרת תלוי ביכולות האימות של מחשב הלקוח. כותרת לדוגמה עשויה להיות: "X-Nego-Capability: Negotiate, pku2u, Kerberos, NTLM, MSOIDSSP". ערך רישום זה והכותרת שהוא מוסיף נמצאים בשימוש נדיר בכל ערימת אימות מודרנית, ו סביר מאוד שלא ישפיעו על תהליך tAodiscover בדרך שלילית או חיובית.
טיפול בשגיאות אישור
מפתח: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
ערך: ShowCertErrors
ברירת מחדל: 0
Data: 1 = Show certificate warnings/errors; 0 = אל תציג אזהרות אישור
מידע: ערך זה קובע כיצד Outlook מטפל בשגיאות אישור ובאזהרות שמתקבלות בעת ביצוע משימות http. Outlook עשוי לעקוף הגדרה זו במקרים מסוימים (שלב 6 במקטע תהליך גילוי אוטומטי), אך במקרה הכללי, אם הגדרה זו זמינה, Outlook יציג בקשה לתיבת דו-שיח של אבטחה המציגה את השגיאה או האזהרה של האישור ותאפשר למשתמש אישור או ביטול בקשת Http. קיימות שלוש שגיאות אישור ספציפיות שהמשתמש יכול להחליט להתעלם מהן ובקש מ- Outlook לנסות שוב את בקשת http:
WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID – קיימת בעיה בתאריך בממאפיינים של האישור
WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID – קיימת בעיה בשם הנפוץ בממאפיינים של האישור
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA – קיימת בעיה עם רשות האישורים בממאפיינים של האישור
ניתן למצוא מידע נוסף אודות שלושת מצבים אלה של שגיאות אישור WINHTTP_STATUS_CALLBACK חזרה
טיפול באימות Proxy
מפתח: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
ערך: AllowOutlookHttpProxyAuthentication
ברירת מחדל: 0
Data: 1 = Allow Outlook to handle authentication challenges from proxy servers; 0 = כשל שקט של אתגרים באימות משרתי Proxy
מידע: ערך רישום זה מאפשר התרגעות של תצורת אבטחה ומכוסה בפירוט במאמר הבא ב- Microsoft Knowledge Base:
3115474 MS16-099: תיאור של עדכון האבטחה עבור Outlook 2010: 9 באוגוסט 2016
גילוי אוטומטי עבור פרוטוקולים אחרים
גילוי אוטומטי כתכונה משמש גם את Outlook כדי לגלות ולהגדיר חשבונות Exchange ActiveSync (EAS). תהליך הגילוי האוטומטי וקבלת ההחלטות של EAS נפרדים מהפעולות המתוארות במאמר זה. לדוגמה, יישום EAS אינו מיישם את לוגיקת נקודת הקצה של O365, והוא אינו כולל שלב שבודקות מיקומי SCP. מאמר זה מסוכם לתיאור השלבים המפורטים בהם Outlook משתמש עבור גילוי אוטומטי מנסה להשיג את הפרוטוקולים מבוססי MAPI מ- Exchange.
חומרי עזר
ניתן למצוא מידע מדור קודם אודות גילוי אוטומטי במאמר הבא ב- Microsoft Knowledge Base:
2212902 פעולה בלתי צפויה של גילוי אוטומטי כאשר יש לך הגדרות רישום תחת המפתח \Autodiscover
לקבלת מידע נוסף אודות גילוי אוטומטי, עיין במאמרים הבאים של Microsoft: