การโยกย้ายขั้นตอน โครงสร้างพื้นฐาน Exchange และ Autodiscover | ตอนที่ 1#2 | ตอนที่ 35#36

ในบทความปัจจุบัน เราจะตรวจสอบหัวข้อของการโยกย้ายขั้นของ Exchange และปัญหาของการกำหนดค่าโปรไฟล์จดหมาย Outlook ใหม่สำหรับผู้ใช้ที่กล่องจดหมายของตนโยกย้ายไปยังระบบคลาวด์

บทความปัจจุบันเกี่ยวข้องกับ "ส่วนทางทฤษฎี" ซึ่งเราจะตรวจสอบอักขระพิเศษของการย้ายขั้นของ Exchange และ "ปัญหา" ที่เราจำเป็นต้องแก้ไขเพื่อให้สามารถสร้างโปรไฟล์ Outlook ใหม่ที่จะเชื่อมต่อผู้ใช้ที่ถูกย้ายเข้ากับ กล่องจดหมาย Exchange Online ของพวกเขา

บทความถัดไปจะรวมคำอธิบายวิธีแก้ปัญหาที่แนะนำซึ่งสามารถนำไปใช้ได้

การโยกย้าย Exchange Stage และโครงสร้างพื้นฐานการค้นหาอัตโนมัติ | บทความชุด

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

• การโยกย้ายขั้นตอน โครงสร้างพื้นฐาน Exchange และ Autodiscover | ตอนที่ 1#2 | ตอนที่ 35#36
• การเชื่อมต่อผู้ใช้กับกล่องจดหมาย Exchange Online - การโยกย้ายระยะ - การไขปริศนา | ตอนที่ 2#2 | ตอนที่ 36#36

เมื่อใช้ตัวเลือกการย้ายขั้นของ Exchange “ปลายทางสุดท้าย” คือการย้ายโครงสร้างพื้นฐาน Exchange on-Premises ที่มีอยู่ทั้งหมดไปยังโครงสร้างพื้นฐาน “คลาวด์เมล” แต่กระบวนการย้ายดังที่ชื่อบอกไว้ จะถูกนำไปใช้ใน “ระยะ” .

ตัวละครหลักอย่างหนึ่งของการย้ายขั้น Exchange คือกระบวนการย้ายเมลจะดำเนินต่อไปเป็นระยะเวลานาน เช่น สัปดาห์หรือเดือน

ในช่วงเวลาข้างต้น โครงสร้างพื้นฐานเมลขององค์กรจะ "กระจัดกระจาย" ทั่วทั้งโครงสร้างพื้นฐาน Exchange on-Premises และโครงสร้างพื้นฐาน Exchange Online จนกว่าการย้ายเมลจะเสร็จสิ้น

ที่ตั้งทางกายภาพของกล่องจดหมายของผู้ใช้ | การโยกย้ายขั้นตอนการแลกเปลี่ยน

เมื่อเราใช้การโยกย้ายขั้นของ Exchange สำหรับการย้ายกล่องจดหมายของผู้ใช้ Exchange on-Premises เฉพาะ ความหมายที่แท้จริงของคำว่า “การโยกย้ายกล่องจดหมาย ” ก็คือ กล่องจดหมายของผู้ใช้คือ คัดลอกไปยังคลาวด์ (Exchange Online)

ผลลัพธ์ก็คือหลังจากการโยกย้ายของผู้ใช้รายใดรายหนึ่งเสร็จสิ้น มีกล่องจดหมายของผู้ใช้สองกล่องในเวลาเดียวกัน

• กล่องจดหมายผู้ใช้หนึ่งกล่องที่โฮสต์บนโครงสร้างพื้นฐาน Exchange on-Premises
• กล่องจดหมายของผู้ใช้หนึ่งรายที่โฮสต์บนโครงสร้างพื้นฐานของ Exchange Online

ในสถานการณ์นี้ เราต้องการ "เชื่อมต่อ" ผู้ใช้ที่กล่องจดหมายของเขาถูกย้าย (คัดลอก) ไปยัง Exchange Online และหลีกเลี่ยงการเชื่อมต่อผู้ใช้กับกล่องจดหมาย "Exchange
on-Premises ก่อนหน้า"

เมื่อเราใช้ตัวเลือกการย้าย Exchange Stage หลังจากที่เราย้ายกล่องจดหมายของผู้ใช้ไปยัง Exchange Online แล้ว เราจะต้องสร้าง โปรไฟล์เมล Outlook ใหม่ ที่จะ เชื่อมต่อผู้ใช้กับกล่องจดหมาย Exchange Online ของเขา

การสร้างโปรไฟล์เมล Outlook ใหม่ | ความจำเป็นในการเปลี่ยนเส้นทางผู้ใช้ไปยังกล่องจดหมายบนคลาวด์ของตน

ปัญหาหลักคือเมื่อเราสร้างโปรไฟล์อีเมล Outlook ใหม่ Outlook จะค้นหา Exchange on-Premises โดยอัตโนมัติและเชื่อมต่อกับ กล่องจดหมาย Exchange on-Premises

ไคลเอนต์ Outlook "ไม่รู้" ว่าเรามีสำเนากล่องจดหมายของผู้ใช้ใน "คลาวด์" (Exchange Online) และตอนนี้เขาต้องเชื่อมต่อกับ "กล่องจดหมายบนคลาวด์" ของเขา!

ความท้าทายหลักของเราคือการหาวิธีที่จะ "บอก" ไคลเอ็นต์ Outlook วิธีเชื่อมต่อกับ "กล่องจดหมาย Exchange Online ใหม่" ของเขาแทนกล่องจดหมาย Exchange on-Premises ที่มีอยู่

วิธีการ "เป็นทางการ" ในการทำงานนี้ให้สำเร็จคือการใช้กลไกในตัวของ Exchange ซึ่งจะเปลี่ยนเส้นทางไคลเอ็นต์การค้นหาอัตโนมัติไปยัง "โครงสร้างพื้นฐานระบบคลาวด์" (กล่องจดหมายของผู้ใช้ที่อยู่ที่ Exchange Online)

เพื่อให้สามารถใช้ "กลไกการเปลี่ยนเส้นทาง" ได้ เราจะต้องแปลงกล่องจดหมายของผู้ใช้ Exchange on-Premises เป็นที่อยู่ติดต่อทางเมลที่มีที่อยู่อีเมลที่ผู้รับมีในโครงสร้างพื้นฐานของ Exchange Online

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

“การทำงานอัตโนมัติ” ของกระบวนการนี้สามารถนำไปใช้ได้โดยใช้ชุดสคริปต์ PowerShell ซึ่งจะช่วยให้เราดำเนินการกระบวนการสนทนาโดยเปลี่ยนกล่องจดหมาย Exchange on-Premises ให้เป็น MEU (ผู้ใช้ที่เปิดใช้งานอีเมล)

วัตถุประสงค์ของสคริปต์ PowerShell นี้คือเพื่อ:

1. ลบกล่องจดหมาย Exchange on-Premises ของผู้ใช้ที่กล่องจดหมายของตนย้ายไปยังระบบคลาวด์
2. คัดลอกที่อยู่อีเมลของผู้รับ
3. สร้าง MEU ใหม่ (ผู้ใช้ที่เปิดใช้งานอีเมล) ซึ่งมีที่อยู่อีเมลของผู้ใช้ที่กล่องจดหมายของเขาย้ายไปยังคลาวด์ + ที่อยู่อีเมล "onmicrosoft"

หลังจากขั้นตอนนี้ยุ่งยาก เมื่อเราสร้างโปรไฟล์เมล Outlook ใหม่ Outlook จะระบุที่อยู่เซิร์ฟเวอร์ Exchange on-Premises ตามค่าเริ่มต้น แต่คราวนี้ เนื่องจาก Exchange on-Premises ไม่ได้โฮสต์กล่องจดหมายของผู้ใช้ Exchange on- สถานที่จะ "เข้าใจ" ว่าเขาจำเป็นต้องเปลี่ยนเส้นทางโปรแกรมรับส่งอีเมลไปยัง "กล่องจดหมายระบบคลาวด์" (ที่อยู่อีเมล onmicrosoft)

Exchange on-Premises จะส่งข้อความการเปลี่ยนเส้นทางไปยังไคลเอนต์ Outlook ซึ่งเป็นส่วนหนึ่งของกระบวนการค้นหาอัตโนมัติ และ Outlook จะ เริ่มต้นอีกครั้ง กระบวนการค้นหาอัตโนมัติ โดยระบุถึง โครงสร้างพื้นฐานเมล Exchange Online

ฟังดูซับซ้อนนิดหน่อยใช่ไหม?

ใช่ฉันเห็นด้วย.

จากประสบการณ์ของฉัน อุปสรรคที่ใหญ่ที่สุดในวิธีนี้ก็คือการดำเนินการ “ลบกล่องจดหมาย Exchange on-Premises ” ฟังดูไม่ “ถูกต้อง” สำหรับผู้ดูแลระบบ Exchange ส่วนใหญ่ และโดยส่วนใหญ่แล้ว ผู้ดูแลระบบ Exchange รู้สึกว่าพวกเขา จำเป็นต้องค้นหาวิธีอื่นในการทำงานให้สำเร็จ - เชื่อมต่อผู้ใช้ที่ถูกย้ายไปยังกล่องจดหมาย Exchange Online ของตน โดยไม่จำเป็นต้องลบกล่องจดหมาย Exchange on-Premises ที่มีอยู่

poppers ของบทความปัจจุบันและบทความถัดไปคือการทบทวนอักขระเฉพาะของการโยกย้ายขั้นของ Exchange ที่เกี่ยวข้องกับเรื่องของการเชื่อมต่อไคลเอ็นต์ Outlook กับกล่องจดหมาย Exchange Online โดยใช้วิธีที่ "ข้าม" "วิธีการอย่างเป็นทางการ" ที่เรา จำเป็นต้องลบกล่องจดหมาย Exchange on-Premises ที่มีอยู่

กฎบัตรเฉพาะการย้ายขั้นตอนการแลกเปลี่ยน

ก่อนที่เราจะเริ่มต้นด้วยคำอธิบายของโซลูชันเสริมที่เราสามารถนำมาใช้ได้ - การเชื่อมต่อไคลเอนต์จดหมาย Outlook กับกล่องจดหมาย Exchange Online เมื่อใช้การโยกย้ายขั้นของ Exchange เพื่อมิให้ตรวจสอบอักขระพื้นฐานของสภาพแวดล้อมการโยกย้ายขั้นของ Exchange:

1. คัดลอกแทนการย้าย
บิวด์การโยกย้ายขั้น Exchange ตามแนวคิด ซึ่งกล่องจดหมายของผู้ใช้คัดลอกจากเซิร์ฟเวอร์ Exchange on-Premises ไปยังเซิร์ฟเวอร์ Exchange Online ความหมายก็คือ ในทางเทคนิคแล้ว ผู้ใช้แต่ละคนที่เข้าร่วมในกระบวนการย้ายข้อมูลจะมีกล่องจดหมายสองกล่อง

กล่องจดหมายหนึ่งกล่องที่โฮสต์บนเซิร์ฟเวอร์ Exchange on-Premises และกล่องจดหมายเพิ่มเติมที่โฮสต์บนเซิร์ฟเวอร์ Exchange Online

<แข็งแกร่ง>2. ค้นหา “ตัวชี้” อัตโนมัติ
เมื่อดำเนินการย้ายข้อมูลตามขั้นตอนของ Exchange เราจะไม่อัปเดตโครงสร้างพื้นฐาน DNS ที่มีอยู่

โครงสร้างพื้นฐาน Exchange on-Premises ยังคงให้บริการไคลเอ็นต์เซิร์ฟเวอร์ Exchange on-Premises ที่มีอยู่
ตราบใดที่การโยกย้ายขั้นตอนดำเนินต่อไป โครงสร้างพื้นฐาน Autodiscover จะยังคงชี้ไปที่โครงสร้างพื้นฐาน Exchange on-Premises

สถานการณ์จำลองการโยกย้ายสเตจ | ข้อมูลระบุตัวตนที่ซ้ำกันของผู้ใช้ที่ถูกย้าย

ในแผนภาพต่อไปนี้ เราจะเห็นว่าผู้ใช้แต่ละรายที่ย้ายไปยังระบบคลาวด์มี "double identity" + กล่องจดหมายคู่
ตัวอย่างเช่น ผู้ใช้ชื่อ Alice ที่กล่องจดหมายของเธอย้ายไปยังระบบคลาวด์ มีบัญชีผู้ใช้อยู่ใน On-Premise Active Directory + ใน Windows Azure Active Directory
เกี่ยวกับโครงสร้างพื้นฐานของ Exchange นั้น Alice มีกล่องจดหมายที่โฮสต์บนเซิร์ฟเวอร์ Exchange on-Premises และในเวลาเดียวกันก็มีกล่องจดหมายเพิ่มเติมที่โฮสต์บน Exchange Online เซิร์ฟเวอร์

โครงสร้างพื้นฐาน Exchange ภายในองค์กร | โครงสร้างพื้นฐานการค้นหาอัตโนมัติเริ่มต้น

ตามที่กล่าวไว้ เมื่อเราใช้การโยกย้ายขั้น Exchange โครงสร้างพื้นฐาน Autodiscover จะยังคงเหมือนเดิม ความหมายก็คือกระบวนการค้นหาอัตโนมัติที่ดำเนินการโดยไคลเอนต์ Exchange เช่น Outlook จะ "นำ" ไคลเอนต์ Exchange ไปยังเซิร์ฟเวอร์ Exchange on-Premises

เมื่อมองแวบแรก กระบวนการนี้ดูเหมือนจะสมเหตุสมผล แต่ในการมองครั้งที่สอง เราเห็นปัญหาที่เป็นไปได้

หลังจากที่เราย้ายกล่องจดหมาย Exchange on-Premises ไปยัง Exchange Online เราจำเป็นต้องสร้างโปรไฟล์อีเมล Outlook ใหม่สำหรับผู้ใช้ที่กล่องจดหมายของเขาย้ายไปยัง Exchange Online

ในกรณีที่เราจะเริ่มกระบวนการ "โปรไฟล์เมล Outlook ใหม่" ไคลเอนต์ Outlook จะใช้กระบวนการ Autodiscover มาตรฐาน แต่ปัญหาคือกระบวนการ Autodiscover จะ "นำ" ไคลเอนต์ Autodiscover ไปยังเซิร์ฟเวอร์ Exchange on-Premises ที่มีอยู่แทน โครงสร้างพื้นฐานการแลกเปลี่ยน

ในแผนภาพต่อไปนี้ เราจะเห็นว่าผู้ใช้ชื่อ Alice ซึ่งใช้ที่อยู่อีเมล Alice@o365info.com ค้นหาเซิร์ฟเวอร์ Exchange CAS ของเธอได้อย่างไร
ในกรณีที่ Alice พยายามค้นหาตำแหน่งเซิร์ฟเวอร์ Exchange CAS ของเขาจากเครือข่ายภายใน Alice จะค้นหาเซิร์ฟเวอร์ Exchange CAS โดยใช้ Active Directory SCP ที่มีชื่อภายในของเซิร์ฟเวอร์ Exchange CAS (exo1.o365info .local ในสถานการณ์ของเรา)

ในกรณีที่ Alice พยายามค้นหาเซิร์ฟเวอร์ Exchange CAS ของเขาจากเครือข่ายภายนอก Alice จะกำหนดเซิร์ฟเวอร์ Exchange CAS โดยใช้กระบวนการค้นหาอัตโนมัติที่นำไปใช้ในสภาพแวดล้อม non-Active Directory โดยการค้นหาชื่อโฮสต์ เช่น - autodiscover.o365info.com

ในสถานการณ์ของเรา การสืบค้นชื่อโฮสต์ - autodiscover.o365info.com จะนำ Alice ไปยังเซิร์ฟเวอร์ Exchange on-Premises Public ที่เชื่อมต่อกับเซิร์ฟเวอร์ Exchange

ป้องกันไม่ให้ไคลเอ็นต์ Outlook เชื่อมต่อเซิร์ฟเวอร์ CAS ของ Exchange ในสถานที่

ส่วนหัวของส่วนนี้ดูแปลกไปหน่อย แต่นี่คือสิ่งที่เราต้องการและอยากทำจริงๆ

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

ปัญหาที่ไคลเอนต์ Outlook เชื่อมต่อ "เซิร์ฟเวอร์ Exchange ไม่ถูกต้อง" เกิดขึ้นเนื่องจากเหตุผลง่ายๆ - "ผู้ใช้ที่ย้าย" ไม่ทราบว่ากล่องจดหมายของเขาถูกย้ายไปยังระบบคลาวด์

จากมุมมองของไคลเอนต์ Autodiscover โครงสร้างพื้นฐาน Autodiscover ยังคง “ชี้เขา” ไปยังเซิร์ฟเวอร์ CAS ของ Exchange on-Premises

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

ในแผนภาพต่อไปนี้ เราจะเห็นตัวอย่างกระบวนการย้ายกล่องจดหมายเมื่อใช้ตัวเลือกการย้ายขั้น

เราจะเห็นได้ว่าหลังจากการรวบรวมการย้ายเมลสำเร็จ “กล่องจดหมายของ Alice” จะมีอยู่ในสองที่ที่แตกต่างกัน - เซิร์ฟเวอร์ Exchange on-Premises + เซิร์ฟเวอร์ Exchange Online

กลุ่มอาการกล่องจดหมายของผู้ใช้การโยกย้ายระยะ

ผู้ใช้องค์กรรายงานปรากฏการณ์ประหลาดที่เมลที่ส่งไปไม่ถึงกล่องจดหมายของเขา แต่เขาสามารถส่งอีเมลไปยังผู้รับภายนอกได้

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

กลไกของ "การส่งต่ออัตโนมัติ" จะไม่ทิ้งสำเนาของกล่องจดหมาย Exchange on-Premises ของผู้ใช้ แต่ให้ "ย้าย" ข้อความอีเมลต้นฉบับไปยังคลาวด์แทน (กล่องจดหมายของผู้ใช้ Exchange Online)

ผลลัพธ์ก็คือหลังจากการโยกย้ายกล่องจดหมาย จดหมายทุกฉบับที่ส่งถึงผู้ใช้เฉพาะจะ "อยู่ในกล่องจดหมาย Exchange Online"

ในกรณีที่เราไม่ได้ดำเนินการเตรียมการที่จำเป็น “ผู้ใช้ที่ถูกย้าย” จะยังคงเชื่อมต่อกับกล่องจดหมาย Exchange on-Premises ของเขาต่อไป

กล่องจดหมาย Exchange on-Premises นี้เป็น "กล่องจดหมายที่ถูกต้อง" และด้วยเหตุนี้ ผู้ใช้สามารถส่งอีเมลไปยังผู้รับต่อไปได้ แต่อีเมลที่จะส่งไปยังผู้ใช้จะเปลี่ยนเส้นทางไปยัง "กล่องจดหมาย Exchange Online" ของเขา ไม่ใช่ไปยัง Exchange ของเขา กล่องจดหมายในสถานที่!

โซลูชันเสริมสำหรับไคลเอนต์ Outlook ในสภาพแวดล้อมการโยกย้าย Stage

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

ตัวเลือกที่ใช้ได้สำหรับโซลูชันแบ่งออกเป็นสองประเภท - ฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์

1. การโยกย้ายสเตจ | โซลูชันฝั่งเซิร์ฟเวอร์

โซลูชันที่อธิบายว่าเป็น "ฝั่งเซิร์ฟเวอร์" ได้รับการปรับใช้โดยใช้ขั้นตอนต่อไปนี้

• การลบกล่องจดหมาย Exchange On-Premise
• สร้างผู้ใช้ที่เปิดใช้งานจดหมายใหม่ (MEU) ซึ่งรวมถึงที่อยู่อีเมลหลักของผู้ใช้ที่ถูกโยกย้ายและใน "ที่อยู่อีเมลภายนอก" ค่าจะใช้ที่อยู่อีเมลเพิ่มเติม ที่อยู่อีเมล Office 365 onmicrosoft

ฟังดูน่าสับสนเล็กน้อยใช่ไหม
ความจริงแล้วสิ่งนี้น่าสับสนจริงๆ
ดังที่กล่าวไว้ก่อนหน้านี้ เมื่อเราใช้การโยกย้ายตามขั้นตอน กล่องจดหมาย Exchange On-Premise จะถูกคัดลอกไปยังระบบคลาวด์

หลังจากที่เราตรวจสอบว่ากล่องจดหมายได้รับการโยกย้าย (คัดลอก) ไปยัง Exchange Online เรียบร้อยแล้ว ในทางเทคนิคแล้ว ไม่จำเป็นต้องมีกล่องจดหมาย Exchange On-Premise

กระบวนการโยกย้ายขั้นไม่ลบกล่องจดหมาย Exchange On-Premise โดยอัตโนมัติ

สมมติว่าหลังจากที่เราได้อ่านข้อมูลนี้แล้ว เราตัดสินใจที่จะดำเนินการตามขั้นตอนที่เราลบกล่องจดหมาย Exchange On-Premise

มีความคิดบ้างไหมว่าจะเกิดอะไรขึ้น?

ในกรณีที่เราลบกล่องจดหมายของผู้ใช้ เมื่อเราพยายามสร้างโปรไฟล์จดหมาย Outlook ใหม่ ตัวช่วยสร้างจดหมาย Outlook จะเชื่อมต่อกับเซิร์ฟเวอร์ Exchange On-Premise โดยอัตโนมัติ เนื่องจากตามที่กล่าวไว้ก่อนหน้านี้ ในขั้นตอนการย้ายข้อมูล โครงสร้างพื้นฐาน Autodiscover จะยังคง "ชี้" ไปยังโครงสร้างพื้นฐาน Exchange On-Premise

