Group Policy (GPO) की practical guide — कैसे काम करती है, apply की पुष्टि, और GPO व Intune के बीच चुनाव

«यह setting GPO से distribute है», «ग्राहक के PC Group Policy से बाँधे गए हैं» — Windows business systems से जुड़े कोई भी व्यक्ति «GPO» शब्द रोज़ सुनता है। पर जब स्वयं AD administration सँभालना हो, या ग्राहक स्थल के domain-joined PC पर app deploy करना हो, Group Policy कब, कहाँ से, और किस priority क्रम में apply होती है सटीक समझा सकने वाले अप्रत्याशित रूप से कम हैं।

«Setting बदली, पर apply नहीं हुई», «gpupdate चलाने को कहा गया पर वास्तव में क्या होता है नहीं पता», «Dev machine पर app चलता है ग्राहक पर नहीं, और निकला GPO था» — यह लेख इन स्थितियों से टकराने वाले business-app developers और AD administration विरासत में लेने वाले छोटे-मध्यम business के IT staff के लिए है। यह Group Policy कैसे काम करती है (LSDOU apply order), कब effective होती है, gpresult और event log से diagnostics, ADMX और Central Store, और GPO बनाम Intune (MDM) का चुनाव, August 2026 तक के primary sources पर आधारित व्यवस्थित करता है।

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

• Group Policy «बाद वाला जीतता है» है। यह local → site → domain → OU (LSDOU) क्रम में process होती है, और conflict में बाद में process हुई GPO priority लेती है। Local GPO (gpedit.msc) सबसे कमज़ोर परत है।¹
• Apply होने का समय «foreground प्लस background» है। Computer Configuration हमेशा startup पर और User Configuration हमेशा sign-in पर apply होती है; उसके ऊपर default से background refresh लगभग हर 90 मिनट प्लस 0–30 मिनट का random offset है (domain controllers पर 5 मिनट)।²
• gpupdate /force «हर setting फिर apply» है — रामबाण नहीं। Software install और folder redirect जैसी कुछ settings केवल sign-in या reboot पर process होती हैं (यही /logoff और /boot options का अस्तित्व है)।³
• Diagnostics का starting point gpresult /h की RSoP report है। Applied GPOs और Denied GPOs कारण सहित दिखती हैं। गहराई के लिए GroupPolicy Operational log (Microsoft-Windows-GroupPolicy/Operational) उपयोग करें।⁴⁵
• नियम के रूप में Administrative Template policies registry की dedicated policy keys (Software\Policies आदि) में लिखी जाती हैं। Policy value app की अपनी setting से priority लेता है, और Not Configured कुछ भी नहीं लिखता। फिर भी कुछ policies dedicated keys के बाहर लिखती हैं (अध्याय 5)।⁶
• ADMX Central Store SYSVOL में PolicyDefinitions folder है। बना देने पर GPMC domain-व्यापी template definitions वहीं से reference करने लगता है।⁷
• GPO या Intune device की identity नींव से चुनें। वही setting दोनों में configure करने से परिणाम की गारंटी नहीं। Migration सोचते समय Group Policy analytics मदद करता है।⁸⁹
• Developers के लिए GPO «केवल ग्राहक स्थल पर नहीं चलता» का classic कारण है। Execution policy, firewall local rules merge disabled, proxy और drive configuration जैसी settings — जो app की assumptions बदल देती हैं — central management से distribute होती हैं।¹⁰¹¹

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 29, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. Group Policy क्या है — Local GPO और domain GPO

Group Policy वह mechanism है जिससे admin Windows settings केंद्र में define कर target computers और users पर force करता है। Settings के bundle को GPO (Group Policy Object) कहते हैं। GPO दो स्थानों में रह सकती है।

Workgroup (non-domain-joined) PC केवल local GPO process करता है।¹ इसलिए व्यवहार में जब लोग कहते हैं machine «GPO से managed» है, लगभग हमेशा domain GPO अभिप्रेत होती है।

flowchart TB
    accTitle: Workgroup PC और domain-joined PC जो GPO process करते हैं
    accDescr: Workgroup PC केवल local GPO process करता है, और domain-joined PC local GPO के साथ Active Directory से distribute domain GPO भी process करता है
    pc{"PC की membership कैसी है?"}
    pc -->|Workgroup| wg["केवल local GPO process"]
    pc -->|Domain join| dom["Local+domain GPO"]
    dom -.-> note["व्यवहार में GPO लगभग domain GPO"]

चित्र 1: Workgroup PC केवल local GPO process करता है, और domain-joined PC domain GPO भी process करता है।

चाहे जो GPO हो, उसकी सामग्री मोटे तौर पर दो categories में पड़ती है।

• Computer Configuration: Settings जो उस PC पर sign-in करने वाले किसी भी व्यक्ति पर apply होती हैं। Startup पर apply।
• User Configuration: Settings जो उस user पर apply होती हैं चाहे वह किसी भी PC पर sign-in करे। Sign-in पर apply।

यह अक्ष — «setting PC से बँधी है या व्यक्ति से» — आगे apply order और apply की पुष्टि दोनों में लगातार आता है। कुछ items दोनों configurations में मौजूद होते हैं, इसलिए setting खोजते समय हमेशा दोनों शाखाएँ देखने की आदत डालें।

flowchart TB
    accTitle: GPO की सामग्री की दो categories
    accDescr: हर GPO में Computer Configuration और User Configuration दो categories हैं; Computer Configuration startup पर apply होकर उस PC पर sign-in करने वाले किसी पर भी चलती है, और User Configuration sign-in पर apply होकर उस user के किसी भी PC पर चलती है
    gpo["GPO की सामग्री"] --> comp["Computer Configuration"]
    gpo --> user["User Configuration"]
    comp --> boot["Startup पर apply"]
    user --> logon["Sign-in पर apply"]
    boot -.-> anyone["Sign-in करने वाले किसी पर"]
    logon -.-> anypc["किसी भी PC पर apply"]

