แลกเปลี่ยนโครงสร้างพื้นฐานสาธารณะ | เว็บไซต์แลกเปลี่ยนสาธารณะและไม่ใช่สาธารณะ | 5#23

บทความปัจจุบันที่เกี่ยวข้องกับหัวข้อโครงสร้างพื้นฐานสาธารณะของ Exchange
เมื่อเราเกี่ยวข้องกับหัวข้อสภาพแวดล้อมการอยู่ร่วมกันของ Exchange 2013 และโฟลว์การเชื่อมต่อโปรโตคอลไคลเอนต์ ซึ่งเป็นหนึ่งในปัจจัยพื้นฐานที่สุดที่กำหนดและมีอิทธิพลต่อ “โฟลว์การเชื่อมต่อโปรโตคอลไคลเอนต์ ” คือที่ตั้งทางกายภาพของลูกค้า Exchange

พูดง่ายๆ ก็คือ ไม่ว่าไคลเอนต์ Exchange ที่อยู่เซิร์ฟเวอร์ Exchange CAS จะถือว่าเป็นไคลเอนต์ Exchange ที่อยู่บนเครือข่ายสาธารณะหรือไคลเอนต์ Exchange ที่เราพบในเครือข่ายภายใน\private องค์กร

ด้วยเหตุนี้ จึงจำเป็นอย่างยิ่งที่เราจะสามารถเข้าใจแนวคิดพื้นฐานบางอย่างและลักษณะของโครงสร้างพื้นฐานสาธารณะของ Exchange ได้ดียิ่งขึ้น

แลกเปลี่ยนโครงสร้างพื้นฐานสาธารณะ | เงื่อนไขพื้นฐาน

เริ่มต้นด้วยคำศัพท์พื้นฐานที่สุด: เซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ และไซต์ Exchange ที่เปิดเผยต่อสาธารณะ

คำว่า: “ไซต์ Exchange แบบสาธารณะ” เกี่ยวข้องกับโครงสร้างพื้นฐาน Exchange ที่ “เปิดเผย” หรือ “พร้อมใช้งาน” สำหรับไคลเอ็นต์ Exchange ที่ตั้งอยู่ในเครือข่ายสาธารณะ

ในทางเทคนิคแล้ว ไม่มีสิ่งที่เรียกว่า: "ไซต์ Exchange ที่เปิดเผยต่อสาธารณะ" เพราะในความเป็นจริง เราไม่ได้เผยแพร่ไซต์ Exchange แต่เป็น "ตัวแทน" ของไซต์แทน ซึ่งอธิบายว่าเป็นเซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ

ความรับผิดชอบของเซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ

1. รับใช้และปกป้อง

“งาน” ของเซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะคือการซ่อนและปกป้อง “โครงสร้างพื้นฐาน Exchange ภายใน” ที่ไม่ได้เปิดเผยต่อเครือข่ายสาธารณะ

<แข็งแกร่ง>2. พร็อกซีหรือการเปลี่ยนเส้นทาง

เซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะซึ่งยอมรับคำขอไคลเอ็นต์ Exchange ภายนอกจะทำการตัดสินใจที่จำเป็น โดยพิจารณาจากข้อมูลที่เขา "ดึง" จาก Active Directory เกี่ยวกับผู้ใช้ Exchange

“การตัดสินใจ” ของเซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะนั้นขึ้นอยู่กับปัจจัยสองสามประการ เช่น - ตำแหน่งของเซิร์ฟเวอร์กล่องจดหมาย Exchange ที่โฮสต์กล่องจดหมายของผู้ใช้ หาก “ไซต์ Exchange ปลายทาง” พิจารณาว่าเป็นส่วนตัว (อินทราเน็ต) หรือ “ สาธารณะ ” (ไซต์ Exchange สาธารณะ) ประเภทของไคลเอ็นต์ Exchange เป็นต้น

