🥇PowerShell Desired State Configuration și șmirghelul: partea 1. Configurarea serverului DSC Pull pentru a lucra cu baza de date SQL

PowerShell Desired State Configuration (DSC) simplifică semnificativ procesul de implementare și configurare a sistemului de operare, rolurilor serverului și aplicațiilor, atunci când aveți sute de servere.

Dar, în utilizarea DSC on-premises, adică nu în MS Azure, apar câteva aspecte. Acestea sunt deosebit de vizibile dacă organizația este mare (de la 300 de stații de lucru și servere) și nu a deschis încă lumea containerelor:

Lipsesc rapoartele complete de stare a sistemelor. Dacă configurația necesară nu a fost aplicată pe unele servere, fără aceste rapoarte nu vom afla acest lucru. Informațiile obținute de la serverul de raportare integrat sunt destul de greu de obținut, iar pentru un număr mare de gazde – de asemenea, durează mult.
Lipsa scalabilității și a redundanței. Nu este posibil să construiți o fermă de servere web DSC care să aibă o bază de date redundantă unică și un depozit comun de fișiere mof de configurații, module și chei de registru.

Astăzi vă voi povesti despre cum să rezolvați prima problemă și să obțineți date pentru a construi rapoarte. Totul ar fi mai simplu dacă ca bază de date s-ar putea folosi SQL. MS promite suport încorporat doar în Windows Server 2019 sau în build-ul Windows Server 1803. Obținerea datelor folosind OleDB provider nici nu va funcționa, deoarece serverul DSC folosește un parametru denumit, care nu este pe deplin suportat de OleDbCommand.

Am găsit această metodă: pentru cei care folosesc Windows Server 2012 și 2016, este posibilă pagina de start și motorul de căutare. utilizarea bazei de date SQL ca backend pentru serverul DSC interogator. Pentru aceasta, vom crea un „proxy” sub forma unui fișier .mdb cu tabelele legate, care va redirecționa datele obținute din rapoartele clienților către baza de date a serverului SQL.

Notă: pentru Windows Server 2016 este necesară utilizarea AccessDatabaseEngine2016x86, deoarece Microsoft.Jet.OLEDB.4.0 nu mai este suportat.

Nu voi detalia procesul de implementare a serverului DSC interogator, acesta este descris foarte bine aici. Voi sublinia doar câteva puncte. Dacă desfășurăm serverul DSC interogator pe același server web cu WSUS sau Kaspersky Security Center, atunci în scriptul de creare a configurației trebuie să schimbăm următoarele parametrii:

```
UseSecurityBestPractices     = $false
```
Altfel, TLS 1.0 va fi dezactivat, nu veți putea să vă conectați la baza de date SQL. Kaspersky Security Center, de asemenea, nu va funcționa (problema ar trebui rezolvată în Kaspersky Security Center v11).
```
Enable32BitAppOnWin64   = $true
```
Dacă nu se face această modificare, nu va fi posibil să pornim AppPool-ul serverului DSC pe IIS cu WSUS.
Atunci când instalați serverul DSC împreună cu WSUS, dezactivați cache-ul static și dinamic pentru site-ul DSC.

Să trecem la configurarea serverului DSC pentru a folosi baza de date SQL.

Crearea bazei de date SQL

Vom crea o bază de date SQL goală numită DSC.
Vom crea un cont pentru conectarea la această bază de date. Verificați mai întâi că pe serverul SQL este permisă autentificarea atât cu conturi Windows, cât și SQL.
Navigăm la secțiunea User Mapping. Alegem baza de date, în acest caz – DSC. Acordăm permisiunile de proprietar pentru baza de date.
Gata.

Crearea schemei pentru baza de date DSC

Crearea schemei pentru baza de date DSC se poate face în două moduri:

autonom, printr-un script 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

importați datele din baza de date goală devices.mdb ca parte a modulului PS PSDesiredStateConfiguration prin Utilitarul de importare a datelor SQL.
Devices.mdb, cu care vom lucra, se află în C:WindowsSysWOW64WindowsPowerShellv1.0ModulesPSDesiredStateConfigurationPullServer.

Pentru a importa datele, lansăm Utilitarul de importare și exportare SQL Server.
Alegem de unde vom prelua datele – în cazul nostru, aceasta este baza de date Microsoft Access. Apăsăm Next.
Alegem fișierul din care importăm schema.
Specificăm unde importăm, – aceasta este baza de date SQL.
Alegem serverul SQL (Server Name) și baza de date în care vom importa datele (DataBase).
Alegem opțiunea Copy data from one or more tables or views (copierea datelor din tabele sau vederi).
Alegem tabelele din care vom importa schema bazei de date.
Bifăm caseta Run Immediately și apăsăm Finish.
Gata.
Ca urmare, în baza de date DSC ar trebui să apară tabelele.

