Automatyzowanie zarządzania zasadami grupy przy użyciu Windows PowerShell

Autor: Darren Mar-Elia

Opublikowano: 26 października 2009

Zawartość strony

	Co udostępnia narzędzie GPMC?
	Automatyzowanie cyklu życiowego GPO
	Automatyzowanie raportowania Zasad grupy
	Generowanie raportu HTML
	Generowanie raportu XML
	Raport rejestrujący RSoP
	Prostsza metoda

 

Artykuł ten jest częściowo oparty o wstępną wersję oprogramowania i może ulec zmianie.

Zasady grupy są mechanizmem o wielkich możliwościach, ale zarazem bardzo złożonym. W jakimś zakresie stosowane są niemal w każdym środowisku. Zaś dla wielu, którzy właśnie na nich opierają bezpieczeństwo i stabilność środowiska Windows, Zasady grupy są kluczowym elementem infrastruktury.

Niezależnie od powyższego, ciągle zaskakuje mnie, jak niewiele automatyzacji stosowanych jest przy zarządzaniu Zasadami grupy w wielu organizacjach. Wraz z utworzeniem narzędzia Group Policy Management Console (GPMC) Microsoft udostępnił kilka interfejsów programowania aplikacji (API) oraz przykładowe skrypty demonstrujące automatyzowanie zadań wykonywanych przez konsolę. API te umożliwiają wykonanie bardzo wielu działań, a poza tym zapewniają możliwość zautomatyzowania innych aspektów zarządzania Zasadami grupy, takich jak zadania dotyczące rozwiązywania problemów i diagnostyki. A wraz z pojawieniem się Windows PowerShell wiele z tych zadań stało się znacznie łatwiejszych.

Wykorzystanie Windows PowerShell do komunikacji z niektórymi API GPMC omówił Thorbjörn Sjövold w artykule „Simplify Group Policy Administration with Windows PowerShell”. W tym artykule chcę przedstawić niektóre dodatkowe techniki, których można użyć do dalszej automatyzacji zarządzania środowiskiem Zasad grupy.

Co udostępnia narzędzie GPMC?

Konsola GPMC przeznaczona jest do operowania całymi obiektami zasad grupy (GPO) wraz z powiązanymi z nimi uprawnieniami, połączeniami i tak dalej, Nie zapewnia ona możliwości automatyzacji ani nawet zarządzania rzeczywistymi ustawieniami zawartymi wewnątrz GPO. Tym niemniej może być przydatna do zautomatyzowania zadań dotyczących całych obiektów zasad jako sposób zarządzania zmianami w środowisku Zasad grupy. Na przykład można wykorzystać API GPMC do zmodyfikowania połączeń obiektów zasad. Jeśli przygotowujemy nowy GPO, który chcemy rozpowszechnić, można oskryptować zarówno samo tworzenie GPO, jak i proces tworzenia połączeń już po wypełnieniu go właściwymi ustawieniami. Z poziomu skryptów można również dokonywać zmian uprawnień GPO w sytuacji, gdy chcemy zmodyfikować grupy zabezpieczeń będące celem danego GPO albo określić, kto będzie mógł edytować ten obiekt zasad.

Oczywiście zawsze można użyć API do odczytywania informacji dotyczących GPO – w przeciwieństwie do samego dokonywania zmian. Obejmuje to również tworzenie raportów w formatach HTML- lub XML w oparciu o ustawienia GPO, a także tworzenie raportów wynikowych zestawów zasad (Resultant Set of Policy ‑ RSoP) dotyczących zdalnych stacji roboczych i serwerów, co pozwala określić, czy Zasady grupy zostały zastosowane z powodzeniem.

Warto również wspomnieć, że gdy firma Microsoft opublikowała uaktualnioną wersję GPMC dołączoną do Windows Vista SP1 oraz Windows Server 2008, nastąpiły również pewne zmiany w API, zapewniające wsparcie dla niektórych spośród nowych funkcji GPMC i ogólne wsparcie mechanizmu Zasad grupy. Wymienić tu należy możliwość tworzenia nowych obiektów zasad z obiektu „Starter GPO” oraz dodawania komentarzy. Startowe obiekty zasad przypominają szablony – pozwalają przygotować zestaw ustawień Administrative Template, które mają być zawarte w nowych obiektach zasad, od razu ustawiając domyślne wartości niektórych z nich. Spróbujmy więc przyjrzeć się, jak można zautomatyzować proces tworzenia, definiowania uprawnień i tworzenia połączeń dla obiektu zasad grupy, a następnie jak moglibyśmy wykorzystać niektóre nowe funkcje GPMC w tej automatyzacji.

 Do początku strony

