Kezdőoldal > Windows Server > Group Policy Preferences és Item-Level Targeting 2. rész

Group Policy Preferences és Item-Level Targeting 2. rész


2. Item Level Targetting

Pár alapgondolat, hogy hány házirendet hozzunk létre (ha esetleg a GPP beállításokat a többi házirend-opciótól külön akarnánk kezelni, s emiatt külön házirendeket hozunk létre):

1. GPO legfelülre: ez akkor jó, ha mindenkinek kell, pl. Company, Common, stb.

2. GPO OU-nként: ha adott meghajtó a szervezeti egységtől függően kerül csatolásra, pl. Scan a Penzugy, Raktar egységeknél

3. GPO legfelülre, de GP-szűrés csoportra: ennek akkor van értelme, ha adott csoport tagjai nincsenek külön szervezeti egységben, de attól még nem teljesen lapos az OU-struktúránk (pl. számlázás és könyvelés egy OU-ban, de csoportosítva). Ekkor több GPO-nk lenne ugyanarra a meghajtóra… Sok értelme nincs, hiszen általában egy csoport tagjai egy OU-ban vannak, akkor már inkább a GPO-t hozzá kötjük. Csak akkor állja meg a helyét, ha egy csoport tagjai különböző OU-kban vannak szétosztva.

4. GPO OU-nként, GP-szűrés csoportra: ha mindenki egy OU-ban van, akkor az előző eset. Ha tényleg vannak különböző OU-k, akkor viszont csak akkor van értelme, ha a csoport tagjai mind ennek a szervezeti egységnek a tagjai, s létezik legalább két különböző csoport az egységen belül (mint előbb, pl. számlázás, könyvelés).

Az eddig ismert szűrésekhez most még hozzájön a GPP saját szűrési lehetősége, az Item Level Targetting.

Mikor érdemes ILT-vel szűrni, nem GP-re? Mivel a modellezés nem mutatja az ILT szűrést (de hátha a következő generációs GPMC már tudni fogja 🙂 ), ezért már most érdemes ezen a kérdésen elgondolkozni.

Egyrészt tudnunk kell, hogy az ILT szűrési lehetőségei sokkal szélesebb körűek a GPO-szűrésnél. Ettől függetlenül, véleményem szerint továbbra is a leggyakrabban használt szűrések leginkább AD-felhasználóra vagy AD-csoportra lesznek, illetve a fordítottja, hogy valaki(k)re nem alkalmazzuk.

A szűrés ugyanaz, mintha az egész GPO-ra lenne, de: ILT meghajtónként, míg GPO esetén az egész házirendet szűrjük.

Ha meg tudjuk oldani, hogy az egész házirendet kiszűrjük, hogy ne legyen érvényes adott csoportra, akkor nem is értékelődik ki, tehát sebességet nyerünk. Mivel viszont nem szeretnénk túlzottan sok házirendet, ha csak a GPP jönne szóba, arra, ami eltér, használhatjuk az ILT-t. Tehát ha pl. szükségünk van arra, hogy egy OU-ra érvényes egy házirend, de egyik opcióját nem szeretnénk alkalmazni egy szűkebb csoportra, akkor a régi módszer alapján két házirendet kellett létrehozzunk. Most elég egy házirend, s azon belül az ILT-vel tudjuk szűrni, hogy az adott opciót megkapja-e vagy nem.

Elméletben megoldható lenne úgy, hogy csak egy házirendünk van, a legfelső szinten, s azt csak szűrjük. Ekkor a GPMC lenne egyedüli módja annak, hogy megtudjuk, ki milyen betűt kap csatolva, de mivel a Modelling nem ismeri az ILT szűrést, érdemes előre végiggondolni az egész kiosztást (mint mindenhol, itt is fontos a tervezés 🙂 ).

Ugyanazt a betűt egy GPP-n belül többször is használhatjuk, megfelelően ILT-vel szűrve. Arra vigyázzunk, hogy több megfelelés (egy személy több csoport tagja), valamint Replace kapcsoló esetén (Update nem!) a sorrendben hátrább levő útvonal lesz érvényes.

Ha csak GPP-ben gondolkoznánk ezután, mint csatolási lehetőség, azzal kell számolni, hogy nem lehet mindenhol kiiktatni, ugyanis lehetnek Windows 2000 kliensek is, ezek nem tudnak részt venni a játszmában – ezért valószínűleg a scriptek is maradnak. Terminál-szolgáltatás esetén pedig természetesen a Loopback feldolgozás módját is kell figyeljük.

S akkor most vissza a már többször említett problémára. Két hasznos eszközt szoktunk használni a házirendeknél. Az egyik az RSoP, ami szépen mutatja a GPP beállításokat is (egyrészt természetesen akkor, ha van 2008/2008 R2 DC, de egy Vista/W7 munkaállomásról történő lekérdezés esetén is), míg a másik a modellezés – ahol már nem ennyire fényes a helyzet.

Ha le akarjuk modellezni egy adott házirend GPP beállításait is (mint említettem, GPP szűrés nélkül), akkor csak és kizárólag W2k8 DC-vel tudjuk. 2008 R2-ben viszont hibára fut a modellezés. Eleinte azt hittem, hogy az ILT tehet róla, de sajnos ILT nélkül is két hibaüzenet rontja kedvünket:

Alkalmazás-napló: 8196 Error: „The client-side extension caught the unhandled exception ‘0x00000000C0000005’ inside: ‘threadEntry : client main’ See trace file for more details.”

GPMC Modellezésnél: Group Policy Drive Maps failed due to the error listed below and failed to log resultant set of policy information

Eddig még nem találtam erre a problémára megoldást, reménykedem, hogy hamarosan egy javítófolt fog születni 😉

Pár apró infó még a GPP/ILT párossal kapcsolatban:

–       GPP logging bekapcsolása ebben a cikkben olvasható.

–       néhány további boncolgatás itt.

Advertisements
Kategóriák:Windows Server
  1. Flowman
    október 7, 2010 - 3:40 du.

    Normál esetben 2008R2 alatt is működik a modellezés, nem sikerült reprodukálnom az általad tapasztalt hibát.

    • október 8, 2010 - 7:52 de.

      Azért furcsa, mert nemrég részt vettem egy oktatási központ nyílt napján, ahol “szűz” W2k8 R2 virtuális hálózatunk/tartományunk volt, s ott is (igaz ILT-vel, mert akkor még nem sejtettem, hogy nem az a baj) sikerült reprodukálni a jelenséget.

  1. No trackbacks yet.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: