การปรับใช้แบบไฮบริดใน Office 365 | รายการตรวจสอบและข้อกำหนดเบื้องต้น | ส่วนที่ 2/3

บทความต่อไปนี้เป็นส่วนที่ 2 ของชุดรายการตรวจสอบการกำหนดค่าไฮบริดและบทความข้อกำหนดเบื้องต้น ในบทความต่อไปนี้ เราจะตรวจสอบ "ส่วนประกอบ" เพิ่มเติมที่เกี่ยวข้องและเกี่ยวข้องกับสภาพแวดล้อมแบบไฮบริด:

• บริการ EWS เซิร์ฟเวอร์ Exchange ภายในองค์กร
• บริการการค้นหาอัตโนมัติของเซิร์ฟเวอร์ Exchange ภายในองค์กร
• เซิร์ฟเวอร์ Exchange ภายในองค์กรและใบรับรองสาธารณะ

การปรับใช้ Office 365 แบบไฮบริด - ชุดบทความ

ชุดบทความประกอบด้วยบทความต่อไปนี้:

• การปรับใช้แบบไฮบริดใน Office 365 | รายการตรวจสอบและข้อกำหนดเบื้องต้น | ส่วนที่ 1/3
• การปรับใช้แบบไฮบริดใน Office 365 | รายการตรวจสอบและข้อกำหนดเบื้องต้น | ส่วนที่ 2/3
• การปรับใช้แบบไฮบริดใน Office 365 | รายการตรวจสอบและข้อกำหนดเบื้องต้น | ส่วนที่ 3/3

7. แลกเปลี่ยนเซิร์ฟเวอร์ไฮบริดในสถานที่ | บริการค้นหาอัตโนมัติ

บริการการค้นหาอัตโนมัติทำหน้าที่เป็น "รากฐาน" สำหรับ "ความสัมพันธ์แบบไฮบริด" ระหว่าง Exchange On-Premise และ Exchange Online และในทางกลับกัน

บริการค้นหาอัตโนมัติจะถูกใช้สำหรับการกำหนดค่าครั้งแรกของสภาพแวดล้อมแบบไฮบริด (เมื่อใช้ HCW) และสำหรับการสื่อสารอย่างต่อเนื่องระหว่างภายในองค์กรและสภาพแวดล้อมระบบคลาวด์
ด้วยเหตุนี้ จึงจำเป็นอย่างยิ่งที่จะต้องตรวจสอบและตรวจสอบ ส่วนต่อไปนี้ที่เกี่ยวข้องกับบริการการค้นหาอัตโนมัติ:

1. บันทึกการค้นหาอัตโนมัติและเครือข่ายสาธารณะ

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

ตัวอย่างเช่น บันทึก Autodiscover สำหรับโดเมนสาธารณะ o365info.com คือ: Autodiscover.o365info.com

เราจะต้องตรวจสอบและตรวจสอบว่าบันทึก Autodiscover ได้รับการเผยแพร่อย่างถูกต้องและบันทึก Autodiscover ชี้ไปที่เซิร์ฟเวอร์ Exchange On-Premise

ในแผนภาพต่อไปนี้ เราจะดูคำอธิบายของกระบวนการ Autodiscover ได้
ในตัวอย่างของเรา Exchange Online จำเป็นต้องรับข้อมูลเกี่ยวกับองค์กร o365info.com

ในการรับข้อมูลที่จำเป็น Exchange Online จะเข้าถึง DNS สาธารณะและสอบถามเกี่ยวกับบันทึก Autodiscover.o365info.com
ในกรณีที่บันทึก DNS ของ Autodiscover ได้รับการกำหนดค่าอย่างถูกต้อง DNS ให้ IP สาธารณะและ Exchange Online ใช้ IP นี้เพื่อติดต่อกับบริการการค้นหาอัตโนมัติในสถานที่ของ Exchange

ค้นหาระเบียน DNS อัตโนมัติ | บันทึก

ในสภาพแวดล้อมแบบไฮบริด การค้นหาอัตโนมัติควรถูกนำมาใช้เป็นระเบียน A ที่เผยแพร่ผ่านทางเซิร์ฟเวอร์ DNS สาธารณะ

ในบางสถานการณ์ การกำหนดค่าการค้นหาอัตโนมัติในสถานที่ของ Exchange จะขึ้นอยู่กับเรกคอร์ด SRV สถานการณ์นี้ไม่ได้รับการสนับสนุนในสภาพแวดล้อมแบบไฮบริด

กล่าวอีกนัยหนึ่ง: ในกรณีที่การค้นหาอัตโนมัติในสถานที่ของ Exchange ปัจจุบันอิงตามระเบียน SRV DNS คุณจะต้องเปลี่ยน/อัปเดตการกำหนดค่านี้เป็น "การกำหนดค่าการค้นหาอัตโนมัติมาตรฐาน" ที่นำไปใช้โดยใช้ระเบียน A ที่ชี้ไปยังสาธารณะ ที่อยู่ IP ของเซิร์ฟเวอร์ Exchange On-Premise

คุณจะต้องรวมบันทึกเหล่านี้ไว้ในใบรับรอง SAN ด้วย คุณสามารถใช้ระเบียน CNAME สำหรับการเปลี่ยนเส้นทางการค้นหาอัตโนมัติได้ แต่นั่นจะไม่เปลี่ยนความจริงที่ว่าคุณต้องเพิ่มระเบียนการค้นหาอัตโนมัติทั้งหมดลงในใบรับรอง SAN นอกจากนี้ การปรับใช้งานแบบไฮบริดของ Exchange ไม่สนับสนุนการเปลี่ยนเส้นทางการค้นหาอัตโนมัติที่ใช้ SRV

ตรวจสอบการดำเนินการที่ประสบความสำเร็จของกระบวนการค้นหาอัตโนมัติในองค์กรของ Exchange

ความจริงที่ว่าบันทึกบริการการค้นหาอัตโนมัติและ IP สาธารณะได้รับการเผยแพร่เป็นเพียงส่วนแรกของการตั้งค่าที่จำเป็นเท่านั้น ในขั้นตอนถัดไป เราต้องตรวจสอบว่าเราสามารถเข้าถึงบริการการค้นหาอัตโนมัติของ Exchange On-Premise + รับข้อมูลที่จำเป็น (Exchange On-Premise จะให้ข้อมูลที่จำเป็นโดยใช้ไฟล์ XML)

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

ตรวจสอบความพร้อมใช้งานของบริการการค้นหาอัตโนมัติในสถานที่ของ Exchange

การตรวจสอบบริการการค้นหาอัตโนมัติในสถานที่ของ Exchange สามารถนำไปใช้ได้โดยใช้เครื่องมือที่มีประสิทธิภาพมากและแนะนำที่ชื่อว่า Microsoft Remote Connectivity Analyzer (MRCA)

ในส่วนต่อไปนี้ เราจะตรวจสอบตัวอย่างของขั้นตอนที่จำเป็นที่เราจำเป็นต้องดำเนินการเพื่อตรวจสอบความพร้อมใช้งานของบริการ AutoDiscover ในสถานที่ของ Exchange

1. เลือกแท็บเซิร์ฟเวอร์ Exchange จากนั้นภายใต้ "การทดสอบการเชื่อมต่อ Microsoft Office Outlook" ให้เลือกตัวเลือก: การค้นหาอัตโนมัติของ Outlook

2. ระบุข้อมูลรับรองผู้ใช้ Exchange On-Premise
   เพื่อให้รับข้อมูลที่จำเป็นได้ เราจะต้องระบุข้อมูลรับรองผู้ใช้ของผู้ใช้ที่มีกล่องจดหมาย Exchange On-Premise
   ในตัวอย่างของเรา เราใช้ข้อมูลรับรองของผู้ใช้ ชื่อ: User2

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

4. ในกรณีที่เราต้องการรับข้อมูลโดยละเอียดเพิ่มเติม ให้คลิกที่ "ขั้นตอนการทดสอบ"
   ในภาพหน้าจอต่อไปนี้ เราจะเห็นเนื้อหาของไฟล์ Autodiscover XML

3. เวอร์ชันเซิร์ฟเวอร์การค้นหาอัตโนมัติและ Exchange On-Premise

ในสภาพแวดล้อม Exchange On-Premise แบบผสม ซึ่งรวมถึงเวอร์ชัน Exchange On-Premise สองเวอร์ชัน เราจะต้องตรวจสอบว่าบันทึกการค้นหาอัตโนมัตินั้น "ชี้" ไปยังเวอร์ชันเซิร์ฟเวอร์ Exchange On-Premise ที่อัปเดตล่าสุดหรือไม่

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

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

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

4. บันทึกการค้นหาอัตโนมัติที่ชี้ไปยังเซิร์ฟเวอร์ Exchange On-Premise

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

หมายเหตุ - เราไม่จำเป็นต้องกำหนดค่าหรืออัปเดตการตั้งค่าการค้นหาอัตโนมัติใดๆ ที่เกี่ยวข้องกับ “คลาวด์” เนื่องจากใน Office 365 การกำหนดค่าที่จำเป็นทั้งหมดของบริการการค้นหาอัตโนมัติได้รับการกำหนดค่าโดยอัตโนมัติโดยใช้ “โดเมนบริการ” หรือ Tenet Office 365 เช่น o365info.mail.onmicrosoft.com

8. แลกเปลี่ยนเซิร์ฟเวอร์ไฮบริดในสถานที่ | บริการอีดับบลิวเอส

สภาพแวดล้อมแบบไฮบริดจะขึ้นอยู่กับแนวคิดที่องค์กร Exchange สองแห่งที่แยกจากกันดำเนินการเป็นเอนทิตีเดียว ตัวอย่างเช่น เปิดใช้งานผู้ใช้ Exchange on-Premises เพื่อดูข้อมูลเวลาว่าง/ไม่ว่างเกี่ยวกับผู้รับ Exchange Online รับข้อความเมื่อไม่อยู่ที่สำนักงาน และอื่นๆ อีกมากมาย
โครงสร้างพื้นฐานสำหรับ "การทำงานร่วมกัน" นี้ระหว่างเซิร์ฟเวอร์ Exchange on-Premises และ Exchange Online ขึ้นอยู่กับบริการ Exchange EWS (Exchange Web Services)
ความหมายคือ:

• Exchange On-Premise จะต้องสามารถเข้าถึงได้จากเครือข่ายสาธารณะ
• ต้องกำหนดค่าบริการ EWS ของ Exchange On-Premise อย่างถูกต้อง

หมายเหตุ - การกำหนดค่าแบบไฮบริดจะขึ้นอยู่กับ "ความสัมพันธ์แบบสองทาง" ซึ่ง Exchange On-Premise จะต้องเข้าถึง Exchange Online EWS ด้วย แต่สมมติฐานพื้นฐานคือ "โครงสร้างพื้นฐานระบบคลาวด์" (Exchange Online) ได้รับการกำหนดค่าอย่างถูกต้องและ นอกเหนือจากเหตุการณ์ที่เกิดขึ้นไม่บ่อยนัก เราถือว่าฝั่งคลาวด์อนุญาตให้พร้อมใช้งานและกำหนดค่าอย่างถูกต้อง

ยืนยัน - ตรวจสอบความพร้อมใช้งานของ: บริการ EWS เซิร์ฟเวอร์ Exchange On-Premise Hybrid

เราตรวจสอบหรือยืนยันความพร้อมใช้งานของบริการ Exchange On-Premise และ EWS ได้โดยใช้ตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้:
ตัวเลือกที่ 1: ตรวจสอบ\ตรวจสอบความพร้อมใช้งานของบริการ Exchange On-Premise และ EWS โดยใช้ EWS URL
ในตัวเลือกนี้ เราสามารถลองเข้าถึง URL ของบริการเว็บ Exchange On-Premise (EWS) ได้

URL เริ่มต้นจะขึ้นอยู่กับการสนทนาการตั้งชื่อต่อไปนี้: https://ews/exchange.asmx

ในสถานการณ์ของเรา ชื่อสาธารณะของ Exchange On-Premise คือ: mail.o3655info.com
เราจะเปิดเว็บเบราว์เซอร์และใช้ที่อยู่ URL ต่อไปนี้: https://mail.o365info.com/ews/exchange.asmx

ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าเราสามารถเชื่อมต่อบริการ EWS ของ Exchange On-Premise ได้สำเร็จ
เพื่อเป็นการตอบสนอง เซิร์ฟเวอร์ Exchange on-Premises จะส่งข้อกำหนดสำหรับการตรวจสอบสิทธิ์
นอกจากนี้ เรายังเห็นว่า ใบรับรองเซิร์ฟเวอร์นั้น "เหมาะสม" เนื่องจากไอคอนล็อคไม่มีข้อผิดพลาด
ข้อมูลรับรองที่เราจะต้องระบุเป็นเพียงข้อมูลรับรองผู้ใช้แบบธรรมดาของผู้รับที่มีกล่องจดหมายบนเซิร์ฟเวอร์ Exchange On-Premise

“คำตอบ” ของ Exchange On-Premise คือไฟล์ XML ที่มีข้อมูลหรือคำอธิบายที่จำเป็นเกี่ยวกับ Exchange On-Premise Web Services

ไม่มีความหมายที่แท้จริงสำหรับเรา ความหมายเดียวคือเราสามารถเข้าถึงบริการ Exchange On-Premise EWS และรับการตอบสนองของเซิร์ฟเวอร์ Exchange

ตัวเลือกที่ 2: ตรวจสอบ/ตรวจสอบความพร้อมใช้งานของบริการ Exchange On-Premise และ EWS โดยใช้ Microsoft Remote Connectivity Analyzer

การตรวจสอบบริการ EWS ภายในองค์กรของ Exchange สามารถใช้งานได้โดยใช้เครื่องมือที่มีประสิทธิภาพและแนะนำซึ่งมีชื่อว่า Microsoft Remote Connectivity Analyzer (MRCA)

ในภาพหน้าจอต่อไปนี้ เราจะดูตัวอย่างขั้นตอนที่จำเป็นที่เราจำเป็นต้องดำเนินการเพื่อตรวจสอบความพร้อมใช้งานของบริการ Exchange On-Premise EWS

1. เลือกแท็บ Exchange server จากนั้นภายใต้ “การทดสอบการเชื่อมต่อ Microsoft Exchange Web Services” ให้เลือกตัวเลือก : การซิงโครไนซ์ การแจ้งเตือน ความพร้อมใช้งาน และการตอบกลับอัตโนมัติ

2. ระบุข้อมูลรับรองผู้ใช้ Exchange On-Premise
เพื่อให้สามารถรับข้อมูลที่จำเป็นได้ เราจะต้องระบุข้อมูลรับรองผู้ใช้ของผู้ใช้ที่มีกล่องจดหมาย Exchange On-Premise
ในตัวอย่างของเรา เราใช้ข้อมูลรับรองของ ผู้ใช้ชื่อ: User2

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

การทดสอบบริการเว็บ Exchange On-Premise จะรวมข้อผิดพลาดเล็กน้อยบางอย่างที่เกิดจากกลไก "การทดลองและข้อผิดพลาด" ของกระบวนการค้นหาอัตโนมัติโดยค่าเริ่มต้น

การที่เราได้รับ “ไอคอนสีเขียว” เป็นการบ่งชี้ถึงการนำกระบวนการบริการเว็บ Exchange On-Premise ไปใช้อย่างประสบความสำเร็จ

4. ในกรณีที่เราต้องการรับข้อมูลโดยละเอียดเพิ่มเติม เราสามารถคลิกที่ “ขั้นตอนการทดสอบ“
ในภาพหน้าจอต่อไปนี้ เราจะเห็นเนื้อหา ของไฟล์ AutoDiscover XML

9. แลกเปลี่ยนเซิร์ฟเวอร์ไฮบริดภายในองค์กร | ใบรับรองสาธารณะ

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

การสร้างช่องทางการสื่อสารที่ปลอดภัยที่นำไปใช้โดยใช้โปรโตคอลที่ปลอดภัย เช่น HTTPS และ SMTP\TLS และส่วนประกอบที่ใช้สำหรับการสร้างการเข้ารหัสข้อมูล ความสมบูรณ์ของข้อมูล การรับรองความถูกต้องร่วมกัน และอื่นๆ จะขึ้นอยู่กับใบรับรองสาธารณะที่ใช้ทั้งสองฝ่าย (Exchange Online และ Exchange On-Premise)

ข้อสันนิษฐานพื้นฐานคือใบรับรองสาธารณะของ Exchange Online ได้รับการกำหนดค่าอย่างถูกต้องและพร้อมใช้งาน

ในสถานการณ์ของเรา เราจะต้องตรวจสอบเรื่องของใบรับรองสาธารณะใน “ฝั่งเซิร์ฟเวอร์ Exchange On-Premise”

หมายเหตุ - เราจะไม่ลงรายละเอียดเกี่ยวกับวิธีสร้างคำขอใบรับรองเพื่อติดตั้งใบรับรองสาธารณะบน Exchange On-Premise และอื่นๆ
สมมติฐานพื้นฐานคือ Exchange On-Premise มีฉนวนของใบรับรองสาธารณะ และ เราเพียงต้องการตรวจสอบว่ามีการติดตั้งใบรับรองสาธารณะและรวมข้อมูลที่จำเป็นไว้ด้วย

ใบรับรองสาธารณะของ Exchange On-Premise จะถูกใช้เป็นส่วนหนึ่งของบริการ AutoDiscover และจริง ๆ แล้วสำหรับการเข้ารหัสของการรับส่งจดหมาย (SMTP/TLS) ระหว่าง Exchange On-Premise Server และเซิร์ฟเวอร์ Exchange Online

ในแผนภาพต่อไปนี้ เราจะเห็นตัวอย่างสำหรับ "ชื่อโฮสต์" ที่จะต้องรวมไว้ในใบรับรองสาธารณะของ Exchange On-Premise

