Group Policy

Čo a načo je Group Policy

Group policy umožňuje nastavovať vlastnosti jednotlivých počítačov v doméne a aplikácii na nich... Tieto nastavenia môžu byť v rámci počítača (teda nech príde hocijaký užívateľ k tomu počítaču, nastavenia budú vždy rovnaké) alebo pre konkrétneho užívateľa (keď príde ten užívateľ k hocijakému počítaču bude mať rovnaké nastavenia).

Hlavná výhoda však spočíva v tom že Group Policy (teda sadu nejakých nastavení) je možné aplikovať na celé skupiny. Dá sa potom ľahko dosiahnuť že všetci užívatelia v organizácii budú mať rovnaké nastavenia, resp. že všetky počítače v organizácii budú mať rovnaké (napr. bezpečnostné) nastavenia.

A nakoniec - všetky tieto nastavenia sú spravované z jedného miesta (Active Directory) a administrátor teda nemusí chodiť a nastavovať jednotlivé počítače v doméne manuálne - všetko sa dá spraviť na servri.

Nastavenia Group Policy sú uložené v objektoch, ktoré sa volajú Group Policy Objects. GPO môže byť viacero a možno ich kombinovať. Čiže potom ako vytvorím nejaký Group Policy Object (nastavím nejakú konfiguráciu) objekt "prilinkujem" k nejakej organizačnej jednotke v AD a všetky objekty v danej OU (a vnorených OU) budú mať potom nastavené vlastnosti tak ako som to definoval v GPO.

Okrem Group Policy v doméne existuje aj tzv. lokálna GP (Local Group Policy), čo sú vlastne zápisy v registroch operačného systému Windows (novší ako Windows 98). Táto je však nastavená pre jednotlivé počítače zvlášť (každý užívateľ si nakonfiguruje systém "po svojom") a tak nie je až tak zaujímavá v rámci domény.

Nastavenia GP v doméne sa neprejavia (väčšinou) okamžite. Na servri sa GP obnovuje každých 5 minút, na počítačoch každých 60 minút (plus náhodný interval 0 až 60 minút). Teda ak vytvorím nejaký nový GPO nastavenia na užívateľských počítačoch prejavia možno až za 2h. Ak to potrebujem urýchliť tak na počítači kde sa majú nahrať nové nastavenia použijem gpupdate /force.
(Povedané jednoducho ak sa zdá, že čosi nefunguje spustím gpupdate /force ...)

Group Policy Management Console

Pravé tlačítko na objekt v AD (v tomto prípade celá doména) a v záložke Group Policy vidím aké GPO sa na tento objekt vzťahujú... Toto je troška zložité, pozerať vlastnosti každého objektu jednotlivo...
Microsoft preto vydal GPMC (dá sa stiahnuť zadarmo), ktorá správu GPO uľahčuje. Čím je GPO viac, tým viac sa táto GPMC oplatí. Nainštalujem ju teda (na môj administrátorský počítač XPClientA) ...
A ak nemám .Net Framework (tiež sa dá stiahnuť zadarmo) bude treba aj ten...

Po nainštalovaní si môžem pridať do svojej MMC snap-in s názvom Group Policy Management.

V Group Policy Management Console mám jednak viac možností a jednak je to prehľadnejšie.
Na tomto obrázku napríklad vidím, že mám v mojej doméne zatiaľ dva GPO (tie vznikli automaticky pri inštalácii).
Default Domain Controller Policy určuje nastavenia pre všetky moje doménové kontroléry (je prilinkovaný k OU s názvom Domain Controllers)
Default Domain Policy ako už z názvu vyplýva určuje nastavenia vzťahujúce sa na všetky objekty v doméne (je prilinkovaný k celej doméne wray.sk)
V pravej časti vidím potom detaily o vybranom GPO (v tomto prípade Default Domain Policy)

Keď kliknem na Settings vygeneruje sa automaticky správa v ktorej vidím ktoré nastavenia tento GPO mení...
Keďže tento konkrétny GPO je prilinkovaný k celej doméne značí to napríklad že všetci užívatelia (okrem iných nastavení) musia mať heslo o dľžke najmenej 7 znakov.

Ak chcem tento GPO upraviť (zmeniť niektoré nastavenia) kliknem pravým tlačítkom a zvolím Edit.

Napríklad nastavenie o dľžke hesla nájdem v Computer Configuration/Windows Settings/Security Setttings/Password Policy.
A nastaviť sa dá toho naozaj hodne - doslova tisícky nastavení. Zorientovať sa v tom je už o niečo ťažšie...

Príklady nastavení pre užívateľov (User Configuration)

Ešte predtým ako vytvorím nejaké GPO je dobré premyslieť si opäť nejakú stratégiu.
Pri Group Policy tiež platí princíp dedenia a teda ak nastavím nejaké GPO pre celú doménu vzťahuje sa na všetky objekty (a objekty v OU) v doméne. Ak nastavím iný GPO v rámci OU ktorá je v hierarchii nižšie prejavia sa oba GPO a výsledky sa sčítajú...
GPO môže obsahovať hocijaké množstvo nastavení preto treba zvážiť či je prehľadnejšie mať veľa GPO a v každom pár nastavení, alebo pár GPO ale s komplexnými nastaveniami... To už ale závisí od konkrétnej organizácie a štruktúry v AD.

Dajme tomu že chcem nastaviť aby si užívatelia nemohli meniť pozadie. V celej firme sa bude používať štandardné pozadie zobrazujúce logo firmy.

Vytvorím teda nový GPO (v Group Policy Objects, takže nebude zatiaľ prilinkovaný)

Nájdem príslušné nastavenie (treba to proste hľadať...) a upravím ho.
Pozor na dvojité zápory. Čiže "Zabrániť zmenu pozadia" - zapnúť (Enabled)

Pripravím si nejaké logo. Toto musím nahrať na server kde je dostupné všetkým. Uložím ho teda do \\Serverb\Projects Data\_Install\logo.jpg kde majú prístup všetci užívatelia.

Nastavím toto pozadie a objekt prilinkujem (pretiahnem myšou do) k celej doméne.

Teraz keď sa napríklad taký Charlie prihlási bude mať pozadie také ako som vybral a nebude mať možnosť ho zmeniť.

Môže sa stať že užívatelia z Research sa teraz začnú sťažovať, že chcú mať možnosť nastaviť si pozadie pretože používajú ako pozadie napr. grafické znázornenie projektu na ktorom pracujú...
Potrebujem teda aby sa GPO ktorý som vytvoril vzťahoval na všetkých okrem pracovníkov v oddelení Research, alebo povedané inak okrem OU All Users/Research/Users...

Možnosť ako to dosiahnuť, je zablokovať dedenie pre túto konkrétnu OU. Block Inheritance - odteraz sa nijaký GPO nalinkovaný nad touto OU neprejaví... V GPMC sa to prejaví bielomodrým výkričníkom.
Napríklad taký Bob bude mať ako pozadie logo firmy, ale Dave (pracovník v Research) bude mať možnosť zvoliť si vlastné pozadie.

Vytvorím teraz nový GPO ktorý nastaví aby v ovládacích paneloch nebola možnosť pridať a odobrať programy (Add or Remove Programs)

Vytvorím teda GPO (v Group Policy Objects, zatiaľ neprilinkovaný)

Teraz je tu konflikt... Ak totiž prilinkujem tento GPO na celú doménu, bude mať efekt na všetkých okrem pracovníkov v Research, lebo pre ich OU som zablokoval dedenie.
Logicky by som teda mal prilinkovať teraz objekt k doméne a aj k OU ktorá nededí. Ide to však aj inak.

Existuje možnosť prikázať GPO bez ohľadu na to že niekde pod ním v hierarchii je OU, ktorá má zakázané dedenie...
Táto možnosť zároveň rieši konfliktné GPO (ak by som teraz k užívateľom v Research prilinkoval nový GPO, ktorý by povoľoval použitie Add Remove programs, aj tak by "zvíťazil" ten GPO, ktorý je enforced)
V GPMC sa takýto objekt označí s malou ikonkou visiacej zámky...

Ak sa teraz prihlásim ako Eva (pracuje v Research) nebudem mať možnosť Add or Remove Programs aj keď pre OU v ktorej sa nachádza bolo zablokované dedenie...
GPO ktorý je enforced sa naozaj prejaví pre všetkých užívateľoch v doméne.

Hm... Ak sa ale prejaví pre úplne všetkých užívateľoch v doméne tak dokonca ani administrátori nebudú mať možnosť Add or Remove Programs a ešte im to aj ironicky poradí "Please check with your administrator."
Na to aby som vyriešil tento problém je nutné uvedomiť si že aj GPO je len objekt v AD a má svoje prístupové práva. Aby sa GPO mohol aplikovať, tak užívateľ musí mať k nemu prístup. A teda ak administrátorom zakážem prístup k nejakému GPO tak ten sa proste v ich prípade nevykoná...

