Best Practices für Pullserver

Gilt für: Windows PowerShell 4.0, Windows PowerShell 5.0

Zusammenfassung: Dieses Dokument soll Prozesse und Erweiterbarkeit enthalten, um Ingenieure bei der Vorbereitung der Lösung zu unterstützen. Die Details sollten Best Practices enthalten, die von Kunden identifiziert und dann vom Produktteam validiert wurden, um sicherzustellen, dass die Empfehlungen zukunftsorientiert sind und als stabil gelten.

• Autor: Michael Greene
• Rezensenten: Ben Gelens, Ravikanth Chaganti, Aleksandar Nikolic
• Veröffentlicht: April, 2015

Zusammenfassung

Dieses Dokument soll eine offizielle Anleitung für alle Benutzer bereitstellen, die eine Implementierung eines Windows PowerShell-Pullservers für die Konfiguration des gewünschten Zustands planen. Ein Pullserver ist ein einfacher Dienst, dessen Bereitstellung nur wenige Minuten dauern sollte. Obwohl dieses Dokument technische Anleitungen enthält, die in einer Bereitstellung verwendet werden können, dient dieses Dokument als Referenz für bewährte Methoden und darüber, was vor der Bereitstellung zu beachten ist. Die Leser sollten mit DSC und den Begriffen, die zur Beschreibung der Komponenten verwendet werden, die in einer DSC-Bereitstellung enthalten sind, vertraut sein. Weitere Informationen finden Sie im Thema Übersicht über die Windows PowerShell-Konfiguration des gewünschten Zustands . Da DSC sich voraussichtlich im Cloud-Rhythmus weiterentwickeln wird, wird erwartet, dass sich auch die zugrunde liegende Technologie, einschließlich des Pull-Servers, weiterentwickelt und neue Funktionen einführt. Dieses Dokument enthält eine Versionstabelle im Anhang, die Verweise auf frühere Versionen und Verweise auf zukunftsorientierte Lösungen enthält, um zukunftsorientierte Designs zu fördern.

Die beiden Hauptabschnitte dieses Dokuments:

• Konfigurationsplanung
• Installationsanleitung

Versionen des Windows Management Framework

Die Informationen in diesem Dokument gelten für Windows Management Framework 5.0. Während WMF 5.0 für die Bereitstellung und den Betrieb eines Pull-Servers nicht erforderlich ist, steht Version 5.0 im Mittelpunkt dieses Dokuments.

Windows PowerShell-Konfiguration des gewünschten Zustands

Desired State Configuration (DSC) ist eine Verwaltungsplattform, die das Bereitstellen und Verwalten von Konfigurationsdaten ermöglicht, indem eine branchenspezifische Syntax namens Managed Object Format (MOF) verwendet wird, um das Common Information Model (CIM) zu beschreiben. Ein Open-Source-Projekt, Open Management Infrastructure (OMI), existiert, um diese Standards plattformübergreifend weiterzuentwickeln, einschließlich Linux und Netzwerkhardware-Betriebssystemen. Weitere Informationen finden Sie auf der DMTF-Seite, auf der auf MOF-Spezifikationen verlinkt ist, und unter OMI-Dokumente und -Quelle.

Windows PowerShell stellt eine Reihe von Spracherweiterungen für die Konfiguration des gewünschten Zustands bereit, die Sie zum Erstellen und Verwalten deklarativer Konfigurationen verwenden können.

Pull-Server-Rolle

Ein Pullserver stellt einen zentralisierten Dienst zum Speichern von Konfigurationen bereit, auf die Zielknoten zugreifen können.

Die Pullserverrolle kann entweder als Webserverinstanz oder als SMB-Dateifreigabe bereitgestellt werden. Die Webserverfunktion umfasst eine OData-Schnittstelle und kann optional Funktionen für Zielknoten enthalten, um die Bestätigung von Erfolg oder Fehler beim Anwenden von Konfigurationen zurückzumelden. Diese Funktion ist nützlich in Umgebungen mit einer großen Anzahl von Zielknoten. Nach der Konfiguration eines Zielknotens (auch als Client bezeichnet), der auf den Pullserver verweist, werden die neuesten Konfigurationsdaten und alle erforderlichen Skripts heruntergeladen und angewendet. Dies kann als einmalige Bereitstellung oder als wiederkehrender Auftrag erfolgen, was den Pullserver auch zu einer wichtigen Ressource für die Verwaltung von Änderungen in großem Maßstab macht. Weitere Informationen finden Sie unter Push- und Pull-Konfigurationsmodi.

Konfigurationsplanung

Für jede Bereitstellung von Unternehmenssoftware gibt es Informationen, die im Voraus gesammelt werden können, um die richtige Architektur zu planen und auf die Schritte vorbereitet zu sein, die zum Abschließen der Bereitstellung erforderlich sind. In den folgenden Abschnitten finden Sie Informationen zur Vorbereitung und zu den organisatorischen Verbindungen, die voraussichtlich im Vorfeld erfolgen müssen.

Softwareanforderungen

Für die Bereitstellung eines Pullservers ist das DSC-Dienstfeature von Windows Server erforderlich. Dieses Feature wurde in Windows Server 2012 eingeführt und durch fortlaufende Versionen von Windows Management Framework (WMF) aktualisiert.

Software-Downloads

Zusätzlich zur Installation der neuesten Inhalte von Windows Update gibt es zwei Downloads, die als bewährte Methode zum Bereitstellen eines DSC-Pullservers gelten: Die neueste Version von Windows Management Framework und ein DSC-Modul zum Automatisieren der Bereitstellung von Pullservern.

DSC-Ressource

Eine Pullserverbereitstellung kann vereinfacht werden, indem der Dienst mithilfe eines DSC-Konfigurationsskripts bereitgestellt wird. Dieses Dokument enthält Konfigurationsskripts, die zum Bereitstellen eines produktionsbereiten Serverknotens verwendet werden können. Um die Konfigurationsskripts verwenden zu können, ist ein DSC-Modul erforderlich, das nicht in Windows Server enthalten ist. Der erforderliche Modulname lautet xPSDesiredStateConfiguration, der die DSC-Ressource xDscWebService enthält. Das xPSDesiredStateConfiguration-Modul kann aus dem PowerShell-Katalog heruntergeladen werden.

Verwenden Sie das Install-Module Cmdlet aus dem PowerShellGet-Modul .

Install-Module xPSDesiredStateConfiguration

Das PowerShellGet-Modul lädt das Modul herunter, um:

C:\Program Files\Windows PowerShell\Modules

Planungsaufgabe

• Haben Sie Zugriff auf die Installationsdateien für Windows Server 2012 R2?
• Verfügt die Bereitstellungsumgebung über einen Internetzugang, um WMF und das Modul aus der Online-Galerie herunterzuladen?
• Wie werden die neuesten Sicherheitsupdates nach der Installation des Betriebssystems installiert?
• Verfügt die Umgebung über Internetzugriff zum Abrufen von Updates, oder verfügt sie über einen lokalen WSUS-Server (Windows Server Update Services)?
• Haben Sie Zugriff auf Windows Server-Installationsdateien, die bereits Updates durch Offlineinjektion enthalten?

Hardwareanforderungen

Pullserverbereitstellungen werden sowohl auf physischen als auch auf virtuellen Servern unterstützt. Die Größenanforderungen für Pullserver entsprechen den Anforderungen für Windows Server 2012 R2.

• CPU: 1,4 GHz 64-Bit-Prozessor
• Arbeitsspeicher: 512 MB
• Speicherplatz: 32 GB
• Netzwerk: Gigabit-Ethernet-Adapter

Planungsaufgabe

• Wird die Bereitstellung auf physischer Hardware oder auf einer Virtualisierungsplattform durchgeführt?
• Wie läuft der Prozess ab, um einen neuen Server für Ihre Zielumgebung anzufordern?
• Wie lange dauert es durchschnittlich, bis ein Server verfügbar ist?
• Welche Servergröße werden Sie anfordern?

Accounts

Es gibt keine Anforderungen an ein Dienstkonto für die Bereitstellung einer Pullserverinstanz. Es gibt jedoch Szenarien, in denen die Website im Kontext eines lokalen Benutzerkontos ausgeführt werden kann. Wenn z. B. auf eine Speicherfreigabe für Websiteinhalte zugegriffen werden muss und entweder der Windows Server oder das Gerät, auf dem die Speicherfreigabe gehostet wird, nicht in die Domäne eingebunden sind.

DNS-Einträge

Sie benötigen einen Servernamen, den Sie verwenden müssen, wenn Sie Clients für die Arbeit mit einer Pullserverumgebung konfigurieren. In Testumgebungen wird in der Regel der Hostname des Servers verwendet, oder die IP-Adresse für den Server kann verwendet werden, wenn die DNS-Namensauflösung nicht verfügbar ist. In Produktionsumgebungen oder in einer Lab-Umgebung, die eine Produktionsbereitstellung darstellen soll, besteht die bewährte Methode darin, einen DNS-CNAME-Eintrag zu erstellen.

Mit einem DNS-CNAME können Sie einen Alias erstellen, der auf Ihren Hosteintrag (A) verweist. Der zusätzliche Namenseintrag soll die Flexibilität erhöhen, falls in Zukunft eine Änderung erforderlich sein sollte. Ein CNAME kann dabei helfen, die Clientkonfiguration zu isolieren, sodass Änderungen an der Serverumgebung, z. B. das Ersetzen eines Pullservers oder das Hinzufügen zusätzlicher Pullserver, keine entsprechende Änderung an der Clientkonfiguration erfordern.

Berücksichtigen Sie bei der Auswahl eines Namens für den DNS-Eintrag die Lösungsarchitektur. Wenn Sie den Lastenausgleich verwenden, muss das Zertifikat, das zum Sichern des Datenverkehrs über HTTPS verwendet wird, denselben Namen wie der DNS-Eintrag haben.

Best Practices für Szenarien

• Testumgebung: Reproduzieren Sie nach Möglichkeit die geplante Produktionsumgebung. Ein Server-Hostname eignet sich für einfache Konfigurationen. Wenn DNS nicht verfügbar ist, kann eine IP-Adresse anstelle eines Hostnamens verwendet werden.
• Single Node Deployment: Erstellen Sie einen DNS-CNAME-Eintrag, der auf den Hostnamen des Servers verweist.

Weitere Informationen finden Sie unter Konfigurieren von DNS-Roundrobin in Windows Server.

Planungsaufgabe

• Wissen Sie, an wen Sie sich wenden müssen, um DNS-Einträge erstellen und ändern zu lassen?
• Wie hoch ist die durchschnittliche Bearbeitungszeit für eine Anforderung eines DNS-Eintrags?
• Müssen Sie statische Hostname-Einträge (A) für Server anfordern?
• Was werden Sie als CNAME anfordern?
• Welche Art von Load-Balancing-Lösung werden Sie bei Bedarf verwenden? (siehe Abschnitt Load Balancing für Details)

Public-Key-Infrastruktur

Die meisten Unternehmen verlangen heute, dass der Netzwerkverkehr, insbesondere der Datenverkehr, der so sensible Daten wie die Konfiguration von Servern enthält, während der Übertragung validiert und/oder verschlüsselt werden muss. Es ist zwar möglich, einen Pull-Server über HTTP bereitzustellen, der Client-Anfragen im Klartext erleichtert, aber es ist eine bewährte Methode, den Datenverkehr über HTTPS zu sichern. Der Dienst kann mithilfe einer Reihe von Parametern in der DSC-Ressource xPSDesiredStateConfiguration für die Verwendung von HTTPS konfiguriert werden.

Die Zertifikatanforderungen zum Sichern des HTTPS-Datenverkehrs für den Pullserver unterscheiden sich nicht von denen anderer HTTPS-Websites. Die Webservervorlage in den Windows Server-Zertifikatdiensten erfüllt die erforderlichen Funktionen.

Planungsaufgabe

• Wenn Zertifikatsanträge nicht automatisiert sind, an wen müssen Sie sich wenden, um ein Zertifikat anzufordern?
• Wie hoch ist die durchschnittliche Bearbeitungszeit für die Anfrage?
• Wie wird die Zertifikatsdatei an Sie übertragen?
• Wie wird der private Schlüssel des Zertifikats an Sie übertragen?
• Wie lange ist die standardmäßige Ablaufzeit?
• Haben Sie sich für einen DNS-Namen für die Pullserver-Umgebung entschieden, den Sie für den Zertifikatsnamen verwenden können?

Auswahl einer Architektur

Ein Pullserver kann entweder mit einem Webdienst bereitgestellt werden, der auf IIS gehostet wird, oder mit einer SMB-Dateifreigabe. In den meisten Fällen bietet die Webservice-Option eine größere Flexibilität. Es ist nicht ungewöhnlich, dass HTTPS-Datenverkehr Netzwerkgrenzen überschreitet, während SMB-Datenverkehr häufig zwischen Netzwerken gefiltert oder blockiert wird. Der Webdienst bietet auch die Möglichkeit, einen Conformance Server oder Web Reporting Manager einzubinden (beides Themen, die in einer zukünftigen Version dieses Dokuments behandelt werden), die einen Mechanismus für Clients bereitstellen, um den Status für eine zentralisierte Sichtbarkeit an einen Server zurückzumelden. SMB bietet eine Option für Umgebungen, in denen die Richtlinie vorschreibt, dass ein Webserver nicht verwendet werden sollte, und für andere Umgebungsanforderungen, die eine Webserverrolle unerwünscht machen. Denken Sie in jedem Fall daran, die Anforderungen für das Signieren und Verschlüsseln des Datenverkehrs zu bewerten. HTTPS, SMB-Signierung und IPSEC-Richtlinien sind Optionen, die eine Überlegung wert sind.

Lastverteilung

Clients, die mit dem Webdienst interagieren, stellen eine Anforderung von Informationen, die in einer einzigen Antwort zurückgegeben werden. Es sind keine sequenziellen Anforderungen erforderlich, sodass die Lastausgleichsplattform nicht sicherstellen muss, dass die Sitzungen zu jedem Zeitpunkt auf einem einzigen Server verwaltet werden.

Planungsaufgabe

• Welche Lösung wird für den Lastenausgleich des Datenverkehrs zwischen Servern verwendet?
• Wenn Sie einen Hardware-Lastenausgleich verwenden, wer nimmt eine Anforderung zum Hinzufügen einer neuen Konfiguration zum Gerät entgegen?
• Wie hoch ist die durchschnittliche Bearbeitungszeit für eine Anforderung zum Konfigurieren eines neuen Webdiensts mit Lastenausgleich?
• Welche Informationen werden für die Anfrage benötigt?
• Müssen Sie eine zusätzliche IP anfordern oder kümmert sich das für den Lastausgleich zuständige Team darum?
• Verfügen Sie über die erforderlichen DNS-Einträge, und wird dies von dem Team benötigt, das für die Konfiguration der Lastausgleichslösung verantwortlich ist?
• Erfordert die Lastenausgleichslösung, dass die PKI vom Gerät verarbeitet wird, oder kann sie einen Lastenausgleich für HTTPS-Datenverkehr durchführen, solange keine Sitzungsanforderungen vorhanden sind?

Bereitstellen von Konfigurationen und Modulen auf dem Pullserver

Im Rahmen der Konfigurationsplanung müssen Sie darüber nachdenken, welche DSC-Module und -Konfigurationen vom Pullserver gehostet werden. Für die Konfigurationsplanung ist es wichtig, ein grundlegendes Verständnis dafür zu haben, wie Inhalte auf einem Pullserver vorbereitet und bereitgestellt werden.

In Zukunft wird dieser Abschnitt erweitert und in einen Betriebsleitfaden für DSC Pull Server aufgenommen. In dem Leitfaden wird der tägliche Prozess für die Verwaltung von Modulen und Konfigurationen im Laufe der Zeit mit Automatisierung erläutert.

DSC-Module

Clients, die eine Konfiguration anfordern, benötigen die erforderlichen DSC-Module. Eine Funktion des Pullservers besteht darin, die Verteilung von DSC-Modulen an Clients bei Bedarf zu automatisieren. Wenn Sie zum ersten Mal einen Pullserver bereitstellen, z. B. als Labor oder Proof of Concept, sind Sie wahrscheinlich auf DSC-Module angewiesen, die in öffentlichen Repositorys wie dem PowerShell-Katalog oder den PowerShell.org GitHub-Repositorys für DSC-Module verfügbar sind.

Es ist wichtig, sich daran zu erinnern, dass selbst für vertrauenswürdige Onlinequellen wie den PowerShell-Katalog jedes Modul, das aus einem öffentlichen Repository heruntergeladen wird, von jemandem überprüft werden sollte, der über PowerShell-Erfahrung und Kenntnisse der Umgebung verfügt, in der die Module verwendet werden, bevor sie in der Produktion verwendet werden. Während des Abschließens dieser Aufgabe ist es ein guter Zeitpunkt, um nach zusätzlicher Nutzlast im Modul zu suchen, die entfernt werden kann, z. B. Dokumentation und Beispielskripts. Dadurch wird die Netzwerkbandbreite pro Client bei der ersten Anforderung reduziert, wenn Module über das Netzwerk vom Server auf den Client heruntergeladen werden.

Jedes Modul muss in einem bestimmten Format verpackt sein, einer ZIP-Datei mit dem Namen ModuleName_Version.zip, die die Modulnutzlast enthält. Nachdem die Datei auf den Server kopiert wurde, muss eine Prüfsummendatei erstellt werden. Wenn Clients eine Verbindung mit dem Server herstellen, wird die Prüfsumme verwendet, um zu überprüfen, ob sich der Inhalt des DSC-Moduls seit der Veröffentlichung nicht geändert hat.

New-DscChecksum -ConfigurationPath .\ -OutPath .\

Planungsaufgabe

• Welche Szenarien sollten Sie validieren, wenn Sie eine Test- oder Laborumgebung planen?
• Gibt es öffentlich zugängliche Module, die Ressourcen enthalten, die alles abdecken, was Sie benötigen, oder müssen Sie Ihre eigenen Ressourcen erstellen?
• Verfügt Ihre Umgebung über einen Internetzugang zum Abrufen öffentlicher Module?
• Wer ist für die Überprüfung der DSC-Module verantwortlich?
• Wenn Sie eine Produktionsumgebung planen, was werden Sie als lokales Repository zum Speichern von DSC-Modulen verwenden?
• Akzeptiert ein zentrales Team DSC-Module von Anwendungsteams? Wie wird der Prozess ablaufen?
• Automatisieren Sie das Verpacken, Kopieren und Erstellen einer Prüfsumme für produktionsbereite DSC-Module auf dem Server aus Ihrem Quellrepository?
• Wird Ihr Team auch für die Verwaltung der Automatisierungsplattform verantwortlich sein?

DSC-Konfigurationen

Der Zweck eines Pullservers besteht darin, einen zentralisierten Mechanismus zum Verteilen von DSC-Konfigurationen an Clientknoten bereitzustellen. Die Konfigurationen werden als MOF-Dokumente auf dem Server gespeichert. Jedes Dokument wird mit einer eindeutigen GUID benannt. Wenn Clients für die Verbindung mit einem Pullserver konfiguriert sind, erhalten sie auch die GUID für die Konfiguration, die sie anfordern sollen. Dieses System der Referenzierung von Konfigurationen durch Guid garantiert globale Eindeutigkeit und ist flexibel, sodass eine Konfiguration mit Granularität pro Knoten oder als Rollenkonfiguration angewendet werden kann, die sich über viele Server erstreckt, die identische Konfigurationen aufweisen sollten.

Guids

Die Planung von Konfigurations-GUIDs sollte bei der Planung einer Pullserverbereitstellung besonders beachtet werden. Es gibt keine spezifischen Anforderungen für die Handhabung von GUIDs , und der Prozess ist wahrscheinlich für jede Umgebung einzigartig. Der Prozess kann von einfach bis komplex reichen: eine zentral gespeicherte CSV-Datei, eine einfache SQL-Tabelle, eine CMDB oder eine komplexe Lösung, die eine Integration mit einem anderen Tool oder einer Softwarelösung erfordert. Es gibt zwei allgemeine Ansätze:

• Zuweisen von GUIDs pro Server – Bietet ein gewisses Maß an Sicherheit, dass jede Serverkonfiguration einzeln gesteuert wird. Dies bietet ein gewisses Maß an Präzision bei Updates und kann in Umgebungen mit wenigen Servern gut funktionieren.

• Zuweisen von GUIDs pro Serverrolle – Alle Server, die dieselbe Funktion ausführen, z. B. Webserver, verwenden dieselbe GUID, um auf die erforderlichen Konfigurationsdaten zu verweisen. Beachten Sie, dass, wenn viele Server dieselbe GUID verwenden, alle gleichzeitig aktualisiert werden, wenn sich die Konfiguration ändert.

  Die GUID ist etwas, das als vertrauliche Daten betrachtet werden sollte, da es von jemandem mit böswilliger Absicht genutzt werden könnte, um Informationen darüber zu erhalten, wie Server in Ihrer Umgebung bereitgestellt und konfiguriert werden. Weitere Informationen finden Sie unter Sicheres Zuordnen von GUIDs im PowerShell-Pullmodus für die Konfiguration des gewünschten Zustands.

Planungsaufgabe

• Wer ist für das Kopieren von Konfigurationen in den Pullserverordner verantwortlich, wenn sie fertig sind?
• Wenn Konfigurationen von einem Anwendungsteam erstellt werden, wie sieht der Prozess aus, um sie zu übergeben?
• Werden Sie ein Repository nutzen, um Konfigurationen während der Erstellung teamübergreifend zu speichern?
• Automatisieren Sie das Kopieren von Konfigurationen auf den Server und das Erstellen einer Prüfsumme, wenn sie fertig sind?
• Wie ordnen Sie GUIDs Servern oder Rollen zu, und wo werden diese gespeichert?
• Was wird als Prozess zum Konfigurieren von Clientcomputern verwendet, und wie lässt er sich in Ihren Prozess zum Erstellen und Speichern von Konfigurationsguids integrieren?

Installationsanleitung

Bei den in diesem Dokument angegebenen Skripts handelt es sich um stabile Beispiele. Überprüfen Sie Skripts immer sorgfältig, bevor Sie sie in einer Produktionsumgebung ausführen.

Voraussetzungen

Verwenden Sie den folgenden Befehl, um die Version von PowerShell auf Ihrem Server zu überprüfen.

$PSVersionTable.PSVersion

Führen Sie nach Möglichkeit ein Upgrade auf die neueste Version von Windows Management Framework durch. Laden Sie als Nächstes das xPsDesiredStateConfiguration Modul mit dem folgenden Befehl herunter.

Install-Module xPSDesiredStateConfiguration

Der Befehl fragt Sie nach Ihrer Zustimmung, bevor Sie das Modul herunterladen.

Installations- und Konfigurationsskripte

Die beste Methode zum Bereitstellen eines DSC-Pullservers ist die Verwendung eines DSC-Konfigurationsskripts. In diesem Dokument werden Skripts vorgestellt, die sowohl grundlegende Einstellungen enthalten, mit denen nur der DSC-Webdienst konfiguriert wird, als auch erweiterte Einstellungen, mit denen ein End-to-End-Webdienst mit Windows Server einschließlich DSC konfiguriert wird.

Hinweis: Derzeit erfordert das xPSDesiredStateConfiguration DSC-Modul, dass sich der Server EN-US Gebietsschema befindet.

Grundkonfiguration 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\'

Erweiterte 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 = 'AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00'
            }
        )
    }

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'

Überprüfen der Pullserverfunktionalität

# 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

Konfigurieren von Clients

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

Zusätzliche Verweise, Snippets und Beispiele

In diesem Beispiel wird gezeigt, wie eine Clientverbindung (WMF5 erforderlich) zu Testzwecken manuell initiiert wird.

Update-DscConfiguration -Wait -Verbose

Das Cmdlet Add-DnsServerResourceRecordName wird verwendet, um einer DNS-Zone einen CNAME-Eintrag vom Typ hinzuzufügen.

Die PowerShell-Funktion zum Erstellen einer Prüfsumme und Veröffentlichen von DSC MOF auf dem SMB-Pullserver generiert automatisch die erforderliche Prüfsumme und kopiert dann sowohl die MOF-Konfigurations- als auch die Prüfsummendateien auf den SMB-Pullserver.

Anhang – Grundlegendes zu den Datentypen von ODATA-Dienstdaten

Eine Datendatei wird gespeichert, um Informationen während der Bereitstellung eines Pullservers zu erstellen, der den OData-Webdienst enthält. Der Dateityp hängt vom Betriebssystem ab, wie unten beschrieben.

• Windows Server 2012 - Der Dateityp ist immer .mdb
• Windows Server 2012 R2 – Der Dateityp wird standardmäßig verwendet .edb , es sei denn, in der Konfiguration ist ein .mdb angegeben.

Im erweiterten Beispielskript für die Installation eines Pull-Servers finden Sie auch ein Beispiel dafür, wie Sie die web.config Dateieinstellungen automatisch steuern können, um die Möglichkeit von Fehlern zu vermeiden, die durch den Dateityp verursacht werden.