🥇PowerShell Desired State Configuration e rasoi: parte 1. Configurazione del Server Pull DSC per lavorare con il database SQL

La configurazione dello stato desiderato di PowerShell (DSC) semplifica notevolmente il processo di distribuzione e configurazione del sistema operativo, dei ruoli del server e delle applicazioni, soprattutto quando si dispone di centinaia di server.

Tuttavia, nell'utilizzo di DSC on-premises, ovvero non in MS Azure, ci sono alcune particolarità. Queste sono particolarmente evidenti se l'organizzazione è grande (con oltre 300 workstation e server) e non ha ancora aperto il mondo dei container:

Non ci sono report dettagliati sullo stato dei sistemi. Se la configurazione desiderata non è stata applicata a determinati server, senza questi report non ne saremo a conoscenza. Ottenere informazioni dal server di report integrato è piuttosto difficile, e per un gran numero di host – anche lungo.
Manca scalabilità e resilienza. È impossibile costruire una farm di server web DSC che abbia un'unica base di dati resiliente e uno storage condiviso per i file di configurazione mof, moduli e chiavi di registrazione.

Oggi spiegherò come è possibile risolvere il primo problema e ottenere dati per costruire report. Sarebbe tutto più semplice se potessimo usare SQL come database. MS promette supporto integrato solo in Windows Server 2019 o nella build di Windows Server 1803. Non è possibile recuperare i dati utilizzando l'OleDB provider, non è possibile, poiché il server DSC utilizza un parametro denominato che non è completamente supportato da OleDbCommand.

Ho trovato questo modo: per chi utilizza Windows Server 2012 e 2016, è possibile essere personalizzato utilizzare 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 ricevuti dai report dei clienti nel database del server SQL.

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

Non mi soffermerò nel dettaglio sul processo di distribuzione del server DSC interrogante, è molto ben descritto qui. Sottolineo solo un paio di punti. Se distribuiamo il server DSC interrogante su un server web insieme a WSUS o Kaspersky Security Center, nel batch della configurazione è necessario modificare i seguenti parametri:

```
UseSecurityBestPractices = $false
```
Altrimenti TLS 1.0 verrà disabilitato e non sarà possibile collegarsi al database SQL. Anche Kaspersky Security Center non funzionerà (il problema dovrebbe essere risolto nella versione 11 di Kaspersky Security Center).
```
Abilitare32BitAppOnWin64   = $true
```
Se non apporti questa modifica, non sarà possibile avviare AppPool del server DSC su IIS con WSUS.
Durante l'installazione del server DSC insieme a WSUS, disabilita la memorizzazione nella cache statica e dinamica per il sito DSC.

Passiamo alla configurazione del server DSC per utilizzare il database SQL.

Creazione del database SQL

Creiamo un database SQL vuoto con il nome DSC.
Creiamo un account per connetterci a questo database. Verifica in anticipo che sul server SQL sia consentita l'autenticazione sia per gli account Windows che per SQL.
Andiamo nella sezione User Mapping. Selezioniamo il database, in questo caso – DSC. Concediamo i diritti di proprietario del database.
Fatto.

Creazione dello schema per il database DSC

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

manualmente, tramite uno script in TSQL

IMPOSTA ANSI_NULLS ON
GO
IMPOSTA QUOTED_IDENTIFIER ON
GO
CREA TABELLA [dbo].[Devices](
[TargetName] [nvarchar](255) NON NULL,
[ConfigurationID] [nvarchar](255) NON NULL,
[ServerCheckSum] [nvarchar](255) NON NULL,
[TargetCheckSum] [nvarchar](255) NON NULL,
[NodeCompliant] [bit] NON NULL,
[LastComplianceTime] [datetime] NULL,
[LastHeartbeatTime] [datetime] NULL,
[Dirty] [bit] NON NULL,
[StatusCode] [int] NULL
) SU [PRIMARY]
GO