ขึ้นอยู่กับการถ่วงน้ำหนักของปัจจัยต่างๆ เซิร์ฟเวอร์ Exchange CAS ที่หันไปทางสาธารณะจะตัดสินใจว่าจะพร็อกซีคำขอไคลเอนต์ Exchange ภายนอกด้วยตัวเองไปยังเซิร์ฟเวอร์ Exchange ปลายทางหรือสั่งให้ไคลเอนต์ Exchange ภายนอกไปยังที่อยู่เซิร์ฟเวอร์ Exchange CAS สาธารณะอื่น ๆ หรือเซิร์ฟเวอร์สาธารณะอื่น ๆ ที่หันหน้าไปทาง เว็บไซต์แลกเปลี่ยน

<แข็งแกร่ง>3. จัดการคำขอการเชื่อมต่อของลูกค้า Exchange ที่แตกต่างกัน

เซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะจะต้องฉลาดเพียงพอและ "พูด" หลายภาษาพร้อมกันได้

ไคลเอนต์ Exchange ที่แตกต่างกันแต่ละราย “พูด” ภาษาที่แตกต่างกัน และสาธารณะที่เผชิญกับเซิร์ฟเวอร์ Exchange CAS จำเป็นต้องจดจำประเภทไคลเอนต์ Exchange เฉพาะ เช่น Outlook, ActiveSync หรือ OWA และใช้ “ภาษา” ที่จำเป็นในการสื่อสารกับไคลเอนต์ Exchange เฉพาะ

จำเป็นต้องเผยแพร่โครงสร้างพื้นฐาน Exchange หรือไม่?

ในทางเทคนิคแล้ว ไม่จำเป็นที่จะต้อง "เปิดเผย" โครงสร้างพื้นฐานหรือบริการของ Exchange สู่สภาพแวดล้อมสาธารณะ แต่ 99% ของเวลาทั้งหมด ข้อกำหนดทางธุรกิจขององค์กรกำหนดความจำเป็นในการเปิดเผยสภาพแวดล้อม Exchange บางส่วนเป็นอย่างน้อยไปยังไคลเอนต์ Exchange ที่ ตั้งอยู่บนเครือข่ายสาธารณะ

โครงสร้างพื้นฐานการแลกเปลี่ยนส่วนตัวและสาธารณะ | คำพ้องความหมายและคำตรงข้าม

“ส่วนที่สับสน” ของสภาพแวดล้อม Exchange แบบส่วนตัวและแบบสาธารณะก็คือ มีคำพ้องความหมายหลายคำที่ใช้เพื่ออธิบายโครงสร้างพื้นฐาน Exchange ที่แตกต่างกัน

ตัวอย่างเช่น คำถัดไปจะใช้เพื่ออธิบายสภาพแวดล้อม Exchange ที่พร้อมใช้งานหรือ “เปิดเผย” สำหรับไคลเอนต์ Exchange ภายนอก:

• สาธารณะที่เชื่อมต่อกับเซิร์ฟเวอร์ Exchange CAS
• เว็บไซต์แลกเปลี่ยนสาธารณะ
• เว็บไซต์ที่เชื่อมต่อกับอินเทอร์เน็ต
• อินเทอร์เน็ตหันหน้าไปทางไซต์โฆษณา
• โฟลว์การเชื่อมต่อไคลเอ็นต์ภายนอก

เราใช้รายการคำศัพท์ต่อไปนี้ เพื่ออธิบายไซต์ Exchange ที่ไม่ได้เปิดเผยต่อเครือข่ายสาธารณะ (สามารถเชื่อมต่อโดยไคลเอ็นต์ภายนอก) และพร้อมใช้งานเฉพาะกับไคลเอ็นต์ Exchange ที่เชื่อมต่อกับเครือข่ายขององค์กรส่วนตัวเท่านั้น:

• ไซต์อินทราเน็ต
• เว็บไซต์ภายใน
• ไซต์โฆษณาที่หันเข้าหาอินเทอร์เน็ต
• ไซต์ AD ที่ไม่ต้องใช้อินเทอร์เน็ต
• เว็บไซต์ที่ไม่เชื่อมต่อกับอินเทอร์เน็ต
• โฟลว์การเชื่อมต่อไคลเอนต์ภายใน
• โฟลว์การเชื่อมต่อไคลเอ็นต์ภายนอก

แนวคิดของ “ตัวแทน”

การใช้งานโครงสร้างพื้นฐานเมล Exchange สาธารณะนั้นขึ้นอยู่กับแนวคิดที่ฉันอธิบายว่า: “เซิร์ฟเวอร์ Exchange CAS ในฐานะตัวแทน”

เมื่อเราต้องการ "เปิดเผย" โครงสร้างพื้นฐานเมลของเราต่อเครือข่ายสาธารณะ\ภายนอก สมมติฐานพื้นฐานคือเราต้องการลด "การเปิดเผย" ต่อภัยคุกคามเครือข่ายสาธารณะที่เป็นไปได้ให้เหลือน้อยที่สุด

เพื่อเปิดใช้งานกลไกที่เราเปิดใช้งานไคลเอ็นต์ Exchange ภายนอกให้เข้าถึง "บริการอีเมล Exchange ภายใน" และในขณะเดียวกัน "ปกป้อง" โครงสร้างพื้นฐานอีเมล Exchange ภายในจากภัยคุกคามเครือข่ายสาธารณะที่เป็นไปได้ เราได้ "ตัดสินใจ" เซิร์ฟเวอร์ Exchange CAS โดยเฉพาะ ที่จะทำหน้าที่เป็น: เซิร์ฟเวอร์ Exchange CAS สาธารณะ

คำขอบริการอีเมลของไคลเอนต์ Exchange ภายนอกจะถูก "ชี้ไปที่" ไปยังเซิร์ฟเวอร์ Exchange CAS สาธารณะโดยเฉพาะ
เซิร์ฟเวอร์ Exchange CAS สาธารณะที่หันหน้าไปทางสาธารณะจะดำเนินการกระบวนการระบุไคลเอนต์ Exchange ภายนอกและหลังจากที่เขาสามารถตรวจสอบข้อมูลประจำตัวของ ไคลเอนต์ Exchange ภายนอก ให้บริการไคลเอนต์ Exchange ภายนอกโดยพรอกซีคำขอของเขาไปยังเซิร์ฟเวอร์ Exchange ภายในหรือในบางสถานการณ์ เปลี่ยนเส้นทางไคลเอนต์ Exchange ภายนอกไปยัง "เซิร์ฟเวอร์ Exchange อื่น ๆ "
หรือ - "ไซต์ Exchange สาธารณะอื่น ๆ "

แลกเปลี่ยนโครงสร้างพื้นฐานเมลสาธารณะ | สถานการณ์ที่หลากหลาย

คำว่า: “โครงสร้างพื้นฐานเมลสาธารณะของ Exchange ” สามารถแปลเป็นสถานการณ์ที่เป็นไปได้ได้มากมาย

ในส่วนต่อไปนี้ เราจะตรวจสอบสถานการณ์ที่เป็นไปได้สองสามประการสำหรับการใช้งาน - โครงสร้างพื้นฐานเมลสาธารณะของ Exchange

สถานการณ์ที่ 1: โครงสร้างพื้นฐานการแลกเปลี่ยนสาธารณะ | โมเดลรวมศูนย์

โครงสร้างพื้นฐาน Exchange ที่ฉันอธิบายว่าเป็น: “โมเดลแบบรวมศูนย์” ตามลักษณะดังต่อไปนี้:

องค์กรซึ่งมีไซต์หลายแห่งในที่ตั้งทางภูมิศาสตร์ที่แตกต่างกัน

