Partilhar via

Melhores práticas do servidor de solicitação

  • Artigo

Aplica-se a: Windows PowerShell 4.0, Windows PowerShell 5.0

Importante

O Servidor pull (Windows Feature DSC-Service) é um componente suportado do Windows Server. No entanto, não existem planos para oferecer novas funcionalidades ou capacidades. Gostaríamos que soubesse que está agora disponível uma versão mais recente do DSC, gerida por uma funcionalidade de Azure Policy com o nome configuração de convidado. O serviço de configuração de convidado combina as funcionalidades da Extensão DSC, Automatização do Azure State Configuration e as funcionalidades mais frequentemente pedidas do feedback dos clientes. A configuração de convidado também inclui suporte de máquina híbrida através de servidores compatíveis com o Arc.

Resumo: este documento destina-se a incluir o processo e a extensibilidade para ajudar os engenheiros que se estão a preparar para a solução. Os detalhes devem fornecer melhores práticas conforme identificados pelos clientes e, em seguida, validados pela equipa do produto para garantir que as recomendações estão futuras e consideradas estáveis.

  • Autor: Michael Greene
  • Revisores: Ben Gelens, Ravikanth Chaganti, Aleksandar Nikolic
  • Publicado em: Abril de 2015

Abstract

Este documento foi concebido para fornecer orientações oficiais para qualquer pessoa que planeie uma implementação do servidor pull Windows PowerShell Desired State Configuration. Um servidor de extração é um serviço simples que deve demorar apenas alguns minutos a implementar. Embora este documento ofereça orientações técnicas sobre procedimentos que podem ser utilizadas numa implementação, o valor deste documento é uma referência para as melhores práticas e sobre o que pensar antes de implementar. Os leitores devem ter conhecimentos básicos sobre o DSC e os termos utilizados para descrever os componentes incluídos numa implementação do DSC. Para obter mais informações, veja o tópico Descrição geral do Windows PowerShell Desired State Configuration. Como se espera que o DSC evolua na cadência da cloud, espera-se também que a tecnologia subjacente, incluindo o servidor pull, evolua e introduza novas capacidades. Este documento inclui uma tabela de versões no apêndice que fornece referências a versões anteriores e referências a soluções futuras para incentivar designs orientados para o futuro.

As duas principais secções deste documento:

  • Planeamento de Configuração
  • Guia de Instalação

Versões do Windows Management Framework

As informações neste documento destinam-se a ser aplicadas ao Windows Management Framework 5.0. Embora o WMF 5.0 não seja necessário para implementar e operar um servidor de extração, a versão 5.0 é o foco deste documento.

Windows PowerShell Desired State Configuration

Desired State Configuration (DSC) é uma plataforma de gestão que permite implementar e gerir dados de configuração através de uma sintaxe do setor com o nome Managed Object Format (MOF) para descrever o Common Information Model (CIM). Existe um projeto de open source, Open Management Infrastructure (OMI), para continuar o desenvolvimento destas normas em várias plataformas, incluindo sistemas operativos de hardware de rede e Linux. Para obter mais informações, veja a página DMTF que liga às especificações do MOF e Documentos e Origem do OMI.

Windows PowerShell fornece um conjunto de extensões de idioma para Desired State Configuration que pode utilizar para criar e gerir configurações declarativas.

Função de servidor pull

Um servidor de extração fornece um serviço centralizado para armazenar configurações que serão acessíveis aos nós de destino.

A função de servidor de extração pode ser implementada como uma instância do Servidor Web ou uma partilha de ficheiros SMB. A capacidade do servidor Web inclui uma interface OData e, opcionalmente, pode incluir capacidades para os nós de destino comunicarem a confirmação de êxito ou falha à medida que as configurações são aplicadas. Esta funcionalidade é útil em ambientes onde existe um grande número de nós de destino. Depois de configurar um nó de destino (também referido como cliente) para apontar para o servidor de extração, os dados de configuração mais recentes e quaisquer scripts necessários são transferidos e aplicados. Isto pode acontecer como uma implementação única ou como uma tarefa que ocorre novamente, o que também faz do servidor de extração um recurso importante para gerir as alterações em escala. Para obter mais informações, veja Modos de Configuração push e pull.

Planeamento de configuração

Para qualquer implementação de software empresarial, existem informações que podem ser recolhidas antecipadamente para ajudar a planear a arquitetura correta e para estar preparado para os passos necessários para concluir a implementação. As secções seguintes fornecem informações sobre como preparar e as ligações organizacionais que provavelmente terão de ocorrer com antecedência.

Requisitos de software

A implementação de um servidor de solicitação requer a funcionalidade Serviço DSC do Windows Server. Esta funcionalidade foi introduzida no Windows Server 2012 e foi atualizada através de versões em curso do Windows Management Framework (WMF).

Transferências de software

Além de instalar o conteúdo mais recente do Windows Update, existem duas transferências consideradas melhores práticas para implementar um servidor de solicitação DSC: a versão mais recente do Windows Management Framework e um módulo DSC para automatizar o aprovisionamento do servidor pull.

Recurso DSC

Uma implementação de servidor pull pode ser simplificada ao aprovisionar o serviço com um script de configuração do DSC. Este documento inclui scripts de configuração que podem ser utilizados para implementar um nó de servidor pronto para produção. Para utilizar os scripts de configuração, é necessário um módulo DSC que não esteja incluído no Windows Server. O nome do módulo necessário é xPSDesiredStateConfiguration, que inclui o recurso de DSC xDscWebService. O módulo xPSDesiredStateConfiguration pode ser transferido a partir do Galeria do PowerShell.

Utilize o Install-Module cmdlet do módulo PowerShellGet .

Install-Module xPSDesiredStateConfiguration

O módulo PowerShellGet irá transferir o módulo para:

C:\Program Files\Windows PowerShell\Modules

Tarefa de planeamento

  • Tem acesso aos ficheiros de instalação do Windows Server 2012 R2?
  • O ambiente de implementação terá acesso à Internet para transferir o WMF e o módulo a partir da galeria online?
  • Como irá instalar as atualizações de segurança mais recentes depois de instalar o sistema operativo?
  • O ambiente terá acesso à Internet para obter atualizações ou terá um servidor de Windows Server Update Services (WSUS) local?
  • Tem acesso aos ficheiros de instalação do Windows Server que já incluem atualizações através da injeção offline?

Requisitos de hardware

As implementações do servidor pull são suportadas em servidores físicos e virtuais. Os requisitos de dimensionamento do servidor de extração estão alinhados com os requisitos do Windows Server 2012 R2.

  • CPU: processador de 64 bits de 1,4 GHz
  • Memória: 512 MB
  • Espaço em Disco: 32 GB
  • Rede: Adaptador Gigabit Ethernet

Tarefa de planeamento

  • Vai implementar em hardware físico ou numa plataforma de virtualização?
  • Qual é o processo para pedir um novo servidor para o seu ambiente de destino?
  • Qual é o tempo médio de reviravolta para que um servidor fique disponível?
  • Que tamanho de servidor vai pedir?

Contas

Não existem requisitos de conta de serviço para implementar uma instância do servidor pull. No entanto, existem cenários em que o site pode ser executado no contexto de uma conta de utilizador local. Por exemplo, se for necessário aceder a uma partilha de armazenamento para o conteúdo do site e o Windows Server ou o dispositivo que aloja a partilha de armazenamento não estiverem associados a um domínio.

Registos DNS

Precisará de um nome de servidor para utilizar ao configurar clientes para trabalhar com um ambiente de servidor de solicitação. Em ambientes de teste, normalmente é utilizado o nome do anfitrião do servidor ou o endereço IP do servidor pode ser utilizado se a resolução de nomes DNS não estiver disponível. Em ambientes de produção ou num ambiente de laboratório destinado a representar uma implementação de produção, a melhor prática é criar um registo CNAME DNS.

Um CNAME DNS permite-lhe criar um alias para fazer referência ao registo do anfitrião (A). A intenção do registo de nomes adicional é aumentar a flexibilidade caso seja necessária uma alteração no futuro. Um CNAME pode ajudar a isolar a configuração do cliente para que as alterações ao ambiente do servidor, como substituir um servidor de extração ou adicionar servidores de extração adicionais, não exijam uma alteração correspondente à configuração do cliente.

