Group Policy (GPO)-এর বাস্তব নির্দেশিকা — কীভাবে কাজ করে, প্রয়োগ নিশ্চিত, এবং Intune-এর সাথে বাছাই

«এই সেটিং GPO দিয়ে বিতরণ করা», «গ্রাহকের PC Group Policy দিয়ে বাঁধা» — Windows ব্যবসায়িক সিস্টেম নিয়ে কাজ করলে এই «GPO» শব্দ রোজ ঘোরে। তবু নিজে AD পরিবেশের আইটি কাজ হাতে নিলে, বা গ্রাহকের ডোমেইন-joined PC-তে অ্যাপ বসালে, Group Policy কখন, কোথা থেকে, কোন অগ্রাধিকার ক্রমে প্রয়োগ হয় সঠিক করে বলতে পারেন এমন লোক অপ্রত্যাশিতভাবে কম।

«সেটিং বদলালাম তবু প্রয়োগ হচ্ছে না», «gpupdate চালাতে বলা হলো কিন্তু কী হচ্ছে বুঝি না», «ডেভ মেশিনে চলা অ্যাপ শুধু গ্রাহকে চলে না, খুঁজে দেখি GPO» — এই নিবন্ধ এমন পরিস্থিতিতে পড়া ব্যবসায়িক-অ্যাপ ডেভেলপার এবং AD পরিবেশ উত্তরাধিকার পাওয়া ছোট ও মাঝারি ব্যবসার আইটি কর্মীদের জন্য। Group Policy কীভাবে কাজ করে (LSDOU প্রয়োগ ক্রম), কখন প্রয়োগ হয়, gpresult ও ইভেন্ট লগ দিয়ে ছাঁটাই, ADMX ও সেন্ট্রাল স্টোর, এবং Intune (MDM)-এর সাথে বাছাই — আগস্ট ২০২৬ পর্যন্ত প্রাথমিক উৎসের ভিত্তিতে সাজায়।

1. আগে উপসংহার

• Group Policy «পরে-আসা জেতে»। স্থানীয় → সাইট → ডোমেইন → OU (LSDOU) ক্রমে প্রক্রিয়া হয়, পরে প্রক্রিয়া হওয়া GPO সংঘর্ষে অগ্রাধিকার পায়। স্থানীয় GPO (gpedit.msc) সবচেয়ে দুর্বল স্তর।¹
• প্রয়োগের সময় «ফোরগ্রাউন্ড + ব্যাকগ্রাউন্ড»। কম্পিউটার কনফিগারেশন স্টার্টআপে, ব্যবহারকারী কনফিগারেশন সাইন ইনে অবশ্যই প্রয়োগ হয়, তার উপর ডিফল্টে প্রায় ৯০ মিনিট + ০–৩০ মিনিট র‍্যান্ডম অফসেটে ব্যাকগ্রাউন্ড আপডেট হয় (ডোমেইন কন্ট্রোলারে ৫ মিনিট)।²
• gpupdate /force «সব সেটিং আবার প্রয়োগ» — সর্বরোগহর নয়। সফটওয়্যার ইনস্টল বা ফোল্ডার রিডাইরেক্টের মতো সেটিং শুধু সাইন ইন বা রিস্টার্টে প্রক্রিয়া হয় (/logoff ও /boot অপশনের অস্তিত্বের কারণ)।³
• ছাঁটাইয়ের শুরু gpresult /h-এর RSoP রিপোর্ট। প্রয়োগ হওয়া GPO ও প্রত্যাখ্যাত GPO (কারণসহ) দেখা যায়। গভীরে GroupPolicy অপারেশনাল লগ (Microsoft-Windows-GroupPolicy/Operational)।⁴⁵
• Administrative template নীতি নিয়ম হিসেবে রেজিস্ট্রির নীতি-নির্দিষ্ট কীতে (Software\Policies ইত্যাদি) লেখা হয়। নীতি মান অ্যাপের নিজের সেটিং-এর উপরে অগ্রাধিকার পায়, আর «Not Configured» কিছু লেখে না। তবে নির্দিষ্ট কী-এর বাইরে লেখে এমন নীতিও কিছু আছে (৫ অধ্যায়)।⁶
• ADMX সেন্ট্রাল স্টোর SYSVOL-এর PolicyDefinitions ফোল্ডার। তৈরি রাখলে GPMC ডোমেইন-সাধারণ টেমপ্লেট সংজ্ঞা সেখান থেকে দেখে।⁷
• GPO না Intune টার্মিনালের পরিচয় ভিত্তিতে স্থির করুন। একই সেটিং দুইতে কনফিগার করলে ফল নিশ্চিত নয়। মাইগ্রেশন ভাবার সময় Group Policy analytics কাজে লাগে।⁸⁹
• ডেভেলপারের কাছে GPO «শুধু গ্রাহকে চলে না»-এর ক্লাসিক কারণ। এক্সিকিউশন পলিসি, ফায়ারওয়ালের স্থানীয় নিয়ম মার্জ অক্ষম, প্রক্সি ও ড্রাইভ কনফিগারেশনের মতো অ্যাপের পূর্বশর্ত বদলানো সেটিং কেন্দ্রীয় ব্যবস্থাপনায় বিতরণ হয়।¹⁰¹¹

