Dela via

Metodtips för pull-server

Gäller för: Windows PowerShell 4.0, Windows PowerShell 5.0

Viktigt!

Pull-servern (Windows Feature DSC-Service) är en komponent som stöds av Windows Server, men det finns inga planer på att erbjuda nya funktioner. Vi vill att du ska veta att en nyare version av DSC nu är allmänt tillgänglig, som hanteras av en funktion i Azure Policy med namnet gästkonfiguration. Gästkonfigurationstjänsten kombinerar funktioner i DSC-tillägget, Azure Automation State Configuration och de vanligaste funktionerna från kundfeedback. Gästkonfigurationen omfattar även stöd för hybriddatorer via Arc-aktiverade servrar.

Sammanfattning: Det här dokumentet är avsett att inkludera process och utökningsbarhet för att hjälpa tekniker som förbereder sig för lösningen. Informationen bör innehålla bästa praxis som identifierats av kunderna och sedan validerats av produktteamet för att säkerställa att rekommendationerna är framtidsinriktade och anses vara stabila.

  • Författare: Michael Greene
  • Granskare: Ben Gelens, Ravikanth Chaganti, Aleksandar Nikolic
  • Publicerad: april, 2015

Abstrakt

Det här dokumentet är utformat för att ge officiell vägledning för alla som planerar för en implementering av en Windows PowerShell Desired State Configuration pull-serverimplementering. En pull-server är en enkel tjänst som bara tar några minuter att distribuera. Även om det här dokumentet innehåller teknisk vägledning som kan användas i en distribution, är värdet av det här dokumentet som en referens för bästa praxis och vad du bör tänka på innan du distribuerar. Läsare bör ha grundläggande kunskaper om DSC och de termer som används för att beskriva de komponenter som ingår i en DSC-distribution. Mer information finns i avsnittet Översikt över önskad tillståndskonfiguration i Windows PowerShell . Eftersom DSC förväntas utvecklas i molntakt förväntas den underliggande tekniken, inklusive pull-servern, också utvecklas och introducera nya funktioner. Det här dokumentet innehåller en versionstabell i bilagan som innehåller referenser till tidigare versioner och referenser till framtidsinriktade lösningar för att uppmuntra framåtblickande design.

De två huvudavsnitten i det här dokumentet:

  • Planering av konfiguration
  • Installationsguide

Versioner av Windows Management Framework

Informationen i det här dokumentet är avsedd att gälla för Windows Management Framework 5.0. WMF 5.0 krävs inte för att distribuera och driva en pull-server, men version 5.0 är i fokus i det här dokumentet.

Konfiguration av önskat tillstånd i Windows PowerShell

Desired State Configuration (DSC) är en hanteringsplattform som gör det möjligt att distribuera och hantera konfigurationsdata med hjälp av en branschsyntax som kallas Managed Object Format (MOF) för att beskriva Common Information Model (CIM). Det finns ett projekt med öppen källkod, Open Management Infrastructure (OMI), för att vidareutveckla dessa standarder på olika plattformar, inklusive Linux och operativsystem för nätverksmaskinvara. Mer information finns på DMTF-sidan som länkar till MOF-specifikationer och OMI-dokument och källa.

Windows PowerShell innehåller en uppsättning språktillägg för Desired State Configuration som du kan använda för att skapa och hantera deklarativa konfigurationer.

Rollen Hämta server

En pull-server tillhandahåller en centraliserad tjänst för att lagra konfigurationer som ska vara tillgängliga för målnoder.

Pull-serverrollen kan distribueras som antingen en webbserverinstans eller en SMB-filresurs. Webbserverfunktionen innehåller ett OData-gränssnitt och kan eventuellt innehålla funktioner för målnoder för att rapportera tillbaka bekräftelse på lyckade eller misslyckade konfigurationer när konfigurationer tillämpas. Den här funktionen är användbar i miljöer där det finns ett stort antal målnoder. När du har konfigurerat en målnod (kallas även klient) så att den pekar på pull-servern laddas de senaste konfigurationsdata och eventuella skript ned och tillämpas. Detta kan inträffa som en engångsdistribution eller som ett återkommande jobb, vilket också gör pull-servern till en viktig tillgång för att hantera ändringar i stor skala. Mer information finns i Push- och Pull-konfigurationslägen.

Planering av konfiguration

För all distribution av företagsprogramvara finns det information som kan samlas in i förväg för att hjälpa till att planera för rätt arkitektur och för att vara förberedd för de steg som krävs för att slutföra distributionen. Följande avsnitt innehåller information om hur du förbereder dig och de organisatoriska anslutningar som sannolikt måste ske i förväg.

Programvarukrav

Distribution av en pull-server kräver DSC-tjänstfunktionen i Windows Server. Den här funktionen introducerades i Windows Server 2012 och har uppdaterats genom pågående versioner av Windows Management Framework (WMF).

Nedladdningar av programvara

Förutom att installera det senaste innehållet från Windows Update finns det två nedladdningar som anses vara bästa praxis för att distribuera en DSC-pullserver: Den senaste versionen av Windows Management Framework och en DSC-modul för att automatisera etablering av pull-server.

DSC-resurs

En pull-serverdistribution kan förenklas genom att etablera tjänsten med hjälp av ett DSC-konfigurationsskript. Det här dokumentet innehåller konfigurationsskript som kan användas för att distribuera en servernod som är klar för produktion. Om du vill använda konfigurationsskripten krävs en DSC-modul som inte ingår i Windows Server. Det nödvändiga modulnamnet är xPSDesiredStateConfiguration, som innehåller DSC-resursen xDscWebService. Modulen xPSDesiredStateConfiguration kan laddas ned från PowerShell-galleriet.

Använd cmdleten Install-Module från PowerShellGet-modulen .

Install-Module xPSDesiredStateConfiguration

PowerShellGet-modulen laddar ned modulen för att:

C:\Program Files\Windows PowerShell\Modules

Planeringsuppgift

  • Har du tillgång till installationsfilerna för Windows Server 2012 R2?
  • Kommer distributionsmiljön att ha Internetåtkomst för att ladda ned WMF och modulen från onlinegalleriet?
  • Hur installerar du de senaste säkerhetsuppdateringarna efter att du har installerat operativsystemet?
  • Kommer miljön att ha Internetåtkomst för att hämta uppdateringar, eller kommer den att ha en lokal WSUS-server (Windows Server Update Services)?
  • Har du åtkomst till Windows Server-installationsfiler som redan innehåller uppdateringar via offlineinmatning?

Maskinvarukrav

Pull-serverdistributioner stöds på både fysiska och virtuella servrar. Storlekskraven för pull-servern överensstämmer med kraven för Windows Server 2012 R2.

  • CPU: 1,4 GHz 64-bitars processor
  • Minne: 512 MB
  • Diskutrymme: 32 GB
  • Nätverk: Gigabit Ethernet-adapter

Planeringsuppgift

  • Kommer du att distribuera på fysisk maskinvara eller på en virtualiseringsplattform?
  • Vad är processen för att begära en ny server för din målmiljö?
  • Vad är den genomsnittliga handläggningstiden för en server att bli tillgänglig?
  • Vilken storlek på servern kommer du att begära?

Accounts

Det finns inga krav på tjänstkonto för att distribuera en pull-serverinstans. Det finns dock scenarier där webbplatsen kan köras i kontexten för ett lokalt användarkonto. Om det till exempel finns ett behov av att komma åt en lagringsresurs för webbplatsinnehåll och antingen Windows Server eller den enhet som är värd för lagringsresursen inte är domänansluten.

DNS-poster

Du behöver ett servernamn som ska användas när du konfigurerar klienter så att de fungerar med en pull-servermiljö. I testmiljöer används vanligtvis serverns värdnamn, eller så kan serverns IP-adress användas om DNS-namnmatchning inte är tillgänglig. I produktionsmiljöer eller i en labbmiljö som är avsedd att representera en produktionsdistribution är det bästa sättet att skapa en DNS CNAME-post.

Med en DNS CNAME kan du skapa ett alias som refererar till din värdpost (A). Syftet med den extra namnposten är att öka flexibiliteten om en ändring skulle krävas i framtiden. En CNAME kan hjälpa till att isolera klientkonfigurationen så att ändringar i servermiljön, till exempel att ersätta en pull-server eller lägga till ytterligare pull-servrar, inte kräver en motsvarande ändring av klientkonfigurationen.

När du väljer ett namn för DNS-posten bör du tänka på lösningens arkitektur. Om du använder belastningsutjämning måste certifikatet som används för att skydda trafik via HTTPS dela samma namn som DNS-posten.

Metodtips för scenario

  • Testmiljö – Återskapa den planerade produktionsmiljön, om det är möjligt. Ett servervärdnamn är lämpligt för enkla konfigurationer. Om DNS inte är tillgängligt kan en IP-adress användas i stället för ett värdnamn.
  • Distribution med en nod – Skapa en DNS CNAME-post som pekar på serverns värdnamn.

Mer information finns i Konfigurera DNS-resursallokering i Windows Server.

Planeringsuppgift

  • Vet du vem du ska kontakta för att få DNS-poster skapade och ändrade?
  • Vad är den genomsnittliga handläggningstiden för en begäran om en DNS-post?
  • Behöver du begära statiska värdnamnsposter (A) för servrar?
  • Vad kommer du att begära som CNAME?
  • Om det behövs, vilken typ av lastbalanseringslösning kommer du att använda? (se avsnittet Belastningsutjämning för mer information)

Infrastruktur för kryptering med öppen nyckel

De flesta organisationer kräver idag att nätverkstrafik, särskilt trafik som innehåller känsliga data som hur servrar är konfigurerade, måste valideras och/eller krypteras under överföringen. Även om det är möjligt att distribuera en pull-server med HTTP som underlättar klientbegäranden i klartext, är det bästa praxis att skydda trafik med HTTPS. Tjänsten kan konfigureras för att använda HTTPS med hjälp av en uppsättning parametrar i DSC-resursen xPSDesiredStateConfiguration.

Certifikatkraven för att skydda HTTPS-trafik för pull-servern skiljer sig inte från att skydda andra HTTPS-webbplatser. Webbservermallen i en Windows Server Certificate Services uppfyller de funktioner som krävs.

Planeringsuppgift

  • Om begäran om intyg inte sker automatiskt, vem ska du kontakta för att begära intyg?
  • Vad är den genomsnittliga handläggningstiden för begäran?
  • Hur kommer certifikatfilen att överföras till dig?
  • Hur kommer certifikatets privata nyckel att överföras till dig?
  • Hur lång är standardförfallotiden?
  • Har du bestämt dig för ett DNS-namn för pull-servermiljön som du kan använda för certifikatnamnet?

Att välja en arkitektur

En pull-server kan distribueras med hjälp av antingen en webbtjänst som finns på IIS eller en SMB-filresurs. I de flesta situationer ger webbtjänstalternativet större flexibilitet. Det är inte ovanligt att HTTPS-trafik passerar nätverksgränser, medan SMB-trafik ofta filtreras eller blockeras mellan nätverk. Webbtjänsten erbjuder också möjligheten att inkludera en Conformance Server eller Web Reporting Manager (båda ämnena kommer att behandlas i en framtida version av det här dokumentet) som tillhandahåller en mekanism för klienter att rapportera status tillbaka till en server för centraliserad synlighet. SMB är ett alternativ för miljöer där principen dikterar att en webbserver inte ska användas och för andra miljökrav som gör en webbserverroll oönskad. I båda fallen bör du komma ihåg att utvärdera kraven för signering och kryptering av trafik. HTTPS, SMB-signering och IPSEC-policyer är alla alternativ som är värda att överväga.

Belastningsutjämning

Klienter som interagerar med webbtjänsten gör en begäran om information som returneras i ett enda svar. Inga sekventiella begäranden krävs, så det är inte nödvändigt för lastbalanseringsplattformen att säkerställa att sessioner upprätthålls på en enda server vid någon tidpunkt.

Planeringsuppgift

  • Vilken lösning kommer att användas för belastningsutjämning av trafik mellan servrar?
  • Om du använder en maskinvarulastbalanserare, vem tar emot en begäran om att lägga till en ny konfiguration på enheten?
  • Vad är den genomsnittliga handläggningstiden för en begäran om att konfigurera en ny belastningsutjämnad webbtjänst?
  • Vilken information kommer att krävas för begäran?
  • Kommer du att behöva begära en ytterligare IP-adress eller kommer teamet som ansvarar för lastbalansering att hantera det?
  • Har du de DNS-poster som behövs och kommer detta att krävas av teamet som ansvarar för att konfigurera lastbalanseringslösningen?
  • Kräver lastbalanseringslösningen att PKI hanteras av enheten eller kan den belastningsutjämna HTTPS-trafik så länge det inte finns några sessionskrav?

Mellanlagring av konfigurationer och moduler på pull-servern

Som en del av konfigurationsplaneringen måste du tänka på vilka DSC-moduler och konfigurationer som ska hanteras av pull-servern. För konfigurationsplanering är det viktigt att ha en grundläggande förståelse för hur man förbereder och distribuerar innehåll till en pull-server.

I framtiden kommer det här avsnittet att utökas och ingå i en driftguide för DSC Pull Server. Guiden kommer att diskutera den dagliga processen för att hantera moduler och konfigurationer över tid med automatisering.

DSC-moduler

Klienter som begär en konfiguration behöver de DSC-moduler som krävs. En funktion i pull-servern är att automatisera distributionen på begäran av DSC-moduler till klienter. Om du distribuerar en pull-server för första gången, kanske som ett labb eller konceptbevis, kommer du förmodligen att vara beroende av DSC-moduler som är tillgängliga från offentliga lagringsplatser, till exempel PowerShell-galleriet eller de PowerShell.org GitHub-lagringsplatserna för DSC-moduler.

Det är viktigt att komma ihåg att även för betrodda onlinekällor, till exempel PowerShell-galleriet, bör alla moduler som laddas ned från en offentlig lagringsplats granskas av någon med PowerShell-erfarenhet och kunskap om miljön där modulerna kommer att användas innan de används i produktion. När du slutför den här uppgiften är det ett bra tillfälle att kontrollera om det finns ytterligare nyttolast i modulen som kan tas bort, till exempel dokumentation och exempelskript. Detta kommer att minska nätverksbandbredden per klient i deras första begäran, när moduler kommer att laddas ner över nätverket från server till klient.

Varje modul måste paketeras i ett visst format, en ZIP-fil med namnet ModuleName_Version.zip som innehåller modulens nyttolast. När filen har kopierats till servern måste en kontrollsummafil skapas. När klienter ansluter till servern används kontrollsumman för att verifiera att innehållet i DSC-modulen inte har ändrats sedan den publicerades.

New-DscChecksum -ConfigurationPath .\ -OutPath .\

Planeringsuppgift

  • Om du planerar en test- eller labbmiljö, vilka scenarier är viktiga att validera?
  • Finns det offentligt tillgängliga moduler som innehåller resurser för att täcka allt du behöver eller kommer du att behöva skapa dina egna resurser?
  • Kommer din miljö att ha Internetåtkomst för att hämta offentliga moduler?
  • Vem kommer att ansvara för att granska DSC-moduler?
  • Om du planerar en produktionsmiljö, vad kommer du att använda som ett lokalt repository för lagring av DSC-moduler?
  • Kommer ett centralt team att acceptera DSC-moduler från programteam? Hur kommer processen att se ut?
  • Kommer du att automatisera paketering, kopiering och skapande av en kontrollsumma för produktionsklara DSC-moduler till servern från källlagringsplatsen?
  • Kommer ditt team också att ansvara för att hantera automationsplattformen?

DSC-konfigurationer

Syftet med en pull-server är att tillhandahålla en centraliserad mekanism för att distribuera DSC-konfigurationer till klientnoder. Konfigurationerna lagras på servern som MOF-dokument. Varje dokument namnges med ett unikt Guid. När klienter konfigureras för att ansluta till en pull-server får de också GUID för den konfiguration som de ska begära. Det här systemet med att referera till konfigurationer av Guid garanterar global unikhet och är flexibelt så att en konfiguration kan tillämpas med kornighet per nod, eller som en rollkonfiguration som sträcker sig över många servrar som ska ha identiska konfigurationer.

Guid

