• Artykuł

Microsoft SQL Server 2008

PowerShell dla administratorów SQL Server (cz. II) Udostępnij na: Facebook

Opublikowano: 14 lipca 2009
Autor: Damian Widera

 

Wprowadzenie do Policy-Based Management  Wprowadzenie do Policy-Based Management
Polityki zarządzania serwerem w konsoli PowerShell  Polityki zarządzania serwerem w konsoli PowerShell
Wykonanie skryptu tworzącego politykę zarządzania serwerem SQL.  Wykonanie skryptu tworzącego politykę zarządzania serwerem SQL.
Narzędzie wspomagające tworzenie skryptów PowerShell  Narzędzie wspomagające tworzenie skryptów PowerShell
Podsumowanie  Podsumowanie
Literatura  Literatura
Załącznik  Załącznik

 

PowerShell to nowy język skryptowy firmy Microsoft, którego istnienia nie sposób pominąć. Można co prawda zadać sobie pytanie – po co uczyć się i poznawać kolejny język programowania?

Pierwszy artykuł z serii prezentował ogólne możliwości, które daje użycie tego języka. W drugim artykule postanowiłem pokazać, w jaki sposób można użyć skryptu PowerShell do programowania i zarządzania systemem zarządzania politykami serwera.

Wprowadzenie do Policy-Based Management

System zarządzania politykami serwera (ang. Policy-Based Management, PBM) jest z całą pewnością jedną z najważniejszych nowości, która została wprowadzona do SQL Server 2008.

 

Pobierz
Pobierz artykuł w pliku:

PBM pozwala na zarządzanie instancjami SQL Server poprzez definiowanie polityk (ang. policies). Administratorzy baz danych mogą używać PBM między innymi za pomocą SQL Server Management Studio (SSMS) ,czyli tworzyć polityki oraz zarządzać serwerem, bazami danych, tabelami, indeksami lub innymi obiektami zawartymi w SQL Server.

W SQL Server 2008 zostały przygotowane szablony reguł oparte o najlepsze praktyki zaimplementowane w narzędziu Best Practices Analyzer, używanym przez administratorów z poprzednimi wersjami systemu SQL Server.

System Policy Based Management ma strukturę hierarchiczną i składa się z trzech podstawowych elementów:

  • PBM management facets – jest to zestaw reguł modelujących zachowanie lub charakterystykę określonego obiektu. Liczba i charakterystyka własności jest wbudowana w każdą regułę i może być zmieniona (dodana, usunięta) tylko przez twórcę reguły. Każda polityka może wykorzystywać jedną lub więcej reguł.
  • PBM conditions – są to warunki określające zestaw dozwolonych stanów, w których może znaleźć się obiekt kontrolowany przez politykę zarządzania serwerem. Dozwolone stany dla każdego obiektu są określane przez omówione powyżej zestawy reguł i charakterystyk ( facets).
  • PBM policies – polityki składają się z warunków, które wymuszają określone zachowanie obiektu. Polityka może zawierać tylko jeden warunek.

 Do początku strony Do początku strony

Polityki zarządzania serwerem w konsoli PowerShell

Po zainstalowaniu SQL Server 2008 dostępny jest host oraz konsola PowerShell, z poziomu której można mieć dostęp do obiektów serwera. Nic nie stoi więc na przeszkodzie, aby programować oraz zarządzać serwerem SQL, o ile tylko użytkownik ma do tego odpowiednie uprawnienia.

W niniejszym artykule przedstawię przykład, w którym pokażę, w jaki sposób wykonać warunek i politykę sprawdzającą, czy funkcjonalności dostępne we wcześniejszych wersjach systemu w narzędziu Surface Area Configuration (SAC) są odpowiednio skonfigurowane (dokładny opis znaczenia każdego z wyżej wymienionych opcji można znaleźć w Books Online):

  • AdHocRemoteQueriesEnabled ustawione na false,
  • ClrIntegrationEnabled ustawione na false,
  • DatabaseMailEnabled ustawione na false,
  • OleAutomationEnabled ustawione na false,
  • RemoteDacEnabled ustawione na false,
  • ServiceBrokerEndpointActive ustawione na false,
  • SoapEndpointsEnabled ustawione na false,
  • SqlMailEnabled ustawione na false,
  • WebAssistantEnabled ustawione na false,
  • XPCmdShellEnabled ustawione na false.

