Group Policy से Intune — SMEs के लिए device-management migration guide

“Server की support window खत्म है, इसलिए replacement की योजना है। पर विश्वास नहीं रहा कि हमें और एक AD server खरीदकर domain और Group Policy एक और cycle (पाँच वर्ष) चलानी चाहिए।” “Office में तय Group Policy remote work वाले laptops पर कभी apply नहीं होती। यदि केवल VPN connect होने पर apply हो, क्या सच में management कह सकते हैं?” — पिछले कुछ वर्षों में SME customers से इस तरह का परामर्श लगातार बढ़ा है।

पृष्ठभूमि काम करने के तरीके का बदलाव है। On-premises Active Directory (AD) और Group Policy (GPO) वह mechanism है जो मानता है “PC corporate LAN पर है और हमेशा domain controller तक access कर सकता है”। अब जब घर ले जाने वाले PCs और remote work सामान्य हैं, वही assumption टूटी है। उसके ऊपर, WSUS — लंबे समय से update management का default — सितंबर 2024 में deprecated हुआ,¹ और Microsoft के device management का gravity center Entra ID प्लस Intune (MDM) पर चला गया।

flowchart TB
    accTitle: टूटी assumption और gravity center का transfer
    accDescr: AD और GPO मानते हैं PC corporate LAN पर है और हमेशा domain controller तक access कर सकता है, पर घर ले जाने वाले PCs और remote work सामान्य होने से वह assumption टूटी, और WSUS deprecated होने से management का gravity center Entra ID और Intune पर चला गया
    adgpo["On-premises AD और GPO"] -.-> premise["Assumption: DC हमेशा reachable"]
    work["घर ले जाने वाले PCs और remote work सामान्य"] --> broken["Assumption स्वयं टूटी"]
    premise --> broken
    wsus["WSUS deprecated है"] --> shift["Gravity center Entra ID+Intune पर जाता है"]
    broken --> shift

चित्र 1: AD+GPO की assumption “PC corporate LAN पर है” काम करने के तरीके बदलने से टूटी, और management का gravity center Entra ID+Intune पर चला गया।

फिर भी, migration all-or-nothing नहीं है। Entra join प्लस Intune से managed PCs और AD domain-joined प्लस GPO वाले PCs एक ही कंपनी में co-exist रख सकते हैं,² और phased migration संभव है: file server के लिए AD छोड़ें, और नए PCs Intune management पर switch करें। SMEs के IT staff और business owners के लिए, यह लेख — अगस्त 2026 तक Microsoft Learn जैसे primary sources पर आधारित — GPO और MDM के काम करने के अंतर, prerequisite configuration, licensing, current GPO inventory कैसे बनाएँ, phased-migration scenario, और जाल व्यवस्थित करता है।

1. निष्कर्ष पहले

• GPO तब apply होती है जब PC domain network से जुड़ा हो; Intune (MDM) internet पर sync करता है। “Setting घर के PC तक कभी नहीं पहुँचती” की समस्या MDM के साथ structurally नहीं उठती। Steady-state sync लगभग हर 8 घंटे, और policy बदलने पर notification-driven sync भी चलती है।³
• Migration all-or-nothing नहीं; co-existence मानने वाला phased migration यथार्थ उत्तर है। Microsoft स्वयं नए PCs Entra-join करने, और existing domain-joined PCs को hybrid join छोड़कर hardware-refresh cycle पर बदलने की recommendation करता है।²
• Intune अकेले subscribe कर सकते हैं, पर SMEs के लिए यथार्थ path Microsoft 365 Business Premium में शामिल Intune Plan 1 उपयोग करना है (अगस्त 2026 तक)। Plan structure बदलती रहती है, इसलिए हस्ताक्षर से पहले हमेशा primary source confirm करें।⁴⁵
• Current GPO inventory के लिए Intune का built-in Group Policy analytics उपयोग करें। GPO XML export import करें और प्रत्येक setting classified होती है कि migrate हो सकती है या नहीं; जिनका counterpart है वे Settings catalog policy में convert हो सकती हैं।⁶
• GPO युग के मुख्य काम लगभग सभी का Intune counterpart है। Administrative Templates Settings catalog से map होते हैं,⁷ WSUS Windows Update for Business से, BitLocker recovery keys Entra ID में storage से,⁸ local Administrator password Windows LAPS से,⁹ और app deployment Win32 apps (.intunewin)¹⁰ और Microsoft Store apps (winget-based) से।¹¹
• Classic चीज़ें जो ज्यों-की-त्यों नहीं जातीं logon scripts, drive maps, और printer deployment हैं। उन्हें PowerShell script deployment,¹² Remediations (पूर्व Proactive remediations),¹³ काम को app बनाना, या “वह practice रोकना” से बदलें।
• एक ही setting GPO और MDM दोनों से न deploy करें। Default से conflict GPO जीतता है। MDMWinsOverGP 1 करने से MDM जीतता है, पर केवल Policy CSP settings पर लागू होता है।¹⁴
• Domain-joined machines और Entra-joined machines co-exist रख सकती हैं, और Entra-joined machine on-premises file server तक access कर सकती है। AD की तत्काल retirement migration की शर्त नहीं।²

एक वाक्य में: “क्या AD server एक और cycle बदलें” प्रश्न को “अगले पाँच वर्षों, office से बाहर बैठे PC का management किससे करेंगे” में पुनः ढालें और उसी आधार पर तय करें।