ไซต์บริษัทเพียงแห่งเดียว: ไซต์นิวยอร์กที่กำหนดค่าเป็น - ไซต์ Exchange ที่เปิดเผยต่อสาธารณะ

“New York Public Facing Exchange CAS ” จะถูกตั้งค่าเป็นจุดสิ้นสุด Autodiscover สาธารณะ และจะเผยแพร่โดยใช้ชื่อโฮสต์: autodiscover.o365info.com

นอกจากนี้ “New York Public Facing Exchange CAS ” จะถูกเผยแพร่โดยใช้ชื่อโฮสต์สาธารณะ: mail.o365info.com
ชื่อสาธารณะนี้ใช้โดยไคลเอนต์ Exchange ภายนอกที่ กล่าวถึง "New York Public Facing Exchange CAS" ว่าเป็น "เซิร์ฟเวอร์อีเมล" ซึ่งจะช่วยให้พวกเขาสามารถเข้าถึงเนื้อหาในกล่องจดหมายของตนได้

ในสถานการณ์ของ: ”ลูกค้า Exchange สาธารณะ ” พนักงานของบริษัททั้งหมด จากทั่วทั้งไซต์ของบริษัท เช่น Los Angles, Madrid และ New York จะกล่าวถึงไซต์ Exchange สาธารณะ ซึ่งแสดงโดย “New York Public หันหน้าไปทาง Exchange CAS . ”

Autodiscover สาธารณะที่บันทึกไว้: autodiscover.o365info.com กำลังชี้ไปที่ "New York Public Facing Exchange CAS"

ในแผนภาพต่อไปนี้ เราจะเห็นโครงสร้างพื้นฐานหากเป็นแบบรวมศูนย์ มีเพียงไซต์เดียวเท่านั้นที่ถือว่าเป็น: “ไซต์ Exchange ที่เปิดเผยต่อสาธารณะ ” ไคลเอนต์ Exchange ภายนอกทั้งหมดจะถูก “ชี้” ไปยังไซต์ Exchange สาธารณะ หรือหากเราต้องการให้แม่นยำมากขึ้น: ไปยังเซิร์ฟเวอร์ Exchange CAS สาธารณะและเซิร์ฟเวอร์ Exchange CAS สาธารณะจะ “จัดการ” คำขอไคลเอนต์ Exchange ภายนอกโดย พรอกซีคำขอไปยังทรัพยากร Exchange ภายในที่จำเป็น

ในกรณีที่ผู้ใช้องค์กรที่อยู่ในเครือข่ายสาธารณะจำเป็นต้องเข้าถึงโครงสร้างพื้นฐานของ Exchange “เกตเวย์ ” หรือ “ประตู ” สู่โครงสร้างพื้นฐานของ Exchange คือ: ไซต์สำนักงานใหญ่ของบริษัท ซึ่งมีเซิร์ฟเวอร์ Exchange CAS ที่เปิดสู่สาธารณะ
เซิร์ฟเวอร์ Exchange CAS สาธารณะทำหน้าที่เป็น "จุดโฟกัส" สำหรับลูกค้า Exchange ที่กล่องจดหมายของตนโฮสต์บนไซต์นิวยอร์กและไซต์ที่เหลือทั้งหมดของบริษัท (ไซต์มาดริด + Los Angles)

“ไซต์บริษัทอื่นๆ (ไซต์มาดริด + ลอสแองเจลีส) ไม่มี “ความพร้อมใช้งานสาธารณะ” หรืออย่างอื่น คำไม่สามารถเข้าถึงได้โดยตรงจากไคลเอ็นต์ Exchange ภายนอก

ผู้ใช้ Exchange จากไซต์ Madrid + Los Angles (ไซต์ที่ไม่เปิดเผยต่อเครือข่ายสาธารณะ) จะเชื่อมต่อเซิร์ฟเวอร์ Exchange CAS สาธารณะในไซต์นิวยอร์ก

