Introduksjon til Windows PowerShell Desired State Configuration

Min forrige artikkel her på TechNet Norge`s blog omhandlet nyheter i Windows PowerShell 4.0. I den artikkelen så vi kort på hva Windows PowerShell Desired State Configuration (DSC) er, men vi skal gå mer i dybden og se på noen praktiske eksempler i denne artikkelen.

 

Hva er DSC?

Desired State Configuration (DSC) er ny funksjonalitet i Windows Management Framework 4.0 (WMF 4.0), noe som i tidligere versjoner har inkludert Windows PowerShell, WMI (Windows Management Instrumentation) og WinRM (Windows Remote Management).

DSC gjør det mulig å definere deklarative konfigurasjoner for hvordan du vil at en maskin skal være konfigurert. Denne konfigurasjonen kan både rulles ut og verifiseres på gitte intervaller ved hjelp av DSC.

Med DSC kommer også utvidelser til Windows PowerShell, som gjør det mulig å definere DSC konfigurasjoner fra PowerShell. Spesifikt er det et nytt keyword i PowerShell 4.0 relatert til DSC som heter configuration, i tillegg flere DSC-relaterte cmdlets og moduler som vi skal se nærmere på. DSC i seg selv er altså ikke en del av Windows PowerShell, men det er mulig å bruke PowerShell for å definere, rulle ut og verifisere konfigurasjoner.

 

DSC kommer med flere innebygde såkalte resources som gjør det mulig å utføre ting som:

• Aktivere og dekativere roller og features i Windows Server
• Administrere registry innstillinger
• Administrere filer og mapper
• Starte, stoppe og administrere prosesser og tjenester
• Administrere brukere og grupper
• Rulle ut programvare
• Administrere environment variabler
• Kjøre PowerShell script

Har man behov for å utføre noe som ikke er dekket av de innebygde ressursene er det også mulig å bygge side egne ressurser, mer informasjon om DSC ressurser finner du på denne TechNet-siden.

 

Før vi begynner å se på det første PowerShell-eksempelet som definerer en konfigurasjon skal vi se nærmere på arkitekturen. DSC har to ulike modeller, en som heter pull og en som heter push:

I Pull mode vil en DSC klient med gitte intervaller sjekke og om nødvendig laste ned konfigurasjonsdefinisjoner fra en Pull server. I Push mode har en konfigurasjon blitt rullet ut til DSC klienten av en administrator.

 

Som vi ser på skissen over er det 3 faser i DSC:

• Authoring Phase

I denne fasen defineres konfigurasjonen, noe som enten kan gjøres ved hjelp av PowerShell eller andre verktøy. Det som produseres i denne fasen er en eller flere MOF (Management Object Format) filer, og det er disse filene som kan konsumeres av en DSC klient. Disse filene kan i prinsippet skrives i Notepad, men siden dette er basert på CIM schemas og ikke veldig «IT Pro»-vennlig er det i praksis vesentlig enklere å benytte de mulighetene som er tilrettelagt i PowerShell for å opprette MOF-filer hvor konfigurasjoner er definert. Denne fases utføres typisk i Windows PowerShell ISE på en administrator`s klient-maskin.

 

• Staging Phase

Neste fase består av å tilgjengelig gjøre MOF-filene for DSC klienten på den maskinen som konfigurasjonen skal gjelde for. I en Pull modell vil MOF-filene kopieres til Pull-serveren hvor de er tilgjengelig for klientene. I en Push modell vil en DSC-konfigurasjon rulles ut til en DSC klient fra for eksempel en administrator`s klient-maskin eller en sentral management server.

 

• «Make it So» Phase

Den siste fasen består av å faktisk bruke konfigurasjonen – «Make it So», som er en henvisning til hva Jean-Luc Picard ville sagt. På en DSC klient er det noe som heter Local Configuration Store hvor konfigurasjonene som enten er manuelt rullet ut eller hentet fra en sentral Pull server er lagret. Her lagres gjeldende konfigurasjon, forrige konfigurasjon og det som er den definerte konfigurasjonen. Konfigurasjonen blir parset og de relevante providerne implementerer nødvendige endringer.

 

DSC klienten

Det som hittil er referert til som «DSC klienten» heter egentlig DSC Local Configuration Manager (LCM), og er i praksis en såkalt CIM Method som trigges som standard hver halvtime av en scheduled task:

Vil man manuelt trigge DSC til å utføre en konfigurasjons-sjekk kan man altså enten kjøre denne oppgaven fra Task Scheduler eller PowerShell:

For konfigurasjon av DSC klienten er Get-DscLocalConfigurationManager og Set-DscLocalConfigurationManager tilgjengelig som en del av PowerShell-modulen PSDesiredStateConfiguration:

Her ser vi standard-innstillingene for en DSC klient som ikke er konfigurert:

ConfigurationMode er som standard konfigurert til ApplyAndMonitor, det vil si at ingen automatisk handling for å rette innstillinger som ikke er i henhold til den definerte konfigurasjonen utføres. To andre gyldige verdier for ConfigurationMode er ApplyOnly og ApplyAndAutoCorrect. På klienten som benyttes i demoen i neste avsnitt er ConfigurationMode satt til ApplyAndAutoCorrect. Mer informasjon om DSC Local Configuration Manager og hvordan den kan konfigureres er tilgjengelig på denne TechNet-siden.

 

Definere en DSC konfigurasjon

Som kjent har vi ulike keywords i PowerShell, for eksempel function for å definere en egendefinert funksjon. I PowerShell 4.0 har det kommet et nytt keyword for å definere DSC konfigurasjoner, den grunnleggende syntaksen er følgende:

I denne demoen skal vi definere en konfigurasjon som benytter den innebygde DSC resourcen «WindowsFeature» for å si at Telnet-klienten skal være installert:

Typisk vil man legge på flere parametre, for eksempel –ComputerName for å si hvilken maskin denne konfigurasjonen defineres for, men i dette eksempelet benyttes localhost for enkelhets skyld.

Når man kjører de 10 linjene over i PowerShell vil det ikke skje noen endring, det eneste som er gjort er å definere en konfigurasjon. Dette prinsippet er det samme som med functions i PowerShell, de må første defineres før de kan brukes.

Når konfigurasjonen er definert kan vi kalle den ved å skrive navnet etterfulgt av de parametre vi vil angi. –OutputPath er en standard-parameter på DSC-konfigurasjoner, og definerer hvor vi vil lagre MOF-filene som genereres:

Når dette er kjørt vil vi se at det er definert en MOF-fil i mappen som ble angitt:

Av ren nysgjerrighet kan vi åpne fila for å se hvordan den ser ut:

Dette er altså innholdet som ble generert av PowerShell, og som kan konsumeres av DSC klienten for å verifisere konfigurasjonen som er definert.

 

Rulle ut en DSC konfigurasjon

I denne artikkelen vil vi kun vise Push modellen, link til en artikkel som viser oppsett av Pull modellen er tilgjengelig i Ressurs-seksjonen nederst i artikkelen. For å rulle ut en DSC konfigurasjon (Push-mode) brukes Start-DscConfiguration hvor vi benytter –Path parameteren for å angi stien til mappen hvor MOF-fila vi genererte i forrige fase ligger. Vi kan også benytte –Wait for å angi at vi vil vente til konfigurasjonen er rullet ut. Etter å ha rullet ut konfigurasjonen bruker vi Get-WindowsFeature for å se status på om Telnet Client er installert:

Som en test vil vi deretter avinstallere Telnet Client:

I stedet for å vente inntil 30 minutter som er standard intervallet for når DSC klienten kjører en konsistens-sjekk kan vi manuelt trigge en sjekk:

La oss ta en ny sjekk på status for Telnet Client:

Nå ser vi at den er installert etter at DSC har kjørt en konsistens-sjekk.

Det er også mulig å sjekke om en maskin er i henhold til definert konfigurasjon ved å kjøre Test-DscConfiguration som vil returnere enten True eller False:

 

Logging

Vi har hittil sett på et enkelt eksempel på hvordan DSC fungerer, men hva om det er noe som ikke fungererer og vi har behov for mer informasjon? Vi har flere muligheter til å se mer på hva som foregår under panseret i DSC. Den første muligheten som kan nevnes er –Verbose parameteren. Her ser vi et eksempel på bruk av –Verbose på Start-DscConfiguration:

Tilsvarende for Test-DscConfiguration:

Den andre muligheten er Event Viewer, siden DSC benytter ETW (Event Tracing for Windows). Under Applications and Services->Logs->Microsoft->Windows finner vi Desired State Configuration Operational loggen:

I eksempelet over ser vi at en konsistens-sjekk ble kjørt. Ved å aktivere «Show Analytic and Debug Logs» i Event Viewer kan vi få tilgang til 2 andre logger hvor vi også finner nyttig informasjon:

Her ser vi i Analytic loggen en hendelse hvor det ble logget at Telnet Client ble installert:

Denne informasjonen er også tilgjengelig via PowerShell ved å benytte Get-WinEvent:

 

Hva er fordelene med Desired State Configuration?

• Gir mulighet for å overvåke og automatisk rette konfigurasjon av maskiner
• Innebygd i Windows 8.1 og Windows Server 2012 R2 og tilgjengelig 2 operativsystem utgivelser tilbake i form av Windows Management Framework 4.0
• Definisjon av DSC konfigurasjoner kan utføres i Windows PowerShell, dermed kan du dra nytte av eksisterende PowerShell kunnskaper både for å definere konfigurasjoner samt feilsøke DSC
• Når DSC kjører konsistens-sjekk vil det kun utføres en handling for de sjekkene som ikke er i henhold til definert konfigurasjon, dermed vil en sjekk utføres på veldig kort tid når alt er i henhold
• Det er mulig å separere konfigurasjons-data fra logikk i en DSC konfigurasjon, slik at man enklere kan gjenbruke konfigurasjons-data for ulike DSC ressurser, klienter og konfigurasjoner. For mer info, se denne TechNet-artikkelen.

 

Oppsummering

DSC i Windows 8.1 og Windows Server 2012 R2 er første utgivelse av denne funksjonaliteten, og eventuell manglende funksjonalitet vil bygges på i kommende versjoner.

Det fins allerede produkter med tilsvarende funksjonalitet, slik som Puppet og Chef. Man skulle tro at disse blir direkte konkurrenter til DSC, men begge disse produktene kan dra nytte av å ha DSC innebygd i Windows. For eksempel kan et tenkt scenario være at man ikke trenger å rulle ut agenter for disse 3. parts produktene, siden de i stedet kan integreres direkte i noe som er innebygd i Windows. I TechEd-videoen det er linket til i ressurs-seksjonen under er det en demo hvor Chef viser hvordan deres produkt kan integreres med DSC i Windows. Blant fordelene med dette er at kunder som kjører både Linux og Windows kan administrere begge miljøene fra samme sted.

I forhold til Group Policy tror jeg ikke DSC vil bli brukt mye på klient-siden, men for servere tror jeg DSC vil kunne brukes sammen med og på lengre sikt kanskje erstatte Group Policy. Blant fordelene med DSC er at det kan brukes på tvers av private og public clouds, uavhengig av Active Directory domene-medlemskap. DSC kan også utvides til å støtte egendefinerte funksjoner i form av custom providers. Alt man kan gjøre i PowerShell kan man lage providers for, eksempelvis kan man lage en provider for en intern Line-Of-Business applikasjon. Skal man utføre en endring på et sett med maskiner, for eksempel for alle Hyper-V servere, kan man utføre endringen i konfigurasjonen som er definert for denne typen servere. Endringen vil da kunne hentes fra en sentral Pull server, og utføres ved neste oppdateringsintervall. En typisk utfordring er at det i forbindelse med feilsøking endres på en innstilling, og det blir glemt å endre denne innstillingen tilbake. Med DSC kan alle typer kritiske innstillinger overvåkes og automatisk settes tilbake dersom noen manuelt har utført en endring. I forhold til utrulling av nye servere vil også DSC kunne ta seg av initiell konfigurasjon, og dermed automatisere arbeid som kanskje har vært manuelt tidligere. Kort fortalt kan man si at DSC er et rammeverk som jeg personlig tror vil være en viktig byggestein i kommende år med tanke på automatisering og «cloud OS».

 

Ressurser

• Windows PowerShell Desired State Configuration Overview – Microsoft TechNet
• Desired State Configuration in Windows Server 2012 R2 PowerShell – TechEd video hvor Kenneth Hansen og Jeffrey Snover presenterer DSC
• Desired State Configuration in Pull mode over SMB – eksempel på hvordan en Pull server kan konfigureres
• Group Policy vs. Desired State Configuration – interessant artikkel skrevet av Group Policy MVP Darren Mar-Elia med hans tanker rundt DSC sett i forhold til Group Policy
• Community-baserte powershell.org`s artikler om DSC
• Community DSC Resources på GitHub

Comments

• Anonymous
  January 01, 2003
  tack så mycket