Ao escolher um nome para o registo DNS, tenha em mente a arquitetura da solução. Se utilizar o balanceamento de carga, o certificado utilizado para proteger o tráfego através de HTTPS terá de partilhar o mesmo nome que o registo DNS.

Melhores práticas do cenário

  • Ambiente de Teste – reproduza o ambiente de produção planeado, se possível. Um nome de anfitrião de servidor é adequado para configurações simples. Se o DNS não estiver disponível, poderá ser utilizado um endereço IP em vez de um nome de anfitrião.
  • Implementação de Nó Único – crie um registo CNAME DNS que aponte para o nome do anfitrião do servidor.

Para obter mais informações, veja Configuring DNS Round Robin in Windows Server (Configurar o Round Robin do DNS no Windows Server).

Tarefa de planeamento

  • Sabe quem deve contactar para que os registos DNS tenham sido criados e alterados?
  • Qual é a reviravolta média de um pedido para um registo DNS?
  • Precisa de pedir registos estáticos de Nome do Anfitrião (A) para servidores?
  • O que vai pedir como CNAME?
  • Se necessário, que tipo de solução de Balanceamento de Carga irá utilizar? (consulte a secção intitulada Balanceamento de Carga para obter detalhes)

Infraestrutura de Chaves Públicas

A maioria das organizações de hoje exige que o tráfego de rede, especialmente o tráfego que inclui dados confidenciais como a forma como os servidores são configurados, tenha de ser validado e/ou encriptado durante o trânsito. Embora seja possível implementar um servidor Pull com HTTP, o que facilita os pedidos de cliente em texto claro, é uma melhor prática proteger o tráfego através de HTTPS. O serviço pode ser configurado para utilizar HTTPS com um conjunto de parâmetros no recurso DSC xPSDesiredStateConfiguration.

Os requisitos de certificado para proteger o tráfego HTTPS para o servidor Pull não são diferentes de proteger qualquer outro web site HTTPS. O modelo de Servidor Web num Serviço de Certificados do Windows Server satisfaz as capacidades necessárias.

Tarefa de planeamento

  • Se os pedidos de certificado não forem automatizados, quem terá de contactar para pedir um certificado?
  • Qual é a reviravolta média do pedido?
  • Como é que o ficheiro de certificado será transferido para si?
  • Como é que a chave privada do certificado será transferida para si?
  • Quanto tempo é o tempo de expiração predefinido?
  • Estabeleceu um nome DNS para o ambiente do servidor Pull, que pode utilizar para o nome do certificado?

Escolher uma arquitetura

Um servidor Pull pode ser implementado através de um serviço Web alojado no IIS ou de uma partilha de ficheiros SMB. Na maioria das situações, a opção de serviço Web proporcionará maior flexibilidade. Não é incomum o tráfego HTTPS atravessar limites de rede, enquanto o tráfego SMB é frequentemente filtrado ou bloqueado entre redes. O serviço Web também oferece a opção de incluir um Servidor de Conformidade ou Um Gestor de Relatórios Web (ambos os tópicos a serem abordados numa versão futura deste documento) que fornece um mecanismo para os clientes comunicarem o estado de volta a um servidor para visibilidade centralizada. O SMB fornece uma opção para ambientes em que a política determina que um servidor Web não deve ser utilizado e para outros requisitos ambientais que tornam uma função de servidor Web indesejável. Em ambos os casos, lembre-se de avaliar os requisitos de assinatura e encriptação de tráfego. As políticas HTTPS, assinatura SMB e IPSEC são todas as opções que vale a pena considerar.

Balanceamento de carga

Os clientes que interagem com o serviço Web fazem um pedido de informações que são devolvidas numa única resposta. Não são necessários pedidos sequenciais, pelo que não é necessário que a plataforma de balanceamento de carga garanta que as sessões são mantidas num único servidor a qualquer momento.