चित्र 2: GPO में PC से बँधी Computer Configuration और व्यक्ति से बँधी User Configuration दो categories हैं।

3. Apply होने की संरचना — LSDOU का «बाद वाला जीतता है» और inheritance control

3.1. LSDOU: local → site → domain → OU

Domain-joined PC पर GPO निम्नलिखित क्रम में process होती हैं।¹

1. Local GPO
2. Site से link GPO
3. Domain से link GPO
4. OU (organizational unit) से link GPO — top-level OU से नीचे process, target computer/user के सीधे OU की GPO अंतिम

आद्यक्षर लेकर इस क्रम का नाम LSDOU है। मुख्य बात यह है कि यह «सबसे ऊँची priority पहले» नहीं, बल्कि processing का क्रम है। जब कई GPO वही setting configure करें, बाद में process हुई जीतती है (जो settings conflict नहीं करतीं बस जुड़ जाती हैं)।¹ अर्थात target के सबसे निकट OU की GPO सबसे मज़बूत है, और local GPO सबसे कमज़ोर। «gpedit.msc में ठीक किया और वापस हो गया» खराबी नहीं — यही specification ठीक वैसे काम कर रहा है।

flowchart TB
    accTitle: LSDOU processing क्रम और बाद वाला जीतता है
    accDescr: GPO local, site, domain, OU क्रम में process होती हैं, और conflict में बाद में process हुई GPO जीतती है, इसलिए target के निकट OU की GPO सबसे मज़बूत और local GPO सबसे कमज़ोर है
    l["1. Local GPO"] --> s["2. Site"]
    s --> d["3. Domain"]
    d --> ou["4. OU（ऊपर से क्रम में）"]
    ou --> win["Conflict में बाद वाला जीतता है"]
    win -.-> strongest["निकट OU की GPO सबसे मज़बूत"]
    win -.-> weakest["Local GPO सबसे कमज़ोर"]

चित्र 3: LSDOU processing का क्रम है, और वही setting conflict करे तो बाद में process हुई GPO जीतती है।

जब एक ही site, domain, या OU से कई GPO link हों, उनके बीच priority GPMC के Linked Group Policy Objects tab के link order से तय होती है। सबसे छोटे link-order number वाली GPO अंतिम process होती है और सबसे ऊँची priority लेती है।¹

flowchart TB
    accTitle: एक ही स्थान पर कई GPO हों तो link order
    accDescr: एक ही site, domain, या OU से कई GPO link हों तो GPMC का link order processing क्रम तय करता है, और सबसे छोटे number वाली GPO अंतिम process होकर सबसे प्राथमिक होती है
    multi["एक ही स्थान पर कई GPO"] --> tab["GPMC के link order से तय"]
    tab --> last["सबसे छोटा number अंतिम process"]
    last --> win["बाद वाला जीतकर सबसे प्राथमिक"]

चित्र 4: एक ही link target पर सबसे छोटे link-order number वाली GPO अंतिम process होकर जीतती है।

3.2. Inheritance block और Enforced

Default क्रम पर अपवाद बना सकते हैं।¹

• Block Inheritance: Domain या OU पर set करने से ऊपर से GPO की inheritance रुकती है। «इस एक OU को कंपनी-व्यापी standard नहीं चाहिए» का औज़ार है।
• Enforced (पूर्व नाम No Override): GPO के link पर set करने से वह GPO हमेशा apply होती है, भले नीचे Block Inheritance हो, और निचली GPO उसे overwrite नहीं कर सकती। Block Inheritance और Enforced टकराएँ तो Enforced जीतता है।¹

flowchart TB
    accTitle: Inheritance block और Enforced का संबंध
    accDescr: Block Inheritance ऊपर से GPO की inheritance रोकता है, पर Enforced GPO नीचे Block Inheritance होने पर भी अवश्य apply होती है और निचली GPO से overwrite नहीं होती
    upper["ऊपर से GPO"] --> blocked{"नीचे inheritance block?"}
    blocked -->|नहीं| inherit["ज्यों की त्यों inheritance"]
    blocked -->|हाँ| enforced{"GPO पर Enforced?"}
    enforced -->|नहीं| stop["Inheritance रुकती है"]
    enforced -->|हाँ| apply["अवश्य apply होती है"]
    apply -.-> noover["निचली GPO overwrite नहीं कर सकती"]

चित्र 5: Block Inheritance ऊपर से inheritance रोकता है, पर Enforced GPO block पार कर अवश्य apply होती है।

Enforced «बाद वाला जीतता है» सिद्धांत तोड़ने वाला mechanism है, इसलिए अति प्रयोग से RSoP पढ़ते समय counter-intuitive परिणाम बढ़ते जाते हैं। Established practice इसे पूरी कंपनी को अवश्य माननी वाली security settings तक सीमित रखना है।

3.3. Security filtering

Link स्थान के अलावा, किस पर apply हो भी GPO-दर-GPO संकीर्ण कर सकते हैं। GPO apply होने के लिए target user या computer के पास उस GPO पर Read और Apply group policy दोनों permissions होनी चाहिए। Default से दोनों Authenticated Users (जिसमें users और computers दोनों हैं) को दी जाती हैं, इसलिए GPO link target के नीचे सभी पर apply होती है। इसे खास security group तक संकीर्ण करना security filtering है। Filter पूरी GPO पर काम करता है; GPO के अंदर setting-दर-setting नहीं बदल सकते।¹³

एक महत्वपूर्ण चेतावनी है। दायरा संकीर्ण करते समय default Authenticated Users से Read भी न हटाएँ। Security update MS16-072 (2016) के बाद user policy computer के security context में प्राप्त होती है, इसलिए यदि computer account GPO पढ़ न सके, target user के पास दोनों permissions होने पर भी user-targeted GPO apply नहीं होगी।¹⁴ दायरा संकीर्ण करने का सही रूप target group को Read + Apply group policy देना और Authenticated Users (या Domain Computers) पर केवल Read छोड़ना है।¹⁴