Kliknem teda na záložku Delegations, pridám skupinu System Admins a nastavím jej Apply Group Policy Deny. Od teraz nemajú administrátori k objektu prístup (k jeho vykonaniu), a GPO sa teda nevykoná a oni v konečnom dôsledku budú mať možnosť Add or Remove Programs...

Aby som vyskúšal ako funguje dedenie GP skúsme vytvoriť nový GPO pre OU Managers v Research. Tento bude umožňovať zmeniť pozadie (aj keď som to predtým v inej GP zakázal...)

Group policy teda vyzerá nasledovne...
A teraz otázka, bude alebo nebude Bob (člen Research Managers) mať možnosť zmeniť si pozadie na pracovnej ploche?

V tejto chvíli - Nie. Je to však spôsobené tým, že je pozadie prednastavené, preto v GPO s názvom Zakaz menit wallpaper vypnem predvolené pozadie, avšak stále nechám zapnuté nastavenie, ktoré zamedzuje zmenu pozadia a...

Bobovi (a ostatným prípadným členom jeho OU) je zmena pozadia znova umožnená...

V prípade že by bolo GPO veľa tak sa ľahko stratí prehľad čo sa na koho aplikuje a čo nie. Situáciu zjednoduší ak kliknem na Group Policy Inheritance pre konkrétnu OU.
Tu je presne vidieť v akom poradí sa GPO spracujú a prednosť majú tie GPO, ktoré sú vyššie...
Pekne tu napríklad vidieť, že Enforced GPO má prednosť pred všetkým.

GPO sa teda vykonávajú v tom poradí ako je to naznačené v záložke Group Policy Inheritance a efekt sa postupne sčítava. Ak existujú konfliktné GPO tak sa prejaví ten ktorý je v tomto zozname vyššie. A ak náhodou potrebujem zariadiť aby sa GPO na niekoho konkrétneho nevzťahovalo stačí odobrať prístupové práva (deny) v záložke Delegation.
Tiež je dobré si vždy uvedomiť že GPO sú nalinkované ku konkrétnym OU (a nie k skupinám, aj keď v názve majú Group...) a preto treba dávať pozor pri presune užívateľov medzi OU...

Príklady nastavení pre počítače (Computer Configuration)

Pri počítačoch je to podobné užívateľským nastaveniam až na to že nastavenia sa vzťahujú na konkrétny počítač a nie konkrétneho užívateľa.

Aby som to mohol vyskúšať rozdelím si pracovné stanice do dvoch skupín. Resp. - vytvorím novú OU pre počítače administrátorov.

Vytvorím nový GPO, ktorý napríklad blokuje prístup k ovládacím panelom a prilinkujem ho k OU Workstations.
Pre OU Administrators Machines nastavím blokovanie dedenia. GPO by sa teda mal prejaviť na všetkých pracovných staniciach okrem tých čo sú v OU Administrators Machines.

Ak sa teda prihlásim ako hocikto na počítač XPClientB prístup k ovládacím panelom by mi mal byť zamietnutý. Ak sa prihlásim na počítač XPClientA ovládacie panely by mali byť dostupné...
Takto by to malo fungovať. Ak však spravím pár pokusov zistím, že každý má prístup k ovládacím panelom na všetkých počítačoch bez ohľadu na to v akej OU sa nachádza... Vyzerá to proste tak, že tento GPO nefunguje.

A dôvod prečo to nefunguje je tzv. Loopback processing. Na to aby bolo možné nastaviť Group Policy iba na základe počítača musí byť táto možnosť v príslušnom GPO povolená.
Aktivujem teda Loopback processing a mód nastavím Replace. (prepísať ak sú iné nastavenia)

Teraz keď reštartujem oba počítače (XPClientA aj XPClientB) zistím že skutočne - kým na počítači XPClientA sú ovládacie panely k dispozícii, na počítači XPClientB je prístup k ovládacím panelom zamietnutý. Či už sa prihlásim ako bežný užívateľ alebo hlavný administrátor...

Ak by som teraz náhodou pridal GPO povoľujúce prístup k ovládacím panelom a prilinkoval ho napríklad k OU All Users/Sales/Managers, nič by sa nezmenilo. Ak sa na počítač XPClientB prihlási napr. Zoe (manažérka) aj tak nebude mať prístup k ovládacím panelom. To je spôsobené práve tým "Loopback processingom".

