Vorteilhaft für IT-Verantwortliche beim Einsatz der Azure-Managementdienste ist, dass mit Azure Arc verwaltete Server als Objekte im Azure-Portal erscheinen und sich so zusammen mit den in Azure beheimateten Servern konsolidiert inventarisieren, updaten und überwachen lassen. Für die Verwaltung von Datenbanken und Kubernetes-Clustern bietet Azure Arc zudem weitere Funktionen, wir fokussieren uns hier jedoch auf die Verwaltung von Servern, was Microsoft als "Azure Arc-enabled Servers" bezeichnet.

Erfreulich ist, dass Microsoft die Features der "Azure Arc Control Plane" kostenfrei anbietet. Diese umfassen die Administration von Servern mit Tags und Azure-Verwaltungsgruppen, das Suchen und Indizieren von Servern mit dem Azure Re- source Graph, das Steuern von Zugriffsrechten über Azure Role-based Access Control (RBAC), Automatisierung über Templates und Extensions sowie die Orchestrierung von Updates. Für die Nutzung der "Azure Policy Guest Configuration" (kostenfrei für herkömmliche Azure-Ressourcen) fallen jedoch für Azure-Arc-Ressourcen aktuell Kosten in Höhe von 6 US-Dollar pro Server und Monat an. Weitere Dienste wie Azure Monitor oder Azure Defender verursachen ebenfalls Gebühren, wenn sie für Azure Arc-enabled Server zum Einsatz kommen.

Der "Azure Connected Machine Agent" (ACMA) ermöglicht es, Windows- und Linux-Maschinen, die außerhalb von Azure im traditionellen Rechenzentrum oder bei anderen Cloudprovidern laufen, von Azure aus zu verwalten. Unter [1] liefert Microsoft ein Schaubild aller Bestandteile von Azure Arc, das auch die Aufgaben des Agenten und seine Kommunikationsbeziehungen zu Azure-Diensten zeigt.

Drei Komponenten im ACMA übernehmen die Kommunikation mit Azure und üben die Verwaltungsaufgaben auf dem lokalen Rechner aus. Der "Hybrid Instance Metadata Dienst" (HIMDS) verantwortet den Verbindungsaufbau mit Azure und stellt die Identität der verbundenen Maschine bereit. Der "Guest Configuration Agent" überprüft, ob der Server mit den in Azure vorgegebenen Konfigurationsvorgaben übereinstimmt und setzt diese Vorgaben bei Bedarf um. Der "Extension Agent" verwaltet den Einsatz von "VM Extensions". Dabei handelt es sich um kleine Applikationen, die für Konfigurations- und Automatisierungsaufgaben wie die Installation von Software oder für das Ausführen von Skripten zum Einsatz kommen. Für deren Abarbeitung ist der "Azure VM Agent for Windows" (auch als Windows Guest Agent bekannt) nötig. Dieser ist auf Azure-Maschinen, die aus Azure-Marketplace-Images stammen, bereits vorinstalliert. Als Teil des Extension Managers ist im Schaubild auch der "Azure Monitor Agent" (AMA) abgebildet – dieser ist für die Sammlung von Monitoringinformationen im Server zuständig und übermittelt diese an Azure Log Analytics.

Wie Microsofts Schaubild ebenfalls zeigt, haben die Komponenten des ACMA Kommunikationsbeziehungen zu Azure-Resource-Providern (ARP). Aus Sicherheitsgründen sind nicht alle davon von Haus aus in einer Azure-Subskription registriert. Um Azure Arc-Enabled Server nutzen zu können, müssen Sie drei ARP für die verwendete Subskription freischalten. Dies erledigen Sie mit einigen Schritten im Portal oder noch einfacher via PowerShell:

Den Azure Connected Machine Agent können Sie nur auf einem unterstützten Betriebssystem installieren – Windows Server 2008 R2 SP1 und höher. Daneben ist auch der Einsatz von gängigen Linux-Distributionen möglich. Genaue Details zu den Voraussetzungen, Einschränkungen und benötigten Rechten in Azure listet Microsoft unter [2] auf.