flowchart TB
    accTitle: Security filter का apply निर्णय
    accDescr: GPO apply होने के लिए target user या computer के पास Read और Apply group policy दोनों permissions होनी चाहिए, और user-targeted GPO के लिए computer account का पढ़ सकना भी आवश्यक हो जाता है
    target["Link target के नीचे का विषय"] --> perm{"पढ़ना और Apply दोनों permission?"}
    perm -->|नहीं| deny["Filter से denied"]
    perm -->|हाँ| usergpo{"User-targeted GPO?"}
    usergpo -->|नहीं| apply["Apply होती है"]
    usergpo -->|हाँ| comp{"Computer पढ़ सकता है?"}
    comp -->|हाँ| apply
    comp -->|नहीं| deny2["Apply नहीं（MS16-072）"]

चित्र 6: Apply होने को Read और Apply group policy दोनों चाहिए, और user-targeted GPO पर computer account का पढ़ना भी आवश्यक है।

व्यवहार में दो classic ठोकरें हैं: «Group में डाला फिर भी apply नहीं (computer-targeted setting है, पर group में केवल user डाला)» और «Group से निकाला फिर भी apply होती रहती है»। बाद वाला background refresh की प्रतीक्षा से भी नहीं छूटता। Group membership sign-in पर बने security token से evaluate होती है, इसलिए user का group बदलाव sign-out/sign-in चक्र के बाद, और computer का group बदलाव reboot के बाद — नया token जारी होने पर — ही filter तक पहुँचता है।

flowchart TB
    accTitle: Group बदलाव filter में कब दिखता है
    accDescr: Group membership sign-in पर बने security token से evaluate होती है, इसलिए user का बदलाव फिर sign-in और computer का बदलाव reboot से नया token बनने पर ही filter में आता है
    change["Group के member बदलें"] --> old["पुराने token से अनपरावर्तित"]
    old --> u["User फिर sign-in"]
    old --> c["Computer reboot"]
    u --> token["नए token से evaluate"]
    c --> token
    token --> ok["Filter में परावर्तित"]
    old -.-> bg["Background refresh से हल नहीं"]

चित्र 7: Group बदलाव sign-out या reboot से नया token बनने पर ही filter में आता है।

Shared PC या Remote Desktop server जैसी स्थितियों के लिए, जहाँ उस PC पर sign-in करने वाले हर व्यक्ति की User Configuration बदलनी हो, loopback processing नामक विशेष mode भी है (computer के स्थान के आधार पर user settings apply करने का mechanism, Replace और Merge modes सहित)।¹⁵ Kiosk machines और कक्षा PC पर प्रयुक्त advanced feature है, इसलिए यह लेख केवल यह नोट करता है कि वह मौजूद है।

flowchart TB
    accTitle: Loopback processing का विचार
    accDescr: Loopback processing computer के स्थान के आधार पर User Configuration apply करने वाला विशेष mode है, Replace और Merge दो modes हैं, और shared PC या kiosk जैसे sign-in सभी पर वही user settings चलाने के दृश्यों में प्रयुक्त होता है
    shared["Shared PC, kiosk आदि"] --> lb["Loopback processing"]
    lb --> base["Computer के स्थान से तय"]
    base --> rep["Replace mode"]
    base --> mrg["Merge mode"]
    lb -.-> aim["Sign-in सभी पर apply"]

चित्र 8: Loopback processing computer के स्थान के आधार पर User Configuration apply करने वाला विशेष mode है, Replace और Merge दो modes सहित।

4. कब apply होती है — Foreground processing और background refresh

«Configure किया पर apply नहीं हुआ» का आधा बस इतना है कि apply होने का समय अभी आया नहीं। Apply होने के दो प्रकार हैं।²

अर्थात चल रहे devices जो domain controller तक पहुँच सकें, उन पर background refresh supported settings GPO बदलने के बाद बिना और कार्रवाई लगभग दो घंटे में फैल जाती हैं। Offline devices, या बिना VPN off-site laptops, अगली बार DC तक पहुँचने तक नहीं पाते। केवल foreground processing से apply settings को extra रूप से startup या sign-in की प्रतीक्षा करनी पड़ती है। जल्दी हो तो target PC पर gpupdate चलाएँ। Default से केवल बदली settings apply होती हैं; /force जोड़ने से बदली हो या न हो हर setting फिर apply होती है।³

rem केवल बदली settings update (आमतौर पर काफ़ी)
gpupdate

rem हर setting फिर apply (cache अवस्था का संदेह हो)
gpupdate /force

flowchart TB
    accTitle: DC तक पहुँच और apply कैसे पहुँचती है
    accDescr: Domain controller तक पहुँच सकने वाले चल रहे device पर background refresh supported settings लगभग दो घंटे में फैल जाती हैं, पर offline या बिना VPN off-site PC अगली बार DC से जुड़ने तक नहीं पाते
    pc{"DC तक पहुँच सकते हैं?"}
    pc -->|हाँ| ok["लगभग 2 घंटे में फैलती है"]
    pc -->|नहीं| ng["जुड़ने तक नहीं आती"]
    ng -.-> ex["Offline या बिना VPN off-site PC"]

चित्र 9: DC तक पहुँच सकने वाले चल रहे device पर लगभग दो घंटे में पहुँचती है, offline device पर अगली बार DC से जुड़ने तक नहीं।

