Рекомендации по работе с опрашивающим сервером

Область применения: Windows PowerShell 4.0, Windows PowerShell 5.0

Описание: Этот документ предназначен для описания процесса и расширяемости, чтобы помочь инженерам, которые готовятся к решению. Детали должны содержать рекомендации, определенные клиентами, а затем проверенные командой по продукту, чтобы гарантировать, что рекомендации соответствуют требованиям будущего и считаются стабильными.

• Автор: Майкл Грин
• Рецензенты: Бен Геленс, Равикант Чаганти, Александр Николич
• Опубликовано: апрель, 2015

Краткие сведения

Этот документ содержит официальные рекомендации для всех, кто планирует реализовать опрашивающий сервер конфигурации требуемого состояния Windows PowerShell. Опрашивающий сервер — это простая служба, развертывание которой должно занять всего несколько минут. Несмотря на то, что в этом документе содержатся технические рекомендации, которые можно использовать при развертывании, ценность этого документа заключается в том, что он является справочником по передовым методикам и сведениям, о которых следует подумать перед развертыванием. Читатели должны быть знакомы с DSC и терминами, используемыми для описания компонентов, включенных в развертывание DSC. Дополнительные сведения см. в разделе Обзор конфигурации требуемого состояния Windows PowerShell . Поскольку ожидается, что DSC будет развиваться в соответствии с облачными технологиями, ожидается, что базовая технология, включая опрашивающий сервер, также будет развиваться и предоставлять новые возможности. В приложении к этому документу содержится таблица версий, содержащая ссылки на предыдущие выпуски и ссылки на будущие решения для поощрения перспективных проектов.

Два основных раздела настоящего документа:

• Планирование конфигурации
• Руководство по установке

Версии платформы управления Windows

Информация в этом документе предназначена для использования в Windows Management Framework 5.0. Хотя WMF 5.0 не требуется для развертывания и эксплуатации опрашивающего сервера, версия 5.0 является основной темой этого документа.

Конфигурация требуемого состояния Windows PowerShell

Конфигурация требуемого состояния (DSC) — это платформа управления, которая позволяет развертывать данные конфигурации и управлять ими с помощью отраслевого синтаксиса под названием Managed Object Format (MOF) для описания общей информационной модели (CIM). Проект с открытым исходным кодом, Open Management Infrastructure (OMI), существует для дальнейшего развития этих стандартов на всех платформах, включая Linux и сетевые аппаратные операционные системы. Дополнительные сведения см. на странице DMTF со ссылкой на спецификации MOF, а также в документах и источнике OMI.

Windows PowerShell предоставляет набор языковых расширений для конфигурации требуемого состояния, которые можно использовать для создания декларативных конфигураций и управления ими.

Роль опрашивающего сервера

Опрашивающий сервер предоставляет централизованную службу для хранения конфигураций, которые будут доступны целевым узлам.

Роль опрашивающего сервера может быть развернута либо как экземпляр веб-сервера, либо как общая папка SMB. Возможности веб-сервера включают в себя интерфейс OData и опционально могут включать возможности для целевых узлов сообщать о подтверждении успеха или неудачи при применении конфигураций. Эта функция полезна в средах с большим количеством целевых узлов. После настройки целевого узла (также называемого клиентом) для указания на опрашивающий сервер загружаются и применяются последние данные конфигурации и все необходимые скрипты. Это может произойти как единовременное развертывание, так и повторяющееся задание, что также делает опрашивающий сервер важным активом для управления изменениями в масштабе. Дополнительные сведения см. в разделе Режимы настройки Push и Pull.

Планирование конфигурации

Для любого развертывания корпоративного программного обеспечения существует информация, которая может быть собрана заранее, чтобы помочь спланировать правильную архитектуру и подготовиться к шагам, необходимым для завершения развертывания. В следующих разделах представлена информация о том, как подготовиться и какие организационные связи могут потребоваться заранее.

Требования к программному обеспечению

Для развертывания опрашивающего сервера требуется функция службы DSC Windows Server. Эта функция появилась в Windows Server 2012 и была обновлена в рамках текущих выпусков Windows Management Framework (WMF).

Скачивание программного обеспечения

В дополнение к установке последнего содержимого из Центра обновления Windows рекомендуется загрузить два варианта для развертывания опрашивающего сервера DSC: последняя версия Windows Management Framework и модуль DSC для автоматизации подготовки опрашивающего сервера.

Ресурс DSC

Развертывание опрашивающего сервера можно упростить, инициализировав службу с помощью сценария конфигурации DSC. Этот документ содержит сценарии конфигурации, которые можно использовать для развертывания готового к использованию серверного узла. Для использования сценариев настройки требуется модуль DSC, который не входит в состав Windows Server. Обязательное имя модуля — xPSDesiredStateConfiguration, который включает ресурс DSC xDscWebService. Модуль xPSDesiredStateConfiguration можно загрузить из галереи PowerShell.

Используйте Install-Module командлет из модуля PowerShellGet .

Install-Module xPSDesiredStateConfiguration

Модуль PowerShellGet загрузит модуль для выполнения следующих задач:

C:\Program Files\Windows PowerShell\Modules

Задача планирования

• Есть ли у вас доступ к установочным файлам для Windows Server 2012 R2?
• Будет ли среда развертывания иметь доступ к Интернету для загрузки WMF и модуля из онлайн-галереи?
• Как вы будете устанавливать последние обновления безопасности после установки операционной системы?
• Будет ли среда иметь доступ к Интернету для получения обновлений или в ней будет локальный сервер служб Windows Server Update Services (WSUS)?
• Есть ли у вас доступ к установочным файлам Windows Server, которые уже содержат обновления путем автономного внедрения?

Требования к оборудованию

Развертывание опрашивающих серверов поддерживается как на физических, так и на виртуальных серверах. Требования к размеру опрашивающего сервера соответствуют требованиям к Windows Server 2012 R2.

• Процессор: 64-разрядный процессор с тактовой частотой 1,4 ГГц
• Оперативная память: 512 МБ
• Место на диске: 32 GB
• Сеть: адаптер Gigabit Ethernet

Задача планирования

• Будете ли вы развертываться на физическом оборудовании или на платформе виртуализации?
• Каков процесс запроса нового сервера для целевой среды?
• Каково среднее время обработки сервера, чтобы он стал доступен?
• Какой размер сервера вы запросите?

Accounts

Для развертывания экземпляра опрашивающего сервера нет требований к учетной записи службы. Однако существуют сценарии, в которых веб-сайт может работать в контексте учетной записи локального пользователя. Например, если необходимо получить доступ к общей папке хранилища для содержимого веб-сайта, а Windows Server или устройство, на котором размещена общая папка хранилища, не присоединены к домену.

Записи DNS

Имя сервера потребуется использовать при настройке клиентов для работы со средой опрашивающего сервера. В тестовых средах обычно используется имя хоста сервера или IP-адрес сервера, если разрешение DNS-имен недоступно. В производственных средах или в лабораторных условиях, предназначенных для представления рабочего развертывания, рекомендуется создать запись DNS CNAME.

DNS CNAME позволяет создать псевдоним для ссылки на запись хоста (A). Целью дополнительной записи имени является повышение гибкости в случае необходимости внесения изменений в будущем. CNAME может помочь изолировать конфигурацию клиента, чтобы изменения в серверной среде, такие как замена опрашивающего сервера или добавление дополнительных опрашивающих серверов, не требовали соответствующего изменения конфигурации клиента.

При выборе имени для DNS-записи учитывайте архитектуру решения. При использовании балансировки нагрузки сертификат, используемый для защиты трафика по протоколу HTTPS, должен иметь то же имя, что и запись DNS.

Рекомендации по сценариям

• Тестовая среда - По возможности воспроизведите запланированную производственную среду. Имя хоста сервера подходит для простых конфигураций. Если DNS недоступен, вместо имени хоста может использоваться IP-адрес.
• Развертывание на одном узле — создание записи DNS CNAME, указывающей на имя узла сервера.

Дополнительные сведения см. в разделе Настройка циклического перебора DNS в Windows Server.

Задача планирования

• Знаете ли вы, к кому обратиться для создания и изменения DNS-записей?
• Каков средний срок выполнения запроса на запись DNS?
• Вам нужно запрашивать статические записи Hostname (A) для серверов?
• Что вы запросите в качестве CNAME?
• При необходимости, какой тип решения для балансировки нагрузки вы будете использовать? (подробнее см. раздел «Балансировка нагрузки»)

Инфраструктура открытых ключей

В настоящее время большинство организаций требуют, чтобы сетевой трафик, особенно трафик, включающий такие конфиденциальные данные, как конфигурация серверов, проверялся и/или шифровался во время передачи. Несмотря на то, что пул-сервер можно развернуть с помощью протокола HTTP, что облегчает обработку клиентских запросов в открытом виде, рекомендуется защищать трафик с помощью протокола HTTPS. Службу можно настроить на использование протокола HTTPS с помощью набора параметров в ресурсе DSC xPSDesiredStateConfiguration.

Требования к сертификату для защиты трафика HTTPS для опрашивающего сервера ничем не отличаются от требований к защите любого другого веб-сайта HTTPS. Шаблон веб-сервера в службах сертификации Windows Server удовлетворяет необходимым возможностям.

Задача планирования

• Если запросы сертификатов не автоматизированы, к кому вам нужно будет обращаться для запроса сертификата?
• Каков средний срок выполнения запроса?
• Как файл сертификата будет передан вам?
• Как вам будет передан приватный ключ сертификата?
• Как долго длится срок действия по умолчанию?
• Вы определились с DNS-именем для среды опрашивающего сервера, которое можно использовать в качестве имени сертификата?

Выбор архитектуры

Опрашивающий сервер может быть развернут с помощью веб-службы, размещенной в IIS, или общей папки SMB. В большинстве ситуаций вариант веб-службы обеспечит большую гибкость. Трафик HTTPS нередко пересекает границы сети, в то время как трафик SMB часто фильтруется или блокируется между сетями. Веб-служба также предлагает возможность включения сервера соответствия или веб-диспетчера отчетов (обе эти темы будут рассмотрены в следующей версии этого документа), которые предоставляют клиентам механизм отправки отчетов о состоянии на сервер для централизованного контроля. SMB предоставляет возможность для сред, в которых политика не требует использования веб-сервера, а также для других требований среды, которые делают роль веб-сервера нежелательной. В любом случае не забудьте оценить требования к подписи и шифрованию трафика. Стоит рассмотреть варианты HTTPS, подписи SMB и политики IPSEC.

Балансировка нагрузки

Клиенты, взаимодействующие с веб-службой, делают запрос на получение информации, который возвращается в виде одного ответа. Последовательные запросы не требуются, поэтому платформе балансировки нагрузки нет необходимости обеспечивать проведение сеансов на одном сервере в любой момент времени.

Задача планирования

• Какое решение будет использоваться для балансировки нагрузки трафика между серверами?
• Если используется аппаратный балансировщик нагрузки, кто будет принимать запрос на добавление новой конфигурации на устройство?
• Каков средний срок выполнения запроса на настройку новой веб-службы с балансировкой нагрузки?
• Какая информация потребуется для запроса?
• Нужно ли вам будет запрашивать дополнительный IP-адрес или это сделает команда, ответственная за балансировку нагрузки?
• Есть ли у вас необходимые записи DNS, и потребуется ли это команде, ответственной за настройку решения для балансировки нагрузки?
• Требует ли решение балансировки нагрузки, чтобы PKI обрабатывалось устройством, или оно может балансировать трафик HTTPS при условии отсутствия требований к сеансу?

Промежуточное размещение конфигураций и модулей на опрашивающем сервере

В рамках планирования конфигурации необходимо подумать о том, какие модули и конфигурации DSC будут размещены на опрашивающем сервере. При планировании конфигурации важно иметь базовое представление о том, как подготавливать и развертывать контент на опрашивающем сервере.

В будущем этот раздел будет расширен и включен в Руководство по эксплуатации DSC Pull Server. В руководстве будет рассмотрен повседневный процесс управления модулями и конфигурациями с течением времени с помощью автоматизации.

Модули DSC

Клиентам, запрашивающим конфигурацию, потребуются необходимые модули DSC. Функционалом пулл-сервера является автоматизация раздачи по требованию модулей DSC клиентам. Если вы развертываете опрашивающий сервер впервые, например, в качестве лабораторной работы или проверки концепции, вы, скорее всего, будете зависеть от модулей DSC, доступных из общедоступных репозиториев, таких как PowerShell Gallery или репозитории PowerShell.org GitHub для модулей DSC.

Важно помнить, что даже для надежных онлайн-источников, таких как PowerShell Gallery, любой модуль, загруженный из общедоступного репозитория, должен быть проверен кем-то, кто имеет опыт работы с PowerShell и знает среду, в которой будут использоваться модули, прежде чем использовать их в рабочей среде. Во время выполнения этой задачи самое время проверить наличие дополнительной полезной нагрузки в модуле, которую можно удалить, например, документацию и примеры скриптов. Это уменьшит пропускную способность сети на каждого клиента при первом запросе, когда модули будут загружаться по сети от сервера к клиенту.

Каждый модуль должен быть упакован в определенный формат, ZIP-файл с именем ModuleName_Version.zip, содержащий полезную нагрузку модуля. После того, как файл будет скопирован на сервер, необходимо создать файл контрольной суммы. Когда клиенты подключаются к серверу, контрольная сумма используется для проверки того, что содержимое модуля DSC не изменилось с момента его публикации.

New-DscChecksum -ConfigurationPath .\ -OutPath .\

Задача планирования

• Если вы планируете тестовую или лабораторную среду, какие сценарии являются ключевыми для проверки?
• Существуют ли общедоступные модули, содержащие ресурсы, охватывающие все необходимое, или вам нужно будет создавать свои собственные ресурсы?
• Будет ли в вашей среде доступ к Интернету для получения общедоступных модулей?
• Кто будет отвечать за рецензирование модулей DSC?
• Если вы планируете производственную среду, что вы будете использовать в качестве локального репозитория для хранения модулей DSC?
• Будет ли центральная группа принимать модули DSC от групп разработчиков? Каким будет процесс?
• Будете ли вы автоматизировать упаковку, копирование и создание контрольной суммы для готовых к производству модулей DSC на сервер из исходного репозитория?
• Будет ли ваша команда также отвечать за управление платформой автоматизации?

Конфигурации DSC

Назначение опрашивающего сервера — предоставить централизованный механизм распределения конфигураций DSC по клиентским узлам. Конфигурации хранятся на сервере в виде документов MOF. Каждому документу будет присвоен уникальный идентификатор Guid. Когда клиенты настроены на подключение к опрашивающему серверу, им также предоставляется Guid для конфигурации, которую они должны запросить. Эта система ссылок на конфигурации от Guid гарантирует глобальную уникальность и является гибкой, так что конфигурация может быть применена с детализацией для каждого узла или в виде конфигурации роли, охватывающей множество серверов, которые должны иметь идентичные конфигурации.

Гиды

Планирование конфигурационных гайдов заслуживает дополнительного внимания при продумывании развертывания опрашивающего сервера. Нет никаких конкретных требований к тому, как обращаться с Guids, и процесс, вероятно, будет уникальным для каждой среды. Процесс может варьироваться от простого до сложного: централизованно хранящийся CSV-файл, простая таблица SQL, CMDB или сложное решение, требующее интеграции с другим инструментом или программным решением. Существует два основных подхода:

• Назначение Guids для каждого сервера — обеспечивает гарантию того, что каждая конфигурация сервера контролируется индивидуально. Это обеспечивает определенный уровень точности при обновлении и может хорошо работать в средах с небольшим количеством серверов.

• Назначение GUID для каждой роли сервера — все серверы, выполняющие одну и ту же функцию, такие как веб-серверы, используют один и тот же GUID для ссылки на необходимые данные конфигурации. Имейте в виду, что если несколько серверов используют один и тот же идентификатор GUID, все они будут обновляться одновременно при изменении конфигурации.

  GUID — это то, что следует считать конфиденциальными данными, поскольку оно может быть использовано злоумышленником со злым умыслом для получения информации о том, как серверы развертываются и настраиваются в вашей среде. Дополнительные сведения см. в статье Безопасное выделение Guids в режиме извлечения конфигурации требуемого состояния PowerShell.

Задача планирования

• Кто будет отвечать за копирование конфигураций в папку опрашивающего сервера, когда они будут готовы?
• Если конфигурации создаются группой разработчиков приложений, каков будет процесс их передачи?
• Будете ли вы использовать репозиторий для хранения конфигураций по мере их создания в разных командах?
• Будете ли вы автоматизировать процесс копирования конфигураций на сервер и создания контрольной суммы по мере их готовности?
• Как вы будете сопоставлять Guids с серверами или ролями, и где они будут храниться?
• Что вы будете использовать в качестве процесса для настройки клиентских компьютеров и как он будет интегрироваться с вашим процессом создания и хранения Configuration Guids?

Руководство по установке

Скрипты, приведенные в этом документе, являются стабильными примерами. Всегда внимательно просматривайте скрипты перед их выполнением в рабочей среде.

Предпосылки

Чтобы проверить версию PowerShell на сервере, используйте следующую команду.

$PSVersionTable.PSVersion

Если возможно, выполните обновление до последней версии Windows Management Framework. Далее скачайте xPsDesiredStateConfiguration модуль с помощью следующей команды.

Install-Module xPSDesiredStateConfiguration

Перед загрузкой модуля команда запросит ваше одобрение.

Скрипты установки и настройки

Лучшим методом развертывания опрашивающего сервера DSC является использование сценария настройки DSC. В этом документе будут представлены сценарии, включающие как базовые параметры, которые настраивают только веб-службу DSC, так и расширенные параметры, которые полностью настраивают Windows Server, включая веб-службу DSC.

Примечание: В настоящее время xPSDesiredStateConfiguration модуль DSC требует, чтобы сервер был EN-US локалью.

Базовая конфигурация для Windows Server 2012

# This is a very basic Configuration to deploy a pull server instance in a lab
# environment on Windows Server 2012.

Configuration PullServer {
Import-DscResource -ModuleName xPSDesiredStateConfiguration

        # Load the Windows Server DSC Service feature
        WindowsFeature DSCServiceFeature
        {
          Ensure = 'Present'
          Name = 'DSC-Service'
        }

        # Use the DSC Resource to simplify deployment of the web service
        xDSCWebService PSDSCPullServer
        {
          Ensure = 'Present'
          EndpointName = 'PSDSCPullServer'
          Port = 8080
          PhysicalPath = "$env:SYSTEMDRIVE\inetpub\wwwroot\PSDSCPullServer"
          CertificateThumbPrint = 'AllowUnencryptedTraffic'
          ModulePath = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"
          ConfigurationPath = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration"
          State = 'Started'
          DependsOn = '[WindowsFeature]DSCServiceFeature'
        }
}
PullServer -OutputPath 'C:\PullServerConfig\'
Start-DscConfiguration -Wait -Force -Verbose -Path 'C:\PullServerConfig\'

Расширенная конфигурация для Windows Server 2012 R2

# This is an advanced Configuration example for Pull Server production deployments
# on Windows Server 2012 R2. Many of the features demonstrated are optional and
# provided to demonstrate how to adapt the Configuration for multiple scenarios
# Select the needed resources based on the requirements for each environment.
# Optional scenarios include:
#      * Reduce footprint to Server Core
#      * Rename server and join domain
#      * Switch from SSL to TLS for HTTPS
#      * Automatically load certificate from Certificate Authority
#      * Locate Modules and Configuration data on remote SMB share
#      * Manage state of default websites in IIS

param (
        [Parameter(Mandatory=$true)]
        [ValidateNotNullorEmpty()]
        [System.String] $ServerName,
        [System.String] $DomainName,
        [System.String] $CARootName,
        [System.String] $CAServerFQDN,
        [System.String] $CertSubject,
        [System.String] $SMBShare,
        [Parameter(Mandatory=$true)]
        [ValidateNotNullorEmpty()]
        [PsCredential] $Credential
    )

