Nur ein weiteres Tool: Kennenlernen der Dienstkonfiguration mit Desired State Configuration 

Desired State Configuration (DSC) ist ein Tool zur Verwaltung der Serverkonfiguration. Damit können Sie den Server konfigurieren (Änderungen an der Registrierung vornehmen, Dateien kopieren, Komponenten installieren und entfernen), den aktuellen Status der Einstellungen überwachen und schnell zu den Grundeinstellungen zurückkehren.

DSC ist interessant für diejenigen, die den DevOps-Ansatz verfolgen. Dieses Tool passt gut zur Infrastruktur als Code-Paradigma: Entwickler können ihre Anforderungen zur Konfiguration hinzufügen und in das Versionskontrollsystem aufnehmen, und Teams können den Code ohne „manuelle“ Prozesse bereitstellen.

Zusammen mit Stanislav Buldakov von der RaiffeisenbankWir haben unsere Erfahrungen mit der DSC-Engine kombiniert und in zwei Artikel unterteilt. Im ersten Teil werden wir die Grundprinzipien der Arbeit analysieren und die Verwendungsmerkmale anhand praktischer Beispiele kennenlernen:

  • "Packen Sie die Box aus" mit der DSC-Engine, sehen Sie, welche Ressourcen standardmäßig vorhanden sind, und zeigen Sie, wo Sie zusätzliche Ressourcen erhalten.
  • Lassen Sie uns sehen, wie die Konfiguration in DSC beschrieben wird. 
  • Wir werden lernen, wie der integrierte Agent Local Configuration Manager Konfigurationen auf dem Server anwendet, und zeigen, wie er mithilfe von Metakonfigurationen konfiguriert wird.
  • Kommen wir zu komplexeren Konfigurationsfällen: Teilkonfigurationen und Stub-Konfigurationen.



DSC ist ein leichter und schneller Motor. Mit ihm können Sie beispielsweise .NET Framework 3.5 auf virtuellen Maschinen viel schneller installieren. Folgendes hilft ihm dabei, den Dienstkonfigurationsprozess zu beschleunigen:

  • « » Windows PowerShell. 
    DSC PowerShell Windows Management Framework. Linux . , PowerShell. 
  • , . 
    , , , . DSC. 
  • , .
    DSC , . .

Konfigurationen werden immer nacheinander ohne Bedingungen und Verzweigungen durchgeführt. Daher sieht der DSC-Operationsalgorithmus kurz wie folgt aus:

  1. Konfigurieren Sie Local Configuration Manager (LCM) . Dies ist der integrierte Agent, der für das Anwenden von Konfigurationen auf den Server verantwortlich ist. Wir sagen ihm, wie die deklarierten Konfigurationen funktionieren sollen und in welcher Reihenfolge. 
  2. Wenn zusätzliche Ressourcen benötigt werden, installieren und verbinden Sie diese im Voraus.
  3. In deklarativer Form schreiben wir die Konfigurationsreihenfolge. 
  4. Wir senden die Konfiguration im Format der MOF-Datei.
  5. Wir senden die Konfiguration an den frisch bereitgestellten oder vorhandenen Zielserver.
  6. LCM erhält die Konfiguration (MOF-Datei) sowie Anweisungen zum Einrichten des LCM.
  7. Die Konfiguration wird sofort von unserem Team übernommen.


Ein vereinfachtes Diagramm der DSC-Architektur.

Wir werden unsere Bekanntschaft mit dem Motor beginnen, indem wir die vordefinierten Ressourcen untersuchen. Versuchen Sie als nächstes, die Konfiguration zu schreiben.

DSC-Ressourcen 


DSC-Ressourcen sind eine Art Analogon zu PowerShell-Modulen. Jeder Windows-Server verfügt bereits über einen vordefinierten Satz von DSC-Ressourcen, die sich im selben Verzeichnis wie die PowerShell-Module befinden. Die Liste kann über das Cmdlet Get-DscResourse abgerufen werden. So sieht diese Liste unter Windows 10 1809 aus:
 
PS C:\windows\system32> Get-DscResource | Sort-Object -Property Name | ft ImplementedAs, Name -a
 