ในกรณีนี้ ไคลเอนต์ Outlook จะจัดการเพื่อเชื่อมต่อเซิร์ฟเวอร์ Exchange On-Premise แต่เนื่องจากกล่องจดหมายของผู้ใช้ถูกลบ ความพยายามในการเชื่อมต่อจึงล้มเหลว

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

ในสถานการณ์ที่เราลบเฉพาะกล่องจดหมาย Exchange On-Premise โดยไม่มีการเตรียมการเพิ่มเติม เช่น การสร้างผู้ใช้ที่เปิดใช้งาน Mail ใหม่ จะทำให้เกิดปัญหาเพิ่มเติมอีกสองประการกับการรับส่งจดหมาย เนื่องจาก Exchange On-Premise มีหน้าที่รับผิดชอบในการกำหนดเส้นทางอีเมลที่ส่งไปยัง ผู้ใช้ที่กล่องจดหมายของเขาถูกย้ายไปยัง "ที่อยู่อีเมล Office 365"

ในกรณีที่เรา "เพิ่งลบ" กล่องจดหมายของผู้ใช้ Exchange On-Premise Exchange on-Premise จะไม่รู้วิธีจัดการเมลที่จะส่งไปยังผู้ใช้รายใดรายหนึ่ง

การดำเนินการที่สองที่เราจะต้องดำเนินการคือ - การสร้างผู้ใช้ที่เปิดใช้งานอีเมล (MEU) ใหม่ ซึ่งจะทำหน้าที่เป็น “ตัวแทน” สำหรับกล่องจดหมายที่ถูกย้าย และจะมีการกำหนดค่า “ที่อยู่อีเมลของผู้รับ Office 365” เป็น - ที่อยู่อีเมลภายนอก

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

ตัวอย่างเช่น Alice เป็นผู้ใช้ที่กล่องจดหมายของเธอย้ายไปยัง Exchange Online

เมื่อ Alice เชื่อมต่อ Exchange On-Premise เนื่องจาก Alice ไม่มีกล่องจดหมายอีกต่อไป และเนื่องจาก Exchange On-Premise มีผู้ใช้ที่เปิดใช้งานอีเมล (MEU) พร้อมด้วยรายละเอียดของ Alice Exchange On-Premise จะ "เข้าใจ" ที่เขาจำเป็นต้องจัดเตรียม อลิซของเธอ “ที่อยู่อีเมล Office 365” ในสถานการณ์ของเรา - Alice@o365info2.onmicrosoft.com

ในกรณีที่เราได้ใช้โซลูชัน "ฝั่งเซิร์ฟเวอร์" ซึ่งเราลบกล่องจดหมายของผู้ใช้ Exchange On-Premise + สร้างผู้ใช้ที่เปิดใช้งานอีเมลด้วยที่อยู่อีเมล Office 365 สถานการณ์ต่อไปนี้จะถูกนำมาใช้:

เมื่อไคลเอนต์จดหมายภายนอกพยายามสร้างโปรไฟล์จดหมาย Outlook ใหม่ ไคลเอนต์ Outlook จะเข้าถึง Active Directory SCP ในเครื่องและรับชื่อของเซิร์ฟเวอร์ Exchange\s ที่มีอยู่ (เซิร์ฟเวอร์ Exchange ภายในองค์กร\s)

เมื่อไคลเอนต์ Outlook ระบุเซิร์ฟเวอร์ Exchange CAS ภายในเครื่อง Exchange จะ "เห็น" ว่าผู้ใช้ไม่มีกล่องจดหมาย แต่มีผู้ใช้ที่เปิดใช้งานอีเมลแทน

