none
Deaktivace nefunční doménové politiky v group policy

    Dotaz

  • Dobrý den.

    Chtěl bych vás požádat o radu k tomuto problému.

    Na Windows Server 2003 jsem měl politiku pro IE s nastavením proxy a zabezpečení. Z nějakého důvodu mi tato politika přestala fungovat (důvod skutečně nevím) a protože jsem nepotřeboval na počítačích delší dobu nic měnit, tak jsem o tom ani nevěděl a případnou chybu v nastavení IE jsem nijak neřešil a provedl na konkrétním PC ručně. 

    Až teď jsem potřeboval provést více změn v zabezpečení a při tom jsem zjistil, že jakákoliv úprava či doplnění v této politice se neprojeví na počítačích, kterých se měla týkat. Po GPupdate /force se tyto změny nedostávaly na žádné klientské PC

    Tato politika měla UID 65BCEF88-A80C-4223-AF70-27A1FDEB6CF4. Původní inetres.adm jsem v této politice odstranil a nahradil novým pro IE9 přejmenovaným na inetres9.adm. Použití přejmenovaného inetres.adm na inetres9.adm je první možná chyba, které jsem se dopustil. U ostatních politik zůstal všude původní inetres.adm.

    Abych zjistil, kde je chyba, tak jsem páchal další kroky.

    1.

    • Zrušil jsem link na politiku s UID 65BCEF88-A80C-4223-AF70-27A1FDEB6CF4, ve které bylo nastavení MSIE.
    • Po GPupdate /force se ale stále tato politika ukazovala jako aktivní (to, co v ní bylo nastaveno bylo stále v nastavení IE a také GPresult ukazoval toto UID jako vítězné), tak jsem u ní zakázal nastavení počítače i nastavení uživatele a když ani toto nepomohlo, tak jsem tuto politiku v gpmc.msc smazal.
    • UID 65BCEF88-A80C-4223-AF70-27A1FDEB6CF4 je pro nastavení proxy a zabezpečení i po těchto krocích zobrazováno v GPresult jako vítězné.

    2.

    • Původní inetres.adm jsem podle instrukcí v Install Instructions pro template IE9 v adresáři \WINDOWS\inf\  přejmenoval na inetres_old.adm a nahradil ho novým inetres.adm pro IE9.
    • Vytvořil jsem novou politiku s nastavením proxy a zabezpečením nazvanou MSIE_nastaveni s tímto novým inetres.adm.
    • Po Gpupdate se nová politika neprojevila (i když mezi "Použité objekty zásad skupiny" je ve výčtu uvedena) a stále je jako Vítězný objekt zásad skupiny původní nefunkční  a smazaná {65BCEF88-A80C-4223-AF70-27A1FDEB6CF4}, i když už neexistuje ani v SYSVOL.

    Ve všech krocích jsem se pohybovat v rámci gpmc.msc a nedělal jsem žádné nestandardní kroky v AD, nic jsem nikde nemazal.

    GPresult

    Doplním.

    Na všech počítačích je Windows7 32 bit a IE9.


    • Upravený yorgstbk 27. května 2013 13:12 diodatek
    27. května 2013 13:00

