Dela via

Ändringar i beteendet i PowerShell Desired State Configuration för datorkonfiguration

  • Artikel

Innan du börjar är det en bra idé att läsa översikten över datorkonfigurationen.

En videogenomgång av det här dokumentet är tillgänglig.

Datorkonfigurationen använder PowerShell Desired State Configuration (PSDSC) version 2 för att granska och konfigurera datorer. DSC-konfigurationen definierar tillståndet som datorn ska vara i. Det finns många viktiga skillnader i hur DSC implementeras i datorkonfigurationen.

Datorkonfiguration använder PowerShell 7 plattformsoberoende

Datorkonfigurationen är utformad så att upplevelsen av att hantera Windows och Linux kan vara konsekvent. I båda operativsystemmiljöerna kan någon med PowerShell DSC-kunskaper skapa och publicera konfigurationer med hjälp av skriptkunskaper.

Datorkonfigurationen använder endast PowerShell DSC version 3 och förlitar sig inte på den tidigare implementeringen av DSC för Linux eller de nx* leverantörer som ingår i lagringsplatsen.

Från och med version 1.26.33 fungerar datorkonfigurationen i PowerShell 7.1.2 för Windows och PowerShell 7.2 förhandsversion 6 för Linux. Från och med version 7.2 flyttade modulen PSDesiredStateConfiguration från att vara en del av PowerShell-installationen och installeras i stället som en modul från PowerShell-galleriet.

Flera konfigurationer

Datorkonfigurationen stöder tilldelning av flera konfigurationer till samma dator. Det finns inga särskilda steg som krävs i operativsystemet för datorkonfigurationstillägget. Du behöver inte konfigurera partiella konfigurationer.

Beroenden hanteras per konfiguration

När en konfiguration paketeras med hjälp av de tillgängliga verktygen inkluderas de nödvändiga beroendena för konfigurationen i en .zip fil. Datorer extraherar innehållet i en unik mapp för varje konfiguration. Agenten som levereras av datorkonfigurationstillägget skapar en dedikerad PowerShell-session för varje konfiguration. Den använder en $Env:PSModulePath som begränsar automatisk modulinläsning till endast sökvägen där paketet extraherades.

Den här ändringen har flera fördelar:

  • Det går att använda olika modulversioner för varje konfiguration på samma dator.
  • När en konfiguration inte längre behövs på en dator tar agenten bort hela mappen där konfigurationen extraherades på ett säkert sätt. Du behöver inte hantera delade beroenden mellan konfigurationer.
  • Det krävs inte för att hantera flera versioner av någon modul i en central tjänst.

Artefakter hanteras som paket

Azure Automation State Configuration-funktionen innehåller artefakthantering för moduler och konfigurationsskript. När båda har publicerats till tjänsten kan skriptet kompileras till MOF-format. På samma sätt krävde Windows Pull Server även hantering av konfigurationer och moduler på webbtjänstinstansen. DSC-tillägget har däremot en förenklad modell där alla artefakter paketeras tillsammans och lagras på en plats som är tillgänglig från måldatorn med hjälp av en HTTPS-begäran. Azure Blob Storage är det populära alternativet för att vara värd för artefakterna.

Datorkonfigurationen använder bara den förenklade modellen där alla artefakter paketeras tillsammans och nås från måldatorn via HTTPS. Du behöver inte publicera moduler, skript eller kompilera i tjänsten. En ändring är att paketet alltid ska innehålla en kompilerad MOF. Det går inte att inkludera en skriptfil i paketet och kompilera på måldatorn.

Maximal storlek på anpassat konfigurationspaket

I Azure Automation State Configuration var DSC-konfigurationerna begränsade i storlek. Datorkonfigurationen stöder en total paketstorlek på 100 MB före komprimering. Det finns ingen specifik gräns för storleken på MOF-filen i paketet.

Konfigurationsläget anges i paketartefakten

När du skapar konfigurationspaketet anges läget med hjälp av följande alternativ:

  • Audit – Verifierar en dators efterlevnad. Inga ändringar görs.
  • AuditandSet – Verifierar och åtgärdar datorns efterlevnadstillstånd. Ändringar görs om datorn inte är kompatibel.

Läget anges i paketet i stället för i tjänsten Local Configuration Manager eftersom varje konfiguration kan tillämpas med ett annat läge.

Parameterstöd via Azure Resource Manager

Parametrar som anges av egenskapen configurationParameter i datorkonfigurationstilldelningar skriver över den statiska texten i en MOF-konfigurationsfil när filen lagras på en dator. Parametrar möjliggör anpassning och en operator för att styra ändringar från tjänst-API:et utan att behöva köra kommandon på datorn.

Parametrar i Azure Policy som skickar värden till datorkonfigurationstilldelningar måste vara strängtyp . Det går inte att skicka matriser via parametrar, även om DSC-resursen stöder matriser.

Utlösaruppsättning från en extern dator

En utmaning i tidigare versioner av DSC har varit att korrigera drift i stor skala utan mycket anpassad kod och beroende av WinRM-fjärranslutningar. Gästkonfigurationen löser det här problemet. Användare av datorkonfiguration har kontroll över driftkorrigering via Reparation på begäran.

Sekvensen innehåller Get-metoden

När datorkonfigurationen granskar eller konfigurerar en dator används samma händelsesekvens för både Windows och Linux. Den anmärkningsvärda ändringen i beteendet är att Get metoden anropas av tjänsten för att returnera information om datorns tillstånd.

  1. Agenten kör Test först för att avgöra om konfigurationen är i rätt tillstånd.
  2. Om paketet är inställt på Auditavgör det booleska värdet som returneras av funktionen om Azure Resource Manager-statusen för gästtilldelningen ska vara Compliant eller NonCompliant.
  3. Om paketet är inställt på AuditandSetavgör det booleska värdet om datorn ska repareras genom att använda konfigurationen Set med hjälp av metoden. Test Om metoden returnerar $false, Set körs. Om Test returnerar $trueSet körs inte .
  4. Slutligen körs Get providern för att returnera det aktuella tillståndet för varje inställning så att det finns information både om varför en dator inte är kompatibel och för att bekräfta att det aktuella tillståndet är kompatibelt.

Särskilda krav för Get

DSC-metoden Get har särskilda krav för datorkonfiguration som inte har behövts för DSC.

  • Hash-tabellen som returneras bör innehålla en egenskap med namnet Reasons.
  • Egenskapen Reasons måste vara en matris.
  • Varje objekt i matrisen ska vara en hash-tabell med nycklar med namnet Kod och fras.
  • Inga andra värden än hash-tabellen ska returneras.

Egenskapen Reasons används av tjänsten för att standardisera hur efterlevnadsinformation visas. Du kan se varje objekt i Skäl som ett meddelande om hur resursen är eller inte är kompatibel. Egenskapen är en matris eftersom en resurs kan vara oefterlevnad av mer än en anledning.

Egenskaperna Kod och fras förväntas av tjänsten. När du redigerar en anpassad resurs anger du den text som du vill visa som orsaken till att resursen inte är kompatibel som värde för Fras. Koden har specifika formateringskrav så att rapportering tydligt kan visa information om den resurs som används för granskning. Den här lösningen gör gästkonfigurationen utökningsbar. Alla kommandon kan köras så länge utdata kan returneras som ett strängvärde för egenskapen Fras .

  • Kod (sträng): Namnet på resursen, upprepat och sedan ett kort namn utan blanksteg som identifierare av orsaken. Dessa tre värden ska vara kolonavgränsade utan blanksteg.
    • Ett exempel skulle vara registry:registry:keynotpresent
  • Fras (sträng): Text som kan läsas av människor för att förklara varför inställningen inte är kompatibel.
    • Ett exempel skulle vara The registry key $key isn't present on the machine.
$reasons = @()
$reasons += @{
  Code   = 'Name:Name:ReasonIdentifier'
  Phrase = 'Explain why the setting is not compliant'
}
return @{
    reasons = $reasons
}

När du använder kommandoradsverktyg för att hämta information som returneras i Getkanske verktyget returnerar utdata som du inte förväntade dig. Även om du samlar in utdata i PowerShell kan utdata också ha skrivits till standardfel. Undvik det här problemet genom att omdirigera utdata till null.

Egenskapen Reasons embedded -klass

I skriptbaserade resurser (endast Windows) ingår klassen Reasons i schema-MOF-filen enligt följande.

[ClassVersion("1.0.0.0")]
class Reason
{
  [Read] String Phrase;
  [Read] String Code;
};

[ClassVersion("1.0.0.0"), FriendlyName("ResourceName")]
class ResourceName : OMI_BaseResource
{
  [Key, Description("Example description")] String Example;
  [Read, EmbeddedInstance("Reason")] String Reasons[];
};

I klassbaserade resurser (Windows och Linux) ingår klassen Reason i PowerShell-modulen på följande sätt. Linux är skiftlägeskänsligt, så C in Code och P in Phrase måste vara versaler.

enum ensure {
  Absent
  Present
}

class Reason {
  [DscProperty()]
  [string] $Code

  [DscProperty()]
  [string] $Phrase
}

[DscResource()]
class Example {

  [DscProperty(Key)]
  [ensure] $ensure

  [DscProperty()]
  [Reason[]] $Reasons

  [Example] Get() {
    # return current current state
  }

  [void] Set() {
    # set the state
  }

  [bool] Test() {
    # check whether state is correct
  }
}

Om resursen har nödvändiga egenskaper bör dessa egenskaper också returneras Get parallellt med klassen Reason . Om Orsak inte ingår innehåller tjänsten ett "catch-all"-beteende som jämför värdena som matas in med Get och värdena som returneras av Getoch ger en detaljerad jämförelse som Orsak.

Konfigurationsnamn

Namnet på den anpassade konfigurationen måste vara konsekvent överallt. Dessa objekt måste ha samma namn:

  • Filen .zip för innehållspaketet
  • Konfigurationsnamnet i MOF-filen
  • Namnet på datorkonfigurationstilldelningen i Azure Resource Manager-mallen

Köra kommandon i Windows PowerShell

Du kan köra Windows-moduler i PowerShell med hjälp av nedanstående mönster i dina DSC-resurser. Nedanstående mönster ställer tillfälligt in PSModulePath att köra Windows PowerShell i stället för PowerShell för att identifiera nödvändiga moduler som är tillgängliga i Windows PowerShell. Det här exemplet är ett kodfragment som är anpassat från den DSC-resurs som används i den inbyggda DSC-resursen för säker webbserver .

Det här mönstret ställer tillfälligt in PowerShell-körningssökvägen så att den körs från Windows PowerShell och identifierar den cmdlet som krävs, vilket i det här fallet är Get-WindowsFeature. Kommandots utdata returneras och standardiseras sedan för kompatibilitetskrav. När cmdleten har körts $env:PSModulePath anges tillbaka till den ursprungliga sökvägen.

# The Get-WindowsFeature cmdlet needs to be run through Windows PowerShell
# rather than through PowerShell, which is what the Policy engine runs.
$null = Invoke-Command -ScriptBlock {
    param ([string]$FileName)

    $InitialPSModulePath   = $env:PSModulePath
    $WindowsPSFolder       = "$env:SystemRoot\System32\WindowsPowershell\v1.0"
    $WindowsPSExe          = "$WindowsPSFolder\powershell.exe"
    $WindowsPSModuleFolder = "$WindowsPSFolder\Modules"
    $GetFeatureScriptBlock = {
        param([string]$FileName)

        if (Get-Command -Name Get-WindowsFeature -ErrorAction SilentlyContinue) {
            Get-WindowsFeature -Name Web-Server |
                ConvertTo-Json |
                Out-File $FileName
        } else {
            Add-Content -Path $FileName -Value 'NotServer'
        }
    }

    try {
        # Set env variable to include Windows PowerShell modules so we can find
        # the Get-WindowsFeature cmdlet.
        $env:PSModulePath = $WindowsPSModuleFolder
        # Call Windows PowerShell to get the info about the Web-Server feature
        & $WindowsPSExe -command $WindowsFeatureScriptBlock -args $FileName
    } finally {
        # Reset the env variable even if there's an error.
        $env:PSModulePath = $InitialPSModulePath
    }
}

Vanliga DSC-funktioner är inte tillgängliga under den offentliga förhandsversionen av datorkonfigurationen

Under den offentliga förhandsversionen har datorkonfigurationen inte stöd för att ange beroenden mellan datorer med hjälp av WaitFor* resurser. Det är inte möjligt för en dator att titta på och vänta tills en annan dator når ett tillstånd innan den fortsätter.

Omstartshantering är inte tillgängligt i den offentliga förhandsversionen av datorkonfigurationen, inklusive, är $global:DSCMachineStatus inte tillgänglig. Konfigurationer kan inte starta om en nod under eller i slutet av en konfiguration.

Kända kompatibilitetsproblem med moduler som stöds

Modulen PsDscResources i modulen PowerShell-galleriet och PSDesiredStateConfiguration som levereras med Windows stöds av Microsoft och har varit en vanlig uppsättning resurser för DSC. Tills PSDscResources-modulen har uppdaterats för DSCv3 bör du vara medveten om följande kända kompatibilitetsproblem.

  • Använd inte resurser från modulen PSDesiredStateConfiguration som levereras med Windows. Växla i stället till PSDscResources.
  • Använd WindowsFeatureinte resurserna , WindowsFeatureSet, WindowsOptionalFeatureoch WindowsOptionalFeatureSet i PsDscResources. Det finns ett känt problem med att läsa in DISM-modulen i PowerShell 7.1.3 på Windows Server som kräver en uppdatering.

Resurserna nx* för Linux som ingick i DSC för Linux-lagringsplatsen skrevs i en kombination av språken C och Python. Eftersom vägen framåt för DSC i Linux är att använda PowerShell är de befintliga nx* resurserna inte kompatibla med DSCv3. Tills en ny modul som innehåller resurser som stöds för Linux är tillgänglig måste du skapa anpassade resurser.

Samexistens med DSC version 3 och tidigare versioner

DSC version 3 i datorkonfigurationen kan samexistera med äldre versioner installerade i Windows och Linux. Implementeringarna är separata. Det finns dock ingen konfliktidentifiering i DSC-versioner, så försök inte hantera samma inställningar.

Nästa steg