Zapewne wielu użytkowników wie, jak należy wykonać to zadanie z poziomu SSMS, ponieważ to zagadnienie było tematem artykułów na stronach TechNet. Osoby, które zaczynają poznawać nowe funkcje SQL Server 2008 odsyłam do Akademii SQL (publikowanej również na polskich stronach TechNet), w ramach której na jednej z pierwszych lekcji pokazano krok po kroku, jak należy rozpocząć pracę z PBM

 Do początku strony Do początku strony

Wykonanie skryptu tworzącego politykę zarządzania serwerem SQL.

Aby w pełni skorzystać z obiektów SQL Server 2008 oraz znacząco ułatwić sobie wykonanie skryptu należy w konsoli PowerShell załadować odpowiednie biblioteki.

Można to zrobić wybierając jeden z poniższych sposobów:

  • Umieścić referencje do bibliotek w pliku profilu hosta, i ładować biblioteki za każdym razem, kiedy uruchamiany jest host PowerShell,
  • Umieścić referencje do bibliotek w skrypcie, który będzie uruchamiany w ramach tego zadania; z obiektów zawartych w bibliotekach można będzie skorzystać dopiero po załadowaniu skryptu,
  • Załadować biblioteki ręcznie w konsoli PowerShell.

Używając słowa „host PowerShell” mam na myśli „mini” konsolę PowerShell, czyli aplikację sqlps.exe, która zostaje zainstalowana w momencie instalacji SQL Server 2008. Ekran aplikacji pokazano na rys. 1.

Aplikacja sqlps.exe.

Rysunek 1: Aplikacja sqlps.exe.

Można także skorzystać z „systemowego” hosta PowerShell, czyli aplikacji powershell.exe pod warunkiem jednak, że doinstalowany zostanie provider SQL Server (zostało to opisane w [1]). Ekran aplikacji powershell.exe pokazano na rys. 2.

Aplikacja powershell.exe.

Rysunek 2: Aplikacja powershell.exe.

Komendy ładujące biblioteki mają postać:

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.ConnectionInfo")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.SmoEnum")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Dmf")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Management.Sdk.Sfc")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.PolicyEnum")

Pamiętając architekturę systemu PBM należy postępować według następującego schematu:

  • Utworzyć nowy warunek lub warunki korzystając z listy dostępnych obiektów (ang. facets).
  • Utworzyć politykę zarządzania serwerem bazując na wcześniej wykonanych warunkach.

Nic nie stoi na przeszkodzie, aby raz wykonane warunki użyć w wielu politykach, ponieważ warunki same w sobie nie definują polityki; należy je raczej rozumieć jako brzegowe ograniczenia, których obiekt nie może pokonać jeśli nie chce naruszać polityki.

Poniżej zaprezentowany kod ma za zadanie przygotować zmienne, które będą wykorzystywane w trakcie przykładu:

#zmienna pcName przechowa nazwę komputera.

$pcName = get-item env:\computername



#ścieżka do servera

$serverPath = ('SQLSERVER:\SQL\' + $pcName.Value + '\default')

$serverName = get-item $serverpath



# ścieżka do obiektu polityk zarządzania serwerem

$policiesPath = ('SQLSERVER:\SQLPOLICY\' + $pcName.Value + '\default')

$policies = get-item $policiesPath



#nazwa biblioteki 

$PBM = 'Microsoft.SqlServer.Management.Dmf.'

Pierwsza zmienna - $pcName przechowuje informację o nazwie komputera, na którym wykonywany jest skrypt. Nazwa ta jest pobierana ze zmiennych środowiskowych systemu operacyjnego, których pełna lista jest dostępna po wykonaniu poleceń:

get-PSDrive

Cd env:

DIR

Druga i trzecia zmienna przechowują ścieżki do obiektu serwera i obiektów polityk dla instancji domyślnej.

Czwarta zmienna - $PBM przechowuje stałą tekstową stanowiącą, która umożliwi tworzenie pozostałych obiektów, takich jak warunki czy polityki.

Utwórzmy zatem nowy warunek. W tym celu należy stworzyć obiekt klasy Microsoft.SqlServer.Management.Dmf.Condition, nadać mu unikalną nazwę oraz wskazać, jakiego obiektu (ang. facet) będzie on dotyczył:

$cond = new-object ($PBM + 'Condition') $policies, "SAC 2005 Config"

$cond.Facet = "ISurfaceAreaFacet"

Póki co wykonaliśmy jedynie definicję warunku. Można sprawdzić, że nie zawiera ona jeszcze żadnych zdefiniowanych własności:

Definicja warunku SAC 2005 Config.

Rysunek 3: Definicja warunku SAC 2005 Config.

Wstawmy w utworzoną powyżej definicję informacje obiektu SurfaceAreaFacet , które muszą zostać sprawdzone. Zanim do tego przejdziemy należy zdefiniować kilka stałych, które uproszczą tworzenie warunków:

$war_AND = [Microsoft.SqlServer.Management.Dmf.OperatorType]::AND

$war_ROWNE = [Microsoft.SqlServer.Management.Dmf.OperatorType]::EQ

$wyl_FALSE = [Microsoft.SqlServer.Management.Dmf.ExpressionNodeFunction+Function]::False

$O_FALSE = new-object ($PBM + 'ExpressionNodeFunction') $wyl_FALSE

Pierwsza stała- $war_AND pozwoli łączyć ze sobą elementy warunku tak, że jeśli jeden z tych elementów nie będzie spełniony, to cała polityka zostanie naruszona (w analogiczny sposób można utworzyć zmienną, która wykona operację OR).

Stała $war_ROWNE pozwoli wykonać operację porównywania wartości, którą posiada sprawdzana własność sprawdzanego obiektu do innej wartości. W naszym przypadku będziemy porównywać z wartością false, która jest reprezentowana przez obiekt $O_FALSE

Zdefiniujmy zatem te własności obiektu SurfaceAreaConfiguration, które zostaną sprawdzone w polityce:

$wl_AdHoc = new-object ($PBM + 'ExpressionNodeAttribute')  "AdHocRemoteQueriesEnabled"

$wl_CLR = new-object ($PBM + 'ExpressionNodeAttribute')  "ClrIntegrationEnabled"

$wl_DbMail = new-object ($PBM + 'ExpressionNodeAttribute')  "DatabaseMailEnabled"

$wl_OLE = new-object ($PBM + 'ExpressionNodeAttribute')  "OleAutomationEnabled"

$wl_DAC = new-object ($PBM + 'ExpressionNodeAttribute')  "RemoteDacEnabled"

$wl_Broker = new-object ($PBM + 'ExpressionNodeAttribute')  "ServiceBrokerEndpointActive"

$wl_SOAP = new-object ($PBM + 'ExpressionNodeAttribute')  "SoapEndpointsEnabled"

$wl_SqlMail = new-object ($PBM + 'ExpressionNodeAttribute')  "SqlMailEnabled"

$wl_Web = new-object ($PBM + 'ExpressionNodeAttribute')  "WebAssistantEnabled"

$wl_cmd = new-object ($PBM + 'ExpressionNodeAttribute')  "XPCmdShellEnabled"

Mając zdefiniowane własności obiektu, możemy dla każdej z nich wypełnić definicje warunku. Polega to na zbudowaniu kolejnego obiektu, w którym wskazujemy sposób sprawdzania wartości dla danej własności.

W naszym przypadku każda wartość własności obiektu SurfaceAreaConfiguration ma być przyrównana do wartości false:

$o_AdHoc = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_AdHoc, $O_FALSE

$o_CLR = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_CLR, $O_FALSE

$o_DbMail = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_DbMail, $O_FALSE

$o_OLE = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_OLE, $O_FALSE

$o_DAC = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_DAC, $O_FALSE

$o_Broker = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_Broker, $O_FALSE

$o_SOAP = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_SOAP, $O_FALSE

$o_SqlMail = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_SqlMail, $O_FALSE

$o_Web = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_Web, $O_FALSE

$o_cmd = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_cmd, $O_FALSE

Nadeszła pora, aby powiązać utworzone obiekty relacjami, które pomiędzy nimi występują. W przypadku , który omawianym w tym artykule, wszystkie własności obiektu SurfaceAreaConfiguration połączone są relacją AND , to znaczy wszystkie własności muszą być spełnione, aby nie została naruszona polityka:

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_AdHoc , $o_CLR

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_DbMail 

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_OLE

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_DAC

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie , $o_Broker

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_SOAP

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_SqlMail 

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_Web

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_cmd

Można zauważyć, że wykorzystałem jeden obiekt $o_wszystkie do skonstruowania relacji pomiędzy wcześniej wykonanymi obiektami. Z drugiej strony w każdym przypisaniu relacji można tworzyć nowy obiekt i podawać go jako jeden z parametrów do kolejnego obiektu.

Obiekt $o_wszystkie jest obiektem klasy Microsoft.SqlServer.Management.Dmf.ExpressionOperatorNode, a jego zadaniem jest utworzenie wyrażenia w postaci:

Left OpType Right

Lewa część wyrażenia (Left) zostanie połączona z prawą częścią (Right) za pomocą operatora OpType. Analizując ten zapis można stwierdzic, że w ten sposób można skonstruować znacznie bardziej logicznie skomplikowany warunek, niż użyty w naszym przykładzie, w którym wszystkie wyrażenia łączone są operatorem AND.

Na rysunku 4 pokazałem zawartość obiektu $o_wszystkie po wykonaniu komend opisanych na wcześniejszych fragmentach kodu:

Obiekt $o_wszystkie.

Rysunek 4: Obiekt $o_wszystkie.

Definiowanie warunku można uznać za zakończone i jedynym krokiem, który pozostał do wykonania, to jego formalne zatwierdzenie przy użyciu komendy Create(). Dodatkowo, należy przypisać do własności ExpressionNode obiektu Condition obiekt $o_wszystkie:

$cond.ExpressionNode = $o_wszystkie

$cond.Create()

Po wykonaniu opisanych powyżej komend można przekonać się, że warunek został utworzony i jest możliwe jego wykorzystanie przy tworzeniu polityk zarządzania serwerem (rysunek 5).

Lista warunków widziana z poziomu konsoli PowerShell.

Rysunek 5: Lista warunków widziana z poziomu konsoli PowerShell.

Warunek można także odnaleźć w Eksploratorze Obiektów w konsoli SSMS W tym celu należy rozwinąć folder Management i przejść do węzła Conditions, jak pokazano na rysunku 6:

Widok Eksploratora Obiektów z utworzonym warunkiem.

Rysunek 6: Widok Eksploratora Obiektów z utworzonym warunkiem.

Mając utworzony warunek można przystąpić do zbudowania polityki zarządzania serwerem. Nie jest to zadanie trudne i w najprostszym przypadku polega na wykonaniu poniżej opisanych kroków:

  1. Zbudowaniu obiektu klasy Microsoft.SqlServer.Management.Dmf.Policy podając ścieżkę do elementu Policies oraz nazwę nowego obiektu (polityki)

  2. Zapisaniu w własności Condition nazwy warunku, na bazie którego zostanie wykonana polityka

  3. Określeniu sposobu uruchomienia polityki, mając do wyboru jeden z czterech trybów:

    1. CheckOnChanges, który uaktywnia sprawdzanie polityki w sytuacji dokonywania zmian w obiekcie, którego ta polityka dotyczy. Rozwiązane jest to przy pomocy mechanizmu Event Notification,
    2. CheckOnSchedule, w którym zostaje utworzone zadanie usługi Agent, które uruchamiane jest zgodnie z podanym interwałem,
    3. Enforce, która działa w ten sam sposób, co opisany wcześniej tryb CheckOnChanges, ale zapobiega zatwierdzeniu zmian, jeśli naruszają politykę,
    4. None, w którym polityka nie jest sprawdzana.

  4. Ustawieniu własności Enabled polityki na jedną z wartości: True lub False. Domyślna wartość własności Enabled to False co oznacza, że polityka nie będzie uruchomiona nawet jeśli jej tryb jest inny niż None.

  5. Wywołaniu metody Create() na obiekcie klasy Microsoft.SqlServer.Management.Dmf.Policy.

Poniższy kod demonstruje opisane powyżej kroki:

#zmienna wyliczeniowa przechowująca informacje o sposobie uwuchamiania polityki

$pol_exec = [Microsoft.SqlServer.Management.Dmf.AutomatedPolicyEvaluationMode]::None



$policyObject = new-object ($PBM + 'Policy') $policies, "SAC 2005 Policy"

$policyObject.Condition =  "SAC 2005 Config"

$policyObject.AutomatedPolicyEvaluationMode = $pol_exec

$policyObject.Enabled = $false

$policyObject.Create()

Krótkie sprawdzenie przy użyciu konsoli PowerShell pozwala upewnić się, że polityka została pomyślnie utworzona i może zostać użyta zgodnie z przypisanymi jej własnościami (rys. 7):

Lista polityk zarządzania serwerem widziana z poziomu konsoli PowerShell.

Rysunek 7: Lista polityk zarządzania serwerem widziana z poziomu konsoli PowerShell.

 Do początku strony Do początku strony

Narzędzie wspomagające tworzenie skryptów PowerShell

Skrypty PowerShell można pisać na wiele sposobów i używając wielu dostępnych narzędzi. Ze zrozumiałych względów najbardziej zainteresowany byłem użyciem narzędzi darmowych. Można do nich zaliczyć dostępną w systemie operacyjnym Windows aplikację Notepad, która jednak w tym przypadku nie jest wygodnym w użyciu edytorem.

Dużo łatwiejsze staje się tworzenie skryptów PowerShell przy użyciu programu PowerGUI firmy Quest, który posiada wiele ulepszeń istotnych dla każdego programisty:

  • Wbudowany debugger,
  • Wbudowany mechanizm IntelliSense,
  • Sprawdzanie poprawności wpisywanego kodu

Nie są to oczywiście wszystkie zalety wspomnianej aplikacji, ale te ułatwiają kodowanie od samego początku. Przykładowy ekran aplikacji pokazałem na rys. 8.

Ekran aplikacji PowerGUI

Rysunek 8: Ekran aplikacji PowerGUI

 Do początku strony Do początku strony

Podsumowanie

W artykule zaprezentowałem niektóre aspekty praktycznego zastosowania języka PowerShell do zarządzania i programowania SQL Server.

Zawarte fragmenty kodu były łatwe i niezbyt długie, ale to w zupełności powinno wystarczyć, aby przekonać o możliwościach, które oferuje PowerShell.

Nie są to oczywiście jedyne możliwości tego języka. Mając na uwadze przyszłość, jaka otwiera się przed PowerShell należy poważnie zastanowić się nie tylko nad przyswojeniem sobie reguł, które tym językiem rządzą, ale również nauczyć się używać go na co dzień.

 Do początku strony Do początku strony

Literatura

[1] Medrala, Potasiński, Szeliga, Widera: „Serwer 2008. Administracja i programowanie”, wyd. Helion

 Do początku strony Do początku strony

Załącznik

W załączniku znajduje się kompletny skrypt, który posłużył do wykonania opisanego w artykule przykładu:

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.ConnectionInfo")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.SmoEnum")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Dmf")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Management.Sdk.Sfc")

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.PolicyEnum")



#zmienna pcName przechowa nazwe komputera.

$pcName = get-item env:\computername



#sciezka do servera

$serverPath = ('SQLSERVER:\SQL\' + $pcName.Value + '\default')

$serverName = get-item $serverpath



# sciezka do obiektu polityk zarzadzania serwerem

$policiesPath = ('SQLSERVER:\SQLPOLICY\' + $pcName.Value + '\default')

$policies = get-item $policiesPath



#nazwa biblioteki 

$PBM = 'Microsoft.SqlServer.Management.Dmf.'



$cond = new-object ($PBM + 'Condition') $policies, "SAC 2005 Config"

$cond.Facet = "ISurfaceAreaFacet" 



$war_AND = [Microsoft.SqlServer.Management.Dmf.OperatorType]::AND

$war_ROWNE = [Microsoft.SqlServer.Management.Dmf.OperatorType]::EQ

$wyl_FALSE = [Microsoft.SqlServer.Management.Dmf.ExpressionNodeFunction+Function]::False

$O_FALSE = new-object ($PBM + 'ExpressionNodeFunction') $wyl_FALSE



$wl_AdHoc = new-object ($PBM + 'ExpressionNodeAttribute')  "AdHocRemoteQueriesEnabled"

$wl_CLR = new-object ($PBM + 'ExpressionNodeAttribute')  "ClrIntegrationEnabled"

$wl_DbMail = new-object ($PBM + 'ExpressionNodeAttribute')  "DatabaseMailEnabled"

$wl_OLE = new-object ($PBM + 'ExpressionNodeAttribute')  "OleAutomationEnabled"

$wl_DAC = new-object ($PBM + 'ExpressionNodeAttribute')  "RemoteDacEnabled"

$wl_Broker = new-object ($PBM + 'ExpressionNodeAttribute')  "ServiceBrokerEndpointActive"

$wl_SOAP = new-object ($PBM + 'ExpressionNodeAttribute')  "SoapEndpointsEnabled"

$wl_SqlMail = new-object ($PBM + 'ExpressionNodeAttribute')  "SqlMailEnabled"

$wl_Web = new-object ($PBM + 'ExpressionNodeAttribute')  "WebAssistantEnabled"

$wl_cmd = new-object ($PBM + 'ExpressionNodeAttribute')  "XPCmdShellEnabled"



$o_AdHoc = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_AdHoc, $O_FALSE

$o_CLR = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_CLR, $O_FALSE

$o_DbMail = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_DbMail, $O_FALSE

$o_OLE = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_OLE, $O_FALSE

$o_DAC = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_DAC, $O_FALSE

$o_Broker = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_Broker, $O_FALSE

$o_SOAP = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_SOAP, $O_FALSE

$o_SqlMail = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_SqlMail, $O_FALSE

$o_Web = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_Web, $O_FALSE

$o_cmd = new-object ($PBM + 'ExpressionNodeOperator') $war_ROWNE, $wl_cmd, $O_FALSE



$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_AdHoc , $o_CLR

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_DbMail 

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_OLE

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_DAC

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie , $o_Broker

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_SOAP

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_SqlMail 

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_Web

$o_wszystkie = new-object ($PBM + 'ExpressionNodeOperator') $war_AND , $o_wszystkie ,$o_cmd



$cond.ExpressionNode = $o_wszystkie

$cond.Create()





$pol_exec = [Microsoft.SqlServer.Management.Dmf.AutomatedPolicyEvaluationMode]::None



$policyObject = new-object ($PBM + 'Policy') $policies, "SAC 2005 Policy"

$policyObject.Condition =  "SAC 2005 Config"

$policyObject.AutomatedPolicyEvaluationMode = $pol_exec

$policyObject.Enabled = $false

$policyObject.Create()
Damian Widera Damian Widera, Project Manager & Team Lead (MCT, MCITP – DBA, MCSD.NET)
Od 8 lat zajmuje się projektowaniem, tworzeniem i wdrażaniem aplikacji wykorzystujących platformę .NET, SQL Server oraz Oracle. Obecnie pracuje jako project manager dla LGBS Polska. Pracował także jako trener, programista, administrator baz danych, twórca domumentacji oraz analityk biznesowy. Aktywnie współpracuje z polskim oddziałem Microsoft publikując atykuły, webcasty oraz porady z zakresu SQL Server na stronach TechNet. Jest współautorem książki „Serwer SQL 2008. Administracja i programowanie”.

Speaker na wielu konferencjach, m.in. Microsoft Heroes Happen Here, C2C, European PASS Conference, Microsoft Technology Summit, Energy Launch, TechED. Od 2004 r. posiada certyfikaty firmy Microsoft: MCT, MCITP–DBA oraz MCSD.NET. Jest współtwórcą oraz liderem jednej z najwiekszych grup pasjonatów SQL Server w Polsce – Śląskiej Regionalnej Grupy Microsoft (PLSSUG Katowice). Od listopada 2008 jest prezesem Polish SQL Server Users Group (PLSSUG) w Polsce. W styczniu 2009 nagrodzony tytułem MVP w kategorii SQL Server.

 

 Do początku strony Do początku strony

Microsoft SQL Server