🥇PowerShell Desired State Configuration i pilnik: część 1. Konfiguracja DSC Pull Server do pracy z bazą danych SQL

PowerShell Desired State Configuration (DSC) znacznie upraszcza proces wdrażania i konfigurowania systemu operacyjnego, ról serwera i aplikacji, gdy mamy setki serwerów.

Jednak korzystając z DSC on-premises, tzn. nie w MS Azure, pojawia się kilka niuansów. Są one szczególnie odczuwalne, jeśli organizacja jest duża (ponad 300 stacji roboczych i serwerów) i nie wprowadziła jeszcze świata kontenerów:

Brakuje pełnych raportów o stanie systemów. Jeśli potrzebna konfiguracja nie została zastosowana na jakichś serwerach, to bez tych raportów nic o tym nie dowiemy się. Uzyskanie informacji z wbudowanego serwera raportów jest dość trudne, a dla dużej liczby hostów – jeszcze dłuższe.
Brak skalowalności i niezawodności. Niemożliwe jest zbudowanie farmy serwerów webowych DSC, które miałyby jedną, niezawodną bazę danych oraz wspólne repozytorium plików mof z konfiguracjami, modułami i kluczami rejestracyjnymi.

Dziś opowiem, jak można rozwiązać pierwszy problem i uzyskać dane do budowy raportów. Wszystko byłoby prostsze, gdyby można było użyć SQL jako bazy danych. MS obiecuje wbudowane wsparcie tylko w Windows Server 2019 lub w wersji Windows Server 1803. Pozyskanie danych z użyciem dostawcy OleDB także nie będzie możliwe, ponieważ serwer DSC wykorzystuje nazwany parametr, który nie jest w pełni wspierany przez OleDbCommand.

Znalazłem taki sposób: ci, którzy używają Windows Server 2012 i 2016, mogą być skonfigurowana używać bazy danych SQL jako zaplecza dla serwera DSC. W tym celu stworzymy 'proxy' w postaci pliku .mdb ze skojarzonymi tabelami, które będą przekierowywały dane uzyskane z raportów klientów do bazy danych SQL serwera.

Uwaga: dla Windows Server 2016 należy używać AccessDatabaseEngine2016x86, ponieważ Microsoft.Jet.OLEDB.4.0 nie jest już wspierany.

Nie będę szczegółowo omawiać procesu wdrażania serwera DSC, jest on bardzo dobrze opisany tutaj. Zaznaczę tylko kilka punktów. Jeśli wdrażamy serwer DSC na tym samym serwerze webowym co WSUS lub Kaspersky Security Center, to w skrypcie tworzenia konfiguracji należy zmienić następujące parametry:

```
UseSecurityBestPractices     = $false
```
W przeciwnym razie TLS 1.0 zostanie wyłączony, nie będziesz mógł połączyć się z bazą danych SQL. Kaspersky Security Center również nie będzie działać (problem powinien być rozwiązany w Kaspersky Security Center v11).
```
Enable32BitAppOnWin64   = $true
```
Jeśli nie dokonasz tej zmiany, nie będzie możliwe uruchomienie AppPool serwera DSC na IIS z WSUS.
Podczas instalacji serwera DSC razem z WSUS wyłącz statyczne i dynamiczne buforowanie dla witryny DSC.

Przejdźmy do konfiguracji serwera DSC do używania bazy danych SQL.

Tworzenie bazy danych SQL

Utwórzmy pustą bazę danych SQL o nazwie DSC.
Utwórzmy konto do połączenia z tą bazą danych. Najpierw sprawdź, czy na serwerze SQL włączona jest autoryzacja zarówno kont Windows, jak i SQL.
Przechodzimy do sekcji User Mapping. Wybieramy bazę danych, w tym przypadku – DSC. Przyznajemy uprawnienia właściciela bazy danych.
Gotowe.

Tworzenie schematu dla bazy danych DSC

Schemat dla bazy danych DSC można utworzyć na dwa sposoby:

samodzielnie, za pomocą skryptu TSQL

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Devices](
[TargetName] [nvarchar](255) NOT NULL,
[ConfigurationID] [nvarchar](255) NOT NULL,
[ServerCheckSum] [nvarchar](255) NOT NULL,
[TargetCheckSum] [nvarchar](255) NOT NULL,
[NodeCompliant] [bit] NOT NULL,
[LastComplianceTime] [datetime] NULL,
[LastHeartbeatTime] [datetime] NULL,
[Dirty] [bit] NOT NULL,
[StatusCode] [int] NULL
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[RegistrationData](
[AgentId] [nvarchar](255) NOT NULL,
[LCMVersion] [nvarchar](255) NULL,
[NodeName] [nvarchar](255) NULL,
[IPAddress] [nvarchar](255) NULL,
[ConfigurationNames] [nvarchar](max) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[StatusReport](
[JobId] [nvarchar](50) NOT NULL,
[Id] [nvarchar](50) NOT NULL,
[OperationType] [nvarchar](255) NULL,
[RefreshMode] [nvarchar](255) NULL,
[Status] [nvarchar](255) NULL,
[LCMVersion] [nvarchar](50) NULL,
[ReportFormatVersion] [nvarchar](255) NULL,
[ConfigurationVersion] [nvarchar](255) NULL,
[NodeName] [nvarchar](255) NULL,
[IPAddress] [nvarchar](255) NULL,
[StartTime] [datetime] NULL,
[EndTime] [datetime] NULL,
[Errors] [nvarchar](max) NULL,
[StatusData] [nvarchar](max) NULL,
[RebootRequested] [nvarchar](255) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

importuj dane z pustego devices.mdb jako składnik modułu PSDesiredStateConfiguration za pomocą Kreatora importu danych SQL.
Devices.mdb, z którym będziemy pracować, znajduje się w C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\PullServer.

Aby zaimportować dane, uruchamiamy SQL Server Import and Export Wizard.
Wybieramy, skąd będziemy pobierać dane – w naszym przypadku jest to baza danych Microsoft Access. Klikamy Dalej.
Wybieramy plik, z którego importujemy schemat.
Wskazujemy, dokąd importujemy – w naszym przypadku to baza danych SQL.
Wybieramy serwer SQL (Nazwa serwera) i bazę danych, do której będziemy importować dane (Baza danych).
Wybieramy opcję Kopiuj dane z jednej lub więcej tabel lub widoków.
Wybieramy tabele, z których będziemy importować schemat bazy danych.
Zaznaczamy opcję Uruchom natychmiast i klikamy Zakończ.
Gotowe.
W rezultacie w bazie danych DSC powinny pojawić się tabele.

Konfiguracja pliku .mdb jako pliku „proxy”

Tworzenie połączenia ODBC z serwerem SQL. Zakłada się, że MS Access nie jest zainstalowany na serwerze DSC, dlatego konfiguracja databases.mdb odbywa się na pośrednim hoście z zainstalowanym MS Access.

Utworzymy systemowe połączenie ODBC z serwerem SQL (architektura połączenia musi odpowiadać architekturze MS Access – 64 lub 32). Można je stworzyć za pomocą:
— polecenia Powershell:

Add-OdbcDsn –Name DSC –DriverName 'SQL Server' –Platform '' –DsnType System –SetPropertyValue @('Description=Serwer Pull DSC',"Server=",'Trusted_Connection=yes','Database=DSC') –PassThru

— lub ręcznie, za pomocą kreatora połączeń:

Otwieramy Narzędzia administracyjne. Wybieramy źródła danych ODBC w zależności od wersji zainstalowanego MS Access. Przechodzimy do zakładki System DSN i tworzymy połączenie systemowe (Dodaj).
Określamy, że będziemy łączyć się z serwerem SQL. Klikamy Zakończ.
Podajemy nazwę i serwer do połączenia. Następnie połączenie z takimi samymi parametrami należy stworzyć na serwerze DSC.
Określamy, że do połączenia z serwerem SQL używamy wcześniej utworzonego przez nas loginu o nazwie DSC.
Podajemy bazę danych w ustawieniach połączenia DSC.
Klikamy Zakończ.
Przed zakończeniem konfiguracji sprawdzamy, czy połączenie działa (Test Data Source).
Gotowe.

Tworzenie bazy danych devices.mdb w MS Access. Uruchamiamy MS Access i tworzymy pustą bazę danych o nazwie devices.mdb.

Przechodzimy do zakładki Zewnętrzne dane, klikamy na Baza danych ODBC. W nowo otwartym oknie wybieramy Utwórz tabelę powiązaną, aby połączyć się z źródłem danych.
W nowym oknie wybieramy zakładkę Machine Data Source i klikamy OK. W nowym oknie wprowadzamy dane logowania do połączenia z serwerem SQL.
Wybieramy tabele, które należy powiązać. Zaznaczamy opcję Zapamiętaj hasło i klikamy OK. Hasło należy zapamiętać za każdym razem dla wszystkich trzech tabel.
W indeksach należy wybrać następujące:
— TargetName dla tabeli dbo_Devices;

— NodeName lub IPAddress dla dbo_RegistrationData;

— NodeName lub IPAddress dla dbo_StatusReport.
Zmieniamy nazwy tabel w MS Access, a mianowicie: usuwamy prefiks dbo_, aby DSC mogło je wykorzystać.
Gotowe.
Zapisujemy plik i zamykamy MS Access. Następnie kopiujemy uzyskany devices.mdb na serwer DSC (domyślnie w C:Program FilesWindowsPowershellDSCService) i zastępujemy nim istniejący (o ile istnieje).

Konfiguracja serwera DSC do używania SQL

Wracamy do serwera DSC. Aby połączyć się z serwerem SQL za pomocą naszego pliku proxy, stworzymy nowe połączenie ODBC na serwerze DSC. Nazwa, architektura i ustawienia połączenia muszą być takie same, jak podczas tworzenia pliku MDB. Można skopiować już skonfigurowany pusty plik devices.mdb stąd.
Aby korzystać z pliku devices.mdb, należy wprowadzić zmiany w pliku web.config serwera DSC (domyślnie – C:inetpubPSDSCPullServerweb.config):

— dla Windows Server 2012

— dla Windows Server 2016

Na tym kończy się konfiguracja serwera DSC.

Sprawdzanie działania serwera DSC

Sprawdzimy, czy serwer DSC jest dostępny przez przeglądarkę internetową.
Teraz sprawdzimy, czy serwer DSC poprawnie działa. W tym celu w module xPSDesiredStateConfiguration znajduje się skrypt pullserversetuptests.ps1. Przed uruchomieniem tego skryptu należy zainstalować moduł Powershell o nazwie Pester. Instalujemy go za pomocą Install-Module -Name Pester.
Otwieramy C:Program FilesWindowsPowerShellModulesxPSDesiredStateConfigurationDSCPullServerSetupPullServerDeploymentVerificationTest (w przykładzie wersja 8.0.0.0.0).
Otwieramy PullServerSetupTests.ps1 i sprawdzamy ścieżkę do web.config serwera DSC. Na czerwono zaznaczyłem ścieżkę do web.config, którą skrypt będzie sprawdzał. W razie potrzeby zmieniamy tę ścieżkę.
Uruchamiamy pullserversetuptests.ps1
Invoke-Pester .PullServerSetupTests.ps1
Wszystko działa.
W SQL Management Studio widzimy, że zarządzane hosty wysyłają raporty do serwera raportów DSC, a dane trafiają do bazy danych DSC na serwerze SQL.

Na tym kończymy. W kolejnych artykułach planuję opisać, jak na podstawie uzyskanych danych tworzyć raporty oraz poruszę kwestie związane z odpornością na awarie i skalowalnością.

Źródło: habr.com