Freigeben über

Änderungen am Verhalten in PowerShell Desired State Configuration für die Computerkonfiguration

  • Artikel

Bevor Sie anfangen, ist es empfehlenswert, den Überblick über die Computerkonfiguration zu lesen.

Für dieses Dokument ist ein Video zur exemplarischen Vorgehensweise verfügbar.

Die Computerkonfiguration verwendet die 3. Version derDesired State Configuration (DSC) von PowerShell, um Computer zu überprüfen und zu konfigurieren. Die DSC-Konfiguration definiert den Zustand, in dem sich der Computer befinden soll. Es gibt viele entscheidende Unterschiede bei der Implementierung von DSC in der Computerkonfiguration.

Die Computerkonfiguration verwendet plattformübergreifend PowerShell 7

Die Computerkonfiguration ist so konzipiert, dass eine einheitliche Verwaltung von Windows und Linux möglich ist. In beiden Betriebssystemumgebungen kann ein Benutzer mit PowerShell DSC-Kenntnissen die Konfigurationen mit skriptbasierten Fähigkeiten erstellen und veröffentlichen.

Die Computerkonfiguration verwendet nur die PowerShell DSC Version 3 und basiert nicht auf der vorherigen Implementierung von DSC für Linux oder den nx*-Anbietern, die in diesem Repository enthalten sind.

Ab Version 1.26.33 wird die Computerkonfiguration in PowerShell Version 7.1.2 für Windows und in der Vorschauversion 6 von PowerShell 7.2 für Linux betrieben. Ab der Version 7.2 wurde das Modul PSDesiredStateConfiguration nicht mehr als Teil der PowerShell-Installation installiert, sondern als Modul aus dem PowerShell-Katalog.

Mehrere Konfigurationen

Die Computerkonfiguration erlaubt die Zuweisung mehrerer Konfigurationen zum gleichen Computer. Innerhalb des Betriebssystems der Computerkonfigurationserweiterung sind keine besonderen Schritte erforderlich. Es ist nicht erforderlich, Teilkonfigurationenzu konfigurieren.

Verwaltung von Abhängigkeiten auf Konfigurationsebene

Wenn eine Konfiguration mithilfe der verfügbaren Tools gepackt wird, sind die für diese Konfiguration erforderlichen Abhängigkeiten in einer .zip-Datei enthalten. Computer extrahieren den Inhalt für die einzelnen Konfigurationen in einen eindeutigen Ordner. Der von der Computerkonfigurationserweiterung bereitgestellte Agent erstellt für jede Konfiguration eine dedizierte PowerShell-Sitzung. Dabei wird die Umgebungsvariable $Env:PSModulePath verwendet, die das automatische Laden von Modulen ausschließlich auf den Pfad beschränkt, unter dem das Paket extrahiert wurde.

Diese Änderung bietet mehrere Vorteile:

  • Die Verwendung verschiedener Modulversionen für die einzelnen Konfigurationen auf demselben Computer ist möglich.
  • Wenn eine Konfiguration auf einem Computer nicht mehr benötigt wird, löscht der Agent sicher den gesamten Ordner, in den die Konfiguration extrahiert wurde. Sie müssen freigegebene Abhängigkeiten nicht mehr über Konfigurationen hinweg verwalten.
  • Es müssen nicht mehrere Versionen eines Moduls in einem zentralen Dienst verwaltet werden.

Verwaltung von Artefakten als Pakete

Azure Automation State Configuration umfasst die Verwaltung von Artefakten für Module und Konfigurationsskripts. Sobald beide im Dienst veröffentlicht wurden, kann das Skript im MOF-Format kompiliert werden. Ähnlich verhielt es sich beim Windows-Pullserver, bei dem ebenfalls Konfigurationen und Module in der Webdienstinstanz verwaltet werden mussten. Die DSC-Erweiterung verfügt jedoch über ein vereinfachtes Modell, bei dem alle Artefakte zusammen gepackt und an einem Speicherort gespeichert werden, auf den vom Zielcomputer aus über eine HTTPS-Anforderung zugegriffen werden kann. Für das Hosting der Artefakte wird häufig gerne Azure Blob Storage verwendet.

Bei der Computerkonfiguration wird nur das vereinfachte Modell verwendet, bei dem alle Artefakte zusammen gepackt werden und über HTTPS vom Zielcomputer aus auf sie zugegriffen wird. Ein Veröffentlichen von Modulen oder Skripts oder Kompilieren im Dienst ist nicht erforderlich. Eine Änderung ist, dass das Paket immer eine kompilierte MOF-Datei enthalten muss. Es ist nicht möglich, eine Skriptdatei in das Paket einzuschließen und das Skript auf dem Zielcomputer zu kompilieren.

Die maximale Größe des benutzerdefinierten Konfigurationspakets

In Azure Automation State Configuration waren die DSC-Konfigurationen in Ihrer Größe begrenzt. Die Computerkonfiguration unterstützt eine Gesamtpaketgröße von 100 MB vor der Komprimierung. Es gibt keine spezielle Größenbeschränkung für die MOF-Datei im Paket.

Der Konfigurationsmodus wird im Paketartefakt festgelegt

Beim Erstellen des Konfigurationspakets wird der Modus mit den folgenden Optionen festgelegt:

  • Audit: Überprüft die Compliance eines Computers. Es sind keine Änderungen vorgenommen worden.
  • AuditandSet: Überprüft den Compliancezustand des Computers und korrigiert ihn. Es werden Änderungen vorgenommen, wenn der Computer nicht konform ist.

Der Modus wird im Paket und nicht im lokalen Configuration Manager-Dienst festgelegt, da jede Konfiguration mit einem anderen Modus angewendet werden kann.

Parameterunterstützung über den Azure Resource Manager

Parameter, die vom configurationParameter-Eigenschaftenarray in den Computerkonfigurationszuweisungen festgelegt werden, überschreiben den statischen Text in einer MOF-Konfigurationsdatei, sobald die Datei auf einem Computer gespeichert wird. Parameter ermöglichen Anpassungen und einem Operator die Steuerung von Änderungen über die Dienst-API, ohne dass Befehle auf dem Computer ausgeführt werden müssen.

Die Parameter in Azure Policy, die Werte an die Computerkonfigurationszuweisungen übergeben, müssen den Typ Zeichenfolge aufweisen. Arrays können nicht über Parameter übergeben werden. Dies gilt selbst dann, wenn die DSC-Ressource Arrays unterstützt.

Auslösen von außerhalb des Computers festlegen

Eine Herausforderung in früheren Versionen von DSC war die Korrektur von Drift im großen Stil ohne viel benutzerdefinierten Code und die Nutzung von WinRM-Remoteverbindungen. Die Gastkonfiguration löst dieses Problem. Benutzer der Computerkonfiguration können die Abweichungskorrektur durch On-Demand-Wiederherstellung steuern.

Sequenz beinhaltet Get-Methode

Wenn die Computerkonfiguration einen Computer überwacht oder konfiguriert, wird die gleiche Abfolge von Ereignissen sowohl für Windows als auch für Linux verwendet. Die wesentliche Änderung des Verhaltens ist, dass die Get-Methode vom Dienst aufgerufen wird, um die Details zum Zustand des Computers zurückzugeben.

  1. Der Agent führt zuerst Test aus, um zu ermitteln, ob die Konfiguration den richtigen Status aufweist.
  2. Wenn das Paket auf Audit festgelegt ist, bestimmt der von der Funktion zurückgegebene boolesche Wert, ob der Zustand von Azure Resource Manager für die Gastzuweisung Compliant oder NonCompliant sein soll.
  3. Wenn das Paket auf AuditandSet festgelegt ist, bestimmt der boolesche Wert, ob der Computer wiederhergestellt werden soll, indem die Konfiguration mithilfe der Set-Methode angewendet wird. Wenn die Test-Methode $false zurückgibt, wird Set ausgeführt. Wenn Test$true zurückgibt, wird Set nicht ausgeführt.
  4. Zuletzt führt der Anbieter Get aus, um den aktuellen Zustand der einzelnen Einstellungen zurückzugeben. Dadurch sind Details dazu verfügbar, warum ein Computer nicht konform ist und um zu bestätigen, dass der aktuelle Zustand konform ist.

Besondere Anforderungen an Get

Die DSC-Methode Get hat spezielle Anforderungen an die Computerkonfiguration, die für DSC nicht erforderlich waren.

  • Die zurückgegebene Hashtabelle sollte eine Eigenschaft namens Reasons (Gründe) enthalten.
  • Die Reasons-Eigenschaft muss ein Array sein.
  • Jedes Element im Array sollte eine Hashtabelle mit Schlüsseln namens Code und Phrase sein.
  • Es sollten keine anderen Werte als die Hashtabelle zurückgegeben werden.

Die Eigenschaft Reasons wird vom Dienst verwendet, um die Konformität von Informationen zu standardisieren. Sie können sich jedes Element in Reasons als Nachricht darüber vorstellen, in welcher Weise die Ressource konform oder nicht konform ist. Die Eigenschaft ist ein Array, da eine Ressource aus mehr als einem Grund nicht konform sein könnte.

Die Eigenschaften Code und Phrase werden vom Dienst erwartet. Wenn Sie eine benutzerdefinierte Ressource erstellen, legen Sie den auszugebenden Text als Grund für die fehlende Konformität der Ressource als Wert für Phrase fest. Code weist bestimmte Formatierungsanforderungen auf, sodass die Berichterstellung eindeutig Informationen zur Ressource anzeigen kann, die für die Überwachung verwendet wird. Diese Lösung macht die Gastkonfiguration erweiterbar. Sie können beliebige Befehle ausführen. Die einzige Voraussetzung ist, dass die Ausgabe des Befehls als Zeichenfolgenwert für die Eigenschaft Phrase zurückgegeben werden kann.

  • Code (Zeichenfolge): Der Name der Ressource, wiederholt, und dann ein Kurzname ohne Leerzeichen als Bezeichner für den Grund. Diese drei Werte sollten ohne Leerzeichen durch Doppelpunkte getrennt sein.
    • Ein Beispiel wäre registry:registry:keynotpresent
  • Phrase (Zeichenfolge): Für Menschen lesbarer Text, um zu erläutern, warum die Einstellung nicht konform ist.
    • Ein Beispiel wäre The registry key $key isn't present on the machine.
$reasons = @()
$reasons += @{
  Code   = 'Name:Name:ReasonIdentifer'
  Phrase = 'Explain why the setting is not compliant'
}
return @{
    reasons = $reasons
}

Wenn Sie Befehlszeilentools verwenden, um Informationen abzurufen, die in Get zurückgegeben werden, werden Sie möglicherweise feststellen, dass das Tool Ausgaben zurückgibt, die Sie nicht erwartet haben. Auch wenn Sie die Ausgabe in PowerShell erfassen, wurde möglicherweise auch eine Ausgabe in den Standardfehler geschrieben. Um dieses Problem zu vermeiden, sollten Sie erwägen, die Ausgabe an NULL umzuleiten.

Die eingebettete Reasons-Eigenschaftsklasse

In skriptbasierten Ressourcen (nur für Windows) ist die Reasons-Klasse wie folgt in der MOF-Schemadatei enthalten.

[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[];
};

In klassenbasierten Ressourcen (für Windows und Linux) ist die Reason-Klasse wie folgt im PowerShell-Modul enthalten. Bei Linux wird die Groß-/Kleinschreibung beachtet, sodass das C in Code und das P in Phrase großgeschrieben werden muss.

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
  }
}

Wenn die Ressource über erforderliche Eigenschaften verfügt, müssen diese Eigenschaften auch von Get parallel zur Klasse Reason zurückgegeben werden. Wenn Reason nicht eingeschlossen ist, enthält der Dienst ein „Catch-All“-Verhalten, das die Werteingaben von Get mit den von Get zurückgegebenen Werten vergleicht und einen ausführlichen Vergleich als Reason (Grund) bereitstellt.

Konfigurationsnamen

Der Name der benutzerdefinierten Konfiguration muss überall einheitlich sein. Diese Elemente müssen denselben Namen haben:

  • Die .zip-Datei für das Inhaltspaket
  • Der Konfigurationsname in der MOF-Datei
  • Der Name der Computerkonfigurationszuweisung in der Azure Resource Manager-Vorlage

Ausführen von Befehlen in Windows PowerShell

Windows-Module in PowerShell können mithilfe des folgenden Musters in Ihren DSC-Ressourcen ausgeführt werden. Das folgende Muster legt PSModulePath vorübergehend so fest, dass Windows PowerShell anstelle von PowerShell ausgeführt wird, um erforderliche Module zu ermitteln, die in Windows PowerShell verfügbar sind. Dieses Beispiel ist ein angepasster Codeausschnitt aus der DSC-Ressource, die in der integrierten DSC-Ressource Sicherer Webserver verwendet wird.

Dieses Muster legt den PowerShell-Ausführungspfad vorübergehend so fest, dass die Ausführung über die Windows PowerShell erfolgt und das erforderliche Cmdlet ermittelt wird. In diesem Fall ist das Get-WindowsFeature. Die Ausgabe des Befehls wird zurückgegeben und dann für die Kompatibilitätsanforderungen standardisiert. Nachdem das Cmdlet ausgeführt wurde, wird $env:PSModulePath auf den ursprünglichen Pfad zurückgesetzt.

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

Allgemeine DSC-Funktionen, die während der öffentlichen Vorschau der Computerkonfiguration nicht verfügbar sind

In der öffentlichen Vorschau wird die Angabe computerübergreifender Abhängigkeiten mit WaitFor*-Ressourcen nicht durch die Computerkonfiguration unterstützt. Es ist nicht möglich, dass ein Computer einen anderen Computer überwacht und darauf wartet, dass dieser einen Zustand erreicht, bevor er fortfährt.

Die Neustartbehandlung ist in der öffentlichen Vorschauversion der Computerkonfiguration einschließlich $global:DSCMachineStatus nicht verfügbar. Die Konfigurationen können einen Knoten während oder am Ende einer Konfiguration nicht neu starten.

Die bekannten Kompatibilitätsprobleme mit unterstützten Modulen

Das Modul PsDscResources im PowerShell-Katalog und das Modul PSDesiredStateConfiguration, das mit Windows geliefert wird, werden von Microsoft unterstützt und sind eine häufig verwendete Gruppe von Ressourcen für DSC. Beachten Sie die folgenden bekannten Kompatibilitätsprobleme, bis das Modul PSDscResources für DSCv3 aktualisiert wurde.

  • Verwenden Sie keine Ressourcen aus dem mit Windows bereitgestellten Modul PSDesiredStateConfiguration. Wechseln Sie stattdessen zu PSDscResources.
  • Verwenden Sie nicht die Ressourcen WindowsFeature, WindowsFeatureSet, WindowsOptionalFeature und WindowsOptionalFeatureSet in PsDscResources. Es gibt ein bekanntes Problem beim Laden des DSIM-Moduls in PowerShell 7.1.3 unter Windows Server, das ein Update erforderlich macht.

Die nx*-Ressourcen für Linux, die im DSC für Linux-Repository enthalten waren, wurden in einer Kombination der Sprachen C und Python geschrieben. Da die Pfadweiterleitung für DSC unter Linux die Verwendung von PowerShell ist, sind die vorhandenen nx*-Ressourcen mit DSCv3 nicht kompatibel. Bis ein neues Modul verfügbar ist, das unterstützte Ressourcen für Linux enthält, ist es erforderlich, benutzerdefinierte Ressourcen zu erstellen.

Gleichzeitige Verwendung von Version 3 und früheren Versionen von DSC

Die DSC Version 3 in der Computerkonfiguration kann gleichzeitig mit älteren Versionen vorhanden sein, die in Windows und Linux installiert sind. Die Implementierungen sind getrennt. Es gibt jedoch keine Konflikterkennung über die DSC-Versionen hinweg. Versuchen Sie daher nicht, die gleichen Einstellungen zu verwalten.

Nächste Schritte