Odpovědi

  • no jestli máte rozdíly v SYSVOL, tak se vám nereplikuje SYSVOL, zatímco LDAP se vám zřejmě replikuje.

    musíte opravit NTFRS replikaci, nebo ověřit, že funguje v pořádku. Můžete zkusit použít BurFlags registrovou hodnotu.

    ondra.

    • Označen jako odpověď yorgstbk 30. května 2013 18:00
    29. května 2013 10:14
  • <strike>a) Když jsem psal minulý příspěvek, tak GPRESULT /H REPORT.HTM obsahovat kompletní výpis, tedy jak část pro počítač, tak i část pro uživatele. Když jsem se po cca 2 hodinách dostal znovu k této stránce, tak už GPRESULT /H REPORT.HTM vypíše jen část pro uživatele a v části pro počítač mám zprávu "Nejsou dostupná žádná data".</strike>

    b) K vaší otázce zda je vidět IEM politika v seznamu aplikovaných/neaplikovaných GPO - nebyla tam vidět ani předtím. Objekt GPO, který tuto hodnotu prosadil jako vítězný tam v seznamu nebyl. Bylo jen zobrazeno Vítězné UID tak, jak je v prvním příspěvku vidět na přiloženém obrázku. To UID si pamatuji podle posledních 6 znaků a bylo původně u politiky, ve které bylo nastavení IE a kterou jsem smazal.

    c) Malé vítězství.

    - Nově vytvořenou politiku pro nastavení IE jsem dal na první místo s nejvyšší prioritou a od té doby se nastavení proxy na počítačí projevilo. V základní doménové politice, která měla předtím vyšší prioritu, bylo zaškrtnuto Automatically detect configuration settings a rovněž tam byl nastaven Import v Security Zones a bylo tak importováno nastavení vyjímek pro proxy ze serveru. Předtím jsem si toho nevšiml. Tato základní doménová politika má ale jiné UID než to, které bylo zobrazováno jako vítězné. To patřilo smazané GPO.

    - Proxy jsem u funkční politiky nastavil v Windows Settings - IEM - Connection - Proxy Settings bez nastavení zabezpečení.

    - Bezpečné servery jsem neimportoval z nastavení serveru ve Windows Settings, ale nastavil v Administrative Templates - Windows components - Internet Explorer - Security Page - Site to Zone Assignment List

    <strike>d) Prohra </strike>

    <strike>

    - GPRESULT /H REPORT.HTM stále nezobrazuje informace o nastaveních konfigurace počítače a nevím, jak to vrátit zpět.

    </strike>GPRESULT zobrazí obě sekce v případě, že je spuštěn jako správce.

    Děkuji za pomoc a zejména trpělivost.

    • Upravený yorgstbk 30. května 2013 17:58 oprava
    • Označen jako odpověď yorgstbk 30. května 2013 17:59
    30. května 2013 17:08

