PowerShell Desired State Configuration et un fichier brut : partie 1. Configuration du serveur Pull DSC pour travailler avec une base de données SQL

La Configuration d'État désiré PowerShell (DSC) simplifie considérablement le déploiement et la configuration du système d'exploitation, des rôles de serveur et des applications, surtout lorsque vous avez des centaines de serveurs.

Mais en utilisant DSC sur site, c'est-à-dire pas dans MS Azure, quelques subtilités apparaissent. Elles sont particulièrement perceptibles si l'organisation est grande (à partir de 300 stations de travail et serveurs) et si elle n'a pas encore ouvert le monde des conteneurs :

• Il n'y a pas de rapports complets sur l'état des systèmes. Si la configuration souhaitée n'a pas été appliquée à certains serveurs, nous n'en saurons rien sans ces rapports. Obtenir des informations à partir du serveur de rapports intégré est assez difficile, et pour un grand nombre d'hôtes, cela prend encore plus de temps.
• Il manque l'évolutivité et la tolérance aux pannes. Il n'est pas possible de construire un parc de serveurs web DSC interrogeant qui posséderaient une unique base de données tolérante aux pannes et un stockage commun des fichiers mof de configurations, modules et clés de registre.

Aujourd'hui, je vais vous parler de comment résoudre le premier problème et obtenir des données pour établir des rapports. Ce serait plus simple si l'on pouvait utiliser SQL comme base de données. MS promet n'offre un support intégré que sur Windows Server 2019 ou dans la build Windows Server 1803. Il n'est pas non plus possible de récupérer des données en utilisant OleDB provider ce qui n'est pas faisable, car le serveur DSC utilise un paramètre nommé qui n'est pas entièrement pris en charge par OleDbCommand.

J'ai trouvé une méthode : ceux qui utilisent Windows Server 2012 et 2016 peuvent configurer utiliser une base de données SQL comme backend pour le serveur DSC interrogeant. Pour cela, nous allons créer un « proxy » sous la forme d'un fichier .mdb avec des tables liées, qui redirigera les données obtenues des rapports clients vers la base de données du serveur SQL.

Remarque : pour Windows Server 2016, il est nécessaire d'utiliser AccessDatabaseEngine2016x86, car Microsoft.Jet.OLEDB.4.0 n'est plus pris en charge.

Je ne vais pas m'attarder sur le processus de déploiement du serveur DSC interrogeant, qui est très bien décrit ici. Je soulignerai seulement quelques points. Si nous déployons le serveur DSC interrogeant sur un même serveur web que WSUS ou Kaspersky Security Center, il est nécessaire de changer les paramètres suivants dans le script de création de configuration :

1. UseSecurityBestPractices     = $false

   Sinon, TLS 1.0 sera désactivé, vous ne pourrez pas vous connecter à la base de données SQL. Kaspersky Security Center ne fonctionnera également pas (le problème doit être résolu dans Kaspersky Security Center v11).

2. Enable32BitAppOnWin64   = $true

   Si ce changement n'est pas effectué, il ne sera pas possible de lancer l'AppPool du serveur DSC sur IIS avec WSUS.

3. Lors de l'installation du serveur DSC avec WSUS, désactivez le cache statique et dynamique pour le site DSC.

Passons à la configuration du serveur DSC pour utiliser la base de données SQL.

Création de la base de données SQL

1. Nous allons créer une base de données SQL vide nommée DSC.

   
   
   

2. Créons un compte pour nous connecter à cette base de données. Vérifiez au préalable que l'authentification des comptes soit autorisée sur le serveur SQL, aussi bien pour Windows que pour SQL.

   
   
   

3. Accédez à la section User Mapping. Sélectionnez la base de données, ici - DSC. Accordez les droits de propriétaire de la base de données.

   

4. C'est fait.

   

Création du schéma pour la base de données DSC

Le schéma de la base de données DSC peut être créé de deux manières :

• soit manuellement, via 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

• importer des données du fichier vide devices.mdb via le module PS PSDesiredStateConfiguration à l'aide de l'Assistant d'importation de données SQL.

  Le fichier Devices.mdb avec lequel nous allons travailler se trouve dans C:WindowsSysWOW64WindowsPowerShellv1.0ModulesPSDesiredStateConfigurationPullServer.

1. Pour importer les données, lancez l'Assistant d'importation et d'exportation SQL Server.

   

2. Sélectionnez la source des données – dans notre cas, il s'agit de la base de données Microsoft Access. Cliquez sur Suivant.

   

3. Sélectionnez le fichier à partir duquel nous allons importer le schéma.

   

4. Indiquez où importer – ici, c'est la base de données SQL.

   

5. Choisissez le serveur SQL (Server Name) et la base de données dans laquelle nous allons importer les données (DataBase).

   

6. Sélectionnez l'option Copier les données d'une ou plusieurs tables ou vues (copier les données à partir de tables ou de vues).

   

7. Sélectionnez les tables d'où nous allons importer le schéma de la base de données.

   

8. Cochez la case Exécuter immédiatement et cliquez sur Terminer.

   

9. C'est fait.

   

10. En conséquence, les tables doivent apparaître dans la base de données DSC.

    