Die nächsten Schritte zum Aufsetzen von Azure Arc in einer Pilot- oder Produktivumgebung umfassen einige Planungsschritte. Zwingend erforderlich ist das Erzeugen einer eigenen Azure-Ressourcen-Gruppe, die ausschließlich Azure Arc-enabled Server beinhaltet. Darüber hinaus empfehlen sich mehrere Planungs- und Überprüfungsschritte, um die gezielte Verwendung von Richtlinien, Berechtigungen, Protokollierung und Tags auf von Arc verwalteten Servern festzulegen.

Netzwerkseitig muss der Azure Connected Machine Agent über das Internet mit den Arc-Diensten auf TCP-Port 443 kommunizieren können – natürlich verschlüsselt. Um die Sicherheit der Kommunikation noch zu erhöhen, nutzen Sie den noch recht neuen Dienst "Azure Private Link", mit dem die Azure-Arc-Komponenten über einen Private Endpoint aus einem Azure-VNet erreichbar werden. Kommt es dann zu einer Verbindung der externen Server über ein VPN oder Azure ExpressRoute zu Azure, fließt auch der für Arc anfallende Netzwerkverkehr nicht mehr über öffentliche IP-Adressen. Bei Azure Private Link fallen zusätzliche Kosten für die Bereitstellung der Private Endpoints und für das Transfervolumen an.

Ist nun die Planung abgeschlossen, ist der nächste Schritt das Ausrollen des Azure-Connected-Machine-Agenten auf die Zielsysteme. Dies erledigen Sie entweder manuell und interaktiv oder automatisiert in größeren Umgebungen. Wir wählen den Weg der automatisierten Einbindung über einen Azure Service Principal, den wir zunächst jedoch anlegen müssen. Hierzu wechseln Sie im Azure-Portal mit der Suchleiste auf den Dienst "Azure Arc" und klicken unter der Kategorie "Management" auf Service "Principals". Mit "Add" gelangen Sie zum Assistenten und geben folgende Daten an:

- Name: Etwa "sp_AzureArc_ Servers".

- Scope assignment level: Resource Group.

- Subscription und Resource Group: Eine Ressourcengruppe neu anlegen, etwa "rg_AzureArc".

- Client Secret: Unter "Expires" legen Sie die Gültigkeitsdauer des "Client Secret Strings" (auch "Application Password" genannt) fest, das für Ihren Service Principal automatisch erstellt wird. Längere Gültigkeitsdauern erhöhen die Nutzbarkeit und Bequemlichkeit, aber natürlich auch das Risiko von Missbrauch oder Bekanntwerden des Secrets.

- Unter "Role assignment" wählen Sie die Rolle "Azure Connected Machine Onboarding" aus.

Mit "Create" erstellen Sie den Service Principal und im nächsten Feld kopieren Sie die Zugangsdaten (Client-ID und Client-Secret) an einen sicheren Ort, da Sie diese für die Onboarding-Skripte benötigen. Vorsicht: Nach dem Schließen dieser Seite lassen sich die Zugangsdaten nicht mehr abrufen.

Danach wechseln Sie im linken Menü auf den Punkt "Server" unter der Kategorie "Infrastructure". Mit Klick auf "+ Add" erhalten Sie verschiedene Optionen, einzelne oder mehrere Server in Azure Arc einzubinden. Wir entscheiden uns für die Möglichkeit, generische Skripte für Windows und Linux zu erzeugen, die dank der Client-ID und des Client-Secrets innerhalb deren Gültigkeitsdauer ohne weitere Interaktion beliebig viele Server in Azure Arc aufnehmen können.

Im Assistenten wählen Sie Ihre Subskription und Resource Group ("rg_AzureArc") aus, die Sie im vorherigen Schritt erzeugt haben. Unter "Server Details" müssen Sie das Betriebssystem festlegen, für das das Skript erzeugt werden soll, und die Region, in der die Azure-Arc-Server via Skript landen sollen. Als "Connectivity Method" belassen Sie den "Public Endpoint" und unter "Authentication" nutzen Sie den eben erzeugten Service Principal, was dazu führt, dass die Client-ID bereits im Skript aufgeführt wird. Im finalen Schritt "Download and run script" laden Sie das Skript (wahlweise für PowerShell, Bash oder Ansible) herunter. Haben Sie als Betriebssystem Windows gewählt, erhalten Sie zusätzlich noch Skriptvarianten für Microsoft System Center Configuration Manager oder Gruppenrichtlinien. Nun müssen Sie lediglich das Client-Secret in den mit "Enter Secret Here" markierten Bereich kopieren, danach ist das Skript einsetzbar.

Für unser Beispiel zu Azure-Arc-enabled-Servern haben wir mehrere virtuelle Maschinen auf Basis von Windows Server 2022 und Red Hat Enterprise Linux 8.x vorbereitet. Nach dem Kopieren des Skripts und dem Ausführen in PowerShell oder Bash läuft die Registrierung bei Azure Arc problemlos durch und die Server erscheinen direkt danach als neue Objekte unter der Ressourcengruppe beziehungsweise im Azure-Arc-Dashboard unterhalb von "Servers". Die Metadaten der Maschinen wie der Computername, die genaue Betriebssystemversion oder die zugrundeliegende Serverplattform (in unserem Fall "VMware Workstation") hat ACMA direkt übermittelt.

Nachdem wir nun unsere lokalen Serversysteme in Azure Arc erfolgreich onboarden konnten, wollen wir für diese im nächsten Schritt die Überwachung ihrer Logs, das Updatemanagement und die Inventarisierung an Azure-Dienste übertragen. Zunächst müssen Sie hierfür die in Azure benötigten Ressourcen anlegen: einen Azure-Automation-Account, einen Log Analytics Workspace sowie eine Azure-Policy.

Bei Azure Automation handelt es sich um einen kostenfreien cloudbasierten Dienst für Prozessautomatisierung, Updatemanagement und Konfigurationsmanagment von Windows und Linux innerhalb und außerhalb von Azure. Kosten fallen für den Service selbst nicht an, jedoch für die in Azure Log Analytics gespeicherten Protokolldaten. Um diesen Dienst erstmalig zu benutzen, benötigen Sie einen Azure-Automation-Account. Dies ist ein eigenständiges Objekt in Azure, das nur dem Namen nach einem Microsoft-oder Azure-Account ähnelt. Mithilfe von Automation-Accounts lassen sich die zur Automatisierung gehörenden Ressourcen, wie Runbooks und Konfigurationseinstellung, von Ressourcen anderer Automation-Accounts trennen und administrativ delegieren. So können Sie beispielsweise je ein Konto für Ihre Produktivsysteme, für Entwicklungsumgebungen und die lokale Umgebung verwenden. Alternativ können Sie über einen einzigen Account alle Betriebssystemupdates Ihrer Maschinen über das Updatemanagement steuern.

Für das Erzeugen des Kontos wechseln Sie im Azure-Portal auf "Automation Accounts" und erzeugen über den Wizard einen neuen Account in Ihrer Ressourcengruppe (im Beispiel "rg-AzureArc"). Als Namen wählen wir für diesen Artikel "ita-arc-servers-automation" und als Region das von uns verwendete "West Eu- rope". Prinzipiell kann der Account unabhängig von seiner Region alle Ressourcen in Azure verwalten. Die Auswahl einer Region erlaubt es Ihnen, zugehörige Daten und Ressourcen in einer bestimmten Region zu isolieren, wenn Richtlinien das verlangen. Unter dem Reiter "Advanced" stellen Sie noch sicher, dass die Verwendung von "System assigned Managed Identities" ausgewählt ist, und können danach mit "Review + Create" den Vorgang abschließen.

Jetzt legen wir einen neuen Log Analytics Workspace an. Dabei handelt es sich um eine in Azure bereitgestellte Umgebung zum Speichern, Verwalten und Auswerten von Protokolldaten von Diensten wie Azure Monitor, Microsoft Sentinel oder Microsoft Defender for Cloud. Jeder Workspace verfügt über seinen eigenen Spei- cherbereich und Konfiguration, kann jedoch Daten von verschiedenen Diensten kombinieren. Die Erzeugung des Workspaces kostet zunächst nichts, Kosten fallen jedoch für die Daten an, die an den Workspace zum Verarbeiten und Speichern übermittelt werden. Wählen Sie im Azure-Portal "Log Analytics Workspaces" aus und legen Sie über den Assistenten einen neuen Workspace mit Default-Einstellungen in Ihrer Ressourcengruppe an. Als Name wählen wir "ita-arc-servers-automation-law", als Region "West Europe".

Anschließend konfigurieren Sie den Import der Protokolldaten nach Azure. Aktuell stellt Microsoft hierfür die Dienste vom bisherigen Dienst ("Log Analytics Agents") auf den neuen Azure Monitor Agent um. Da dies zum Redaktionsschluss nicht abgeschlossen war und der Azure Monitor Agent noch nicht alle Szenarien unterstützt, verwenden wir noch den bisherigen Dienst, den Microsoft noch bis zum 31. August 2024 supportet. Hierzu wählen wir in der linken Leiste unter "Classic" die Funktion "Legacy agents management" aus. Unterhalb von "Windows event logs" fügen Sie mit "Add windows event log" exemplarisch das Systemprotokoll hinzu und lassen die Kategorien "Error", "Warning" und "Information" ausgewählt. Nach einem Klick auf "Apply" ist die Konfiguration gespeichert. Sie wiederholen dies für Linux, indem Sie "Syslog" in der Leiste oben auswählen und dort auf "Add facility" klicken, die "Syslog facility" mit allen Log-Leveln hinzufügen und dies ebenfalls über "Apply" bestätigen.

Im nächsten Schritt stellen Sie sicher, dass die von Arc verwalteten Windows- und Linux-Server ihre Protokolldaten an den Azure Log Analytics Workspace schicken. Hierzu nutzen wir eine Azure-Policy, um diese Konfiguration auf die On-Prem-VMs auszurollen. Diese erstellen Sie, indem Sie in der Azure-Suchleiste "Policy" eingeben und in der Policy-Überblicksseite auf der linken Seite auf "Assignments" unterhalb von "Authoring" klicken. Hier wählen Sie dann die Funktion "Assign Initiative" aus. Eine "Initiative" gruppiert mehrere zusammengehörige Richtliniendefinitionen in eine Einheit, um die Verwaltung zu vereinfachen: Anstatt mehrere einzelne Richtlinien zuweisen zu müssen, können Sie einmalig die Gruppierung (Initiative) zuweisen. Im Assistenten zum Zuweisen der Azure-Policy-Initiative wählen Sie als "Scope" Ihre Subskription inklusive der Ressourcengruppe aus.

Nun gilt es, unter "Basics – Initiative definition" die Initiative mit dem Namen "Legacy – Enable Azure Monitor for VMs" zu definieren. Unter "Parameters" wählen Sie Ihren Log Analytics Workspace aus und unter "Remediation" stellen Sie sicher, dass unterhalb von "Create a Managed Identity" die Auswahl "System assigned managed identity" getroffen ist. Hier müssen Sie noch die Region passend zu den verwalteten Ressourcen einstellen. Danach weisen Sie mit "Review + create" die Initiative zu. Jetzt werfen Sie einen Blick in die Zuweisung, indem Sie auf deren Namen klicken. Unter "View definition" sehen Sie, dass die Initiative aus zehn einzelnen Richtlinien besteht, die dafür sorgen sollen, dass die "Log Analytics Extension" und der "Dependency Agent" auf Windows- und Linux-Servern ausgerollt werden. Durch die Verbindung der Richtlinieninitiative mit Ihrer Ressourcengruppe ist nun sichergestellt, dass alle neu in Azure Arc aufgenommenen Server die notwendigen Agenten automatisch erhalten.

Allerdings haben wir bereits Server vor der Zuweisung der Richtlinieninitiative in Azure Arc aufgenommen. Damit diese auch in den Genuss des Log-Analytics-Agenten kommen, müssen Sie in der Initiativenzuweisung noch Korrekturauf­gaben erstellen, die dies im Nachgang geradeziehen. Hierzu klicken Sie auf die Zuweisung der Initiative unter "Policy / Assignments" und wählen die Funktion "Create Remediation Task" aus. Hier müssen Sie insgesamt vier "Remediation Tasks" anlegen, um vier der Policies aus unserer Initiative auf bereits existierende Serverobjekte anzuwenden:

- LogAnalyticsExtension_Windows_HybridVM_Deploy

- LogAnalyticsExtension_Linux_HybridVM_Deploy

- DependencyAgentExtension_Windows_HybridVM_Deploy

- DependencyAgentExtension_Linux_HybridVM_Deploy

In den Einstellungen wählen Sie jeweils unterhalb des Abschnitts "Resources to remidiate" Ihre Ressourcengruppe im Feld "Scope" aus und stellen sicher, dass der Haken bei "Re-evaluate resource compliance before remediating" gesetzt ist.

Unter "Remediation" erscheinen nun die erzeugten Remediation-Tasks mit ihrem aktuellen Zustand ( etwa "accepted", "running" oder "succeeded"). Bis alle vier Tasks danach in den Zustand "succeeded" übergehen, kann es durchaus einige Minuten dauern. Ein Blick in die mit Azure Arc verwalteten VMs sollte dann in der Softwareliste beispielhaft unter Windows den "Microsoft Monitoring Agent" und den "Dependency Agent" als frisch installiert anzeigen. Unter Red Hat Linux 8.7 zeigt rpm -qa | grep agent auf der Kommandozeile sowohl ein "omsagent"- als auch ein "dependency-agent"-Paket als installiert an.

Nun steht das Einschalten des Updatemanagements für Azure-Arc-Server auf dem Plan. Hierfür navigieren Sie im Azure-Portal zum Azure-Automation-Account (im Beispiel "ita-arc-servers-automation"). Dort klicken Sie im linken Navigationsbereich auf "Update Management" und schalten dieses ein, indem Sie den vorher erstellten Log Analytics Workspace auswählen und dann mit einem Klick auf die Schaltfläche "Enable" bestätigen. Nach wenigen Minuten sollte das Feature in Azure für Ihren Bereich ausgerollt sein und Sie können mit einem erneuten Klick auf "Update Management" die Seite neu laden und anschließend das Updatemanagement konfigurieren.

Hierzu klicken Sie auf der neu geladenen Updatemanagement-Seite nach der erfolgten Bereitstellung auf "Manage Machines" und wählen im sich öffnenden Dialogfenster die Option "Enable on all available and future machines". Direkt darunter zeigt das Dialogfeld auch eine Liste der aktuellen Azure-Arc-Server an, auf die sich diese Einstellung aktuell auswirkt. Per Klick auf "Enable" bestätigen Sie die Konfiguration – danach dauerte es in unserem Testlauf rund 15 Minuten, bis sich die Konfiguration auf die Server auswirkte und diese mit Azure die relevanten Daten austauschten. Danach können Sie unter "Automation Account / Update Management" den Updatestatus der von Azure Arc verwalteten Server abrufen und sehen, wie viele und welche Updates auf unseren Servern fehlen.

Um nun die Updates auch auf die Server auszurollen, benötigen Sie im nächsten Schritt eine Funktion, die die Azure-Arc-VMs auf den Schirm bringt. Hierzu wechseln Sie zum Log Analytics Workspace und wählen im linken Navigationsbereich die Funktion "Logs" aus. Dort erzeugen Sie unter dem Anfragefenster eine neue Abfrage in Microsofts einfacher, SQL-artiger Abfragesprache "Kusto" mit "Update | Distinct Computer". Diese speichern Sie mit "Save as function" als Funktion "Get-AllArcVMs", übernehmen den gleichen Namen auch für das Feld "Legacy Category" und wählen zusätzlich die Speicheroption "Save as computer group" aus.

Jetzt wechseln Sie zurück zur Updatemanagement-Funktionalität im Automation Account und navigieren zu "Schedule update management". Für Windows- als auch Linux-Server benötigen Sie nun je eine Einstellung, um Updates auszurollen. Für Windows wählen Sie die folgenden Daten aus:

- Name: Update Windows

- Betriebssystem: Windows

- Items to update: "Groups to update auswählen / Non-Azure" und unsere eben definierte Funktion "GetAllArcVMs"

- Schedule settings: "Recurrence / Recurring, Recur every 1 Day"

Nun speichern Sie diesen Zeitplan mit "Create" und wiederholen dies ganz analog für Linux Server.

Sind die Zeitpläne eingerichtet, können Sie über das Updatemanagement-Dashboard genau nachvollziehen, ob und wann die Updates gelaufen sind und welche Ergebnisse die Vorgänge gebracht haben. In unseren Tests dauerte es etwas, bis die frisch installierten Updates nicht mehr als fehlend im Dashboard angezeigt wurden. Dies liegt an der zugrundeliegenden Kusto-Query und ihrem großzügigen Zeitfenster für die Abfrage. Insgesamt macht das Updatemanagement einen sehr durchdachten und aufgeräumten Eindruck und erlaubt es auf einfachem Weg, potenziell weltweit verteilte Serversysteme mit zentral verwalteten Updates zu versorgen.

Der finale Schritt ist die Konfiguration der Softwareinventarisierung für von Azure Arc verwaltete Server. Hierzu navigieren Sie zum Azure-Automation-Account und wählen unterhalb von "Configuration Management" in der linken Navigationsleiste "Inventory" aus. Zum Einschalten müssen Sie noch den Log Analytics Workspace spezifizieren und klicken danach auf "Enable". Jetzt laden Sie die Funktionskachel erneut, klicken oben auf "Manage Machines" und wählen dann "Enable on all available and future machines" aus. Nach einigen Minuten sind die Daten geladen und wir können je nach Betriebssystem des Servers installierte Software mit ihren Versionsnummern und Herstellern, Windows-Dienste, Linux-Daemons und weitere Eigenschaften direkt im Automation-Account unter "Inventory" oder alternativ unter einzelnen Serverobjekten einsehen.

Damit endet zwar unser Workshop zum Einstieg in Azure Arc, doch dessen Funktionalität geht noch deutlich weiter. Aktuell lassen sich etwa mit "VM Insights" weitere Eigenschaften von Servern abrufen, über "Managed Identities" der zentrale Zugriff auf Secrets und Zugangsdaten im Azure Key Vault verwalten, die Sicherheit von Azure-Arc-Servern mit einer Integration mit dem Azure Security Center und dem Microsoft Defender for Cloud erhöhen. Und mittels Azure Automanage Server lässt sich die Erfüllung von bestimmten Bedingungen oder Richtlinien überprüfen sowie Registry-Keys ausrollen. Zudem ist auch eine hybride Verwaltung von Kubernetes-Clustern, Datenbanken und (aktuell noch im Preview) von VM-ware vSphere und Microsoft Azure Stack HCI möglich.

Diese weitreichenden praktischen Funktionen zeigen, dass Azure Arc für Microsoft eine wichtige Initiative darstellt, um IT-Verantwortlichen eine zentrale Verwaltung von in klassischen Rechenzentren oder beliebigen, in anderen Clouds gehosteten Diensten zentralisiert in Azure anzubieten. Mit diesem Workshop gelingt Ihnen der nicht immer ganz einfache Einstieg in Azure Arc, von dem Sie dann die fortgeschrittenen Funktionen in Angriff nehmen können.