none
Nepřístupné politiky v Odmítnuté objekty zásad skupiny

    Dotaz

  • Dobrý den, prosím o radu, jak odstranit nepřístupné objekty objekty zásad skupiny na 2003 server.

    Ve výpisu gpresult -h přímo na stanici mám v části "Souhrn - Souhrnné informace o konfiguraci počítače - Objekty zásad skupin - Odmítnuté objekty zásad skupiny" dvě politiky (název obsahuje jen ID politiky typicky něco jako EE985E12-6D20-464C-9CC5-5DBE44077149) označené jako nepřístupné. Když tuto politiku podle řetězce na serveru v SYSVOL vyhledám, tak v souboru GPT.INI je uveden displayName, který už v Správě zásad skupiny neexistuje nebo tam je default název "Nový objekt zásad skupiny". Jak to přesně vzniklo nevím, patrně vymazáním politiky před jejím vyřazením ze správy.

    Můžete mi prosím poradit, jak tento problém vyřešit pokud možno standardními nástroji?



    30. května 2011 8:52

Odpovědi

Všechny reakce

  • Z poskytnutych informaci se tezko neco usuzuje. Predevsim by bylo dobre vedet, co jste delal, nez k teto situaci doslo. Uzitecny by byl take peclivejsi popis situace s vypisem chyb v protokolu udalosti. 

    Odhaduji, ze nejblize bude k odhaleni a reseni problemu toto http://support.microsoft.com/kb/839499/en-us

    30. května 2011 13:25
    Moderátor
  • Děkuji za odpověd i odkaz, bohužel ale nejsem schopen zpětně zjistit, jak k tomu došlo. Uvedený odkaz bohužel řeší jinou věc. Nemám problém s tím, že bych se nedostal na uvedenou politiku popřípadě do snap-in modulu, ale s tím, že uvedené politiky se šíří v rámci domény, ale já je v správě zásad skupiny nevidím.

    V protokolu událostí na serveru ani na počítači k tomu žádná další informace není. Záznam najdu pouze ve výpise GPRESULT /h popřípadě dalších variantách výpisu. Pokusím se popsat podrobněji, jak jsem to vůbec zjistil.

    Dnes mi bylo oznámeno, že na jednom počítači není nainstalován program, který se instaluje přes GPO z msi balíčku. GPUPDATE nepomohl, a ani po jeho vynucení nebyl  platný záznam o spravovaném programu v registrech v HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt a tak jsem si na tomto počítači nechal vypsat GPRESULT /h. Tím jsem zjistil v dotazu popsaný stav v "Souhrn - Souhrnné informace o konfiguraci počítače - Objekty zásad skupin - Odmítnuté objekty zásad skupiny".

    {EE985E12-6D20-464C-9CC5-5DBE44077149} OU Nepřístupné 
    {A7987EA7-F649-4F84-B2D2-5C17ED54A93F} OU Nepřístupné

    U první politiky je v SYSVOL v GPT.INI název politiky, která už ve správě politik není:
    [General]
    Version=13
    displayName=Instalace MS-Office 2000

    U druhé politiky je GPT.INI nepřejmenovaný název politiky
    [General]
    Version=25
    displayName=Nový objekt zásad skupiny

    Jak k tomu ale přesně došlo nevím, obojí je v SYSVOL s datem vzniku v roce 2007. Tedy stará věc, která se ale šíří v doméně.

    Jde mi o to, jak tyto "nespravované" politiky ze správy skupin dostat pryč tak aby se při startu PC dále netestovaly a zmizely z GPRESULT. Dále jsem zjistil, že se testují se na všech PC v rámci domény a předpokládám, že tak zbytečně zpomalují start systému. Mám zato, že prosté vymazání odpovídajícího adresáře v SYSVOL asi k úspěchu nepovede a spíš bych si tím vymazáním mohl přidělat další problémy.




    30. května 2011 14:39
  • Nejprve bych se podíval pomocí ADSIEdit nebo Active Directory Users and Computers do kontejneru doména\System\Policies, jestli tam existují kontejnery pro tyto dvě GPO ID.
    Petr Bouška www.samuraj-cz.com
    30. května 2011 16:40
  • "Jak k tomu ale přesně došlo nevím, obojí je v SYSVOL s datem vzniku v roce 2007. Tedy stará věc, která se ale šíří v doméně." Tak tohle vypada jako by se skupinova politika sirila v systemu jako eroze Vltavskych brehu v poslednim mileniu. 

    Ja bych ulohu rozdelil na dve:

    1. Proc se neuplatni politika, ktera by se uplatnit mela? Vime, jaky je operacni system na serveru, nevime kolik je serveru ve funkci domenoveho radice (replikace, DNS), nevime s jakymi klienty mame co do cineni (XP ,6, 6.1). Tady bych zjemnil logovani a mozna jeste nasadil audit.

    2. Proc jsou v systemu politiky, ke kterym neni pristup? Tady neni jasne s jakymi pravy (s jakym uctem se provedl test GPO). Prava lze delegovat na uzivatele, pokud se test provadi s pravy uzivatele, a pak by mela byt situace jina. 

    Zacneme diagnostikou, abychom meli neco, o co se oprit. Pokud pouzivate gpresult a nastane problem, tak pouzijte gpresult /Z . Dostanete detailni vypis (dalsi parametry zjistite: gpresult /?)

    Diagnosticke logovani pro Windows XP, 2000 a 2003 se nastavuje v HKEY_Local_Machine:

    HKLM/Software/Microsoft/Windows NT/CurrentVersion

    Zde vytvorte klic Diagnostics a v nem RunDiagnosticLoggingGroupPolicy (REG_DWORD, hodnota 1) a AppMgmtDebugLevel (REG_DWORD, hodnota hexa 4b)

    (Obcas nekde najdete jeste RunDiagnosticLoggingIntelliMirror a RunDiagnosticLoggingAppDeploy, ale klidne se touto informaci neridte. Je to "bug".)

    U Visty a W7 se zmenilo logovani, z applikacniho logu se premistilo do systemoveho.





    30. května 2011 20:08
    Moderátor
  • Nejprve bych se podíval pomocí ADSIEdit nebo Active Directory Users and Computers do kontejneru doména\System\Policies, jestli tam existují kontejnery pro tyto dvě GPO ID.


    Ano, oba tyto kontejnery v Active Directory Users and Computers v doména\System\Policies jsou. Nevidím je v Group Policy Management.

    Znamená to tedy, že je mohu v Active Directory Users and Computers v doména\System\Policies vymazat a tím si popsaný problém vyřeším?

    31. května 2011 5:19
  • Ano, máte pravdu ve všech 3 odstavcích.

    Přiznám se, že neznám odborný pojem, jak se toto fungování politik, kdy se projeví na spravovaných počítačích nazývá. Proto jsem použil slovo šíří.

    ad 1) Nevím proč, ale občas (tak jednou do roka) se to na některém z počítačů stane. Řeším to tím, že počítač přeřadím z domény do workgroup, účet počítače v doméně smažu, po spuštění GPUPDATE smažu v registrech zbývající klíče Policies a počítač přidám opět do domény. Pak to funguje. Možná ale existuje elegantnější řešení. Jinak počítače jsou XP, Vista i W7. Servery jsou 2.

    ad 2) Jak jsem psal výše, nevím proč tam ty politiky, ke kterým není v  Group Policy Management přístup, jsou a patrně se i uplatňují. Test GPO (předpokládám, že testem myslíte GPRESULT) jsem provedl pod účtem s právy doménového administrátora. Pod účtem uživatele se může výsledek určitě lišit. Předpokládám ale, že uvedená část bude v obou případech stejná.

     

    31. května 2011 5:39
  • K Vašemu dodatku. Předně děkuji za postup úpravy registrů. Hodí se. Záznam v systémovém logu je velmi podrobný a přehledný.

    Výpis GPRESULT /Z uvedené informace o zapomenutých zásadách neobsahuje. Přesněji, i když jsem to opakovaně pročítal, tak jsem tam nic takového nenašel.

    Po úpravě registrů pro logování je systémový log bez chyb a končí posledním oznámením "Nastavení zásad skupiny pro počítač bylo úspěšně zpracováno. Byla zjištěna a použita nová nastavení v objektech zásad skupiny 30."

    Problém, který primárně řeším, není v tom, že by se něco neprovedlo. To, že se nenainstaloval jeden program, jsem uvedl pouze pro to, abych dokumentoval, jak jsem na popsanou chybu přišel.

    Jde mi ale především o bezpečné odstranění "zapomenutých" zásad, které jsou vypisovány v GPRESULT /H. Je možné tyto zásady v Active Directory Users and Computers v doména\System\Policies vymazat, aniž bych tím vyvolal ještě horší stav?


    31. května 2011 10:56
  • Já si myslím, že je možné smazat soubory politiky v SYSVOLu (\\domena\SYSVOL\domena\Policies) a záznamy v AD (Active Directory Users and Computers v doména\System\Policies) a dojde ke korektnímu odstranění politiky. Ale možná se vyjádří někdo povolanější :-). Myslím, že se to dá vyzkoušet, když obě části pouze přesuneme a pak zkusit na klientovi, jestli se tam stále snaží aplikovat.
    Petr Bouška www.samuraj-cz.com
    31. května 2011 11:13
  • Bohužel k odstranění problému tímto postupem nedošlo.

    Vymazal jsem jeden záznam v
    - Active Directory Users and Computers,
    - doména\System\Policies,
    - c:\WINDOWS\SYSVOL\domain\Policies\ i v
    - c:\WINDOWS\SYSVOL\sysvol\doména.cz\Policies\
    a po GPUpdate /force je uvedená politika mezi vypsanými chybami se stavem nepřístupná.

    Na testovacím počítači byla politika zapsaná v registrech v HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\GPLink-List. Když odtud klíč, který tuto politiku obsahuje smažu, tak po GPUpdate se tam znovu vrátí. Přitom už tato politika není v Active Directory Users and Computers, v Group Policy Management ani v SYSVOL. Takže nevím odkud se tam vrátí. V ADSI Edit záznam o politice po jejim vymazání v Actice Directory doména\System\Policies také vidět není.

    I když to je zbytečné, tak jsem pro jistotu spustil GPUPdate i na serveru, ale bez výsledku.


    1. června 2011 11:45
  • Zasatral jsem po Internetu a nasel jsem http://support.microsoft.com/kb/294257/en-us 

     

     


    1. června 2011 12:33
    Moderátor
  • Jestli to skutečně při startu vadí nevím. V systémovém logu ale tato politika načítána není. Vypisuje se pouze v GPResult -h popřípadě  v Group Policy Result v GPM.

    To, že nedošlo k vymazání OU s aktivní politikou vyloučit nemohu. Pokud to je zástupný problém, tak věc odkládám.

    Děkuji.

    1. června 2011 12:53
  • Děkuji Vám za čas, který jste té věci věnoval. Bohužel to ale problém neřeší. Ani jedna z chybových hlášek
    Inaccessible GPO - Access Denied. 
    Failed to open the Group Policy Object. You may not have appropriate rights.

    se u mě nevyskytuje a v Group Policy Management mám přístup na všechny tam uvedené politiky.

    V odkaze popsaný postup opravy s dsacls jsem pro ověření vyzkoušel s výsledkem The command completed successfully, ale nic se nezměnilo. Uvedená politika se u nadále objevuje ve výpise a je uvedená v registrech v HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\GPLink-List.

    Chybové GUID v Windows\Sysvol\Sysvol\<var>Domain_name</var>\Policies mělo v zabezpečení Full Control pro Domain Admins  i bez provedení v odkazu popsaného postupu opravy.  A po opravě Full Control zůstal nastavený.

    1. června 2011 14:13
    • Označen jako odpověď yorgstbk 6. června 2011 9:39
    6. června 2011 8:43
    Moderátor
  • Děkuji za odkaz a značím jako odpověď. 

    Uvedené postupy k cíli patrně povedou, ale překračuje to už mé znalosti.  Vzhledem k dříve uvedenému, že tento problém není zásadní, nechávám ho být.

    6. června 2011 9:42