จาก Group Policy สู่ Intune — คู่มือโยกย้ายการจัดการอุปกรณ์สำหรับธุรกิจขนาดกลางและเล็ก

“หน้าต่างสนับสนุนของเซิร์ฟเวอร์หมดแล้ว จึงวางแผนเปลี่ยน แต่เราหมดความมั่นใจว่าควรซื้อเซิร์ฟเวอร์ AD อีกเครื่องแล้วรันโดเมนกับ Group Policy อีกรอบ (ห้าปี)” “Group Policy ที่ตัดสินในสำนักงานไม่เคยใช้กับแล็ปท็อปที่ใช้ทำงานระยะไกล หากใช้ได้เฉพาะเมื่อเชื่อม VPN จะพูดได้จริงไหมว่าเรากำลังจัดการ” — ไม่กี่ปีที่ผ่านมา คำปรึกษาแบบนี้จากลูกค้าธุรกิจขนาดกลางและเล็กเพิ่มขึ้นเรื่อย ๆ

ฉากหลังคือการเปลี่ยนวิธีทำงาน Active Directory (AD) ในองค์กรและ Group Policy (GPO) คือกลไกที่สมมติ “เครื่องอยู่บน LAN ขององค์กรและถึงตัวควบคุมโดเมนได้เสมอ” ตอนนี้ที่เครื่องพากลับบ้านและการทำงานระยะไกลเป็นปกติ ข้อสมมตินั้นเองที่พัง บนนั้น WSUS — นานแล้วที่เป็นค่าเริ่มต้นของการจัดการอัปเดต — ถูกเลิกในเดือนกันยายน 2024¹ และจุดศูนย์ถ่วงของการจัดการอุปกรณ์ของ Microsoft ย้ายไป Entra ID บวก Intune (MDM)

flowchart TB
    accTitle: ข้อสมมติที่พังและการย้ายจุดศูนย์ถ่วง
    accDescr: AD และ GPO สมมติว่าเครื่องอยู่บน LAN ขององค์กรและถึงตัวควบคุมโดเมนได้เสมอ แต่เครื่องพากลับบ้านและการทำงานระยะไกลเป็นปกติทำให้ข้อสมมตินั้นพัง และเมื่อ WSUS ถูกเลิก จุดศูนย์ถ่วงของการจัดการย้ายไป Entra ID และ Intune
    adgpo["AD ในองค์กรและ GPO"] -.-> premise["ข้อสมมติ: DC ถึงได้เสมอ"]
    work["เครื่องพากลับบ้านและการทำงานระยะไกลเป็นปกติ"] --> broken["ข้อสมมติเองที่พัง"]
    premise --> broken
    wsus["WSUS ถูกเลิก"] --> shift["จุดศูนย์ถ่วงย้ายไป Entra ID+Intune"]
    broken --> shift

ภาพ 1: ข้อสมมติ AD+GPO ที่ว่า “เครื่องอยู่บน LAN ขององค์กร” พังเมื่อวิธีทำงานเปลี่ยน และจุดศูนย์ถ่วงของการจัดการย้ายไป Entra ID+Intune

อย่างไรก็ตาม การโยกย้ายไม่ใช่ทั้งหมดหรือไม่มีเลย เครื่องที่จัดการด้วย Entra join บวก Intune และเครื่องที่เข้าร่วมโดเมน AD บวก GPO อยู่ร่วมในบริษัทเดียวกันได้² และการโยกย้ายเป็นขั้นเป็นไปได้: คง AD สำหรับเซิร์ฟเวอร์ไฟล์ และสลับเครื่องใหม่ไปการจัดการ Intune มุ่งเจ้าหน้าที่ไอทีและเจ้าของธุรกิจในธุรกิจขนาดกลางและเล็ก บทความนี้จัด — ยึดแหล่งปฐมภูมิอย่าง Microsoft Learn ณ สิงหาคม 2026 — ความต่างของวิธีที่ GPO และ MDM ทำงาน การกำหนดค่าข้อกำหนด สิทธิ์ วิธีทำรายการ GPO ปัจจุบัน สถานการณ์โยกย้ายเป็นขั้น และกับดัก

1. สรุปก่อนเลย

• GPO ถูกใช้เมื่อเครื่องเชื่อมกับเครือข่ายโดเมน Intune (MDM) ซิงค์ผ่านอินเทอร์เน็ต ปัญหา “การตั้งค่าไม่ถึงเครื่องบ้าน” ไม่เกิดเชิงโครงกับ MDM การซิงค์สถานะคงที่ประมาณทุก 8 ชั่วโมง และการซิงค์ตามการแจ้งก็รันเมื่อนโยบายเปลี่ยน³
• การโยกย้ายไม่ใช่ทั้งหมดหรือไม่มีเลย การโยกย้ายเป็นขั้นที่สมมติการอยู่ร่วมคือคำตอบสมจริง Microsoft เองแนะนำให้ Entra-join เครื่องใหม่ และปล่อยเครื่องที่เข้าร่วมโดเมนอยู่แล้วเป็น hybrid join แล้วแทนตามรอบเปลี่ยนฮาร์ดแวร์²
• สมัคร Intune เดี่ยวได้ แต่สำหรับธุรกิจขนาดกลางและเล็ก เส้นทางสมจริงคือใช้ Intune Plan 1 ที่รวมใน Microsoft 365 Business Premium (ณ สิงหาคม 2026) องค์ประกอบแผนเปลี่ยนเรื่อย ๆ จึงยืนยันแหล่งปฐมภูมิเสมอก่อนลงนาม⁴⁵
• เพื่อทำรายการ GPO ปัจจุบัน ใช้ Group Policy analytics ที่สร้างใน Intune นำเข้าการส่งออก XML ของ GPO แล้วแต่ละการตั้งค่าถูกจัดตามว่าโยกย้ายได้ การตั้งค่าที่มีคู่แปลงเป็นนโยบาย Settings catalog ได้⁶
• งานหลักของยุค GPO เกือบทั้งหมดมีคู่ใน Intune Administrative Templates แมปไป Settings catalog⁷ WSUS ไป Windows Update for Business กุญแจกู้ BitLocker ไปการเก็บใน Entra ID⁸ รหัสผ่านผู้ดูแลท้องถิ่นไป Windows LAPS⁹ และการแจกแอปไป Win32 apps (.intunewin)¹⁰ และแอป Microsoft Store (ฐาน winget)¹¹
• สิ่งคลาสสิกที่ย้ายตามที่เป็นไม่ได้คือสคริปต์ล็อกออน แมปไดรฟ์ และการแจกเครื่องพิมพ์ คุณแทนด้วยการแจกสคริปต์ PowerShell¹² Remediations (เดิม Proactive remediations)¹³ ทำให้งานเป็นแอป หรือ “หยุดการปฏิบัตินั้น”
• อย่าแจกการตั้งค่าเดียวกันจากทั้ง GPO และ MDM โดยค่าเริ่มต้น GPO ชนะความขัดแย้ง การตั้ง MDMWinsOverGP เป็น 1 ทำให้ MDM ชนะ แต่ใช้เฉพาะการตั้งค่า Policy CSP¹⁴
• เครื่องที่เข้าร่วมโดเมนและเครื่องที่ Entra-join อยู่ร่วมได้ และเครื่องที่ Entra-join เข้าถึงเซิร์ฟเวอร์ไฟล์ในองค์กรได้ การเลิก AD ทันทีไม่ใช่เงื่อนไขของการโยกย้าย²

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

flowchart LR
    accTitle: การจัดคำถามที่ควรตัดสินใหม่
    accDescr: คำถามว่าจะเปลี่ยนเซิร์ฟเวอร์ AD อีกรอบหรือไม่ควรจัดใหม่เป็นคำถามว่าห้าปีถัดไปจะใช้อะไรจัดการเครื่องนอกสถานที่
    q1["เปลี่ยนเซิร์ฟเวอร์ AD อีกรอบ?"] -->|จัดใหม่| q2["ห้าปีถัดไป อะไรจัดการเครื่องนอกสถานที่?"]

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