เมื่อ “New York Public Facing Exchange CAS” ยอมรับคำขอการเชื่อมต่อจากไคลเอนต์ Exchange ภายนอก เขาจะตัดสินใจว่า “จะทำอย่างไร” หรือ “วิธีการพร็อกซี” คำขอของไคลเอ็นต์ไปยังเซิร์ฟเวอร์ที่เหมาะสมตามสถานที่ตั้งของไคลเอนต์ Exchange เฉพาะ (เซิร์ฟเวอร์กล่องจดหมาย Exchange ที่โฮสต์กล่องจดหมายของผู้ใช้ Exchange)

สถานการณ์ที่ 2: โครงสร้างพื้นฐาน Exchange สาธารณะ | โมเดลแบบกระจาย

โมเดลที่สองสามารถอธิบายได้ว่า: "โมเดลแบบกระจาย" หรือบางครั้งเรียกว่า "โมเดลภูมิภาค" ”

"โมเดลแบบกระจาย" จะขึ้นอยู่กับแนวคิดที่แต่ละไซต์ของบริษัททางกายภาพ (หรือไซต์บริษัทเฉพาะ) นำเสนอโดยไซต์ Exchange สาธารณะโดยเฉพาะ

แนวคิดเบื้องหลังโมเดลนี้คือการปรับประสิทธิภาพและเวลาตอบสนองที่นำเสนอโดยเซิร์ฟเวอร์ Exchange CAS สาธารณะ

ไคลเอนต์ Exchange ที่เป็นของไซต์ A จะเข้าถึงเซิร์ฟเวอร์ Exchange CAS สาธารณะซึ่งเป็นตัวแทนของไซต์ A และอื่น ๆ

ในสถานการณ์นี้ องค์กรตัดสินใจที่จะ "เปิดเผย" ไซต์ Exchange มากกว่าหนึ่งไซต์
ตัวอย่างเช่น - โครงสร้างพื้นฐานสาธารณะของ Exchange จะรวมไซต์สำนักงานใหญ่ของบริษัทในสหรัฐอเมริกาและไซต์ของบริษัทเพิ่มเติมในยุโรป

โปรดทราบว่าบริษัทมีไซต์เพิ่มเติมในพื้นที่ทางภูมิศาสตร์อื่นซึ่งไม่ได้เปิดเผยต่อเครือข่ายสาธารณะ: ไซต์ Los Angles ที่อธิบายว่าเป็นไซต์ที่ไม่เชื่อมต่อกับอินเทอร์เน็ต

เพื่อให้สามารถแยกความแตกต่างระหว่างไซต์ Exchange สาธารณะสองไซต์ที่มีอยู่ แต่ละไซต์จะใช้เนมสเปซที่แตกต่างกัน

ตัวอย่างเช่น - เซิร์ฟเวอร์ Exchange CAS สาธารณะในสำนักงานใหญ่ที่เผยแพร่โดยใช้ FQDN: mail.o365info.com และเซิร์ฟเวอร์ Exchange CAS สาธารณะที่ไซต์ยุโรปจะได้รับการเผยแพร่โดย ใช้ FQDN: europe.mail.o365info.com

ผู้ใช้ Exchange ของยุโรปภายนอกจะใช้ "เนมสเปซของยุโรป" เพื่อเชื่อมต่อโครงสร้างพื้นฐานของ Exchange

ผู้ใช้ Exchange ภายนอกที่เหลือทั้งหมดจะเชื่อมต่อกับเซิร์ฟเวอร์ Exchange CAS สาธารณะในสำนักงานใหญ่

ความพร้อมใช้งานสาธารณะของเซิร์ฟเวอร์ Exchange เทียบกับเซิร์ฟเวอร์ Exchange ภายใน

แลกเปลี่ยน FQDN ภายนอกและภายในและที่อยู่ URL