Configuration du fichier .mdb «proxy»

Création d'une connexion ODBC au serveur SQL. On suppose que MS Access n'est pas installé sur le serveur avec DSC, donc la configuration databases.mdb est réalisée sur un hôte intermédiaire avec MS Access installé.

Créons une connexion ODBC système au serveur SQL (l'architecture de la connexion doit correspondre à l'architecture de MS Access – 64 ou 32 bits). Elle peut être créée à l'aide de :
— la commande Powershell :

Add-OdbcDsn –Name DSC –DriverName 'SQL Server' –Platform '' –DsnType System –SetPropertyValue @('Description=Serveur de récupération DSC', "Server=", 'Trusted_Connection=yes', 'Database=DSC') –PassThru

— ou manuellement, via l'assistant de connexion :

1. Ouvrons Outils d'administration. Sélectionnons les sources de données ODBC selon la version installée de MS Access. Passons à l'onglet DSN système et créons une connexion système (Ajouter).

   

2. Indiquons que nous allons nous connecter au serveur SQL. Cliquons sur Terminer.

   

3. Indiquons le nom et le serveur pour la connexion. Ensuite, une connexion avec les mêmes paramètres devra être créée sur le serveur DSC.

   

4. Indiquons que pour se connecter au serveur SQL, nous utilisons le login que nous avons préalablement créé avec le nom DSC.

   

5. Indiquons la base de données dans les paramètres de connexion DSC.

   

6. Cliquons sur Terminer.

   

7. Avant de terminer la configuration, vérifions que la connexion fonctionne (Tester la source de données).

   

8. C'est fait.

   

Création de la base de données devices.mdb dans MS Access. Lançons MS Access et créons une base de données vide nommée devices.mdb.

1. Passons à l'onglet Données externes, cliquons sur Base de données ODBC. Dans la fenêtre qui apparaît, choisissons Créer une table liée pour se connecter à la source de données.

   

2. Dans la nouvelle fenêtre, choisissons l'onglet Machine Data Source et cliquons sur OK. Dans la nouvelle fenêtre, saisissons les informations d'identification pour se connecter au serveur SQL.

   

3. Sélectionnons les tables à lier. Cochons la case Enregistrer le mot de passe et cliquons sur OK. Le mot de passe doit être enregistré chaque fois pour les trois tables.

   

4. Dans les index, il faut choisir les suivants :
   — TargetName pour la table dbo_Devices;

   
   
   — NodeName ou IPAddress pour dbo_RegistrationData;

   
   
   — NodeName ou IPAddress pour dbo_StatusReport.

   

5. Renommons les tables dans MS Access, à savoir : supprimons le préfixe dbo_ afin que DSC puisse les utiliser.

   

6. C'est fait.

   

7. Enregistrons le fichier et fermons MS Access. Maintenant, copions le devices.mdb obtenu sur le serveur DSC (par défaut dans C:Program FilesWindowsPowershellDSCService) et le remplaçons par l'existant (s'il y en a un).

Configuration du serveur DSC pour utiliser SQL

1. Retour au serveur DSC. Pour se connecter à SQL Server avec notre fichier proxy, nous allons créer une nouvelle connexion ODBC sur le serveur DSC. Le nom, l'architecture et les paramètres de connexion doivent être les mêmes que lors de la création du fichier MDB. Vous pouvez copier le fichier devices.mdb vide déjà configuré d'ici.
2. Pour utiliser devices.mdb, il est nécessaire de modifier le fichier web.config du serveur DSC en mode interrogateur (par défaut - C:inetpubPSDSCPullServerweb.config) :

— pour Windows Server 2012

— pour Windows Server 2016

Avec cela, la configuration du serveur DSC est terminée.

Vérification du bon fonctionnement du serveur DSC

1. Vérifions que le serveur DSC est accessible via un navigateur web.

   

2. Vérifions maintenant si le serveur interrogateur DSC fonctionne correctement. Pour cela, le module xPSDesiredStateConfiguration contient le script pullserversetuptests.ps1. Avant d'exécuter ce script, il est nécessaire d'installer le module PowerShell nommé Pester. Nous l’installons avec Install-Module -Name Pester.
3. Ouvrons C:Program FilesWindowsPowerShellModulesxPSDesiredStateConfigurationDSCPullServerSetupPullServerDeploymentVerificationTest (dans l'exemple, la version est 8.0.0.0.0).

   

4. Ouvrons PullServerSetupTests.ps1 et vérifions le chemin vers le fichier web.config du serveur DSC. Le chemin vers le fichier web.config que le script va vérifier est surligné en rouge. Si nécessaire, modifions ce chemin.

   

5. Exécutons pullserversetuptests.ps1
   Invoke-Pester .PullServerSetupTests.ps1
   Tout fonctionne.

   

6. Dans SQL Management Studio, nous voyons que les hôtes gérés envoient des rapports au serveur de rapports DSC et que les données vont dans la base de données DSC sur le serveur SQL.

   

C'est tout. Dans les prochains articles, je prévois de parler de la création de rapports à partir des données obtenues et d'aborder les questions de haute disponibilité et d'évolutivité.

Source : habr.com