2. GPO กับ MDM ต่างกันอย่างไร — เทียบกลไกการใช้

ก่อนอื่น เทียบสองอย่างในสนามเดียวกัน กลไกของ GPO เอง (ลำดับการใช้ LSDOU วิธียืนยันด้วย gpupdate/gpresult) ครอบคลุมลึกใน “คู่มือปฏิบัติ Group Policy (GPO)” ดังนั้นที่นี่เราแคบไปความต่างที่สำคัญต่อการตัดสินโยกย้าย

แถวที่สำคัญที่สุดต่อการตัดสินโยกย้ายคือแถวแรกกับแถวที่สาม ที่ GPO ไม่ถึงเครื่องบ้านไม่ใช่บั๊ก — คือข้อสมมติออกแบบ “เครื่องนั่งที่ถึงตัวควบคุมโดเมนได้” ไม่ตรงวิธีทำงานวันนี้แล้ว คุณคง GPO ให้มีชีวิตด้วยการบังคับ VPN เปิดตลอดกับพนักงานทุกคนได้ แต่นั่นก็เป็นการเลือกที่จะรับการบำรุงโครงสร้างพื้นฐานอีกชิ้น: แพลตฟอร์ม VPN

flowchart TB
    accTitle: ทางเลือกระหว่างการคง GPO ให้มีชีวิตกับการโยกย้ายไป MDM
    accDescr: ที่ GPO ไม่ถึงเครื่องบ้านเป็นเพราะข้อสมมติออกแบบไม่ตรงวิธีทำงานวันนี้ และการบังคับ VPN เปิดตลอดเพื่อคง GPO คือการเลือกที่จะรับการบำรุงโครงสร้างพื้นฐานอีกชิ้น คือแพลตฟอร์ม VPN
    gap["ข้อสมมติออกแบบไม่ตรงวิธีทำงาน"] --> sel{"ตอบอย่างไร"}
    sel -->|คงให้มีชีวิตด้วย VPN เปิดตลอด| vpn["ทำต่อกับ GPO"]
    sel -->|โยกย้ายไป MDM| mdm["จัดการผ่านอินเทอร์เน็ต"]
    vpn --> cost["คุณรับการบำรุงโครงสร้างพื้นฐานอื่น"]

ภาพ 3: เส้นทางคง GPO ให้มีชีวิตด้วย VPN เปิดตลอดก็เป็นการเลือกที่จะรับการบำรุงโครงสร้างพื้นฐานอีกชิ้น: แพลตฟอร์ม VPN

ในทางกลับกัน ช่วงซิงค์ของ MDM (ประมาณ 8 ชั่วโมง) หยาบกว่าการรีเฟรชเป็นระยะของ GPO (ประมาณ 90 นาที) และความรู้สึก “แจกแล้วใช้ทันที” ไม่ตามมา เมื่อคุณกำหนดหรือเปลี่ยนนโยบาย มีการแจ้งไปอุปกรณ์และซิงค์ค่อนข้างเร็ว³ แต่การควบคุมที่ต้องการความทันที (การบล็อกฉุกเฉิน และคล้ายกัน) ต้องออกแบบรอบช่วงซิงค์

flowchart TB
    accTitle: GPO และ MDM ใช้นโยบายอย่างไร
    accDescr: GPO ใช้เฉพาะเมื่อเครื่องเชื่อมตัวควบคุมโดเมนในองค์กรได้ ดังนั้นเครื่องบ้านขึ้นกับ VPN Intune ซิงค์ผ่านอินเทอร์เน็ตประมาณทุก 8 ชั่วโมงและซิงค์ตามการแจ้งเมื่อนโยบายเปลี่ยน จึงถึงเครื่องได้ทุกที่
    officepc["เครื่องในองค์กร"] --> dc["ตัวควบคุมโดเมน"]
    officepc -.-> when["สตาร์ตและลงชื่อเข้าใช้"]
    when -.-> when2["บวกการรีเฟรชเป็นระยะ"]
    homepc["เครื่องบ้าน"] --> vpn{"ถึง DC ผ่าน VPN?"}
    vpn -->|ใช่| dc
    vpn -->|ไม่| miss["นโยบายไม่เคยมา"]
    anypc["เครื่องทุกที่"] --> intune["บริการ Intune"]
    anypc -.-> every["ซิงค์ประมาณทุก 8 ชม."]
    intune -.-> notify["การเปลี่ยนตามการแจ้ง"]
    dc ~~~ homepc
    miss ~~~ anypc

ภาพ 4: GPO ใช้เฉพาะเมื่อเครื่องถึงตัวควบคุมโดเมนได้ Intune ซิงค์ผ่านอินเทอร์เน็ตไม่ว่าจะอยู่ที่ไหน

3. จัดข้อกำหนด — สามรูปแบบ: Domain Join, Hybrid Join และ Entra Join

มีสามรูปแบบของ “เครื่อง Windows เข้าร่วมบริษัทอย่างไร” และการเลือกใดกำหนดเครื่องมือจัดการที่คุณใช้ได้²

Hybrid join คือรูปแบบสำหรับ “ให้เครื่องที่เข้าร่วมโดเมนอยู่แล้วมีตัวตนคลาวด์” และให้คุณเริ่มใช้ Intune และ Conditional Access ขณะเก็บสินทรัพย์ที่มีอยู่ Microsoft อย่างไรก็ตาม แนะนำไม่ให้ทำให้ hybrid join เป็นเป้าหมายสุดท้าย และให้ Entra-join เครื่องใหม่และเครื่องแทน²

มีข้อจำกัดหนึ่งที่ต้องรับ ไม่มีทางที่ Microsoft รองรับในการแปลงเครื่องที่เข้าร่วมโดเมนอยู่แล้ว (รวม hybrid join) เป็น Entra join ต้องรีเซ็ต Windows (ล้าง) นั่นคือเหตุที่ Microsoft ยังแนะนำให้ย้ายไป Entra join ตอนเปลี่ยนฮาร์ดแวร์หรือติดตั้งระบบปฏิบัติการใหม่²

flowchart TB
    accTitle: สามรูปแบบการเข้าร่วมและเส้นทางโยกย้าย
    accDescr: เครื่องที่เข้าร่วมโดเมน AD อย่างเดียวลงทะเบียนใน Entra ID ด้วยแล้วเป็น hybrid join ได้ แต่ไม่มีทางแปลงตรงไป Entra join และต้องล้าง ดังนั้นการ Entra-join เครื่องใหม่และเครื่องแทนจึงถูกแนะนำ
    adonly["เข้าร่วมโดเมน AD อย่างเดียว （GPO）"] -->|ลงทะเบียนใน Entra ID ด้วย| hybrid["hybrid join （GPO และ Intune）"]
    hybrid -.->|ไม่มีเส้นทางแปลงตรง| wipe["ต้องล้าง （รีเซ็ต）"]
    wipe --> entra["Entra join （Intune）"]
    newpc["เครื่องใหม่และเครื่องแทน"] -->|แนะนำ| entra

ภาพ 5: ไม่มีทางที่รองรับในการแปลงเครื่องที่เข้าร่วมโดเมนอยู่แล้วเป็น Entra join รูปแบบที่ยึดคือสลับจากเครื่องใหม่และเครื่องแทน

จากข้างต้น เป้าหมายสมจริงสำหรับธุรกิจขนาดกลางหรือเล็กวางได้แบบนี้

1. จัดการเครื่องใหม่และเครื่องแทนด้วย Entra join บวก Intune
2. ปล่อยเครื่องที่เข้าร่วมโดเมนอยู่แล้วไว้ และให้ถูกแทนตามธรรมชาติตามรอบเปลี่ยนฮาร์ดแวร์
3. คง AD ไว้ชั่วคราวสำหรับบทบาทที่เหลืออย่างการยืนยันตัวตนเซิร์ฟเวอร์ไฟล์ และทำให้เนื้อหาของ GPO ว่างเป็นขั้น

flowchart TB
    accTitle: การกำหนดค่าอยู่ร่วมระหว่างการโยกย้ายเป็นขั้น
    accDescr: เครื่องที่ Entra-join และเครื่องที่เข้าร่วมโดเมนอยู่ร่วมในสภาพแวดล้อมองค์กรเดียวกันได้ อันแรกจัดการด้วย Intune อันหลังด้วย GPO ขณะที่คง AD สำหรับบทบาทที่เหลือและทำให้เนื้อหาของ GPO ว่างเป็นขั้นเท่านั้น
    env["สภาพแวดล้อมองค์กรเดียวกัน"] --> ejoin["เครื่องที่ Entra-join"]
    env --> djoin["เครื่องที่เข้าร่วมโดเมน"]
    ejoin --> intune["จัดการด้วย Intune"]
    djoin --> gpo["จัดการด้วย GPO"]
    gpo -.-> shrink["ทำให้เนื้อหาว่างเป็นขั้น"]
    env -.-> ad["คง AD สำหรับบทบาทที่เหลือ"]

ภาพ 6: เครื่องที่ Entra-join และเครื่องที่เข้าร่วมโดเมนอยู่ร่วมในสภาพแวดล้อมองค์กรเดียวกันได้ และคง AD ไว้ชั่วคราวสำหรับบทบาทที่เหลือ

เครื่องที่ Entra-join และเครื่องที่เข้าร่วมโดเมนอยู่ร่วมในสภาพแวดล้อมเดียวกันได้ และเครื่องที่ Entra-join เข้าถึงสินทรัพย์ในองค์กรอย่างเซิร์ฟเวอร์ไฟล์ในองค์กรได้² การลงชื่อเข้าใช้เดียวนั้น อย่างไรก็ตาม มีสองข้อกำหนด (1) ผู้ใช้เป็นตัวตนไฮบริดที่ซิงค์จาก AD ในองค์กรด้วย Entra Connect (หรือ Cloud Sync) (ผู้ใช้ที่มีอยู่เฉพาะในคลาวด์ได้ข้อมูลประจำตัว Kerberos/NTLM ของ AD ไม่ได้) และ (2) เครื่องมีการถึงเครือข่ายไปตัวควบคุมโดเมน (จากนอกสถานที่ ต้องการ VPN หรือคล้ายกัน)¹⁵ ในแผนโยกย้าย ยืนยันก่อนว่าไม่มีผู้ใช้หรือสถานการณ์การใช้ที่ล้มสองจุดนี้

flowchart TB
    accTitle: ข้อกำหนดของ SSO จากเครื่องที่ Entra-join ไปสินทรัพย์ในองค์กร
    accDescr: เพื่อเข้าถึงเซิร์ฟเวอร์ไฟล์ในองค์กรจากเครื่องที่ Entra-join ต้องครบสองข้อกำหนด: ตัวตนไฮบริดที่ซิงค์ด้วย Entra Connect หรือคล้ายกัน และการถึงตัวควบคุมโดเมน
    pc["เครื่องที่ Entra-join"] --> cond1{"ตัวตนไฮบริด?"}
    cond1 -->|ใช่| cond2{"ถึง DC ได้?"}
    cond1 -->|ไม่| ng1["ได้ข้อมูลประจำตัว AD ไม่ได้"]
    cond2 -->|ใช่| ok["SSO ไปเซิร์ฟเวอร์ไฟล์"]
    cond2 -->|ไม่| ng2["จากนอกสถานที่ ต้องการ VPN หรือคล้ายกัน"]

ภาพ 7: SSO จากเครื่องที่ Entra-join ไปสินทรัพย์ในองค์กรมีสองข้อกำหนด: ตัวตนไฮบริดและการถึงตัวควบคุมโดเมน

4. สิทธิ์และต้นทุน — แผนใดรวม Intune (ณ สิงหาคม 2026)

สิทธิ์ Intune ฐานคือ Microsoft Intune Plan 1 ให้ทั้งเป็นการสมัครเดี่ยวและรวมในแผน Microsoft 365 ต่าง ๆ⁴

ที่สำคัญสำหรับธุรกิจขนาดกลางและเล็กคือ Microsoft 365 Business Premium สำหรับสูงสุด 300 ผู้ใช้ รวม Intune Plan 1⁵ Business Premium ยังรวม Microsoft Entra ID P1 และ Microsoft Defender for Business ดังนั้นการกำหนดค่านโยบายความสอดคล้องบวก Conditional Access ที่อธิบายต่อไปครบในแผนนี้ได้ Business Standard/Basic ในทางกลับกัน ไม่รวม Intune เมื่อคุณก้าวจากสัญญาเมลและ Office อย่างเดียวเข้าสู่การจัดการอุปกรณ์ ต้นทุนอัปเกรดไป Business Premium คือต้นทุนที่มีผลของการนำ Intune เข้า

flowchart TB
    accTitle: แผน SME สัมพันธ์กับ Intune อย่างไร
    accDescr: Business Premium สำหรับสูงสุด 300 ผู้ใช้รวม Intune Plan 1, Entra ID P1 และ Defender for Business และครบถึง Conditional Access แต่ Business Standard/Basic ไม่รวม Intune
    bp["Business Premium"] -.-> cap["สูงสุด 300 ผู้ใช้"]
    bp --> intune["Intune Plan 1"]
    bp --> p1["Entra ID P1"]
    bp --> dfb["Defender for Business"]
    p1 --> ca["ครบถึง Conditional Access"]
    dfb ~~~ std["Business Standard/Basic"]
    std --> noint["ไม่รวม Intune"]

ภาพ 8: Business Premium รวม Intune Plan 1 และ Entra ID P1 Business Standard/Basic ไม่รวม Intune

มีสองข้อควรระวัง

• องค์ประกอบแผนเปลี่ยนบ่อย แม้เข้าปี 2026 การเปลี่ยนแปลงที่กระจายคุณลักษณะ Intune Suite เข้าแผน Microsoft 365 สูงกว่า (E3/E5 และคล้ายกัน) กำลังดำเนิน และการทบทวนสิ่งที่รวมยังต่อเนื่อง⁴ ถือส่วนนี้ ณ สิงหาคม 2026 และก่อนลงนามยืนยันข้อมูลล่าสุดบนหน้าสิทธิ์และราคาของ Microsoft เสมอ
• บางคุณลักษณะที่เปิดจาก UI ของ Intune ได้ต้องการสิทธิ์แยก ตัวอย่างตัวแทนคือ Remediations ที่อธิบายต่อไป: ต้องการสิทธิ์ระดับ Windows Enterprise E3/E5 (รวมใน Microsoft 365 E3/E5 และคล้ายกัน) และไม่มีในขอบของ Business Premium¹³

การเทียบต้นทุนไม่ใช่ “ต้นทุนสมัคร Intune” กับ “ศูนย์” ฝั่ง GPO คุณจ่ายอยู่แล้วสำหรับการเปลี่ยนฮาร์ดแวร์เซิร์ฟเวอร์ AD สิทธิ์ Windows Server และ CAL ต้นทุนสร้าง ห้าปีของการบำรุง สำรอง และการตอบเหตุการณ์ การเทียบที่ถูกคือวางใบเสนอราคาเปลี่ยนเซิร์ฟเวอร์ข้างห้าปีของ Business Premium แล้วใส่ความต่างของความสามารถ “การจัดการถึงเครื่องนอกสถานที่ไหม”