ध्यान रहे कि कुछ settings gpupdate से apply होती ही नहीं। User-targeted software install और folder redirect केवल sign-in पर, और computer-targeted software install केवल startup पर process होते हैं। gpupdate इसी लिए /logoff (update के बाद sign-out) और /boot (update के बाद reboot) options देता है।³ «gpupdate /force चलाया फिर भी नहीं आया» कहने से पहले जाँचें कि setting reboot या sign-in चाहने वाले प्रकार की तो नहीं।

flowchart TB
    accTitle: Setting apply होने के path
    accDescr: GPO बदलाव background refresh supported setting हो तो default लगभग 90 मिनट और 0–30 मिनट offset में पहुँचता है, केवल foreground से apply settings को startup या sign-in की प्रतीक्षा करनी पड़ती है, और जल्दी वाले gpupdate पर foreground settings को /logoff या /boot चाहिए
    change["GPO बदलें"] --> kind{"Background refresh supported?"}
    kind -->|हाँ| bg["लगभग 90 मिनट+0–30 मिनट में"]
    kind -->|नहीं| fg["Startup या sign-in पर apply"]
    bg --> done["परावर्तित"]
    fg --> done
    rush["जल्दी हो तो"] -.-> upd["gpupdate चलाएँ"]
    upd -.-> force["/force से सब फिर apply"]
    upd -.-> reboot["Foreground को /logoff या /boot"]

चित्र 10: Background refresh केवल supported settings पहुँचाता है; केवल foreground से apply settings को gpupdate के बाद भी sign-out या reboot चाहिए।

5. Apply न होने पर छाँटना — gpresult, event log, और registry

5.1. gpresult /h से RSoP जाँचना

कई GPO परत दर परत चढ़ने के बाद अंतिम परिणाम (RSoP: Resultant Set of Policy) जाँचने का standard tool gpresult है। Elevated command prompt से HTML report निकालना सबसे पठनीय तरीका है।⁴⁵

rem User और computer दोनों का RSoP HTML report में
gpresult /h C:\temp\gp-report.html /f

rem Console में केवल सारांश
gpresult /r
gpresult /scope computer /r

Report में पहले ये तीन बातें देखें:

1. Applied GPOs की सूची — आप जिस GPO के पीछे हैं वह मौजूद है?
2. Denied GPOs की सूची, कारण सहित — Security filter, WMI filter, या खाली GPO जैसे apply न होने के कारण यहाँ दिखते हैं⁵
3. प्रत्येक setting का Winning GPO — Target setting किस GPO के मान से तय हुई। कोई दूसरी GPO जीत रही हो तो अध्याय 3 की priority नियम पुनर्विचार करें

flowchart TB
    accTitle: RSoP report में पहले देखने योग्य तीन बातें
    accDescr: gpresult report में पहले Applied GPOs की सूची में target GPO है या नहीं देखें, फिर Denied GPOs की सूची और कारण जाँचें, अंत में प्रत्येक setting के Winning GPO से कौन सा मान जीता तय करें
    rep["RSoP report खोलें"] --> one["1. Applied GPOs की सूची"]
    one --> two["2. Denied GPOs और कारण"]
    two --> three["3. Setting का Winning GPO"]
    three -.-> review["दूसरी GPO जीती तो पुनर्विचार"]

चित्र 11: RSoP report Applied GPOs, Denied GPOs और कारण, फिर प्रत्येक setting के Winning GPO क्रम से देखें।

5.2. GroupPolicy Operational log

जब gpresult काफ़ी न हो — मान लें processing पूरी तरह fail हो रही है, या बहुत लंबा लग रहा है — Event Viewer में GroupPolicy Operational log देखें। स्थान Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational है (log नाम Microsoft-Windows-GroupPolicy/Operational)। यहाँ policy processing का पूरा विस्तार, आरंभ से अंत तक, Applied GPOs की सूची और Denied GPOs की सूची (कारण सहित) दर्ज होता है। Policy processing के प्रत्येक चक्र को unique ActivityID मिलता है, इसलिए Microsoft की recommended प्रक्रिया System log की warning या error से ActivityID उठाना और custom view से केवल उसी एक चक्र तक छानना है।⁵

flowchart TB
    accTitle: GroupPolicy Operational log छानने की प्रक्रिया
    accDescr: GroupPolicy Operational log में policy processing के प्रत्येक चक्र को unique ActivityID मिलता है, इसलिए System log की warning या error से ActivityID उठाएँ और custom view से केवल उसी एक चक्र की घटनाएँ पढ़ें
    sys["System log की warning या error"] --> aid["ActivityID उठाएँ"]
    aid --> cv["Custom view से छानें"]
    cv --> one["एक चक्र की घटनाएँ पढ़ें"]
    one -.-> rec["Applied व Denied GPOs कारण सहित"]

चित्र 12: Operational log System log से ActivityID उठाकर custom view से policy processing के एक चक्र तक छानकर पढ़ें।

5.3. Registry की Policies key से संबंध

Administrative Template policies (अगला अध्याय) अंततः registry values के रूप में लिखी जाती हैं। नियम के रूप में वे निम्नलिखित dedicated policy keys में लिखी जाती हैं।⁶

• HKEY_LOCAL_MACHINE\Software\Policies (Computer Configuration; recommended स्थान)
• HKEY_CURRENT_USER\Software\Policies (User Configuration; recommended स्थान)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

यहाँ एक महत्वपूर्ण design सिद्धांत काम करता है। Policy-enabled app पहले Policies key पढ़ता है; मान हो तो वह priority लेता है; न हो तो app अपनी setting (preference) या default पर गिरता है। Not Configured policy registry में कुछ भी नहीं लिखती।⁶ अर्थात Administrative Template policies app की अपनी setting overwrite कर «tattoo» (tattooing) नहीं छोड़तीं — बल्कि अलग स्थान पर रखा forced मान priority से देखा जाता है। Policy configure करना बंद करें तो app अपनी setting मान मानने पर लौट आता है।