Tarefa de planeamento

  • Que solução será utilizada para o balanceamento de carga do tráfego entre servidores?
  • Se estiver a utilizar um balanceador de carga de hardware, quem irá pedir para adicionar uma nova configuração ao dispositivo?
  • Qual é a reviravolta média de um pedido para configurar um novo serviço Web com balanceamento de carga?
  • Que informações serão necessárias para o pedido?
  • Terá de pedir um IP adicional ou a equipa responsável pelo balanceamento de carga processa isso?
  • Tem os registos DNS necessários e será necessário para a equipa responsável pela configuração da solução de balanceamento de carga?
  • A solução de balanceamento de carga requer que o PKI seja processado pelo dispositivo ou pode fazer o balanceamento de carga do tráfego HTTPS desde que não existam requisitos de sessão?

Configurações de teste e módulos no servidor Pull

Como parte do planeamento de configuração, terá de pensar em que módulos e configurações do DSC serão alojados pelo servidor Pull. Para fins de planeamento de configuração, é importante ter uma compreensão básica de como preparar e implementar conteúdos num servidor Pull.

No futuro, esta secção será expandida e incluída num Guia de Operações do Servidor Pull DSC. O guia irá debater o processo diário para gerir módulos e configurações ao longo do tempo com a automatização.

Módulos DSC

Os clientes que pedirem uma configuração precisarão dos módulos de DSC necessários. Uma funcionalidade do servidor Pull é automatizar a distribuição a pedido de módulos DSC para clientes. Se estiver a implementar um servidor Pull pela primeira vez, talvez como laboratório ou prova de conceito, é provável que dependa de módulos DSC disponíveis a partir de repositórios públicos, como o Galeria do PowerShell ou os PowerShell.org repositórios do GitHub para módulos DSC.

É fundamental lembrar que, mesmo para origens online fidedignas, como a Galeria do PowerShell, qualquer módulo transferido de um repositório público deve ser revisto por alguém com experiência e conhecimento do PowerShell sobre o ambiente onde os módulos serão utilizados antes de serem utilizados na produção. Ao concluir esta tarefa, é uma boa altura para verificar se existem payloads adicionais no módulo que possam ser removidos, como documentação e scripts de exemplo. Isto reduzirá a largura de banda de rede por cliente no primeiro pedido, quando os módulos serão transferidos através da rede de servidor para cliente.

Cada módulo tem de ser empacotado num formato específico, um ficheiro ZIP com o nome ModuleName_Version.zip que contém o payload do módulo. Depois de o ficheiro ser copiado para o servidor, tem de ser criado um ficheiro de soma de verificação. Quando os clientes se ligam ao servidor, a soma de verificação é utilizada para verificar se o conteúdo do módulo DSC não foi alterado desde que foi publicado.

New-DscChecksum -ConfigurationPath .\ -OutPath .\

Tarefa de planeamento

  • Se estiver a planear um ambiente de teste ou laboratório que cenários são fundamentais para validar?
  • Existem módulos publicamente disponíveis que contenham recursos para cobrir tudo o que precisa ou precisará de criar os seus próprios recursos?
  • O seu ambiente terá acesso à Internet para obter módulos públicos?
  • Quem será responsável pela revisão dos módulos do DSC?
  • Se estiver a planear um ambiente de produção, o que irá utilizar como um repositório local para armazenar módulos DSC?
  • Uma equipa central aceitará módulos DSC das equipas de aplicações? Qual será o processo?
  • Irá automatizar o empacotamento, a cópia e a criação de uma soma de verificação para módulos DSC prontos para produção no servidor, a partir do repositório de origem?
  • A sua equipa também será responsável pela gestão da plataforma de automatização?

Configurações do DSC

O objetivo de um servidor Pull é fornecer um mecanismo centralizado para distribuir configurações de DSC para nós de cliente. As configurações são armazenadas no servidor como documentos MOF. Cada documento será nomeado com um Guid exclusivo. Quando os clientes são configurados para se ligarem a um servidor Pull, também lhes é atribuído o Guid para a configuração que devem pedir. Este sistema de referência de configurações por Guid garante a exclusividade global e é flexível de modo a que uma configuração possa ser aplicada com granularidade por nó ou como uma configuração de função que abrange muitos servidores que devem ter configurações idênticas.

Guids