2. Group Policy কী — স্থানীয় GPO ও ডোমেইন GPO

Group Policy সেই ব্যবস্থা যাতে অ্যাডমিনিস্ট্রেটর Windows সেটিং কেন্দ্রীয়ভাবে সংজ্ঞায়িত করে লক্ষ্য কম্পিউটার ও ব্যবহারকারীর উপর জোর করে প্রয়োগ করেন। সেটিং-এর গুচ্ছকে GPO (Group Policy Object) বলে। GPO-এর দুই জায়গা আছে।

ওয়ার্কগ্রুপ (ডোমেইন-বিহীন) 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-এর ভিতর মোটা দাগে দুই ধারা।

• কম্পিউটার কনফিগারেশন: সেই PC-তে সাইন ইন করা যে কাউকে লাগে এমন সেটিং। স্টার্টআপে প্রয়োগ হয়।
• ব্যবহারকারী কনফিগারেশন: সেই ব্যবহারকারী যে PC-তে সাইন ইন করুক লাগে এমন সেটিং। সাইন ইনে প্রয়োগ হয়।

«সেটিং PC-এর সাথে বাঁধা, না মানুষের সাথে» — এই অক্ষ পরে প্রয়োগ ক্রমেও প্রয়োগ নিশ্চিতেও বারবার আসে। একই আইটেম দুই কনফিগারেশনেও থাকতে পারে, তাই সেটিং খুঁজতে সবসময় দুই ধারা দেখার অভ্যাস রাখুন।

flowchart TB
    accTitle: GPO-এর ভিতরের দুই ধারা
    accDescr: প্রতিটি GPO-তে কম্পিউটার কনফিগারেশন ও ব্যবহারকারী কনফিগারেশন দুই ধারা থাকে, কম্পিউটার কনফিগারেশন স্টার্টআপে প্রয়োগ হয়ে সেই PC-তে সাইন ইন করা যে কাউকে লাগে, ব্যবহারকারী কনফিগারেশন সাইন ইনে প্রয়োগ হয়ে সেই ব্যবহারকারী যে PC-তে সাইন ইন করুক না কেন লাগে
    gpo["GPO-এর ভিতর"] --> comp["কম্পিউটার কনফিগারেশন"]
    gpo --> user["ব্যবহারকারী কনফিগারেশন"]
    comp --> boot["স্টার্টআপে প্রয়োগ"]
    user --> logon["সাইন ইনে প্রয়োগ"]
    boot -.-> anyone["সাইন ইন করা যে কাউকে লাগে"]
    logon -.-> anypc["যেকোনো PC-তে লাগে"]

চিত্র 2: GPO-তে PC-বাঁধা কম্পিউটার কনফিগারেশন ও মানুষ-বাঁধা ব্যবহারকারী কনফিগারেশন — দুই ধারা আছে।

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 কনফিগার করলে পরে প্রক্রিয়া হওয়া 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["সবচেয়ে ছোট নম্বরের GPO শেষে"]
    last --> win["পরে-আসা জেতে সর্বোচ্চ অগ্রাধিকার"]

চিত্র 4: একই লিঙ্ক লক্ষ্যে লিঙ্ক ক্রমের সবচেয়ে ছোট নম্বরের GPO শেষে প্রক্রিয়া হয়ে জেতে।

3.2. উত্তরাধিকার ব্লক ও Enforced

ডিফল্ট ক্রমে ব্যতিক্রম তৈরি করা যায়।¹

• Block Inheritance (উত্তরাধিকার ব্লক): ডোমেইন বা OU-তে সেট করলে উপর থেকে GPO উত্তরাধিকার থামে। «এই OU শুধু কোম্পানি-মানক নিতে চায় না» — সেই হাতিয়ার।
• Enforced (পুরোনো নাম: No Override): GPO-এর লিঙ্কে সেট করলে সেই GPO নিচে উত্তরাধিকার ব্লক থাকলেও অবশ্যই প্রয়োগ হয়, আর নিচের GPO দিয়ে ওভাররাইট হয় না। উত্তরাধিকার ব্লক ও Enforced সংঘর্ষে Enforced জেতে।¹

flowchart TB
    accTitle: উত্তরাধিকার ব্লক ও Enforced-এর সম্পর্ক
    accDescr: উত্তরাধিকার ব্লক উপর থেকে GPO উত্তরাধিকার থামায়, কিন্তু Enforced GPO নিচে উত্তরাধিকার ব্লক থাকলেও অবশ্যই প্রয়োগ হয় এবং নিচের GPO দিয়ে ওভাররাইট হয় না
    upper["উপর থেকে আসা GPO"] --> blocked{"নিচে উত্তরাধিকার ব্লক?"}
    blocked -->|না| inherit["যেমন আছে উত্তরাধিকার হয়"]
    blocked -->|হ্যাঁ| enforced{"GPO-তে Enforced আছে?"}
    enforced -->|না| stop["উত্তরাধিকার থেমে যায়"]
    enforced -->|হ্যাঁ| apply["অবশ্যই প্রয়োগ হয়"]
    apply -.-> noover["নিচের GPO দিয়ে ওভাররাইট হয় না"]

চিত্র 5: উত্তরাধিকার ব্লক উপর থেকে উত্তরাধিকার থামায়, কিন্তু Enforced GPO ব্লক পেরিয়ে অবশ্যই প্রয়োগ হয়।

Enforced «পরে-আসা জেতে» নীতি ভাঙে, তাই বেশি ব্যবহার করলে RSoP পড়েও স্বজ্ঞার বিরুদ্ধে ফল বাড়ে। সারা কোম্পানিতে অবশ্যই মানতে হবে এমন নিরাপত্তা সেটিং-এ সীমিত রাখাই রীতি।

3.3. নিরাপত্তা ফিল্টার প্রক্রিয়া

লিঙ্কের জায়গা ছাড়াও, কার উপর প্রয়োগ হবে GPO প্রতি ছাঁটা যায়। GPO প্রয়োগ হতে লক্ষ্য ব্যবহারকারী বা কম্পিউটারের সেই GPO-তে «Read» ও «Apply group policy» দুই অনুমতি থাকতে হয়। ডিফল্টে Authenticated Users (ব্যবহারকারী ও কম্পিউটার দুই)-এ দুটোই দেওয়া, তাই লিঙ্ক লক্ষ্যের নিচের সবাইকে প্রয়োগ হয়। একে নির্দিষ্ট সিকিউরিটি গ্রুপে সীমিত করাই নিরাপত্তা ফিল্টার। ফিল্টার পুরো GPO-তে লাগে; GPO-এর ভিতর সেটিং প্রতি বদলানো যায় না।¹³

একটি গুরুত্বপূর্ণ সতর্কতা। পরিসর ছাঁটতে ডিফল্ট Authenticated Users থেকে «Read» পর্যন্ত তুলবেন না। নিরাপত্তা আপডেট MS16-072 (২০১৬) থেকে ব্যবহারকারী নীতি কম্পিউটারের সিকিউরিটি কনটেক্সটে নেওয়া হয়, তাই কম্পিউটার অ্যাকাউন্ট GPO পড়তে না পারলে লক্ষ্য ব্যবহারকারীকে দুই অনুমতি দিলেও ব্যবহারকারী-লক্ষ্য GPO প্রয়োগ হয় না।¹⁴ ছাঁটতে লক্ষ্য গ্রুপকে «Read + Apply group policy» দিয়ে, Authenticated Users (বা Domain Computers)-এ শুধু «Read» রেখে দেওয়া সঠিক রূপ।¹⁴

flowchart TB
    accTitle: নিরাপত্তা ফিল্টারের প্রয়োগ বিচার
    accDescr: GPO প্রয়োগ হতে লক্ষ্য ব্যবহারকারী বা কম্পিউটারের পড়া ও গ্রুপ পলিসি প্রয়োগ দুই অনুমতি থাকতে হয়, আর ব্যবহারকারী-লক্ষ্য GPO-তে আরও কম্পিউটার অ্যাকাউন্ট পড়তে পারা দরকার
    target["GPO লিঙ্কের নিচের লক্ষ্য"] --> 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-তে সাইন ইন করা সবার ব্যবহারকারী কনফিগারেশন বদলাতে চাই» পরিস্থিতির জন্য লুপব্যাক প্রক্রিয়া নামে বিশেষ মোডও আছে (কম্পিউটারের অবস্থানের ভিত্তিতে ব্যবহারকারী সেটিং প্রয়োগ করার ব্যবস্থা, Replace ও Merge দুই মোড)।¹⁵ কিয়স্ক টার্মিনাল বা শ্রেণিকক্ষ PC-তে ব্যবহৃত উন্নত বৈশিষ্ট্য, তাই এই নিবন্ধে অস্তিত্বের পরিচিতিতেই সীমাবদ্ধ।