V praxi sa toto dá použiť nielen na blokovanie prístupu k niečomu ale napríklad aj k povolenie... Ak mám firemnú Group Policy, ktorá kvôli bezpečnosti blokuje niektoré nastavenia, môžem ľahko vytvoriť OU pre počítače na ktoré sa tieto nastavenia nemajú vzťahovať a vytvoriť pre túto OU Group Policy s Loopback processingom...

Keďže sa v týchto všetkých nastaveniach dá celkom ľahko stratiť a pri zložitej hierarchii a množstve GPO nemusí byť jasné, ktoré GPO sa spracujú a ktoré nie, existuje príkaz gpresult, ktorý presne na základe mena počítača a užívateľského mena vyhodnotí čo sa vykoná a čo nie...

Presmerovanie dôležitých adresárov (Folder Redirection)

Napísal som síce "dôležitých" ale to len preto, že netuším ako sa oficiálne volajú... Jedná sa o zložky My Documents, Application Data, Desktop a Start Menu.
Tieto sú obvykle uložené na lokálnom disku a zväčša sa teda nezálohujú. Taktiež ak užívateľ používa viacero počítačov (každý deň pracuje na inej pracovnej stanici) tak by mu mohli dokumenty napríklad na pracovnej ploche chýbať...
Existujú aj tzv. Roaming Profiles keď sú profily ukladané tiež na servri avšak tieto sa pri prihlásení užívateľa vždy skopírujú na lokálny počítač a tam jednak zaberajú miesto a jednak nie vždy je žiadúce aby sa privátne užívateľské dáta ukladali na viaceré počítače...

Príklad - administrátor Lubo pracuje väčšinou na svojom počítači XPClientA a na ploche má množstvo užitočných ikoniek a dokumentov pre správu siete... Jedného dňa mu zavolá Zoe, že "čosi" jej nechce fungovať. Lubo teda príde do jej kancelárie (ktorá je pomerne ďaleko) a zistí že na vyriešenie problému je treba upraviť pár vecí na servri. Prihlási sa teda na jej počítač (povedzme že to je XPClientB) a uvidí že všetky tie dôležité súbory čo mal na pracovnej ploche tam teraz nie sú...
Napríklad na ploche má uloženú detailnú konfiguráciu routrov a celú konfiguráciu vôbec.

Ďalší problém - dokumenty na pracovnej ploche si nezálohuje a tak v prípade nejakého vážneho problému na počítači XPClientA by nebol veľmi spokojný keby o dáta na pracovnej ploche prišiel...

Ak by použil Roaming profiles, síce by to fungovalo ale znamenalo by to isté bezpečnostné riziko pretože na pracovnej ploche má napr. uložené prístupové heslá a nebolo by dobré keby sa tento súbor kopíroval na lokálny disk kde by ho mohol prípadný útočník nájsť.

Všetky tieto problémy rieši presmerovanie adresárov...

Ako prvé si niekde na servri (File servri ServerB) vytvorím zdieľanú zložku kde budem presmerované adresáre ukladať.
Prístupové práva môžem dať všetkým plné, neskôr to upravím cez NTFS prístupové práva...

Vytvorím nový GPO prilinkovaný k celej doméne (presmerujem pracovné plochy pre všetkých užívateľov).
V GPO povolím Folder Redirection, a nastavím Basic...
Dôležité je aby sa pre každého užívateľa vytvoril nový adresár (Create a folder for each user under the root path) a Root path nech je zdieľaná zložka, ktorú som vytvoril na servri...

Pri gpupdate /force sa bude treba odhlásiť a prihlásiť (resp. na to aby sa aplikovalo presmerovanie adresárov je potrebný Log Off a Log On)...

Ale dôležíté je, že Lubova pracovná plocha je rovnaká na všetkých počítačoch, kde sa prihlási...
Vľavo XPClientA, vpravo XPClientB

Kvôli testom som si vytvoril aj nový virtuálny počítač s operačným systémom Windows Vista a pridal ho do domény.
Bohužiaľ sa zdá, že Windows Vista pracovnú plochu zo servra nevie použiť a - nefunguje to (možno len teraz a možno len neviem ako) a Lubova pracovná plocha nie je dostupná.
Našťastie sa však dá k dokumentom dostať aspoň priamo cez \\serverb\