Automatyzowanie cyklu życiowego GPO

Aby zademonstrować, jak można zautomatyzować tworzenie i administrowanie obiektami zasad grupy, zamierzam posłużyć się środowiskiem Windows PowerShell oraz API GPMC. W tym przykładzie utworzę GPO o nazwie „TechNet Marketing Policy”. Do tworzenia GPO zamierzam użyć Starter GPO o nazwie „User Lockdown Template” jako punktu wyjścia, po czym dodać komentarz informujący, że to ja go utworzyłem. Sam Starter GPO również można utworzyć za pomocą API GPMC, ale w tym przykładzie zakładam, że obiekt ten już istnieje.

Kolejnym krokiem jest określenie uprawnień dla utworzonego GPO. Zamierzam określić takie uprawnienia, aby tylko użytkownicy z grupy „Marketing Users” mogli przetwarzać zawarte w nim zasady (a tym samym tylko do nich zostaną one zastosowane), oraz dodam grupę „GPO Admins” mającą uprawnienia do edytowania tego GPO. Na koniec podłączę GPO do jednostki organizacyjnej Marketing OU w mojej domenie Active Directory.

Kompletny skrypt Windows PowerShell, który nazwałem gpoCreate.ps1, przedstawiono na Rysunku 1. Numery wierszy zostały dodane dla przejrzystości.

$gpmc = New-Object -ComObject GPMgmt.GPM

$constants = $gpmc.GetConstants()

$domain = $gpmc.GetDomain("cpandl.com",$null,$null)

$starter = $domain.GetStarterGPO("{CDFD6B94-BF4E-4D07-8D99-3D416EC7C9A0}")

$gpo = $domain.CreateGPOFromStarterGPO($starter)

$gpo.DisplayName = "Technet Marketing Policy"

$gpo.Description = "Created by Darren for Technet Demo"

$permissions = $gpo.GetSecurityInfo()

$permissions.RemoveTrustee("Authenticated Users")

$applyPermission = $gpmc.CreatePermission("Marketing Users",$constants.permGPOApply,$false)

$editPermission = $gpmc.CreatePermission("GPO Admins",$constants.permGPOEdit,$false)

$permissions.Add($applyPermission)

$permissions.Add($editPermission)

$gpo.SetSecurityInfo($permissions)

$som = $domain.GetSOM("OU=Marketing,DC=cpandl,DC=com")

$som.CreateGPOLink(1,$gpo)

Rysunek 1: Skrypt gpoCreate.ps1.

Wiersz 1 jest konieczny, aby rozpocząć korzystanie z API GPMC. Musi się on pojawić w każdym skrypcie GPMC. Wiersz ten tworzy instancję bazowego obiektu GPMC i przypisuje go do zmiennej $gpmc. Wiersz 2 to inne standardowe polecenie. GPMC udostępnia zbiór przydatnych stałych, które są używane w bardzo wielu zadaniach do sygnalizowanego stanu. Zobaczymy później, jak zostaną użyte w skrypcie, ale w tym momencie po prostu przypisuję te stałe do zmiennej $constants.

Trzeci wiersz pozwala uzyskać odsyłacz do domeny Active Directory, w której będziemy działać. W tym przykładzie domena ta nazywa się cpandl.com. W tym celu wywołuję metodę GetDomain dla zmiennej $gpmc. Dwa parametry $null są opcjonalne i pozwalają określić konkretny kontroler domeny, z którym należy się połączyć. Ponieważ parametry te zostały pominięte, użyta zostanie wartość domyślna, czyli kontroler domeny odgrywający rolę emulatora PDC.

W wierszu czwartym muszę uzyskać odsyłacz do wybranego przeze mnie Starter GPO (User Lockdown Template). Jednak metoda GetStarterGPO wspiera jedynie wywołanie Starter GPO za pośrednictwem jego GUID (globalnie unikatowego identyfikatora), zatem musiałem zajrzeć do konsoli GPMC, aby ustalić tę wartość (jakkolwiek to zadanie również można wykonać skryptem). Znaleziony GUID zostaje przesłany do metody GetStarterGPO.

W wierszu piątym, mając już odsyłacz do Starter GPO, wykorzystuję go do utworzenia nowego obiektu zasad grupy przy użyciu metody CreateGPOfromStarterGPO, dostępnej dla zmiennej $domain. Nowo utworzony obiekt zasad przypisuję do zmiennej $gpo, dzięki czemu będę mógł się do niego odwoływać później. Warto zauważyć, że w tym momencie nowy GPO nie ma nazwy, a ściślej mówiąc, ma nazwę domyślną „New Group Policy Object” (Nowy obiekt zasad grupy). Zatem w wierszu szóstym modyfikuję właściwość DisplayName zmiennej $gpo, aby nadać mu nową nazwę. Wiersz siódmy dodaje komentarz do obiektu zasad poprzez ustawienie właściwości Description zmiennej $gpo.

Teraz, gdy utworzyłem już GPO, następny zestaw zadań to zmodyfikowanie uprawnień do tego obiektu. W wierszu ósmym uzyskuję bieżącą listę uprawnień do nowo utworzonego obiektu, wykorzystując wobec niego metodę GetSecurityInfo. Technika modyfikowania uprawnień sprowadza się do uzyskania listy bieżących uprawnień do obiektu, dodania i usunięcia wpisów z tej listy zgodnie z potrzebami, po czym ponownego zaaplikowania listy do GPO. Tak więc w wierszu dziewiątym usuwam domyślny wpis uprawnień dla grupy Authenticated Users z nowo utworzonego obiektu zasad.

W wierszach dziesiątym i jedenastym tworzę dwa nowe wpisy uprawnień, które chcę dodać do GPO. Osiągam to przy użyciu metody CreatePermission dla zmiennej $gpmc, podając nazwę Trustee (grupy użytkowników) oraz uprawnienie, które grupa ta ma uzyskać. Warto zwrócić uwagę, że do definiowania uprawnienia wykorzystuję zmienną $constants. Właściwość $constants.permGPOApply przyznaje uprawnienie „Read and Apply Group Policy” (Odczyt i stosowanie zasad), które pozwala członkom grupy na przetwarzanie obiektu zasad, podczas gdy właściwości permGPOEdit przyznaje wskazanej grupie zdolność do edytowania GPO. Parametr $false na końcu wywołania metody CreatePermission powoduje, że uprawnienie to nie będzie dziedziczone, aby zastąpić domyślne zachowanie uprawnień GPO.

Po utworzeniu tych dwóch uprawnień wiersze dwunasty i trzynasty dołączają je ponownie do listy $permissions, zaś w wierszu czternastym wywołana zostaje metoda SetSecurityInfo, aplikująca nową listę w obiekcie zasad.

Końcowe dwa wiersze tworzą połączenie GPO z jednostką organizacyjną (OU) Marketing. W wierszu piętnastym, wywołuję metodę GetSOM (SOM oznacza „scope of management” – „zakres zarządzania”) dla zmiennej $domain, aby „połączyć” obiekt z OU. W wierszu szesnastym wywołuję metodę CreateGPOLink dla obiektu $som utworzonego w poprzednim kroku i przekazuję do niej dwa parametry. Pierwszy określa kolejność, w jakiej obiekt zasad jest przyłączany do OU (do jednostki organizacyjnych można przyłączyć wiele obiektów zasad). Wartość „1” wymieniona jako pierwszy parametr oznacza, że chcę, aby GPO był przyłączony jako pierwszy na liście. Drugi parametr (w tym przypadku jest to zmienna $gpo) wskazuje GPO, który ma zostać przyłączony.

Tym samym udało się z powodzeniem utworzyć, określić uprawnienia i połączyć GPO w sposób automatyczny. Rezultat ukazuje Rysunek 2.

Rysunek 2: Przeglądanie nowo utworzonego obiektu zasad grupy.

 Do początku strony

Automatyzowanie raportowania Zasad grupy

Innym aspektem zarządzania Zasadami grupy, który można zautomatyzować, jest raportowanie. Z tego punktu widzenia istnieją co najmniej dwa typy raportów dostarczanych przez GPMC. Pierwszym jest możliwość stworzenia spisu ustawień zawartych wewnątrz GPO. Umożliwia to wygenerowanie raportu w formacie HTML albo XML, zawierającego ustawienia, które są aktualnie włączone w danym GPO, co pokazano na Rysunku 3.

Rysunek 3: Raport ukazujący ustawienia GPO.

Druga opcja to możliwość generowania raportów Resultant Set of Policy (RSoP) (inaczej Group Policy Results – Wyniki zasad grupy). Istnieją dwa typy raportów RSoP – rejestrujące i planowe. Raport rejestrujący wykonywany jest względem określonej stacji roboczej lub serwera, ukazując zasady, które zostały przekazane do tego systemu, i to, czy ich aplikacja zakończyła się su3kcesem. Raporty planowe RSoP pozwalają wykonać analizę typu „co by było, gdyby” względem wskazanej jednostki organizacyjnej, komputera czy użytkownika, aby określić, jakie zasady zostaną zastosowane. W obu wypadkach można utworzyć wynik w formacie HTML lub XML, używając API GPMC oraz Windows PowerShell.

 Do początku strony

Generowanie raportu HTML

Aby utworzyć raport zawierający ustawienia GPO za pomocą Windows PowerShell, rozpocznę od użycia dwóch poleceń, które zastosowałem już w poprzednim skrypcie:

gpmc = New-Object -ComObject GPMgmt.GPM

$constants = $gpmc.GetConstants()

Następnie muszę uzyskać odsyłacz do obiektu GPO, którego ma dotyczyć raport, podobnie jak w przykładzie:

$domain = $gpmc.GetDomain("cpandl.com",$null,$null)

$gpo = domain.GetGPO("{31B2F340-016D-11D2-945F-00C04FB984F9}")

W wierszu trzecim wykonuję połączenie z domeną, zaś w czwartym wykorzystuję metodę GetGPO w tej domenie, aby uzyskać odsyłacz do obiektu zasad. W tym celu muszę przekazać GUID tego GPO (w tym wypadku jest to obiekt „Default Domain Policy”).

Teraz mogę przejść do generowania raportu o ustawieniach:

$gpo.GenerateReportToFile($constants.ReportHTML,"c:\GPReports\DDPSettings.html")

Wywołuję tu metodę GenerateReportToFile względem GPO w celu utworzenia raportu o ustawieniach. Pierwszy parametr wykorzystuje zmienną $constants w celu wyspecyfikowania typu raportu (ReportHTML). Drugi parametr określa ścieżkę pliku, w którym raport zostanie zapisany.

 Do początku strony

Generowanie raportu XML

Inną metodą dostępu do danych ustawień za pomocą Windows PowerShell jest skorzystanie z wbudowanych w tę powłokę funkcji przetwarzania XML wraz z możliwością generowania raportu w formacie XML. Tak więc wiersz piąty z poprzedniego przykładu zmienię następująco:

[xml]$report = ($gpo.GenerateReport($constants.ReportXML)).Result

W tym przykładzie używam innej metody wobec GPO – GenerateReport. Metoda ta wykorzystuje tylko pojedynczy parametr, określający typ raportu. Jednak w tym wypadku wiążę wyjście wywołania metody ze zmienną $report, poprzedzając tę nazwę akceleratorem typu środowiska Windows PowerShell [xml], nakazując PowerShell przejęcie danych wyjściowych polecenia zapisanych w zmiennej $report i przekonwertowanie ich do postaci dokumentu XML zamiast czystego tekstu. Jednak aby uzyskać rzeczywiste dane XML z metody GenerateReport, musiałem użyć właściwości Result dla tego wyjścia, co jest widoczne na końcu wyrażenia. Tak więc właściwość ta przechowuje faktyczne dane XML, które zostaną wykorzystane do wygenerowania dokumentu XML.

W momencie, gdy mamy już XML w zmiennej $report, można z nim zrobić wiele interesujących rzeczy. Dla przykładu rozważmy polecenie:

$report.GPO

Zwraca ono element „GPO” dokumentu, udostępniający ogólne informacje na temat obiektu zasad, którego dotyczy raport. Albo takie polecenie:

$report.GPO.LinksTo

Zwraca ono listę wszystkich miejsc, z którymi dany GPO jest połączony.

Co jednak jest znacznie bardziej interesujące, można wykorzystać strukturalną naturę XML do zbadania rzeczywistych ustawień zawartych w GPO z poziomu wiersza polecenia. Na przykład, ponieważ jest to Default Domain Policy GPO, wiemy, że zawiera on pewne ustawienia zabezpieczeń dotyczące zasad haseł. Dzięki przeglądaniu przestrzeni nazw GPO reprezentowanej w pliku XML można szybko dotrzeć do tych ustawień, jak w przykładzie:

$report.GPO.Computer

Polecenie zwraca informacje o części ustawień GPO dotyczących komputera. Jeśli wyświetlimy właściwości dla cechy Computer, łatwo zauważymy zbiór ustawień zasad widoczny dla właściwości ExtensionData, co ukazuje Rysunek 4.

Rysunek 4: Wyświetlanie ustawień GPO za pośrednictwem XML.

W tym przykładzie istnieją dwa obszary rozszerzeń w części GPO dotyczącej komputera: Registry (rejestr) oraz Security (zabezpieczenia). Użyjmy zatem polecenia:

$report.GPO.Computer.ExtensionData[0].Extension

Zwraca ono listę obszarów zasad zaimplementowanych w sekcji Security. Można tu zobaczyć dwie właściwości o nazwach Account (Konto) oraz Security Options (Opcje zabezpieczeń). Wprowadźmy zatem następujące polecenie:

$report.GPO.Computer.ExtensionData[0].Extension.Account

Zwraca ono listę wszystkich ustawień Account Policy (Zasady konta) dla tego GPO, jak pokazuje Rysunek 5.

Rysunek 5: Wyświetlanie ustawień Account Policy w GPO.

Zwróćmy uwagę, że niektóre ustawienia widoczne na Rysunku 5 nie ukazują wartości. Każde ustawienie zwracane jest jako członek kolekcji wewnątrz właściwości Account. Zatem w celu wyświetlenia na przykład ustawienia Minimum Password Length należy wskazać indeks kolekcji, tak jak w przykładzie:

$report.GPO.Computer.ExtensionData[0].Extension.Account[4]

Gdy już zorientujemy się w technikach poruszania się po przestrzeni nazw XML dla ustawień GPO, możemy łatwo dostać się do konkretnych ustawień i wykorzystać tę możliwość w połączeniu z mechanizmami Windows PowerShell, aby szybko zlokalizować wartości ustawień wewnątrz GPO.

 Do początku strony

Raport rejestrujący RSoP

Podobnie jak w przypadku ustawień GPO można przy użyciu Windows PowerShell wygenerować raporty w formacie XML lub HTML, ukazujące ustawienia zasad, które zostały rzeczywiście zaaplikowane na określonym komputerze. Metoda postępowania jednak nieco się różni od pokazanej w poprzednich dwóch przykładach. Rozpocznę od dwóch poleceń inicjujących, ale później poprowadzę skrypt w nieco innym kierunku:

$gpmc = New-Object -ComObject GPMgmt.GPM

$constants = $gpmc.GetConstants()

$rsop = $gpmc.GetRSOP($constants.RSOPModeLogging,$null,0)

$rsop.LoggingComputer = "xp2"

$rsop.LoggingUser = "cpandl\dpmtest"

$rsop.CreateQueryResults()

$rsop.GenerateReportToFile($constants.ReportHTML,"c:\gpreports\XP2Rsop.html")

Po wierszach pierwszym i drugim, które rozpoczynają cały proces, wiersz trzeci tworzy zmienną $rsop poprzez wywołanie metody GetRSOP wobec zmiennej $gpmc. W wywołaniu metody zaznaczam, że chcę utworzyć raport rejestrujący (logging), a nie planowy. Wiersze czwarty i piąty określają właściwości tego obiektu $rsop, informując, dla którego komputera i użytkownika mają być gromadzone dane RSOP. Następnie jedynym przeznaczeniem wiersza szóstego jest utworzenie połączenia z komputerem wskazanym w wierszu piątym i wygenerowanie przestrzeni nazw RSoP dla tego zapytania. Na koniec w wierszu siódmym wyniki zapytania kierowane są do pliku HTML.

Zwróćmy uwagę, że obiekt RSoP ma również metodę GenerateReport podobną do omówionej w przykładzie dotyczącym ustawień GPO. Oznacza to, że można raport RSOP uzyskać jako dokument XML i przeglądać przy użyciu Windows PowerShell, aby ustalić, co dzieje się na wskazanym komputerze z perspektywy Zasad grupy. Dla przykładu załóżmy, że chcę szybko sprawdzić, czy przetwarzanie Zasad grupy zakończyło się powodzeniem dla części Computer obiektów zasad. Wykorzystam poprzedni skrypt, zastępując wiersz siódmy następującym:

[xml]$rsopReport = 

  ($rsop.GenerateReport($constants.ReportXML)).Result

Powoduje on skierowanie raportu RSoP do dokumentu XML.