flowchart TB
    accTitle: লুপব্যাক প্রক্রিয়ার ধারণা
    accDescr: লুপব্যাক প্রক্রিয়া কম্পিউটারের অবস্থানের ভিত্তিতে ব্যবহারকারী কনফিগারেশন প্রয়োগ করার বিশেষ মোড, Replace ও Merge দুই মোড আছে, শেয়ার্ড PC বা কিয়স্ক টার্মিনালে সাইন ইন করা সবাইকে একই ব্যবহারকারী সেটিং লাগাতে ব্যবহার হয়
    shared["শেয়ার্ড PC·কিয়স্ক ইত্যাদি"] --> lb["লুপব্যাক প্রক্রিয়া"]
    lb --> base["কম্পিউটারের অবস্থানে স্থির"]
    base --> rep["Replace মোড"]
    base --> mrg["Merge মোড"]
    lb -.-> aim["সাইন ইন করা সবাইকে লাগে"]

চিত্র 8: লুপব্যাক প্রক্রিয়া কম্পিউটারের অবস্থানের ভিত্তিতে ব্যবহারকারী কনফিগারেশন প্রয়োগ করার বিশেষ মোড, Replace ও Merge দুই মোড আছে।

4. কখন প্রয়োগ হয় — ফোরগ্রাউন্ড প্রক্রিয়া ও ব্যাকগ্রাউন্ড আপডেট

«কনফিগার করলাম তবু প্রয়োগ হচ্ছে না»-এর অর্ধেক শুধু এখনও প্রয়োগের সময় আসেনি। প্রয়োগ দুই রকম।²

অর্থাৎ ডোমেইন কন্ট্রোলারে পৌঁছাতে পারা চালু টার্মিনালে, GPO বদলানোর পর আর কিছু না করলেও, ব্যাকগ্রাউন্ড আপডেট-সমর্থিত সেটিং প্রায় দুই ঘণ্টায় পৌঁছায়। অফলাইন টার্মিনাল, বা VPN ছাড়া বাইরে নিয়ে যাওয়া PC পরেরবার DC-তে না পৌঁছানো পর্যন্ত পায় না। শুধু ফোরগ্রাউন্ডে প্রয়োগ হওয়া সেটিং আরও স্টার্টআপ বা সাইন ইন অপেক্ষা করে। তাড়াতাড়ি হলে লক্ষ্য PC-তে gpupdate চালান। ডিফল্টে শুধু যে সেটিং বদলেছে প্রয়োগ হয়; /force দিলে বদলেছে কি না নির্বিশেষে সব সেটিং আবার প্রয়োগ হয়।³

rem শুধু বদলানো সেটিং আপডেট (সাধারণত যথেষ্ট)
gpupdate

rem সব সেটিং আবার প্রয়োগ (ক্যাশ অবস্থা সন্দেহ হলে)
gpupdate /force

flowchart TB
    accTitle: DC-তে পৌঁছানো যায় কি না ও প্রয়োগ কীভাবে পৌঁছায়
    accDescr: ডোমেইন কন্ট্রোলারে পৌঁছাতে পারা চালু টার্মিনালে ব্যাকগ্রাউন্ড আপডেট-সমর্থিত সেটিং প্রায় দুই ঘণ্টায় পৌঁছায়, কিন্তু অফলাইন বা VPN-বিহীন বাইরের PC পরেরবার DC-তে না পৌঁছানো পর্যন্ত পায় না
    pc{"DC-তে পৌঁছাতে পারে?"}
    pc -->|হ্যাঁ| ok["প্রায় দুই ঘণ্টায় পৌঁছায়"]
    pc -->|না| ng["সংযোগ না হওয়া পর্যন্ত পায় না"]
    ng -.-> ex["অফলাইন বা VPN-বিহীন বাইরের PC"]

চিত্র 9: DC-তে পৌঁছাতে পারা চালু টার্মিনালে প্রায় দুই ঘণ্টায় পৌঁছায়, অফলাইন টার্মিনালে পরেরবার DC-তে না পৌঁছানো পর্যন্ত পায় না।