flowchart TB
    accTitle: Policy मान और app settings की priority
    accDescr: Policy-enabled app पहले Policies key पढ़ता है और मान हो तो उसे priority देता है, नहीं तो अपनी setting या default उपयोग करता है, और Not Configured policy registry में कुछ नहीं लिखती
    app["Policy-enabled app setting पढ़ता है"] --> haspol{"Policies key में मान?"}
    haspol -->|हाँ| pol["Policy मान प्राथमिक"]
    haspol -->|नहीं| pref["अपनी setting या default"]
    notconf["Not Configured policy"] -.-> nowrite["Registry में कुछ नहीं लिखती"]

चित्र 13: Policy app की अपनी setting overwrite नहीं करती; अलग स्थान पर रखा forced मान priority से देखा जाता है।

फिर भी हर policy dedicated key में नहीं लिखती। कुछ built-in OS settings (उदाहरण: Enable Win32 long paths HKLM\SYSTEM\CurrentControlSet\Control\FileSystem के LongPathsEnabled में लिखता है), साथ पुरानी पीढ़ी या third-party templates, dedicated keys के बाहर मनमाने path पर लिखते हैं। ऐसी setting पर policy configure करना बंद करने के बाद भी मान ज्यों का त्यों रहता है। दी गई setting वास्तव में किस key में लिखती है, ADMX definition, setting का विवरण पाठ, या gpresult report से जाँचें।

दूसरे शब्दों में, ऊपर का सुव्यवस्थित design केवल Administrative Templates (dedicated policy keys) की सीमा में है। Scripts या Group Policy Preferences Policies key के बाहर जो मान लिखें वे साधारण registry values जैसे व्यवहार करते हैं, और distribution बंद करने पर उन्हें अपने आप वापस करने का mechanism इस ढाँचे में नहीं है। Diagnostics में सबसे तेज़ और विश्वसनीय तरीका सीधे देखना है कि target setting Policies key के नीचे लिखी है या नहीं।

# Policy से distribute मान सीधे जाँचने का उदाहरण (अधिकांश policies Policies के नीचे लिखी जाती हैं)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: Apply न होने पर छाँटने की प्रक्रिया
    accDescr: पहले gpresult की RSoP report से Applied और Denied GPOs जाँचें, काफ़ी न हो तो GroupPolicy Operational log ActivityID से छानें, और distribute वास्तविक मान registry की Policies key में सीधे देखें
    start["Setting apply नहीं होती"] --> rsop["gpresult /h से RSoP जाँचें"]
    rsop --> found{"Apply व denial का कारण स्पष्ट?"}
    found -->|हाँ| fix["Priority या filter पुनर्विचार"]
    found -->|नहीं| oplog["GroupPolicy Operational log देखें"]
    oplog -.-> aid["ActivityID से एक चक्र छानें"]
    rsop -.-> reg["Policies key का वास्तविक मान सीधे जाँचें"]

चित्र 14: छाँटना gpresult /h से शुरू करें; काफ़ी न हो तो GroupPolicy Operational log, वास्तविक मान Policies key की सीधी जाँच से यांत्रिक आगे बढ़ें।

6. Administrative Templates (ADMX) और Central Store

GPMC के Administrative Templates के नीचे listed settings की definitions ADMX files (definition का शरीर) प्लस ADML files (प्रत्येक भाषा के display strings) के रूप में लिखी जाती हैं। हर PC पर OS-प्रदत्त definitions C:\Windows\PolicyDefinitions के नीचे हैं, और management tools settings screen बनाने इन्हें load करते हैं।⁷

Domain में operations हो तो मूल कदम Central Store बनाना है। Domain controller के SYSVOL के नीचे PolicyDefinitions folder बनाएँ (उदाहरण: \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), और उसकी सामग्री domain के हर domain controller पर replicate होती है; Group Policy tools तब default से Central Store reference करते हैं।⁷ इससे «management workstation-दर-workstation template version भिन्न, दिखाई settings मेल नहीं खाती» की समस्या मिटती है। ADML files भाषा-specific subfolder में जाती हैं (Japanese के लिए ja-JP)।⁷

flowchart TB
    accTitle: Central Store की संरचना
    accDescr: Domain controller के SYSVOL के नीचे PolicyDefinitions folder बनाने से सामग्री हर domain controller पर replicate होती है, और Group Policy tools default से Central Store reference करते हैं, इसलिए management terminal-दर-terminal definition अंतर मिट जाता है
    create["SYSVOL के नीचे बनाएँ"] --> cs["PolicyDefinitions"]
    cs --> repl["सभी DC पर replicate होता है"]
    cs --> ref["GP tools default से reference"]
    ref -.-> benefit["Terminal-दर-terminal definition अंतर मिटता है"]
    cs -.-> adml["ADML भाषा folder में"]

चित्र 15: SYSVOL का PolicyDefinitions हर domain controller पर replicate होता है, और Group Policy tools default से उसे reference करते हैं।

Operations की दो चेतावनियाँ हैं। पहली, Microsoft प्रत्येक नए Windows version के लिए नए ADMX distribute करता है, और update करते समय Central Store पक्ष बदलते हैं। प्रत्येक PC पर C:\Windows\PolicyDefinitions को download version से बदलना supported नहीं है।⁷ दूसरी, मौजूदा Central Store update करते समय guidance production PolicyDefinitions सीधे overwrite न करने का है। इसके बजाय OS वाले और Office व Edge जैसे apps वाले ADMX का पूरा set PolicyDefinitions-24H2 जैसे version-नाम work folder में इकट्ठा करें, वर्तमान folder का नाम PolicyDefinitions-23H2 जैसे बदलकर हटाएँ, फिर work folder का नाम PolicyDefinitions कर production बनाएँ।⁷ Group Policy tools केवल शाब्दिक नाम PolicyDefinitions वाले folder reference करते हैं, इसलिए version-नाम folder में files रखना कोई प्रभाव नहीं डालता। इस दृष्टिकोण का लाभ: समस्या आए तो हटाए folder पर लौट सकते हैं।⁷

