PowerShell Desired State Configuration (DSC) сильно упрощает работу по развертыванию и конфигурированию операционной системы, ролей сервера и приложений, когда у вас сотни серверов.
Но при использовании DSC on-premises, т.е. не в MS Azure, возникает пара нюансов. Они особенно ощутимы, если организация большая (от 300 рабочих станций и серверов) и в ней еще не открыли мир контейнеров:
- Нет полноценных отчетов о состоянии систем. Если нужная конфигурация не применилась на каких-то серверах, то без этих отчетов мы об этом не узнаем. От встроенного сервера отчетов информацию получить довольно сложно, а для большого количества хостов – еще и долго.
- Отсутствует масштабируемость и отказоустойчивость. Невозможно построить ферму опрашивающих веб-серверов DSC, которые бы имели единую отказоустойчивую базу данных и общее хранилище mof-файлов конфигураций, модулей и ключей регистрации.
Сегодня я расскажу, как можно решить первую проблему и получить данные для построения отчетности. Все было бы проще, если в качестве базы данных можно было бы использовать SQL. MS обещает встроенную поддержку только в Windows Server 2019 или в build Windows server 1803. Забирать данные с использованием OleDB provider тоже не получится, так как DSC-сервер использует именованный параметр, который не полностью поддерживается OleDbCommand.
Нашел вот такой способ: тем, кто использует Windows Server 2012 и 2016, можно настроить использование БД SQL в качестве backend’a для опрашивающего DSC-сервера. Для этого создадим «прокси» в виде .mdb файла со связанными таблицами, который будет перенаправлять данные, полученные от отчетов клиентов, в БД SQL-сервера.
Примечание: для Windows Server 2016 необходимо использовать AccessDatabaseEngine2016x86, так как Microsoft.Jet.OLEDB.4.0 больше не поддерживается.
Я не буду подробно останавливаться на процессе развертывания опрашивающего DSC-сервера, он очень хорошо описан тут. Отмечу только пару моментов. Если мы разворачиваем опрашивающий DSC на одном веб-сервере со WSUS или Kaspersky Security Center, то в скрипте создания конфигурации необходимо поменять следующие параметры:
UseSecurityBestPractices = $false
Иначе TLS 1.0 будет отключен, вы не сможете подключиться к БД SQL. Kaspersky Security Center тоже не будет работать (проблема должна быть решена в Kaspersky Security Center v11).Enable32BitAppOnWin64 = $true
Если не внести это изменение, не получится запустить AppPool DSC-сервера на IIS со WSUS.- При установке DSC-сервера совместно с WSUS отключите статическое и динамическое кэширование для сайта DSC.
Перейдем к настройке сервера DSC для использования БД SQL.
Создание БД SQL
- Создадим пустую базу данных SQL с именем DSC.
- Создадим учетную запись для подключения к этой базе данных. Предварительно проверьте, что на SQL-сервере разрешена аутентификация учетных записей как Windows, так и SQL.
- Переходим в раздел User Mapping. Выбираем базу данных, в данном случае – DSC. Даем права владельца базы данных.
- Готово.
Создание схемы для базы данных DSC
Создать схему для базы данных DSC можно двумя способами:
- самостоятельно, через скрипт на 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
- импортировать данные из пустого devices.mdb в составе PS-модуля PSDesiredStateConfiguration через Мастера импорта данных SQL.
Devices.mdb, с которым мы будем работать, находится в C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\PullServer.
- Для импорта данных запускаем SQL Server Import and Export Wizard.
- Выбираем, откуда мы будем забирать данные – в нашем случае это база данных Microsoft Access. Нажимаем Next.
- Выбираем файл, откуда импортируем схему.
- Указываем, куда импортировать, – у нас это БД SQL.
- Выбираем SQL-сервер (Server Name) и базу данных, в которую будем импортировать данные (DataBase).
- Выбираем опцию Copy data from one or more tables or views (копирование данных из таблиц или представлений).
- Выбираем таблицы, из которых будем импортировать схему БД.
- Ставим галочку Run Immediately и жмем Finish.
- Готово.
- В результате в БД DSC должны появиться таблицы.
Настройка .mdb «прокси» файла
Создание ODBC-подключения к SQL-серверу. Предполагается, что MS Access не установлен на сервере с DSC, поэтому настройка databases.mdb выполняется на промежуточном хосте с установленным MS Access.
Создадим системное ODBC-подключение к SQL-серверу (разрядность подключения должна совпадать с разрядностью MS Access – 64 или 32). Его можно создать с помощью:
— командлета Powershell:
Add-OdbcDsn –Name DSC –DriverName 'SQL Server' –Platform '<64-bit or 32-bit>' –DsnType System –SetPropertyValue @('Description=DSC Pull Server',"Server=<Name of your SQL Server>",'Trusted_Connection=yes','Database=DSC') –PassThru
— или вручную, с помощью мастера подключений:
- Открываем Administrative tools. Выбираем источники данных ODBC в зависимости от версии установленного MS Access. Переходим во вкладку System DSN и создаем системное подключение (Add).
- Указываем, что будем подключаться к SQL-серверу. Жмем Finish.
- Указываем имя и сервер для подключения. Потом подключение с такими же параметрами нужно будет создать на сервере DSC.
- Указываем, что для подключения к SQL-серверу используется предварительно созданный нами логин с именем DSC.
- Указываем БД в настройках подключения DSC.
- Жмем Finish.
- Перед завершением настройки проверяем, что подключение работает (Test Data Source).
- Готово.
Создание базы данных devices.mdb в MS Access. Запускаем MS Access и создаем пустую базу данных под названием devices.mdb.
- Переходим во вкладку Внешние данные, кликаем на База данных ODBC. В появившемся окне выбираем Создать связанную таблицу для связи с источником данных.
- В новом окне выбираем вкладку Machine Data Source и жмем ОК. В новом окне вводим учетные данные для подключения к SQL-серверу.
- Выбираем таблицы, которые необходимо прилинковать. Отмечаем галкой Сохранить пароль и жмем ОК. Пароль сохранять каждый раз для всех трех таблиц.
- В индексах нужно выбрать следующие:
— TargetName для таблицы dbo_Devices;
— NodeName или IPAddress для dbo_RegistrationData;
— NodeName или IPAddress для dbo_StatusReport.
- Переименуем таблицы в MS Access, а именно: удалим префикс dbo_, чтобы DSC мог использовать их.
- Готово.
- Сохраняем файл и закрываем MS Access. Теперь копируем полученный devices.mdb на DSC-сервер (по умолчанию в C:\Program Files\WindowsPowershell\DSCService) и заменяем им существующий (если он есть).
Настройка DSC-сервера для использования SQL
- Возвращаемся к серверу DSC. Чтобы подключиться к SQL-серверу с нашим proxy-файлом, создадим новое ODBC подключение на DSC-сервере. Имя, и разрядность, и настройки подключения должны быть такие же, как и при создании MDB-файла. Можно скопировать уже настроенный пустой devices.mdb отсюда.
- Чтобы использовать devices.mdb, нужно внести изменения в web.config опрашивающего сервера DSC (по умолчанию – C:\inetpub\PSDSCPullServer\web.config):
— для Windows Server 2012
<add key="dbprovider" value="System.Data.OleDb">
<add key="dbconnectionstr" value="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Program Files\WindowsPowerShell\DscService\Devices.mdb;">
— для Windows Server 2016
<add key="dbprovider" value="System.Data.OleDb">
<add key="dbconnectionstr" value="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Program Files\WindowsPowerShell\DscService\Devices.mdb;">
На этом настройка DSC-сервера закончена.
Проверка работоспособности DSC-сервера
- Проверим, что DSC-сервер доступен через web-браузер.
- Теперь проверим, правильно ли работает опрашивающий сервер DSC. Для этого в составе модуля xPSDesiredStateConfiguration есть скрипт pullserversetuptests.ps1. Перед запуском этого скрипта необходимо установить модуль Powershell с именем Pester. Устанавливаем его Install-Module -Name Pester.
- Открываем C:\Program Files\WindowsPowerShell\Modules\xPSDesiredStateConfiguration\<версия модуля>\DSCPullServerSetup\PullServerDeploymentVerificationTest (в примере версия 8.0.0.0.0).
- Открываем PullServerSetupTests.ps1 и проверяем путь к web.config DSC-сервера. Красным выделил путь к web.config, который будет проверять скрипт. Если нужно, меняем этот путь.
- Запускаем pullserversetuptests.ps1
Invoke-Pester .\PullServerSetupTests.ps1
Все работает.
- В SQL Management Studio видим, что администрируемые хосты отправляют отчеты на сервер отчетов DSC и данные попадают в базу данных DSC на SQL-сервере.
На этом все. В следующих статьях планирую рассказать, как на полученных данных построить отчеты, и коснусь вопросов про отказоустойчивость и масштабируемость.