PowerShell Desired State Configuration y un destornillador: parte 1. Configuración del servidor DSC Pull para trabajar con bases de datos SQL

PowerShell Desired State Configuration (DSC) simplifica en gran medida el trabajo de implementación y configuración del sistema operativo, roles de servidor y aplicaciones, especialmente cuando tienes cientos de servidores.

Sin embargo, al usar DSC en las instalaciones, es decir, no en MS Azure, hay un par de matices. Son especialmente evidentes si la organización es grande (más de 300 estaciones de trabajo y servidores) y aún no ha explorado el mundo de los contenedores:

• No hay informes completos sobre el estado de los sistemas. Si la configuración necesaria no se aplicó en algunos servidores, no lo sabremos sin estos informes. Obtener información del servidor de informes integrado es bastante difícil, y para un gran número de hosts, aún más lento.
• Falta de escalabilidad y tolerancia a fallos. No es posible construir un conjunto de servidores web DSC que tenga una base de datos única de tolerancia a fallos y un almacenamiento común de archivos mof de configuraciones, módulos y claves de registro.

Hoy hablaré sobre cómo se puede resolver el primer problema y obtener datos para construir informes. Todo sería más fácil si se pudiera usar SQL como base de datos. promete Soporte incorporado solo en Windows Server 2019 o en la compilación Windows Server 1803. Obtener datos utilizando el proveedor OleDB tampoco funcionará, ya que el servidor DSC utiliza un parámetro nombrado que no es completamente compatible con OleDbCommand.

Encontré esta forma: para quienes usan Windows Server 2012 y 2016, se puede configurar utilizar una base de datos SQL como backend para el servidor DSC sondeador. Para ello, crearemos un "proxy" en forma de archivo .mdb con tablas vinculadas, que redirigirá los datos obtenidos de los informes de los clientes a la base de datos del servidor SQL.

Nota: para Windows Server 2016 es necesario utilizar AccessDatabaseEngine2016x86, ya que Microsoft.Jet.OLEDB.4.0 ya no es compatible.

No me detendré en el proceso de implementación del servidor DSC sondeador, está muy bien descrito. aquíSolo destacaré un par de puntos. Si estamos implementando el servidor DSC sondeador en un servidor web con WSUS o Kaspersky Security Center, en el script de creación de la configuración es necesario cambiar los siguientes parámetros:

1. UseSecurityBestPractices = $false

   De lo contrario, TLS 1.0 se desactivará y no podrás conectarte a la base de datos SQL. Kaspersky Security Center tampoco funcionará (el problema debería resolverse en Kaspersky Security Center v11).

2. Enable32BitAppOnWin64 = $true

   Si no se realiza este cambio, no se podrá iniciar el AppPool del servidor DSC en IIS con WSUS.

3. Al instalar el servidor DSC junto con WSUS, desactive el almacenamiento en caché, tanto estático como dinámico, para el sitio DSC.

Pasemos a la configuración del servidor DSC para utilizar la base de datos SQL.

Creación de la base de datos SQL

1. Crearemos una base de datos SQL vacía llamada DSC.

   
   
   

2. Crearemos una cuenta para conectarnos a esta base de datos. Asegúrese de que en el servidor SQL esté habilitada la autenticación tanto de cuentas de Windows como de SQL.

   
   
   

3. Vamos a la sección de Mapeo de Usuarios. Elegimos la base de datos, en este caso, DSC. Otorgamos permisos de propietario de la base de datos.

   

4. Listo.

   

Creación del esquema para la base de datos DSC

Se puede crear un esquema para la base de datos DSC de dos maneras:

• manualmente, a través de un script en 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

• importar datos del dispositivo vacío devices.mdb como parte del módulo PS PSDesiredStateConfiguration a través del Asistente de importación de datos de SQL.

  Devices.mdb, con el que trabajaremos, se encuentra en C:WindowsSysWOW64WindowsPowerShellv1.0ModulesPSDesiredStateConfigurationPullServer.

1. Para importar los datos, iniciamos el Asistente de Importación y Exportación de SQL Server.

   

2. Elegimos de dónde tomaremos los datos; en nuestro caso, es la base de datos Microsoft Access. Hacemos clic en Siguiente.

   

3. Elegimos el archivo del que importaremos el esquema.

   

4. Indicamos a dónde importar, que es nuestra base de datos SQL.

   

5. Seleccionamos el servidor SQL (Nombre del Servidor) y la base de datos a la que importaremos los datos (Base de Datos).

   

6. Seleccionamos la opción Copiar datos de una o más tablas o vistas.

   

7. Elegimos las tablas de las que importaremos el esquema de la base de datos.

   

8. Marcamos la casilla Ejecutar Inmediatamente y hacemos clic en Finalizar.

   

9. Listo.

   

10. Como resultado, las tablas deberían aparecer en la base de datos DSC.

    

Configuración del archivo .mdb 'proxy'

Creación de una conexión ODBC al servidor SQL. Se supone que MS Access no está instalado en el servidor con DSC, por lo que la configuración de databases.mdb se realiza en un host intermedio con MS Access instalado.

Crearemos una conexión ODBC del sistema al servidor SQL (la arquitectura de la conexión debe coincidir con la de MS Access: 64 o 32 bits). Se puede crear utilizando:
— el cmdlet de PowerShell:

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

— o manualmente, utilizando el asistente de conexiones:

1. Abrimos Herramientas administrativas. Seleccionamos fuentes de datos ODBC dependiendo de la versión de MS Access instalada. Vamos a la pestaña DSN del sistema y creamos una conexión del sistema (Agregar).

   

2. Indicamos que nos conectaremos al servidor SQL. Hacemos clic en Finalizar.

   

3. Indicamos el nombre y el servidor para la conexión. Luego, deberemos crear la conexión con los mismos parámetros en el servidor DSC.

   

4. Indicamos que para la conexión al servidor SQL se utiliza el inicio de sesión que hemos creado previamente con el nombre DSC.

   

5. Especificamos la base de datos en la configuración de conexión de DSC.

   

6. Hacemos clic en Finalizar.

   

7. Antes de completar la configuración, verificamos que la conexión funcione (Probar origen de datos).

   

8. Listo.

   

Creación de la base de datos devices.mdb en MS Access. Iniciamos MS Access y creamos una base de datos vacía llamada devices.mdb.

1. Vamos a la pestaña Datos externos, hacemos clic en Base de datos ODBC. En la ventana que aparece, seleccionamos Crear tabla vinculada para conectar con la fuente de datos.

   

2. En la nueva ventana, seleccionamos la pestaña Fuente de datos de máquina y hacemos clic en Aceptar. En la nueva ventana, ingresamos las credenciales para conectarnos al servidor SQL.

   

3. Seleccionamos las tablas que necesitamos vincular. Marcamos la opción Guardar contraseña y hacemos clic en Aceptar. Se debe guardar la contraseña cada vez para las tres tablas.

   

4. En los índices, debemos seleccionar los siguientes:
   — TargetName para la tabla dbo_Devices;

   
   
   — NodeName o IPAddress para dbo_RegistrationData;

   
   
   — NodeName o IPAddress para dbo_StatusReport.

   

5. Renombramos las tablas en MS Access, es decir: eliminamos el prefijo dbo_ para que DSC pueda utilizarlas.

   

6. Listo.

   

7. Guardamos el archivo y cerramos MS Access. Ahora copiamos el devices.mdb obtenido en el servidor DSC (por defecto en C:Program FilesWindowsPowershellDSCService) y lo reemplazamos si ya existe.

Configuración del servidor DSC para utilizar SQL

1. Volvemos al servidor DSC. Para conectarnos al servidor SQL con nuestro archivo proxy, crearemos una nueva conexión ODBC en el servidor DSC. El nombre, la arquitectura y la configuración de conexión deben ser los mismos que al crear el archivo MDB. Se puede copiar el archivo devices.mdb vacío ya configurado desde aquí.
2. Para utilizar devices.mdb, es necesario realizar cambios en el archivo web.config del servidor DSC (por defecto – C:inetpubPSDSCPullServerweb.config):

— para Windows Server 2012

— para Windows Server 2016

La configuración del servidor DSC ha finalizado.

Verificación del funcionamiento del servidor DSC

1. Comprobaremos que el servidor DSC es accesible a través de un navegador web.

   

2. Ahora verificaremos si el servidor DSC funciona correctamente. Para ello, en el módulo xPSDesiredStateConfiguration hay un script llamado pullserversetuptests.ps1. Antes de ejecutar este script, es necesario instalar el módulo de PowerShell llamado Pester. Lo instalamos usando Install-Module -Name Pester.
3. Abrimos C:Program FilesWindowsPowerShellModulesxPSDesiredStateConfigurationDSCPullServerSetupPullServerDeploymentVerificationTest (en el ejemplo, la versión 8.0.0.0.0).

   

4. Abrimos PullServerSetupTests.ps1 y comprobamos la ruta al archivo web.config del servidor DSC. He destacado en rojo la ruta al web.config que será verificada por el script. Si es necesario, cambiamos esta ruta.

   

5. Ejecutamos pullserversetuptests.ps1
   Invoke-Pester .PullServerSetupTests.ps1
   Todo funciona.

   

6. En SQL Management Studio, vemos que los hosts administrados envían informes al servidor de informes DSC y que los datos llegan a la base de datos DSC en el servidor SQL.

   

Eso es todo. En los próximos artículos planeo contar cómo construir informes con los datos obtenidos y abordar temas sobre la tolerancia a fallos y la escalabilidad.

Fuente: habr.com