ในสถานการณ์ของเรา ใบรับรองสาธารณะ Exchange On-Premise ควรมีชื่อของโฮสต์: Autodiacover.o3655info.com สำหรับบริการ Autodiscover และชื่อโฮสต์เพิ่มเติม - mail.o3655info.com
นี่คือชื่อโฮสต์ที่จะใช้โดยเซิร์ฟเวอร์ Exchange Online สำหรับที่อยู่เซิร์ฟเวอร์ Exchange On-Premise (สร้างช่องทางการสื่อสารที่ปลอดภัยไปยังเซิร์ฟเวอร์ Exchange On-Premise)

ประเภทใบรับรองสาธารณะ

ใบรับรองสาธารณะมีอยู่สองสามประเภท ประเภทที่พบบ่อยที่สุดคือ:
ใบรับรอง Wildcard และใบรับรอง SAN (Subject Alternative Name)
ข้อแตกต่างที่สำคัญระหว่างสองประเภทนี้คือ: ใบรับรอง Wildcard ไม่มีข้อมูลเกี่ยวกับชื่อโฮสต์เฉพาะเทียบกับ SAN ใบรับรองที่ต้องมีชื่อเฉพาะของ “โฮสต์” ที่ได้รับอนุญาตให้ใช้ใบรับรอง

ข้อกำหนดใบรับรองสาธารณะ

เพื่อให้สามารถตรวจสอบ\ยืนยันการตั้งค่าใบรับรองสาธารณะใน Exchange On-Premise ให้ใช้ Exchange MMC การกำหนดค่าเซิร์ฟเวอร์ เลือกชื่อเซิร์ฟเวอร์ไฮบริด (EX01 ในสถานการณ์ของเรา) โดยดูที่แท็บ Exchange Certificate

มีข้อกำหนดหลักสามประการที่เกี่ยวข้องกับใบรับรอง Exchange On-Premise:

1. ใบรับรองสาธารณะ

