Dela via

Metodtips för hämtningsservern

  • Artikel

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

Viktigt

Pull Server (Windows Feature DSC-Service) är en komponent som stöds i 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. Information bör tillhandahålla metodtips som identifieras av kunder och sedan valideras av produktteamet för att säkerställa att rekommendationerna är framtida och anses vara stabila.

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

Sammanfattning

Det här dokumentet är utformat för att ge officiell vägledning för alla som planerar för en Windows PowerShell Desired State Configuration hämtningsserverimplementering. En hämtningsserver är en enkel tjänst som bara ska ta några minuter att distribuera. Även om det här dokumentet ger teknisk vägledning som kan användas i en distribution, är värdet av det här dokumentet 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 Windows PowerShell Desired State Configuration Översikt. Eftersom DSC förväntas utvecklas i molntakt förväntas även den underliggande tekniken, inklusive hämtningsservern, 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 framtida lösningar för att uppmuntra framåtblickande design.

De två huvudavsnitten i det här dokumentet:

  • Konfigurationsplanering
  • Installationsguide

Versioner av Windows Management Framework

Informationen i det här dokumentet är avsedd att gälla för Windows Management Framework 5.0. Även om WMF 5.0 inte krävs för att distribuera och använda en hämtningsserver är version 5.0 i fokus för det här dokumentet.

Windows PowerShell Desired State Configuration

Desired State Configuration (DSC) är en hanteringsplattform som gör det möjligt att distribuera och hantera konfigurationsdata med hjälp av en branschsyntax med namnet MOF (Managed Object Format) för att beskriva CIM (Common Information Model). Ett öppen källkod projekt, Open Management Infrastructure (OMI), finns för att ytterligare utveckla dessa standarder på 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.

Hämtningsserverroll

En hämtningsserver tillhandahåller en centraliserad tjänst för lagring av konfigurationer som är tillgängliga för målnoder.

Hämtningsserverrollen 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 bekräftelse av lyckad eller misslyckad 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) för att peka på hämtningsservern hämtas och tillämpas de senaste konfigurationsdata och eventuella skript som krävs. Detta kan inträffa som en engångsdistribution eller som ett återkommande jobb, vilket också gör hämtningsservern till en viktig tillgång för att hantera ändringar i stor skala. Mer information finns i Push- och Pull-konfigurationslägen.

Konfigurationsplanering

För all distribution av företagsprogram finns det information som kan samlas in i förväg för att planera för rätt arkitektur och förberedas för de steg som krävs för att slutföra distributionen. Följande avsnitt innehåller information om hur du förbereder och de organisationsanslutningar som sannolikt kommer att behöva ske i förväg.

Programvarukrav

Distribution av en hämtningsserver kräver DSC-tjänstfunktionen i Windows Server. Den här funktionen introducerades i Windows Server 2012 och har uppdaterats via 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-hämtningsserver: Den senaste versionen av Windows Management Framework och en DSC-modul för att automatisera etableringen av hämtningsservrar.

DSC-resurs

Du kan förenkla distributionen av en pull-server 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 produktionsklar servernod. 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 till:

C:\Program Files\Windows PowerShell\Modules

Planeringsaktivitet

  • Har du åtkomst 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 när du har installerat operativsystemet?
  • Kommer miljön att ha Internetåtkomst för att hämta uppdateringar, eller kommer den att ha en lokal Windows Server Update Services -server (WSUS)?
  • Har du åtkomst till Windows Server-installationsfiler som redan innehåller uppdateringar via offlineinmatning?

Maskinvarukrav

Distributioner av pull-servrar stöds på både fysiska och virtuella servrar. Storlekskraven för hämtningsservern ö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-kort

Planeringsaktivitet

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

Konton

Det finns inga tjänstkontokrav för att distribuera en instans av en hämtningsserver. 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 enheten 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 för att fungera med en hämtningsservermiljö. I testmiljöer används vanligtvis serverns värdnamn, eller så kan IP-adressen för servern användas om DNS-namnmatchning inte är tillgänglig. I produktionsmiljöer eller i en labbmiljö som är avsedd att representera en produktionsdistribution är bästa praxis att skapa en DNS CNAME-post.

Med ett DNS CNAME kan du skapa ett alias för att referera till din värdpost (A). Avsikten med den ytterligare 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 hämtningsserver eller lägga till ytterligare hämtningsservrar, inte kräver någon motsvarande ändring av klientkonfigurationen.

Tänk på lösningsarkitekturen när du väljer ett namn för DNS-posten. 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 lämpar sig 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 av enskild nod – Skapa en DNS CNAME-post som pekar på serverns värdnamn.

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

Planeringsaktivitet

  • Vet du vem du ska kontakta för att skapa och ändra DNS-poster?
  • Vad är den genomsnittliga vändningen för en begäran om en DNS-post?
  • Behöver du begära statiska värdnamnsposter (A) för servrar?
  • Vad begär du som CNAME?
  • Vilken typ av lösning för belastningsutjämning kommer du att använda om det behövs? (se avsnittet Belastningsutjämning för mer information)

Infrastruktur för offentliga nycklar

De flesta organisationer kräver idag att nätverkstrafik, särskilt trafik som innehåller så känsliga data som hur servrar konfigureras, måste verifieras 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 någon annan HTTPS-webbplats. Webbservermallen i en Windows Server Certificate Services uppfyller de nödvändiga funktionerna.

Planeringsaktivitet

  • Om certifikatbegäranden inte är automatiserade, vem behöver du kontakta för att begära ett certifikat?
  • Vilken är den genomsnittliga vändningen för begäran?
  • Hur överförs certifikatfilen till dig?
  • Hur överförs den privata certifikatnyckeln till dig?
  • Hur lång är standardtiden för förfallotid?
  • Har du fastställt ett DNS-namn för pull-servermiljön som du kan använda för certifikatnamnet?

Välja en arkitektur

En pull-server kan distribueras med antingen en webbtjänst som finns på IIS eller en SMB-filresurs. I de flesta fall 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 överensstämmelseserver eller webbrapporteringshanterare (båda ämnena som ska behandlas i en framtida version av det här dokumentet) som ger 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 föreskriver 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-signerings- och IPSEC-principer är alla alternativ som är värda att överväga.

Belastningsutjämning

Klienter som interagerar med webbtjänsten begär information som returneras i ett enda svar. Inga sekventiella begäranden krävs, så det är inte nödvändigt för belastningsutjämningsplattformen att se till att sessioner underhålls på en enskild server när som helst.

Planeringsaktivitet

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

Mellanlagringskonfigurationer och moduler på pull-servern

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

I framtiden kommer det här avsnittet att utökas och inkluderas i en driftsguide för DSC-hämtningsservern. Guiden beskriver den dagliga processen för att hantera moduler och konfigurationer över tid med automatisering.

DSC-moduler

Klienter som begär en konfiguration behöver nödvändiga DSC-moduler. En funktion hos 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 PowerShell.org GitHub-lagringsplatser för DSC-moduler.

Det är viktigt att komma ihåg att även för betrodda onlinekällor som 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 ska användas innan de används i produktion. När du slutför den här uppgiften är det ett bra tillfälle att söka efter ytterligare nyttolaster i modulen som kan tas bort, till exempel dokumentation och exempelskript. Detta minskar nätverksbandbredden per klient i deras första begäran, när moduler laddas ned via 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 modulnyttolasten. 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 .\

Planeringsaktivitet

  • Vilka scenarier är viktiga för att verifiera om du planerar en test- eller labbmiljö?
  • Finns det offentligt tillgängliga moduler som innehåller resurser för att täcka allt du behöver eller behöver du skapa egna resurser?
  • Kommer din miljö att ha Internetåtkomst för att hämta offentliga moduler?
  • Vem ansvarar för att granska DSC-moduler?
  • Om du planerar en produktionsmiljö, vad ska du använda som en lokal lagringsplats 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 skapa 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 har konfigurerats för att ansluta till en pull-server får de även guid för den konfiguration som de ska begära. Det här systemet med referenskonfigurationer från Guid garanterar global unikhet och är flexibelt så att en konfiguration kan tillämpas med kornighet per nod eller som en rollkonfiguration som omfattar många servrar som ska ha identiska konfigurationer.

Guid

Att planera för konfigurations-Guids är värt ytterligare uppmärksamhet när du tänker igenom en pull-serverdistribution. Det finns inget specifikt krav på hur guid-hanteringen ska hanteras och processen kommer sannolikt att vara unik för varje miljö. Processen kan variera från enkel till komplex: en centralt lagrad CSV-fil, en enkel SQL-tabell, en CMDB eller en komplex lösning som kräver integrering med ett annat verktyg eller en annan programvarulösning. Det finns två allmänna metoder:

  • Tilldela GUID per server – Ger ett mått på att varje serverkonfiguration styrs individuellt. Detta ger en precisionsnivå 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 användas av någon med skadlig avsikt för att få information om hur servrar distribueras och konfigureras i din miljö. Mer information finns i Allokera guids på ett säkert sätt i PowerShell Desired State Configuration pull-läge.

Planeringsaktivitet

  • Vem ansvarar för att kopiera konfigurationer till pull-servermappen när de är klara?
  • Vad är processen för att lämna över dem om konfigurationer har skapats av ett programteam?
  • Kommer du att använda en lagringsplats för att lagra konfigurationer när de redigeras i olika team?
  • Kommer du att automatisera processen med att kopiera konfigurationer till servern och skapa en kontrollsumma när de är klara?
  • Hur kommer du att mappa guids 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: er?

Installationsguide

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

Förutsättningar

Kontrollera versionen av PowerShell på servern med hjälp av följande kommando.

$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 ber om ditt godkännande innan du laddar ned modulen.

Installations- och konfigurationsskript

Den bästa metoden för att distribuera en DSC-hämtningsserver är att använda ett DSC-konfigurationsskript. Det här dokumentet innehåller 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.

Obs! För närvarande xPSDesiredStateConfiguration kräver DSC-modulen att servern är en-US-språkvariant.

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-serverfunktioner

# 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-typpost i en DNS-zon.

PowerShell-funktionen för att skapa en kontrollsumma och publicera DSC MOF till SMB-pullservern genererar automatiskt den nödvändiga kontrollsumman och kopierar sedan både MOF-konfigurations- och kontrollsummafilerna till SMB-hämtningsservern.

Bilaga – Förstå filtyper för ODATA-tjänstdata

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

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

I advanced example script for installing a Pull Server ( Avancerat exempelskript för installation av en pull-server) hittar du också ett exempel på hur du automatiskt kontrollerar web.config filinställningarna för att förhindra eventuella fel som orsakas av filtypen.