সতর্ক থাকুন: কিছু সেটিং gpupdate দিয়ে প্রয়োগ হয় না। ব্যবহারকারী-লক্ষ্য সফটওয়্যার ইনস্টল ও ফোল্ডার রিডাইরেক্ট শুধু সাইন ইনে, কম্পিউটার-লক্ষ্য সফটওয়্যার ইনস্টল শুধু স্টার্টআপে প্রক্রিয়া হয়। gpupdate-এ ঠিক এ জন্য /logoff (আপডেটের পর সাইন আউট) ও /boot (আপডেটের পর রিস্টার্ট) অপশন আছে।³ «gpupdate /force চালালাম তবু ঢোকে না» বলার আগে দেখুন সেটিং কি রিস্টার্ট বা সাইন ইন চায় এমন ধরনের।

flowchart TB
    accTitle: সেটিং প্রয়োগ হওয়ার পথ
    accDescr: GPO পরিবর্তন ব্যাকগ্রাউন্ড আপডেট-সমর্থিত সেটিং হলে ডিফল্ট প্রায় ৯০ মিনিট ও ০ থেকে ৩০ মিনিট অফসেটে পৌঁছায়, শুধু ফোরগ্রাউন্ডে প্রয়োগ হওয়া সেটিং স্টার্টআপ বা সাইন ইন অপেক্ষা করে, তাড়াতাড়ি gpupdate-এও ফোরগ্রাউন্ড সেটিংয়ে /logoff বা /boot লাগে
    change["GPO পরিবর্তন"] --> kind{"ব্যাকগ্রাউন্ড আপডেট সমর্থিত?"}
    kind -->|হ্যাঁ| bg["প্রায় ৯০ মিনিট+০–৩০ মিনিটে আপডেট"]
    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 জিতলে ৩ অধ্যায়ের অগ্রাধিকার পুনর্বিবেচনা করুন

flowchart TB
    accTitle: RSoP রিপোর্টে প্রথমে যে তিনটি দেখবেন
    accDescr: gpresult-এর রিপোর্টে প্রথমে প্রয়োগ হওয়া GPO তালিকায় লক্ষ্য GPO আছে কি না দেখুন, তারপর প্রত্যাখ্যাত GPO তালিকা ও কারণ নিশ্চিত করুন, শেষে সেটিং প্রতি Winning GPO দিয়ে কোন 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 বরাদ্দ হয়, তাই সিস্টেম লগের সতর্কতা বা ত্রুটি ইভেন্ট থেকে ActivityID তুলে কাস্টম ভিউ দিয়ে সেই একবারই ছাঁটা Microsoft-এর সুপারিশকৃত পদ্ধতি।⁵

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 (কম্পিউটার কনফিগারেশন; সুপারিশকৃত জায়গা)
• HKEY_CURRENT_USER\Software\Policies (ব্যবহারকারী কনফিগারেশন; সুপারিশকৃত জায়গা)
• 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 template (নীতি-নির্দিষ্ট কী)-এর সীমানার কথা। স্ক্রিপ্ট বা 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-তে C:\Windows\PolicyDefinitions-এ OS-সরবরাহকৃত সংজ্ঞা থাকে, ব্যবস্থাপনা টুল সেটা পড়ে সেটিং স্ক্রিন গড়ে।⁷

ডোমেইনে চালালে সেন্ট্রাল স্টোর তৈরি করাই ভিত্তি। ডোমেইন কন্ট্রোলারের 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 টুল ডিফল্টে সেটা দেখে।

পরিচালনার দুই সতর্কতা। প্রথম, নতুন Windows সংস্করণের ADMX Microsoft সংস্করণ প্রতি বিতরণ করে, আপডেট করলে সেন্ট্রাল স্টোর দিক বদলান। প্রতিটি PC-এর C:\Windows\PolicyDefinitions ডাউনলোড করা সংস্করণ দিয়ে বদলানো সমর্থিত নয়।⁷ দ্বিতীয়, বিদ্যমান সেন্ট্রাল স্টোর আপডেট করতে প্রোডাকশন PolicyDefinitions সরাসরি ওভাররাইট করবেন না। PolicyDefinitions-24H2-এর মতো সংস্করণ-নাম ওয়ার্কিং ফোল্ডারে OS ও অ্যাপ (Office, Edge ইত্যাদি) ADMX একসেট জড়ো করুন, বর্তমান ফোল্ডার 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 আদৌ পৌঁছায় না।

