Konfiguracja żądanego stanu programu PowerShell (DSC) znacznie upraszcza wdrażanie i konfigurowanie systemu operacyjnego, ról serwerów i aplikacji w przypadku setek serwerów.
Ale w przypadku korzystania z DSC lokalnie, tj. nie w MS Azure, jest kilka niuansów. Są one szczególnie zauważalne, jeśli organizacja jest duża (od 300 stacji roboczych i serwerów) i nie odkryła jeszcze świata kontenerów:
- Brak jest pełnych raportów na temat stanu systemów. Jeżeli na niektórych serwerach nie została zastosowana wymagana konfiguracja, to bez tych raportów nie dowiemy się o tym. Uzyskanie informacji z wbudowanego serwera raportowania jest dość trudne, a w przypadku dużej liczby hostów może to również zająć dużo czasu.
- Brakuje skalowalności i odporności na błędy. Niemożliwe jest zbudowanie farmy serwerów WWW typu pull DSC, która miałaby jedną odporną na awarie bazę danych i wspólne miejsce przechowywania plików mof dla konfiguracji, modułów i kluczy rejestracyjnych.
Dziś opowiem Ci jak możesz rozwiązać pierwszy problem i zdobyć dane do raportowania. Wszystko byłoby prostsze, gdyby SQL mógł służyć jako baza danych. SM wbudowana obsługa tylko w Windows Server 2019 lub w kompilacji Windows Server 1803. Pobieraj dane również za pomocą dostawcy OleDB ponieważ serwer DSC używa nazwanego parametru, który nie jest w pełni obsługiwany przez OleDbCommand.
Znalazłem tę metodę: dla tych, którzy korzystają z Windows Server 2012 i 2016, możesz używanie bazy danych SQL jako zaplecza dla serwera zapytań DSC. W tym celu utworzymy „proxy” w postaci pliku .mdb z powiązanymi tabelami, który przekieruje dane otrzymane z raportów klienta do bazy danych serwera SQL.
Uwaga: w przypadku systemu Windows Server 2016 należy użyć ponieważ Microsoft.Jet.OLEDB.4.0 nie jest już obsługiwany.
Nie będę wdawał się w szczegóły procesu wdrażania serwera ściągającego DSC, jest on bardzo dobrze opisany . Zwrócę tylko uwagę na kilka punktów. Jeśli wdrożymy ściągacz DSC na tym samym serwerze internetowym, co WSUS lub Kaspersky Security Center, wówczas w skrypcie tworzenia konfiguracji musimy zmienić następujące parametry:
-
UseSecurityBestPractices = $falseW przeciwnym razie protokół TLS 1.0 zostanie wyłączony i nie będzie można połączyć się z bazą danych SQL. Kaspersky Security Center również nie będzie działać (problem powinien zostać rozwiązany w Kaspersky Security Center v11).
-
Enable32BitAppOnWin64 = $trueJeśli ta zmiana nie zostanie wprowadzona, uruchomienie serwera AppPool DSC w usługach IIS z usługą WSUS nie będzie możliwe.
- Podczas instalowania serwera DSC za pomocą programu WSUS wyłącz statyczne i dynamiczne buforowanie dla witryny DSC.
Przejdźmy do konfiguracji serwera DSC do korzystania z bazy danych SQL.
Tworzenie bazy danych SQL
- Utwórzmy pustą bazę danych SQL o nazwie DSC.
- Utwórzmy konto, aby połączyć się z tą bazą danych. Najpierw sprawdź, czy serwer SQL umożliwia uwierzytelnianie kont Windows i SQL.
- Przejdź do sekcji Mapowanie użytkowników. Wybierz bazę danych, w tym przypadku DSC. Nadajemy uprawnienia właściciela bazy danych.
- Zrobione.
Tworzenie schematu dla bazy danych DSC
Istnieją dwa sposoby tworzenia schematu bazy danych DSC:
- niezależnie, poprzez skrypt 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 pliku devices.mdb w ramach modułu PS PSDesiredStateConfiguration za pomocą Kreatora importu danych SQL.
Plik Devices.mdb, z którym będziemy pracować, znajduje się w C:WindowsSysWOW64WindowsPowerShellv1.0ModulesPSDesiredStateConfigurationPullServer.
- Aby zaimportować dane, uruchom Kreatora importu i eksportu programu SQL Server.
- Wybieramy skąd będziemy pobierać dane – w naszym przypadku jest to baza danych Microsoft Access. Kliknij Następny.
- Wybierz plik, z którego importujemy diagram.
- Wskazujemy gdzie importować – dla nas jest to baza danych SQL.
- Wybierz serwer SQL (Nazwa serwera) i bazę danych, do której będziemy importować dane (DataBase).
- Wybierz opcję Kopiuj dane z jednej lub większej liczby tabel lub widoków (kopiowanie danych z tabel lub widoków).
- Wybieramy tabele, z których zaimportujemy schemat bazy danych.
- Zaznacz pole Uruchom natychmiast i kliknij Zakończ.
- Zrobione.
- W rezultacie tabele powinny pojawić się w bazie danych DSC.
Konfigurowanie pliku „proxy” .mdb
Tworzenie połączenia ODBC z serwerem SQL. Zakłada się, że MS Access nie jest zainstalowany na serwerze z uruchomionym DSC, więc konfiguracja Databases.mdb odbywa się na hoście pośrednim z zainstalowanym MS Access.
Stwórzmy systemowe połączenie ODBC z serwerem SQL (bitowość połączenia musi odpowiadać bitowości MS Access - 64 lub 32). Można go utworzyć za pomocą:
- Polecenie cmdlet PowerShell:
Add-OdbcDsn –Name DSC –DriverName 'SQL Server' –Platform '<64-bit or 32-bit>' –DsnType System –SetPropertyValue @('Description=DSC Pull Server',"Server=<Name of your SQL Server>",'Trusted_Connection=yes','Database=DSC') –PassThru— lub ręcznie, korzystając z kreatora połączeń:
- Otwórz narzędzia administracyjne. Źródła danych ODBC wybieramy w zależności od wersji zainstalowanego MS Access. Przejdź do zakładki Systemowe DSN i utwórz połączenie systemowe (Dodaj).
- Wskazujemy, że połączymy się z serwerem SQL. Kliknij Zakończ.
- Określ nazwę i serwer, z którym chcesz się połączyć. Następnie konieczne będzie utworzenie połączenia o tych samych parametrach na serwerze DSC.
- Wskazujemy, że do połączenia się z serwerem SQL wykorzystujemy utworzony wcześniej login o nazwie DSC.
- Bazę danych określamy w ustawieniach połączenia DSC.
- Kliknij Zakończ.
- Przed zakończeniem konfiguracji sprawdzamy, czy połączenie działa (Test źródła danych).
- Zrobione.
Tworzenie bazy danych devices.mdb w programie MS Access. Uruchom MS Access i utwórz pustą bazę danych o nazwie devices.mdb.
- Przejdź do zakładki Dane zewnętrzne i kliknij Baza danych ODBC. W wyświetlonym oknie wybierz opcję Utwórz tabelę połączoną, aby połączyć się ze źródłem danych.
- W nowym oknie wybierz zakładkę Machine Data Source i kliknij OK. W nowym oknie wprowadź dane uwierzytelniające, aby połączyć się z serwerem SQL.
- Wybierz tabele, które mają zostać połączone. Zaznacz pole Zapisz hasło i kliknij OK. Zapisz hasło za każdym razem dla wszystkich trzech tabel.
- W indeksach musisz wybrać:
— TargetName dla tabeli dbo_Devices;
— Nazwa węzła lub adres IP dla dbo_RegistrationData;
— Nazwa węzła lub adres IP dla dbo_StatusReport. - Zmieńmy nazwy tabel w MS Access, a mianowicie: usuń przedrostek dbo_, aby DSC mógł z nich korzystać.
- Zrobione.
- Zapisz plik i zamknij MS Access. Teraz kopiujemy powstały plik devices.mdb na serwer DSC (domyślnie w C: Program FilesWindowsPowershellDSCService) i zastępujemy nim istniejący (jeśli istnieje).
Konfigurowanie serwera DSC do używania języka SQL
- Wracamy do serwera DSC. Aby połączyć się z serwerem SQL za pomocą naszego pliku proxy, utwórzmy nowe połączenie ODBC na serwerze DSC. Nazwa, głębia bitowa i ustawienia połączenia muszą być takie same, jak przy tworzeniu pliku MDB. Możesz stąd skopiować już skonfigurowany pusty plik devices.mdb.
- Aby użyć pliku devices.mdb, należy wprowadzić zmiany w pliku web.config serwera ściągania DSC (domyślnie jest to C:inetpubPSDSCPullServerweb.config):
- dla systemu Windows Server 2012
<add key="dbprovider" value="System.Data.OleDb">
<add key="dbconnectionstr" value="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:Program FilesWindowsPowerShellDscServiceDevices.mdb;">- dla systemu Windows Server 2016
<add key="dbprovider" value="System.Data.OleDb">
<add key="dbconnectionstr" value="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:Program FilesWindowsPowerShellDscServiceDevices.mdb;">To kończy konfigurację serwera DSC.
Sprawdzenie funkcjonalności serwera DSC
- Sprawdźmy, czy serwer DSC jest dostępny poprzez przeglądarkę internetową.
- Sprawdźmy teraz, czy serwer ściągania DSC działa poprawnie. W tym celu moduł xPSDesiredStateConfiguration zawiera skrypt pullserversetuptests.ps1. Przed uruchomieniem tego skryptu musisz zainstalować moduł Powershell o nazwie Pester. Zainstaluj go. Moduł instalacyjny -Nazwa Pester.
- Otwórz C:Program FilesWindowsPowerShellModulesxPSDesiredStateConfiguration<wersja modułu>DSCPullServerSetupPullServerDeploymentVerificationTest (w przykładzie wersja 8.0.0.0.0).
- Otwórz plik PullServerSetupTests.ps1 i sprawdź ścieżkę do pliku web.config serwera DSC. Ścieżka do pliku web.config, który sprawdzi skrypt, jest podświetlona na czerwono. Jeśli zajdzie taka potrzeba, zmieniamy tę ścieżkę.
- Uruchom pullserversetuptests.ps1
Invoke-Pester.PullServerSetupTests.ps1
Все работает. - W SQL Management Studio widzimy, że administrowane hosty wysyłają raporty do serwera raportowania DSC, a dane trafiają do bazy danych DSC na serwerze SQL.
To wszystko. W kolejnych artykułach planuję opowiedzieć jak na podstawie uzyskanych danych budować raporty, a także poruszę kwestie związane z odpornością na błędy i skalowalnością.
Źródło: www.habr.com