ImplementedAs Name
------------- ----
   PowerShell Archive
   PowerShell Environment
       Binary File
   PowerShell Group
    Composite GroupSet
       Binary Log
   PowerShell Package
   PowerShell PackageManagement
   PowerShell PackageManagementSource
    Composite ProcessSet
   PowerShell Registry
   PowerShell Script
   PowerShell Service
    Composite ServiceSet
       Binary SignatureValidation
   PowerShell User
   PowerShell WaitForAll
   PowerShell WaitForAny
   PowerShell WaitForSome
   PowerShell WindowsFeature
    Composite WindowsFeatureSet
   PowerShell WindowsOptionalFeature
    Composite WindowsOptionalFeatureSet
   PowerShell WindowsPackageCab
   PowerShell WindowsProcess

Die Namen der Ressourcen geben einen Überblick darüber, womit sie arbeiten: 

  • Archiv - mit Ein- und Auspacken von Archiven;
  • Umgebung - mit Umgebungsvariablen;
  • Datei - mit Dateien;
  • Gruppe - mit lokalen Benutzergruppen;
  • Protokoll - mit Protokollen;
  • Paket - mit Softwarepaketen;
  • Registrierung - mit Registrierungsschlüsseln und deren Status;
  • Service - mit Services und deren Status;
  • Benutzer - mit lokalen Benutzerkonten;
  • WindowsFeature — Windows Server;
  • WindowsProcess — Windows;
  • Script —  PowerShell- . 3 : SetScript — -, TestScript — , , GetScript — .

In den meisten Fällen reichen sofort einsatzbereite DSC-Ressourcen nicht aus . In diesem Fall können Sie Ihre eigenen Skripte für alles schreiben, was über das Standardmodul hinausgeht. Um das Rad nicht neu zu erfinden, können Sie DSC-Ressourcen verwenden, die von anderen Entwicklern geschrieben wurden. Zum Beispiel von hier https://github.com/PowerShell/DscResources oder von PSGallery
 
So installieren Sie zusätzliche Ressourcen . Wir verwenden das Cmdlet Install-Module . Beim Installieren von Ressourcen werden einfach Ressourcendateien entlang eines der Pfade in der Umgebungsvariablen $ env: PSModulePath kopiert . Installierte Ressourcen werden beim Kompilieren nicht automatisch verbunden, daher werden wir sie später zusätzlich in der Konfiguration selbst verbinden.

Um eine Ressource zu verwenden, müssen Sie sie lokal und auf dem Zielserver installieren. In lokalen Infrastrukturen verbietet eine Sicherheitsrichtlinie normalerweise den Internetzugang für Server. In diesem Fall kann der DSC-Server keine zusätzlichen Ressourcen aus externen Quellen laden. Um Archive mit Modulen zu veröffentlichen, stellen wir ein lokales NuGet-Repository oder einen regulären Webserver bereit. Sie können zusätzliche Ressourcen für den Webserver installieren, indem Sie das Modul in das Verzeichnis C: \ Programme \ WindowsPowerShell \ Modules \
entpacken. Genau das tut das Cmdlet Install-Module.

Im zweiten Artikel werden wir uns den Unterschied zwischen den Einstellungen für den Push- und den Pull-Modus genauer ansehen. 

Einfache Analyseanalyse


Die Konfiguration ist eine einfache, konsistente Beschreibung dessen, was auf dem Server zu tun ist. So sieht eine einfache DSC-Konfiguration aus: 

Configuration EnvironmentVariable_Path
{
param ()
Import-DscResource -ModuleName 'PSDscResources'
Node localhost
    {
        Environment CreatePathEnvironmentVariable
        {
            Name = 'TestPathEnvironmentVariable'
            Value = 'TestValue'
            Ensure = 'Present'
            Path = $true
            Target = @('Process', 'Machine')
        }
    }
}
EnvironmentVariable_Path -OutputPath:"C:\EnvironmentVariable_Path"

Lassen Sie uns für ihr Beispiel sehen, woraus die Konfiguration besteht.

Der Konfigurationsblock ist eine spezielle Art von PowerShell-Funktion, die beschreibt, was wir erhalten möchten. 

Innerhalb des Blocks enthält: 

  • param - Block mit den Parametern , die intern verwendet werden können; 
  • Block mit zusätzlichen PowerShell-Aufrufen. Hier führen wir zu Beginn der Konfiguration immer Import-Resource aus , um zusätzliche Ressourcen zu verbinden.
  • Blöcke mit Einstellungen für bestimmte Node $ Servername- Server

Innerhalb des Knotenblocks geben wir an, welche Ressourcen auf einem bestimmten Server konfiguriert werden sollen. Im obigen Beispiel wird eine Umgebungsvariable mithilfe einer regulären Umgebungsressource erstellt.

Schauen wir uns die Syntax einer bestimmten Ressource mit dem Befehl Get-DscResource -Name Environment -Syntax genauer an:
 

PS C:\windows\system32> Get-DscResource -Name Environment -Syntax
Environment [String] #ResourceName
{
    Name = [string]
    [DependsOn = [string[]]]
    [Ensure = [string]{ Absent | Present }]
    [Path = [bool]]
    [PsDscRunAsCredential = [PSCredential]]
    [Value = [string]]
}

In diesem Beispiel: 

  • Name - Der Name der Umgebungsvariablen.
  • In DependsOn geben wir die Abhängigkeit von anderen Ressourcen an. Es ist wichtig zu beachten, dass der Vorgang erst ausgeführt wird, wenn die hier angegebene Ressource abgeschlossen ist. 
  • In Sicherstellen geben wir die Konfigurationsbedingungen an. Wenn eine solche Variable fehlt, werden wir sie erstellen. Wenn es vorhanden ist, wird diese Ressource nicht konfiguriert.
  • Der Pfad gibt an, ob die Umgebungsvariable einen Pfad enthält. 
  • In PsDscRunAsCredential wurden Anmeldeinformationen angegeben.
  • Wert - Der Wert der Umgebungsvariablen. 
  • Das Ziel kann angegeben werden, auf wen die Konfiguration angewendet wird.

So starten Sie die Kompilierung . Wir nennen die Konfiguration einfach beim Namen mit den notwendigen Parametern. Das Ergebnis ist eine Mof-Datei, die von der DSC-Engine weiter zum Konfigurieren eines bestimmten Servers verwendet wird:
 
PS C:\windows\system32> EnvironmentVariable_Path -OutputPath:"C:\EnvironmentVariable_Path"
 
    Directory: C:\EnvironmentVariable_Path
 
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       25.02.2020     14:05           2172 localhost.mof

Konfigurieren Sie Local Configuration Manager


Der lokale Konfigurationsmanager ist für die Anwendung der Konfigurationen verantwortlich, die wir in mof-Dateien kompiliert haben. Er überwacht die Erhaltung des in der Konfiguration definierten Zustands. Wenn das System diesen Status verlässt, ruft LCM den Code in den Ressourcen auf, um den angegebenen Status wiederherzustellen. 

Sehen wir uns die Einstellungen des lokalen Konfigurationsmanagers über Get-DscLocalConfigurationManager an:
 
PS C:\windows\system32> Get-DscLocalConfigurationManager
 
ActionAfterReboot              : ContinueConfiguration
AgentId                        : 1FB3A2EE-57C9-11EA-A204-58A023EF3A48
AllowModuleOverWrite           : False
CertificateID                  :
ConfigurationDownloadManagers  : {}
ConfigurationID                :
ConfigurationMode              : ApplyAndMonitor
ConfigurationModeFrequencyMins : 15
Credential                     :
DebugMode                      : {NONE}
DownloadManagerCustomData      :
DownloadManagerName            :
LCMCompatibleVersions          : {1.0, 2.0}
LCMState                       : Idle
LCMStateDetail                 :
LCMVersion                     : 2.0
StatusRetentionTimeInDays      : 10
SignatureValidationPolicy      : NONE
SignatureValidations           : {}
MaximumDownloadSizeMB          : 500
PartialConfigurations          :
RebootNodeIfNeeded             : False
RefreshFrequencyMins           : 30
RefreshMode                    : PUSH
ReportManagers                 : {}
ResourceModuleManagers         : {}
PSComputerName                 :

  • RefreshMode enthält den LCM-Betriebsmodus - Push oder Pull. Wir werden im zweiten Artikel mehr über Modi sprechen.
  • ConfigurationMode zeigt den aktuellen Konfigurationsanwendungsmodus an. In unserem Fall ist es ApplyAndMonitor - Änderungen anwenden und verfolgen. ApplyOnly-Modi sind ebenfalls verfügbar (LCM verfolgt keine Konfigurationsänderungen) und ApplyAndAutocorrect-Modi (LCM verfolgt Änderungen nicht nur, sondern setzt sie auch auf die Basiskonfiguration zurück).
  • RebootNodeIfNeeded - kann den Server nach Abschluss der Konfiguration neu starten , falls erforderlich, um die Einstellungen zu übernehmen. 
  • ConfigurationModeFrequencyMins - Legt fest, wie oft LCM nach Konfigurationsänderungen sucht.

Ändern Sie die LCM-Einstellungen in der Metakonfiguration. Hier ist ihr Beispiel:
 

Configuration LCMConfiguration
{
   Node Localhost
   {
       LocalConfigurationManager
       {
           RebootNodeIfNeeeded = $True
       }
   }
}
LCMConfiguration

Gleiches gilt für die neueste Version von WMF mit Kommentaren:


 
[DSCLocalConfigurationManager()]
Configuration LCMConfiguration
{
   param
   (
       [string[]]$Server = "localhost"
   )

 

#  LCM:
#  ,  
# : PUSH
#    30 
   Node $Server
   {
       Settings
       {
           RebootNodeIfNeeded = $True
           RefreshMode        = 'Push'
           RefreshFrequencyMins = 30
       }
   }
}


#   
LCMConfiguration -Server "localhost" -OutputPath "C:\DSC\MetaConfigurations\EnvironmentVariable_Path\"

Features Metakonfiguration . Beim Schreiben einer Metakonfiguration verwenden wir dieselben Blöcke wie bei einer regulären DSC-Konfiguration. Die Ausnahme ist der interne Block LocalConfigurationManager (v4) oder das Attribut DSCLocalConfigurationManager (v5) für einen bestimmten Server. Sie beschreiben alle notwendigen Einstellungen. 

Die Metakonfiguration wird ebenfalls in eine mof-Datei kompiliert. Zur Verwendung wird jedoch das Cmdlet Set-DSCLocalConfigurationManager und nicht Start-DSCConfiguration verwendet.
 
PS C:\windows\system32> LCMConfiguration -OutputPath C:\EnvironmentVariable_Path\
 
    Directory: C:\EnvironmentVariable_Path
 
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       26.02.2020     20:05           1016 Localhost.meta.mof

 

PS C:\windows\system32> Set-DscLocalConfigurationManager -Path C:\EnvironmentVariable_Path\
PS C:\windows\system32> Get-DscLocalConfigurationManager
 
RebootNodeIfNeeded             : True

Theoretisch hindert uns nichts daran, die Konfiguration von LCM und konventionellen Ressourcen in derselben Konfiguration zu kombinieren. Der Einfachheit halber wird jedoch empfohlen, Rechtschreibung und Anwendung von Konfiguration und Metakonfiguration zu trennen.

Teilkonfigurationen 


Teilkonfigurationen - mehrere Konfigurationen, die nacheinander ausgeführt werden. Sie sind nützlich, wenn mehrere Teams am Service arbeiten. Jeder der Befehle gibt die Einstellungen für seinen Teil des Dienstes an, und die Teilkonfiguration wendet dann alle Einstellungen nacheinander an. In den LCM-Einstellungen geben wir Teilkonfigurationen in PartialConfigurations an

In Teilkonfigurationen müssen wir die einfache DSC-Logik berücksichtigen. Die Engine erlaubt keine Verzweigung, daher werden zusätzliche Ressourcen benötigt, um verschiedene Bedingungen zu erfüllen. Wir werden dies anhand einiger Beispiele analysieren. 

Angenommen, wir möchten die Konfiguration garantiert an den Server liefern und gemäß dem folgenden Algorithmus vorgehen:

  1. Überprüfen Sie zunächst, ob die erforderlichen Module auf dem Server installiert sind.
  2. Wir führen die Konfiguration durch, die den Server in den gewünschten Zustand bringt.

So sieht eine Metakonfiguration mit mehreren aufeinander folgenden Konfigurationen aus:


#   
[DSCLocalConfigurationManager()]
configuration MetaPushConfig
{
param
   (
       [ValidateNotNullOrEmpty()]
       [string] $NodeName = 'localhost'
   )

 

   Node $NodeName
   {
 	
 #      LCM,    
       PartialConfiguration ModulesDownloadConfig
       {
               Description = 'Download and install modules'
               RefreshMode = 'Push'
       }

 

       #        
       PartialConfiguration ServerOSConfig
       {
               DependsOn = "[PartialConfiguration]ModulesDownloadConfig"
               Description = 'Configuration'
               RefreshMode = 'Push'
       }

 

       #   LCM
       Settings
       {
               RefreshMode        = 'Push'
               RefreshFrequencyMins = 30
               RebootNodeIfNeeded = $true
       }
   }
}

 
 

#  
MetaPushConfig -NodeName "NewServer.contoso.com" -OutputPath c:\DSC\MetaConfigurations

 

#      
$cred = (Get-Credential -UserName Administrator -Message "Enter admin credentials")

 

#  LCM   
Set-DscLocalConfigurationManager -ComputerName "NewServer.contoso.com" -Credential $cred -Path "c:\DSC\MetaConfigurations" -Verbose -Force

 

#  
Publish-DscConfiguration c:\DSC\Configurations\ModulesDownloadConfig -ComputerName "NewServer.contoso.com" -Credential $cred -Force
Publish-DscConfiguration c:\DSC\Configurations\ServerOSConfig -ComputerName "NewServer.contoso.com" -Credential $cred -Force

 

#    
Start-DscConfiguration -UseExisting -ComputerName "NewServer.contoso.com" -Credential $cred -Force -Verbose

Im ersten Teil der Konfiguration heißt es : Modul herunterladen und installieren: Laden Sie die erforderlichen Ressourcen herunter und installieren Sie sie. Der zweite Teil von ServerOSConfig bringt den Server in den gewünschten Zustand. Was sind die Nuancen der DSC-Unkompliziertheit hier: 

  1. Wenn der erste Teil der Konfiguration anfänglich FALSE zurückgegeben und vollständig abgeschlossen hat, wechselt LCM nicht zur zweiten Konfiguration. Gemäß der DSC-Logik müssen Sie zuerst den Server in den ersten beschriebenen Zustand bringen. 
    Vorgehensweise: Führen Sie die Konfiguration zweimal aus oder automatisieren Sie den gesamten Prozess in einem Skript.
  2. Wenn der Server nach der Installation einer Komponente einen Neustart erfordert, wird die Konfiguration erst fortgesetzt, wenn wir den Server selbst neu starten. Selbst wenn wir LCM mitteilen, dass RebootNodeIfNeeeded = $ True ist, wartet der Agent während der Konfiguration auf unsere Lösung. Vorgehensweise
    : Die xPendingReboot- Ressource wird gerettet , die den Registrierungsschlüssel beim Neustart steuert. Diese Ressource startet den Server für uns neu.

Hier ist eine Beispielkonfiguration zum Herunterladen und Installieren von Ressourcen im Szenario „Bloody Enterprise“, wenn der Server keinen Internetzugang hat. Es wird das Vorhandensein eines Webservers vorausgesetzt, auf dem vorab heruntergeladene Ressourcen über das http-Protokoll für alle verfügbar sind.


Configuration ModulesDownloadConfig
{
   param
   (
       [string[]]$Server
   )

 

   #   
   Import-DscResource -ModuleName "PSDesiredStateConfiguration"

 

   #  
   Node $Server
   {
       #  IE Security
       Registry DisableIEESC-Admin {
           Key = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}"
           ValueName = "IsInstalled"
           Ensure = "Present"
           ValueData = 0
           ValueType = "DWORD"
       }

 

       Registry DisableIEESC-User {
           Key = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}"
           ValueName = "IsInstalled"
           Ensure = "Present"
           ValueData = "0"
           ValueType = "DWORD"
       }

 

	
 #    ,    
       File CreateDistribDir {
           Ensure          = "present"
           DestinationPath = "C:\Install\PSModules"
           Type            = "Directory"
       }

 

	
 #   NetworkingDsc (<a href="https://www.powershellgallery.com/packages/NetworkingDsc/8.0.0-preview0004">https://www.powershellgallery.com/packages/NetworkingDsc/8.0.0-preview0004</a>),      
       Script NetworkingDscDownLoad {
           SetScript = { Invoke-WebRequest -Uri "http://repo.contoso.com/repo/modules/NetworkingDsc.zip" -OutFile "C:\Install\PSModules\NetworkingDsc.zip" }
           GetScript = { return @{ Result = Test-Path "C:\Install\PSModules\NetworkingDsc.zip"
               GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript
               }
           }
           TestScript = { Test-Path "C:\Program Files\WindowsPowerShell\Modules\NetworkingDsc" }
       }

 

 #   NetworkingDsc  C:\Program Files\WindowsPowerShell\Modules
       Archive UnpackNetworkingDsc {
           Ensure = "Present"
           DependsOn = "[Script]NetworkingDscDownLoad"
           Path = "C:\Install\PSModules\NetworkingDsc.zip"
           Destination = "C:\Program Files\WindowsPowerShell\Modules\"
       }

 

 #   ComputerManagementDsc (<a href="https://www.powershellgallery.com/packages/ComputerManagementDsc/8.2.1-preview0001">https://www.powershellgallery.com/packages/ComputerManagementDsc/8.2.1-preview0001</a>),      
       Script ComputerManagementDscDownLoad {
           SetScript = { Invoke-WebRequest -Uri "http://repo.contoso.com/repo/modules/ComputerManagementDsc.zip" -OutFile "C:\Install\PSModules\ComputerManagementDsc.zip" }
           GetScript = { return @{ Result = Test-Path "C:\Install\PSModules\ComputerManagementDsc.zip"
               GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript
               }
           }
           TestScript = { Test-Path "C:\Program Files\WindowsPowerShell\Modules\ComputerManagementDsc" }
       }

 

	
 #   ComputerManagementDsc  C:\Program Files\WindowsPowerShell\Modules
       Archive UnpackComputerManagementDsc {
           Ensure = "Present"
           DependsOn = "[Script]ComputerManagementDscDownLoad"
           Path = "C:\Install\PSModules\ComputerManagementDsc.zip"
           Destination = "C:\Program Files\WindowsPowerShell\Modules\"
       }

 

	
 #   xPendingReboot (<a href="https://www.powershellgallery.com/packages/xPendingReboot/0.4.0.0">https://www.powershellgallery.com/packages/xPendingReboot/0.4.0.0</a>),      
       Script xPendingRebootDownLoad {
           SetScript = { Invoke-WebRequest -Uri "http://repo.contoso.com/repo/modules/xPendingReboot.zip" -OutFile "C:\Install\PSModules\xPendingReboot.zip" }
           GetScript = { return @{ Result = Test-Path "C:\Install\PSModules\xPendingReboot.zip"
               GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript
               }
           }
           TestScript = { Test-Path "C:\Program Files\WindowsPowerShell\Modules\xPendingReboot" }
       }

 

	
 #   xPendingReboot  C:\Program Files\WindowsPowerShell\Modules
       Archive UnpackxPendingReboot {
           Ensure = "Present"
           DependsOn = "[Script]xPendingRebootDownLoad"
           Path = "C:\Install\PSModules\xPendingReboot.zip"
           Destination = "C:\Program Files\WindowsPowerShell\Modules\"
       }
   }
}

Über Sicherheit


Das fette Minus von DSC am Boden ist das Fehlen von Run As Accounts. Dieser Mechanismus speichert Konten sicher in Form von Benutzername + "Salt Hash des Passworts" und leitet sie an den Dienst weiter, der für die Authentifizierung verantwortlich ist. Ohne diese Funktion kann DSC keine Konten für einen anderen Dienst verwalten. Und wenn wir uns unter einem Konto mit besonderen Berechtigungen authentifizieren müssen, ist der Automatisierungsprozess sehr kompliziert. Dies ist beispielsweise der Fall, wenn Sie den Server in die Domäne eingeben.

Alles zu unserer Verfügung:

  • Anmeldeinformationen werden im Nur-Text-Format gespeichert.
  • verschlüsselte Anmeldeinformationen funktionieren nur auf dem PC, auf dem sie generiert wurden.

In der Praxis gibt es mehrere Lösungen. 


"Stubs" sind gut, wenn die Vorhersagbarkeit des Serververhaltens sichergestellt werden muss.
In mehreren Fällen führen wir nach der Serverkonfiguration einen „Stub“ durch, wenn wir Folgendes verwendet haben:

  • Neustart (xPendingReboot-Ressource) 
  • Übertragung von Anmeldeinformationen 
  • andere Ressourcen, die die Leistung des Servers in Bezug auf ungeplante Neustarts oder Sicherheit beeinträchtigen können.

Erstellen Sie dazu Konfigurationen OHNE Blöcke, die die xPendingReboot-Ressource und Konfigurationen mit Anmeldeinformationen enthalten, und veröffentlichen Sie sie erneut.

Dieser Ansatz gilt nur für das Push-Szenario, da Pull ziemlich einfach ist und keine sofortige Konfigurationsänderung impliziert. Im nächsten Artikel vonbuldakovWir werden uns die Einstellungen und Funktionen der Arbeit im Push- und Pull-Modus genauer ansehen.

Außerdem werden die Nuancen der DSC-Technologie und die Grenzen ihrer Anwendung am 28. Mai um 18.00 Uhr beim ersten Online-Treffen der DGTL Communications Raiffeisenbank-Community erörtert. Während des Meetings werden wir darüber sprechen, wie Sie ELK- und Exchange-Freunde finden und was Microsoft Endpoint Manager in der Geräteverwaltung tun kann. Hier ist die Registrierung für den Mitap .

All Articles