อีกจุดที่ผมอยากชี้แจงก็คือที่อยู่ URL ภายนอกและภายในของ Exchange

ในส่วนก่อนหน้านี้ เราเรียนรู้เกี่ยวกับสถานการณ์สมมติที่องค์กร Exchange ยึดตามไซต์ที่เชื่อมต่อกับอินเทอร์เน็ตมากกว่าหนึ่งไซต์ และในบางสถานการณ์ เซิร์ฟเวอร์ Exchange CAS สามารถตัดสินใจเปลี่ยนเส้นทางคำขอของไคลเอนต์ Exchange ไปยัง "เซิร์ฟเวอร์ Exchange CAS อื่น ๆ" บน ไซต์แลกเปลี่ยนอื่น ๆ ตัวเลือกอื่นคือการให้ข้อมูลการค้นหาอัตโนมัติของไคลเอนต์ Exchange ซึ่งรวมถึง “ลิงก์” (ที่อยู่ URL และ FQDN) ของ “เซิร์ฟเวอร์ Exchange CAS สาธารณะอื่น ๆ”

คำถามที่ปรากฏในขณะนี้คือ: เซิร์ฟเวอร์ Exchange CAS รู้เกี่ยวกับ "เซิร์ฟเวอร์ Exchange CAS สาธารณะอื่น ๆ ได้อย่างไร"

คำตอบนั้นค่อนข้างง่าย: เซิร์ฟเวอร์ Exchange CAS ที่มี "ค่า" ในช่อง "ที่อยู่ URL ภายนอก " ซึ่งถือเป็น "เซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ"

เมื่อเรากรอกข้อมูล (ที่อยู่ URL) ในส่วนของ “URL ภายนอก” ข้อมูลนี้จะเผยแพร่ใน Active Directory และข้อมูลนี้จะพร้อมใช้งานสำหรับเซิร์ฟเวอร์ Exchange ทั้งหมด

แต่ละครั้งที่เราใช้คำเช่น: “เซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ” ความหมายคือ “การมีอยู่” ของเซิร์ฟเวอร์ Exchange CAS ซึ่งมีไดเร็กทอรีเสมือนมีคุณสมบัติ ExternalURL ที่เติมข้อมูล

เราสามารถพูดในสิ่งเดียวกันได้ใน "การปฏิเสธ": ไซต์ Exchange ที่ไม่เชื่อมต่อกับอินเทอร์เน็ตนั้นหมายถึงไซต์ Active Directory ใด ๆ ที่มีเซิร์ฟเวอร์ Exchange CAS ซึ่งไดเรกทอรีเสมือนไม่มีคุณสมบัติ ExternalURL ที่เติมข้อมูล

แลกเปลี่ยน FQDN ภายนอกและภายในและที่อยู่ URL

โครงสร้างอีกประการหนึ่งของโครงสร้างพื้นฐานสาธารณะของ Exchange คือเงื่อนไข: ที่อยู่ URL และ FQDN

การเข้าถึงไคลเอ็นต์ Exchange หรือที่อยู่ เซิร์ฟเวอร์ Exchange โดยใช้ที่อยู่ URL ที่มีชื่อโฮสต์เฉพาะ (FQDN) หรือโดยการกำหนดที่อยู่ชื่อโฮสต์เฉพาะโดยตรง

ตัวอย่างเช่น. ในแผนภาพต่อไปนี้ เราจะเห็นตัวอย่างที่อยู่ URL ของบริการเว็บ Exchange

โฮสต์ Exchange ที่ให้บริการเว็บ Exchange คือ: mail.o365info.com
เมื่อไคลเอ็นต์ Exchange ใช้ URL นี้ เขารู้ว่าเซิร์ฟเวอร์ Exchange ที่เขาควรระบุคือ : mail.o365info.com

ในสถานการณ์อื่น ไคลเอ็นต์ Exchange จะใช้ FQDN (ชื่อโฮสต์) เฉพาะที่เป็นตัวแทนของเซิร์ฟเวอร์ Exchange

