תקציר

מאמר זה נועד להציג את יכולות שירות ה- Directory Service Access (או בקצרה DSAccess) בעת שילובו עם שרת Exchange Server.

מבוא ל- DSAccess

כיום Exchange Server משולב ב- Active Directory בשונה מעבר (Exchange 5.5 Server לדוגמה) וזקוק ל- Active Directory (AD) למגוון רחב של פעילויות, ניתן למנות את הסיבות הבאות לצורך בגישה ל- Domain Controllers (DCs):

• קבלת גישה למידע המאוחסן ב- Configuration Partition – ה- Exchange Server שומר מידע רב ב- AD DS תחת ה- Configuration Partition דוגמת פרמטרים רבים הנוגעים ל- Mailboxes ו- Public Folders.
  
• גישה למידע המאוחסן ב- Global Catalogs (GCs) – ה- Exchange Server זקוק לגישה ל- DCs שהם גם GCs מסיבות עיקריות ביניהן ניתן להדגיש את נושא ה- Recipients. מלבד Exchange Server, גם בצד הלקוח – Outlook זקוק לגישה ל- DCs שהם GCs בכדי לקבל לדוגמה גישה ל- Address Lists כמו ה- GAL.
  
• גישה למידע המאוחסן ב- Domain – במידה ו- Exchange Server יכול לקבל את המידע הנחוץ לו מ- DC רגיל במקום לגשת ל- GC הוא יעשה זאת. פעולה אשר תגרום להפחתה משמעותית בגישה ועבודה במקביל ל- GCs.

הרכיב אשר אחראי על איתור DCs ו- GCs מתאימים לעבודה מול Exchange Server נקרא DSAccess, ה- DSAccess הוא רכיב אשר פועל תחת ה- MSExchangeSA (המוכר יותר כ- System Attendant) מקובץ DLL בשם DSAccess.dll, אל קובץ זה חוברים שני קבצי DLL נוספים: DSCMgs.dll אשר מכיל את המידע ש- DSAccess עושה בו שימוש לכתיבת Event logs ו- DSCPerf.dll מאחסן את המידע על ה- Performance object הרלוונטיים ל- DSAccess.

ה- DSAccess מאתר ומלקט עד כ- 10 שרתים שהם DC ועד כ- 10 שרתי GC ומקבץ אותם בפרופיל מסודר (DSAccess Profile). מלבד זאת, ה- DSAccess עובד במקביל ל- DC יחיד כשרת Configuration, הסיבה שנעשה שימוש בשרת DC יחיד למטרות עבודה במקביל ל- Configuration Partition היא למנוע בעיות רפליקציה (משום ש- Active Directory מתרפלק בתצורה של Multi-master).

איתור וליקוט שרתי ה- DC וה- GC נעשה תחילה ב- Site המקומי, במידה ואין שרתים שכאלו ב- Site המקומי ה- DSAccess יפנה ל- Site אחר.

רכיב ה- DSAccess משאיר חיבור פתוח בצורה קבועה לכלל השרתים אשר זמינים ב- DSAccess Profile. הסיבה לכך שהחיבור פתוח בצורה קבועה היא למנוע זמן בפנייה לבקשות לפתיחה וסגירה של חיבורי TCP ו- RPC בכל פעם שה- Exchange Server מבקש מידע.

ה- DSAccess מעביר בקשות אשר נשלחות אליו ל- DCs ו- GCs (משירותים נוספים אשר כלולים ב- Exchange Server כמו ה- DSProxy וה- Categorizer לדוגמה) בשיטת Round-robin מטעמי רצון לבצע איזון עומסים.

כמו כן, DSAccess יעיל מבחינת ביצועים משום שהוא מבצע Caching של תוצאות שאילתות LDAP שנעשו מבעוד מועד וחוסך התקשרות ותשאול LDAP מיותר מן ה- DC/GC. כברירת מחדל, Exchange Server מספק עבור DSAccess כ- 4MB לצורכי Caching (הרבה מקום בהתחשב בעובדה שמדובר על אחסון תוצאות שאילתות).

אופן בחירת השרתים ל- DSAccess

הצורה בה נבחרים DCs ו- GCs עבור ה- DSAccess מתחילה ב- DNS, שם מאתר ה- DSAccess רשומות מתאימות של שרתי DC ו- GC (באמצעות רשומות SRV – Service Locator), כמו שניתן לראות בתמונה מטה דוגמה לרשומת SRV של GC.

מלבד איתור רשומות SRV המפנות ל- DCs ו- GCs מתבצעות מספר בדיקות נוספות לקביעת אותם שרתים נבחרים:

• קישוריות – ה- DSAccess יפנה לשרתים המיועדים בפורטים המקובלים (389 ל- DCs ו- 3268 עבור GCs) ויבדוק האם הם זמינים וניתן לצור עימם קשר על-גבי פורטים אלו.
  
• סינכרון – מתבצעת בדיקה של ה- Attribute ששמו isSynchronized לערך True. ה- Attribute הנ"ל נמצא ב- RootDSE של ה- DC.
  
• בדיקת GC – ה- DSAccess יוודא האם השרת GC ע"י איתור ה- Attribute ששמו isGlobalCatalogReady כאשר ערכו יהיה True. ה- Attribute הנ"ל בדומה לקודמו שוכן אף הוא ב- RootDSE של ה- DC.
  
• בדיקות במקביל ל- Netlogon – מתבצעת בדיקה בין DSAccess ל- DCs באמצעות חיבור RPC לשירות ה- Netlogon. כאשר נוצר חיבור שכזה מתבצעות מספר בדיקות על-גבי ה- DC כמו נושא סינכרון הזמן.
  
• גרסת מערכת ההפעלה – DSAccess בוחרת אך ורק בשרתים אשר פועלים עם מערכת ההפעלה Windows 2000 SP3 ומעלה.
  
• Domain Exchange Ready – מתבצעות בדיקות שונות כמו לקבוצת ה- Exchange Enterprise Servers בעלת הרשאות מסוימות כמו כתיבת לוגים, האם ה- Administrator ביצע DomainPrep וכדומה.