Informáciu o tom že pracovné plochy sú odteraz presmerované zachytila aj Mallory a samozrejme sa z toho bude snažiť (ako správna záškodníčka) vyťažiť. Keďže Zoe jej spomínala, že Lubo jej bol pomôcť s počítačom, pokúsi sa nájsť na počítači XPClientB nejaké Lubove dokumenty...

Mallory je v počítačoch celkom zdatná a tak vie, že profily sa ukladajú v C:\Documents and Settings.
Prístup k Lubovej zložke jej však bude zamietnutý...

Mallory však vie že to bolo iba preto, že v doméne jej účet veľa neznamená...
V istom okamihu - pri inštalovaní počítača si všimla že lokálny administrátorský účet má prihlasovacie údaje administrator a password. Nič jej teda nebráni prihlásiť sa lokálne.
Ani toto jej však nepomôže a aj keď bude mať teraz k Lubovej zložke prístup súbory z pracovnej plochy (adresár Desktop) tu nie sú...

K Active Directory resp. Group Policy prístup Mallory síce nemá, ale povedzme že sa jej nejakým spôsobom podarilo zistiť kde sú užívateľské pracovné plochy uložené. (Keďže som zdieľanú zložku ani nespravil skrytou, pomocou znaku $, tak to nebolo zas až tak ťažké...) Skúsi sa teda k dátam dostať priamo na servri...

Avšak ani tu sa k Lubovej pracovnej ploche (kvôli prístupovým právam) nedostane. A to že je prihlásená ako lokálny administrátor jej v tomto prípade veľmi nepomôže...
Lubove dáta sú teda relatívne v bezpečí (preto iba relatívne, lebo existujú aj zdatnejší útočníci ako Mallory...)

Takto podobne je možné presmerovať aj My Documents príp. Application Data a Start Menu...

Prihlasovacie skripty (Logon Scripts) a sieťové disky (Network Drives)

Ešte v časoch MS Dosu existoval súbor autoexec.bat, v ktorom sa dalo určiť ktoré aplikácie sa majú spustiť a ktoré príkazy vykonať pri každom reštarte počítača... V operačnom systéme Windows má podobnú úlohu zložka "Spustiť pri štarte" (Startup items) príp. niektoré veci sa dajú nastaviť v registroch problém však nastáva ak potrebujem mať pre každého užívateľa nastavenia rôzne.
Alebo - ak aj potrebujem mať nastavenia rovnaké ale v rámci celej domény a aby to bolo ľahko ovládateľné z jedného miesta. A práve na toto slúžia prihlasovacie (príp. aj odhlasovacie) skripty

Veľmi jednoduchý príklad - povedzme, že zakaždým pri vypnutí počítača chcem vyprázdniť adresár temp v Windows... Často sa tam hromadia nepotrebné súbory po rôznych inštaláciách a tak sa to môže hodiť. (možno nie po každom reštarte, ale v tomto príklade sa pokúsim práve o toto)

Vytvorím si teda nový GPO a prilinkujem ho k celej doméne. Teraz hľadám Logoff Scripts.

Kliknem na Show Files (aby som vedel kde sa tie skripty ukladajú) a vytvorím tu nový skript, ktorý zmaže všetko v C:\Windows\Temp

Kliknem na Add a pridám novovytvorený skript...

Pri gpupdate /force sa ukáže že je potrebný log off a log on, takže sa odhlásim, prihlásim a skúsim niečo nahrať do C:\Windows\Temp. Pri najbližšom odhlásení bude to čo som tam nahral (resp. hocičo v temp) vymazané...

Avšak asi najčastejšie sa prihlasovacie skripty používajú na primapovanie sieťových diskov. Sieťové disky sú obyčajné zdieľané zložky na file servri, avšak aby si užívatelia nemuseli pamätať presnú cestu a názov servra (pričom toto sa môže hocikedy zmeniť) je jednoduchšie pre nich vedieť, že dokumenty sú napr. na disku H:

Namapovať sieťovú zložku ako disk nie je nič zložité, stačí druhé tlačítko na zdieľanú zložku a Map network drive...

Skúsenejší užívateľ to dokonca zvládne aj z príkazového riadku.
net use h: "\\serverb\Projects Data"
Nie všetci užívatelia sú však tak skúsení a - bolo by dobré keby mali všetci túto zložku namapovanú ako rovnaký disk - H: Aj toto rieši Group Policy a Logon Scripts.

