Share via


Lekérési kiszolgáló – ajánlott eljárások

A következőkre vonatkozik: Windows PowerShell 4.0, Windows PowerShell 5.0

Fontos

A Lekéréses kiszolgáló (Windows feature DSC-Service) a Windows Server egyik támogatott összetevője, de nem tervez új funkciókat vagy képességeket kínálni. Szeretnénk tudni, hogy a DSC újabb verziója már általánosan elérhető, amelyet Azure Policy nevű vendégkonfiguráció egyik funkciója felügyel. A vendégkonfigurációs szolgáltatás egyesíti a DSC-bővítmény, a Azure Automation State Configuration és az ügyfél visszajelzései által leggyakrabban kért funkciókat. A vendégkonfiguráció a hibrid gépek Arc-kompatibilis kiszolgálókon keresztüli támogatását is magában foglalja.

Összefoglalás: Ez a dokumentum a megoldásra készülő mérnököknek szánt folyamatokat és bővíthetőséget tartalmazza. A részleteknek meg kell adniuk az ügyfelek által meghatározott ajánlott eljárásokat, majd ellenőrizniük kell a termékcsapatot annak érdekében, hogy a javaslatok a jövőben is elérhetők és stabilak legyenek.

  • Szerző: Michael Greene
  • Véleményezők: Ben Gelens, Ravikanth Chaganti, Aleksandar Nikolic
  • Közzétéve: 2015. április

Abstract

Ez a dokumentum hivatalos útmutatást nyújt minden olyan felhasználó számára, aki Windows PowerShell Desired State Configuration lekéréses kiszolgáló megvalósítását tervezi. A lekéréses kiszolgáló egy egyszerű szolgáltatás, amely üzembe helyezése csak perceket vesz igénybe. Bár ez a dokumentum technikai útmutatót nyújt, amely használható egy üzemelő példányban, ennek a dokumentumnak az értéke referenciaként szolgál az ajánlott eljárásokhoz, és hogy mit kell gondolni az üzembe helyezés előtt. Az olvasóknak alapszintű ismeretekkel kell rendelkezniük a DSC-vel kapcsolatban, valamint a DSC-üzembe helyezés összetevőinek leírására használt kifejezésekkel. További információ: Windows PowerShell Desired State Configuration Áttekintés témakör. Mivel a DSC várhatóan a felhőbeli ütemben fejlődik, a mögöttes technológia, beleértve a lekéréses kiszolgálót is, várhatóan fejlődni fog, és új képességeket vezet be. Ez a dokumentum tartalmaz egy verziótáblát a függelékben, amely a korábbi kiadásokra mutató hivatkozásokat és a jövőbe mutató megoldásokra mutató hivatkozásokat tartalmaz a jövőbe mutató tervek ösztönzése érdekében.

A dokumentum két fő szakasza:

  • Konfigurációtervezés
  • Telepítési útmutató

A Windows Management Framework verziói

A dokumentumban szereplő információk az Windows Management Framework 5.0-s verzióra vonatkoznak. Bár a WMF 5.0 nem szükséges egy lekéréses kiszolgáló üzembe helyezéséhez és üzemeltetéséhez, a dokumentum középpontjában az 5.0-s verzió áll.

Windows PowerShell Desired State Configuration

Desired State Configuration (DSC) egy felügyeleti platform, amely lehetővé teszi a konfigurációs adatok üzembe helyezését és kezelését a Managed Object Format (MOF) nevű iparági szintaxissal a Common Information Model (CIM) leírásához. Az Open Management Infrastructure (OMI) egy nyílt forráskód projekt, amely ezen szabványok további fejlesztését célozza a platformokon, beleértve a Linux és a hálózati hardveres operációs rendszereket is. További információért tekintse meg az MOF-specifikációkra mutató DMTF-oldalt, valamint az OMI-dokumentumokat és -forrást.

Windows PowerShell nyelvi bővítményeket biztosít Desired State Configuration, amelyekkel deklaratív konfigurációkat hozhat létre és kezelhet.

Lekéréses kiszolgálói szerepkör

A lekéréses kiszolgáló egy központosított szolgáltatást biztosít a célcsomópontok számára elérhető konfigurációk tárolásához.

A lekéréses kiszolgálói szerepkör webkiszolgáló-példányként vagy SMB-fájlmegosztásként is üzembe helyezhető. A webkiszolgálói képesség tartalmaz egy OData-felületet, és opcionálisan olyan képességeket is tartalmazhat a célcsomópontokhoz, amelyek a konfigurációk alkalmazásakor jelzik a sikeresség vagy a hiba megerősítését. Ez a funkció olyan környezetekben hasznos, ahol nagy számú célcsomópont található. Miután konfigurálta a célcsomópontot (más néven ügyfelet), hogy a lekéréses kiszolgálóra mutasson, a rendszer letölti és alkalmazza a legújabb konfigurációs adatokat és a szükséges szkripteket. Ez egyszeri üzembe helyezésként vagy újra előforduló feladatként fordulhat elő, amely a lekéréses kiszolgálót is fontos eszközként kezeli a nagy léptékű változások kezeléséhez. További információ: Leküldéses és lekéréses konfigurációs módok.

Konfigurációtervezés

A vállalati szoftvertelepítések esetében előre gyűjthetők olyan információk, amelyek segítenek megtervezni a megfelelő architektúrát, és fel kell készülni az üzembe helyezés elvégzéséhez szükséges lépésekre. Az alábbi szakaszok tájékoztatást nyújtanak a felkészülés módjáról és azokról a szervezeti kapcsolatokról, amelyeknek valószínűleg előre meg kell történniük.

Szoftverkövetelmények

A lekéréses kiszolgáló üzembe helyezéséhez a Windows Server DSC szolgáltatása szükséges. Ez a funkció a Windows Server 2012-ben lett bevezetve, és a Windows Management Framework (WMF) folyamatban lévő kiadásával frissült.

Szoftverletöltések

A Windows Update legújabb tartalmának telepítése mellett két letöltés tekinthető ajánlott eljárásnak egy DSC lekéréses kiszolgáló üzembe helyezéséhez: a Windows Management Framework legújabb verziója, valamint egy DSC-modul a lekéréses kiszolgálók kiépítésének automatizálásához.

DSC-erőforrás

A lekéréses kiszolgálók üzembe helyezését leegyszerűsítheti a szolgáltatás DSC-konfigurációs szkripttel történő kiépítésével. Ez a dokumentum olyan konfigurációs szkripteket tartalmaz, amelyek éles üzemre kész kiszolgálócsomópont üzembe helyezésére használhatók. A konfigurációs szkriptek használatához olyan DSC-modulra van szükség, amely nem szerepel a Windows Serverben. A szükséges modulnév az xPSDesiredStateConfiguration, amely tartalmazza az xDscWebService DSC-erőforrást. Az xPSDesiredStateConfiguration modul letölthető a PowerShell-galéria.

Használja a Install-ModulePowerShellGet modul parancsmagát.

Install-Module xPSDesiredStateConfiguration

A PowerShellGet modul a következőre tölti le a modult:

C:\Program Files\Windows PowerShell\Modules

Tervezési feladat

  • Rendelkezik hozzáféréssel az R2 Windows Server 2012 telepítési fájljaihoz?
  • Az üzembehelyezési környezetnek lesz internetkapcsolata a WMF és a modul online katalógusból való letöltéséhez?
  • Hogyan telepíti a legújabb biztonsági frissítéseket az operációs rendszer telepítése után?
  • Rendelkezik-e a környezet internet-hozzáféréssel a frissítések beszerzéséhez, vagy rendelkezik helyi Windows Server Update Services (WSUS) kiszolgálóval?
  • Van hozzáférése olyan Windows Server-telepítőfájlokhoz, amelyek offline injektálással már tartalmazzák a frissítéseket?

Hardverkövetelmények

A lekéréses kiszolgálók telepítései mind fizikai, mind virtuális kiszolgálókon támogatottak. A lekéréses kiszolgáló méretezési követelményei összhangban Windows Server 2012 R2 követelményeivel.

  • CPU: 1,4 GHz 64 bites processzor
  • Memória: 512 MB
  • Lemezterület: 32 GB
  • Hálózat: Gigabit Ethernet-adapter

Tervezési feladat

  • Fizikai hardveren vagy virtualizálási platformon fog üzembe helyezni?
  • Mi az a folyamat, amely új kiszolgálót kér a célkörnyezethez?
  • Mennyi az átlagos átfutási idő ahhoz, hogy egy kiszolgáló elérhetővé váljon?
  • Milyen méretű kiszolgálót kér?

Fiókok

A lekéréses kiszolgálópéldány üzembe helyezéséhez nincs szolgáltatási fiókra vonatkozó követelmény. Vannak azonban olyan esetek, amikor a webhely egy helyi felhasználói fiók környezetében futhat. Ha például hozzá kell férnie egy webhelytartalomhoz tartozó tárolómegosztáshoz, és a Windows Server vagy a tárolómegosztást üzemeltető eszköz nem csatlakozik tartományhoz.

DNS records

Szüksége lesz egy kiszolgálónévre, amelyet az ügyfelek lekéréses kiszolgálói környezettel való együttműködésre való konfigurálásakor kell használnia. Tesztkörnyezetekben általában a kiszolgáló állomásneve, vagy a kiszolgáló IP-címe használható, ha a DNS-névfeloldás nem érhető el. Éles környezetben vagy tesztkörnyezetben, amely egy éles üzembe helyezést kíván képviselni, az ajánlott eljárás egy DNS CNAME rekord létrehozása.

A DNS CNAME használatával létrehozhat egy aliast, amely a gazdagéprekordra (A) hivatkozik. A további névrekord célja a rugalmasság növelése, ha a jövőben módosításra van szükség. A CNAME segít elkülöníteni az ügyfélkonfigurációt, hogy a kiszolgálói környezet módosítása, például egy lekéréses kiszolgáló cseréje vagy további lekéréses kiszolgálók hozzáadása, ne igényeljen megfelelő módosítást az ügyfélkonfigurációban.

A DNS-rekord nevének kiválasztásakor tartsa szem előtt a megoldásarchitektúrát. Terheléselosztás használata esetén a HTTPS-en keresztüli forgalom védelméhez használt tanúsítványnak a DNS-rekord nevével megegyező nevet kell megosztania.

Ajánlott forgatókönyvek

  • Tesztkörnyezet – Ha lehetséges, reprodukálja a tervezett éles környezetet. A kiszolgáló állomásneve egyszerű konfigurációkhoz alkalmas. Ha a DNS nem érhető el, egy IP-cím használható a gazdagépnév helyett.
  • Egycsomópontos üzembe helyezés – Hozzon létre egy DNS CNAME rekordot, amely a kiszolgáló állomásnevére mutat.

További információ: A DNS-ciklikus időszeletelés konfigurálása a Windows Serverben.

Tervezési feladat

  • Tudja, hogy kivel kell kapcsolatba lépnie a DNS-rekordok létrehozásához és módosításához?
  • Mi a DNS-rekordra vonatkozó kérelmek átlagos átfutási ideje?
  • Statikus Állomásnév (A) rekordokat kell kérnie a kiszolgálókhoz?
  • Mit fog kérni CNAME-ként?
  • Ha szükséges, milyen típusú terheléselosztási megoldást fog használni? (részletekért lásd a Terheléselosztás című szakaszt)

Nyilvános kulcsú infrastruktúra

Napjainkban a legtöbb szervezet megköveteli a hálózati forgalom ellenőrzését és/vagy titkosítását, különösen az olyan bizalmas adatokat tartalmazó forgalmat, mint a kiszolgálók konfigurálása. Bár http használatával is üzembe helyezhet lekéréses kiszolgálót, amely világos szövegben segíti elő az ügyfélkéréseket, ajánlott https használatával biztonságossá tenni a forgalmat. A szolgáltatás konfigurálható HTTPS használatára az xPSDesiredStateConfiguration DSC-erőforrás paramétereinek használatával.

A lekéréses kiszolgáló HTTPS-forgalmának védelmére vonatkozó tanúsítványkövetelmények nem különböznek a többi HTTPS-webhely biztonságossá tételétől. A Windows Server tanúsítványszolgáltatások webkiszolgálói sablonja megfelel a szükséges képességeknek.

Tervezési feladat

  • Ha a tanúsítványkérelmek nem automatizáltak, kihez kell fordulnia a tanúsítványigényléshez?
  • Mi a kérés átlagos átfutási ideje?
  • Hogyan továbbítja Önnek a tanúsítványfájlt?
  • Hogyan továbbítja Önnek a tanúsítvány titkos kulcsát?
  • Mennyi az alapértelmezett lejárati idő?
  • A lekéréses kiszolgálói környezet DNS-nevének rendezése a tanúsítványnévhez használható?

Architektúra kiválasztása

A lekéréses kiszolgáló egy IIS-en üzemeltetett webszolgáltatással vagy egy SMB-fájlmegosztással helyezhető üzembe. A legtöbb esetben a webszolgáltatás nagyobb rugalmasságot biztosít. Nem ritka, hogy a HTTPS-forgalom átlépi a hálózati határokat, míg az SMB-forgalmat gyakran szűrik vagy blokkolják a hálózatok között. A webszolgáltatás egy megfelelőségi kiszolgálót vagy webjelentés-kezelőt is tartalmaz (mindkét témakört a dokumentum későbbi verziójában kell kezelni), amely lehetővé teszi az ügyfelek számára, hogy állapotot küldjenek vissza egy kiszolgálónak a központosított láthatóság érdekében. Az SMB lehetőséget biztosít olyan környezetekhez, ahol a szabályzat azt írja elő, hogy a webkiszolgálót nem szabad használni, valamint egyéb környezeti követelmények esetén, amelyek a webkiszolgálói szerepkört nemkívánatossá teszik. Mindkét esetben ne felejtse el kiértékelni a forgalom aláírására és titkosítására vonatkozó követelményeket. A HTTPS, az SMB-aláírás és az IPSEC-szabályzatok mind megfontolni érdemes lehetőségek.

Terheléselosztás

A webszolgáltatással interakcióba lépő ügyfelek egyetlen válaszban visszaadott információkérést kérnek. Nincs szükség szekvenciális kérésekre, így a terheléselosztási platformnak nem kell gondoskodnia arról, hogy a munkamenetek egyetlen kiszolgálón legyenek fenntartva bármikor.

Tervezési feladat

  • Milyen megoldást használ a rendszer a kiszolgálók közötti forgalom terheléselosztására?
  • Ha hardveres terheléselosztót használ, ki fogja kérni, hogy adjon hozzá új konfigurációt az eszközhöz?
  • Mi az új elosztott terhelésű webszolgáltatás konfigurálására vonatkozó kérések átlagos átfutási ideje?
  • Milyen információkra lesz szükség a kérelemhez?
  • Igényelni kell egy további IP-címet, vagy ezt a terheléselosztásért felelős csapat fogja kezelni?
  • Rendelkezik a szükséges DNS-rekordokkal, és erre a terheléselosztási megoldás konfigurálását végző csapatnak szüksége lesz?
  • A terheléselosztási megoldás megköveteli, hogy az eszköz kezelje a PKI-t, vagy ki tudja egyensúlyozni a HTTPS-forgalmat mindaddig, amíg nincsenek munkamenet-követelmények?

Előkészítési konfigurációk és modulok a lekérési kiszolgálón

A konfigurációtervezés részeként végig kell gondolnia, hogy mely DSC-modulokat és konfigurációkat fogja üzemeltetni a lekérési kiszolgáló. A konfigurációtervezéshez fontos, hogy alapszintű ismereteket biztosítsunk a tartalom lekéréses kiszolgálóra való előkészítéséről és üzembe helyezéséről.

A jövőben ez a szakasz ki lesz bővítve, és szerepelni fog a DSC lekéréses kiszolgáló üzemeltetési útmutatójában. Az útmutató a modulok és konfigurációk automatizálással történő kezelésének napi folyamatát ismerteti.

DSC-modulok

A konfigurációt kérő ügyfeleknek szüksége lesz a szükséges DSC-modulokra. A lekérési kiszolgáló egyik funkciója a DSC-modulok igény szerinti elosztásának automatizálása az ügyfelek számára. Ha első alkalommal helyez üzembe lekéréses kiszolgálót, például tesztkörnyezetként vagy megvalósíthatósági vizsgálatként, valószínűleg olyan DSC-moduloktól fog függeni, amelyek nyilvános adattárakból érhetők el, például a PowerShell-galéria vagy a DSC-modulokhoz készült PowerShell.org GitHub-adattáraktól.

Fontos megjegyezni, hogy még a megbízható online források, például a PowerShell-galéria esetében is, a nyilvános adattárból letöltött modulokat olyan személynek kell áttekintenie, aki rendelkezik PowerShell-tapasztalattal és a környezet ismeretével, amelyben a modulokat az éles környezetben való használat előtt használni fogják. A feladat elvégzése során érdemes ellenőrizni, hogy vannak-e további hasznos adatok a modulban, amelyeket el lehet távolítani, például a dokumentációt és a példaszkripteket. Ez csökkenti az ügyfélenkénti hálózati sávszélességet az első kérés során, amikor a modulok a hálózaton keresztül töltődnek le a kiszolgálóról az ügyfélre.

Minden modult egy adott formátumban kell csomagolni, egy ModuleName_Version.zip nevű ZIP-fájlt, amely tartalmazza a modul hasznos adatait. A fájl kiszolgálóra másolása után létre kell hozni egy ellenőrzőösszegfájlt. Amikor az ügyfelek csatlakoznak a kiszolgálóhoz, a rendszer ellenőrzi, hogy a DSC-modul tartalma nem változott-e a közzététel óta.

New-DscChecksum -ConfigurationPath .\ -OutPath .\

Tervezési feladat

  • Ha tesztkörnyezetet vagy tesztkörnyezetet tervez, mely forgatókönyvek ellenőrzése kulcsfontosságú?
  • Vannak olyan nyilvánosan elérhető modulok, amelyek erőforrásokat tartalmaznak, hogy mindent lefedjenek, amire szüksége van, vagy saját erőforrásokat kell létrehoznia?
  • Rendelkezik-e a környezete internet-hozzáféréssel a nyilvános modulok lekéréséhez?
  • Ki lesz felelős a DSC-modulok áttekintéséért?
  • Ha éles környezetet tervez, mit fog helyi adattárként használni a DSC-modulok tárolásához?
  • A központi csapat elfogadja-e a DSC-modulokat az alkalmazáscsapatoktól? Mi lesz a folyamat?
  • Automatizálni fogja a csomagolást, a másolást és az ellenőrzőösszeg létrehozását az éles üzemre kész DSC-modulok számára a kiszolgálóra a forrásadattárból?
  • A csapata is felelős lesz az automatizálási platform kezeléséért?

DSC-konfigurációk

A lekéréses kiszolgáló célja, hogy központosított mechanizmust biztosítson a DSC-konfigurációk ügyfélcsomópontokra való elosztásához. A konfigurációkat a rendszer MOF-dokumentumként tárolja a kiszolgálón. Minden dokumentum neve egyedi GUID azonosítóval lesz elnevezve. Ha az ügyfelek úgy vannak konfigurálva, hogy egy lekéréses kiszolgálóhoz csatlakozzanak, a rendszer a kért konfiguráció guid azonosítóját is megkapja. Ez a GUID-referenciakonfigurációkra hivatkozó rendszer garantálja a globális egyediséget, és rugalmas, így a konfigurációk csomópontonkénti részletességgel alkalmazhatók, vagy olyan szerepkör-konfigurációként, amely több kiszolgálóra is kiterjed, amelyeknek azonos konfigurációkkal kell rendelkezniük.

Guid

A konfigurációs guidok megtervezése további figyelmet érdemel a lekéréses kiszolgáló üzembe helyezése során. Nincs konkrét követelmény a guidok kezeléséhez, és a folyamat valószínűleg minden környezetben egyedi lesz. A folyamat az egyszerűtől az összetettig terjedhet: egy központilag tárolt CSV-fájl, egy egyszerű SQL-tábla, egy CMDB vagy egy más eszközzel vagy szoftveres megoldással való integrációt igénylő összetett megoldás. Két általános megközelítés létezik:

  • Guidok hozzárendelése kiszolgálónként – Biztosítja, hogy minden kiszolgálókonfiguráció külön-külön legyen vezérelve. Ez a frissítésekkel kapcsolatos pontosságot biztosít, és kevés kiszolgálóval rendelkező környezetekben is jól működik.

  • Guid-azonosítók hozzárendelése kiszolgálói szerepkörenként – Az azonos funkciót (például webkiszolgálókat) végrehajtó összes kiszolgáló ugyanazt a GUID-t használja a szükséges konfigurációs adatokra való hivatkozáshoz. Vegye figyelembe, hogy ha sok kiszolgáló ugyanazt a GUID-t használja, a konfiguráció módosításakor az összes kiszolgáló egyidejűleg frissül.

    A GUID olyan dolog, amelyet bizalmas adatoknak kell tekinteni, mert rosszindulatú szándékkal rendelkező személy hasznosíthatja a kiszolgálók környezetbeli üzembe helyezésének és konfigurálásának módját. További információ: Guidok biztonságos lefoglalása PowerShell-Desired State Configuration lekéréses módban.

Tervezési feladat

  • Ki lesz a felelős a konfigurációknak a lekérési kiszolgáló mappájába való másolásáért, amikor azok készen állnak?
  • Ha a konfigurációkat egy alkalmazáscsapat szerkesztette, mi lesz a folyamat az átadásukkal?
  • Használ egy adattárat a konfigurációk szerkesztésük közbeni tárolására a csapatok között?
  • Automatizálni fogja a konfigurációk kiszolgálóra másolásának folyamatát, és létrehoz egy ellenőrzőösszeget, amikor azok készen állnak?
  • Hogyan fogja leképezni a guidokat a kiszolgálókra vagy szerepkörökre, és hol tárolja a rendszer?
  • Mit fog használni folyamatként az ügyfélszámítógépek konfigurálásához, és hogyan integrálható a konfigurációs guidok létrehozására és tárolására szolgáló folyamattal?

Telepítési útmutató

A dokumentumban megadott szkriptek stabil példák. Éles környezetben való végrehajtás előtt mindig alaposan tekintse át a szkripteket.

Előfeltételek

A PowerShell verziójának ellenőrzéséhez használja a következő parancsot a kiszolgálón.

$PSVersionTable.PSVersion

Ha lehetséges, frissítsen a Windows Management Framework legújabb verziójára. Ezután töltse le a modult xPsDesiredStateConfiguration a következő paranccsal.

Install-Module xPSDesiredStateConfiguration

A parancs a modul letöltése előtt kérni fogja a jóváhagyást.

Telepítési és konfigurációs szkriptek

A DSC lekéréses kiszolgáló üzembe helyezésének legjobb módja egy DSC konfigurációs szkript használata. Ez a dokumentum olyan szkripteket fog bemutatni, amelyek az alapszintű beállításokat is tartalmazzák, amelyek csak a DSC-webszolgáltatást konfigurálják, valamint olyan speciális beállításokat, amelyek a Windows Server teljes körű konfigurálását teszik lehetővé, beleértve a DSC webszolgáltatást is.

Megjegyzés: Jelenleg a xPSDesiredStateConfiguration DSC-modul megköveteli, hogy a kiszolgáló EN-US területi beállítás legyen.

Alapszintű konfiguráció a 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\'

Speciális konfiguráció az Windows Server 2012 R2-höz

# 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'

A lekérési kiszolgáló működésének ellenőrzése

# 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

Ügyfelek konfigurálása

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

További hivatkozások, kódrészletek és példák

Ez a példa bemutatja, hogyan kezdeményezhet manuálisan ügyfélkapcsolatot (WMF5 szükséges hozzá) a teszteléshez.

Update-DscConfiguration -Wait -Verbose

Az Add-DnsServerResourceRecordName parancsmaggal CNAME típusú rekordot adhat hozzá egy DNS-zónához.

Az Ellenőrzőösszeg létrehozása és A DSC MOF közzététele az SMB lekérési kiszolgálón powershell-függvény automatikusan létrehozza a szükséges ellenőrzőösszeget, majd az MOF-konfigurációt és az ellenőrzőösszegfájlokat is átmásolja az SMB lekérési kiszolgálóra.

Függelék – Az ODATA szolgáltatás adatfájltípusának ismertetése

A rendszer egy adatfájlt tárol, hogy információkat hozzon létre az OData webszolgáltatást tartalmazó lekéréses kiszolgáló üzembe helyezése során. A fájl típusa az operációs rendszertől függ, az alábbiak szerint.

  • Windows Server 2012 – A fájltípus mindig.mdb
  • Windows Server 2012 R2 – A fájltípus alapértelmezés szerint .edb a lesz, hacsak .mdb nincs megadva a konfigurációban.

A Lekéréses kiszolgáló telepítésére szolgáló Speciális példaszkriptben egy példát is talál arra, hogyan szabályozhatja automatikusan a fájlbeállításokat, hogy megelőzze a web.config fájltípus által okozott hibák esélyét.