CREA TABELLA [dbo].[RegistrationData](
[AgentId] [nvarchar](255) NON NULL,
[LCMVersion] [nvarchar](255) NULL,
[NodeName] [nvarchar](255) NULL,
[IPAddress] [nvarchar](255) NULL,
[ConfigurationNames] [nvarchar](max) NULL
) SU [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

CREA TABELLA [dbo].[StatusReport](
[JobId] [nvarchar](50) NON NULL,
[Id] [nvarchar](50) NON 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
) SU [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

importare i dati da un vuoto devices.mdb all'interno del modulo PS PSDesiredStateConfiguration tramite la procedura guidata di importazione dati SQL.
Devices.mdb, con cui lavoreremo, si trova in C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\PullServer.

Per importare i dati, lanciamo la Procedura guidata di importazione ed esportazione di SQL Server.
Selezioniamo da dove prenderemo i dati: in questo caso è un database Microsoft Access. Facciamo clic su Avanti.
Selezioniamo il file da cui importiamo lo schema.
Indichiamo dove importare, nel nostro caso nel database SQL.
Selezioniamo il server SQL (Nome server) e il database in cui importeremo i dati (DataBase).
Selezioniamo l'opzione Copia dei dati da una o più tabelle o viste.
Selezioniamo le tabelle da cui importeremo lo schema del database.
Mettiamo il segno di spunta Esegui immediatamente e premiamo Fine.
Fatto.
Di conseguenza, nelle tabelle del database DSC dovrebbero apparire.

Configurazione del file .mdb "proxy"

Creazione della connessione ODBC al server SQL. Si suppone 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.

Creeremo una connessione ODBC di sistema al server SQL (la bitness della connessione deve corrispondere a quella di MS Access – 64 o 32). Può essere creata utilizzando:
— il cmdlet 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, usando la procedura guidata di connessione:

Apriamo Strumenti di amministrazione. Selezioniamo le fonti dati ODBC a seconda della versione di MS Access installata. Andiamo alla scheda DSN di sistema e creiamo una connessione di sistema (Aggiungi).
Indichiamo che ci connetteremo al server SQL. Clicchiamo su Finish.
Inseriamo il nome e il server per la connessione. Poi sarà necessario creare una connessione con gli stessi parametri sul server DSC.
Indichiamo che per la connessione al server SQL viene utilizzato un login precedentemente creato con il nome DSC.
Indichiamo il DB nelle impostazioni di connessione DSC.
Clicchiamo su Finish.
Prima di completare le impostazioni, verifichiamo che la connessione funzioni (Test Data Source).
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 connettersi alla fonte dati.
Nella nuova finestra selezioniamo la scheda Machine Data Source e clicchiamo su OK. Nella nuova finestra inseriamo le credenziali per la connessione al server SQL.
Selezioniamo le tabelle che devono essere collegate. Spuntiamo Salva password e clicchiamo su OK. La password deve essere salvata ogni volta per tutte e tre le tabelle.
Negli indici, dobbiamo selezionare i seguenti:
— TargetName per la tabella dbo_Devices;

— NodeName o IPAddress per dbo_RegistrationData;

— NodeName o IPAddress per dbo_StatusReport.
Rinominare le tabelle in MS Access, rimuovendo il prefisso dbo_ in modo che DSC possa utilizzarle.
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 lo sostituiamo a quello esistente (se presente).

Configurazione del server DSC per utilizzare SQL

Torniamo al server DSC. Per connetterci al server SQL usando il nostro file proxy, creeremo una nuova connessione ODBC sul server DSC. Il nome, l'architettura e le impostazioni di connessione devono essere le stesse usate per creare il file MDB. È possibile copiare il devices.mdb vuoto già configurato da qui.
Per utilizzare devices.mdb, è necessario apportare modifiche a web.config del server DSC (di default – C:inetpubPSDSCPullServerweb.config):

— per Windows Server 2012

— per Windows Server 2016

Con questo, la configurazione del server DSC è completata.

Verifica del funzionamento del server DSC

Controlliamo che il server DSC sia accessibile tramite un browser web.
Ora verifichiamo se il server del DSCPullServer funziona correttamente. A tal fine, nel modulo xPSDesiredStateConfiguration è presente uno script chiamato pullserversetuptests.ps1. Prima di eseguire questo script, è necessario installare il modulo PowerShell chiamato Pester. Procediamo con Install-Module -Name Pester.
Apriamo C:Program FilesWindowsPowerShellModulesxPSDesiredStateConfiguration<versione del modulo>DSCPullServerSetupPullServerDeploymentVerificationTest (nell'esempio, versione 8.0.0.0.0).
Apriamo PullServerSetupTests.ps1 e controlliamo il percorso del file web.config del server DSC. Ho evidenziato in rosso il percorso del web.config che verrà verificato dallo script. Se necessario, modifichiamo questo percorso.
Eseguiamo pullserversetuptests.ps1
Invoke-Pester .PullServerSetupTests.ps1
Tutto funziona.
In SQL Management Studio vediamo che gli host amministrati inviano rapporti al server report DSC e i dati vengono memorizzati nel database DSC sul server SQL.

Questo è tutto. Negli articoli successivi, ho intenzione di spiegare come costruire report sui dati acquisiti e affronterò le questioni relative alla tolleranza agli errori e alla scalabilità.

Fonte: habr.com