বাস্তবে ছোট ও মাঝারি ব্যবসা মাঝখানে, অর্থাৎ হাইব্রিড (ডোমেইন join + Intune নামানো), আর এখানে সবচেয়ে খারাপ «একই সেটিং GPO ও MDM দুইতে কনফিগার করা»। Policy CSP-তে GPO ও MDM সংঘর্ষে MDM জেতাতে MDMWinsOverGP নীতি আছে, কিন্তু পরিসর 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 Execution Policy ও স্ক্রিপ্ট স্বাক্ষর — «Bypass দিয়ে ঢাকার» অভ্যাস থেকে বেরোনোর বাস্তব নির্দেশিকা“।
• ফায়ারওয়ালের স্থানীয় নিয়ম মার্জ অক্ষম: GPO/Intune দিয়ে ফায়ারওয়াল কেন্দ্রীয়ভাবে পরিচালিত পরিবেশে প্রোফাইল প্রতি «local rule merging» (AllowLocalPolicyMerge) অক্ষম করা যায়। অক্ষম থাকলে ইনস্টলার স্থানীয়ভাবে রেজিস্টার করা ইনবাউন্ড নিয়ম থাকলেও প্রয়োগ হয় না।¹¹ সার্ভার-ধরনের অ্যাপ বসানোর আগে অবশ্যই নিশ্চিত করার বিষয়; বিস্তার “Windows Firewall ও ব্যবসায়িক অ্যাপ“।
• ড্রাইভ ম্যাপ, প্রক্সি ইত্যাদি পরিবেশ কনফিগারেশন: নেটওয়ার্ক ড্রাইভ ম্যাপ ও প্রিন্টার ইত্যাদি Group Policy Preferences দিয়ে বিতরণই রীতি।¹⁶ «Z ড্রাইভ থাকবে», «প্রক্সি সরাসরি সংযোগ» — এ ধরনের পরিবেশ অনুমান সাইন ইন করা ব্যবহারকারী বা PC-এর OU সদস্যপদে ভেঙে যায়। ব্যবহারকারী কনফিগারেশনে বিতরণ করা সেটিং সার্ভিস বা শিডিউলড টাস্কের অ্যাকাউন্টে স্বাভাবিকভাবেই লাগে না — রেসিডেন্ট-ধরনের অ্যাপে এটা সহজে চোখ এড়ায়।
• সেটিং আদৌ «ফেরানো যায় না»: administrative template থেকে আসা সেটিং ব্যবহারকারী 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 এক্সিকিউশন পলিসি, ফায়ারওয়াল, পরিবেশ কনফিগারেশনের মতো অ্যাপের পূর্বশর্ত চুপিচুপি বদলায়।

ডেভেলপমেন্ট পক্ষের বাস্তব প্রস্তুতি তিনটি। প্রথম, অ্যাপ নির্ভর পরিবেশ পূর্বশর্ত (এক্সিকিউশন পলিসি, লিসেন পোর্ট, লেখার জায়গা, প্রক্সি পথ ইত্যাদি) ডিপ্লয়মেন্ট শর্ত হিসেবে নথি করে ডিপ্লয়মেন্টের আগে গ্রাহকের আইটিকে নিশ্চিত করতে বলা। দ্বিতীয়, সমস্যায় অনুমান নয়, gpresult /h রিপোর্ট ও HKLM\Software\Policies-এর নিচের প্রকৃত মান দেখা (৫ অধ্যায়)। তৃতীয়, অ্যাডমিন অধিকার লাগে এমন কাজ ও লাগে না এমন কাজ ডিজাইন পর্যায়ে আলাদা রাখা (এই রেখা “Windows-এ অ্যাডমিনিস্ট্রেটর অধিকার আসলে কখন লাগে — UAC, সুরক্ষিত এলাকা, এবং ডিজাইনে কীভাবে চেনা যায়“-এ আঁকা)। GPO শত্রু নয় — পরিবেশের স্পেসিফিকেশন। স্পেসিফিকেশন হিসেবে ধরলে ছাঁটাই যান্ত্রিক হয়।

flowchart TB
    accTitle: ডেভেলপমেন্ট পক্ষের তিন প্রস্তুতি
    accDescr: ডেভেলপমেন্ট পক্ষের প্রস্তুতি অ্যাপ নির্ভর পরিবেশ পূর্বশর্ত ডিপ্লয়মেন্ট শর্ত হিসেবে নথি করে ডিপ্লয়মেন্টের আগে গ্রাহকের আইটিকে নিশ্চিত করতে বলা, সমস্যায় gpresult রিপোর্ট ও Policies কী-এর প্রকৃত মান দেখা, অ্যাডমিন অধিকার লাগে কি না ডিজাইনে আলাদা রাখা — এই তিনটি
    dev["ডেভেলপমেন্ট পক্ষের প্রস্তুতি"] --> doc["1. পরিবেশ পূর্বশর্ত নথি"]
    dev --> chk["2. gpresult ও প্রকৃত মানে নিশ্চিত"]
    dev --> priv["3. অধিকারের প্রয়োজন ডিজাইনে আলাদা"]
    doc -.-> ask["ডিপ্লয়মেন্টের আগে আইটিকে নিশ্চিত করতে বলুন"]

চিত্র 20: ডেভেলপমেন্ট পক্ষের প্রস্তুতি পরিবেশ পূর্বশর্ত নথি, gpresult ও প্রকৃত মানে নিশ্চিত, অ্যাডমিন অধিকার লাগে কি না ডিজাইনে আলাদা — এই তিনটি।

9. সারসংক্ষেপ

• Group Policy GPO-স্তরের সেটিং স্থানীয় → সাইট → ডোমেইন → OU (LSDOU) ক্রমে প্রক্রিয়া করে, সংঘর্ষ পরে-আসা জেতে। লক্ষ্যের কাছের OU-এর GPO সবচেয়ে শক্তিশালী স্তর, স্থানীয় GPO সবচেয়ে দুর্বল।
• Block Inheritance, Enforced ও নিরাপত্তা ফিল্টার দিয়ে ডিফল্ট প্রবাহ নিয়ন্ত্রণ করা যায়। Enforced উত্তরাধিকার ব্লককেও হারায়, তাই বেশি ব্যবহার নিষিদ্ধ।
• প্রয়োগ দুই চ্যানেল: স্টার্টআপ/সাইন ইনের ফোরগ্রাউন্ড প্রক্রিয়া, এবং ডিফল্টে প্রায় ৯০ মিনিট + র‍্যান্ডম অফসেটের ব্যাকগ্রাউন্ড আপডেট। gpupdate /force সব সেটিং আবার প্রয়োগ করে, কিন্তু শুধু সাইন ইন বা রিস্টার্টে প্রক্রিয়া হওয়া সেটিং-এ লাগে না।
• প্রয়োগ না হলে gpresult /h → GroupPolicy অপারেশনাল লগ → রেজিস্ট্রির Policies কী — এই ক্রমে যান্ত্রিকভাবে ছাঁটুন। প্রত্যাখ্যাত GPO কারণসহ দেখায়।
• Administrative template সংজ্ঞা ADMX/ADML, ডোমেইন পরিচালনায় SYSVOL সেন্ট্রাল স্টোরে জড়ো করুন। আপডেটে স্থানীয় PolicyDefinitions বদলান না, সেন্ট্রাল স্টোর দিক বদলান।
• GPO না Intune টার্মিনালের পরিচয় ভিত্তি ও অবস্থানে স্থির করুন; হাইব্রিডে একই সেটিং দ্বৈত কনফিগার এড়িয়ে ব্যবস্থাপনা কর্তৃপক্ষ একদিকে রাখুন। মাইগ্রেশন ছাঁটাইয়ে Group Policy analytics কাজে লাগে।
• ডেভেলপারের কাছে গ্রাহকের GPO পরিবেশ স্পেসিফিকেশনের অংশ। এক্সিকিউশন পলিসি, ফায়ারওয়াল, ড্রাইভ ও প্রক্সি কনফিগারেশনের পূর্বশর্ত নথি করে gpresult দিয়ে নিশ্চিত করার অভ্যাস রাখুন — «শুধু গ্রাহকে চলে না»-এর বেশিরভাগ আর ভয় পায় না।

সম্পর্কিত নিবন্ধ

• Windows Firewall ও ব্যবসায়িক অ্যাপ — ইনবাউন্ড নিয়ম ইনস্টলার থেকে রেজিস্টার করুন
• WSUS অবচয়নের পর Windows Update ব্যবস্থাপনা — WUfB, Autopatch ও Intune-এর মধ্যে কীভাবে বাছবেন
• PowerShell Execution Policy ও স্ক্রিপ্ট স্বাক্ষর — «Bypass দিয়ে ঢাকার» অভ্যাস থেকে বেরোনোর বাস্তব নির্দেশিকা
• winget + PowerShell দিয়ে PC প্রভিশনিং স্বয়ংক্রিয় করা — রানবুককে কার্যকর করা
• IE মোড নির্ভরতা থেকে বেরোনোর নির্দেশিকা
• Windows-এ অ্যাডমিনিস্ট্রেটর অধিকার আসলে কখন লাগে — UAC, সুরক্ষিত এলাকা, এবং ডিজাইনে কীভাবে চেনা যায়

সম্পর্কিত পরামর্শ ক্ষেত্র

KomuraSoft LLC GPO ব্যবস্থাপনায় গ্রাহকের পরিবেশে ব্যবসায়িক অ্যাপ না চলার কারণ তদন্ত, ডিপ্লয়মেন্ট শর্ত (এক্সিকিউশন পলিসি, ফায়ারওয়াল, নেটওয়ার্ক পূর্বশর্ত) সাজানো, এবং AD পরিবেশ উত্তরাধিকার পাওয়া আইটি কর্মীদের জন্য নীতি তালিকা ও Intune সহ-পরিচালনা পরিকল্পনার প্রযুক্তিগত পরামর্শ সামলায়। «gpresult রিপোর্ট একসঙ্গে পড়ুন» — এত আগে থেকে শুরু করা যায়।