O planeamento dos Guids de configuração vale a pena ter mais atenção ao pensar através de uma implementação do servidor Pull. Não existe um requisito específico para como lidar com guids e é provável que o processo seja exclusivo para cada ambiente. O processo pode ir de simples a complexo: um ficheiro CSV armazenado centralmente, uma tabela SQL simples, um CMDB ou uma solução complexa que exija integração com outra ferramenta ou solução de software. Existem duas abordagens gerais:

  • Atribuir Guids por servidor – fornece uma medida de garantia de que cada configuração do servidor é controlada individualmente. Isto fornece um nível de precisão em torno das atualizações e pode funcionar bem em ambientes com poucos servidores.

  • Atribuir Guids por função de servidor – todos os servidores que executam a mesma função, como servidores Web, utilizam o mesmo GUID para referenciar os dados de configuração necessários. Tenha em atenção que, se muitos servidores partilharem o mesmo GUID, todos serão atualizados em simultâneo quando a configuração for alterada.

    O GUID é algo que deve ser considerado dados confidenciais porque pode ser aproveitado por alguém com intenção maliciosa para obter informações sobre como os servidores são implementados e configurados no seu ambiente. Para obter mais informações, veja Alocar guids de forma segura no PowerShell Desired State Configuration Modo Pull.

Tarefa de planeamento

  • Quem será responsável por copiar as configurações para a pasta do servidor Pull quando estiverem prontas?
  • Se as Configurações forem criadas por uma equipa de aplicações, qual será o processo para as entregar?
  • Irá tirar partido de um repositório para armazenar configurações à medida que estão a ser criadas, entre equipas?
  • Irá automatizar o processo de copiar configurações para o servidor e criar uma soma de verificação quando estiverem prontas?
  • Como irá mapear guids para servidores ou funções e onde será armazenado?
  • O que irá utilizar como um processo para configurar máquinas cliente e como irá integrar-se no seu processo de criação e armazenamento de Guids de Configuração?

Guia de Instalação

Os scripts indicados neste documento são exemplos estáveis. Reveja sempre os scripts cuidadosamente antes de executá-los num ambiente de produção.

Pré-requisitos

Para verificar a versão do PowerShell no servidor, utilize o seguinte comando.

$PSVersionTable.PSVersion

Se possível, atualize para a versão mais recente do Windows Management Framework. Em seguida, transfira o xPsDesiredStateConfiguration módulo com o seguinte comando.

Install-Module xPSDesiredStateConfiguration

O comando pedirá a sua aprovação antes de transferir o módulo.

Scripts de instalação e configuração

O melhor método para implementar um servidor pull DSC é utilizar um script de configuração do DSC. Este documento apresentará scripts, incluindo ambas as definições básicas que configurariam apenas o serviço Web DSC e definições avançadas que configurariam um serviço Web do Windows Server ponto a ponto, incluindo o serviço Web DSC.

Nota: atualmente, o xPSDesiredStateConfiguration módulo DSC requer que o servidor seja uma região EN-US.

Configuração básica para 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\'

Configuração avançada para 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'

Verificar a funcionalidade do servidor Pull

# 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

Configurar clientes

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

Referências adicionais, fragmentos e exemplos

Este exemplo mostra como iniciar manualmente uma ligação de cliente (requer WMF5) para testes.

Update-DscConfiguration -Wait -Verbose

O cmdlet Add-DnsServerResourceRecordName é utilizado para adicionar um tipo de registo CNAME a uma zona DNS.

A Função do PowerShell para Criar uma Soma de Verificação e Publicar o MOF do DSC no SMB Pull Server gera automaticamente a soma de verificação necessária e, em seguida, copia os ficheiros de soma de verificação e configuração do MOF para o servidor pull SMB.

Apêndice – Compreender os tipos de ficheiros de dados do serviço ODATA

É armazenado um ficheiro de dados para criar informações durante a implementação de um servidor Pull que inclui o serviço Web OData. O tipo de ficheiro depende do sistema operativo, conforme descrito abaixo.

  • Windows Server 2012 - O tipo de ficheiro será sempre.mdb
  • Windows Server 2012 R2 – o tipo de ficheiro será predefinido a .edb menos que seja especificado um .mdb na configuração

No script Exemplo avançado para instalar um Servidor Pull, também encontrará um exemplo de como controlar automaticamente as definições de web.config ficheiro para evitar qualquer hipótese de erro causado pelo tipo de ficheiro.