Configurarea fișierului .mdb "prădător"

Crearea unei conexiuni ODBC la serverul SQL. Se presupune că MS Access nu este instalat pe serverul cu DSC, așadar configurarea databases.mdb se face pe un host intermediar cu MS Access instalat.

Vom crea o conexiune ODBC sistematică la serverul SQL (arhitectura conexiunii trebuie să corespundă cu arhitectura MS Access – 64 sau 32). Aceasta poate fi creată cu ajutorul:
— cmdlet-ului Powershell:

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

— sau manual, cu ajutorul asistentului de conexiuni:

Deschidem Administrative tools. Alegem sursele de date ODBC în funcție de versiunea MS Access instalată. Mergem la tab-ul System DSN și creăm o conexiune sistematică (Add).
Specificați că ne vom conecta la serverul SQL. Apăsăm Finish.
Specificați numele și serverul pentru conexiune. Apoi, conexiunea cu aceleași setări trebuie creată pe serverul DSC.
Specificați că pentru conectarea la serverul SQL se folosește login-ul creat anterior numit DSC.
Specificați baza de date în setările de conexiune DSC.
Apăsăm Finish.
Înainte de finalizarea setărilor, verificăm că conexiunea funcționează (Test Data Source).
Gata.

Crearea bazei de date devices.mdb în MS Access. Lansați MS Access și creați o bază de date goală numită devices.mdb.

Mergem la tab-ul External Data, facem clic pe ODBC Database. În fereastra care apare, alegem Create Linked Table pentru a ne conecta la sursa de date.
În fereastra nouă, selectăm tab-ul Machine Data Source și apăsăm OK. În fereastra nouă, introducem datele de autentificare pentru a ne conecta la serverul SQL.
Selectăm tabelele care trebuie legate. Bifăm opțiunea Save Password și apăsăm OK. Parola trebuie salvată de fiecare dată pentru toate cele trei tabele.
În indecși trebuie să alegem următoarele:
— TargetName pentru tabela dbo_Devices;

— NodeName sau IPAddress pentru dbo_RegistrationData;

— NodeName sau IPAddress pentru dbo_StatusReport.
Vom redenumi tabelele în MS Access, adică vom elimina prefixul dbo_ pentru ca DSC să le poată folosi.
Gata.
Salvăm fișierul și închidem MS Access. Acum copiem devices.mdb obținut pe serverul DSC (de obicei în C:Program FilesWindowsPowershellDSCService) și îl vom înlocui pe cel existent (dacă există).

Configurarea serverului DSC pentru utilizarea SQL.

Revenim la serverul DSC. Pentru a ne conecta la serverul SQL cu fișierul nostru proxy, vom crea o nouă conexiune ODBC pe serverul DSC. Numele, arhitectura și setările de conectare trebuie să fie identice cu cele utilizate la crearea fișierului MDB. Putem copia fișierul devices.mdb gol deja configurat de aici.
Pentru a utiliza devices.mdb, trebuie să facem modificări în web.config al serverului DSC (implicit – C:inetpubPSDSCPullServerweb.config):

— pentru Windows Server 2012

\n

— pentru Windows Server 2016

\n

Aceasta este configurația serverului DSC finalizată.

Verificarea funcționalității serverului DSC

Vom verifica dacă serverul DSC este accesibil prin browser web.
Acum vom verifica dacă serverul DSC funcționează corect. În cadrul modulului xPSDesiredStateConfiguration există un script pullserversetuptests.ps1. Înainte de a rula acest script, este necesar să instalăm modulul PowerShell numit Pester. Îl instalăm cu comanda Install-Module -Name Pester.
Deschidem C:Program FilesWindowsPowerShellModulesxPSDesiredStateConfigurationDSCPullServerSetupPullServerDeploymentVerificationTest (în exemplu, versiunea 8.0.0.0.0).
Deschidem PullServerSetupTests.ps1 și verificăm calea către web.config al serverului DSC. Am evidențiat în roșu calea către web.config, care va fi verificată de script. Dacă este necesar, modificăm această cale.
Rulăm pullserversetuptests.ps1
Invoke-Pester .PullServerSetupTests.ps1
Totul funcționează.
În SQL Management Studio vedem că gazdele administrate trimit rapoarte către serverul de rapoarte DSC și datele sunt salvate în baza de date DSC pe serverul SQL.

Asta este tot. În articolele următoare, intenționez să explic cum să generăm rapoarte pe baza datelor obținute și să discut despre probleme legate de redundanță și scalabilitate.

Sursa: habr.com