סיכום
גילוי אוטומטי הוא התכונה שבה Outlook כדי להשיג מידע תצורה עבור שרתים אליו הוא מתחבר. ב- Outlook 2016 עם שרתי Exchange, גילוי אוטומטי נחשב לנקודה אחת של אמת עבור מידע תצורה ויש להגדיר אותו ולעבד אותו כראוי כדי Outlook פונקציונליות מלאה. מאמר זה מתאר את ההטמעה של גילוי אוטומטי בערוץ הנוכחי של מהדורת 'לחץ הפעל' של Outlook 2016. לקבלת מידע נוסף אודות מהדורות Office 365 לקוח, עיין באתרי האינטרנט הבאים של Microsoft:
מספרי גירסאות וגירסאות Build של מהדורות ערוץ עדכון עבור Office 365 לקוחות
מידע נוסף
תזמון גילוי אוטומטי
גילוי אוטומטי פועל בזמנים הבאים:
-
במהלך יצירת החשבון.
-
במרווחי זמן מוגדרים כדי לאסוף שינויים בכתובות URL Exchange תכונות שירות אינטרנט (OOF, Availability Service, ועוד). אם תהליך זה מצליח, ניסיון נוסף נעשה שעה אחת מאוחר יותר. אם הניסיון לא הצליח, הניסיון הבא יושלם 5 דקות מאוחר יותר. כל ניסיון יכול להיות מתנודד על-ידי עד 25 אחוזים עקב תשתית המשימות ברקע המשמשת את כל Microsoft Office היישומים.
-
בתגובה לכשלים מסוימים בקישוריות. בתרחישים שונים, כאשר ניסיון חיבור נכשל, Outlook מפעיל משימה של גילוי אוטומטי כדי לאחזר הגדרות חדשות בכל ניסיון לתקן את בעיית החיבור.
-
כאשר יישום אחר להפעיל אותו באמצעות MAPI. לקבלת מידע נוסף אודות MAPI, עיין במאמר MSDN הבא: Outlook MAPI Reference.
יעילות גילוי אוטומטי
השתמש בשם ראשי של משתמש (UPN) כדי לזרז את תהליך גילוי אוטומטי.
במחשב המצורף לתחום, Outlook צריך לדעת את UPN עבור משתמש כדי להפעיל את תהליך גילוי אוטומטי. ייתכן ש- UPN שימש לכניסה ל- Windows, במקרה Outlook גישה ישירה ל- UPN מתעודות הכניסה. אך אם משתמש משתמש משתמש ב- domain\username כדי להיכנס Windows, Outlook זהה רק עבור המשתמש. כדי לקבל את UPN, Outlook תחילה לחפש את המשתמש במדריך הכתובות. Outlook לבקש שבדיקת מידע זו תרדוף אחר הפניות. בסביבות מורכבות, הדבר עלול לגרום ליצירת קשר עם מספר רב של מחשבי DC לפני שנמצאת תוצאה. לאחר 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 משתמשת בערכה של heuristics כדי לקבוע אם חשבון המשתמש שסופק מגיע מ- 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 Config מרכזי כדי לאחזר כתובות URL מתאימות שממנה יש לאחזר את עומס המנה של גילוי אוטומטי. מושגית, התהליך פועל באופן הבא:
-
הגדר את המדיניות החדשה.
-
במהלך שלב 4 של תהליך גילוי אוטומטי, Outlook שאילתות על Office 365 Config.
-
השירות קובע אילו (אם בכלל) צרכי ITAR מיוחדים בתוקף עבור המשתמש שצוין, ומחזיר את כתובות ה- URL המתאימות עבור משתמש זה באמצעות פרטי התחום של UPN.
-
Outlook מנסה לאחזר את עומס המנה של גילוי אוטומטי מכתובות ה- URL שסופקו על-ידי השירות.
ערך בקרת המדיניות עבור התכונה החדשה לשימוש בשירות Office 365 Config הוא 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.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: אל תכלולHttpsRootDomain.
שלב 7: בדיקת תחום גילוי אוטומטי
עבור שלב זה, Outlook בונה כתובת URL משם התחום של הכתובת ההתחלתית בתבנית https://autodiscover.<domain>/autodiscover/autodiscover.xml ומנסה לאחזר את המנה מכתובת ה- URL שנוצרת. מאחר זוהי כתובת ה- URL הראשית בדרך כלל עבור נתוני גילוי אוטומטי, Outlook אינה משתיקה שגיאות אישור המתרחשות במהלך הניסיון לאחזור. אם שלב זה אינו מאחזר מנה, Outlook עובר לשלב 8.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: אל תכלולHttpsAutoDiscoverDomain.
שלב 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>" ומחפש את התוצאות בחיפוש אחר הרשומה הראשונה המשתמשת ב- https כפרוטוקול שלה. Outlook מכן מנסה לאחזר את המנה מכתובת URL זו. אם שלב זה אינו מאחזר מנה, Outlook עובר לשלב 11.
ערך בקרת המדיניות עבור שלב זה הוא כדלקמן: ExcludeSrvRecord.
שלב 11: בדוק אם O365 נכשל
אם כל השלבים הקודמים לא החזירו תוכן מנה, Outlook משתמש בערכה פחות מגבילה של heuristics כדי להחליט אם ניסיון סופי לנקודות הקצה של 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 (בדוק אם קיימים נתוני Last Known Good (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
נתונים: הגדר נתוני DWORD אלה ל- 1 כדי לכפות Outlook להתקשר לשירות Office 365 Config כדי לאחזר כתובות 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
נתונים: 1 = הפרוטוקול אינו זמין; 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: משא ומתן, pku2u, Kerberos, NTLM, MSOIDSSP". ערך רישום זה והכותרת שהוא מוסיף משמשים לעתים נדירות בכל ערימת אימות מודרנית, ו סביר מאוד שלא ישפיעו על תהליך tAodiscover באופן שלילי או חיובי.
טיפול בשגיאות אישור
מפתח: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
ערך: ShowCertErrors
ברירת מחדל: 0
נתונים: 1 = הצג אזהרות/שגיאות של אישורים; 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
נתונים: 1 = אפשר Outlook לטפל באתגרי אימות משרתי Proxy; 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:
