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-Module
PowerShellGet 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.
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: