Group Policy (GPO) की व्यावहारिक मार्गदर्शिका — कैसे काम करती है, लागू पुष्टि, और GPO व Intune के बीच चुनाव

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

«सेटिंग बदली, पर लागू नहीं हुई», «gpupdate चलाने को कहा गया पर वास्तव में क्या होता है नहीं पता», «डेव मशीन पर ऐप चलता है ग्राहक पर नहीं, और निकला GPO था» — यह लेख इन स्थितियों से टकराने वाले व्यावसायिक-ऐप डेवलपर्स और AD प्रशासन विरासत में लेने वाले छोटे-मध्यम व्यवसाय के IT स्टाफ के लिए है। यह Group Policy कैसे काम करती है (LSDOU लागू क्रम), कब प्रभावी होती है, gpresult और इवेंट लॉग से निदान, ADMX और सेंट्रल स्टोर, और GPO बनाम Intune (MDM) का चुनाव, अगस्त 2026 तक के प्राथमिक स्रोतों पर आधारित व्यवस्थित करता है।

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

• Group Policy «बाद वाला जीतता है» है। यह स्थानीय → साइट → डोमेन → OU (LSDOU) क्रम में संसाधित होती है, और संघर्ष में बाद में संसाधित GPO प्राथमिकता लेती है। स्थानीय GPO (gpedit.msc) सबसे कमज़ोर परत है।¹
• लागू होने का समय «फ़ोरग्राउंड प्लस बैकग्राउंड» है। Computer Configuration हमेशा स्टार्टअप पर और User Configuration हमेशा साइन-इन पर लागू होती है; उसके ऊपर डिफ़ॉल्ट से बैकग्राउंड रिफ्रेश लगभग हर 90 मिनट प्लस 0–30 मिनट का यादृच्छिक ऑफ़सेट है (डोमेन नियंत्रकों पर 5 मिनट)।²
• gpupdate /force «हर सेटिंग पुनः लागू» है — रामबाण नहीं। सॉफ़्टवेयर इंस्टॉल और फ़ोल्डर रीडायरेक्ट जैसी कुछ सेटिंग केवल साइन-इन या पुनः आरंभ पर संसाधित होती हैं (यही /logoff और /boot विकल्पों का अस्तित्व है)।³
• निदान का आरंभ बिंदु gpresult /h की RSoP रिपोर्ट है। लागू GPO और अस्वीकृत GPO कारण सहित दिखती हैं। गहराई के लिए GroupPolicy ऑपरेशनल लॉग (Microsoft-Windows-GroupPolicy/Operational) उपयोग करें।⁴⁵
• नियम के रूप में Administrative Template नीतियाँ रजिस्ट्री की समर्पित नीति कुंजियों (Software\Policies आदि) में लिखी जाती हैं। नीति मान ऐप की अपनी सेटिंग से प्राथमिकता लेता है, और Not Configured कुछ भी नहीं लिखता। फिर भी कुछ नीतियाँ समर्पित कुंजियों के बाहर लिखती हैं (अध्याय 5)।⁶
• ADMX सेंट्रल स्टोर SYSVOL में PolicyDefinitions फ़ोल्डर है। बना देने पर GPMC डोमेन-व्यापी टेम्प्लेट परिभाषाएँ वहीं से संदर्भित करने लगता है।⁷
• GPO या Intune डिवाइस की पहचान नींव से चुनें। वही सेटिंग दोनों में कॉन्फ़िगर करने से परिणाम की गारंटी नहीं। माइग्रेशन सोचते समय Group Policy analytics मदद करता है।⁸⁹
• डेवलपर्स के लिए GPO «केवल ग्राहक स्थल पर नहीं चलता» का क्लासिक कारण है। निष्पादन नीति, फ़ायरवॉल स्थानीय नियम मर्ज अक्षम, प्रॉक्सी और ड्राइव कॉन्फ़िगरेशन जैसी सेटिंग — जो ऐप की मान्यताएँ बदल देती हैं — केंद्रीय प्रबंधन से वितरित होती हैं।¹⁰¹¹

2. Group Policy क्या है — स्थानीय GPO और डोमेन GPO

Group Policy वह तंत्र है जिससे व्यवस्थापक Windows सेटिंग केंद्र में परिभाषित कर लक्ष्य कंप्यूटर और उपयोगकर्ताओं पर बाध्य करता है। सेटिंग के बंडल को GPO (Group Policy Object) कहते हैं। GPO दो स्थानों में रह सकती है।

वर्कग्रुप (गैर-डोमेन-joined) PC केवल स्थानीय GPO संसाधित करता है।¹ इसलिए व्यवहार में जब लोग कहते हैं मशीन «GPO से प्रबंधित» है, लगभग हमेशा डोमेन GPO अभिप्रेत होती है।

flowchart TB
    accTitle: वर्कग्रुप PC और डोमेन-joined PC जो GPO संसाधित करते हैं
    accDescr: वर्कग्रुप PC केवल स्थानीय GPO संसाधित करता है, और डोमेन-joined PC स्थानीय GPO के साथ Active Directory से वितरित डोमेन GPO भी संसाधित करता है
    pc{"PC की सदस्यता कैसी है?"}
    pc -->|वर्कग्रुप| wg["केवल स्थानीय GPO संसाधित"]
    pc -->|डोमेन join| dom["स्थानीय+डोमेन GPO"]
    dom -.-> note["व्यवहार में GPO लगभग डोमेन GPO"]

चित्र 1: वर्कग्रुप PC केवल स्थानीय GPO संसाधित करता है, और डोमेन-joined PC डोमेन GPO भी संसाधित करता है।

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

• Computer Configuration: सेटिंग जो उस PC पर साइन-इन करने वाले किसी भी व्यक्ति पर लागू होती हैं। स्टार्टअप पर लागू।
• User Configuration: सेटिंग जो उस उपयोगकर्ता पर लागू होती हैं चाहे वह किसी भी PC पर साइन-इन करे। साइन-इन पर लागू।

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

flowchart TB
    accTitle: GPO की सामग्री की दो श्रेणियाँ
    accDescr: हर GPO में Computer Configuration और User Configuration दो श्रेणियाँ हैं; Computer Configuration स्टार्टअप पर लागू होकर उस PC पर साइन-इन करने वाले किसी पर भी चलती है, और User Configuration साइन-इन पर लागू होकर उस उपयोगकर्ता के किसी भी PC पर चलती है
    gpo["GPO की सामग्री"] --> comp["Computer Configuration"]
    gpo --> user["User Configuration"]
    comp --> boot["स्टार्टअप पर लागू"]
    user --> logon["साइन-इन पर लागू"]
    boot -.-> anyone["साइन-इन करने वाले किसी पर"]
    logon -.-> anypc["किसी भी PC पर लागू"]

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

3. लागू होने की संरचना — LSDOU का «बाद वाला जीतता है» और इनहेरिटेंस नियंत्रण

3.1. LSDOU: स्थानीय → साइट → डोमेन → OU

डोमेन-joined PC पर GPO निम्नलिखित क्रम में संसाधित होती हैं।¹

1. स्थानीय GPO
2. साइट से लिंक GPO
3. डोमेन से लिंक GPO
4. OU (organizational unit) से लिंक GPO — शीर्ष-स्तरीय OU से नीचे संसाधित, लक्ष्य कंप्यूटर/उपयोगकर्ता के सीधे OU की GPO अंतिम

आद्यक्षर लेकर इस क्रम का नाम LSDOU है। मुख्य बात यह है कि यह «सबसे ऊँची प्राथमिकता पहले» नहीं, बल्कि संसाधन का क्रम है। जब कई GPO वही सेटिंग कॉन्फ़िगर करें, बाद में संसाधित जीतती है (जो सेटिंग संघर्ष नहीं करतीं बस जुड़ जाती हैं)।¹ अर्थात लक्ष्य के सबसे निकट OU की GPO सबसे मज़बूत है, और स्थानीय GPO सबसे कमज़ोर। «gpedit.msc में ठीक किया और वापस हो गया» खराबी नहीं — यही विनिर्देश ठीक वैसे काम कर रहा है।

flowchart TB
    accTitle: LSDOU संसाधन क्रम और बाद वाला जीतता है
    accDescr: GPO स्थानीय, साइट, डोमेन, OU क्रम में संसाधित होती हैं, और संघर्ष में बाद में संसाधित GPO जीतती है, इसलिए लक्ष्य के निकट OU की GPO सबसे मज़बूत और स्थानीय GPO सबसे कमज़ोर है
    l["1. स्थानीय GPO"] --> s["2. साइट"]
    s --> d["3. डोमेन"]
    d --> ou["4. OU（ऊपर से क्रम में）"]
    ou --> win["संघर्ष में बाद वाला जीतता है"]
    win -.-> strongest["निकट OU की GPO सबसे मज़बूत"]
    win -.-> weakest["स्थानीय GPO सबसे कमज़ोर"]

चित्र 3: LSDOU संसाधन का क्रम है, और वही सेटिंग संघर्ष करे तो बाद में संसाधित GPO जीतती है।

जब एक ही साइट, डोमेन, या OU से कई GPO लिंक हों, उनके बीच प्राथमिकता GPMC के Linked Group Policy Objects टैब के लिंक क्रम से तय होती है। सबसे छोटे लिंक-क्रम नंबर वाली GPO अंतिम संसाधित होती है और सबसे ऊँची प्राथमिकता लेती है।¹

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

चित्र 4: एक ही लिंक लक्ष्य पर सबसे छोटे लिंक-क्रम नंबर वाली GPO अंतिम संसाधित होकर जीतती है।

3.2. इनहेरिटेंस ब्लॉक और Enforced

डिफ़ॉल्ट क्रम पर अपवाद बना सकते हैं।¹

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

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

चित्र 5: Block Inheritance ऊपर से विरासत रोकता है, पर Enforced GPO ब्लॉक पार कर अवश्य लागू होती है।

Enforced «बाद वाला जीतता है» सिद्धांत तोड़ने वाला तंत्र है, इसलिए अति प्रयोग से RSoP पढ़ते समय सहज-विरोधी परिणाम बढ़ते जाते हैं। स्थापित अभ्यास इसे पूरी कंपनी को अवश्य माननी वाली सुरक्षा सेटिंग तक सीमित रखना है।

3.3. सुरक्षा फ़िल्टरिंग

लिंक स्थान के अलावा, किस पर लागू हो भी GPO-दर-GPO संकीर्ण कर सकते हैं। GPO लागू होने के लिए लक्ष्य उपयोगकर्ता या कंप्यूटर के पास उस GPO पर Read और Apply group policy दोनों अनुमतियाँ होनी चाहिए। डिफ़ॉल्ट से दोनों Authenticated Users (जिसमें उपयोगकर्ता और कंप्यूटर दोनों हैं) को दी जाती हैं, इसलिए GPO लिंक लक्ष्य के नीचे सभी पर लागू होती है। इसे खास सुरक्षा ग्रुप तक संकीर्ण करना सुरक्षा फ़िल्टरिंग है। फ़िल्टर पूरी GPO पर काम करता है; GPO के अंदर सेटिंग-दर-सेटिंग नहीं बदल सकते।¹³

एक महत्वपूर्ण चेतावनी है। दायरा संकीर्ण करते समय डिफ़ॉल्ट Authenticated Users से Read भी न हटाएँ। सुरक्षा अद्यतन MS16-072 (2016) के बाद उपयोगकर्ता नीति कंप्यूटर के सुरक्षा संदर्भ में प्राप्त होती है, इसलिए यदि कंप्यूटर खाता GPO पढ़ न सके, लक्ष्य उपयोगकर्ता के पास दोनों अनुमतियाँ होने पर भी उपयोगकर्ता-लक्षित GPO लागू नहीं होगी।¹⁴ दायरा संकीर्ण करने का सही रूप लक्ष्य ग्रुप को Read + Apply group policy देना और Authenticated Users (या Domain Computers) पर केवल Read छोड़ना है।¹⁴

flowchart TB
    accTitle: सुरक्षा फ़िल्टर का लागू निर्णय
    accDescr: GPO लागू होने के लिए लक्ष्य उपयोगकर्ता या कंप्यूटर के पास Read और Apply group policy दोनों अनुमतियाँ होनी चाहिए, और उपयोगकर्ता-लक्षित GPO के लिए कंप्यूटर खाते का पढ़ सकना भी आवश्यक हो जाता है
    target["लिंक लक्ष्य के नीचे का विषय"] --> perm{"पढ़ना और लागू दोनों अनुमति?"}
    perm -->|नहीं| deny["फ़िल्टर से अस्वीकृत"]
    perm -->|हाँ| usergpo{"उपयोगकर्ता-लक्षित GPO?"}
    usergpo -->|नहीं| apply["लागू होती है"]
    usergpo -->|हाँ| comp{"कंप्यूटर पढ़ सकता है?"}
    comp -->|हाँ| apply
    comp -->|नहीं| deny2["लागू नहीं（MS16-072）"]

चित्र 6: लागू होने को Read और Apply group policy दोनों चाहिए, और उपयोगकर्ता-लक्षित GPO पर कंप्यूटर खाते का पढ़ना भी आवश्यक है।

व्यवहार में दो क्लासिक ठोकरें हैं: «ग्रुप में डाला फिर भी लागू नहीं (कंप्यूटर-लक्षित सेटिंग है, पर ग्रुप में केवल उपयोगकर्ता डाला)» और «ग्रुप से निकाला फिर भी लागू होती रहती है»। बाद वाला बैकग्राउंड रिफ्रेश की प्रतीक्षा से भी नहीं छूटता। ग्रुप सदस्यता साइन-इन पर बने सुरक्षा टोकन से मूल्यांकित होती है, इसलिए उपयोगकर्ता का ग्रुप बदलाव साइन-आउट/साइन-इन चक्र के बाद, और कंप्यूटर का ग्रुप बदलाव पुनः आरंभ के बाद — नया टोकन जारी होने पर — ही फ़िल्टर तक पहुँचता है।

flowchart TB
    accTitle: ग्रुप बदलाव फ़िल्टर में कब दिखता है
    accDescr: ग्रुप सदस्यता साइन-इन पर बने सुरक्षा टोकन से मूल्यांकित होती है, इसलिए उपयोगकर्ता का बदलाव पुनः साइन-इन और कंप्यूटर का बदलाव पुनः आरंभ से नया टोकन बनने पर ही फ़िल्टर में आता है
    change["ग्रुप के सदस्य बदलें"] --> old["पुराने टोकन से अनपरावर्तित"]
    old --> u["उपयोगकर्ता पुनः साइन-इन"]
    old --> c["कंप्यूटर पुनः आरंभ"]
    u --> token["नए टोकन से मूल्यांकन"]
    c --> token
    token --> ok["फ़िल्टर में परावर्तित"]
    old -.-> bg["बैकग्राउंड रिफ्रेश से हल नहीं"]

चित्र 7: ग्रुप बदलाव साइन-आउट या पुनः आरंभ से नया टोकन बनने पर ही फ़िल्टर में आता है।

साझा PC या Remote Desktop सर्वर जैसी स्थितियों के लिए, जहाँ उस PC पर साइन-इन करने वाले हर व्यक्ति की User Configuration बदलनी हो, लूपबैक प्रोसेसिंग नामक विशेष मोड भी है (कंप्यूटर के स्थान के आधार पर उपयोगकर्ता सेटिंग लागू करने का तंत्र, Replace और Merge मोड सहित)।¹⁵ कियोस्क मशीनों और कक्षा PC पर प्रयुक्त उन्नत सुविधा है, इसलिए यह लेख केवल यह नोट करता है कि वह मौजूद है।

flowchart TB
    accTitle: लूपबैक प्रोसेसिंग का विचार
    accDescr: लूपबैक प्रोसेसिंग कंप्यूटर के स्थान के आधार पर User Configuration लागू करने वाला विशेष मोड है, Replace और Merge दो मोड हैं, और साझा PC या कियोस्क जैसे साइन-इन सभी पर वही उपयोगकर्ता सेटिंग चलाने के दृश्यों में प्रयुक्त होता है
    shared["साझा PC, कियोस्क आदि"] --> lb["लूपबैक प्रोसेसिंग"]
    lb --> base["कंप्यूटर के स्थान से तय"]
    base --> rep["Replace मोड"]
    base --> mrg["Merge मोड"]
    lb -.-> aim["साइन-इन सभी पर लागू"]

चित्र 8: लूपबैक प्रोसेसिंग कंप्यूटर के स्थान के आधार पर User Configuration लागू करने वाला विशेष मोड है, Replace और Merge दो मोड सहित।

4. कब लागू होती है — फ़ोरग्राउंड प्रोसेसिंग और बैकग्राउंड रिफ्रेश

«कॉन्फ़िगर किया पर लागू नहीं हुआ» का आधा बस इतना है कि लागू होने का समय अभी आया नहीं। लागू होने के दो प्रकार हैं।²

अर्थात चल रहे डिवाइस जो डोमेन नियंत्रक तक पहुँच सकें, उन पर बैकग्राउंड रिफ्रेश समर्थित सेटिंग GPO बदलने के बाद बिना और कार्रवाई लगभग दो घंटे में फैल जाती हैं। ऑफ़लाइन डिवाइस, या बिना VPN ऑफ-साइट लैपटॉप, अगली बार DC तक पहुँचने तक नहीं पाते। केवल फ़ोरग्राउंड प्रोसेसिंग से लागू सेटिंग को अतिरिक्त रूप से स्टार्टअप या साइन-इन की प्रतीक्षा करनी पड़ती है। जल्दी हो तो लक्ष्य PC पर gpupdate चलाएँ। डिफ़ॉल्ट से केवल बदली सेटिंग लागू होती हैं; /force जोड़ने से बदली हो या न हो हर सेटिंग पुनः लागू होती है।³

rem केवल बदली सेटिंग अद्यतन (आमतौर पर काफ़ी)
gpupdate

rem हर सेटिंग पुनः लागू (कैश अवस्था का संदेह हो)
gpupdate /force

flowchart TB
    accTitle: DC तक पहुँच और लागू कैसे पहुँचती है
    accDescr: डोमेन नियंत्रक तक पहुँच सकने वाले चल रहे डिवाइस पर बैकग्राउंड रिफ्रेश समर्थित सेटिंग लगभग दो घंटे में फैल जाती हैं, पर ऑफ़लाइन या बिना VPN ऑफ-साइट PC अगली बार DC से जुड़ने तक नहीं पाते
    pc{"DC तक पहुँच सकते हैं?"}
    pc -->|हाँ| ok["लगभग 2 घंटे में फैलती है"]
    pc -->|नहीं| ng["जुड़ने तक नहीं आती"]
    ng -.-> ex["ऑफ़लाइन या बिना VPN ऑफ-साइट PC"]

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

ध्यान रहे कि कुछ सेटिंग gpupdate से लागू होती ही नहीं। उपयोगकर्ता-लक्षित सॉफ़्टवेयर इंस्टॉल और फ़ोल्डर रीडायरेक्ट केवल साइन-इन पर, और कंप्यूटर-लक्षित सॉफ़्टवेयर इंस्टॉल केवल स्टार्टअप पर संसाधित होते हैं। gpupdate इसी लिए /logoff (अद्यतन के बाद साइन-आउट) और /boot (अद्यतन के बाद पुनः आरंभ) विकल्प देता है।³ «gpupdate /force चलाया फिर भी नहीं आया» कहने से पहले जाँचें कि सेटिंग पुनः आरंभ या साइन-इन चाहने वाले प्रकार की तो नहीं।

flowchart TB
    accTitle: सेटिंग लागू होने के मार्ग
    accDescr: GPO बदलाव बैकग्राउंड रिफ्रेश समर्थित सेटिंग हो तो डिफ़ॉल्ट लगभग 90 मिनट और 0–30 मिनट ऑफ़सेट में पहुँचता है, केवल फ़ोरग्राउंड से लागू सेटिंग को स्टार्टअप या साइन-इन की प्रतीक्षा करनी पड़ती है, और जल्दी वाले gpupdate पर फ़ोरग्राउंड सेटिंग को /logoff या /boot चाहिए
    change["GPO बदलें"] --> kind{"बैकग्राउंड रिफ्रेश समर्थित?"}
    kind -->|हाँ| bg["लगभग 90 मिनट+0–30 मिनट में"]
    kind -->|नहीं| fg["स्टार्टअप या साइन-इन पर लागू"]
    bg --> done["परावर्तित"]
    fg --> done
    rush["जल्दी हो तो"] -.-> upd["gpupdate चलाएँ"]
    upd -.-> force["/force से सब पुनः लागू"]
    upd -.-> reboot["फ़ोरग्राउंड को /logoff या /boot"]

चित्र 10: बैकग्राउंड रिफ्रेश केवल समर्थित सेटिंग पहुँचाता है; केवल फ़ोरग्राउंड से लागू सेटिंग को gpupdate के बाद भी साइन-आउट या पुनः आरंभ चाहिए।

5. लागू न होने पर छाँटना — gpresult, इवेंट लॉग, और रजिस्ट्री

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

कई GPO परत दर परत चढ़ने के बाद अंतिम परिणाम (RSoP: Resultant Set of Policy) जाँचने का मानक उपकरण gpresult है। ऊँचे कमांड प्रॉम्प्ट से HTML रिपोर्ट निकालना सबसे पठनीय तरीका है।⁴⁵

rem उपयोगकर्ता और कंप्यूटर दोनों का RSoP HTML रिपोर्ट में
gpresult /h C:\temp\gp-report.html /f

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

रिपोर्ट में पहले ये तीन बातें देखें:

1. लागू GPO की सूची — आप जिस GPO के पीछे हैं वह मौजूद है?
2. अस्वीकृत GPO की सूची, कारण सहित — सुरक्षा फ़िल्टर, WMI फ़िल्टर, या खाली GPO जैसे लागू न होने के कारण यहाँ दिखते हैं⁵
3. प्रत्येक सेटिंग का Winning GPO — लक्ष्य सेटिंग किस GPO के मान से तय हुई। कोई दूसरी GPO जीत रही हो तो अध्याय 3 की प्राथमिकता नियम पुनर्विचार करें

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

चित्र 11: RSoP रिपोर्ट लागू GPO, अस्वीकृत GPO और कारण, फिर प्रत्येक सेटिंग के Winning GPO क्रम से देखें।

5.2. GroupPolicy ऑपरेशनल लॉग

जब gpresult काफ़ी न हो — मान लें प्रोसेसिंग पूरी तरह विफल हो रही है, या बहुत लंबा लग रहा है — Event Viewer में GroupPolicy ऑपरेशनल लॉग देखें। स्थान Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational है (लॉग नाम Microsoft-Windows-GroupPolicy/Operational)। यहाँ नीति प्रोसेसिंग का पूरा विस्तार, आरंभ से अंत तक, लागू GPO की सूची और अस्वीकृत GPO की सूची (कारण सहित) दर्ज होता है। नीति प्रोसेसिंग के प्रत्येक चक्र को अद्वितीय ActivityID मिलता है, इसलिए Microsoft की अनुशंसित प्रक्रिया सिस्टम लॉग की चेतावनी या त्रुटि से ActivityID उठाना और कस्टम व्यू से केवल उसी एक चक्र तक छानना है।⁵

flowchart TB
    accTitle: GroupPolicy ऑपरेशनल लॉग छानने की प्रक्रिया
    accDescr: GroupPolicy ऑपरेशनल लॉग में नीति प्रोसेसिंग के प्रत्येक चक्र को अद्वितीय ActivityID मिलता है, इसलिए सिस्टम लॉग की चेतावनी या त्रुटि से ActivityID उठाएँ और कस्टम व्यू से केवल उसी एक चक्र की घटनाएँ पढ़ें
    sys["सिस्टम लॉग की चेतावनी या त्रुटि"] --> aid["ActivityID उठाएँ"]
    aid --> cv["कस्टम व्यू से छानें"]
    cv --> one["एक चक्र की घटनाएँ पढ़ें"]
    one -.-> rec["लागू व अस्वीकृत GPO कारण सहित"]

चित्र 12: ऑपरेशनल लॉग सिस्टम लॉग से ActivityID उठाकर कस्टम व्यू से नीति प्रोसेसिंग के एक चक्र तक छानकर पढ़ें।

5.3. रजिस्ट्री की Policies कुंजी से संबंध

Administrative Template नीतियाँ (अगला अध्याय) अंततः रजिस्ट्री मान के रूप में लिखी जाती हैं। नियम के रूप में वे निम्नलिखित समर्पित नीति कुंजियों में लिखी जाती हैं।⁶

• HKEY_LOCAL_MACHINE\Software\Policies (Computer Configuration; अनुशंसित स्थान)
• HKEY_CURRENT_USER\Software\Policies (User Configuration; अनुशंसित स्थान)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

यहाँ एक महत्वपूर्ण डिज़ाइन सिद्धांत काम करता है। नीति-सक्षम ऐप पहले Policies कुंजी पढ़ता है; मान हो तो वह प्राथमिकता लेता है; न हो तो ऐप अपनी सेटिंग (preference) या डिफ़ॉल्ट पर गिरता है। Not Configured नीति रजिस्ट्री में कुछ भी नहीं लिखती।⁶ अर्थात Administrative Template नीतियाँ ऐप की अपनी सेटिंग अधिलेखित कर «टैटू» (tattooing) नहीं छोड़तीं — बल्कि अलग स्थान पर रखा बाध्य मान प्राथमिकता से देखा जाता है। नीति कॉन्फ़िगर करना बंद करें तो ऐप अपनी सेटिंग मान मानने पर लौट आता है।

flowchart TB
    accTitle: नीति मान और ऐप सेटिंग की प्राथमिकता
    accDescr: नीति-सक्षम ऐप पहले Policies कुंजी पढ़ता है और मान हो तो उसे प्राथमिकता देता है, नहीं तो अपनी सेटिंग या डिफ़ॉल्ट उपयोग करता है, और Not Configured नीति रजिस्ट्री में कुछ नहीं लिखती
    app["नीति-सक्षम ऐप सेटिंग पढ़ता है"] --> haspol{"Policies कुंजी में मान?"}
    haspol -->|हाँ| pol["नीति मान प्राथमिक"]
    haspol -->|नहीं| pref["अपनी सेटिंग या डिफ़ॉल्ट"]
    notconf["Not Configured नीति"] -.-> nowrite["रजिस्ट्री में कुछ नहीं लिखती"]

चित्र 13: नीति ऐप की अपनी सेटिंग अधिलेखित नहीं करती; अलग स्थान पर रखा बाध्य मान प्राथमिकता से देखा जाता है।

फिर भी हर नीति समर्पित कुंजी में नहीं लिखती। कुछ अंतर्निर्मित OS सेटिंग (उदाहरण: Enable Win32 long paths HKLM\SYSTEM\CurrentControlSet\Control\FileSystem के LongPathsEnabled में लिखता है), साथ पुरानी पीढ़ी या तृतीय-पक्ष टेम्प्लेट, समर्पित कुंजियों के बाहर मनमाने पथ पर लिखते हैं। ऐसी सेटिंग पर नीति कॉन्फ़िगर करना बंद करने के बाद भी मान ज्यों का त्यों रहता है। दी गई सेटिंग वास्तव में किस कुंजी में लिखती है, ADMX परिभाषा, सेटिंग का विवरण पाठ, या gpresult रिपोर्ट से जाँचें।

दूसरे शब्दों में, ऊपर का सुव्यवस्थित डिज़ाइन केवल Administrative Templates (समर्पित नीति कुंजियाँ) की सीमा में है। स्क्रिप्ट या Group Policy Preferences Policies कुंजी के बाहर जो मान लिखें वे साधारण रजिस्ट्री मान जैसे व्यवहार करते हैं, और वितरण बंद करने पर उन्हें स्वतः वापस करने का तंत्र इस ढाँचे में नहीं है। निदान में सबसे तेज़ और विश्वसनीय तरीका सीधे देखना है कि लक्ष्य सेटिंग Policies कुंजी के नीचे लिखी है या नहीं।

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

flowchart TB
    accTitle: लागू न होने पर छाँटने की प्रक्रिया
    accDescr: पहले gpresult की RSoP रिपोर्ट से लागू और अस्वीकृत GPO जाँचें, काफ़ी न हो तो GroupPolicy ऑपरेशनल लॉग ActivityID से छानें, और वितरित वास्तविक मान रजिस्ट्री की Policies कुंजी में सीधे देखें
    start["सेटिंग लागू नहीं होती"] --> rsop["gpresult /h से RSoP जाँचें"]
    rsop --> found{"लागू व अस्वीकृति का कारण स्पष्ट?"}
    found -->|हाँ| fix["प्राथमिकता या फ़िल्टर पुनर्विचार"]
    found -->|नहीं| oplog["GroupPolicy ऑपरेशनल लॉग देखें"]
    oplog -.-> aid["ActivityID से एक चक्र छानें"]
    rsop -.-> reg["Policies कुंजी का वास्तविक मान सीधे जाँचें"]

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

6. Administrative Templates (ADMX) और सेंट्रल स्टोर

GPMC के Administrative Templates के नीचे सूचीबद्ध सेटिंग की परिभाषाएँ ADMX फ़ाइलें (परिभाषा का शरीर) प्लस ADML फ़ाइलें (प्रत्येक भाषा के प्रदर्शन स्ट्रिंग) के रूप में लिखी जाती हैं। हर PC पर OS-प्रदत्त परिभाषाएँ C:\Windows\PolicyDefinitions के नीचे हैं, और प्रबंधन उपकरण सेटिंग स्क्रीन बनाने इन्हें लोड करते हैं।⁷

डोमेन में संचालन हो तो मूल कदम सेंट्रल स्टोर बनाना है। डोमेन नियंत्रक के SYSVOL के नीचे PolicyDefinitions फ़ोल्डर बनाएँ (उदाहरण: \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), और उसकी सामग्री डोमेन के हर डोमेन नियंत्रक पर दोहराई जाती है; Group Policy उपकरण तब डिफ़ॉल्ट से सेंट्रल स्टोर संदर्भित करते हैं।⁷ इससे «प्रबंधन वर्कस्टेशन-दर-वर्कस्टेशन टेम्प्लेट संस्करण भिन्न, दिखाई सेटिंग मेल नहीं खाती» की समस्या मिटती है। ADML फ़ाइलें भाषा-विशिष्ट सबफ़ोल्डर में जाती हैं (जापानी के लिए ja-JP)।⁷

flowchart TB
    accTitle: सेंट्रल स्टोर की संरचना
    accDescr: डोमेन नियंत्रक के SYSVOL के नीचे PolicyDefinitions फ़ोल्डर बनाने से सामग्री हर डोमेन नियंत्रक पर दोहराई जाती है, और Group Policy उपकरण डिफ़ॉल्ट से सेंट्रल स्टोर संदर्भित करते हैं, इसलिए प्रबंधन टर्मिनल-दर-टर्मिनल परिभाषा अंतर मिट जाता है
    create["SYSVOL के नीचे बनाएँ"] --> cs["PolicyDefinitions"]
    cs --> repl["सभी DC पर दोहराया जाता है"]
    cs --> ref["GP उपकरण डिफ़ॉल्ट से संदर्भित"]
    ref -.-> benefit["टर्मिनल-दर-टर्मिनल परिभाषा अंतर मिटता है"]
    cs -.-> adml["ADML भाषा फ़ोल्डर में"]

चित्र 15: SYSVOL का PolicyDefinitions हर डोमेन नियंत्रक पर दोहराया जाता है, और Group Policy उपकरण डिफ़ॉल्ट से उसे संदर्भित करते हैं।

संचालन की दो चेतावनियाँ हैं। पहली, Microsoft प्रत्येक नए Windows संस्करण के लिए नए ADMX वितरित करता है, और अद्यतन करते समय सेंट्रल स्टोर पक्ष बदलते हैं। प्रत्येक PC पर C:\Windows\PolicyDefinitions को डाउनलोड संस्करण से बदलना समर्थित नहीं है।⁷ दूसरी, मौजूदा सेंट्रल स्टोर अद्यतन करते समय मार्गदर्शन प्रोडक्शन PolicyDefinitions सीधे अधिलेखित न करने का है। इसके बजाय OS वाले और Office व Edge जैसे ऐप वाले ADMX का पूरा सेट PolicyDefinitions-24H2 जैसे संस्करण-नाम कार्य फ़ोल्डर में इकट्ठा करें, वर्तमान फ़ोल्डर का नाम PolicyDefinitions-23H2 जैसे बदलकर हटाएँ, फिर कार्य फ़ोल्डर का नाम PolicyDefinitions कर प्रोडक्शन बनाएँ।⁷ Group Policy उपकरण केवल शाब्दिक नाम PolicyDefinitions वाले फ़ोल्डर संदर्भित करते हैं, इसलिए संस्करण-नाम फ़ोल्डर में फ़ाइलें रखना कोई प्रभाव नहीं डालता। इस दृष्टिकोण का लाभ: समस्या आए तो हटाए फ़ोल्डर पर लौट सकते हैं।⁷

flowchart TB
    accTitle: सेंट्रल स्टोर अद्यतन की प्रक्रिया
    accDescr: अद्यतन संस्करण-नाम कार्य फ़ोल्डर में OS वाले और ऐप वाले ADMX का पूरा सेट इकट्ठा करता है, वर्तमान फ़ोल्डर का नाम बदलकर हटाता है, फिर कार्य फ़ोल्डर का नाम प्रोडक्शन PolicyDefinitions कर देता है, और समस्या आए तो हटाए पुराने फ़ोल्डर पर लौटता है
    work["संस्करण-नाम कार्य फ़ोल्डर"] --> gather["OS वाले और ऐप वाले इकट्ठा करें"]
    gather --> evac["वर्तमान का नाम बदलकर हटाएँ"]
    evac --> rename["कार्य फ़ोल्डर को प्रोडक्शन नाम"]
    rename --> live["प्रोडक्शन के रूप में संदर्भित"]
    live -.-> back["समस्या पर पुराना फ़ोल्डर वापस"]

चित्र 16: अद्यतन कार्य फ़ोल्डर में पूरा सेट इकट्ठा करता है, वर्तमान हटाता है, फिर नाम बदलकर प्रोडक्शन बनाता है।

7. GPO बनाम Intune (MDM/CSP) बनाम मैनुअल/स्क्रिप्ट — निर्णय तालिका

Windows डिवाइस कॉन्फ़िगरेशन प्रबंधन का विकल्प अब केवल GPO नहीं। Intune से चिह्नित MDM, CSP (Configuration Service Provider) नामक तंत्र से OS सेटिंग कॉन्फ़िगर करता है। किसे अक्ष बनाएँ, इसकी निर्णय तालिका है।

निर्णय का अक्ष सरल है: डिवाइस की पहचान नींव (AD, या Microsoft Entra) और डिवाइस कहाँ है। ऑन-प्रिमाइसेस AD से पूर्ण-joined कार्यालय के डेस्क-बद्ध PC के बेड़े पर GPO सबसे विश्वसनीय है; Entra-joined मोबाइल PC तक GPO पहुँचती ही नहीं।

वास्तविकता में अधिकांश छोटे और मध्यम व्यवसाय बीच में बैठते हैं, हाइब्रिड सेटअप (डोमेन-joined प्लस Intune-नामांकित) में, और यहाँ सबसे बुरी बात «वही सेटिंग GPO और MDM दोनों से कॉन्फ़िगर करना» है। Policy CSP में MDMWinsOverGP नीति है जो GPO और MDM संघर्ष पर MDM जीतवा सकती है, पर उसका दायरा Policy CSP के अंदर संबंधित नीतियों तक सीमित है। Microsoft स्वयं स्पष्ट है कि उस नियंत्रण के बाहर सेटिंग GPO और MDM दोनों से कॉन्फ़िगर करना रेस कंडीशन पैदा करता है जिसकी जीत की गारंटी नहीं, और दोहरी कॉन्फ़िगरेशन से बचना चाहिए।⁸ हाइब्रिड संचालन का पहला सिद्धांत सेटिंग-क्षेत्र के अनुसार «यह GPO, यह Intune» तय कर प्रबंधन अधिकार एक तरफ रखना है।

flowchart TB
    accTitle: GPO और Intune का चुनाव
    accDescr: डिवाइस की पहचान नींव ऑन-प्रिमाइसेस AD और कार्यालय में हो तो GPO, Entra join या ऑफ-साइट डिवाइस हो तो Intune उपयुक्त है, और हाइब्रिड में वही सेटिंग दोहरी कॉन्फ़िगर न कर क्षेत्र के अनुसार प्रबंधन एक तरफ रखें
    q{"डिवाइस का आधार और स्थान?"}
    q -->|AD join और कार्यालय में| gpo["GPO विश्वसनीय और बारीक"]
    q -->|Entra join या ऑफ-साइट| intune["Intune ऑफ-साइट भी पहुँचता है"]
    q -->|हाइब्रिड| split["क्षेत्र के अनुसार एक तरफ रखें"]
    split -.-> warn["दोहरी कॉन्फ़िग परिणाम गारंटी नहीं"]
    split -.-> ana["छाँटने को Group Policy analytics"]

चित्र 17: चुनाव डिवाइस की पहचान नींव और स्थान से तय करें, और हाइब्रिड में वही सेटिंग GPO और MDM दोनों से कॉन्फ़िगर न करें।

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

flowchart TB
    accTitle: Group Policy analytics से छाँटना
    accDescr: GPMC से XML रूप में निर्यात GPO Group Policy analytics में आयात करने से सेटिंग-दर-सेटिंग MDM समर्थित है या अप्रचलित या असमर्थित छँटती है, और समर्थित सेटिंग Settings catalog नीति में माइग्रेट हो सकती हैं
    exp["GPMC से XML निर्यात"] --> imp["analytics में आयात"]
    imp --> ana["सेटिंग-दर-सेटिंग समर्थन विश्लेषण"]
    ana --> ok["MDM समर्थित"]
    ana --> dep["अप्रचलित या असमर्थित"]
    ok --> mig["Settings catalog नीति में माइग्रेट"]

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

8. डेवलपर की दृष्टि का जाल — ग्राहक GPO ऐप का व्यवहार कैसे बदलती है

अंत में, अनुबंध विकास के पद से जानने योग्य बात। ग्राहक की GPO आपके ऐप की मान्यताएँ चुपचाप अधिलेखित कर देती है। फ़ायरवॉल और एंटीवायरस के साथ, GPO «डेव मशीन पर चलता है ग्राहक पर नहीं» के नियमित अपराधी में है। कुछ ठोस उदाहरण।

• PowerShell की निष्पादन नीति: निष्पादन नीति GPO से केंद्र में कॉन्फ़िगर हो सकती है, और GPO-व्युत्पन्न MachinePolicy/UserPolicy स्कोप स्थानीय या प्रक्रिया पर सेट मान से हमेशा प्राथमिकता लेते हैं।¹⁰ यदि इंस्टॉलर या संचालन स्क्रिप्ट «-ExecutionPolicy Bypass जोड़ने से चल जाएगी» मान्यता पर बनी है, GPO प्रबंधन के नीचे वह चालू भी नहीं होती। विवरण «PowerShell निष्पादन नीति और स्क्रिप्ट हस्ताक्षर — Bypass से ढकने से आगे बढ़ने की व्यावहारिक मार्गदर्शिका» में।
• फ़ायरवॉल पर स्थानीय नियम मर्ज अक्षम: जिन वातावरणों में फ़ायरवॉल GPO/Intune से केंद्र में प्रबंधित है, प्रोफ़ाइल-दर-प्रोफ़ाइल «स्थानीय नियम मर्ज» (AllowLocalPolicyMerge) अक्षम हो सकता है। जहाँ अक्षम हो, इंस्टॉलर का स्थानीय रूप से पंजीकृत इनबाउंड नियम मौजूद होता है पर लागू नहीं होता।¹¹ सर्वर-प्रकार ऐप परिनियोजित करने से पहले अवश्य पुष्टि करने योग्य बिंदु है; विस्तार «Windows फ़ायरवॉल और व्यावसायिक ऐप» में।
• ड्राइव मैप और प्रॉक्सी जैसी पर्यावरण कॉन्फ़िगरेशन: नेटवर्क ड्राइव मैप, प्रिंटर आदि आमतौर पर Group Policy Preferences से वितरित होते हैं।¹⁶ पर्यावरण की मान्यताएँ — «Z ड्राइव होना चाहिए», «प्रॉक्सी डायरेक्ट कनेक्शन होना चाहिए» — साइन-इन उपयोगकर्ता या PC की OU सदस्यता से टूट सकती हैं। निवासी-प्रकार ऐप के लिए यह भी आसानी से छूटता है कि User Configuration से वितरित सेटिंग सेवा या शेड्यूल्ड टास्क के खाते पर स्वाभाविक रूप से लागू नहीं होती।
• सेटिंग «वापस बदली ही नहीं जा सकती»: Administrative Templates से आई सेटिंग आमतौर पर उपयोगकर्ता UI से बदल ही नहीं सकता (आइटम धूसर)। «ग्राहक सेटिंग बदल दे तो ठीक हो जाएगा» न चलना समर्थन दृष्टिकोण के डिज़ाइन पर वास्तविक प्रभाव डालता है।

flowchart TB
    accTitle: ग्राहक GPO ऐप की मान्यताएँ कैसे बदलती है
    accDescr: ग्राहक की GPO निष्पादन नीति बाध्य करने, फ़ायरवॉल स्थानीय नियम मर्ज अक्षम करने, ड्राइव या प्रॉक्सी वितरित करने, और उपयोगकर्ता सेटिंग वापस न बदल पाने के रूप में ऐप की पूर्वापेक्षाएँ बदलती है, और केवल ग्राहक पर न चलने का एक कारण बनती है
    gpo["ग्राहक की GPO"] --> ep["निष्पादन नीति बाध्य"]
    gpo --> fw["स्थानीय नियम मर्ज अक्षम"]
    gpo --> env["ड्राइव व प्रॉक्सी वितरण"]
    gpo --> lock["सेटिंग वापस नहीं बदल सकते"]
    ep --> sym["केवल ग्राहक पर न चलने का कारण"]
    fw --> sym
    env --> sym
    lock --> sym

चित्र 19: ग्राहक की GPO निष्पादन नीति, फ़ायरवॉल, पर्यावरण कॉन्फ़िगरेशन जैसी ऐप की पूर्वापेक्षाएँ चुपचाप अधिलेखित कर देती है।

विकास पक्ष की यथार्थ तीन तैयारियाँ हैं। पहली, ऐप जिन पर्यावरण मान्यताओं पर निर्भर है — निष्पादन नीति, सुनने वाले पोर्ट, लिखने का स्थान, प्रॉक्सी पथ आदि — को परिनियोजन आवश्यकता के रूप में दस्तावेज़ित करें और परिनियोजन से पहले ग्राहक IT से पुष्टि करवाएँ। दूसरी, समस्या आए तो अनुमान नहीं, gpresult /h रिपोर्ट और HKLM\Software\Policies के नीचे वास्तविक मान जाँचें (अध्याय 5)। तीसरी, डिज़ाइन चरण में कौन से ऑपरेशन व्यवस्थापक विशेषाधिकार चाहते हैं और कौन नहीं अलग रखें (यह रेखा «Windows पर व्यवस्थापक विशेषाधिकार वास्तव में कब चाहिए? - UAC, संरक्षित क्षेत्र, और डिज़ाइन से कैसे पहचानें» में खिंची है)। GPO शत्रु नहीं — वातावरण का विनिर्देश है। विनिर्देश की तरह सँभालें तो निदान यांत्रिक हो जाता है।

flowchart TB
    accTitle: विकास पक्ष की तीन तैयारियाँ
    accDescr: विकास पक्ष की तैयारी ऐप की पर्यावरण मान्यताएँ परिनियोजन आवश्यकता के रूप में दस्तावेज़ित कर परिनियोजन से पहले ग्राहक IT से पुष्टि करवाना, समस्या पर gpresult रिपोर्ट और Policies कुंजी के वास्तविक मान जाँचना, और व्यवस्थापक विशेषाधिकार चाहने वाले ऑपरेशन डिज़ाइन चरण में अलग रखना है
    dev["विकास पक्ष की तैयारी"] --> doc["1. पर्यावरण मान्यताएँ दस्तावेज़ित"]
    dev --> chk["2. gpresult व वास्तविक मान जाँचें"]
    dev --> priv["3. विशेषाधिकार की ज़रूरत डिज़ाइन में अलग"]
    doc -.-> ask["परिनियोजन से पहले ग्राहक IT से पुष्टि"]

चित्र 20: विकास पक्ष की तैयारी पर्यावरण मान्यताएँ दस्तावेज़ित करना, gpresult और वास्तविक मान जाँचना, और व्यवस्थापक विशेषाधिकार की ज़रूरत डिज़ाइन में अलग रखना है।

9. सारांश

• Group Policy GPO-स्तरीय सेटिंग स्थानीय → साइट → डोमेन → OU (LSDOU) क्रम में संसाधित करने का तंत्र है, और संघर्ष बाद-वाले-की-जीत से हल होते हैं। लक्ष्य के निकट OU की GPO सबसे मज़बूत परत है, स्थानीय GPO सबसे कमज़ोर।
• Block Inheritance, Enforced, और सुरक्षा फ़िल्टरिंग डिफ़ॉल्ट प्रवाह नियंत्रित करते हैं। Enforced Block Inheritance को भी हराता है, इसलिए अति प्रयोग न करें।
• लागू होना दो चैनलों से होता है: स्टार्टअप/साइन-इन पर फ़ोरग्राउंड प्रोसेसिंग, और डिफ़ॉल्ट लगभग 90 मिनट प्लस यादृच्छिक ऑफ़सेट का बैकग्राउंड रिफ्रेश। gpupdate /force हर सेटिंग पुनः लागू करता है, पर केवल साइन-इन या पुनः आरंभ पर संसाधित सेटिंग पर कोई प्रभाव नहीं।
• सेटिंग लागू न हो तो gpresult /h → GroupPolicy ऑपरेशनल लॉग → रजिस्ट्री की Policies कुंजी क्रम से यांत्रिक निदान करें। अस्वीकृत GPO कारण सहित दिखती हैं।
• Administrative Template परिभाषाएँ ADMX/ADML हैं, और डोमेन संचालन उन्हें SYSVOL सेंट्रल स्टोर में एकत्र करे। अद्यतन पर स्थानीय PolicyDefinitions फ़ोल्डर बदलने के बजाय सेंट्रल स्टोर पक्ष बदलें।
• GPO या Intune डिवाइस की पहचान नींव और स्थान से तय होता है; हाइब्रिड सेटअप में वही सेटिंग दोहरी कॉन्फ़िगर न करें और प्रबंधन अधिकार एक तरफ रखें। माइग्रेशन छाँटने को Group Policy analytics मदद करता है।
• डेवलपर्स के लिए ग्राहक GPO वातावरण के विनिर्देश का भाग है। निष्पादन नीति, फ़ायरवॉल, ड्राइव मैप, और प्रॉक्सी कॉन्फ़िगरेशन की मान्यताएँ दस्तावेज़ित करें, और gpresult से पुष्टि की आदत बनाएँ — तो «केवल ग्राहक पर नहीं चलता» के अधिकांश मामले डरावने नहीं रहते।

संबंधित लेख

• Windows फ़ायरवॉल और व्यावसायिक ऐप — इंस्टॉलर से इनबाउंड नियम पंजीकृत करें
• WSUS अप्रचलन के बाद Windows Update प्रबंधन — WUfB, Autopatch, और Intune में कैसे चुनें
• PowerShell निष्पादन नीति और स्क्रिप्ट हस्ताक्षर — Bypass से ढकने से आगे बढ़ने की व्यावहारिक मार्गदर्शिका
• winget + PowerShell से PC प्रावधान स्वचालित करना — रनबुक को निष्पादन योग्य बनाना
• IE मोड निर्भरता से बाहर निकलने की मार्गदर्शिका
• Windows पर व्यवस्थापक विशेषाधिकार वास्तव में कब चाहिए? - UAC, संरक्षित क्षेत्र, और डिज़ाइन से कैसे पहचानें

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

KomuraSoft LLC GPO प्रबंधन के नीचे ग्राहक वातावरण में व्यावसायिक ऐप न चलने की जाँच, परिनियोजन आवश्यकताएँ (निष्पादन नीति, फ़ायरवॉल, नेटवर्क मान्यताएँ) व्यवस्थित करना, और AD वातावरण विरासत में लेने वाले IT स्टाफ के लिए नीति सूची व Intune सह-प्रबंधन योजना पर तकनीकी परामर्श सँभालता है। «gpresult रिपोर्ट साथ पढ़ें» जितने आरंभिक चरण से शुरू करना ठीक है।

• तकनीकी परामर्श और डिज़ाइन समीक्षा
• बग और कारणों की जाँच
• Windows ऐप विकास
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

gpupdate /force चलाया, फिर भी सेटिंग लागू नहीं हुई। क्यों?

पहले जाँचें कि सेटिंग उन प्रकारों में तो नहीं है जिन्हें बैकग्राउंड रिफ्रेश कभी लागू नहीं करता। उपयोगकर्ता-लक्षित सॉफ़्टवेयर इंस्टॉल और फ़ोल्डर रीडायरेक्ट केवल साइन-इन पर, और कंप्यूटर-लक्षित सॉफ़्टवेयर इंस्टॉल केवल स्टार्टअप पर संसाधित होते हैं, इसलिए gpupdate खत्म होने के बाद साइन-आउट (/logoff) या पुनः आरंभ (/boot) चाहिए। फिर gpresult /h से RSoP रिपोर्ट निकालें और देखें कि वह GPO Applied GPOs में है, या Denied GPOs में कारण सहित है। लागू है पर व्यवहार नहीं बदला तो संदेह करें कि ऊँची प्राथमिकता वाली दूसरी GPO वही सेटिंग अधिलेखित कर रही है (बाद वाला जीतता है)। रिपोर्ट प्रत्येक सेटिंग का Winning GPO दिखाती है, इसलिए कौन सी GPO जीत रही है तक तय कर सकते हैं।

gpresult रिपोर्ट में Denied - Filtering का क्या अर्थ है?

अर्थ यह है कि लिंक स्थान के हिसाब से GPO दायरे में है, पर फ़िल्टरिंग ने उसे वास्तव में लागू होने से बाहर कर दिया। सबसे आम कारण सुरक्षा फ़िल्टरिंग है: GPO लागू होने के लिए उपयोगकर्ता या कंप्यूटर के पास उस GPO पर Read और Apply group policy दोनों अनुमतियाँ होनी चाहिए। डिफ़ॉल्ट से दोनों Authenticated Users को दी जाती हैं, पर यदि आपने इसे खास ग्रुप तक संकीर्ण किया है तो ग्रुप सदस्यता चूकना — ग्रुप न जोड़ना, या कंप्यूटर खाता न जोड़ना — अस्वीकृति लाता है। उपयोगकर्ता-लक्षित GPO पर लक्ष्य उपयोगकर्ता को दोनों अनुमतियाँ देना काफ़ी नहीं। MS16-072 के बाद उपयोगकर्ता नीति कंप्यूटर के सुरक्षा संदर्भ में प्राप्त होती है, इसलिए Authenticated Users या Domain Computers पर Read (Apply नहीं) छोड़ना आवश्यक है। अन्य कारण WMI फ़िल्टर का न मिलना, या GPO पर ही उपयोगकर्ता/कंप्यूटर कॉन्फ़िगरेशन अक्षम होना हैं। अस्वीकृति का कारण gpresult रिपोर्ट और GroupPolicy ऑपरेशनल लॉग दोनों में दर्ज होता है।

डिवाइस GPO से प्रबंधित करें या Intune से?

मूल नियम डिवाइस की पहचान नींव से मेल खाना है। यदि डिवाइस मुख्यतः ऑन-प्रिमाइसेस AD से डोमेन-joined हैं और आंतरिक नेटवर्क से स्थायी रूप से जुड़े हैं, GPO सबसे विश्वसनीय और सबसे बारीक विकल्प है। यदि Microsoft Entra-joined डिवाइस अधिक हैं, या घर के ऐसे मशीन जो डोमेन नियंत्रक को छूते ही नहीं, तो Intune (MDM/CSP) बेहतर बैठता है, जो कार्यालय से बाहर भी कॉन्फ़िगरेशन पहुँचा सकता है। दोनों के सह-अस्तित्व वाले हाइब्रिड वातावरण में वही सेटिंग GPO और MDM दोनों से कॉन्फ़िगर करने से संघर्ष होता है और विजेता की गारंटी नहीं, इसलिए सिद्धांत सेटिंग-क्षेत्र के अनुसार कौन प्रबंधित करता है तय कर उसी एक पर टिकना है। माइग्रेशन सोचने लगें तो मौजूदा GPO Intune के Group Policy analytics में आयात करने से सेटिंग MDM-समर्थित और असमर्थित या अप्रचलित में छँट जाती हैं।

स्थानीय Group Policy संपादक (gpedit.msc) से कॉन्फ़िगर की सेटिंग डोमेन सेटिंग से अधिलेखित हो जाती है। क्या यह विनिर्देश है?

हाँ, यही डिज़ाइन है। Group Policy स्थानीय → साइट → डोमेन → OU (LSDOU) क्रम में संसाधित होती है, और संघर्ष में बाद में संसाधित GPO जीतती है, इसलिए स्थानीय GPO सबसे कमज़ोर परत है। यदि डोमेन GPO वही सेटिंग कॉन्फ़िगर करे, स्थानीय बदलाव हमेशा अधिलेखित होगा। उलटा, यदि डोमेन पक्ष वह सेटिंग Not Configured छोड़े, स्थानीय GPO का मान ज्यों का त्यों रहता है। परीक्षण के लिए स्थानीय सेटिंग को प्राथमिकता देनी हो, तब भी डोमेन-joined PC पर इस प्राथमिकता क्रम को उलटने का कोई तरीका नहीं, इसलिए यथार्थ रास्ते हैं समर्पित परीक्षण OU बनाकर डोमेन-पक्ष GPO समायोजित करना, या गैर-डोमेन-joined परीक्षण मशीन उपयोग करना।

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

पहला कदम ग्राहक के व्यवस्थापक से प्रभावित PC पर ऊँचे कमांड प्रॉम्प्ट से gpresult /h report.html चलवाकर RSoP रिपोर्ट देखना है। ऐप का व्यवहार बदलने वाली सेटिंग देखें: निष्पादन नीति से स्क्रिप्ट रुकना, फ़ायरवॉल स्थानीय नियम मर्ज अक्षम, या कॉन्फ़िगर प्रॉक्सी और ड्राइव मैप। साथ ही रजिस्ट्री में HKLM\Software\Policies और HKCU\Software\Policies के नीचे संबंधित उत्पाद के नीति मान लिखे हैं या नहीं जाँचें — इससे Administrative Templates से आई बाध्य सेटिंग यांत्रिक रूप से झंडित होती हैं। विकास पक्ष की यथार्थ तैयारी ऐप जिन मान्यताओं पर निर्भर है — निष्पादन नीति, सुनने वाले पोर्ट, लिखने का फ़ोल्डर आदि — को परिनियोजन आवश्यकता के रूप में दस्तावेज़ित करना और परिनियोजन से पहले ग्राहक IT से पुष्टि करवाना है।

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

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

Go Komura

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

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