Verwalten und Warten des Connected Machine-Agents

Nachdem Sie den Azure Verbundenen Computer-Agent bereitgestellt haben, müssen Sie den Agent möglicherweise neu konfigurieren, aktualisieren, entfernen oder andere Änderungen vornehmen. Diese Routinewartungsaufgaben können manuell ausgeführt werden. Sie können auch automatische Agent-Upgrades (Vorschau) aktivieren oder nach anderen Aufgaben suchen, die Sie automatisieren können, um Betriebsfehler und Ausgaben zu reduzieren.

In diesem Artikel wird beschrieben, wie verschiedene Vorgänge im Zusammenhang mit dem Connected Machine-Agent und Ihren Arc-fähigen Servern ausgeführt werden.

Installieren einer bestimmten Version des Agents

Wir empfehlen in der Regel, die neueste Version des Azure Connected Machine-Agent zu verwenden. Wenn Sie jedoch aus irgendeinem Grund eine ältere Version des Agents ausführen müssen, deinstallieren Sie die aktuelle Version, und installieren Sie dann die Zielversion. Wenn Ihr Computer bereits mit Azure Arc verbunden ist, müssen Sie den Computer nicht trennen. Nur im letzten Jahr veröffentlichte Versionen von Connected Machine werden offiziell von der Produktgruppe unterstützt.

Befolgen Sie diese Anweisungen, um eine bestimmte Version des Azure Connected Machine-Agent zu installieren.

Upgraden des Agents

Der Azure Agent für verbundene Computer wird regelmäßig aktualisiert, um Fehlerbehebungen, Stabilitätsverbesserungen und neue Funktionen zu beheben. Azure Advisor identifiziert Ressourcen, die nicht die neueste Version des Computer-Agents verwenden, und empfiehlt, ein Upgrade auf die neueste Version durchzuführen. Sie werden benachrichtigt, wenn Sie den Azure Arc-fähigen Server auswählen, indem ein Banner auf der Seite Overview angezeigt wird, oder wenn Sie über das Azure Portal auf Advisor zugreifen.

Der Azure Connected Machine Agent für Windows und Linux kann je nach Ihren Anforderungen manuell oder automatisch auf die neueste Version aktualisiert werden. Wenn Sie den Azure Verbundenen Computer-Agent installieren, aktualisieren oder deinstallieren, müssen Sie den Server nicht neu starten.

Automatisches Agent-Upgrade (Vorschau)

Ab Version 1.57 des Azure Verbundenen Computer-Agents können Sie den Agent so konfigurieren, dass es sich automatisch auf die neueste Version aktualisiert. Dieses Feature befindet sich derzeit in der öffentlichen Vorschau und ist nur in der Azure öffentlichen Cloud verfügbar.

Durch Aktivieren von automatischen Upgrades wird der Agent planmäßig aktualisiert, wenn das Release nicht mehr als eine Version vom vorherigen Release auseinander ist. Um die Stabilität in allen Regionen aufrechtzuerhalten und Unterbrechungen zu minimieren, werden Upgrades über Batches hinweg eingeführt, wobei alle Upgrades während der Nebenzeiten initiiert werden. Wenn das Upgrade nicht erfolgreich abgeschlossen wurde, wird der Agent das automatische Upgrade in regelmäßigen Abständen erneut aktualisieren, bis es erfolgreich ist.

Um automatische Upgrades zu aktivieren, wenn Sie Ihren Computer mit Azure Arc verbinden, verwenden Sie das Flag --enable-automatic-upgrade im Befehl azcmagent connect. Beispiel:

azcmagent connect --subscription-id "Production" --resource-group "HybridServers" --location "eastus" --enable-automatic-upgrade

Sie können auch Azure Policy verwenden, um die Richtlinie Configure Azure Arc-fähige Server, um automatische Upgrades zu aktivieren zuzuweisen. Diese Richtlinie ermöglicht das automatische Upgrade der Agenten auf Servern in großem Maßstab in Ihrer gesamten Umgebung.

Um automatische Upgrades auf einem vorhandenen Arc-fähigen Server zu aktivieren, legen Sie die eigenschaft enableAutomaticUpgrade auf true mithilfe von Azure CLI (Windows oder Linux) oder Azure PowerShell fest.

Das folgende Beispiel zeigt, wie Automatische Agent-Upgrades mit Azure CLI konfiguriert werden.

# Set your target subscription
az account set --subscription "YOUR SUBSCRIPTION"

# Enable automatic upgrades on a single Arc-enabled server
az rest 
--method PATCH 
--url "https://management.azure.com/subscriptions/<SUB_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.HybridCompute/machines/<MACHINE_NAME>?api-version=2024-05-20-preview" 
--headers "Content-Type=application/json" 
--body '{"properties":{"agentUpgrade":{"enableAutomaticUpgrade":true}}}'

Das folgende Beispiel zeigt, wie Automatische Agent-Upgrades mithilfe von PowerShell konfiguriert werden.

Set-AzContext -Subscription "YOUR SUBSCRIPTION"

$params = @{
  ResourceGroupName = "YOUR RESOURCE GROUP"
  ResourceProviderName = "Microsoft.HybridCompute"
  ResourceType = "Machines"
  ApiVersion = "2024-05-20-preview"
  Name = "YOUR MACHINE NAME"
  Method = "PATCH"
  Payload = '{"properties":{"agentUpgrade":{ "enableAutomaticUpgrade":true}}}'
}
Invoke-AzRestMethod @params

Weitere Agent-Upgrademethoden

In der folgenden Tabelle werden weitere Methoden beschrieben, die für das Agent-Upgrade unterstützt werden.

$ServiceManager = (New-Object -com "Microsoft.Update.ServiceManager")
$ServiceID = "7971f918-a847-4430-9279-4a52d1efe18d"
$ServiceManager.AddService2($ServiceId,7,"")

Deinstallieren des Agents

Führen Sie für Server, die Sie nicht mehr mit Azure Arc-fähigen Servern verwalten möchten, die folgenden Schritte aus, um alle VM-Erweiterungen vom Server zu entfernen, den Agent zu trennen und die Software von Ihrem Server zu deinstallieren. Es ist wichtig, alle diese Schritte auszuführen, um alle zugehörigen Softwarekomponenten vollständig aus Ihrem System zu entfernen.

Entfernen der VM-Erweiterungen

Wenn Sie Azure VM-Erweiterungen auf einem Azure Arc-aktivierten Server bereitgestellt haben, müssen Sie alle Erweiterungen deinstallieren, bevor Sie den Agent trennen oder die Software deinstallieren. Durch die Deinstallation des Azure Verbundenen Computer-Agents werden keine Erweiterungen automatisch entfernt, und diese Erweiterungen werden nicht erkannt, wenn Sie den Server erneut mit Azure Arc verbinden.

Anleitungen zum Auflisten und Entfernen von Erweiterungen auf Ihrem Azure Arc-fähigen Server finden Sie in den folgenden Ressourcen:

• Manage VM-Erweiterungen mit dem Azure Portal
• Manage VM-Erweiterungen mit Azure PowerShell
• Manage VM-Erweiterungen mit Azure CLI

Trennen des Servers von Azure Arc

Nachdem Sie alle Erweiterungen vom Server entfernt haben, besteht der nächste Schritt darin, den Agent zu trennen. Dadurch wird die entsprechende Azure Ressource für den Server gelöscht und der lokale Status des Agents gelöscht.

Um den Agent zu trennen, führen Sie den azcmagent disconnect Befehl als Administrator auf dem Server aus. Sie werden aufgefordert, sich mit einem Azure Konto anzumelden, das über die Berechtigung zum Löschen der Ressource in Ihrem Abonnement verfügt. Wenn die Ressource bereits in Azure gelöscht wurde, übergeben Sie ein zusätzliches Flag, um den lokalen Zustand zu bereinigen: azcmagent disconnect --force-local-only.

Wenn Ihr Administrator- und Azure-Konten unterschiedlich sind, treten möglicherweise Probleme mit der Anmeldeaufforderung auf, die standardmäßig auf das Administratorkonto festgelegt ist. Führen Sie den azcmagent disconnect --use-device-code Befehl aus, um diese Probleme zu beheben. Sie werden aufgefordert, sich mit einem Azure Konto anzumelden, das über die Berechtigung zum Löschen der Ressource verfügt.

Deinstallieren des Agents

Schließlich können Sie den Connected Machine-Agent vom Server entfernen.

sudo apt purge azcmagent

sudo yum remove azcmagent

sudo zypper remove azcmagent

Aktualisieren oder Entfernen von Proxyeinstellungen

Um den Agent für die Kommunikation mit dem Dienst über einen Proxyserver zu konfigurieren oder diese Konfiguration nach der Bereitstellung zu entfernen, verwenden Sie eine der hier beschriebenen Methoden. Der Agent kommuniziert ausgehend über das HTTP-Protokoll unter diesem Szenario.

Proxyeinstellungen können mithilfe des Befehls „azcmagent config“ oder mit Systemumgebungsvariablen konfiguriert werden. Wenn ein Proxyserver sowohl in den Agentkonfigurations- als auch in Systemumgebungsvariablen angegeben ist, hat die Agentkonfiguration Vorrang und wird zur effektiven Einstellung. Verwenden Sie azcmagent show, um die effektive Proxykonfiguration für den Agenten anzuzeigen.

Agentspezifische Proxykonfiguration

Die agentspezifische Proxykonfiguration ist die bevorzugte Methode zum Konfigurieren von Proxyservereinstellungen. Diese Methode ist ab Version 1.13 des Azure Verbundenen Computer-Agents verfügbar. Die Verwendung der agentspezifischen Proxykonfiguration verhindert, dass die Proxyeinstellungen für den Azure Verbundenen Computer-Agent andere Anwendungen auf Ihrem System beeinträchtigen.

Führen Sie den folgenden Befehl aus, um den Agent für die Kommunikation über einen Proxyserver zu konfigurieren:

azcmagent config set proxy.url "http://ProxyServerFQDN:port"

Sie können eine IP-Adresse oder einen einfachen Hostnamen anstelle des FQDN verwenden, wenn ihr Netzwerk dies erfordert. Wenn Ihr Proxyserver auf Port 80 ausgeführt wird, können Sie ":80" am Ende weglassen.

Um zu überprüfen, ob eine Proxyserver-URL in den Agenteinstellungen konfiguriert ist, führen Sie den folgenden Befehl aus:

azcmagent config get proxy.url

Führen Sie den folgenden Befehl aus, um zu verhindern, dass der Agent über einen Proxyserver kommuniziert:

azcmagent config clear proxy.url

Sie müssen keine Dienste neu starten, wenn Sie die Proxyeinstellungen mit dem azcmagent config Befehl neu konfigurieren.

Proxyumgehung für private Endpunkte

Ab Agent Version 1.15 können Sie auch Dienste angeben, die nicht den angegebenen Proxyserver verwenden sollten. Dies kann bei Szenarien mit geteilten Netzwerken und privaten Endpunktszenarien hilfreich sein, in denen Sie Microsoft Entra ID und Azure Resource Manager Datenverkehr über Ihren Proxyserver zu öffentlichen Endpunkten durchlaufen möchten. Sie möchten jedoch, dass Azure Arc Datenverkehr den Proxy überspringt und mit einer privaten IP-Adresse in Ihrem Netzwerk kommuniziert.

Die Proxy-Umgehungsfunktion erfordert nicht, dass Sie bestimmte URLs eingeben, um sie zu umgehen. Stattdessen geben Sie den Namen aller Dienste an, die nicht den Proxyserver verwenden sollten. Der Standortparameter bezieht sich auf die Azure Region des Arc-fähigen Servers.

Der Proxy-Umgehungswert, wenn er auf ArcData festgelegt ist, umgeht nur den Datenverkehr der Azure-Erweiterung für SQL Server, nicht aber den des Arc-Agents.

¹ Der Proxyumgehungswert ArcData ist verfügbar ab der Azure Connected Machine Agent-Version 1.36 und der Azure Extension für SQL Server-Version 1.1.2504.99. Frühere Versionen enthalten die SQL Server, die von Azure Arc Endpunkten im Proxyumgehungswert "Arc" aktiviert werden.

Um Microsoft Entra ID und Azure Resource Manager Datenverkehr über einen Proxyserver zu senden, aber den Proxy für Azure Arc Datenverkehr zu überspringen, führen Sie den folgenden Befehl aus:

azcmagent config set proxy.url "http://ProxyServerFQDN:port"
azcmagent config set proxy.bypass "Arc"

Um eine Liste der Dienste bereitzustellen, trennen Sie die Dienstnamen durch Kommas:

azcmagent config set proxy.bypass "ARM,Arc"

Führen Sie den folgenden Befehl aus, um den Proxy-Ausschluss zu löschen.

azcmagent config clear proxy.bypass

Sie können die effektive Proxyserver- und Proxy-Umgehungskonfiguration anzeigen, indem Sie den Befehl azcmagent show ausführen.

Windows Umgebungsvariablen

Unter Windows überprüft der Azure verbundene Maschine-Agent zunächst die proxy.url Agent-Konfigurationseigenschaft (beginnend mit Agent Version 1.13) und dann die systemweite HTTPS_PROXY Umgebungsvariable, um zu bestimmen, welcher Proxyserver verwendet werden soll. Wenn beide leer sind, wird kein Proxyserver verwendet, auch wenn die standardmäßige Windows systemweite Proxyeinstellung konfiguriert ist.

Wir empfehlen die Verwendung der agentspezifischen Proxykonfiguration anstelle der Systemumgebungsvariable.

Führen Sie die folgenden Befehle aus, um die Proxyserverumgebungsvariable festzulegen:

# If a proxy server is needed, execute these commands with the proxy URL and port.
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://ProxyServerFQDN:port", "Machine")
$env:HTTPS_PROXY = [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine")
# For the changes to take effect, the agent services need to be restarted after the proxy environment variable is set.
Restart-Service -Name himds, ExtensionService, GCArcService

Führen Sie die folgenden Befehle aus, um den Agent so zu konfigurieren, dass die Kommunikation über einen Proxyserver beendet wird:

[Environment]::SetEnvironmentVariable("HTTPS_PROXY", $null, "Machine")
$env:HTTPS_PROXY = [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine")
# For the changes to take effect, the agent services need to be restarted after the proxy environment variable removed.
Restart-Service -Name himds, ExtensionService, GCArcService

Linux-Umgebungsvariablen

Unter Linux überprüft der Azure Connected Machine-Agent zunächst die Agent Konfigurationseigenschaft proxy.url (beginnend mit Agent-Version 1.13) und dann die HTTPS_PROXY Umgebungsvariable, die für die himds, GC_Ext und GCArcService-Daemons festgelegt ist. Ein enthaltenes Skript konfiguriert systemd's Standardproxyeinstellungen so, dass der Azure Verbundenen Computer-Agent und alle anderen Dienste auf dem Computer einen angegebenen Proxyserver verwenden.

Führen Sie den folgenden Befehl aus, um den Agent für die Kommunikation über einen Proxyserver zu konfigurieren:

sudo /opt/azcmagent/bin/azcmagent_proxy add "http://ProxyServerFQDN:port"

Führen Sie den folgenden Befehl aus, um die Umgebungsvariable zu entfernen:

sudo /opt/azcmagent/bin/azcmagent_proxy remove

Migrieren von Umgebungsvariablen zur Agent-spezifischen Proxykonfiguration

Wenn Sie bereits Umgebungsvariablen zum Konfigurieren des Proxyservers für den Azure Verbundenen Computer-Agent verwenden und basierend auf den lokalen Agenteinstellungen zu der agentspezifischen Proxykonfiguration migrieren möchten, führen Sie die folgenden Schritte aus:

1. Aktualisieren Sie den Azure Connected Machine-Agent auf die neueste Version.

2. Konfigurieren Sie den Agenten mit Ihren Proxyserverinformationen, indem Sie den Befehl azcmagent config set proxy.url "http://ProxyServerFQDN:port" ausführen.

3. Entfernen Sie die nicht verwendeten Umgebungsvariablen, indem Sie die Schritte für Windows oder Linux ausführen.

Umbenennen einer Azure Arc-aktivierten Serverressource

Wenn Sie den Namen eines Linux- oder Windows Computers ändern, der mit Azure Arc-fähigen Servern verbunden ist, wird der neue Name nicht automatisch erkannt, da der Ressourcenname in Azure unveränderlich ist. Wie bei anderen Azure Ressourcen müssen Sie die Ressource in Azure löschen und dann neu erstellen, um den neuen Namen zu verwenden.

Für Azure Arc-fähige Server müssen Sie vor dem Umbenennen des Computers die VM-Erweiterungen entfernen:

1. Führen Sie die auf dem Computer installierten VM-Erweiterungen auf, und notieren Sie ihre Konfiguration mithilfe des Azure-Portals, Azure CLI oder Azure PowerShell.

2. Entfernen Sie alle auf dem Computer installierten VM-Erweiterungen mithilfe des Azure-Portals, Azure CLI oder Azure PowerShell.

3. Verwenden Sie das Tool azcmagent mit dem Parameter Disconnect, um den Computer von Azure Arc zu trennen und die Computerressource aus Azure zu löschen. Sie können dieses Tool manuell ausführen, während Sie interaktiv angemeldet sind, mit einem Microsoft Identitätstoken Access-Token oder mit einem Service principal.

   Wenn Sie den Computer von Azure Arc-fähigen Servern trennen, wird der Agent für verbundene Computer nicht entfernt, und Sie müssen den Agent nicht im Rahmen dieses Prozesses entfernen.

4. Registrieren Sie den Connected Machine-Agent erneut auf Azure Arc-aktivierten Servern. Führen Sie das azcmagent Tool mit dem Parameter Connect aus, um diesen Schritt abzuschließen. Der Agent verwendet standardmäßig den aktuellen Hostnamen des Computers, Aber Sie können Ihren eigenen Ressourcennamen auswählen, indem Sie den --resource-name Parameter an den Verbindungsbefehl übergeben.

5. Stellen Sie die VM-Erweiterungen erneut bereit, die ursprünglich auf dem Computer von Azure Arc-fähigen Servern bereitgestellt wurden. Wenn Sie den Azure Monitor für VMs-Agent (Insights) mithilfe einer Azure Policy Definition bereitgestellt haben, werden die Agents nach dem nächsten Bewertungszyklus erneut bereitgestellt.

Untersuchen der Trennung von Azure Arc-aktivierten Servern

Der Connected Machine-Agent sendet eine regelmäßige Herzschlagnachricht alle fünf Minuten an Azure. Wenn ein Arc-fähiger Server länger als 15 Minuten aufhört, Heartbeat-Signale an Azure zu senden, kann dies bedeuten, dass der Server offline ist, die Netzwerkverbindung blockiert ist oder der Agent nicht ausgeführt wird.

Entwickeln Sie einen Plan, um auf diese Vorfälle zu reagieren und sie zu untersuchen. Richten Sie beispielsweise Resource Health-Benachrichtigungen ein, damit Sie benachrichtigt werden, wenn solche Vorfälle auftreten. Weitere Informationen finden Sie unter Create Resource Health alerts in the Azure portal.

Entfernen veralteter Serverressourcen

Wenn ein Server außer Betrieb genommen oder getrennt wird, ohne den Agent sauber zu entfernen, verbleibt die Ressource in der Regel im Azure Portal mit dem Status "Getrennt". Im Laufe der Zeit können diese veralteten Ressourcen Ihre Umgebung überladen.

Mit dem folgenden PowerShell-Skript können Sie Azure Arc-fähige Server identifizieren und löschen, die für eine bestimmte Anzahl von Tagen nicht verbunden waren.

Voraussetzungen

• Azure PowerShell: Das Az Modul installiert.
• Permissions: Lesezugriff auf die Abfrage über Azure Resource Graph und Beitragender/Besitzer (oder Microsoft.HybridCompute/machines/delete), um die Ressourcen zu löschen.

Das Bereinigungsskript

Dieses Skript verwendet Azure Resource Graph zum Abfragen Microsoft.HybridCompute/machines Ressourcen, wobei der Status Disconnected ist und der zeitstempel lastStatusChange älter als der konfigurierte Schwellenwert ist.

Speichern Sie den folgenden Code als Cleanup-StaleArcServers.ps1.

<#
.SYNOPSIS
    Identifies and removes stale Azure Arc-enabled servers that have been disconnected for a specified number of days.

.DESCRIPTION
    This script queries Azure Resource Graph to find Azure Arc-enabled servers (Microsoft.HybridCompute/machines)
    that have a status of 'Disconnected' and have not updated their status for more than the specified number of days.
    Supports -WhatIf and -Confirm via SupportsShouldProcess.

.PARAMETER DaysDisconnected
    The number of days a server must be disconnected to be considered stale. Default is 60.

.PARAMETER Subscription
    Optional. One or more Subscription IDs to scope the query to.
    If not specified, queries all subscriptions the current context has access to.

.PARAMETER ManagementGroup
    Optional. A Management Group name to scope the query to.
    Cannot be used together with -Subscription.

.EXAMPLE
    .\Cleanup-StaleArcServers.ps1 -DaysDisconnected 60 -WhatIf
    Lists Arc servers disconnected for more than 60 days across all subscriptions.

.EXAMPLE
    .\Cleanup-StaleArcServers.ps1 -DaysDisconnected 90 -Subscription 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
    Permanently deletes Arc servers disconnected for more than 90 days in the specified subscription.

.NOTES
    Author: Microsoft
    Date: 2026-01-12
    Requires: Az.ResourceGraph, Az.Resources
#>

[CmdletBinding(SupportsShouldProcess, ConfirmImpact = 'High')]
param (
    [int]$DaysDisconnected = 60,
    
    [ValidateNotNullOrEmpty()]
    [string[]]$Subscription,

    [ValidateNotNullOrEmpty()]
    [string]$ManagementGroup
)

# Check required modules
foreach ($mod in @('Az.ResourceGraph', 'Az.Resources')) {
    if (-not (Get-Module -Name $mod -ListAvailable -ErrorAction SilentlyContinue)) {
        Write-Error "Required module '$mod' is not installed. Run: Install-Module $mod -Scope CurrentUser"
        return
    }
}

# Check for Azure connection
try {
    $context = Get-AzContext -ErrorAction Stop
    Write-Host "Connected to Azure context: $($context.Name)" -ForegroundColor Cyan
}
catch {
    Write-Error "Not connected to Azure. Please run 'Connect-AzAccount' first."
    return
}

# Construct the KQL query
# We look for resources of type hybridcompute/machines
# Status must be Disconnected
# lastStatusChange must be older than $DaysDisconnected
$kqlQuery = @"
Resources
| where type == 'microsoft.hybridcompute/machines'
| where properties.status == 'Disconnected'
| where properties.lastStatusChange < ago($($DaysDisconnected)d)
| project id, name, resourceGroup, subscriptionId, location, status = properties.status, lastStatusChange = properties.lastStatusChange
"@

Write-Host "Searching for Arc servers disconnected for more than $DaysDisconnected days..." -ForegroundColor Yellow

# Execute Search with pagination (Search-AzGraph returns max 1000 results per call)
$staleServers = [System.Collections.Generic.List[object]]::new()
$skipToken = $null

try {
    do {
        $params = @{
            Query = $kqlQuery
            First = 1000
        }
        if ($skipToken) {
            $params['SkipToken'] = $skipToken
        }
        if ($Subscription) {
            $params['Subscription'] = $Subscription
        }
        if ($ManagementGroup) {
            $params['ManagementGroup'] = $ManagementGroup
        }

        $result = Search-AzGraph @params -ErrorAction Stop
        if ($result) {
            $staleServers.AddRange([object[]]$result)
            $skipToken = $result.SkipToken
        }
    } while ($skipToken)
}
catch {
    Write-Error "Failed to query Azure Resource Graph. Ensure resource graph module is installed and you have read permissions.`nError: $_"
    return
}

if ($staleServers.Count -eq 0) {
    Write-Host "No stale Arc servers found matching the criteria." -ForegroundColor Green
    return
}

Write-Host "Found $($staleServers.Count) stale servers." -ForegroundColor Yellow

# Process results
$successCount = 0
$failCount = 0

foreach ($server in $staleServers) {
    if ($PSCmdlet.ShouldProcess($server.id, "Delete stale Arc server '$($server.name)' (Disconnected since: $($server.lastStatusChange))")) {
        try {
            Remove-AzResource -ResourceId $server.id -Force -ErrorAction Stop
            Write-Host "Successfully deleted '$($server.name)'." -ForegroundColor Green
            $successCount++
        }
        catch {
            Write-Error "Failed to delete '$($server.name)'. Error: $_"
            $failCount++
        }
    }
}

Write-Host "`nCleanup completed. Deleted: $successCount, Failed: $failCount, Total: $($staleServers.Count)" -ForegroundColor Green

Verwendung des Skripts

Voraussetzungen

Für das Skript sind die folgenden PowerShell-Module erforderlich:

• Az.ResourceGraph
• Az.Resources

Wenn sie nicht installiert sind, führen Sie Folgendes aus:

Install-Module Az.ResourceGraph, Az.Resources -Scope CurrentUser

Schritte

1. Anmelden bei Azure

   Öffnen Sie Ihr PowerShell-Terminal, und melden Sie sich an.

   Connect-AzAccount
   

2. Ausführen einer What-If Analyse

   Führen Sie zuerst das Skript mit dem -WhatIf Schalter aus. Dadurch werden die Server aufgelistet, die den Kriterien entsprechen, ohne sie tatsächlich zu löschen. Dieser Befehl überprüft Server, die seit 60 Tagen oder mehr getrennt sind.

   .\Cleanup-StaleArcServers.ps1 -DaysDisconnected 60 -WhatIf
   

   Verwenden Sie den -Subscription Parameter, um die Abfrage auf ein bestimmtes Abonnement zu beschränken:

   .\Cleanup-StaleArcServers.ps1 -DaysDisconnected 60 -Subscription 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' -WhatIf
   

   Verwenden Sie den -ManagementGroup Parameter, um die Abfrage stattdessen auf eine Verwaltungsgruppe zu beschränken:

   .\Cleanup-StaleArcServers.ps1 -DaysDisconnected 60 -ManagementGroup 'MyManagementGroup' -WhatIf
   

   Überprüfen Sie die Ausgabe, um sicherzustellen, dass nur die vorgesehenen Server aufgelistet sind.

3. Bereinigung durchführen

   Sobald Sie sicher sind, dass die Liste der zu entfernenden Server entfernt wird, führen Sie das Skript ohne den -WhatIf Switch aus.

   .\Cleanup-StaleArcServers.ps1 -DaysDisconnected 60
   

   Zum Bereinigen von Servern, die für einen längeren Zeitraum getrennt wurden (z. B. 6 Monate), erhöhen Sie die Anzahl der Tage:

   .\Cleanup-StaleArcServers.ps1 -DaysDisconnected 180
   

   Das Skript fordert vor jedem Löschen zur Bestätigung auf. Fügen Sie -Confirm:$falsezum Überspringen von Eingabeaufforderungen hinzu.

Verwandte Inhalte

• Informationen zur Problembehandlung finden Sie im Leitfaden zum Beheben von Problemen mit dem Connected Machine-Agent.
• Erfahren Sie, wie Sie Azure Arc-fähige Server in beliebiger Größenordnung planen und bereitstellen sowie eine zentrale Verwaltung und Überwachung implementieren.
• Erfahren Sie, wie Sie Ihre Maschine mithilfe von Azure Policy verwalten, zum Beispiel die VM Guest-Konfiguration, überprüfen, ob die Maschine an den erwarteten Log Analytics-Arbeitsbereich berichtet, die Überwachung mit VM Insights aktivieren und vieles mehr.