เซิร์ฟเวอร์ Exchange จะ "เข้าใจ" ว่าเขาจำเป็นต้องส่ง "ข้อความเปลี่ยนเส้นทาง" ไปยังไคลเอ็นต์ Outlook ที่มีที่อยู่อีเมล Office 365 (ในสถานการณ์ของเรา -
Alice@o365info2. onmicrosoft.com

ไคลเอ็นต์ Outlook เข้าใจว่าขณะนี้ เขาจะต้องเริ่มกระบวนการค้นหาอัตโนมัติทั้งหมดอีกครั้ง โดยใช้ชื่อโดเมนที่แยกมาจากที่อยู่อีเมลใหม่

ในสถานการณ์สมมติของเรา Outlook จะพยายามค้นหาโฮสต์ที่ชื่อ - o365info2.onmicrosoft.com และถ้าไม่พบชื่อโฮสต์ดังกล่าว เขาจะพยายามสอบถาม DNS สำหรับ ตามด้วยชื่อโฮสต์ - autodiscover.o365info2.onmicrosoft.com

2. การโยกย้ายสเตจ | โซลูชันฝั่ง "ลูกค้า"

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

เพื่อสาธิตสถานการณ์การย้ายขั้นมาตรฐาน ลองใช้ตัวอย่างต่อไปนี้:

โดเมนสาธารณะขององค์กรคือ - o365info.com
ผู้ใช้ชื่อ Alice ซึ่งมีที่อยู่อีเมล - Alice@o365info.com ถูกย้ายไปยังระบบคลาวด์

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

กระบวนการค้นหาอัตโนมัติภายใน

ในแผนภาพต่อไปนี้ เราจะเห็นว่า "ความท้าทาย" ที่เรากำลังเผชิญอยู่เมื่อเราต้องการสร้างเมล Outlook ใหม่สำหรับผู้ใช้ที่กล่องจดหมายของเขาได้ย้ายไปยัง "คลาวด์" (Exchange Online)

ตามค่าเริ่มต้น ในสภาพแวดล้อม Active Directory ไคลเอนต์การค้นหาอัตโนมัติจะสอบถาม Active Directory สำหรับชื่อของเซิร์ฟเวอร์ Exchange CAS ภายในเครื่อง

ในสถานการณ์ของเรา เราต้องการป้องกันไม่ให้ไคลเอนต์ Outlook เชื่อมต่อ Active Directory ในเครื่อง

สมมติว่าเราพบวิธี "บล็อก" ไคลเอ็นต์ Outlook ไม่ให้เชื่อมต่อกับ Active Directory ในเครื่อง (หมายเลข 1)

ตามค่าเริ่มต้น Outlook (ไคลเอนต์การค้นหาอัตโนมัติ) จะ "เปลี่ยนกลับ" เป็นวิธีการที่เขาแยกชื่อโดเมนจากที่อยู่อีเมลของผู้รับ และใช้ชื่อโดเมนนี้เป็นชื่อโฮสต์ของจุดสิ้นสุดการค้นหาอัตโนมัติ

ในสถานการณ์ของเรา ไคลเอนต์ Outlook ควรสอบถาม DNS ในเครื่องสำหรับโฮสต์ชื่อ - o365info.com (หมายเลข 2) และหากไม่พบ IP ไคลเอนต์ Autodiscover จะค้นหาโฮสต์ชื่อ - autodiscover.o365info.com

ตามทฤษฎีแล้ว เซิร์ฟเวอร์ DNS จะให้ที่อยู่ IP สาธารณะของเซิร์ฟเวอร์ Exchange CAS สาธารณะ
และอีกครั้ง ในสถานการณ์ของเรา เราต้องการป้องกันไม่ให้ Outlook เชื่อมต่อเซิร์ฟเวอร์ Exchange CAS ภายในเครื่องเนื่องจากเราต้องการให้ Outlook เริ่มการค้นหาอัตโนมัติ กระบวนการที่จะ "นำ" เขาไปสู่ "เซิร์ฟเวอร์ Cloud Exchange" (หมายเลข 3)

กระบวนการค้นหาอัตโนมัติภายนอก

ในแผนภาพต่อไปนี้ เราจะเห็นโครงสร้างพื้นฐานของผู้ใช้องค์กร (อลิซ) ที่ต้องการสร้างโปรไฟล์เมล Outlook ใหม่ แต่คราวนี้ ผู้ใช้ที่อยู่ในเครือข่ายสาธารณะ

ข้อแตกต่างคือ ขณะนี้ ผู้ใช้ไม่สามารถใช้วิธีค้นหาอัตโนมัติที่นำไปใช้ในสภาพแวดล้อม Active Directory ได้

ในสถานการณ์ของเรา ไคลเอนต์ Outlook ควรสอบถาม DNS สาธารณะสำหรับโฮสต์ที่ชื่อ - o365info.com (หมายเลข 1) และหากไม่พบ IP ไคลเอนต์ Autodiscover จะค้นหาโฮสต์ชื่อ - autodiscover.o365info.com

เซิร์ฟเวอร์ DNS สาธารณะจะให้ที่อยู่ IP สาธารณะของเซิร์ฟเวอร์ Exchange CAS สาธารณะ
และอีกครั้ง ในสถานการณ์ของเรา เราต้องการป้องกันไม่ให้ Outlook เชื่อมต่อเซิร์ฟเวอร์ Exchange CAS ภายในเครื่องเนื่องจากเราต้องการให้ Outlook เริ่มกระบวนการค้นหาอัตโนมัติ ที่จะ "นำ" เขาไปสู่ "เซิร์ฟเวอร์ cloud Exchange" (หมายเลข 2)

โซลูชัน "ฝั่งไคลเอ็นต์"

โซลูชัน “ฝั่งไคลเอ็นต์” ในสภาพแวดล้อมการย้ายขั้นประกอบด้วยสองตัวเลือก:

ตัวเลือกที่ 1: อัปเดตไฟล์การกำหนดค่าในเครื่อง

ในตัวเลือกนี้ เราจะเปลี่ยนลักษณะการทำงานเริ่มต้นของไคลเอนต์ Outlook โดยการแก้ไขส่วนประกอบระบบปฏิบัติการ - รีจิสทรีเดสก์ท็อปในเครื่องและไฟล์ HOSTS ในเครื่อง

1. การอัปเดตรีจิสทรีจะรวม DWORD ใหม่ที่จะป้องกันไม่ให้ไคลเอนต์ Outlook ใช้วิธีการค้นหาอัตโนมัติมาตรฐานในสภาพแวดล้อม Active Directory
2. การอัปเดตไฟล์ HOSTS จะรวม "การโกง" เล็กน้อยซึ่งเราจะแมปชื่อโฮสต์ Autodiscover กับที่อยู่ IP ของส่วนประกอบ Office 365 ซึ่งจะเปลี่ยนเส้นทางไคลเอ็นต์ Autodiscover ไปยังเซิร์ฟเวอร์ Exchange Online

ตัวเลือกที่ 2: การใช้ที่อยู่อีเมล onmicrosoft

ผู้ใช้ Office 365 แต่ละคนที่มีกล่องจดหมาย Exchange Online มี
ที่อยู่อีเมลอย่างน้อยสองรายการ:

“ที่อยู่อีเมลสาธารณะ ” เช่น - Alice@o365info.com
และที่อยู่อีเมล Office 365

ที่อยู่อีเมล Office 365 ขึ้นอยู่กับชื่อทฤษฎี Office 365 + ส่วนต่อท้ายโดเมน - onmicrosoft.com

ในตัวอย่างของเรา ที่อยู่อีเมล Office 365 ของ Alice คือ - Alice@o365info2.onmicrosoft.com

ในสถานการณ์ที่เราต้องการป้องกันไม่ให้ผู้ใช้เชื่อมต่อกับเซิร์ฟเวอร์ Exchange ภายในเครื่อง เราสามารถใช้เคล็ดลับเล็กๆ น้อยๆ ซึ่งเราจะให้ที่อยู่อีเมล Office 365 เมื่อสร้างโปรไฟล์อีเมล Outlook ใหม่แทน "อีเมลมาตรฐาน" ที่อยู่อีเมล”

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

ในกรณีที่เราต้องการ "บอก" Outlook ว่าเราต้องการใช้กระบวนการค้นหาอัตโนมัติอื่น เราจะใช้ที่อยู่อีเมล "อื่น ๆ " ที่ Alice มี -
Alice@o365info2. onmicrosoft.com

เมื่อเราสร้างโปรไฟล์เมล Outlook ใหม่โดยใช้ที่อยู่อีเมลนี้ (Alice@o365info2.onmicrosoft.com) กระบวนการค้นหาอัตโนมัติจะถูกนำมาใช้ในลักษณะต่อไปนี้-

ไคลเอนต์ Outlook จะสร้างแบบสอบถาม DNS เพื่อค้นหาจุดสิ้นสุดการค้นหาอัตโนมัติชื่อ - o365info2.onmicrosoft.com และในกรณีที่ไม่พบที่อยู่ IP สำหรับโฮสต์ดังกล่าว กระบวนการค้นหาอัตโนมัติ จะ “ก้าวต่อไป” ไปยังการสืบค้น DNS เพิ่มเติม โดยมองหาจุดสิ้นสุดการค้นหาอัตโนมัติชื่อ - autodiscover.o365info2.onmicrosoft.com

โฮสต์ - autodiscover.o365info2.onmicrosoft.com เป็นส่วนประกอบของ Office 365 ที่จะเปลี่ยนเส้นทางไคลเอ็นต์ Outlook ไปยังกล่องจดหมาย Exchange Online ของเขา