ตัวอย่างเช่น ไคลเอนต์ Exchange ภายนอกที่ “เป็นของ ” เพื่อจัดระเบียบชื่อ: o365info.com จะเริ่มกระบวนการสื่อสารโดยมองหาจุดสิ้นสุดการค้นหาอัตโนมัติที่ชื่อ: autodiscover.o365info.com

อีกตัวอย่างหนึ่งอาจเป็นชื่อของชื่อปลายทาง RPC ที่ไคลเอนต์ Outlook ใช้ ในสถานการณ์ของเรา เซิร์ฟเวอร์ Exchange CAS สาธารณะที่ทำหน้าที่เป็น: RPC Endpoint สำหรับไคลเอนต์ Outlook ภายนอกชื่อ: mail.o365info.com

ข้อมูลการค้นหาอัตโนมัติที่จะให้กับ Exchange ภายนอก ไคลเอนต์ Outlook จะมีการอ้างอิงถึงชื่อโฮสต์:

FQDN ภายนอกและภายใน

ข้อสังเกตที่สำคัญอีกประการหนึ่งที่เกี่ยวข้องกับโครงสร้างพื้นฐานไคลเอ็นต์ Exchange สาธารณะคือหัวข้อของชื่อ FQDN ภายนอกและภายใน

แต่ละเซิร์ฟเวอร์ Exchange จะต้องแสดงตามชื่อโฮสต์ (FQDN)

• ชื่อ FQDN ภายใน - ชื่อโฮสต์ไคลเอนต์ Exchange สามารถอธิบายได้ว่าเป็นส่วนตัว ในกรณีนี้ ไคลเอนต์ Exchange ภายในเพียงตัวเดียวที่อยู่บนเครือข่ายบริษัทส่วนตัวจะสามารถระบุที่อยู่และเข้าถึงเซิร์ฟเวอร์ Exchange เฉพาะโดยใช้ชื่อโฮสต์ที่ระบุได้
• ชื่อ FQDN สาธารณะ - ชื่อโฮสต์ไคลเอ็นต์ Exchange สามารถอธิบายได้ว่าเป็น - สาธารณะในกรณีที่ไคลเอ็นต์ Exchange ภายนอกสามารถระบุที่อยู่และเข้าถึงเซิร์ฟเวอร์ Exchange เฉพาะได้ เพื่อให้สามารถใช้งานได้กับไคลเอนต์ Exchange ภายนอก เซิร์ฟเวอร์ Exchange ที่กำหนดค่าเป็น - เซิร์ฟเวอร์ Exchange CAS สาธารณะและชื่อโฮสต์ของเซิร์ฟเวอร์ Exchange จะต้องเผยแพร่ในเซิร์ฟเวอร์ DNS ภายนอก\สาธารณะ

ไซต์ Exchange สาธารณะหลายแห่ง

ในสถานการณ์สมมติของไซต์ Exchange สาธารณะหลายไซต์ แต่ละไซต์ Exchange สาธารณะจะต้องมีตัวแทน: เซิร์ฟเวอร์ Exchange CAS สาธารณะที่จะยอมรับคำขอการสื่อสารจากไคลเอนต์ Exchange ภายนอก

ตัวอย่างเช่น บริษัทที่มีไซต์ Exchange สาธารณะสองไซต์ ไซต์หนึ่งในนิวยอร์ก และไซต์เพิ่มเติมในมาดริด

• เซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะซึ่งเป็นตัวแทนของนิวยอร์กจะได้รับการเผยแพร่โดยชื่อโฮสต์ (FQDN): mail.o365info.com
• เซิร์ฟเวอร์ Exchange CAS สาธารณะซึ่งเป็นตัวแทนของมาดริดจะได้รับการเผยแพร่โดยชื่อโฮสต์ (FQDN): europe.mail.o365info.com