Następnie mogę przejrzeć przestrzeń nazw XML w celu ustalenia statusu Client-Side Extension (CSE) dla danego komputera:

$rsopReport.Rsop.ComputerResults.ExtensionStatus

Spowoduje to wyświetlenie statusu dla każdego CSE przetworzonego przez ten komputer!

 Do początku strony

Prostsza metoda

Jak można zauważyć, wykorzystanie API GPMC daje wielkie możliwości automatyzowania cyklu życiowego obiektów zasad, raportowania czy zadań diagnostycznych. Nadal jednak trzeba wykonać kilka kroków, aby uzyskać pożądane rezultaty. Istnieją tutaj pewne ułatwienia, a jeszcze więcej ma się pojawić w niedalekiej przyszłości.

Utworzyłem zbiór 25 darmowych poleceń cmdlet Windows PowerShell dla GPMC, które opakowują najczęstsze funkcje GPMC. Polecenia te można pobrać z witrynywww.sdmsoftware.com/freeware. Aby zademonstrować, jak upraszczają one cały proces, weźmy pierwszy przykład tworzenia, przypisywania uprawnień i łączenia GPO. Poniższy skrypt używający moich poleceń cmdlet pozwoli wykonać te same zadania, ale w mniejszej liczbie kroków:

$gpo = New-SDMgpo "Technet Marketing Policy" 

  -FromStarterGPO "User Lockdown Template" –native

$gpo.Description = 

  "Darren's Technet Demo GPO" Remove-SDMgpoSecurity 

$gpo.DisplayName -Trustee "Authenticated Users"  –PermApply

Add-SDMgpoSecurity $gpo.DisplayName 

  -Trustee "Marketing Users" –PermApply

Add-SDMgpoSecurity $gpo.DisplayName 

  -Trustee "GPO Admins" –PermEdit

Add-SDMgplink "Technet Marketing Policy" 

  -Scope "OU=Marketing,DC=cpandl,DC=com" -Location 1

Co więcej, Windows 7 oraz Windows Server 2008 R2 będą zawierały wbudowane polecenia cmdlet dla GPMC. Na przykład, aby utworzyć GPO na podstawie Starter GPO z jednoczesnym dodaniem komentarza, wystarczy tylko jedno polecenie Windows PowerShell:

new-gpo "Darren's Technet Policy" -starterGPOName 

 "User Lockdown Template" -Comment "Darren's Demo"

Firma Microsoft dodała również wsparcie do odczytywania i zapisywania podzbiorów ustawień Zasad grupy. Mówiąc ściśle, dostępna będzie możliwość odczytywania i zapisywania ustawień rejestru albo w tradycyjnej gałęzi Administrative Template, albo w nowym rozszerzeniu Group Policy Preferences. Na przykład, aby zapisać nową wartość rejestru w rozszerzeniu Group Policy Preferences, trzeba użyć polecenia:

Set-GPPrefRegistryValue "Darren's Technet Policy" 

  -key 'HKEY_LOCAL_MACHINE\Software\SDM Software' 

  -ValueName "Path" -Value "2" -Type String 

  -Context Computer -Action Update

W tym przykładzie polecenie cmdlet set-GPPrefRegistryValue pobiera kilka parametrów, aby utworzyć zasadę rejestru wewnątrz obiektu „Darren's Technet Policy” dla klucza HKEY_LOCAL_MACHINE\Software\SDM Software\Path= REG_SZ 2. Parametr Context informuje, czy zasada powinna zostać umieszczona w części Computer, czy też User obiektu zasad, zaś parametr Action określa, jak wartość rejestru ma być zastosowana, i odpowiada opcjom dostępnym w interfejsie użytkownika (inne opcje to Replace, Create oraz Delete).

W momencie pisania tego artykułu planowane było opublikowanie Windows 7 i Windows Server 2008 R2 wraz z 25 poleceniami cmdlet umożliwiającymi zarządzanie Zasadami grupy. Gdy polecenia te będą dostępne, zarządzanie Zasadami grupy za pośrednictwem Windows PowerShell będzie dużo łatwiejsze.

O autorze

Darren Mar-Elia jest MVP w dziedzinie zasad grupy, twórcą popularnej witryny www.gpoguy.com i współautorem książki Microsoft Windows Group Policy Guide (Microsoft Press, 2005). Jest również CTO i założycielem firmy SDM Software, Inc. można się z nim skontaktować pod adresem Darren@gpoguy.com.

Do początku strony

---