flowchart TB
    accTitle: Central Store update की प्रक्रिया
    accDescr: Update version-नाम work folder में OS वाले और apps वाले ADMX का पूरा set इकट्ठा करता है, वर्तमान folder का नाम बदलकर हटाता है, फिर work folder का नाम production PolicyDefinitions कर देता है, और समस्या आए तो हटाए पुराने folder पर लौटता है
    work["Version-नाम work folder"] --> gather["OS वाले और apps वाले इकट्ठा करें"]
    gather --> evac["वर्तमान का नाम बदलकर हटाएँ"]
    evac --> rename["Work folder को production नाम"]
    rename --> live["Production के रूप में reference"]
    live -.-> back["समस्या पर पुराना folder वापस"]

चित्र 16: Update work folder में पूरा set इकट्ठा करता है, वर्तमान हटाता है, फिर नाम बदलकर production बनाता है।

7. GPO बनाम Intune (MDM/CSP) बनाम manual/script — Decision table

Windows device configuration management का option अब केवल GPO नहीं। Intune से चिह्नित MDM, CSP (Configuration Service Provider) नामक mechanism से OS settings configure करता है। किसे अक्ष बनाएँ, इसकी decision table है।

निर्णय का अक्ष सरल है: Device की identity नींव (AD, या Microsoft Entra) और device कहाँ है। On-premises AD से पूर्ण-joined office के desk-बद्ध PC के बेड़े पर GPO सबसे विश्वसनीय है; Entra-joined mobile PC तक GPO पहुँचती ही नहीं।

वास्तविकता में अधिकांश छोटे और मध्यम businesses बीच में बैठते हैं, hybrid setup (domain-joined प्लस Intune-enrolled) में, और यहाँ सबसे बुरी बात «वही setting GPO और MDM दोनों से configure करना» है। Policy CSP में MDMWinsOverGP policy है जो GPO और MDM conflict पर MDM जीतवा सकती है, पर उसका दायरा Policy CSP के अंदर संबंधित policies तक सीमित है। Microsoft स्वयं स्पष्ट है कि उस नियंत्रण के बाहर settings GPO और MDM दोनों से configure करना race condition पैदा करता है जिसकी जीत की गारंटी नहीं, और dual configuration से बचना चाहिए।⁸ Hybrid operations का पहला सिद्धांत setting-क्षेत्र के अनुसार «यह GPO, यह Intune» तय कर management अधिकार एक तरफ रखना है।

flowchart TB
    accTitle: GPO और Intune का चुनाव
    accDescr: Device की identity नींव on-premises AD और office में हो तो GPO, Entra join या off-site device हो तो Intune उपयुक्त है, और hybrid में वही setting dual configure न कर क्षेत्र के अनुसार management एक तरफ रखें
    q{"Device का आधार और स्थान?"}
    q -->|AD join और office में| gpo["GPO विश्वसनीय और बारीक"]
    q -->|Entra join या off-site| intune["Intune off-site भी पहुँचता है"]
    q -->|Hybrid| split["क्षेत्र के अनुसार एक तरफ रखें"]
    split -.-> warn["Dual config परिणाम गारंटी नहीं"]
    split -.-> ana["छाँटने को Group Policy analytics"]

चित्र 17: चुनाव device की identity नींव और स्थान से तय करें, और hybrid में वही setting GPO और MDM दोनों से configure न करें।

GPO से Intune migration सोचने के चरण में Intune का Group Policy analytics प्रवेश द्वार है। GPMC से export GPO (XML) import करें, और वह प्रत्येक setting MDM-supported है या unsupported/deprecated analyse करता है; supported settings Intune Settings catalog policy में migrate हो सकती हैं।⁹ इसे «सब कुछ स्थानांतरित» से अधिक «क्या जा सकता है, क्या नहीं, क्या छोड़ें छाँटने» का tool समझना वास्तविकता से मेल खाता है। Windows Update का management अधिकार भी उसी संदर्भ में पुनर्गठित हो रहा है — देखें «WSUS deprecation के बाद Windows Update management»।

flowchart TB
    accTitle: Group Policy analytics से छाँटना
    accDescr: GPMC से XML रूप में export GPO Group Policy analytics में import करने से setting-दर-setting MDM supported है या deprecated या unsupported छँटती है, और supported settings Settings catalog policy में migrate हो सकती हैं
    exp["GPMC से XML export"] --> imp["Analytics में import"]
    imp --> ana["Setting-दर-setting support analysis"]
    ana --> ok["MDM supported"]
    ana --> dep["Deprecated या unsupported"]
    ok --> mig["Settings catalog policy में migrate"]

चित्र 18: Group Policy analytics export GPO import कर MDM में जा सकने वाली और न जा सकने वाली settings छाँटता है।

8. Developer की दृष्टि का pitfall — ग्राहक GPO app का व्यवहार कैसे बदलती है

अंत में, Custom Software Development के पद से जानने योग्य बात। ग्राहक की GPO आपके app की assumptions चुपचाप overwrite कर देती है। Firewall और antivirus के साथ, GPO «dev machine पर चलता है ग्राहक पर नहीं» के regular अपराधी में है। कुछ ठोस उदाहरण।

• PowerShell की execution policy: Execution policy GPO से केंद्र में configure हो सकती है, और GPO-derived MachinePolicy/UserPolicy scope local या process पर set मान से हमेशा priority लेते हैं।¹⁰ यदि installer या operations script «-ExecutionPolicy Bypass जोड़ने से चल जाएगी» assumption पर बनी है, GPO management के नीचे वह चालू भी नहीं होती। विवरण «PowerShell execution policy और script signing — Bypass से ढकने से आगे बढ़ने की practical guide» में।
• Firewall पर local rules merge disabled: जिन environments में firewall GPO/Intune से केंद्र में managed है, profile-दर-profile «local rules merge» (AllowLocalPolicyMerge) disabled हो सकता है। जहाँ disabled हो, installer का locally registered inbound rule मौजूद होता है पर apply नहीं होता।¹¹ Server-प्रकार app deploy करने से पहले अवश्य पुष्टि करने योग्य बिंदु है; विस्तार «Windows firewall और business apps» में।
• Drive map और proxy जैसी environment configuration: Network drive map, printer आदि आमतौर पर Group Policy Preferences से distribute होते हैं।¹⁶ Environment की assumptions — «Z drive होना चाहिए», «proxy direct connection होना चाहिए» — sign-in user या PC की OU membership से टूट सकती हैं। Resident-प्रकार app के लिए यह भी आसानी से छूटता है कि User Configuration से distribute settings service या scheduled task के account पर स्वाभाविक रूप से apply नहीं होती।
• Setting «वापस बदली ही नहीं जा सकती»: Administrative Templates से आई settings आमतौर पर user UI से बदल ही नहीं सकता (item धूसर)। «ग्राहक setting बदल दे तो ठीक हो जाएगा» न चलना support दृष्टिकोण के design पर वास्तविक प्रभाव डालता है।

flowchart TB
    accTitle: ग्राहक GPO app की assumptions कैसे बदलती है
    accDescr: ग्राहक की GPO execution policy force करने, firewall local rules merge disable करने, drive या proxy distribute करने, और user settings वापस न बदल पाने के रूप में app की पूर्वापेक्षाएँ बदलती है, और केवल ग्राहक पर न चलने का एक कारण बनती है
    gpo["ग्राहक की GPO"] --> ep["Execution policy force"]
    gpo --> fw["Local rules merge disabled"]
    gpo --> env["Drive व proxy distribution"]
    gpo --> lock["Settings वापस नहीं बदल सकते"]
    ep --> sym["केवल ग्राहक पर न चलने का कारण"]
    fw --> sym
    env --> sym
    lock --> sym

चित्र 19: ग्राहक की GPO execution policy, firewall, environment configuration जैसी app की पूर्वापेक्षाएँ चुपचाप overwrite कर देती है।

Development पक्ष की realistic तीन तैयारियाँ हैं। पहली, app जिन environment assumptions पर निर्भर है — execution policy, सुनने वाले ports, लिखने का स्थान, proxy path आदि — को deployment requirement के रूप में document करें और deployment से पहले ग्राहक IT से पुष्टि करवाएँ। दूसरी, समस्या आए तो अनुमान नहीं, gpresult /h report और HKLM\Software\Policies के नीचे वास्तविक मान जाँचें (अध्याय 5)। तीसरी, design चरण में कौन से operations admin privilege चाहते हैं और कौन नहीं अलग रखें (यह रेखा «Windows पर admin privilege वास्तव में कब चाहिए? - UAC, protected areas, और design से कैसे पहचानें» में खिंची है)। GPO शत्रु नहीं — environment का specification है। Specification की तरह सँभालें तो diagnostics यांत्रिक हो जाता है।

flowchart TB
    accTitle: Development पक्ष की तीन तैयारियाँ
    accDescr: Development पक्ष की तैयारी app की environment assumptions deployment requirement के रूप में document कर deployment से पहले ग्राहक IT से पुष्टि करवाना, समस्या पर gpresult report और Policies key के वास्तविक मान जाँचना, और admin privilege चाहने वाले operations design चरण में अलग रखना है
    dev["Development पक्ष की तैयारी"] --> doc["1. Environment assumptions document"]
    dev --> chk["2. gpresult व वास्तविक मान जाँचें"]
    dev --> priv["3. Privilege की ज़रूरत design में अलग"]
    doc -.-> ask["Deployment से पहले ग्राहक IT से पुष्टि"]

चित्र 20: Development पक्ष की तैयारी environment assumptions document करना, gpresult और वास्तविक मान जाँचना, और admin privilege की ज़रूरत design में अलग रखना है।

9. सारांश

• Group Policy GPO-level settings local → site → domain → OU (LSDOU) क्रम में process करने का mechanism है, और conflicts बाद-वाले-की-जीत से हल होते हैं। Target के निकट OU की GPO सबसे मज़बूत परत है, local GPO सबसे कमज़ोर।
• Block Inheritance, Enforced, और security filtering default flow नियंत्रित करते हैं। Enforced Block Inheritance को भी हराता है, इसलिए अति प्रयोग न करें।
• Apply होना दो channels से होता है: startup/sign-in पर foreground processing, और default लगभग 90 मिनट प्लस random offset का background refresh। gpupdate /force हर setting फिर apply करता है, पर केवल sign-in या reboot पर process settings पर कोई प्रभाव नहीं।
• Setting apply न हो तो gpresult /h → GroupPolicy Operational log → registry की Policies key क्रम से systematic diagnostics करें। Denied GPOs कारण सहित दिखती हैं।
• Administrative Template definitions ADMX/ADML हैं, और domain operations उन्हें SYSVOL Central Store में एकत्र करे। Update पर local PolicyDefinitions folder बदलने के बजाय Central Store पक्ष बदलें।
• GPO या Intune device की identity नींव और स्थान से तय होता है; hybrid setup में वही setting dual configure न करें और management अधिकार एक तरफ रखें। Migration छाँटने को Group Policy analytics मदद करता है।
• Developers के लिए ग्राहक GPO environment के specification का भाग है। Execution policy, firewall, drive map, और proxy configuration की assumptions document करें, और gpresult से पुष्टि की आदत बनाएँ — तो «केवल ग्राहक पर नहीं चलता» के अधिकांश मामले डरावने नहीं रहते।

संबंधित लेख

• Windows firewall और business apps — Installer से inbound rules register करें
• WSUS deprecation के बाद Windows Update management — WUfB, Autopatch, और Intune में कैसे चुनें
• PowerShell execution policy और script signing — Bypass से ढकने से आगे बढ़ने की practical guide
• winget + PowerShell से PC provision automatic करना — Runbook को executable बनाना
• IE mode dependency से बाहर निकलने की guide
• Windows पर admin privilege वास्तव में कब चाहिए? - UAC, protected areas, और design से कैसे पहचानें

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

KomuraSoft LLC GPO management के नीचे ग्राहक environment में business app न चलने की जाँच, deployment requirements (execution policy, firewall, network assumptions) व्यवस्थित करना, और AD environment विरासत में लेने वाले IT staff के लिए policy सूची व Intune co-management योजना पर technical consulting सँभालता है। «gpresult report साथ पढ़ें» जितने आरंभिक चरण से शुरू करना ठीक है।

• Technical consulting और design review
• बग और कारणों की जाँच
• Windows app development
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

gpupdate /force चलाया, फिर भी setting apply नहीं हुई। क्यों?

पहले जाँचें कि setting उन प्रकारों में तो नहीं है जिन्हें background refresh कभी apply नहीं करता। User-targeted software install और folder redirect केवल sign-in पर, और computer-targeted software install केवल startup पर process होते हैं, इसलिए gpupdate खत्म होने के बाद sign-out (/logoff) या reboot (/boot) चाहिए। फिर gpresult /h से RSoP report निकालें और देखें कि वह GPO Applied GPOs में है, या Denied GPOs में कारण सहित है। Apply है पर व्यवहार नहीं बदला तो संदेह करें कि ऊँची priority वाली दूसरी GPO वही setting overwrite कर रही है (बाद वाला जीतता है)। Report प्रत्येक setting का Winning GPO दिखाती है, इसलिए कौन सी GPO जीत रही है तक तय कर सकते हैं।

gpresult report में Denied - Filtering का क्या अर्थ है?

अर्थ यह है कि link स्थान के हिसाब से GPO दायरे में है, पर filtering ने उसे वास्तव में apply होने से बाहर कर दिया। सबसे आम कारण security filtering है: GPO apply होने के लिए user या computer के पास उस GPO पर Read और Apply group policy दोनों permissions होनी चाहिए। Default से दोनों Authenticated Users को दी जाती हैं, पर यदि आपने इसे खास group तक संकीर्ण किया है तो group membership चूकना — group न जोड़ना, या computer account न जोड़ना — denial लाता है। User-targeted GPO पर target user को दोनों permissions देना काफ़ी नहीं। MS16-072 के बाद user policy computer के security context में प्राप्त होती है, इसलिए Authenticated Users या Domain Computers पर Read (Apply नहीं) छोड़ना आवश्यक है। अन्य कारण WMI filter का न मिलना, या GPO पर ही user/computer configuration disabled होना हैं। Denial का कारण gpresult report और GroupPolicy Operational log दोनों में दर्ज होता है।

Device GPO से manage करें या Intune से?

मूल नियम device की identity नींव से मेल खाना है। यदि devices मुख्यतः on-premises AD से domain-joined हैं और internal network से स्थायी रूप से जुड़े हैं, GPO सबसे विश्वसनीय और सबसे बारीक option है। यदि Microsoft Entra-joined devices अधिक हैं, या घर के ऐसे machines जो domain controller को छूते ही नहीं, तो Intune (MDM/CSP) बेहतर बैठता है, जो office से बाहर भी configuration पहुँचा सकता है। दोनों के सह-अस्तित्व वाले hybrid environment में वही setting GPO और MDM दोनों से configure करने से conflict होता है और विजेता की गारंटी नहीं, इसलिए सिद्धांत setting-क्षेत्र के अनुसार कौन manage करता है तय कर उसी एक पर टिकना है। Migration सोचने लगें तो मौजूदा GPO Intune के Group Policy analytics में import करने से settings MDM-supported और unsupported या deprecated में छँट जाती हैं।

Local Group Policy Editor (gpedit.msc) से configure की setting domain settings से overwrite हो जाती है। क्या यह specification है?

हाँ, यही design है। Group Policy local → site → domain → OU (LSDOU) क्रम में process होती है, और conflict में बाद में process हुई GPO जीतती है, इसलिए local GPO सबसे कमज़ोर परत है। यदि domain GPO वही setting configure करे, local बदलाव हमेशा overwrite होगा। उलटा, यदि domain पक्ष वह setting Not Configured छोड़े, local GPO का मान ज्यों का त्यों रहता है। Testing के लिए local settings को प्राथमिकता देनी हो, तब भी domain-joined PC पर इस priority क्रम को उलटने का कोई तरीका नहीं, इसलिए realistic रास्ते हैं dedicated test OU बनाकर domain-पक्ष GPO समायोजित करना, या non-domain-joined test machine उपयोग करना।

हमारा विकसित business app केवल ग्राहक environment में नहीं चलता। GPO कारण है या नहीं, जाँचने का तरीका है?

पहला कदम ग्राहक के admin से प्रभावित PC पर elevated command prompt से gpresult /h report.html चलवाकर RSoP report देखना है। App का व्यवहार बदलने वाली settings देखें: execution policy से scripts रुकना, firewall local rules merge disabled, या configured proxy और drive map। साथ ही registry में HKLM\Software\Policies और HKCU\Software\Policies के नीचे संबंधित product के policy values लिखे हैं या नहीं जाँचें — इससे Administrative Templates से आई forced settings यांत्रिक रूप से flagged होती हैं। Development पक्ष की realistic तैयारी app जिन assumptions पर निर्भर है — execution policy, सुनने वाले ports, लिखने का folder आदि — को deployment requirement के रूप में document करना और deployment से पहले ग्राहक IT से पुष्टि करवाना है।

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

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

Go Komura

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

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