🥇PowerShell Desired State Configuration e limature: parte 1. Configurazione del server DSC Pull per lavorare con un database SQL

PowerShell Desired State Configuration (DSC) semplifica notevolmente il lavoro di distribuzione e configurazione del sistema operativo, dei ruoli del server e delle applicazioni, soprattutto quando si hanno centinaia di server.

Tuttavia, nell'utilizzo di DSC on-premises, ovvero non in MS Azure, si presentano alcune problematiche. Queste diventano particolarmente rilevanti se l'organizzazione è grande (da 300 workstation e server) e non ha ancora aperto il mondo dei container:

Mancanza di report completi sullo stato dei sistemi. Se la configurazione desiderata non è stata applicata su alcuni server, senza questi report non ne verremo a conoscenza. Ottenere informazioni dal server di report integrato è piuttosto complesso, e per un gran numero di host è anche lungo.
Mancanza di scalabilità e tolleranza ai guasti. Non è possibile costruire un'architettura di server web DSC interroganti con un'unica base di dati resistente ai guasti e un'archiviazione comune di file mof di configurazione, moduli e chiavi di registrazione.

Oggi parlerò di come risolvere il primo problema e ottenere dati per costruire reportistica. Tutto sarebbe più semplice se fosse possibile utilizzare SQL come base di dati. MS promette un supporto integrato solo in Windows Server 2019 o nella build di Windows Server 1803. Non è possibile prelevare dati utilizzando il provider OleDB non sarà possibile, poiché il server DSC utilizza un parametro denominato che non è completamente supportato da OleDbCommand.

Ho trovato un modo: per chi utilizza Windows Server 2012 e 2016, è possibile configurare l'uso di un database SQL come backend per il server DSC interrogante. A tal fine, creeremo un 'proxy' sotto forma di file .mdb con tabelle collegate, che reindirizzerà i dati ottenuti dai report dei clienti al database del server SQL.

Nota: per Windows Server 2016 è necessario utilizzare AccessDatabaseEngine2016x86, poiché Microsoft.Jet.OLEDB.4.0 non è più supportato.

Non mi soffermerò sul processo di distribuzione del server DSC interrogante, che è ben descritto qui. Sottolineerò solo un paio di punti. Se distribuiamo il server DSC interrogante su un singolo server web insieme a WSUS o Kaspersky Security Center, è necessario modificare i seguenti parametri nello script di creazione della configurazione:

```
UseSecurityBestPractices = $false
```
Altrimenti TLS 1.0 verrà disabilitato, non sarai in grado di connetterti al database SQL. Anche Kaspersky Security Center non funzionerà (il problema dovrebbe essere risolto in Kaspersky Security Center v11).
```
Enable32BitAppOnWin64   = $true
```
Se non viene apportata questa modifica, non sarà possibile avviare l'AppPool del server DSC su IIS con WSUS.
Durante l'installazione del server DSC insieme a WSUS, disattiva la cache statica e dinamica per il sito DSC.

Passiamo alla configurazione del server DSC per l'uso del database SQL.

Creazione del database SQL

Creiamo un database SQL vuoto con il nome DSC.
Creiamo un account per connetterci a questo database. Assicurati in precedenza che sul server SQL sia abilitata l'autenticazione sia degli account Windows che SQL.
Andiamo alla sezione User Mapping. Selezioniamo il database, in questo caso – DSC. Assegniamo i diritti di proprietà del database.
Fatto.

Creazione dello schema per il database DSC

È possibile creare uno schema per il database DSC in due modi:

manuale, tramite 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

importare i dati da un devices.mdb vuoto come parte del modulo PS PSDesiredStateConfiguration tramite la procedura guidata di importazione dati SQL.
Il Devices.mdb con cui lavoreremo si trova in C:WindowsSysWOW64WindowsPowerShellv1.0ModulesPSDesiredStateConfigurationPullServer.

Per importare i dati, avviamo la Procedura guidata di importazione ed esportazione di SQL Server.
Selezioniamo da dove prenderemo i dati – in questo caso il database Microsoft Access. Clicchiamo su Avanti.
Selezioniamo il file da cui importiamo lo schema.
Indichiamo dove importare, in questo caso è il database SQL.
Selezioniamo il server SQL (Nome server) e il database in cui importeremo i dati (Database).
Selezioniamo l'opzione Copia dati da una o più tabelle o viste.
Selezioniamo le tabelle da cui importeremo lo schema del DB.
Selezioniamo l'opzione Esegui immediatamente e facciamo clic su Fine.
Fatto.
Di conseguenza, le tabelle dovrebbero comparire nel DB DSC.

Configurazione del file .mdb "proxy"

Creazione di una connessione ODBC a SQL Server. Si presume che MS Access non sia installato sul server con DSC, quindi la configurazione di databases.mdb viene eseguita su un host intermedio con MS Access installato.

Creiamo una connessione ODBC di sistema a SQL Server (la bitness della connessione deve corrispondere a quella di MS Access – 64 o 32). Può essere creata utilizzando:
— il comando PowerShell:

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

— oppure manualmente, tramite la procedura guidata delle connessioni:

Apriamo Strumenti di amministrazione. Selezioniamo le origini dati ODBC a seconda della versione di MS Access installata. Passiamo alla scheda DSN di sistema e creiamo una connessione di sistema (Aggiungi).
Indichiamo che ci connetteremo a SQL Server. Facciamo clic su Fine.
Indichiamo il nome e il server per la connessione. Poi sarà necessario creare la stessa connessione sul server DSC con gli stessi parametri.
Indichiamo che per connettersi a SQL Server utilizziamo il login pre-creato chiamato DSC.
Indichiamo il DB nelle impostazioni di connessione DSC.
Facciamo clic su Fine.
Prima di completare la configurazione, verifichiamo che la connessione funzioni (Testa la sorgente dati).
Fatto.

Creazione del database devices.mdb in MS Access. Avviamo MS Access e creiamo un database vuoto chiamato devices.mdb.

Passiamo alla scheda Dati esterni, facciamo clic su Database ODBC. Nella finestra che appare, selezioniamo Crea una tabella collegata per collegarci alla sorgente dati.
Nella nuova finestra selezioniamo la scheda Origine dati macchina e facciamo clic su OK. Nella nuova finestra inseriamo le credenziali per la connessione a SQL Server.
Selezioniamo le tabelle da collegare. Selezioniamo l'opzione Salva password e facciamo clic su OK. La password deve essere salvata ogni volta per tutte e tre le tabelle.
Negli indici è necessario selezionare i seguenti:
— TargetName per la tabella dbo_Devices;

— NodeName o IPAddress per dbo_RegistrationData;

— NodeName o IPAddress per dbo_StatusReport.
Rinominiamo le tabelle in MS Access, ovvero: rimuoviamo il prefisso dbo_ affinché DSC possa usarle.
Fatto.
Salviamo il file e chiudiamo MS Access. Ora copiamo il file devices.mdb ottenuto sul server DSC (di default in C:Program FilesWindowsPowershellDSCService) e sostituiamo quello esistente (se presente).

Configurazione del server DSC per l'utilizzo di SQL

Torniamo al server DSC. Per connettersi al server SQL utilizzando il nostro file proxy, creeremo una nuova connessione ODBC sul server DSC. Il nome, l'architettura e le impostazioni di connessione devono essere gli stessi usati durante la creazione del file MDB. È possibile copiare il file devices.mdb vuoto già configurato da qui.
Per utilizzare devices.mdb, è necessario apportare modifiche al web.config del server DSC (per impostazione predefinita – C:inetpubPSDSCPullServerweb.config):

— per Windows Server 2012

— per Windows Server 2016

A questo punto, la configurazione del server DSC è completata.

Verifica del funzionamento del server DSC

Verifichiamo che il server DSC sia accessibile tramite il web browser.
Ora verifichiamo se il server DSC sta funzionando correttamente. A tal fine, all'interno del modulo xPSDesiredStateConfiguration, è presente uno script chiamato pullserversetuptests.ps1. Prima di eseguire questo script, è necessario installare il modulo Powershell chiamato Pester. Installiamolo con Install-Module -Name Pester.
Apriamo C:Program FilesWindowsPowerShellModulesxPSDesiredStateConfigurationDSCPullServerSetupPullServerDeploymentVerificationTest (nell'esempio la versione è 8.0.0.0.0).
Apriamo PullServerSetupTests.ps1 e controlliamo il percorso del web.config del server DSC. Ho evidenziato in rosso il percorso del web.config che sarà verificato dallo script. Se necessario, cambiamo questo percorso.
Eseguiamo pullserversetuptests.ps1
Invoke-Pester .PullServerSetupTests.ps1
Tutto funziona.
In SQL Management Studio vediamo che gli host gestiti inviano rapporti al server rapporti DSC e che i dati vengono archiviati nel database DSC sul server SQL.

Questo è tutto. Nei prossimi articoli ho intenzione di spiegare come costruire rapporti sui dati ottenuti e affronterò temi relativi alla resilienza e alla scalabilità.

Fonte: habr.com