flowchart LR
    accTitle: वह प्रश्न पुनः ढालना जिसका decision करना चाहिए
    accDescr: AD server एक और cycle बदलने का प्रश्न अगले पाँच वर्षों off-site PC का management किससे करेंगे के प्रश्न में पुनः ढाला जाना चाहिए
    q1["AD server एक और cycle बदलें?"] -->|पुनः ढालें| q2["अगले 5 वर्षों, off-site PC का management क्या करता है?"]

चित्र 2: Server-replacement प्रश्न को “अगले पाँच वर्षों, office से बाहर बैठे PC का management किससे करेंगे” में पुनः ढालें और उसी आधार पर तय करें।

2. GPO और MDM कैसे भिन्न हैं — apply होने के mechanism की तुलना

पहले दोनों की एक ही मैदान पर तुलना करें। GPO mechanism स्वयं (LSDOU apply क्रम, gpupdate/gpresult से confirm) “Group Policy (GPO) practical guide” में गहराई से cover है, इसलिए यहाँ migration decision के लिए मायने रखने वाले अंतर तक संकीर्ण करते हैं।

Migration decision के लिए सबसे महत्वपूर्ण पंक्तियाँ पहली और तीसरी हैं। घर के PC तक GPO न पहुँचना bug नहीं — यह है कि design assumption “PC वहाँ बैठता है जहाँ domain controller तक access सके” आज के काम करने के तरीके से मेल नहीं खाती। हर employee पर always-on VPN थोपकर GPO जीवित रख सकते हैं, पर वह अलग infrastructure — VPN platform — का maintenance लेने का चुनाव भी है।

flowchart TB
    accTitle: GPO जीवित रखने और MDM पर migrate करने के बीच चुनाव
    accDescr: घर के PC तक GPO न पहुँचना इसलिए है कि design assumption आज के काम करने के तरीके से मेल नहीं खाती, और GPO जीवित रखने के लिए always-on VPN थोपना अलग infrastructure, VPN platform, का maintenance लेने का चुनाव है
    gap["Design assumption काम करने के तरीके से मेल नहीं खाती"] --> sel{"कैसे उत्तर दें?"}
    sel -->|Always-on VPN से जीवित रखें| vpn["GPO जारी रखें"]
    sel -->|MDM पर migrate करें| mdm["Internet पर manage करें"]
    vpn --> cost["आप अन्य infrastructure का maintenance लेते हैं"]

चित्र 3: Always-on VPN से GPO जीवित रखने का path अलग infrastructure, VPN platform, का maintenance लेने का चुनाव भी है।

दूसरी ओर, MDM sync interval (लगभग 8 घंटे) GPO के periodic refresh (लगभग 90 मिनट) से मोटा है, और “deploy करें और तुरंत apply” का अहसास नहीं आता। Policy assign या बदलने पर device को notification जाती है और अपेक्षाकृत शीघ्र sync होता है,³ पर immediacy चाहने वाले controls (emergency block आदि) sync interval के इर्द-गिर्द design करने चाहिए।

flowchart TB
    accTitle: GPO और MDM policy कैसे apply करते हैं
    accDescr: GPO केवल तब apply होता है जब PC in-house domain controller से जुड़ सके, इसलिए घर का PC VPN पर निर्भर है; Intune internet पर लगभग हर 8 घंटे sync करता है और policy बदलने पर notification पर भी sync करता है, इसलिए PC जहाँ भी हो पहुँचता है
    officepc["In-house PC"] --> dc["Domain controller"]
    officepc -.-> when["Startup और sign-in"]
    when -.-> when2["प्लस periodic refresh"]
    homepc["घर का PC"] --> vpn{"VPN से DC तक access?"}
    vpn -->|हाँ| dc
    vpn -->|नहीं| miss["Policy कभी नहीं आती"]
    anypc["PC जहाँ भी हो"] --> intune["Intune service"]
    anypc -.-> every["लगभग हर 8 घंटे sync"]
    intune -.-> notify["Notification-driven change"]
    dc ~~~ homepc
    miss ~~~ anypc

चित्र 4: GPO केवल तब apply होता है जब PC domain controller तक access सके; Intune स्थान की परवाह किए बिना internet पर sync करता है।

3. Prerequisites छाँटना — तीन रूप: Domain Join, Hybrid Join, और Entra Join

“Windows PC कंपनी से कैसे जुड़ता है” के तीन रूप हैं, और कौन चुनें यह तय करता है कौन से management tools उपयोग कर सकते हैं।²

Hybrid join “existing domain-joined PC को cloud identity देने” का रूप है, और existing assets रखते Intune और Conditional Access शुरू करने देता है। Microsoft, पर, hybrid join को final goal न बनाने, और नए व replacement PCs Entra-join करने की recommendation करता है।²

यहाँ एक बाधा ग्रहण करें। Existing domain-joined PC (hybrid join सहित) को Entra join में convert करने का कोई Microsoft-supported तरीका नहीं; Windows reset (wipe) आवश्यक है। इसलिए Microsoft hardware-refresh या OS-restore पर Entra join जाने की भी recommendation करता है।²

flowchart TB
    accTitle: तीन join रूप और migration path
    accDescr: केवल-AD-domain-join PC Entra ID में भी registered होकर hybrid join बन सकता है, पर Entra join में सीधे convert करने का मार्ग नहीं और wipe आवश्यक है, इसलिए नए व replacement PCs Entra-join करना recommended है
    adonly["केवल AD domain join （GPO）"] -->|Entra ID में भी register करें| hybrid["Hybrid join （GPO और Intune）"]
    hybrid -.->|कोई direct conversion path नहीं| wipe["Wipe （reset） आवश्यक है"]
    wipe --> entra["Entra join （Intune）"]
    newpc["नए व replacement PCs"] -->|Recommended| entra