Configuration PullServer {
    Import-DscResource -ModuleName xPSDesiredStateConfiguration, xWebAdministration, xCertificate, xComputerManagement
    Node localhost
    {

        # Configure the server to automatically corret configuration drift including reboots if needed.
        LocalConfigurationManager
        {
            ConfigurationMode = 'ApplyAndAutoCorrect'
            RebootNodeifNeeded = $node.RebootNodeifNeeded
            CertificateId = $node.Thumbprint
        }

        # Remove all GUI interfaces so the server has minimum running footprint.
        WindowsFeature ServerCore
        {
            Ensure = 'Absent'
            Name = 'User-Interfaces-Infra'
        }

        # Set the server name and if needed, join a domain. If not joining a domain, remove the DomainName parameter.
        xComputer DomainJoin
        {
            Name = $Node.ServerName
            DomainName = $Node.DomainName
            Credential = $Node.Credential
        }

        # The next series of settings disable SSL and enable TLS, for environments where that is required by policy.
        Registry TLS1_2ServerEnabled
        {
            Ensure = 'Present'
            Key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'
            ValueName = 'Enabled'
            ValueData = 1
            ValueType = 'Dword'
        }

        Registry TLS1_2ServerDisabledByDefault
        {
            Ensure = 'Present'
            Key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'
            ValueName = 'DisabledByDefault'
            ValueData = 0
            ValueType = 'Dword'
        }

        Registry TLS1_2ClientEnabled
        {
            Ensure = 'Present'
            Key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client'
            ValueName = 'Enabled'
            ValueData = 1
            ValueType = 'Dword'
        }

        Registry TLS1_2ClientDisabledByDefault
        {
            Ensure = 'Present'
            Key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client'
            ValueName = 'DisabledByDefault'
            ValueData = 0
            ValueType = 'Dword'
        }

        Registry SSL2ServerDisabled
        {
            Ensure = 'Present'
            Key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server'
            ValueName = 'Enabled'
            ValueData = 0
            ValueType = 'Dword'
        }

        # Install the Windows Server DSC Service feature
        WindowsFeature DSCServiceFeature
        {
            Ensure = 'Present'
            Name = 'DSC-Service'
        }

        # If using a certificate from a local Active Directory Enterprise Root Certificate Authority,
        # complete a request and install the certificate
        xCertReq SSLCert
        {
            CARootName = $Node.CARootName
            CAServerFQDN = $Node.CAServerFQDN
            Subject = $Node.CertSubject
            AutoRenew = $Node.AutoRenew
            Credential = $Node.Credential
        }

        # Use the DSC resource to simplify deployment of the web service.  You might also consider
        # modifying the default port, possibly leveraging port 443 in environments where that is
        # enforced as a standard.
        xDSCWebService PSDSCPullServer
        {
            Ensure = 'Present'
            EndpointName = 'PSDSCPullServer'
            Port = 8080
            PhysicalPath = "$env:SYSTEMDRIVE\inetpub\wwwroot\PSDSCPullServer"
            CertificateThumbPrint = 'CertificateSubject'
            CertificateSubject = $Node.CertSubject
            ModulePath = "$($Node.SMBShare)\DscService\Modules"
            ConfigurationPath = "$($Node.SMBShare)\DscService\Configuration"
            State = 'Started'
            DependsOn = '[WindowsFeature]DSCServiceFeature'
        }

        # Validate web config file contains current DB settings
        xWebConfigKeyValue CorrectDBProvider
        {
            ConfigSection = 'AppSettings'
            Key = 'dbprovider'
            Value = 'System.Data.OleDb'
            WebsitePath = 'IIS:\sites\PSDSCPullServer'
            DependsOn = '[xDSCWebService]PSDSCPullServer'
        }
        xWebConfigKeyValue CorrectDBConnectionStr
        {
            ConfigSection = 'AppSettings'
            Key = 'dbconnectionstr'
            Value = 'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Program Files\WindowsPowerShell\DscService\Devices.mdb;'
            WebsitePath = 'IIS:\sites\PSDSCPullServer'
            DependsOn = '[xDSCWebService]PSDSCPullServer'
        }

        # Stop the default website
        xWebsite StopDefaultSite
        {
            Ensure = 'Present'
            Name = 'Default Web Site'
            State = 'Stopped'
            PhysicalPath = 'C:\inetpub\wwwroot'
            DependsOn = '[WindowsFeature]DSCServiceFeature'
        }
    }
}