Podobne ako pri odhlasovacích skriptoch - iba vytvorím GPO s prihlasovacím skriptom, vytvorím nový skript (bat súbor) s jedným riadkom net use h: "\\serverb\Projects Data"

Pridám tento skript...

Nalinkujem nový GPO (pomenoval som ho Logon Scripts) k celej doméne a hotovo.

Ak sa teraz prihlásim napr. ako Trent (na toho som zabúdal :) tak "disk H:" bude namapovaný automaticky.

Keď je reč o sieťových diskoch - ďalšia vec čo sa často používa sú tzv. užívateľské disky. Toto je čosi podobné ako presmerovanie zdieľanej plochy na server. Aj v tomto prípade sa pre každého užívateľa vytvorí nová sieťová zložka a táto sa namapuje ako nový disk. Každý užívateľ má potom svoj disk (napr.) U: a má k nemu prístup bez ohľadu na to na ktorom počítači práve pracuje.
Užívateľské disky nijak nesúvisia s Group Policy, je to len podobná téma.

Ako prvé je znova najprv potrebné vytvoriť na servri zdieľanú zložku, kde budú tieto "disky" uložené. Prístupové práva (Permissions) môžem povoliť všetkým.
Bolo by lepšie kvôli bezpečnosti zdieľať zložku ako skrytú (znak $ na konci) ale keďže zatiaľ len odlaďujem nechám to takto...

Potom v Active Directory vyberiem užívateľa a v Profile nastavím kde je jeho užívateľský disk (Home Folder)
%username% zastupuje užívateľské meno a v tomto prípade sa automaticky zamení za Charlie.
Samozrejme toto všetko je dobré spraviť ešte predtým ako vytvorím všetkých užívateľov (kopírovať nastavenia zo šablóny - template user) inak budem musieť urobiť zmeny v AD pre každého užívateľa zvlášť.

Keď sa teraz Charlie prihlási (na hocijakom počítači v doméne) má k dispozícii disk H: a svoj vlastný disk U:. Výhody sú zrejmé (prístup odvšadiaľ, centrálne miesto správy, zálohovanie).

Prístupové práva neboli samozrejme nastavené automaticky a treba to upraviť. Ak sa teraz prihlási napr. Eva (okrem iného je vidieť že na Evu sa GPO neprejavujú - v istom okamihu som pre užívateľov z Research zakázal dedenie Group Policy) tak jej disk U: (ak som ho vytvoril) je odlišný od toho Charlieho.
Avšak keďže som ponechal zdieľanú zložku viditeľnú Eva ju ľahko na servri nájde...

A dokonca má k Charlieho dátam plný prístup...
Je teda potrebné prístupové práva nastaviť.

Inštalácia programov pomocou Group Policy (Deploying Applications)

Na inštaláciu programov v rámci celej organizácie sa síce používa skôr SMS a SUS server ale jednoduchšie aplikácie je možné "nasadzovať" aj pomocou Group Policy.
Toto rieši problém keď je v organizácii veľa počítačov a všetky (veľa z nich) používa nejaký program a tento by bolo treba za normálnych okolností nainštalovať manuálne na každom počítači zvlášť. Ak si vytvorím na toto GPO program(y) sa nainštaluje sám automaticky.

Ako prvé nahrám inštalačný balíček programu (v tomto prípade Winamp) na server, kde má každý k nemu prístup.

Vytvorím nový GPO a v položke Computer Configuration, Software Installation pridám balíček...

A odteraz by všetko fungovalo, avšak mne sa nepodarilo nájsť msi balíček s ktorým by si Group Policy rozumelo a tak proste screenshoty nebudú uff. Toto je myslím DOSŤ veľký problém takéhoto nasadzovania aplikácií - msi balíčkov až toľko nie je a aj tie čo sú občas nefungujú...
Avšak za normálnych okolností by sa Winamp fakt nainštaloval na všetky počítače, ku ktorým by bol GPO prilinkovaný...

Assign - značí, že je to len "pripravené" k inštalácii - navonok sa bude Winamp tváriť ako nainštalovaný, ale k inštalácii dôjde až vtedy keď ho bude užívateľ prvý krát potrebovať (napr. klikne na mp3).

Publish - Užívateľ si bude môcť Winamp priinštalovať - ak zájde do Control Panel, Add Remove Programs a Add New Programs

Remove - odinštalovať

Redeploy - preinštalovať

(c) Wray 2007