• প্রযুক্তিগত পরামর্শ ও ডিজাইন রিভিউ
• বাগ ও কারণ তদন্ত
• Windows অ্যাপ ডেভেলপমেন্ট
• যোগাযোগ করুন

তথ্যসূত্র

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।

এই বিষয়ের সাথে সম্পর্কিত সেবা

নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।

প্রায়শ জিজ্ঞাসিত প্রশ্ন

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

gpupdate /force চালালাম তবু সেটিং প্রয়োগ হচ্ছে না। কেন?

আগে দেখুন সেটিং কি «ব্যাকগ্রাউন্ড আপডেটে প্রয়োগ হয় না» ধরনের। ব্যবহারকারী-লক্ষ্য সফটওয়্যার ইনস্টল ও ফোল্ডার রিডাইরেক্ট শুধু সাইন ইনে, কম্পিউটার-লক্ষ্য সফটওয়্যার ইনস্টল শুধু স্টার্টআপে প্রক্রিয়া হয়, তাই gpupdate শেষে সাইন আউট (/logoff) বা রিস্টার্ট (/boot) লাগে। তারপর gpresult /h দিয়ে RSoP রিপোর্ট বের করে সেই GPO «প্রয়োগ হওয়া GPO»-তে আছে কি না, বা কারণসহ «প্রত্যাখ্যাত GPO»-তে আছে কি না দেখুন। প্রয়োগ হয়েছে তবু আচরণ বদলায়নি হলে, উচ্চতর অগ্রাধিকারের অন্য GPO একই সেটিং ওভাররাইট করছে (পরে-আসা জেতে) সন্দেহ করুন। রিপোর্টে প্রতিটি সেটিং-এর «Winning GPO» দেখায়, তাই কোন GPO জিতছে পর্যন্ত নির্দিষ্ট করা যায়।

gpresult-এ «ফিল্টারে প্রত্যাখ্যাত» দেখালে কী বোঝায়?

সেই 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 একই সেটিং কনফিগার করলে স্থানীয় পরিবর্তন সবসময় ওভাররাইট হয়। উল্টোদিকে ডোমেইন দিক «Not Configured» রাখলে স্থানীয় GPO-এর মান যেমন আছে তেমন থাকে। যাচাইয়ে স্থানীয় সেটিং অগ্রাধিকার দিতে চাইলেও, ডোমেইন-joined PC-তে এই অগ্রাধিকার ক্রম উল্টানোর উপায় নেই, তাই যাচাই OU তৈরি করে ডোমেইন দিকের GPO সামলানো, অথবা ডোমেইন-বিহীন যাচাই মেশিন ব্যবহার করাই বাস্তব।

আমরা যে ব্যবসায়িক অ্যাপ তৈরি করেছি সেটা শুধু গ্রাহকের পরিবেশে চলে না। GPO কারণ কি না দেখার উপায় আছে?

প্রথম ধাপ গ্রাহকের অ্যাডমিনিস্ট্রেটরকে সমস্যা PC-তে এলিভেটেড কমান্ড প্রম্পট থেকে gpresult /h report.html চালিয়ে RSoP রিপোর্ট দেখতে বলা। এক্সিকিউশন পলিসিতে স্ক্রিপ্ট থামা, ফায়ারওয়ালের স্থানীয় নিয়ম মার্জ অক্ষম, প্রক্সি বা ড্রাইভ ম্যাপের কনফিগারেশনের মতো অ্যাপের আচরণ বদলানো সেটিং প্রয়োগ আছে কি না দেখুন। সাথে রেজিস্ট্রির HKLM\Software\Policies ও HKCU\Software\Policies-এর নিচে সংশ্লিষ্ট পণ্যের নীতি মান লেখা আছে কি না দেখলে administrative template থেকে আসা জোর সেটিং যান্ত্রিকভাবে ধরা যায়। ডেভেলপমেন্ট পক্ষের প্রস্তুতি: অ্যাপ নির্ভর পূর্বশর্ত (এক্সিকিউশন পলিসি, লিসেন পোর্ট, লেখার ফোল্ডার ইত্যাদি) ডিপ্লয়মেন্ট নির্দেশিকায় লিখে, ডিপ্লয়মেন্টের আগে গ্রাহকের আইটিকে নিশ্চিত করতে বলা।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।