Migrieren von vorhandenen Agent-basierten Hybrid Workern zu erweiterungsbasierten Hybrid Workern

  • Artikel

Wichtig

Der Azure Automation Agent-basierte Benutzer-Hybrid Runbook Worker (Windows und Linux) wird am 31. August 2024 eingestellt und wird nach diesem Datum nicht mehr unterstützt. Sie müssen die Migration vorhandener Agent-basierter Benutzer-Hybrid Runbook Worker zu erweiterungsbasierten Workern vor dem 31. August 2024 abschließen. Darüber hinaus ist ab dem 1. November 2023 das Erstellen neuer Agent-basierter Hybrid Worker nicht mehr möglich. Weitere Informationen

In diesem Artikel werden die Vorteile des erweiterungsbasierten Hybrid Runbook Workers und die Migration vorhandener Agent-basierter Benutzerhybrid-Runbook-Worker zu erweiterungsbasierten Hybrid-Workern beschrieben.

Es gibt nun zwei Hybrid Runbook Worker-Installationsplattformen, die von Azure Automation unterstützt werden:

  • Agent-basierter Hybrid-Runbook-Worker (V1) – Der Agent-basierte Hybrid-Runbook-Worker hängt vom Log Analytics-Agent ab.
  • Erweiterungsbasierter Hybrid-Runbook-Worker (V2) – Der erweiterungsbasierte Hybrid-Runbook-Worker bietet native Integration der Hybrid-Runbook-Workerrolle über das Erweiterungsframework für virtuelle Computer (VM). 

Der Prozess der Ausführung von Runbooks für Hybrid Runbook Workers bleibt für beide identisch.

Vorteile erweiterungsbasierter Benutzer-Hybrid Runbook Worker gegenüber Agent-basierten Workern

Der erweiterungsbasierte Ansatz dient dazu, die Installation und Verwaltung der Hybrid Worker zu vereinfachen und die Komplexität gegenüber der Arbeit mit der Agent-basierten Version zu verringern. Im Folgenden finden Sie einige wichtige Vorteile:

  • Nahtloses Onboarding: Der Agent-basierte Ansatz für das Onboarding von Hybrid Runbook Workern hängt vom Log Analytics-Agent ab, bei dem es sich um einen mehrstufigen, zeitaufwändigen und fehleranfälligen Prozess handelt. Der erweiterungsbasierte Ansatz bietet mehr Sicherheit und ist nicht mehr vom Log Analytics-Agent abhängig.

  • Einfache Verwaltbarkeit: Bietet native Integration in die Azure Resource Manager (ARM)-Identität für Hybrid Runbook Worker sowie die Flexibilität für Governance im großen Stil mittels Richtlinien und Vorlagen.

  • Microsoft Entra ID-basierte Authentifizierung: Verwendet eine systemseitig zugewiesene verwaltete VM-Identität, die von Microsoft Entra ID bereitgestellt wird. Damit wird die Steuerung und Verwaltung von Identitäten und Ressourcenanmeldeinformationen zentralisiert.

  • Einheitliche Benutzeroberfläche: Bietet eine identische Erfahrung für die Verwaltung von Azure-Computern sowie von Nicht-Azure-Computern mit Arc-Unterstützung.

  • Mehrere Onboardingkanäle: Sie können sich entschließen, das Onboarding erweiterungsbasierter Worker über das Azure-Portal, mit PowerShell-Cmdlets, mittels Bicep, ARM-Vorlagen, REST-API oder Azure CLI durchzuführen und sie zu verwalten.

  • Standardmäßiges automatisches Upgrade: Bietet standardmäßig ein automatisches Upgrade von Nebenversionen, wodurch der Verwaltungsaufwand, um auf die neueste Version aktualisiert zu bleiben, erheblich verringert wird. Es wird empfohlen, automatische Upgrades zu aktivieren, um ohne den manuellen Aufwand von allen Sicherheits- oder Featureupdates zu profitieren. Sie können automatische Upgrades auch jederzeit kündigen. Hauptversionsupgrades werden derzeit nicht unterstützt und sollten manuell verwaltet werden.

Hinweis

Erweiterungsbasierte Hybrid Runbook Worker unterstützen nur den benutzerbasierten Hybrid Runbook Worker-Typ und enthalten nicht den System-Hybrid Runbook Worker, der für die Updateverwaltung erforderlich ist.

Voraussetzungen

Mindestanforderungen für Computer

Unterstützte Betriebssysteme

Windows (x64) Linux (x64)
● Windows Server 2022 (einschließlich Server Core)
● Windows Server 2019 (einschließlich Server Core)
● Windows Server 2016, Versionen 1709 und 1803 (ohne Server Core)
● Windows Server 2012, 2012 R2 (ohne Server Core)
● Windows 10 Enterprise (einschließlich Multisession) und Pro		 ● Debian GNU/Linux 8, 9, 10 und 11
● Ubuntu 18.04 LTS, 20.04 LTS und 22.04 LTS
● SUSE Linux Enterprise Server 15.2 und 15.3
● Red Hat Enterprise Linux Server 7, 8 und 9
● CentOS Linux 7 und 8
● SUSE Linux Enterprise Server (SLES) 15
● Rocky Linux 9
● Oracle Linux 7 und 8
Hybrid Worker-Erweiterung folgt den Supportzeitvorgaben des Betriebssystemanbieters. 

Andere Anforderungen

Windows (x64) Linux (x64)
Windows PowerShell 5.1 (WMF 5.1 herunterladen). PowerShell Core wird nicht unterstützt. Die Linux-Härtung darf nicht aktiviert sein. 
.NET Framework 4.6.2 oder höher 

Paketanforderungen für Linux

Erforderliches Paket BESCHREIBUNG Mindestversion
Glibc GNU C-Bibliothek 2.5-12
Openssl OpenSSL-Bibliotheken 1.0 (TLS 1.1 und TLS 1.2 werden unterstützt)
Curl cURL-Webclient 7.15.5
Python-ctypes Fremdfunktionsbibliothek für Python Python 2.x oder Python 3.x erforderlich
PAM Module für austauschbare Authentifizierung
Optionale Pakete Beschreibung Mindestversion
PowerShell Core Um PowerShell-Runbooks auszuführen, muss PowerShell Core installiert sein. Anweisungen hierzu finden Sie unter Installieren von PowerShell unter Linux. 6.0.0

Berechtigungen für Hybrid-Worker-Anmeldeinformationen

Wenn Agent-basierte Hybrid Worker die Anmeldeinformationen der benutzerdefinierten Hybrid Worker verwendet, stellen Sie sicher, dass dem benutzerdefinierten Benutzer folgende Berechtigungen zugewiesen sind, um zu vermeiden, dass Aufträge für den erweiterungsbasierten Hybrid Worker angehalten werden.

Ressourcentyp Ordnerberechtigungen
Azure VM C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (Lesen und Ausführen)
Server mit Arc-Unterstützung C:\ProgramData\AzureConnectedMachineAgent\Tokens (Lesen)
C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (Lesen und Ausführen)

Hinweis

  • Stellen Sie für den Arc-fähigen Server sicher, dass Sie die Berechtigungen neu zuweisen, sobald sie entfernt werden, wenn der ARC-Agent aktualisiert wird.
  • Hybrid Runbook Worker wird für VM-Skalierungsgruppen (Virtual Machine Scale Sets, VMSS) derzeit nicht unterstützt.

Migrieren von vorhandenen Agent-basierten Hybrid Workern zu erweiterungsbasierten Hybrid Workern

Um die Vorteile von erweiterungsbasierten Hybrid Workern nutzen zu können, müssen Sie alle vorhandenen Agent-basierten Benutzer-Hybrid Worker zu erweiterungsbasierten Workern migrieren. Ein Hybrid Worker-Computer kann nicht gleichzeitig auf den beiden Plattformen Agent-basiert (V1) und Erweiterungsbasiert (V2) vorhanden sein. Die erweiterungsbasierte Installation wirkt sich nicht auf die Installation oder Verwaltung eines Agent-basierten Workers aus.

Führen Sie die folgenden Schritte aus, um die Hybrid Worker-Erweiterung auf einem vorhandenen Agent-basierten Hybrid Worker zu installieren:

  1. Wählen Sie unter Prozessautomatisierung die Option Hybrid Worker-Gruppen aus, und wählen Sie dann Ihre vorhandene Hybrid Worker-Gruppe aus, um zur Seite Hybrid Worker-Gruppe zu wechseln.

  2. Wählen Sie unter Hybrid Worker-Gruppe die Option Hybrid Worker>+ Hinzufügen aus, um zur Seite Computer als Hybrid Worker hinzufügen zu wechseln.

  3. Aktivieren Sie das Kontrollkästchen neben dem vorhandenen „Agent-basiert (V1)“-Hybrid Worker. Wenn Agent-basierte Hybrid Worker nicht aufgeführt werden, stellen Sie sicher, dass der Azure Arc Connected Machine-Agent auf dem Computer installiert ist. Informationen zum Installieren des AzureConnectedMachineAgent für Server mit Arc-Unterstützung finden Sie unter Verbinden von Hybridcomputern mit Azure über das Azure-Portal, oder unter Verwalten virtueller VMware-Computer mit Azure Arc-Unterstützung finden Sie Informationen zum Aktivieren der Gastverwaltung für VMware vSphere-VMs mit Azure Arc-Unterstützung.

    Screenshot des Hinzufügens von Computern als Hybrid-Worker.

  4. Wählen Sie Hinzufügen aus, um den Computer der Gruppe hinzuzufügen.

    In der Spalte Plattform wird derselbe Hybrid-Worker wie Agent-basiert (V1) und Extension-basiert (V2) angezeigt. Nachdem Sie mit der erweiterungsbasierten Hybrid Worker-Erfahrung und deren Verwendung vertraut sind, können Sie den Agent-basierten Worker entfernen.

    Screenshot des Felds „Plattform“ mit agentbasiertem oder Erweiterungsbasiertem Hybrid-Worker.

Für die Migration mehrerer Agent-basierter Hybrid Worker im großen Stil können Sie auch andere Kanäle verwenden, z. B. Bicep, ARM-Vorlagen, PowerShell-Cmdlets, REST-API und Azure CLI.

Verwalten der Hybrid Worker-Erweiterung unter Verwendung von Bicep- und ARM-Vorlagen, REST-API, Azure CLI und PowerShell

Sie können die Bicep-Vorlage verwenden, um eine neue Hybrid Worker-Gruppe zu erstellen, in Azure eine neue Windows-VM zu erstellen und sie einer vorhandenen Hybrid Worker-Gruppe hinzuzufügen. Erfahren Sie mehr zu Bicep.

Führen Sie beispielsweise die unten angegebenen Schritte aus:

  1. Erstellen Sie eine Hybrid Worker-Gruppe.
  2. Erstellen Sie einen virtuellen Azure-Computer oder einen Arc-fähigen Server. Alternativ können Sie auch eine vorhandene Azure-VM oder einen Arc-fähigen Server verwenden.
  3. Verbinden Sie die Azure-VM oder den Arc-fähigen Server mit der oben erstellten Hybrid Worker-Gruppe.
  4. Generieren Sie eine neue GUID und übergeben Sie sie als Namen des Hybrid Workers.
  5. Aktivieren Sie die systemseitig zugewiesene verwaltete Identität auf dem virtuellen Computer.
  6. Installieren Sie die Hybrid Worker-Erweiterung auf dem virtuellen Computer.
  7. Um zu bestätigen, ob die Erweiterung erfolgreich auf der VM installiert wurde, wechseln Sie im Azure-Portal zur Registerkarte >Erweiterungen für die VM, und überprüfen Sie den Status der auf der VM installierten Hybrid Worker-Erweiterung.
param automationAccount string
param automationAccountLocation string
param workerGroupName string

@description('Name of the virtual machine.')
param virtualMachineName string

@description('Username for the Virtual Machine.')
param adminUsername string

@description('Password for the Virtual Machine.')
@minLength(12)
@secure()
param adminPassword string

@description('Location for the VM.')
param vmLocation string = 'North Central US'

@description('Size of the virtual machine.')
param vmSize string = 'Standard_DS1_v2'

@description('The Windows version for the VM. This will pick a fully patched image of this given Windows version.')
@allowed([
  '2008-R2-SP1'
  '2012-Datacenter'
  '2012-R2-Datacenter'
  '2016-Nano-Server'
  '2016-Datacenter-with-Containers'
  '2016-Datacenter'
  '2019-Datacenter'
  '2019-Datacenter-Core'
  '2019-Datacenter-Core-smalldisk'
  '2019-Datacenter-Core-with-Containers'
  '2019-Datacenter-Core-with-Containers-smalldisk'
  '2019-Datacenter-smalldisk'
  '2019-Datacenter-with-Containers'
  '2019-Datacenter-with-Containers-smalldisk'
])
param osVersion string = '2019-Datacenter'

@description('DNS name for the public IP')
param dnsNameForPublicIP string

var nicName_var = 'myVMNict'
var addressPrefix = '10.0.0.0/16'
var subnetName = 'Subnet'
var subnetPrefix = '10.0.0.0/24'
var subnetRef = resourceId('Microsoft.Network/virtualNetworks/subnets', virtualNetworkName_var, subnetName)
var vmName_var = virtualMachineName
var virtualNetworkName_var = 'MyVNETt'
var publicIPAddressName_var = 'myPublicIPt'
var networkSecurityGroupName_var = 'default-NSGt'
var UniqueStringBasedOnTimeStamp = uniqueString(resourceGroup().id)

resource publicIPAddressName 'Microsoft.Network/publicIPAddresses@2020-08-01' = {
  name: publicIPAddressName_var
  location: vmLocation
  properties: {
    publicIPAllocationMethod: 'Dynamic'
    dnsSettings: {
      domainNameLabel: dnsNameForPublicIP
    }
  }
}

resource networkSecurityGroupName 'Microsoft.Network/networkSecurityGroups@2020-08-01' = {
  name: networkSecurityGroupName_var
  location: vmLocation
  properties: {
    securityRules: [
      {
        name: 'default-allow-3389'
        properties: {
          priority: 1000
          access: 'Allow'
          direction: 'Inbound'
          destinationPortRange: '3389'
          protocol: 'Tcp'
          sourceAddressPrefix: '*'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
        }
      }
    ]
  }
}

resource virtualNetworkName 'Microsoft.Network/virtualNetworks@2020-08-01' = {
  name: virtualNetworkName_var
  location: vmLocation
  properties: {
    addressSpace: {
      addressPrefixes: [
        addressPrefix
      ]
    }
    subnets: [
      {
        name: subnetName
        properties: {
          addressPrefix: subnetPrefix
          networkSecurityGroup: {
            id: networkSecurityGroupName.id
          }
        }
      }
    ]
  }
}

resource nicName 'Microsoft.Network/networkInterfaces@2020-08-01' = {
  name: nicName_var
  location: vmLocation
  properties: {
    ipConfigurations: [
      {
        name: 'ipconfig1'
        properties: {
          privateIPAllocationMethod: 'Dynamic'
          publicIPAddress: {
            id: publicIPAddressName.id
          }
          subnet: {
            id: subnetRef
          }
        }
      }
    ]
  }
  dependsOn: [

    virtualNetworkName
  ]
}

resource vmName 'Microsoft.Compute/virtualMachines@2020-12-01' = {
  name: vmName_var
  location: vmLocation
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    hardwareProfile: {
      vmSize: vmSize
    }
    osProfile: {
      computerName: vmName_var
      adminUsername: adminUsername
      adminPassword: adminPassword
    }
    storageProfile: {
      imageReference: {
        publisher: 'MicrosoftWindowsServer'
        offer: 'WindowsServer'
        sku: osVersion
        version: 'latest'
      }
      osDisk: {
        createOption: 'FromImage'
      }
    }
    networkProfile: {
      networkInterfaces: [
        {
          id: nicName.id
        }
      ]
    }
  }
}

resource automationAccount_resource 'Microsoft.Automation/automationAccounts@2021-06-22' = {
  name: automationAccount
  location: automationAccountLocation
  properties: {
    sku: {
      name: 'Basic'
    }
  }
}

resource automationAccount_workerGroupName 'Microsoft.Automation/automationAccounts/hybridRunbookWorkerGroups@2022-02-22' = {
  parent: automationAccount_resource
  name: workerGroupName
  dependsOn: [

    vmName
  ]
}

resource automationAccount_workerGroupName_testhw_UniqueStringBasedOnTimeStamp 'Microsoft.Automation/automationAccounts/hybridRunbookWorkerGroups/hybridRunbookWorkers@2021-06-22' = {
  parent: automationAccount_workerGroupName
  name: guid('testhw', UniqueStringBasedOnTimeStamp)
  properties: {
    vmResourceId: resourceId('Microsoft.Compute/virtualMachines', virtualMachineName)
  }
  dependsOn: [
    vmName
  ]
}

resource virtualMachineName_HybridWorkerExtension 'Microsoft.Compute/virtualMachines/extensions@2022-03-01' = {
  name: '${virtualMachineName}/HybridWorkerExtension'
  location: vmLocation
  properties: {
    publisher: 'Microsoft.Azure.Automation.HybridWorker'
    type: 'HybridWorkerForWindows'
    typeHandlerVersion: '1.1'
    autoUpgradeMinorVersion: true
    enableAutomaticUpgrade: true
    settings: {
      AutomationAccountURL: automationAccount_resource.properties.automationHybridServiceUrl
    }
  }
  dependsOn: [
    vmName
  ]
}

output output1 string = automationAccount_resource.properties.automationHybridServiceUrl

Agent-basierten Hybrid Worker entfernen

  1. Öffnen Sie eine PowerShell-Sitzung im Administratormodus und führen Sie den folgenden Befehl aus:

     Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\HybridRunbookWorker\<AutomationAccountID>\<HybridWorkerGroupName>" -Force -Verbose

  2. Klicken Sie unter Prozessautomatisierung auf Hybrid Worker-Gruppen, und wählen Sie dann Ihre Hybrid Worker-Gruppe aus, um zur Seite Hybrid Worker-Gruppe zu wechseln.

  3. Wählen Sie unter Hybrid Worker-Gruppe die Option Hybrid Worker aus.

  4. Aktivieren Sie das Kontrollkästchen neben den Computern, die Sie aus der Hybrid Worker-Gruppe löschen möchten.

  5. Wählen Sie Löschen aus, um den Agent-basierten Windows Hybrid Worker zu entfernen.

    Hinweis

    • Nachdem Sie die Private Link in Ihrem Automation-Konto deaktiviert haben, kann es bis zu 60 Minuten dauern, bis der Hybrid Runbook Worker entfernt wurde.
    • Nachdem Sie die Hybrid Worker entfernt haben, ist das Hybrid Worker-Authentifizierungszertifikat auf dem Computer 45 Minuten lang gültig.

Nächste Schritte