Všechny reakce

  • a) nemyslím si, že ve vašem případě má vůbec efekt jakkoliv laborovat s inetres.adm. To je administrativní šablona (administrative template). Vy ale podle výpisu nastavujete proxy pomocí Windows Settings - Internet Explorer Maintainance, což nemá podle mého názoru nic společného s administrativními šablonami (ale samozřejmě se mohu mýlit).

    b) jestliže jste původní objekt smazal jak ze %systemroot%\...\sysvol a nevidíte ho ani v konzoli GPMC v položce Group Policy Objects (tedy v místě, kde by měly být vidět všechny existující GPO v dané doméně bez ohledu na to, kam jsou přilinkované), tak bych to typoval na nějakou replikační chybu

    c) máte více DC? Nejspíš ano, že? Vaše GPMC konzole se připojuje vždy pouze na PDC - tedy na jedno jediné DC a vidíte tedy jeho vlastní stav, zatímco stav ostatních DC nevidíte v konzoli. Ostatní DC si replikují změny a musel byste se podívat na ta ostatní DC.

    d) Group Policy je složeno ze dvou věcí - má nějaká nastavení v LDAP Active Directory a současně jsou soubory s konfigurací na disku v SYSVOL. Tohle se replikuje samostatně. Tzn. pokud něco upravujete pomocí GPMC konzole, děláte současně zásah do dvou věcí - do LDAPu a do SYSVOL. LDAP se replikuje samostatně, nezávisle na SYSVOL. SYSVOL se replikuje pomocí NTFRS replikace.

    e) stanice se připojují na jedno DC kvůli LDAP a nezávisle na tomto DC na (klidně jiné) DC pro SYSVOL. Pokud se vám to nereplikuje spolehlivě oboje, tak ta stanice vidí něco jiného nekonzistentně v LDAPu, zatímco si stahuje kdoví co ze SYSVOL jiného DC.

    f) zjistěte kolik a kde máte DC. Zkuste přinutit GPMC konzoli (pravým tlačítkem někde nahoře), aby se připojila na jiné DC a zkontrolujte co tam vidíte.

    g) na svém blogu mám článeček, pomocí kterého se podívejte na stanici, které z těch DCček se používá stanice: NLTEST a také si otevřete v průzkumníkovi \\vase.domena.cz a podívejte se pravým tlačítkem, který z DFS referalů je aktivní:

    https://www.sevecek.com/Lists/Posts/Post.aspx?ID=32

    ondra.

    28. května 2013 17:19
  • Neuskodi zacit s netdiag /fix /debug , abychom vedeli, jak je na tom zdravotne AD. pak bych pokracoval s

    http://technet.microsoft.com/en-us/library/cc776678(v=ws.10).aspx

    M.

    28. května 2013 20:42
    Moderátor
  • Děkuji za obsáhlou odpověď a pokusím se reagovat na jednotlivé body.

    ad a) Děkuji za vysvětlení. Nastavuji tam i chování ActiveX a skriptování a měl jsem za to, že oproti administrative template, které je v server 2003 default tuším že pro IE6 tam může být změna, která by bránila novějším položkám v nastavení IE.

    ad b) Původní objekt s UID 65BCEF88-A80C-4223-AF70-27A1FDEB6CF4 jsem ze %systemroot%\...\sysvol "fyzicky" nemazal. Není tam po smazání politiky z konzoly. Chyba replikace je pravděpodobná. Už jsem se s ní dříve setkal. Projevovalo se to chybovou zprávou při GPupdate. Tentokrát ale GPupdate končí bez chyby. Už při mém hledání kde je problém jsem replikaci vynutil na DC NT2 z NT1 v Active Directory Sites and Services, ale nepomohlo to. Další místo pro vynucení replikace bohužel neznám.

    ad c) Ano, máme 2 DC. Konzola GPMC je na NT1 a NLTEST /SC_QUERY vypíše Název důvěryhodného řadiče domény NT2.

    ad d) Přiznám se, že tuto záležitost znám jen teoreticky, vím, že to tak funguje, ale nevím, jak prakticky replikaci obou mimo replikaci v Active Directory Sites and Services vynutit.

    ad e) viz bod c.

    ad f) Po změně řadiče domény v gpmc.msc z NT1 na NT2 je obsah složky Group Policy Object stejný.

    ad g)
    NLTEST /SC_QUERY vypíše připojení na NT2.
    NSLOOKUP, SET Q=SRV končí chybovou hláškou "*** Nelze nalézt adresu serveru Q=SRV: Non-existent domain"
    NLTEST /DSGETSITE vypíše název domény
    DFSUTIL CACHE REFERRAL vypíše
    1 entries...
    Entry: \domena.cz\SysVol
    ShortEntry: \domena.cz\SysVol
    Expires in 0 seconds
    UseCount: 0 Type:0x1 ( DFS )
       0:[\nt1.domena.cz\SysVol] AccessStatus: 0 ( ACTIVE TARGETSET )
       1:[\nt2.domena.cz\SysVol]

    Po všech těchto provedených krocích je stav stejný. Nastavení proxy a zabezpečení se z politiky na počítačích neprojeví. Jako Vítězný objekt zásad skupiny je v GPresult pro nastavení proxy stále už neexistující UID 65BCEF88-A80C-4223-AF70-27A1FDEB6CF4.

    29. května 2013 7:33
  • netdiag /fix /debug z NT2 je docela obsáhlý, má přes 5000 řádků a nevím, zda ho tady mohu celý přilepit.

    29. května 2013 8:07
  • dobře, takže máme podezření na replikaci. to bych se pokusil vyřešit. těžko tu psát o řešení replikace, tak to zkuste nějak pořešit.

    jinak potom pomocí konzole GPMC a průzkumníka kontrola:

    = nejprve se podívejte, že obsahy SYSVOL na obou stranách jsou fyzicky stejné na disku

    = potom si připojte tu konzoli GPMC postupně na oba dva DC a proklikejte po jednom všechny GPO v Group Policy Objects kontejneru v té konzoli. Ověřte si, že na záložce Details každého důležitého objektu vidíte stejné obsahy

    ondra.

    29. května 2013 8:18
  • Srovnání sysvol:

    Rozdíly mezi adresáři sysvol na obou serverech jsou z roku 2011, viz obrázek ze srovnání obsahu adresářů

    Nalezené UID se v GPMC nevyskytují.

    Srovnání jednotlivých GPO:

    - liší se u většina politik v čase Změněno, rozdíl je v řádu sekund (max cca 15 sec)

    - na obou serverech je i nově vytvořená politika MSIE_nastaveni, která se neuplatňuje a ta původní politika, kterou jsem smazal, už tam není

    - vytvořil jsem novou testovací politiku pro instalaci SW z msi balíčku na testovací počítač a ta byla v gpmc.msc na druhém serveru prakticky okamžitě a na zadaném počítači se sw nainstaloval a po odebrání propojení zase odinstaloval (bylo nastaveno odinstalovat je-li mimo obor správy)

    Podle toho soudím, že replikace jako taková funguje a problém je "jen" v tom, že  Vítězný objekt zásad skupiny je v GPresult pro nastavení proxy stále už neexistující UID 65BCEF88-A80C-4223-AF70-27A1FDEB6CF4 a změněné  hodnoty v "Nepoužívat proxy server pro adresy začínající na" a "Důvěryhodné servery, Weby v této zóně" se na počítačích neprojeví.

    Změna v "Nepoužívat proxy server pro adresy začínající na" a "Důvěryhodné servery, Weby v této zóně" je právě to, čeho potřebuji dosáhnout.

    29. května 2013 10:13
  • no jestli máte rozdíly v SYSVOL, tak se vám nereplikuje SYSVOL, zatímco LDAP se vám zřejmě replikuje.

    musíte opravit NTFRS replikaci, nebo ověřit, že funguje v pořádku. Můžete zkusit použít BurFlags registrovou hodnotu.

    ondra.

    • Označen jako odpověď yorgstbk 30. května 2013 18:00
    29. května 2013 10:14
  • Použil jsem Neautoritativní obnovení a rozdíl mezi sysvol už není. Oba adresáře jsou plně synchronizované. Nastavení v "Nepoužívat proxy server pro adresy začínající na" a "Důvěryhodné servery, Weby v této zóně" se přesto nezměnilo. Je stále původní.

    Zkusím ještě otázku doplnit.

    Když si v GPMC nechám zpracovat pro můj počítač a můj účet v Group Policy Results dostanu dále uvedenou chybu. V aplikačním ani v systémovém serveru přitom žádná hláška není. Můžete mě prosím ještě navést, kde dále hledat, o který log se jedná? Nedaří se mi to najít.

    Internet Explorer Branding Failed 29.5.2013 12:58:02
    Internet Explorer Branding failed due to the error listed below.

    The specified procedure could not be found.
    Additional information may have been logged. Review the Policy Events tab in the console or the application event log for events between 29.5.2013 12:58:02 and 29.5.2013 12:58:02.
    29. května 2013 11:47
  • tak první problém s replikací vyřešen, pokračujme na problém s GPO.

    dále tedy:

    a) upozorňuju, že Internet Explorer Maintainance (IEM) je v uživatelské části politiky.

    b) IEM se aplikuje podle mých zkušeností pouze při přihlášení uživatele, neaplikuje se to při periodické aktualizaci

    c) pokud tu politiku "odeberete", tak předpokládám, že skutečné nastavení na stanici zůstane nezměněno tak, jak ho politika před časem vynutila - tedy odebráním politiky se nevracíte na původní hodnotu

    d) když už vám jede replikace, tak já bych začal po jednom. odstraňte ty objekty s IEM úplně a na stanici dejte GPUPDATE /FORCE a pak přímo na stanici můžete udělat GPRESULT /H report.htm.

    e) vyrobte nový GPO a dejte do uživatelské části jen nějaká testovací nastavení, ideálně mezi Administrative Templates, rozhodně nepoužívejte IEM (abychom odlišili problém IEM a dalších zásad) například System - Prevent Access to Registry Editing Tools. znovu dejte na stanici GPUPDATE /FORCE.

    aplikuje se to?

    o.

    29. května 2013 12:09
  • Předně se omlouvám, že reaguje až teď, ale musel jsem řešit i jiné úkoly.

    ad 1) Ano, tak jsem to měl vždy nastavené.

    ad b) Máte tím na mysli první přihlášení uživatele když se vytváří profil uživatele (nepoužíváme cestovní profily) nebo to, že by se tyto změny měly projevit až po GPUPDATE /FORCE a neprojeví se "časem samy"? Na testovacích počítačích se změna neprojeví ani po spuštění GPUPDATE /FORCE.

    ad c) Odebráním politiky, která řídí nastavení IE, se na počítačích změnilo nastavení domovské stránky, ale jen v případě, že na tom počítači nebyla domovská stránka nastavena ručně. Nastavilo se připojení na default výchozí stránku směřující na server MS. Ostatní části (proxy, zabezpečení) se po odebrání politiky nezměnily.

    ad d) Politiku k IEM jsem odstranil. Po GPUPDATE /FORCE je v reportu z GPRESULT stále zobrazena část s nastavením domovské stránky, proxy i starého zabezpečení. Prošel jsem zobrazení Settings u všech existujících politik a v žádné není nastavení proxy řešeno.

    V registrech je problémové UID v klíči HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B}\0

    ad e) Vytvořil jsem novou politiku v User Configuration - Administrative Templates - System/Ctrl+Alt+Del Options - Remove Change Password = Enabled. Po GPUPDATE /FORCE změna hesla z menu zmizela a po odstranění této politiky se zase změna hesla v menu zobrazila.

    Zkusil jsem také odebrat a znovu vytvořit profil uživatele a je to beze změny.

    30. května 2013 9:58
  • takže víme, že nová nastavení nových GPO se projevují i odebírají v pořádku. Pokud smažete uživatelův profil a znovu ho přihlásíte, tak se musí GPO aplikovat na čisto, takže máme jistotu, že to tam někde ještě drhne.

    takže zřejmě je něco podivného v chování IEM. říkáte, že i když jste odebral IEM politiku, tak to na stanici pořád hlásí, že se vlastně aplikovala? Říkáte, že i když IEM GPO vůbec nemá být v účinnosti, tak se to tváří, že v účinnosti je, že?

    Udělejte si tedy ještě jednou ten GPRESULT /H REPORT.HTM a musíte tam vidět v seznamu aplikovaných/neaplikovaných GPO tuto vaši IEM politiku. Vidíte ji tam, nebo nevidíte? V jejím řádku je taky napsáno, proč se ne/aplikovala.

    Jestli v tom reportu stále vidíte hodnotu proxy, tak i u této hodnoty v pravo musí být vidět objekt GPO, který tuto hodnotu prosadil. Z toho poznáte, který objekt ji tam protlačuje.

    ondra.

    30. května 2013 10:58
  • <strike>a) Když jsem psal minulý příspěvek, tak GPRESULT /H REPORT.HTM obsahovat kompletní výpis, tedy jak část pro počítač, tak i část pro uživatele. Když jsem se po cca 2 hodinách dostal znovu k této stránce, tak už GPRESULT /H REPORT.HTM vypíše jen část pro uživatele a v části pro počítač mám zprávu "Nejsou dostupná žádná data".</strike>

    b) K vaší otázce zda je vidět IEM politika v seznamu aplikovaných/neaplikovaných GPO - nebyla tam vidět ani předtím. Objekt GPO, který tuto hodnotu prosadil jako vítězný tam v seznamu nebyl. Bylo jen zobrazeno Vítězné UID tak, jak je v prvním příspěvku vidět na přiloženém obrázku. To UID si pamatuji podle posledních 6 znaků a bylo původně u politiky, ve které bylo nastavení IE a kterou jsem smazal.

    c) Malé vítězství.

    - Nově vytvořenou politiku pro nastavení IE jsem dal na první místo s nejvyšší prioritou a od té doby se nastavení proxy na počítačí projevilo. V základní doménové politice, která měla předtím vyšší prioritu, bylo zaškrtnuto Automatically detect configuration settings a rovněž tam byl nastaven Import v Security Zones a bylo tak importováno nastavení vyjímek pro proxy ze serveru. Předtím jsem si toho nevšiml. Tato základní doménová politika má ale jiné UID než to, které bylo zobrazováno jako vítězné. To patřilo smazané GPO.

    - Proxy jsem u funkční politiky nastavil v Windows Settings - IEM - Connection - Proxy Settings bez nastavení zabezpečení.

    - Bezpečné servery jsem neimportoval z nastavení serveru ve Windows Settings, ale nastavil v Administrative Templates - Windows components - Internet Explorer - Security Page - Site to Zone Assignment List

    <strike>d) Prohra </strike>

    <strike>

    - GPRESULT /H REPORT.HTM stále nezobrazuje informace o nastaveních konfigurace počítače a nevím, jak to vrátit zpět.

    </strike>GPRESULT zobrazí obě sekce v případě, že je spuštěn jako správce.

    Děkuji za pomoc a zejména trpělivost.

    • Upravený yorgstbk 30. května 2013 17:58 oprava
    • Označen jako odpověď yorgstbk 30. května 2013 17:59
    30. května 2013 17:08
  • no já bych řekl, že ten uživatel co zrovna spouští GPRESULT /H tak zřejmě není lokálním adminem na té stanici? to potom nevidí na výsledek zásad počítače, ale vidí ty svoje. ověřil bych, že máte CMD puštěno "jako Administrator".

    ondra.

    31. května 2013 5:35
  • To bylo první, co jsem kontroloval. Můj doménový účet je součástí lokální skupiny Administrators a není členem domain admins. Když se mi část pro počítač nezobrazovala, tak jsem měl CMD puštěno pod svým účtem.

    31. května 2013 6:00