चित्र 5: Existing domain-joined machine को Entra join में convert करने का कोई supported तरीका नहीं; स्थापित pattern नए व replacement PCs से switch करना है।

उपर्युक्त से, SME का यथार्थ target इस प्रकार रखा जा सकता है।

1. नए व replacement PCs Entra join प्लस Intune से manage करें
2. Existing domain-joined PCs छोड़ें और hardware-refresh cycle पर natural replacement होने दें
3. File-server authentication जैसी शेष roles के लिए AD फिलहाल छोड़ें, और GPO की content चरणों में खाली करें

flowchart TB
    accTitle: Phased migration के दौरान co-existence configuration
    accDescr: Entra-joined machines और domain-joined machines एक ही corporate environment में co-exist रख सकती हैं; पूर्व Intune से और उत्तर GPO से managed होती हैं, जबकि शेष roles के लिए AD छोड़ा जाता है और केवल GPO की content चरणों में खाली होती है
    env["एक ही corporate environment"] --> ejoin["Entra-joined machines"]
    env --> djoin["Domain-joined machines"]
    ejoin --> intune["Intune से managed"]
    djoin --> gpo["GPO से managed"]
    gpo -.-> shrink["Content चरणों में खाली करें"]
    env -.-> ad["शेष roles के लिए AD छोड़ें"]

चित्र 6: Entra-joined machines और domain-joined machines एक ही corporate environment में co-exist रख सकती हैं, और शेष roles के लिए AD फिलहाल छोड़ा जाता है।

Entra-joined machines और domain-joined machines एक ही environment में co-exist रख सकती हैं, और Entra-joined machine on-premises file server जैसी in-house assets तक access कर सकती है।² वह single sign-on, पर, दो prerequisites रखता है। (1) User Entra Connect (या Cloud Sync) से on-premises AD से sync hybrid identity है (केवल cloud में मौजूद user AD Kerberos/NTLM credentials नहीं पा सकता), और (2) PC के पास domain controller तक network access है (off-site से VPN या समान आवश्यक)।¹⁵ Migration plan में पहले confirm करें कि इन दो बिंदुओं पर कोई user या usage scenario fail न हो।

flowchart TB
    accTitle: Entra-joined machine से on-premises assets तक SSO की prerequisites
    accDescr: Entra-joined machine से on-premises file server तक access करने के लिए दो prerequisites पूरी हों: Entra Connect या समान से sync hybrid identity, और domain controller तक access
    pc["Entra-joined machine"] --> cond1{"Hybrid identity?"}
    cond1 -->|हाँ| cond2{"DC तक access सकता है?"}
    cond1 -->|नहीं| ng1["AD credentials नहीं पा सकता"]
    cond2 -->|हाँ| ok["File server तक SSO"]
    cond2 -->|नहीं| ng2["Off-site से VPN या समान आवश्यक"]

चित्र 7: Entra-joined machine से on-premises assets तक SSO की दो prerequisites हैं: hybrid identity और domain controller तक access।

4. Licensing और लागत — किन plans में Intune है (अगस्त 2026 तक)

Base Intune license Microsoft Intune Plan 1 है, अकेले subscription और विभिन्न Microsoft 365 plans में bundle दोनों रूप में।⁴

SMEs के लिए मायने यह है कि 300 users तक Microsoft 365 Business Premium में Intune Plan 1 शामिल है।⁵ Business Premium में Microsoft Entra ID P1 और Microsoft Defender for Business भी हैं, इसलिए आगे वर्णित compliance-policy प्लस Conditional Access configuration इस plan के अंदर पूरा हो सकता है। Business Standard/Basic, दूसरी ओर, Intune शामिल नहीं करते। जब केवल mail-and-Office contract से device management में कदम रखें, Business Premium तक upgrade लागत Intune लाने की effective लागत है।

flowchart TB
    accTitle: SME plans Intune से कैसे संबंधित हैं
    accDescr: 300 users तक Business Premium में Intune Plan 1, Entra ID P1, और Defender for Business शामिल हैं और Conditional Access तक पूरा करता है, पर Business Standard/Basic में Intune नहीं
    bp["Business Premium"] -.-> cap["300 users तक"]
    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 नहीं।

दो सावधानियाँ हैं।

• Plan structure बार-बार बदलती है। 2026 में भी, Intune Suite features को उच्च Microsoft 365 plans (E3/E5 आदि) में redistributed करने वाले changes चल रहे हैं, और bundle की review जारी है।⁴ इस खंड को अगस्त 2026 तक मानें, और हस्ताक्षर से पहले Microsoft के licensing और pricing pages पर latest जानकारी हमेशा confirm करें।
• Intune UI से खोली जा सकने वाली कुछ features को अलग license चाहिए। Representative उदाहरण आगे वर्णित Remediations है: Windows Enterprise E3/E5-class license चाहिए (Microsoft 365 E3/E5 आदि में bundle) और Business Premium के दायरे में available नहीं।¹³

लागत तुलना “Intune subscription लागत” बनाम “शून्य” नहीं है। GPO पक्ष पर आप पहले से AD-server hardware replacement, Windows Server licenses और CAL, build लागत, पाँच वर्ष maintenance, backup, और incident response चुका रहे हैं। सही तुलना server-replacement quotation को पाँच वर्ष Business Premium के बगल रखना, फिर “क्या management off-site PC तक पहुँचता है” की capability अंतर जोड़ना है।

flowchart TB
    accTitle: लागत तुलना सोचने का सही तरीका
    accDescr: GPO पक्ष पर भी AD-server replacement, licenses, और पाँच वर्ष maintenance जैसी लागतें आती हैं, इसलिए server-replacement quotation को पाँच वर्ष Business Premium के बगल रखें और फिर तय करें कि management off-site PC तक पहुँचता है या नहीं की capability अंतर जोड़कर
    gpocost["GPO जारी रखने की लागत"] --> hw["Server replacement, licenses, CAL"]
    gpocost --> ops["Build, maintenance, backup"]
    bpcost["Intune पर migrate करने की लागत"] --> sub["पाँच वर्ष Business Premium"]
    hw --> diff["पाँच-वर्ष अंतर साथ रखें"]
    ops --> diff
    sub --> diff
    diff --> ability["जोड़े कि management off-site PC तक पहुँचता है या नहीं"]

चित्र 9: Server-replacement quotation को पाँच वर्ष Business Premium के बगल रखें, और off-site PC management की capability अंतर जोड़कर तय करें।

5. GPO से जो करते थे वह Intune में कैसे करें

GPO operations के प्रत्येक मुख्य काम का Intune counterpart mapping table में दिखाया है।

कुछ notes।

• Settings catalog “GPO editor का cloud version” से मेल खाने वाली screen है, और Microsoft स्वयं इसे “जब on-premises GPO जैसी बारीकी से configure करना चाहें तो natural migration destination” रखता है। इसमें ADMX-supported policies हैं (ADMX में defined setting का MDM version), और third-party ADMX import करने की (preview) feature भी है।⁷
• Compliance policy प्लस Conditional Access वह विचार है जो GPO के पास नहीं था। आप “BitLocker चालू, OS current, Defender चल रहा” जैसी compliance शर्तें define करते हैं और उन्हें न पूरा करने वाले device से Microsoft 365 access block कर सकते हैं। Conditional Access Entra ID P1 feature है और Business Premium में शामिल है।¹⁶
• Remediations का नाम Proactive remediations से बदला गया। यह mechanism periodic रूप से detect-script प्लस remediate-script जोड़ी चलाता है, और “हर logon पर कुछ ठीक करें” प्रकार के GPO operations बदल सकता है, पर जैसा कहा Windows Enterprise E3/E5-class license चाहिए।¹³ Business Premium के दायरे में यथार्थ विकल्प platform scripts (script या assignment बदलने पर चलते हैं, और failure पर retry)¹² को Win32-app detection rules से जोड़ना है।
• Update management के विस्तृत चुनाव (WUfB, Autopatch, और WSUS जारी रखने में decision) “WSUS deprecation के बाद Windows Update management” में, और BitLocker व LAPS का design “BitLocker practical guide” और “Windows LAPS practical guide” में क्रमशः cover हैं।

flowchart TB
    accTitle: Compliance policy और Conditional Access का प्रवाह
    accDescr: Compliance policy केवल device की compliance state compliance शर्तों के विरुद्ध तय करती है; केवल जब Conditional Access policy compliant device माँगे compliant device अनुमति और non-compliant block होते हैं
    policy["Compliance शर्तें define करें"] -.-> cond["BitLocker चालू, OS current आदि"]
    policy --> state["Device की compliance state तय करें"]
    state --> ca["Conditional Access compliance माँगता है"]
    ca -->|Compliant| allow["Microsoft 365 access अनुमति"]
    ca -->|Non-compliant| block["Access block"]

चित्र 10: Compliance state तय करना compliance policy का काम है; block Conditional Access का। केवल combination में block प्रभावी होता है।

6. Current GPO inventory — Group Policy Analytics से छाँटना

Migration plan का पहला वास्तविक काम current GPO inventory बनाना है। Intune की dedicated feature Group Policy analytics प्रति setting classify कर सकती है “क्या MDM इसे बदल सकता है” बिना GPO हाथ से पढ़े।⁶

चरण निम्न हैं।⁶

1. Domain controller या समान पर Group Policy Management Console (GPMC.msc) खोलें, target GPO पर right-click → Save Report और XML file के रूप में export करें (प्रति file 4 MB या कम)
2. Intune admin center में Devices → Group Policy analytics जाएँ और XML import करें (multiple selection अनुमत)
3. Automatic analysis के बाद प्रत्येक GPO MDM support percentage दिखाता है (Intune में equivalent वाली settings का हिस्सा)
4. Group policy migration readiness report में per-setting classification confirm करें: Ready for migration / Not supported / Deprecated
5. Ready for migration settings ज्यों-की-त्यों Settings catalog policy में convert कर deploy की जा सकती हैं