Det är värt ytterligare uppmärksamhet att planera för konfigurations-Guid när du tänker igenom en pull-serverdistribution. Det finns inga specifika krav på hur guid ska hanteras och processen är sannolikt unik för varje miljö. Processen kan sträcka sig från enkel till komplex: en centralt lagrad CSV-fil, en enkel SQL-tabell, en CMDB eller en komplex lösning som kräver integration med ett annat verktyg eller programvarulösning. Det finns två allmänna metoder:

  • Tilldela guid per server – Ger ett mått på säkerhet för att varje serverkonfiguration styrs individuellt. Detta ger en nivå av precision kring uppdateringar och kan fungera bra i miljöer med få servrar.

  • Tilldela guid per serverroll – Alla servrar som utför samma funktion, till exempel webbservrar, använder samma GUID för att referera till nödvändiga konfigurationsdata. Tänk på att om många servrar delar samma GUID uppdateras alla samtidigt när konfigurationen ändras.

    GUID är något som bör betraktas som känsliga data eftersom det kan utnyttjas av någon med ont uppsåt för att få information om hur servrar distribueras och konfigureras i din miljö. Mer information finns i Säker allokering av guid i PowerShell Desired State Configuration Pull Mode.

Planeringsuppgift

  • Vem kommer att ansvara för att kopiera konfigurationer till pull-servermappen när de är klara?
  • Om konfigurationer har skapats av ett programteam, hur ser processen ut för att lämna över dem?
  • Kommer du att använda en lagringsplats för att lagra konfigurationer när de skapas, mellan team?
  • Kommer du att automatisera processen med att kopiera konfigurationer till servern och skapa en kontrollsumma när de är klara?
  • Hur mappar du Guid till servrar eller roller, och var kommer detta att lagras?
  • Vad kommer du att använda som en process för att konfigurera klientdatorer och hur kommer den att integreras med din process för att skapa och lagra konfigurations-guid?

Installationsguide

Skript som ges i det här dokumentet är stabila exempel. Granska alltid skript noggrant innan du kör dem i en produktionsmiljö.

Förutsättningar

Använd följande kommando för att verifiera versionen av PowerShell på servern.

$PSVersionTable.PSVersion

Uppgradera om möjligt till den senaste versionen av Windows Management Framework. Ladda sedan ned modulen xPsDesiredStateConfiguration med följande kommando.

Install-Module xPSDesiredStateConfiguration

Kommandot kommer att be om ditt godkännande innan du laddar ner modulen.

Installations- och konfigurationsskript

Den bästa metoden för att distribuera en DSC-pullserver är att använda ett DSC-konfigurationsskript. Det här dokumentet visar skript som innehåller både grundläggande inställningar som endast konfigurerar DSC-webbtjänsten och avancerade inställningar som konfigurerar en Windows Server från slutpunkt till slutpunkt, inklusive DSC-webbtjänsten.

Notera: För närvarande kräver DSC-modulen xPSDesiredStateConfiguration att servern är EN-US språk.

Grundläggande konfiguration för 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\'

Avancerad konfiguration för 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'

Verifiera pull-serverns funktioner

# 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

Konfigurera klienter

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

Ytterligare referenser, kodfragment och exempel

Det här exemplet visar hur du manuellt initierar en klientanslutning (kräver WMF5) för testning.

Update-DscConfiguration -Wait -Verbose

Cmdleten Add-DnsServerResourceRecordName används för att lägga till en CNAME-post av typen i en DNS-zon.

PowerShell-funktionen för att skapa en kontrollsumma och publicera DSC MOF till SMB Pull-servern genererar automatiskt den kontrollsumma som krävs och kopierar sedan både MOF-konfigurations- och kontrollsummafilerna till SMB-pullservern.

Bilaga – Förstå datafiltyper för ODATA-tjänsten

En datafil lagras för att skapa information under distributionen av en pull-server som innehåller OData-webbtjänsten. Typen av fil beror på operativsystemet, enligt beskrivningen nedan.

  • Windows Server 2012 – Filtypen kommer alltid att vara .mdb
  • Windows Server 2012 R2 – Filtypen är .edb som standard om inte a .mdb anges i konfigurationen

I det avancerade exempelskriptet för att installera en pull-server hittar du också ett exempel på web.config hur du automatiskt styr filinställningarna för att förhindra risk för fel som orsakas av filtyp.