flowchart TB
    accTitle: วิธีคิดที่ถูกของการเทียบต้นทุน
    accDescr: ฝั่ง GPO ก็มีต้นทุนอย่างการเปลี่ยนเซิร์ฟเวอร์ AD สิทธิ์ และห้าปีของการบำรุง ดังนั้นวางใบเสนอราคาเปลี่ยนเซิร์ฟเวอร์ข้างห้าปีของ Business Premium แล้วตัดสินด้วยความต่างของความสามารถว่าการจัดการถึงเครื่องนอกสถานที่ไหม
    gpocost["ต้นทุนของการทำต่อกับ GPO"] --> hw["การเปลี่ยนเซิร์ฟเวอร์ สิทธิ์ CAL"]
    gpocost --> ops["การสร้าง การบำรุง การสำรอง"]
    bpcost["ต้นทุนของการโยกย้ายไป Intune"] --> sub["ห้าปีของ Business Premium"]
    hw --> diff["วางความต่างห้าปีข้างกัน"]
    ops --> diff
    sub --> diff
    diff --> ability["ใส่ว่าการจัดการถึงเครื่องนอกสถานที่ไหม"]

ภาพ 9: วางใบเสนอราคาเปลี่ยนเซิร์ฟเวอร์ข้างห้าปีของ Business Premium แล้วตัดสินด้วยความต่างของความสามารถในการจัดการเครื่องนอกสถานที่

5. ทำสิ่งที่เคยทำด้วย GPO ใน Intune อย่างไร

สำหรับแต่ละงานหลักของการดำเนินงาน GPO คู่ใน Intune แสดงในตารางแมป

สองสามหมายเหตุ

• Settings catalog คือหน้าจอที่ตรงกับ “ฉบับคลาวด์ของตัวแก้ไข GPO” และ Microsoft เองวางเป็น “ปลายทางโยกย้ายธรรมชาติเมื่ออยากกำหนดในรายละเอียดเดียวกับ GPO ในองค์กร” รวมนโยบายที่รองรับ ADMX (ฉบับ MDM ของการตั้งค่าที่นิยามใน ADMX) และยังมีคุณลักษณะ (พรีวิว) สำหรับนำเข้า ADMX ของบุคคลที่สาม⁷
• นโยบายความสอดคล้องบวก Conditional Access คือความคิดที่ GPO ไม่มี คุณนิยามเงื่อนไขความสอดคล้องอย่าง “BitLocker เปิด ระบบปฏิบัติการปัจจุบัน Defender รัน” และบล็อกการเข้าถึง Microsoft 365 จากอุปกรณ์ที่ไม่ครบ Conditional Access คือคุณลักษณะ Entra ID P1 และรวมใน Business Premium¹⁶
• Remediations ถูกเปลี่ยนชื่อจาก Proactive remediations คือกลไกที่รันคู่สคริปต์ตรวจบวกแก้เป็นระยะ และแทนการดำเนินงาน GPO แบบ “แก้บางอย่างทุกครั้งที่ล็อกออน” ได้ แต่ตามที่กล่าวต้องการสิทธิ์ระดับ Windows Enterprise E3/E5¹³ ในขอบของ Business Premium ตัวแทนสมจริงคือรวม platform scripts (รันเมื่อสคริปต์หรือการกำหนดเปลี่ยน และลองใหม่เมื่อล้ม)¹² กับกฎการตรวจของแอป Win32
• ทางเลือกรายละเอียดของการจัดการอัปเดต (การตัดสินระหว่าง WUfB, Autopatch และการทำต่อกับ WSUS) ครอบคลุมใน “การจัดการ Windows Update หลังการเลิก WSUS” และการออกแบบ BitLocker และ LAPS ใน “คู่มือปฏิบัติ BitLocker” และ “คู่มือปฏิบัติ Windows LAPS” ตามลำดับ

flowchart TB
    accTitle: ไหลของนโยบายความสอดคล้องและ Conditional Access
    accDescr: นโยบายความสอดคล้องตัดสินเฉพาะสถานะความสอดคล้องของอุปกรณ์กับเงื่อนไขความสอดคล้อง มีเพียงเมื่อนโยบาย Conditional Access ต้องการอุปกรณ์ที่สอดคล้อง อุปกรณ์ที่สอดคล้องจึงได้รับอนุญาตและอุปกรณ์ที่ไม่สอดคล้องถูกบล็อก
    policy["นิยามเงื่อนไขความสอดคล้อง"] -.-> cond["BitLocker เปิด ระบบปฏิบัติการปัจจุบัน และคล้ายกัน"]
    policy --> state["ตัดสินสถานะความสอดคล้องของอุปกรณ์"]
    state --> ca["Conditional Access ต้องการความสอดคล้อง"]
    ca -->|สอดคล้อง| allow["การเข้าถึง Microsoft 365 อนุญาต"]
    ca -->|ไม่สอดคล้อง| block["การเข้าถึงถูกบล็อก"]

ภาพ 10: การตัดสินสถานะความสอดคล้องคืองานของนโยบายความสอดคล้อง การบล็อกคืองานของ Conditional Access มีผลบล็อกเฉพาะเมื่อรวมกัน

6. การทำรายการ GPO ปัจจุบัน — จัดด้วย Group Policy Analytics

งานจริงแรกของแผนโยกย้ายคือการทำรายการ GPO ปัจจุบัน Intune มีคุณลักษณะเฉพาะ Group Policy analytics ที่จัดต่อตั้งค่าได้ว่า “MDM แทนสิ่งนี้ได้ไหม” โดยไม่ต้องอ่าน GPO ด้วยมือ⁶

ขั้นตอนมีดังนี้⁶

1. เปิด Group Policy Management Console (GPMC.msc) บนตัวควบคุมโดเมนหรือคล้ายกัน คลิกขวา GPO เป้าหมาย → Save Report แล้วส่งออกเป็น ไฟล์ XML (4 MB หรือน้อยกว่าต่อไฟล์)
2. ในศูนย์ผู้ดูแล Intune ไป Devices → Group Policy analytics แล้วนำเข้า XML (เลือกหลายไฟล์ได้)
3. หลังการวิเคราะห์อัตโนมัติ แต่ละ GPO แสดง เปอร์เซ็นต์การรองรับ MDM (สัดส่วนของการตั้งค่าที่มีเทียบเท่าใน Intune)
4. ในรายงาน Group policy migration readiness ยืนยันการจัดต่อตั้งค่า: Ready for migration / Not supported / Deprecated
5. การตั้งค่า Ready for migration แปลงตามที่เป็นเป็นนโยบาย Settings catalog แล้วแจกได้