flowchart TB
    accTitle: Group Policy analytics से inventory प्रवाह
    accDescr: GPMC से GPO XML के रूप में export कर Intune में import करें; MDM support percentage और per-setting migration readiness दिखाई जाती है, और Ready for migration settings Settings catalog policy में convert हो सकती हैं
    export["GPMC से GPO XML export"] --> import["Intune में import"]
    import --> rate["MDM support percentage दिखाया जाता है"]
    rate --> report["Migration readiness report"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["Settings catalog policy में convert करें"]

चित्र 11: XML export से import, per-setting classification, और Settings catalog में conversion — वही Group Policy analytics प्रवाह है।

Japanese environment में महत्वपूर्ण सावधानी है। Group Policy analytics में non-ADMX settings का analysis केवल English है; English से भिन्न भाषा की settings वाला GPO import करने से MDM support percentage गलत हो सकता है।⁶ Support percentage को मोटा संदर्भ मानें, और final decision per-setting list से लें।

flowchart TB
    accTitle: Japanese GPO analysis करते समय सावधानी
    accDescr: Group Policy analytics में non-ADMX settings का analysis केवल English है, इसलिए Japanese settings वाले GPO से MDM support percentage गलत हो सकता है; percentage को मोटा संदर्भ मानें और final decision per-setting list से लें
    jgpo["Japanese settings वाला GPO"] --> limit["Non-ADMX analysis केवल English"]
    limit --> rate["Support percentage गलत हो सकता है"]
    rate --> use1["Percentage को मोटा संदर्भ मानें"]
    rate --> use2["Final decision per-setting list से लें"]

चित्र 12: Japanese GPO में MDM support percentage गलत हो सकता है, इसलिए final decision per-setting list से लें।

Practice में, classification results तीन ढेरों में बाँटें।

1. त्यागने योग्य settings — Internet Explorer-era settings, retired systems की settings, जिनका कारण कोई नहीं समझा सकता। Inventory का सबसे बड़ा लाभ वास्तव में यह ढेर फेंक पाना है। दस वर्ष चली GPO में काफी legacy जमा होती है।
2. Intune में ले जाने योग्य settings — Ready for migration में से वे जो अभी चाहिए। Settings catalog में convert कर pilot group से validate करें।
3. जिनके लिए विकल्प design करें — Not supported में से वे जो अभी चाहिए। Representative उदाहरण और विकल्प दिशा निम्न हैं।

flowchart TB
    accTitle: Inventory results के तीन ढेर
    accDescr: Inventory results तीन ढेरों के रूप में सँभाले जाते हैं: त्यागने योग्य settings, Intune में ले जाकर validate करने योग्य, और जिनका counterpart नहीं जिनके लिए विकल्प design करें
    result["Classification results"] --> discard["त्यागने योग्य settings"]
    result --> more{"ले जाएँ या विकल्प?"}
    more --> move["Intune में ले जाएँ"]
    more --> alt["विकल्प design करें"]
    discard -.-> legacy["Legacy निपटाएँ"]
    move --> pilot["Settings catalog"]
    pilot -.-> pilotN["फिर validate करें"]
    alt --> design["Scripts या app बनाएँ"]

चित्र 13: Inventory results तीन ढेरों “त्यागें”, “Intune में ले जाएँ”, और “विकल्प design करें” में बाँटें।

7. Phased migration scenario — पाँच चरण और exit criteria

पूरे को पाँच चरणों में बाँटें और प्रत्येक पर exit criteria रखें। पहले तय करना “कब कह सकते हैं यह हो गया” वह चाल है जो एक-व्यक्ति IT migration को अटकने से बचाती है।

flowchart TB
    accTitle: पाँच-चरण migration scenario
    accDescr: Pilot से baseline policy, app deployment, existing PCs का hardware-refresh cycle पर replacement, और AD की भूमिका सिकोड़ने तक चरणों में आगे बढ़ें, और अंत में GPO से deployed settings शून्य करें
    s1["（1） Pilot"] --> s2["（2） Baseline policy"]
    s2 --> s3["（3） App deployment"]
    s3 --> s4["（4） Existing PCs का natural replacement"]
    s4 --> s5["（5） AD की भूमिका सिकोड़ना"]
    s5 -.-> goal["GPO से deployed settings शून्य"]

चित्र 14: Pilot से AD की भूमिका सिकोड़ने तक पाँच चरणों में migration आगे बढ़ाएँ, और प्रत्येक चरण का exit criteria पहले तय करें।

प्रत्येक चरण के मुख्य बिंदु।

• (1) Pilot उस PC से शुरू होता है जिसे वैसे भी खरीदने वाले थे — अगला नए-hire PC, break/repair replacement आदि। नई machine से शुरू करने का लाभ शून्य extra investment से शुरू करना है, और fail हो तो wipe कर फिर शुरू कर सकते हैं। गिनती बढ़े तो Windows Autopilot से OOBE (initial setup) से Entra join प्लस Intune enrolment तक automatic करने पर विचार करें।²
• (2) Baseline policy में हर GPO setting reproduce करने का लक्ष्य न रखें। पहले updates, encryption, Defender, screen lock, और LAPS पाँच तक संकीर्ण करें, और compliance policy से compliance state दृश्य करें। Conditional Access में “केवल compliant devices” enable करना pilot में कोई false-positive न होने की पुष्टि के बाद आता है।¹⁶
• (3) App deployment provisioning automatic करने से सतत है। यदि पहले से winget-based process हो (“winget + PowerShell से PC provisioning automatic करना”), वह asset लगभग ज्यों-की-त्यों Store app (नया) या Win32-app wrapper के रूप में reuse हो सकती है।¹¹
• (4) Existing PCs, अध्याय 3 के अनुसार, Entra join का conversion path नहीं रखते, इसलिए सिद्धांत natural replacement है। जिन संगठनों के पास अभी Windows 10 replacement plan है (“Windows 10 support समाप्ति के बाद practical विकल्प”) वह replacement (4) के साथ आगे बढ़ाकर काम दो बार करने से बच सकते हैं।
• (5) AD की भूमिका सिकोड़ना में GPO खाली करना आवश्यकतः तुरंत AD अनावश्यक नहीं बनाता। यदि file-server authentication, legacy app से LDAP search आदि रहें, AD “authentication server” के रूप में संकुचित रूप में जारी रहता है। उनका inventory बनाना और timeline तय करना इस चरण का काम है।

flowchart TB
    accTitle: GPO खाली होने के बाद AD का क्या करें
    accDescr: GPO खाली होने के बाद भी, यदि file-server authentication या legacy app से LDAP search रहें, AD authentication server के रूप में संकुचित रूप में जारी रहता है, और शेष roles की list व timeline तय करना अंतिम चरण का काम है
    gpoempty["GPO खाली है"] --> remain{"कौन सी शेष roles हैं?"}
    remain -->|File-server authentication| keep["Authentication server के रूप में संकुचित रूप में जारी रखें"]
    remain -->|Legacy LDAP search| keep
    remain -->|कोई शेष role नहीं| retire["AD स्वयं retire करने पर विचार करें"]
    keep --> task["Inventory और timeline तय करना पूरा करें"]

चित्र 15: GPO खाली होने के बाद भी, यदि शेष roles हों, AD authentication server के रूप में संकुचित रूप में जारी रहता है।

8. जाल

8.1. GPO और MDM का dual apply — default से GPO जीतता है

Migration अवधि में GPO और Intune दोनों एक ही PC (hybrid-joined machine) पर settings deploy करेंगे। यहाँ, जब वही setting conflict करे, default से Group Policy जीतती है। Policy CSP का MDMWinsOverGP 1 करने से MDM-side setting जीतती है और matching GPO setting block होती है, पर वह mechanism केवल Policy CSP के अंतर्गत settings पर लागू होता है और Defender CSP जैसी अन्य CSPs में defined settings पर नहीं। Microsoft स्वयं कहता है कि MDMWinsOverGP के अंतर्गत न आने वाली settings GPO और MDM दोनों से configure करें तो conflict state में जाते हैं और कौन जीतेगा इसकी guarantee नहीं।¹⁴

flowchart TB
    accTitle: GPO और MDM conflict पर precedence
    accDescr: यदि वही setting GPO और MDM दोनों से deploy करें, default से GPO जीतता है; MDMWinsOverGP 1 करने से केवल Policy CSP के अंतर्गत settings पर MDM जीतता है, और अन्य CSPs की settings पर कौन जीतेगा इसकी guarantee नहीं
    both["वही setting GPO और MDM दोनों से deploy करें"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|नहीं| gpowin["GPO जीतता है （default）"]
    flag -->|हाँ| csp{"Policy CSP के अंतर्गत setting?"}
    csp -->|हाँ| mdmwin["MDM जीतता है"]
    csp -->|नहीं| unknown["कौन जीतेगा इसकी guarantee नहीं"]
    both -.-> avoid["Principle दोनों से न deploy करना है"]

चित्र 16: Default से GPO जीतता है, और MDMWinsOverGP केवल Policy CSP के अंतर्गत लागू होता है। Principle dual deployment टालना है।

व्यावहारिक principle सरल है। Precedence control पर भरोसा न करें; वही setting दोनों से न deploy करें। Intune में ले जाई setting के लिए matching GPO-side configuration “Not configured” पर लौटाएँ, या GPO पूरी तरह unlink करें। अध्याय 6 की migrate list इसी का खाता भी है।

8.2. On-premises assets पर dependency — network drives और printers

Migration जहाँ अटकता है उनमें से कई Intune features नहीं बल्कि on-premises assets से connectivity हैं। Entra-joined machine से on-premises file server तक access स्वयं संभव है,² पर यदि drive maps और printer deployment GPO logon scripts पर निर्भर थे, वह deployment means पहले गायब होता है। Pilot के दौरान तय करें कि share migration OneDrive/SharePoint पर या Universal Print से replacement चरण (3) में मोड़ें, या फिलहाल script deployment से पुल बाँधें।¹²

flowchart TB
    accTitle: On-premises assets पर निर्भर deployment बदलना
    accDescr: यदि drive maps और printer deployment GPO logon scripts पर निर्भर हों, वह deployment means migration में पहले गायब होता है, इसलिए pilot के दौरान तय करें कि OneDrive या SharePoint पर share migration, Universal Print से replacement, या फिलहाल script deployment से उत्तर दें
    dep["Logon scripts पर dependency"] --> lost["Deployment means migration में गायब होता है"]
    lost --> share["OneDrive/SharePoint पर migrate करें"]
    lost --> print["Universal Print या समान से बदलें"]
    lost --> script["Script deployment से पुल बाँधें"]
    share --> decide["Pilot के दौरान दृष्टिकोण तय करें"]
    print --> decide
    script --> decide

चित्र 17: Logon scripts पर निर्भर deployment migration में means पहले खोते हैं, इसलिए pilot के दौरान replacement तय करें।

8.3. Provisioning पुनः design — Autopilot “आवश्यक” नहीं

कभी Intune migration के साथ Windows Autopilot set में लाने की सलाह मिलेगी, पर वर्ष में कुछ से एक दर्जन machines के खरीद पैमाने पर, OOBE पर work account से sign in कर हाथ से Entra-join करने में कोई वास्तविक हानि नहीं। Autopilot तब लाभ देने लगता है जब खरीद गिनती बढ़े और unboxing से unattended setup मूल्य रखे, या reseller पक्ष पर device registration उपयोग हो सके। (2) और (3) जगह पर होने के बाद जोड़ना ठीक है; यह migration की prerequisite नहीं।

flowchart TB
    accTitle: Autopilot introduction decision
    accDescr: वर्ष में कुछ से एक दर्जन machines के खरीद पैमाने पर, OOBE पर हाथ से Entra-join करने में कोई वास्तविक हानि नहीं; Autopilot बाद में जोड़ें, जब खरीद गिनती बढ़े और unattended setup मूल्य रखे
    scale{"वार्षिक खरीद पैमाना क्या है?"} -->|कुछ से एक दर्जन| manual["OOBE पर manual Entra join"]
    scale -->|गिनती बढ़े| ap["Autopilot से unattended"]
    ap -.-> later["（2） और （3） जगह पर होने के बाद जोड़ें"]

चित्र 18: जब खरीद पैमाना छोटा हो, manual Entra join पर्याप्त है; Autopilot बाद में जोड़ा जा सकता है।

8.4. यह भ्रम कि “तब तक अच्छा नहीं जब तक सब Intune में न हो”

अंतिम technical समस्या नहीं बल्कि assumption की है। Entra-joined machines और domain-joined machines का co-existence औपचारिक रूप से supported configuration है,² और “AD अभी है = migration fail” सत्य नहीं। वे कंपनियाँ जो वर्षों GPO में कुछ settings छोड़कर चलती हैं दुर्लभ नहीं, और तब भी “हर नया PC cloud-managed है, और control off-site भी काम करता है” अवस्था का बड़ा मूल्य है। पूर्ण migration की सुंदरता से छोटे, reversible अग्रिम पसंद करें।

flowchart TB
    accTitle: पूर्ण migration पर ज़ोर दिए बिना parallel चलाने का मूल्य
    accDescr: AD रहना failed migration नहीं; GPO में settings रहते वर्षों parallel चलाने पर भी हर नया PC cloud-managed होने और control off-site काम करने की अवस्था का बड़ा मूल्य है
    miscon["AD रहना मतलब migration fail?"] -->|नहीं| run["GPO रहते वर्षों parallel चलाएँ"]
    run --> value["नए PCs off-site भी control में"]
    value -.-> forward["छोटे अग्रिम पसंद करें"]

चित्र 19: AD रहते parallel चलाने पर भी, हर नया PC cloud-managed होने की अवस्था का बड़ा मूल्य है।

9. एक-व्यक्ति IT का यथार्थ उत्तर

अंत में, उस कंपनी में operational design का सारांश जहाँ जिम्मेदार व्यक्ति एक है (या भूमिका side job है)।

• Management मद शुरू से संकीर्ण करें। यदि हर GPO-era setting लाने का प्रयास करें, केवल inventory पर थक जाएँगे। अध्याय 7 (2) के पाँच (updates, encryption, Defender, screen lock, LAPS) से शुरू करें और “subtraction design” बनाएँ जो settings केवल आवश्यकता उठने पर जोड़ता है। Settings catalog हज़ारों settings देता है,⁷ पर उपयोग करने की बाध्यता नहीं।
• एक standard PC image तय करें। केवल एक standard रखें: “इस कंपनी में PC policies का यह set और apps का यह set है”। विभागीय exceptions groups और filters से व्यक्त हो सकते हैं, पर exceptions जितने बढ़ें, एक व्यक्ति उतना कम साथ रख सकता है।
• Design और templates बनाने के लिए बाहरी partner से पूछें; दिन-प्रतिदिन operations in-house रखें। आसानी fail होने वाला Intune-migration outsourcing वह मामला है जहाँ build दीवार के पार फेंकें और “admin screen का अर्थ कोई नहीं समझता” अवस्था में पहुँचें। बाहर से initial design, policies का templating, और migration decisions के लिए sounding-board माँगें, और target वह अवस्था बनाएँ जहाँ दिन-प्रतिदिन स्वयं PCs जोड़ और policy tweak कर सकें। दूसरी तरह, ऐसा partner चुनें जो इतना दूर सौंपे।
• एक समय एक चीज़ बदलें। Policy changes एक समय एक करें, और Intune reports (policy apply state और assignment failures) में परिणाम confirm करने के बाद ही आगे बढ़ें। MDM sync लगभग-8-घंटे cycle पर है,³ और अधिकांश “apply नहीं हुआ” समय की बात है, दोष की नहीं।

flowchart TB
    accTitle: Policy change का operational cycle
    accDescr: Policy changes एक समय एक करें, और Intune reports में apply state confirm करने के बाद ही अगले change पर जाएँ। अधिकांश non-apply मामले लगभग 8-घंटे sync cycle की प्रतीक्षा से हल होते हैं
    change["केवल एक policy change करें"] --> report["Report में apply state confirm करें"]
    report --> next["यदि कोई समस्या नहीं, अगले change पर"]
    next --> change
    report -.-> wait["अधिकांश non-apply sync की प्रतीक्षा है"]

चित्र 20: Policy changes एक समय एक करें, और reports में परिणाम confirm करने के बाद ही आगे बढ़ें।

10. सारांश

• GPO वह mechanism है जो domain controller तक access मानता है, और structurally off-site PC तक नहीं पहुँचता। Intune (MDM) internet पर sync करता है, इसलिए इस समस्या को जड़ से हल करता है।
• Migration all-or-nothing नहीं। Entra-joined machines और domain-joined machines co-exist रख सकती हैं, और नए PCs को Entra join प्लस Intune पर switch करने वाला phased migration SMEs का यथार्थ उत्तर है। Existing machines का conversion path नहीं, इसलिए hardware-refresh cycle पर replacement स्थापित pattern है।
• SMEs के लिए Microsoft 365 Business Premium (Intune Plan 1 प्लस Entra ID P1) से Intune शुरू करना यथार्थ है। Plan structure बदलती रहती है, पर, और Remediations जैसी कुछ features उच्च license चाहती हैं, इसलिए इस अगस्त 2026 लेख को gospel न मानें; primary source confirm करें।
• Current GPO की inventory Group Policy analytics से automatic हो सकती है। Ready for migration settings Settings catalog में convert करें, और जिनका counterpart नहीं logon scripts व printer deployment को script deployment, काम को app बनाना, या practice रोकना से बदलें। ध्यान दें कि Japanese GPO में support percentage गलत हो सकता है।
• Migration पाँच चरणों “pilot → baseline policy → app deployment → existing PCs का natural replacement → AD की भूमिका सिकोड़ना” में आगे बढ़ाएँ, और प्रत्येक चरण का exit criteria पहले तय करें।
• Dual-apply conflict default से GPO जीतता है। MDMWinsOverGP केवल-Policy-CSP mechanism है, इसलिए principle “वही setting दोनों से न deploy करें” है।
• जब server-replacement quotation आए वही इस migration पर विचार करने का सर्वोत्तम समय है। “AD का एक और cycle” से पहले सोचें अगले पाँच वर्षों PCs कहाँ उपयोग होंगे।

संबंधित लेख

• Group Policy (GPO) practical guide — कैसे काम करती है, apply confirm, और GPO व Intune के बीच चुनाव
• WSUS deprecation के बाद Windows Update management — WUfB, Autopatch, और Intune में कैसे चुनें
• Windows 10 support समाप्ति के बाद practical विकल्प — ESU, LTSC, और replacement की decision table
• winget + PowerShell से PC provisioning automatic करना — runbook को executable बनाना
• BitLocker practical guide — recovery key management से शुरू drive encryption
• Windows LAPS practical guide — सभी PCs पर shared local Administrator password retire करना

संबंधित परामर्श क्षेत्र

KomuraSoft LLC AD+GPO environment से Entra ID+Intune तक phased migration का design (current GPO inventory, settings reproduce करने की policy, pilot plan), server replacement बनाम cloud transfer की comparative review, और existing line-of-business apps व provisioning assets reuse करने वाले परामर्श सँभालता है। साथ सोचने से शुरू करना “क्या और एक AD server खरीदें” ठीक है।

• Technical consulting और design review
• Existing assets का reuse और migration
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

यदि GPO से Intune migrate करें, क्या आज उपयोग की हर Group Policy setting reproduce हो सकती है?

सभी नहीं। Intune Settings catalog में ADMX से आने वाली सहित हज़ारों Windows settings हैं, और अधिकांश security settings व restrictions transfer हो सकते हैं, पर कुछ चीज़ें — logon script से drive map, bulk printer deployment — की कोई matching MDM setting नहीं। Current GPO का XML export Intune के Group Policy analytics में import करें तो प्रत्येक setting Ready for migration, Not supported, या Deprecated classified होती है। जिन settings का counterpart नहीं, उन्हें PowerShell script deployment, काम को app बनाना, या वह setting रोकना से cover करें।

Intune उपयोग के लिए कौन सा license चाहिए?

Base Microsoft Intune Plan 1 है। अकेले subscribe कर सकते हैं, पर SMEs में Microsoft 365 Business Premium (300 users तक) के भाग के रूप में उपयोग आम है। Business Premium में Entra ID P1 भी है, इसलिए compliance policies को Conditional Access से जोड़ने तक जा सकते हैं। Remediations जैसी कुछ features को अलग से Windows Enterprise E3/E5-class license चाहिए। Plan structure बार-बार बदलती है, इसलिए हस्ताक्षर से पहले Microsoft के official licensing pages पर latest details confirm करें (यह लेख अगस्त 2026 का है)।

क्या AD server तुरंत retire करना होगा?

नहीं। Entra join प्लस Intune से managed PCs और AD domain join प्लस GPO से managed PCs एक ही corporate network पर co-exist रख सकते हैं। Phased migration — file-server authentication और existing line-of-business systems के लिए AD छोड़ना, और केवल नए PCs Entra-join करना — यथार्थ है। उलटा, existing domain-joined PCs को Entra join में "convert" करने का कोई supported तरीका नहीं; wipe (reset) आवश्यक है, इसलिए स्थापित pattern hardware-refresh cycle पर existing machines बदलना है। GPO खाली होने और शेष roles list करने के बाद AD retirement सोचना पर्याप्त है।

Remote work वाले PCs पर Group Policy क्यों apply नहीं होती?

क्योंकि GPO तब प्राप्त और apply होती है जब PC domain controller तक access सके। Office से बाहर PC latest policy तभी पाता है जब VPN या समान से domain controller तक पहुँचे, और बिना VPN वाला घर का PC मूलतः कभी नहीं पाता। Intune (MDM) internet पर policy sync करता है, इसलिए PC जहाँ भी हो manage कर सकते हैं; off-site PC management की समस्या MDM की structure से हल होती है। लगभग हर 8 घंटे की periodic sync के अतिरिक्त, policy बदलने पर notification-driven sync भी चलती है।

यदि वही setting GPO और Intune दोनों से deploy करें, कौन जीतता है?

Default से, conflicted setting Group Policy जीतती है। MDMWinsOverGP policy 1 करने से MDM (Intune) पक्ष जीतता है, पर वह mechanism केवल Policy CSP के अंतर्गत settings पर लागू होता है; Defender CSP जैसी अन्य CSPs में defined settings पर नहीं। Precedence control पर भरोसा व्यवहार unexpected बनाता है, इसलिए practice में principle "दोनों channels से वही setting न deploy करें" है, और setting Intune में जाने के बाद original GPO से हटाकर dual management टालें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।