ความหมายของคำว่า "ใบรับรองสาธารณะ" คือใบรับรองที่สร้างโดย Public CA (ผู้ออกใบรับรอง)
ในภาพหน้าจอต่อไปนี้ เราใช้อินเทอร์เฟซ MMC ภายในองค์กรของ Exchange 2010 เพื่อรับข้อมูลเกี่ยวกับใบรับรองสาธารณะ< br>เราจะเห็นได้ว่าในส่วน "ลงนามด้วยตนเอง" ค่าของใบรับรองคือ: เท็จ (หมายเลข 1 ในภาพหน้าจอ)
ความหมายคือใบรับรองนี้ไม่ใช่ สร้างโดยเซิร์ฟเวอร์ Exchange On-Premise (ลงนามด้วยตนเอง แต่ถูกสร้างขึ้นโดยผู้ให้บริการใบรับรองสาธารณะแทน

2. การกำหนดใบรับรอง

ควรกำหนดใบรับรองสาธารณะให้กับบริการแลกเปลี่ยนต่อไปนี้: IIS และ SMTP (หมายเลข 2 ในภาพหน้าจอ)

3. ใบรับรองสาธารณะของ SAN

ใบรับรอง SAN (Subject Alternative Name) ประกอบด้วยชื่อของโฮสต์ที่ "อนุญาต" ให้ใช้ใบรับรอง คำว่า “หัวเรื่อง” อธิบายชื่อโฮสต์ที่สามารถนำมาใช้เป็นชื่อโฮสต์ธรรมดา เช่น SRV1 หรือ FQDN เช่น mail.o3655info.com

เมื่อเซิร์ฟเวอร์ Exchange on-Premises “นำเสนอ” ใบรับรองสาธารณะของเขาต่อ Exchange Online นั้น Exchange Online จะต้องตรวจสอบว่าชื่อเซิร์ฟเวอร์อีเมลที่กำหนดค่าใน Exchange Online ได้รับตัวเชื่อมต่อนั้นรวมอยู่ในใบรับรองสาธารณะที่เซิร์ฟเวอร์ Exchange on-Premises จัดเตรียมไว้ให้
(ในสถานการณ์ของเรา: ใบรับรองสาธารณะที่ผู้ให้บริการเซิร์ฟเวอร์ Exchange on-Premises จะต้องมีชื่อโฮสต์: mail.o3655info.com

เราขอแนะนำให้คุณระบุชื่อ DNS ที่จำเป็นทั้งหมดในใบรับรองเดียวกันโดยใช้ใบรับรอง Unified Communications ที่สนับสนุนฟิลด์ Subject Alternative Name การใช้ใบรับรอง Unified Communications ช่วยลดความซับซ้อนของการกำหนดค่าและการจัดการบริการ Autodiscover และ URL ของบริการ Exchange อย่างไรก็ตาม การใช้ใบรับรอง Unified Communications อาจเพิ่มค่าใช้จ่าย เนื่องจากใบรับรองประเภทนี้อาจมีราคาแพงกว่าใบรับรองชื่อเดียวที่คุณอาจมีอยู่แล้ว

ใบรับรอง - ใบรับรองดิจิทัลที่ใช้สำหรับการขนส่งจดหมายที่ปลอดภัยระหว่างองค์กรภายในองค์กรและองค์กร Exchange Online จะต้องได้รับการติดตั้งบนเซิร์ฟเวอร์การเข้าถึงไคลเอนต์ในสถานที่ทั้งหมด จะต้องออกจากผู้ออกใบรับรองบุคคลที่สาม (CA) จะต้องไม่ หมดอายุ และต้องได้รับมอบหมายบริการ IIS และ SMTP หากไม่เป็นไปตามข้อกำหนดใบรับรองเหล่านี้ การขนส่งอีเมลที่ปลอดภัยจากองค์กร Exchange Online ไปยังองค์กรภายในองค์กรจะทำงานไม่ถูกต้อง

อ่านเพิ่มเติม: แก้ไขปัญหาการปรับใช้แบบไฮบริด

ตรวจสอบ-ตรวจสอบเนื้อหาของใบรับรองสาธารณะของเซิร์ฟเวอร์ Exchange on-Premises

ตัวเลือกที่ 1: รับข้อมูลเกี่ยวกับใบรับรองสาธารณะโดยใช้ Exchange MMC
เพื่อให้สามารถตรวจสอบโฮสต์ที่มีชื่อซึ่งรวมอยู่ในใบรับรองสาธารณะ ให้ดับเบิลคลิกที่ใบรับรองสาธารณะและบนแท็บรายละเอียด มองหาฟิลด์ - ชื่อทางเลือกของหัวเรื่อง

ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าใบรับรองสาธารณะมีชื่อโฮสต์ที่จำเป็นทั้งหมด

ตัวเลือกที่ 2: ตรวจสอบใบรับรองสาธารณะของ Exchange On-Premise โดยเข้าถึง OWA URL
อีกตัวเลือกหนึ่งในการตรวจสอบใบรับรองสาธารณะของ Exchange On-Premise คือการเข้าถึง URL ของ Exchange On-Premise ที่ใช้สำหรับ การเข้าถึง OWA

ในสถานการณ์ของเรา OWA URL คือ: https://mail.o365info.com/owa

ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าเราใช้ URL ที่มุมขวาของแถบ URL เราจะเห็นไอคอนแม่กุญแจที่แสดงถึงความจริงที่ว่าไซต์ให้ใบรับรอง

เมื่อเราดับเบิลคลิกที่ไอคอนแม่กุญแจ เราจะสามารถดู “เนื้อหา ” ของใบรับรองสาธารณะที่เซิร์ฟเวอร์ Exchange on-Premises มอบให้

10. เซิร์ฟเวอร์ Microsoft MFG และหลักฐานกระบวนการเป็นเจ้าของ

ขั้นตอนแรกที่เราต้องการสร้างการกำหนดค่าแบบไฮบริดคือขั้นตอนที่เซิร์ฟเวอร์ Exchange On-Premise สร้างความสัมพันธ์ที่เชื่อถือได้” ด้วย Microsoft Federation Gateway (MFG)
ความสัมพันธ์ที่เชื่อถือได้นี้เรียกว่า ความน่าเชื่อถือแบบสหพันธรัฐ

หมายเหตุ - เมื่อใช้การกำหนดค่าแบบไฮบริดทั้งสองด้าน (Exchange On-Premise และ Exchange Online) จำเป็นต้อง “เชื่อถือ” MFG โครงสร้างพื้นฐานระบบคลาวด์ของ Office 365 ได้รับการตั้งค่าให้เชื่อถือเซิร์ฟเวอร์ MFG โดยอัตโนมัติ ดังนั้นข้อกำหนดเดียวคือการ "สร้าง" ความไว้วางใจใหม่ระหว่าง Exchange On-Premise และ MFG

“การสร้าง” ของความไว้วางใจของสหพันธรัฐกับเซิร์ฟเวอร์ Microsoft MFG นั้นถูกสร้างขึ้นโดยการใช้กระบวนการ “พิสูจน์ความเป็นเจ้าของ” สำหรับโดเมนสาธารณะที่เราใช้

ตัวอย่างเช่น ในกรณีที่เราต้องการกำหนดค่าการกำหนดค่าแบบไฮบริดโดยใช้ชื่อโดเมนสาธารณะ: o3655info.com เราจะต้องพิสูจน์ว่าเราเป็นเจ้าของโดเมนนี้

กระบวนการ "พิสูจน์ความเป็นเจ้าของ" นำไปใช้ในลักษณะต่อไปนี้: เมื่อใช้ HCW Exchange On-Premise จะติดต่อกับเซิร์ฟเวอร์ Microsoft MFG
เซิร์ฟเวอร์ MFG จะตอบกลับด้วย "สตริง TXT"

เราจะต้องคัดลอกสตริงข้อความนี้ ไปที่เซิร์ฟเวอร์ DNS สาธารณะของเรา เพิ่มบันทึก TXT ใหม่ที่มีค่าที่ได้รับจากเซิร์ฟเวอร์ MFG และหลังจากที่เราสร้าง "หลักฐาน" แล้วเท่านั้น เซิร์ฟเวอร์ MFG จะเข้าถึง DNS สาธารณะของเรา เซิร์ฟเวอร์กำลังมองหาสตริง TXT นี้

ในไดอะแกรมต่อไปนี้ เราจะดูคำอธิบายของโฟลว์หรือขั้นตอนที่จำเป็นสำหรับการสร้างความน่าเชื่อถือด้วยเซิร์ฟเวอร์ Microsoft MFG

เมื่อใช้ HCW (ตัวช่วยสร้างการกำหนดค่า Exchange Hybrid) สตริง TXT ที่จำเป็นซึ่งส่งจากเซิร์ฟเวอร์ MFG จะแสดงบนหน้าจอ

ในกรณีที่ไม่แสดงสตริง TXT ที่จำเป็นด้วยเหตุผลบางประการ เราสามารถใช้คำสั่ง PowerShell เพื่อแสดงสตริง TXT (การพิสูจน์โดเมน TXT)

PowerShell ที่เราใช้จะขึ้นอยู่กับไวยากรณ์ต่อไปนี้:

Get-FederatedDomainProof -DomainName "<Domain name>"

ในภาพหน้าจอต่อไปนี้ เราจะเห็นสตริงข้อความการพิสูจน์โดเมน

ตัวเลือกที่ 1: ตรวจสอบว่าบันทึก TXT ได้รับการกำหนดค่าอย่างถูกต้องใน DNS สาธารณะโดยใช้คำสั่ง Nslookup ด้วยl

ในกรณีที่เราต้องการตรวจสอบว่าบันทึก TXT (TXT Domain Proof) ได้รับการกำหนดค่าอย่างถูกต้องใน DNS สาธารณะ เราสามารถสร้างแบบสอบถามสำหรับบันทึก TXT ได้
เพื่อตรวจสอบว่าบันทึก TXT (TXT Domain Proof) ได้รับการกำหนดค่าใน Public DNS สามารถตรวจสอบข้อมูลได้โดยใช้คำสั่ง NSLOOKUP

ตัวอย่างเช่น - เราสามารถใช้เครื่องมือ NSLOOKUP เพื่อรับข้อมูลเกี่ยวกับบันทึก TXT ที่ได้รับการกำหนดค่าในโดเมน: o3655info.com
จากพรอมต์คำสั่งที่เราพิมพ์:

Nslookup
Set type=txt
ต่อไปเราจะพิมพ์ชื่อโดเมนเนมที่เราต้องการสอบถาม
o365info.com

ในภาพหน้าจอต่อไปนี้ เราจะเห็นผลลัพธ์ของคำสั่ง Nslookup

ตัวเลือกที่ 2: ตรวจสอบว่าบันทึก TXT ได้รับการกำหนดค่าอย่างถูกต้องใน DNS สาธารณะโดยใช้เครื่องมือเว็บ
มีเครื่องมือเว็บฟรีมากมายที่สามารถช่วยให้เราค้นหาเซิร์ฟเวอร์ DNS
ในส่วนต่อไปนี้ ตัวอย่าง เราจะใช้ไซต์ MxToolbox

1. เลือกเมนู เพิ่มเติม

2. เลือกตัวเลือก TXT และพิมพ์ชื่อโดเมนที่คุณต้องการค้นหา

ในตัวอย่างของเรา เราต้องการรับข้อมูลเกี่ยวกับระเบียน TXT ทั้งหมดในโดเมน o365info.com
ในภาพหน้าจอต่อไปนี้ เราจะเห็นผลลัพธ์ของข้อความค้นหา มีระเบียน TXT สองรายการภายใต้โดเมน o365info.com
หนึ่งในระเบียน TXT นี้คือสตริงข้อความที่ได้รับจากเซิร์ฟเวอร์ Microsoft MFG และอัปเดตในโดเมน o365info.com เป็นระเบียน TXT

11. ช่องทางการสื่อสารโดยตรง | แลกเปลี่ยนเซิร์ฟเวอร์ในสถานที่เป็น Exchange Online

เรื่องของการรับส่งจดหมายในการกำหนดค่าแบบไฮบริดเกี่ยวข้องกับสถานการณ์ต่างๆ ของการรับส่งจดหมายขาเข้าและการรับส่งจดหมายขาออก

ตัวอย่างเช่น -

• เมลที่ส่งจาก “โครงสร้างพื้นฐานคลาวด์” ไปยังเครือข่ายสาธารณะ
• เมลที่ส่งจาก "โครงสร้างพื้นฐานคลาวด์" ไปยังผู้รับ Exchange on-Premises
• เมลที่ส่งจาก Exchange ภายในองค์กรไปยังเครือข่ายสาธารณะ
• จดหมายที่ส่งจาก Exchange on-Premises ไปยังผู้รับ Office 365

เราจะไม่ลงรายละเอียดเกี่ยวกับสถานการณ์การรับส่งอีเมลที่มีอยู่ทั้งหมด แต่ฉันต้องการเน้นเฉพาะการรับส่งจดหมายระหว่างเซิร์ฟเวอร์ Exchange on-Premises และ Exchange Online และในทางกลับกัน

ตามที่กล่าวไว้ก่อนหน้านี้ ในการกำหนดค่าแบบไฮบริด Exchange on-Premises Server และ Exchange Online ทำหน้าที่เป็นหนึ่งหน่วยหรือหนึ่งเอนทิตี

การกำหนดค่าที่นำไปใช้โดยการสร้างเส้นทางการสื่อสารโดยตรงระหว่าง Exchange on-Premises Server และ Exchange Online ที่ยึดตามโปรโตคอล SMTP\TLS และ HTTPS

การรับส่งจดหมายทั้งหมดระหว่าง Exchange on-Premises Server และ Exchange Online จะผ่านช่องทางการสื่อสารที่ปลอดภัยนี้

ตัวอย่างเช่น ในกรณีที่กล่องจดหมายของ Bob อยู่บนเซิร์ฟเวอร์ Exchange on-Premises และ Bob ส่งจดหมายถึง Alice ว่ากล่องจดหมายของเธออยู่บนเซิร์ฟเวอร์ Exchange Online เมลจะถูก “ถ่ายโอน” โดยเซิร์ฟเวอร์ Exchange on-Premises ไปยัง Exchange Online โดยใช้ “ลิงก์การสื่อสารที่ปลอดภัยโดยตรง” ที่มีอยู่ระหว่าง Exchange on-Premises Server และ Exchange Online (“ช่องทางที่ปลอดภัย” นี้ถูกสร้างขึ้นโดย HCW - Exchange Hybrid วิซาร์ดการกำหนดค่า)

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

สถานการณ์ที่รองรับอีกสถานการณ์หนึ่งอาจเป็นสถานการณ์ที่สภาพแวดล้อม Exchange On-Premise มีเซิร์ฟเวอร์ Edge Transport ในสถานการณ์นี้ ช่องทางการสื่อสารที่ปลอดภัยโดยตรงจะถูกสร้างขึ้นโดยใช้เซิร์ฟเวอร์ Edge Transport เป็น "จุดสิ้นสุด" หรือเกตเวย์ในฝั่ง On-Premise

สถานการณ์ที่ไม่รองรับ | ใช้เซิร์ฟเวอร์ที่ไม่ใช่ Exchange เป็น "จุดสิ้นสุดภายในองค์กร"

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

ในทางเทคนิคแล้ว เราสามารถใช้สถานการณ์นี้ได้ แต่ไม่รองรับการกำหนดค่านี้ และมีโอกาสที่สมเหตุสมผล (หากไม่ใช่โอกาสที่แน่นอน) ที่คุณจะประสบปัญหาหลายประเภท

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

ไม่สามารถมีโฮสต์หรือบริการ SMTP อื่นๆ ระหว่างเซิร์ฟเวอร์ Exchange 2013 Client Access ภายในองค์กรหรือเซิร์ฟเวอร์ Exchange 2013/2010 SP3 Edge Transport และ EOP ข้อมูลที่เพิ่มลงในข้อความที่เปิดใช้งานคุณลักษณะการขนส่งแบบไฮบริดจะถูกเอาออกเมื่อผ่านเซิร์ฟเวอร์ที่ไม่ใช่ Exchange 2013 เซิร์ฟเวอร์ pre-Exchange 2010 SP3 หรือโฮสต์ SMTP

อ่านเพิ่มเติม: ตัวเลือกการขนส่งในการปรับใช้ Exchange แบบไฮบริด