$configData = @{
    AllNodes = @(
        @{
            NodeName = 'localhost'
            ServerName = $ServerName
            DomainName = $DomainName
            CARootName = $CARootName
            CAServerFQDN = $CAServerFQDN
            CertSubject = $CertSubject
            AutoRenew = $true
            SMBShare = $SMBShare
            Credential = $Credential
            RebootNodeifNeeded = $true
            CertificateFile = 'c:\PullServerConfig\Cert.cer'
            Thumbprint = 'B9A39921918B466EB1ADF2509E00F5DECB2EFDA9'
            }
        )
    }

PullServer -ConfigurationData $configData -OutputPath 'C:\PullServerConfig\'
Set-DscLocalConfigurationManager -ComputerName localhost -Path 'C:\PullServerConfig\'
Start-DscConfiguration -Wait -Force -Verbose -Path 'C:\PullServerConfig\'

# .\Script.ps1 -ServerName web1 -domainname 'test.pha' -carootname 'test-dc01-ca' -caserverfqdn 'dc01.test.pha' -certsubject 'CN=service.test.pha' -smbshare '\\sofs1.test.pha\share'

Проверка функциональности опрашивающего сервера

# This function is meant to simplify a check against a DSC pull server. If you do not use the
# default service URL, you will need to adjust accordingly.
function Verify-DSCPullServer ($fqdn) {
    ([xml](Invoke-WebRequest "https://$($fqdn):8080/psdscpullserver.svc" | % Content)).service.workspace.collection.href
}

Verify-DSCPullServer 'INSERT SERVER FQDN'

Expected Result:
Action
Module
StatusReport
Node

Настройка клиентов

Configuration PullClient {
    param(
        $ID,
        $Server
    )
    LocalConfigurationManager
    {
        ConfigurationID = $ID;
        RefreshMode = 'PULL';
        DownloadManagerName = 'WebDownloadManager';
        RebootNodeIfNeeded = $true;
        RefreshFrequencyMins = 30;
        ConfigurationModeFrequencyMins = 15;
        ConfigurationMode = 'ApplyAndAutoCorrect';
        DownloadManagerCustomData = @{
            ServerUrl = "http://"+$Server+":8080/PSDSCPullServer.svc"
            AllowUnsecureConnection = $true
        }
    }
}

PullClient -ID 'INSERTGUID' -Server 'INSERTSERVER' -Output 'C:\DSCConfig\'
Set-DscLocalConfigurationManager -ComputerName 'Localhost' -Path 'C:\DSCConfig\' -Verbose

Дополнительные ссылки, сниппеты и примеры

В этом примере показано, как вручную инициировать подключение клиента (требуется WMF5) для тестирования.

Update-DscConfiguration -Wait -Verbose

Командлет Add-DnsServerResourceRecordName используется для добавления записи типа CNAME в зону DNS.

Функция PowerShell для создания контрольной суммы и публикации DSC MOF на опрашивающем сервере SMB автоматически создает необходимую контрольную сумму, а затем копирует файлы конфигурации и контрольной суммы MOF на опрашивающий сервер SMB.

Приложение - Общие сведения о типах файлов данных службы ODATA

Файл данных хранится для создания информации во время развертывания опрашивающего сервера, включающего веб-службу OData. Тип файла зависит от операционной системы, как описано ниже.

• Windows Server 2012 - Тип файла всегда будет .mdb
• Windows Server 2012 R2 — тип файла будет использоваться по умолчанию, .edb если в конфигурации не указан a .mdb

В Расширенном примере скрипта для установки Pull Server вы также найдете пример автоматического управления настройками web.config файла, чтобы предотвратить вероятность ошибки, вызванной типом файла.