flowchart TB
    accTitle: ไหลการทำรายการด้วย Group Policy analytics
    accDescr: ส่งออก GPO เป็น XML จาก GPMC แล้วนำเข้า Intune เปอร์เซ็นต์การรองรับ MDM และความพร้อมโยกย้ายต่อตั้งค่าถูกแสดง และการตั้งค่า Ready for migration แปลงเป็นนโยบาย Settings catalog ได้
    export["ส่งออก GPO เป็น XML จาก GPMC"] --> import["นำเข้า Intune"]
    import --> rate["เปอร์เซ็นต์การรองรับ MDM ถูกแสดง"]
    rate --> report["รายงานความพร้อมโยกย้าย"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["แปลงเป็นนโยบาย Settings catalog"]

ภาพ 11: จากการส่งออก XML ผ่านการนำเข้า การจัดต่อตั้งค่า และการแปลงไป Settings catalog — นั่นคือไหลของ Group Policy analytics

มีข้อควรระวังสำคัญในสภาพแวดล้อมญี่ปุ่น การวิเคราะห์การตั้งค่าที่ไม่ใช่ ADMX ใน Group Policy analytics เป็นภาษาอังกฤษอย่างเดียว การนำเข้า GPO ที่มีการตั้งค่าในภาษาอื่นนอกจากอังกฤษอาจทำให้เปอร์เซ็นต์การรองรับ MDM คลาด⁶ ถือเปอร์เซ็นต์การรองรับเป็นค่าอ้างอิงหยาบ และตัดสินสุดท้ายจากรายการต่อตั้งค่า

flowchart TB
    accTitle: ข้อควรระวังเมื่อวิเคราะห์ GPO ญี่ปุ่น
    accDescr: การวิเคราะห์การตั้งค่าที่ไม่ใช่ ADMX ใน Group Policy analytics เป็นภาษาอังกฤษอย่างเดียว ดังนั้น GPO ที่มีการตั้งค่าญี่ปุ่นอาจทำให้เปอร์เซ็นต์การรองรับ MDM คลาด ถือเปอร์เซ็นต์เป็นอ้างอิงหยาบและตัดสินสุดท้ายจากรายการต่อตั้งค่า
    jgpo["GPO ที่มีการตั้งค่าญี่ปุ่น"] --> limit["การวิเคราะห์ที่ไม่ใช่ ADMX เป็นอังกฤษอย่างเดียว"]
    limit --> rate["เปอร์เซ็นต์การรองรับอาจคลาด"]
    rate --> use1["ถือเปอร์เซ็นต์เป็นอ้างอิงหยาบ"]
    rate --> use2["ตัดสินสุดท้ายจากรายการต่อตั้งค่า"]

ภาพ 12: ใน GPO ญี่ปุ่น เปอร์เซ็นต์การรองรับ MDM อาจคลาด ดังนั้นตัดสินสุดท้ายจากรายการต่อตั้งค่า

ในทางปฏิบัติ แยกผลการจัดเป็นสามกอง

1. การตั้งค่าที่ทิ้ง — การตั้งค่ายุค Internet Explorer การตั้งค่าสำหรับระบบที่เลิก การตั้งค่าที่ไม่มีใครอธิบายเหตุได้ ผลตอบแทนใหญ่สุดของการทำรายการจริง ๆ คือการทิ้งกองนี้ได้ GPO ที่รันสิบปีมีมรดกกองพอสมควร
2. การตั้งค่าที่ย้ายไป Intune — ที่ใน Ready for migration ที่คุณยังต้องการ แปลงไป Settings catalog แล้วยืนยันกับกลุ่มนำร่อง
3. การตั้งค่าที่คุณออกแบบตัวแทน — ที่ใน Not supported ที่คุณยังต้องการ ตัวอย่างตัวแทนและทิศทางการแทนมีดังนี้

flowchart TB
    accTitle: สามกองของผลการทำรายการ
    accDescr: ผลการทำรายการถูกจัดการเป็นสามกอง การตั้งค่าที่ทิ้ง การตั้งค่าที่ย้ายไป Intune แล้วยืนยัน และการตั้งค่าที่ไม่มีคู่ซึ่งคุณออกแบบตัวแทน
    result["ผลการจัด"] --> discard["การตั้งค่าที่ทิ้ง"]
    result --> more{"ย้ายหรือแทน?"}
    more --> move["ย้ายไป Intune"]
    more --> alt["ออกแบบตัวแทน"]
    discard -.-> legacy["กำจัดมรดก"]
    move --> pilot["Settings catalog"]
    pilot -.-> pilotN["แล้วยืนยัน"]
    alt --> design["สคริปต์หรือทำให้เป็นแอป"]

ภาพ 13: แยกผลการทำรายการเป็นสามกอง “ทิ้ง” “ย้ายไป Intune” และ “ออกแบบตัวแทน”

7. สถานการณ์โยกย้ายเป็นขั้น — ห้าขั้นและเกณฑ์ออก

แยกทั้งหมดเป็นห้าขั้นแล้วใส่เกณฑ์ออกแต่ละขั้น การตัดสินล่วงหน้าว่า “เมื่อไหร่พูดได้ว่าเสร็จ” คือกลเม็ดที่กันการโยกย้ายของไอทีคนเดียวไม่ให้ค้าง

flowchart TB
    accTitle: สถานการณ์โยกย้ายห้าขั้น
    accDescr: ก้าวเป็นขั้นจากนำร่องผ่านนโยบายฐาน การแจกแอป การแทนเครื่องที่มีอยู่ตามรอบเปลี่ยนฮาร์ดแวร์ และการหดบทบาทของ AD สุดท้ายทำให้การตั้งค่าที่แจกผ่าน GPO เป็นศูนย์
    s1["（1） นำร่อง"] --> s2["（2） นโยบายฐาน"]
    s2 --> s3["（3） การแจกแอป"]
    s3 --> s4["（4） การแทนตามธรรมชาติของเครื่องที่มีอยู่"]
    s4 --> s5["（5） การหดบทบาทของ AD"]
    s5 -.-> goal["การตั้งค่าที่แจกผ่าน GPO เป็นศูนย์"]

ภาพ 14: ก้าวการโยกย้ายในห้าขั้นจากนำร่องผ่านการหดบทบาทของ AD และตัดสินเกณฑ์ออกของแต่ละขั้นล่วงหน้า

จุดสำคัญของแต่ละขั้น

• (1) นำร่อง เริ่มด้วยเครื่องที่คุณจะซื้ออยู่แล้ว — เครื่องพนักงานใหม่ถัดไป การแทนเครื่องพัง และคล้ายกัน การเริ่มจากเครื่องใหม่มีข้อดีว่าเริ่มด้วยการลงทุนเพิ่มเป็นศูนย์ และหากล้ม ล้างแล้วเริ่มใหม่ได้ เมื่อจำนวนโต พิจารณาใช้ Windows Autopilot เพื่ออัตโนมัติจาก OOBE (การตั้งค่าเริ่มต้น) ผ่าน Entra join บวกการลงทะเบียน Intune²
• ใน (2) นโยบายฐาน อย่ามุ่งทำซ้ำการตั้งค่า GPO ทุกอย่าง ก่อนแคบไปห้าอย่างของอัปเดต การเข้ารหัส Defender ล็อกจอ และ LAPS แล้วทำให้สถานะความสอดคล้องเห็นด้วยนโยบายความสอดคล้อง การเปิด “เฉพาะอุปกรณ์ที่สอดคล้อง” ใน Conditional Access มาหลังยืนยันว่าไม่มีผลบวกลวงในนำร่อง¹⁶
• (3) การแจกแอป ต่อเนื่องกับการอัตโนมัติการจัดเตรียม หากมีขั้นตอนฐาน winget อยู่แล้ว (“การจัดเตรียมเครื่องอัตโนมัติด้วย winget + PowerShell”) สินทรัพย์นั้นใช้ซ้ำเกือบตามที่เป็นเป็นแอป Store (ใหม่) หรือตัวห่อแอป Win32 ได้¹¹
• (4) เครื่องที่มีอยู่ ตามที่บทที่ 3 กล่าว ไม่มีเส้นทางแปลงไป Entra join ดังนั้นหลักคือการแทนตามธรรมชาติ องค์กรที่ยังมีแผนแทน Windows 10 (“ทางเลือกปฏิบัติหลังสิ้นสุดการสนับสนุน Windows 10”) หลีกเลี่ยงการทำงานซ้ำด้วยการเร่งการแทนนั้นพร้อมกับ (4)
• ใน (5) การหดบทบาทของ AD การทำให้ GPO ว่างไม่จำเป็นหมายความว่า AD ไม่จำเป็นทันที หากการยืนยันตัวตนเซิร์ฟเวอร์ไฟล์ การค้นหา LDAP จากแอปเดิม และคล้ายกันยังอยู่ AD ทำต่อในรูปที่หดเป็น “เซิร์ฟเวอร์ยืนยันตัวตน” การทำรายการเหล่านั้นและการตั้งกำหนดคืองานของขั้นนี้

flowchart TB
    accTitle: จะทำอะไรกับ AD หลัง GPO ว่าง
    accDescr: แม้หลัง GPO ว่าง หากการยืนยันตัวตนเซิร์ฟเวอร์ไฟล์หรือการค้นหา LDAP จากแอปเดิมยังอยู่ AD ทำต่อในรูปที่หดเป็นเซิร์ฟเวอร์ยืนยันตัวตน และการทำรายการบทบาทที่เหลือกับการตั้งกำหนดคืองานของขั้นสุดท้าย
    gpoempty["GPO ว่าง"] --> remain{"บทบาทที่เหลือมีอะไร"}
    remain -->|การยืนยันตัวตนเซิร์ฟเวอร์ไฟล์| keep["ทำต่อในรูปที่หดเป็นเซิร์ฟเวอร์ยืนยันตัวตน"]
    remain -->|การค้นหา LDAP เดิม| keep
    remain -->|ไม่มีบทบาทที่เหลือ| retire["พิจารณาเลิก AD เอง"]
    keep --> task["ทำรายการและการตั้งกำหนดให้ครบ"]

ภาพ 15: แม้หลัง GPO ว่าง หากมีบทบาทที่เหลือ AD ทำต่อในรูปที่หดเป็นเซิร์ฟเวอร์ยืนยันตัวตน

8. กับดัก

8.1. การใช้คู่ของ GPO และ MDM — โดยค่าเริ่มต้น GPO ชนะ

ระหว่างช่วงโยกย้าย ทั้ง GPO และ Intune จะแจกการตั้งค่าไปเครื่องเดียวกัน (เครื่อง hybrid-join) ที่นี่ เมื่อการตั้งค่าเดียวกันขัดแย้ง Group Policy ชนะโดยค่าเริ่มต้น การตั้ง MDMWinsOverGP ของ Policy CSP เป็น 1 ทำให้การตั้งค่าฝั่ง MDM ชนะและบล็อกการตั้งค่า GPO ที่ตรง แต่กลไกนั้น ใช้เฉพาะการตั้งค่าใต้ Policy CSP และไม่ใช้กับการตั้งค่าที่นิยามใน CSP อื่นอย่าง Defender CSP Microsoft เองระบุว่าหากคุณกำหนดการตั้งค่าที่ไม่อยู่ใต้ MDMWinsOverGP จากทั้ง GPO และ MDM คุณเข้าสู่สถานะขัดแย้งและไม่มีการรับประกันว่าอันใดชนะ¹⁴

flowchart TB
    accTitle: ลำดับเมื่อ GPO และ MDM ขัดแย้ง
    accDescr: หากแจกการตั้งค่าเดียวกันจากทั้ง GPO และ MDM GPO ชนะโดยค่าเริ่มต้น การตั้ง MDMWinsOverGP เป็น 1 ทำให้ MDM ชนะเฉพาะการตั้งค่าใต้ Policy CSP และการตั้งค่าใน CSP อื่นไม่มีการรับประกันว่าอันใดชนะ
    both["แจกการตั้งค่าเดียวกันจากทั้ง GPO และ MDM"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|ไม่| gpowin["GPO ชนะ （ค่าเริ่มต้น）"]
    flag -->|ใช่| csp{"การตั้งค่าใต้ Policy CSP?"}
    csp -->|ใช่| mdmwin["MDM ชนะ"]
    csp -->|ไม่| unknown["ไม่มีการรับประกันว่าอันใดชนะ"]
    both -.-> avoid["หลักคืออย่าแจกจากทั้งสอง"]

ภาพ 16: โดยค่าเริ่มต้น GPO ชนะ และ MDMWinsOverGP ใช้เฉพาะใต้ Policy CSP หลักคือหลีกเลี่ยงการแจกคู่

หลักปฏิบัติเรียบง่าย อย่าพึ่งการควบคุมลำดับความสำคัญ อย่าแจกการตั้งค่าเดียวกันจากทั้งสอง สำหรับการตั้งค่าที่คุณย้ายไป Intune แล้ว ให้การกำหนดค่าฝั่ง GPO ที่ตรงกลับเป็น “Not configured” หรือเลิกลิงก์ GPO ทั้งหมด รายการที่ย้ายของบทที่ 6 ก็เป็นสมุดบัญชีสำหรับสิ่งนี้

8.2. การพึ่งสินทรัพย์ในองค์กร — ไดรฟ์เครือข่ายและเครื่องพิมพ์

หลายจุดที่การโยกย้ายค้างไม่ใช่คุณลักษณะ Intune แต่เป็นการเชื่อมต่อกับสินทรัพย์ในองค์กร การเข้าถึงเองจากเครื่องที่ Entra-join ไปเซิร์ฟเวอร์ไฟล์ในองค์กรเป็นไปได้² แต่หากแมปไดรฟ์และการแจกเครื่องพิมพ์พึ่งสคริปต์ล็อกออนของ GPO ทางแจกนั้นหายไปก่อน ตัดสินระหว่างนำร่องว่าจะพับการโยกย้ายแชร์ไป OneDrive/SharePoint หรือการแทนด้วย Universal Print เข้าขั้น (3) หรือสะพานชั่วคราวด้วยการแจกสคริปต์¹²

flowchart TB
    accTitle: การแทนการแจกที่พึ่งสินทรัพย์ในองค์กร
    accDescr: หากแมปไดรฟ์และการแจกเครื่องพิมพ์พึ่งสคริปต์ล็อกออนของ GPO ทางแจกนั้นหายไปก่อนในการโยกย้าย ดังนั้นตัดสินระหว่างนำร่องว่าจะตอบด้วยการโยกย้ายแชร์ไป OneDrive หรือ SharePoint การแทนด้วย Universal Print หรือการแจกสคริปต์ชั่วคราว
    dep["การพึ่งสคริปต์ล็อกออน"] --> lost["ทางแจกหายไปในการโยกย้าย"]
    lost --> share["โยกย้ายไป OneDrive/SharePoint"]
    lost --> print["แทนด้วย Universal Print หรือคล้ายกัน"]
    lost --> script["สะพานด้วยการแจกสคริปต์"]
    share --> decide["ตัดสินแนวทางระหว่างนำร่อง"]
    print --> decide
    script --> decide

ภาพ 17: การแจกที่พึ่งสคริปต์ล็อกออนเสียทางก่อนในการโยกย้าย ดังนั้นตัดสินการแทนระหว่างนำร่อง

8.3. การออกแบบการจัดเตรียมใหม่ — Autopilot ไม่ใช่ “จำเป็น”

บางครั้งคุณจะถูกแนะนำให้นำ Windows Autopilot เข้าเป็นชุดกับการโยกย้าย Intune แต่ ที่ขนาดจัดซื้อไม่กี่ถึงสิบกว่าเครื่องต่อปี การลงชื่อเข้าใช้ด้วยบัญชีงานที่ OOBE แล้ว Entra-join ด้วยมือไม่เสียหายจริง Autopilot เริ่มคุ้มเมื่อจำนวนจัดซื้อโตและการตั้งค่าไม่ต้องดูแลจากแกะกล่องมีค่า หรือเมื่อใช้การลงทะเบียนอุปกรณ์ฝั่งผู้ขายได้ การเพิ่มหลัง (2) และ (3) อยู่แล้วได้ ไม่ใช่ข้อกำหนดของการโยกย้าย

flowchart TB
    accTitle: การตัดสินนำ Autopilot เข้า
    accDescr: ที่ขนาดจัดซื้อไม่กี่ถึงสิบกว่าเครื่องต่อปี การ Entra-join ด้วยมือที่ OOBE ไม่เสียหายจริง เพิ่ม Autopilot ทีหลัง เมื่อจำนวนจัดซื้อโตและการตั้งค่าไม่ต้องดูแลมีค่า
    scale{"ขนาดจัดซื้อรายปีเท่าไหร่"} -->|ไม่กี่ถึงสิบกว่า| manual["Entra join ด้วยมือที่ OOBE"]
    scale -->|เมื่อจำนวนโต| ap["ไม่ต้องดูแลด้วย Autopilot"]
    ap -.-> later["เพิ่มหลัง （2） และ （3） อยู่แล้ว"]

ภาพ 18: ขณะที่ขนาดจัดซื้อเล็ก Entra join ด้วยมือพอ Autopilot เพิ่มทีหลังได้

8.4. ความเข้าใจผิดที่ว่า “ไม่ดีจนกว่าทุกอย่างจะอยู่ใน Intune”

อันสุดท้ายไม่ใช่ปัญหาเทคนิคแต่เป็นปัญหาของข้อสมมติ การอยู่ร่วมของเครื่องที่ Entra-join และเครื่องที่เข้าร่วมโดเมนเป็นการกำหนดค่าที่รองรับอย่างเป็นทางการ² และ “AD ยังอยู่ = การโยกย้ายล้ม” ไม่จริง บริษัทที่รันหลายปีด้วยการตั้งค่าไม่กี่อย่างยังเหลือใน GPO ไม่หายาก และแม้ตอนนั้นก็มีค่ามากในสถานะ “เครื่องใหม่ทุกเครื่องถูกจัดการด้วยคลาวด์ และการควบคุมทำงานนอกสถานที่ด้วย” ชอบการก้าวเล็กที่กลับได้มากกว่าความสวยของการโยกย้ายสมบูรณ์

flowchart TB
    accTitle: ค่าของการรันคู่โดยไม่ยืนกรานการโยกย้ายสมบูรณ์
    accDescr: ที่ AD เหลือไม่ใช่การโยกย้ายล้ม แม้รันคู่หลายปีด้วยการตั้งค่ายังอยู่ใน GPO ก็มีค่ามากในสถานะที่เครื่องใหม่ทุกเครื่องถูกจัดการด้วยคลาวด์และการควบคุมทำงานนอกสถานที่
    miscon["ที่ AD เหลือหมายความว่าการโยกย้ายล้ม?"] -->|ไม่ใช่| run["รันคู่หลายปีด้วย GPO ยังอยู่"]
    run --> value["เครื่องใหม่อยู่ใต้การควบคุมแม้นอกสถานที่"]
    value -.-> forward["ชอบการก้าวเล็ก"]

ภาพ 19: แม้รันคู่ด้วย AD ยังอยู่ สถานะที่เครื่องใหม่ทุกเครื่องถูกจัดการด้วยคลาวด์มีค่ามาก

9. คำตอบสมจริงสำหรับไอทีคนเดียว

สุดท้าย สรุปการออกแบบการดำเนินงานในบริษัทที่ผู้รับผิดชอบคนเดียว (หรือมีบทบาทเป็นงานข้าง)

• แคบรายการจัดการตั้งแต่ต้น หากพยายามนำการตั้งค่ายุค GPO ทุกอย่างเข้า คุณจะหมดแรงที่การทำรายการอย่างเดียว เริ่มจากห้าอย่างในบทที่ 7 (2) (อัปเดต การเข้ารหัส Defender ล็อกจอ LAPS) แล้วทำให้เป็น “การออกแบบลบ” ที่เพิ่มการตั้งค่าเฉพาะเมื่อความต้องการเกิด Settings catalog ให้การตั้งค่านับพัน⁷ แต่คุณไม่มีข้อผูกพันต้องใช้
• ตัดสินภาพเครื่องมาตรฐานหนึ่งภาพ รักษาเฉพาะมาตรฐานหนึ่ง: “เครื่องในบริษัทนี้คือชุดนโยบายนี้และชุดแอปนี้” ข้อยกเว้นของแผนกแสดงด้วยกลุ่มและตัวกรองได้ แต่ยิ่งข้อยกเว้นโต คนเดียวตามไม่ทัน
• ขอคู่ภายนอกสำหรับการออกแบบและการทำเทมเพลต คงการดำเนินงานรายวันในองค์กร การจ้างโยกย้าย Intune ที่ล้มง่ายคือกรณีที่คุณโยนการสร้างข้ามกำแพงแล้วจบในสถานะที่ “ไม่มีใครเข้าใจว่าหน้าจอผู้ดูแลหมายความว่าอะไร” ขอนอกสำหรับการออกแบบเริ่มต้น การทำเทมเพลตนโยบาย และที่ปรึกษาสำหรับการตัดสินโยกย้าย และทำให้เป้าหมายเป็นสถานะที่คุณเพิ่มเครื่องและปรับนโยบายเองได้ในรายวัน พูดอีกทาง คุณควรเลือกคู่ที่จะส่งมอบไกลขนาดนั้น
• เปลี่ยนทีละอย่าง เปลี่ยนนโยบายทีละอย่าง และก้าวต่อเฉพาะหลังยืนยันผลในรายงาน Intune (สถานะการใช้นโยบายและความล้มเหลวของการกำหนด) การซิงค์ MDM อยู่ในรอบประมาณ 8 ชั่วโมง³ และส่วนใหญ่ของ “ยังไม่ใช้” คือเรื่องเวลา ไม่ใช่ความผิด

flowchart TB
    accTitle: รอบการดำเนินงานของการเปลี่ยนนโยบาย
    accDescr: เปลี่ยนนโยบายทีละอย่าง และก้าวไปการเปลี่ยนถัดไปเฉพาะหลังยืนยันสถานะการใช้ในรายงาน Intune กรณีส่วนใหญ่ที่ยังไม่ใช้แก้ด้วยการรอรอบซิงค์ประมาณ 8 ชั่วโมง
    change["เปลี่ยนนโยบายเพียงอย่างเดียว"] --> report["ยืนยันสถานะการใช้ในรายงาน"]
    report --> next["หากไม่มีปัญหา ไปการเปลี่ยนถัดไป"]
    next --> change
    report -.-> wait["ส่วนใหญ่ที่ยังไม่ใช้คือการรอซิงค์"]

ภาพ 20: เปลี่ยนนโยบายทีละอย่าง และก้าวต่อเฉพาะหลังยืนยันผลในรายงาน

10. สรุป

• GPO คือกลไกที่สมมติการถึงตัวควบคุมโดเมน และเชิงโครงไม่ถึงเครื่องนอกสถานที่ Intune (MDM) ซิงค์ผ่านอินเทอร์เน็ต จึงแก้ปัญหานี้ที่ราก
• การโยกย้ายไม่ใช่ทั้งหมดหรือไม่มีเลย เครื่องที่ Entra-join และเครื่องที่เข้าร่วมโดเมนอยู่ร่วมได้ และการโยกย้ายเป็นขั้นที่สลับเครื่องใหม่ไป Entra join บวก Intune คือคำตอบสมจริงสำหรับธุรกิจขนาดกลางและเล็ก ไม่มีเส้นทางแปลงสำหรับเครื่องที่มีอยู่ ดังนั้นการแทนตามรอบเปลี่ยนฮาร์ดแวร์คือรูปแบบที่ยึด
• สำหรับธุรกิจขนาดกลางและเล็ก การเริ่ม Intune ด้วย Microsoft 365 Business Premium (Intune Plan 1 บวก Entra ID P1) สมจริง องค์ประกอบแผนเปลี่ยนเรื่อย ๆ อย่างไรก็ตาม และบางคุณลักษณะอย่าง Remediations ต้องการสิทธิ์สูงกว่า จึงอย่าถือบทความสิงหาคม 2026 นี้เป็นพระคัมภีร์ ยืนยันแหล่งปฐมภูมิ
• การทำรายการ GPO ปัจจุบันอัตโนมัติได้ด้วย Group Policy analytics แปลงการตั้งค่า Ready for migration ไป Settings catalog และแทนสคริปต์ล็อกออนและการแจกเครื่องพิมพ์ที่ไม่มีคู่ด้วยการแจกสคริปต์ การทำให้งานเป็นแอป หรือการหยุดการปฏิบัติ โปรดทราบว่าใน GPO ญี่ปุ่น เปอร์เซ็นต์การรองรับอาจคลาด
• ก้าวการโยกย้ายในห้าขั้น “นำร่อง → นโยบายฐาน → การแจกแอป → การแทนตามธรรมชาติของเครื่องที่มีอยู่ → การหดบทบาทของ AD” และตัดสินเกณฑ์ออกของแต่ละขั้นก่อน
• ความขัดแย้งของการใช้คู่ GPO ชนะโดยค่าเริ่มต้น MDMWinsOverGP คือกลไกเฉพาะ Policy CSP ดังนั้นหลักคือ “อย่าแจกการตั้งค่าเดียวกันจากทั้งสอง”
• เมื่อใบเสนอราคาเปลี่ยนเซิร์ฟเวอร์มาถึงคือเวลาที่ดีที่สุดในการพิจารณาการโยกย้ายนี้ ก่อน “AD อีกรอบ” คิดว่าเครื่องห้าปีถัดไปจะถูกใช้ที่ไหน

บทความที่เกี่ยวข้อง

• คู่มือปฏิบัติ Group Policy (GPO) — ทำงานอย่างไร การยืนยันการใช้ และการเลือกระหว่าง GPO กับ Intune
• การจัดการ Windows Update หลังการเลิก WSUS — วิธีเลือกระหว่าง WUfB, Autopatch และ Intune
• ทางเลือกปฏิบัติหลังสิ้นสุดการสนับสนุน Windows 10 — ตารางตัดสินสำหรับ ESU, LTSC และการแทน
• การจัดเตรียมเครื่องอัตโนมัติด้วย winget + PowerShell — ทำให้สมุดรันบุกปฏิบัติการได้
• คู่มือปฏิบัติ BitLocker — การเข้ารหัสไดรฟ์เริ่มจากการจัดการกุญแจกู้
• คู่มือปฏิบัติ Windows LAPS — การเลิกรหัสผ่านผู้ดูแลท้องถิ่นที่ใช้ร่วมบนทุกเครื่อง

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับการออกแบบการโยกย้ายเป็นขั้นจากสภาพแวดล้อม AD+GPO ไป Entra ID+Intune (การทำรายการ GPO ปัจจุบัน นโยบายการทำซ้ำการตั้งค่า แผนนำร่อง) การตรวจทานเปรียบเทียบการเปลี่ยนเซิร์ฟเวอร์กับการย้ายคลาวด์ และคำปรึกษาที่ใช้แอปธุรกิจที่มีอยู่และสินทรัพย์การจัดเตรียมซ้ำ เริ่มจากการพิจารณาด้วยกันว่า “ควรซื้อเซิร์ฟเวอร์ AD อีกเครื่องไหม” ก็ได้

• ที่ปรึกษาด้านเทคนิคและการตรวจทานการออกแบบ
• การใช้ประโยชน์และโยกย้ายสินทรัพย์ซอฟต์แวร์เดิม
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

หากโยกย้ายจาก GPO ไป Intune จะทำซ้ำการตั้งค่า Group Policy ที่ใช้อยู่ทุกอย่างได้ไหม

ทำซ้ำทั้งหมดไม่ได้ Settings catalog ของ Intune มีการตั้งค่า Windows นับพัน รวมที่มาจาก ADMX และการตั้งค่าความปลอดภัยกับข้อจำกัดส่วนใหญ่ย้ายได้ แต่บางอย่าง — แมปไดรฟ์ผ่านสคริปต์ล็อกออน การแจกเครื่องพิมพ์จำนวนมาก — ไม่มีการตั้งค่า MDM ที่ตรงกัน หากนำเข้าการส่งออก XML ของ GPO ปัจจุบันเข้า Group Policy analytics ของ Intune แต่ละการตั้งค่าถูกจัดเป็น Ready for migration, Not supported หรือ Deprecated สำหรับการตั้งค่าที่ไม่มีคู่ คุณครอบคลุมด้วยการแจกสคริปต์ PowerShell ทำให้งานเป็นแอป หรือแค่หยุดการตั้งค่านั้น

ต้องใช้สิทธิ์ใดเพื่อใช้ Intune

ฐานคือ Microsoft Intune Plan 1 สมัครเดี่ยวได้ แต่ในธุรกิจขนาดกลางและเล็กมักใช้เป็นส่วนของ Microsoft 365 Business Premium (สูงสุด 300 ผู้ใช้) Business Premium รวม Entra ID P1 ด้วย จึงไปได้ถึงการรวมนโยบายความสอดคล้องกับ Conditional Access บางคุณลักษณะอย่าง Remediations ต้องการสิทธิ์ระดับ Windows Enterprise E3/E5 แยก องค์ประกอบแผนเปลี่ยนบ่อย จึงยืนยันรายละเอียดล่าสุดบนหน้าสิทธิ์อย่างเป็นทางการของ Microsoft ก่อนลงนาม (บทความนี้ ณ สิงหาคม 2026)

ต้องเลิกเซิร์ฟเวอร์ AD ทันทีไหม

ไม่ เครื่องที่จัดการด้วย Entra join บวก Intune และเครื่องที่จัดการด้วย AD domain join บวก GPO อยู่ร่วมบนเครือข่ายองค์กรเดียวกันได้ การโยกย้ายเป็นขั้น — คง AD สำหรับการยืนยันตัวตนเซิร์ฟเวอร์ไฟล์และระบบธุรกิจที่มีอยู่ และ Entra-join เฉพาะเครื่องใหม่ — สมจริง ในทางกลับกัน ไม่มีทางที่รองรับในการ "แปลง" เครื่องที่เข้าร่วมโดเมนอยู่แล้วเป็น Entra join ต้องล้าง (รีเซ็ต) ดังนั้นรูปแบบที่ยึดคือแทนเครื่องเดิมตามรอบเปลี่ยนฮาร์ดแวร์ พอพิจารณาเลิก AD หลัง GPO ว่างและคุณทำรายการบทบาทที่เหลือ

ทำไม Group Policy ไม่ใช้กับเครื่องที่ใช้ทำงานระยะไกล

เพราะ GPO ถูกดึงและใช้เมื่อเครื่องถึงตัวควบคุมโดเมนได้ เครื่องนอกสำนักงานรับนโยบายล่าสุดได้เฉพาะเมื่อถึงตัวควบคุมโดเมนผ่าน VPN หรือคล้ายกัน และเครื่องบ้านที่ไม่ใช้ VPN โดยหลักไม่เคยได้ Intune (MDM) ซิงค์นโยบายผ่านอินเทอร์เน็ต จึงจัดการเครื่องได้ทุกที่ ปัญหาการจัดการเครื่องนอกสถานที่ถูกแก้ด้วยโครงของ MDM นอกจากการซิงค์เป็นระยะประมาณทุก 8 ชั่วโมง ยังมีการซิงค์ตามการแจ้งเมื่อนโยบายเปลี่ยน

หากแจกการตั้งค่าเดียวกันจากทั้ง GPO และ Intune อันใดชนะ

โดยค่าเริ่มต้น การตั้งค่าที่ขัดแย้ง Group Policy ชนะ การตั้ง MDMWinsOverGP เป็น 1 ทำให้ฝั่ง MDM (Intune) ชนะ แต่กลไกนั้นใช้เฉพาะการตั้งค่าใต้ Policy CSP ไม่ใช้กับการตั้งค่าที่นิยามใน CSP อื่นอย่าง Defender CSP การพึ่งการควบคุมลำดับความสำคัญทำให้พฤติกรรมคาดยาก ดังนั้นในทางปฏิบัติหลักคือ "อย่าแจกการตั้งค่าเดียวกันจากทั้งสองช่อง" และเมื่อการตั้งค่าย้ายไป Intune แล้ว ให้ลบจาก GPO ต้นทางเพื่อหลีกเลี่ยงการจัดการคู่

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก