Freigeben über

Problembehandlung bei Agent-basierten Hybrid Runbook Workern in Automation

  • Artikel

Wichtig

Der Azure Automation Agent-basierte Benutzer-Hybrid Runbook Worker (Windows und Linux) wurde am 31. August 2024 eingestellt und wird nicht mehr unterstützt. Befolgen Sie die Richtlinien zum Migrieren von einem vorhandenen Agent-basierten Benutzer für Hybrid Runbook Worker zu erweiterungsbasierten Hybrid-Workern.

Dieser Artikel enthält Informationen zur Problembehandlung bei Agent-basierten Hybrid Runbook Workern in Azure Automation. Informationen zur Problembehandlung bei erweiterungsbasierten Workern finden Sie unter Problembehandlung bei erweiterungsbasierten Hybrid Runbook Workern in Automation. Allgemeine Informationen finden Sie unter Übersicht über Hybrid Runbook Worker.

Allgemein

Der Hybrid Runbook Worker benötigt einen Agent, um mit Ihrem Azure Automation-Konto für die Registrierung des Workers zu kommunizieren, Runbookaufträge zu erhalten und den Status zu melden. Für Windows ist dieser Agent der Log Analytics-Agents für Windows. Für Linux handelt es sich um den Log Analytics-Agent für Linux.

Az-Module können während der Verwendung des Hybrid Workers nicht aktualisiert werden

Problem

Es traten Fehler bei den Aufträgen für Hybrid Runbook Worker auf, da Az-Module nicht importiert werden konnten.

Lösung

Als Problemumgehung können Sie die folgenden Schritte ausführen:

  1. Wechseln Sie zum Ordner: C:\Programme\Microsoft Monitoring Agent\Agent\AzureAutomation\7.3.1722.0\HybridAgent
  2. Bearbeiten Sie die Datei mit dem Namen Orchestrator.Sandbox.exe.config
  3. Fügen Sie innerhalb des <assemblyBinding>-Tags folgende Zeilen hinzu:
<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />
</dependentAssembly>

Hinweis

Die Problemumgehung ersetzt die Datei durch das Original, wenn Sie MMA/Server entweder durch Aktivieren von Lösung oder Patching neu starten. Für beide Szenarien wird empfohlen, den Inhalt zu ersetzen.

Szenario: Fehler bei der Runbook-Ausführung

Problem

Bei der Ausführung eines Runbooks tritt ein Fehler mit der folgenden Fehlermeldung auf:

The job action 'Activate' cannot be run, because the process stopped unexpectedly. The job action was attempted three times.

Kurze Zeit nach drei Ausführungsversuchen wird Ihr Runbook angehalten. Es gibt Bedingungen, die den Abschluss des Runbooks unterbrechen können. Die dafür angezeigte Fehlermeldung enthält möglicherweise keine zusätzlichen Informationen.

Ursache

Folgende Ursachen kommen in Betracht:

  • Die Runbooks können nicht bei lokalen Ressourcen authentifiziert werden.
  • Der Hybrid Worker befindet sich hinter einem Proxy oder einer Firewall.
  • Der für die Ausführung des Hybrid Runbook Workers konfigurierte Computer erfüllt die Hardwaremindestanforderungen nicht.

Lösung

Stellen Sie sicher, dass der Computer an Port 443 über ausgehenden Zugriff auf *.azure-automation.net verfügt.

Computer, auf denen der Hybrid Runbook Worker ausgeführt werden soll, müssen die Mindestanforderungen an die Hardware erfüllen, damit sie als Host für dieses Feature konfiguriert werden können. Runbooks und die von ihnen verwendeten Hintergrundprozesse führen möglicherweise zu einer Überlastung des Systems sowie zu Verzögerungen und Timeouts bei Runbookaufträgen.

Vergewissern Sie sich, dass der für die Ausführung des Hybrid Runbook Worker-Features vorgesehene Computer die Hardwaremindestanforderungen erfüllt. Wenn dies der Fall ist, überwachen Sie die CPU- und Arbeitsspeicherauslastung, um Zusammenhänge zwischen der Leistung der Hybrid Runbook Worker-Prozesse und Windows zu erkennen. Wenn der Arbeitsspeicher oder die CPU stark ausgelastet sind, kann dies auf die Notwendigkeit eines Upgrades von Ressourcen hindeuten. Sie können auch eine andere Computeressource auswählen, die die Mindestanforderungen erfüllt. Bei entsprechend großer Workload skalieren Sie sie nach Bedarf.

Prüfen Sie, ob im Ereignisprotokoll Microsoft-SMA ein entsprechendes Ereignis mit der Beschreibung Win32 Process Exited with code [4294967295] vorhanden ist. Die Ursache dieses Fehlers liegt darin, dass Sie in Ihren Runbooks die Authentifizierung nicht konfiguriert haben oder dass Sie die „Ausführen als“-Anmeldeinformationen für die Hybrid Runbook Worker-Gruppe nicht angegeben haben. Überprüfen Sie die Runbookberechtigungen in Ausführen von Runbooks auf einem Hybrid Runbook Worker, und vergewissern Sie sich, dass Sie die Authentifizierung für Ihre Runbooks ordnungsgemäß konfiguriert haben.

Szenario: Runbooks schlagen mit Gatewayfehlern fehl

Problem

Die Hybrid Runbook Worker-Aufträge konnten bei der Kommunikation über einen Log Analytics-Gatewayserver nicht aktualisiert werden, und der zurückgegebene Fehler ähnelt: Spool operation id does not exist (spool ID): see attachment for job details and exact exception messages.

Lösung

Vergewissern Sie sich, dass der Log Analytics-Gatewayserver online ist und von dem Computer aus zugegriffen werden kann, der die Hybrid Runbook Worker-Rolle hostet. Zusätzliche Informationen zur Problembehandlung finden Sie unter Problembehandlung des Log Analytics-Gateways.

Szenario: Der Auftrag konnte nicht gestartet werden, da der Hybrid Worker nicht verfügbar war, als der geplante Auftrag gestartet wurde

Problem

Der Auftrag kann bei einem Hybrid Worker nicht gestartet werden und es wird der folgende Fehler angezeigt:

Fehler beim Start, da der Hybrid Worker beim Starten des geplanten Auftrags nicht verfügbar war. Der Hybrid-Worker war zuletzt am tt.mm.jjjj aktiv.

Ursache

Dieser Fehler kann aus den folgenden Gründen auftreten:

  • Der Computer ist nicht mehr vorhanden.
  • Der Computer ist ausgeschaltet und nicht erreichbar.
  • Der Computer weist ein Problem mit der Netzwerkverbindung auf.
  • Die Hybrid Runbook Worker-Erweiterung wurde vom Computer deinstalliert.

Lösung

  • Stellen Sie sicher, dass der Computer vorhanden und die Hybrid Runbook Worker-Erweiterung darauf installiert ist. Der Hybrid Worker sollte fehlerfrei sein und einen Heartbeat geben. Behandeln Sie Netzwerkprobleme, indem Sie die Microsoft-SMA-Ereignisprotokolle bei den Workern in der Hybrid Runbook Worker-Gruppe überprüfen, die versucht haben, diesen Auftrag auszuführen.
  • Sie können auch die Metrik HybridWorkerPing überwachen, welche die Anzahl der Pings von einem Hybrid Worker bereitstellt und dabei hilft, mit dem Ping im Zusammenhang stehende Probleme zu überprüfen.

Szenario: Auftrag wurde angehalten, da er den Auftragsgrenzwert für einen Hybrid Worker überschritten hat

Problem

Der Auftrag wird mit der folgenden Fehlermeldung angehalten:

Auftrag wurde angehalten, da er den Auftragsgrenzwert für einen Hybrid Worker überschritten hat. Fügen Sie der Hybrid Worker-Gruppe weitere Hybrid Worker hinzu, um dieses Problem zu beheben.

Ursache

Aufträge können aufgrund der folgenden Gründe angehalten werden:

  • Jeder aktive Hybrid Worker in der Gruppe fragt alle 30 Sekunden nach Aufträgen ab, um zu ermitteln, ob welche verfügbar sind. Der Worker wählt Aufträge auf der Grundlage von „First Come, First Served“ aus. Je nachdem, wann ein Auftrag gepusht wurde, übernimmt der Hybrid Worker innerhalb der Hybrid Worker-Gruppe den Auftrag, der den Automation-Dienst zuerst angepingt hat. Ein einzelner Hybrid Worker kann generell vier Aufträge pro Ping abrufen (d. h. alle 30 Sekunden). Wenn die Anzahl der Pushaufträge höher als vier pro 30 Sekunden ist und kein anderer Worker den Auftrag abnimmt, wird der Auftrag möglicherweise angehalten.
  • Der Hybrid Worker fragt möglicherweise nicht wie erwartet alle 30 Sekunden ab. Dies kann passieren, wenn der Worker nicht fehlerfrei ist oder Netzwerkprobleme auftreten.

Lösung

  • Wenn das Auftragslimit für einen Hybrid Worker vier Aufträge pro 30 Sekunden überschreitet, können Sie der Hybrid Worker-Gruppe weitere Hybrid Worker für Hochverfügbarkeit und Lastenausgleich hinzufügen. Sie können Aufträge auch so planen, dass sie die Grenze von vier Aufträgen pro 30 Sekunden nicht überschreiten. Die Verarbeitungszeit der Auftragswarteschlange hängt vom Hybrid Worker-Hardwareprofil und der Auslastung ab. Stellen Sie sicher, dass der Hybrid Worker fehlerfrei ist und einen Heartbeat abgibt.
  • Behandeln Sie Netzwerkprobleme, indem Sie die Microsoft-SMA-Ereignisprotokolle bei den Workern in der Hybrid Runbook Worker-Gruppe überprüfen, die versucht haben, diesen Auftrag auszuführen.
  • Sie können auch die Metrik HybridWorkerPing überwachen, welche die Anzahl der Pings von einem Hybrid Worker bereitstellt und dabei hilft, mit dem Ping im Zusammenhang stehende Probleme zu überprüfen.

Szenario: Ereignis 15011 im Hybrid Runbook Worker

Problem

Der Hybrid Runbook Worker empfängt das Ereignis 15011, das darauf hinweist, dass ein Abfrageergebnis nicht gültig ist. Die folgende Fehlermeldung wird angezeigt, wenn der Worker versucht, eine Verbindung mit dem SignalR-Server zu öffnen.

[AccountId={c7d22bd3-47b2-4144-bf88-97940102f6ca}] [Uri=https://cc-jobruntimedata-prod-su1.azure-automation.net/notifications/hub][Exception=System.TimeoutException: Transport timed out trying to connect​ at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()​ at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)​ at JobRuntimeData.NotificationsClient.JobRuntimeDataServiceSignalRClient.<Start>d__45.MoveNext()​

Ursache

Der Hybrid Runbook Worker wurde nicht ordnungsgemäß für die automatisierte Featurebereitstellung (z. B. die Updateverwaltung) konfiguriert. Die Bereitstellung enthält einen Teil, der die VM mit dem Log Analytics-Arbeitsbereich verbindet. Das PowerShell-Skript sucht in dem Abonnement mit dem angegebenen Namen nach dem Arbeitsbereich. In diesem Fall befindet sich der Log Analytics-Arbeitsbereich in einem anderen Abonnement. Das Skript kann den Arbeitsbereich nicht finden und versucht, einen zu erstellen, doch der Name ist bereits vergeben. Daher tritt bei der Bereitstellung ein Fehler auf.

Lösung

Sie haben zwei Möglichkeiten, dieses Problem zu beheben:

  • Ändern Sie das PowerShell-Skript so, dass es in einem anderen Abonnement nach dem Log Analytics-Arbeitsbereich sucht. Dies ist eine gute Lösung, wenn Sie planen, in Zukunft viele Hybrid Runbook Worker-Computer bereitzustellen.

  • Konfigurieren Sie den Workercomputer manuell so, dass er in einer Orchestrator-Sandbox ausgeführt wird. Führen Sie dann ein im Azure Automation-Konto erstelltes Runbook auf dem Worker aus, um dessen Funktionalität zu testen.

Szenario: Microsoft Azure-VMs wurden automatisch aus einer Hybrid Worker-Gruppe gelöscht.

Problem

Hybrid Runbook Worker oder VMs werden Ihnen nicht angezeigt, wenn der Workercomputer lange Zeit ausgeschaltet war.

Ursache

Der Hybrid Runbook Worker-Computer hat Azure Automation länger als 30 Tage nicht gepingt. Daher hat Automation die Hybrid Runbook Worker-Gruppe oder die System Worker-Gruppe gelöscht.

Lösung

Starten Sie den Workercomputer, und registrieren Sie ihn erneut in Azure Automation. Anweisungen zur Installation der Runbookumgebung und dem Herstellen einer Verbindung mit Azure Automation finden Sie unter Bereitstellen eines Windows Hybrid Runbook Workers.

Szenario: Es wurde kein Zertifikat im Zertifikatspeicher auf dem Hybrid Runbook Worker gefunden

Problem

Ein Runbook, das auf einem Hybrid Runbook Worker ausgeführt wird, schlägt mit der folgenden Fehlermeldung fehl:

Connect-AzAccount : No certificate was found in the certificate store with thumbprint 0000000000000000000000000000000000000000 At line:3 char:1 + Connect-AzAccount -ServicePrincipal -Tenant $Conn.TenantID -Appl ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : CloseError: (:) [Connect-AzAccount],ArgumentException + FullyQualifiedErrorId : Microsoft.Azure.Commands.Profile.ConnectAzAccountCommand

Ursache

Dieser Fehler tritt auf, wenn Sie versuchen, ein ausführendes Konto in einem Runbook zu verwenden, das auf einem Hybrid Runbook Worker ausgeführt wird, auf dem das Zertifikat des ausführenden Kontos nicht vorhanden ist. Der Hybrid Runbook Worker enthält das Zertifikatobjekt nicht standardmäßig lokal. Dieses Objekt ist aber für die ordnungsgemäße Funktion des ausführenden Kontos erforderlich.

Lösung

Wenn es sich bei Ihrem Hybrid Runbook Worker um eine Azure-VM handelt, können Sie stattdessen die Runbook-Authentifizierung mit verwalteten Identitäten verwenden. Dieses Szenario gestattet Ihnen die Authentifizierung bei Azure-Ressourcen mithilfe der verwalteten Identität der Azure-VM anstelle des „Ausführen als“-Kontos, was die Authentifizierung vereinfacht. Wenn der Hybrid Runbook Worker ein lokaler Computer ist, müssen Sie das Zertifikat des „Ausführen als“-Kontos auf dem Computer installieren. Sehen Sie sich die Schritte an, die für die Ausführung des PowerShell-Runbooks Export-RunAsCertificateToHybridWorker erforderlich sind und in Ausführen von Runbooks auf einem Hybrid Runbook Worker erläutert werden, wenn Sie Informationen zum Installieren des Zertifikats erhalten möchten.

Szenario: Fehler 403 während der Registrierung eines Hybrid Runbook Workers

Problem

Die anfängliche Registrierungsphase des Workers schlägt fehlt, und der folgende Fehler (403) wird zurückgegeben:

Forbidden: You don't have permission to access / on this server.

Ursache

Folgende Probleme kommen als Ursache in Betracht:

  • In den Einstellungen des Agents wurde eine Arbeitsbereich-ID oder ein (primärer) Arbeitsbereichsschlüssel fehlerhaft eingegeben.
  • Der Hybrid Runbook Worker kann die Konfiguration nicht herunterladen, was zu einem Fehler bei der Kontoverknüpfung führt. Wenn Azure Features auf Computern in Azure aktiviert sind, werden nur bestimmte Regionen zum Verknüpfen eines Log Analytics-Arbeitsbereichs und eines Automation-Kontos unterstützt. Es ist auch möglich, dass auf dem Computer ein falsches Datum oder eine falsche Uhrzeit festgelegt wurde. Wenn die Zeit um ca. 15 Minuten von der aktuellen Uhrzeit abweicht, tritt bei der Featurebereitstellung ein Fehler auf.
  • Das Protokollanalyse-Gateway ist nicht für die Unterstützung von Hybrid Runbook Worker konfiguriert.

Lösung

Fehlerhaft eingegebene Arbeitsbereichs-ID oder fehlerhaft eingegebener Arbeitsbereichsschlüssel

Sehen Sie sich im Artikel „Verwalten und Warten des Log Analytics-Agents für Windows und Linux“ die Informationen im Abschnitt zum Hinzufügen oder Entfernen von Arbeitsbereichen für den Windows-Agent bzw. Linux-Agent an, um zu überprüfen, ob die Arbeitsbereichs-ID oder der Arbeitsbereichsschlüssel des Agents fehlerhaft eingegeben wurde. Stellen Sie sicher, dass Sie die Zeichenfolge im Azure-Portal vollständig markieren, und gehen Sie beim Kopieren und Einfügen sorgfältig vor.

Konfiguration nicht heruntergeladen

Ihr Log Analytics-Arbeitsbereich und Ihr Automation-Konto müssen sich in einer verknüpften Region befinden. Dies ist die empfohlene Lösung für System Hybrid Runbook Worker, die von der Updateverwaltung verwendet wird. Eine Liste unterstützter Regionen finden Sie unter Arbeitsbereichzuordnungen.

Möglicherweise müssen Sie auch das Datum oder die Zeitzone auf Ihrem Computer aktualisieren. Wenn Sie eine benutzerdefinierte Zeitzone auswählen, sollten Sie sich vergewissern, dass die Zone der koordinierten Weltzeit entspricht, die sich von Ihrer lokalen Zeitzone unterscheiden kann.

Protokollanalyse-Gateway nicht konfiguriert

Führen Sie die hier beschriebenen Schritte aus, um dem Protokollanalyse-Gateway Hybrid Runbook Worker-Endpunkte hinzuzufügen.

Szenario: Bei Set-AzStorageBlobContent auf einem Hybrid Runbook Worker tritt ein Fehler auf

Problem

Das Runbook schlägt fehl, wenn es versucht, Set-AzStorageBlobContent auszuführen, und Sie erhalten die folgende Fehlermeldung:

Set-AzStorageBlobContent : Failed to open file xxxxxxxxxxxxxxxx: Illegal characters in path

Ursache

Dieser Fehler wird durch das Verhalten bei langen Dateinamen in Aufrufen von [System.IO.Path]::GetFullPath() verursacht, bei denen UNC-Pfade hinzugefügt werden.

Lösung

Um dieses Problem zu umgehen, können Sie eine Konfigurationsdatei namens OrchestratorSandbox.exe.config mit folgendem Inhalt erstellen:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
  </runtime>
</configuration>

Legen Sie diese Datei im selben Ordner wie die ausführbare Datei OrchestratorSandbox.exe ab. Ein auf ein Objekt angewendeter

%ProgramFiles%\Microsoft Monitoring Agent\Agent\AzureAutomation\7.3.702.0\HybridAgent

Hinweis

Wenn Sie ein Upgrade des Agent durchführen, wird diese Konfigurationsdatei gelöscht und muss neu erstellt werden.

Linux

Der Linux Hybrid Runbook Worker ist abhängig vom Log Analytics-Agent für Linux, um mit Ihrem Automation-Konto für die Registrierung des Workers zu kommunizieren, Runbook-Aufträge zu erhalten und den Status zu melden. Wenn bei der Registrierung des Workers ein Fehler auftritt, kommen hierfür mehrere Gründe infrage.

Szenario: Beim Signieren eines Runbooks erhält der Linux-Hybrid Runbook Worker eine Aufforderung zum Eingeben eines Kennworts

Problem

Wenn Sie den Befehl sudo für einen Linux-Hybrid Runbook Worker ausführen, wird eine unerwartete Aufforderung für die Eingabe eines Kennworts abgerufen.

Ursache

Das Konto nxautomationuser für den Log Analytics-Agent für Linux ist in der Datei sudoers nicht ordnungsgemäß konfiguriert. Der Hybrid Runbook Worker benötigt die entsprechende Konfiguration der Kontobenachrichtigungen und anderer Daten, damit Runbooks auf dem Linux-Runbook Worker signiert werden können.

Lösung

  • Stellen Sie sicher, dass der Hybrid Runbook Worker auf dem Computer über die ausführbare Datei „GnuPG (GPG)“ verfügt.

  • Überprüfen Sie die Konfiguration des nxautomationuser-Kontos in der sudoers-Datei. Lesen Sie sich den Artikel Ausführen von Runbooks auf einem Hybrid Runbook Worker durch.

Szenario: Der Log Analytics-Agent für Linux wird nicht ausgeführt

Problem

Der Log Analytics-Agent für Linux wird nicht ausgeführt.

Ursache

Wenn der Agent nicht ausgeführt wird, verhindert er die Kommunikation zwischen dem Linux Hybrid Runbook Worker und Azure Automation. Es kann verschiedene Gründe geben, warum der Agent nicht ausgeführt werden kann.

Lösung

Überprüfen Sie, ob der Agent ausgeführt wird, indem Sie den Befehl ps -ef | grep python eingeben. Eine Ausgabe ähnlich der folgenden sollte angezeigt werden. Der python-Befehl wird unter Verwendung des Benutzerkontos nxautomation verarbeitet. Wenn das Azure Automation-Feature nicht aktiviert ist, wird keiner der folgenden Prozesse ausgeführt.

nxautom+   8567      1  0 14:45 ?        00:00:00 python /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker/DSCResources/MSFT_nxOMSAutomationWorkerResource/automationworker/worker/main.py /var/opt/microsoft/omsagent/state/automationworker/oms.conf rworkspace:<workspaceId> <Linux hybrid worker version>
nxautom+   8593      1  0 14:45 ?        00:00:02 python /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker/DSCResources/MSFT_nxOMSAutomationWorkerResource/automationworker/worker/hybridworker.py /var/opt/microsoft/omsagent/state/automationworker/worker.conf managed rworkspace:<workspaceId> rversion:<Linux hybrid worker version>
nxautom+   8595      1  0 14:45 ?        00:00:02 python /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker/DSCResources/MSFT_nxOMSAutomationWorkerResource/automationworker/worker/hybridworker.py /var/opt/microsoft/omsagent/<workspaceId>/state/automationworker/diy/worker.conf managed rworkspace:<workspaceId> rversion:<Linux hybrid worker version>

Die folgende Liste enthält die Prozesse, die für einen Linux Hybrid Runbook Worker gestartet werden. Sie befinden sich alle im Verzeichnis /var/opt/microsoft/omsagent/state/automationworker/.

  • oms.conf: Dies ist der Worker-Manager-Prozess. Er wird direkt vom DSC gestartet.
  • worker.conf: Dies ist der automatisch registrierte Hybrid Worker-Prozess. Er wird vom Worker-Manager gestartet. Dieser Prozess dient der Updateverwaltung und ist für den Benutzer transparent. Dieser Prozess ist nicht vorhanden, wenn die Updateverwaltung auf dem Computer nicht aktiviert wurde.
  • diy/worker.conf: Dies ist der eigenständige Hybrid Worker-Prozess. Der eigenständige Hybrid Worker-Prozess wird verwendet, um Benutzerrunbooks auf dem Hybrid Runbook Worker auszuführen. Er unterscheidet sich vom automatisch registrierten Hybrid Worker-Prozess nur in dem wichtigen Detail, dass eine andere Konfiguration verwendet wird. Dieser Prozess ist nicht vorhanden, wenn Azure Automation deaktiviert und der eigenständige Linux-Hybrid Worker nicht registriert ist.

Wenn der Agent nicht ausgeführt wird, führen Sie zum Starten des Diensts den folgenden Befehl aus: sudo /opt/microsoft/omsagent/bin/service_control restart.

Szenario: Die angegebene Klasse ist nicht vorhanden

Wenn im Protokoll /var/opt/microsoft/omsconfig/omsconfig.log die Fehlermeldung The specified class does not exist.. (Die angegebene Klasse ist nicht vorhanden..) auftaucht, muss der Log Analytics-Agent für Linux aktualisiert werden. Führen Sie den folgenden Befehl aus, um den Agent neu zu installieren.

wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <WorkspaceID> -s <WorkspaceKey>

Windows

Der Windows Hybrid Runbook Worker ist abhängig vom Log Analytics-Agent für Windows, um mit Ihrem Automation-Konto für die Registrierung des Workers zu kommunizieren, Runbook-Aufträge zu erhalten und den Status zu melden. Für den Fall, dass bei der Registrierung des Workers ein Fehler auftritt, werden in diesem Abschnitt einige mögliche Gründe hierfür erläutert.

Szenario: Der Log Analytics-Agent für Windows wird nicht ausgeführt

Problem

Auf dem Computer mit dem Hybrid Runbook Worker wird der healthservice nicht ausgeführt.

Ursache

Wenn der Log Analytics-Agent für Windows-Dienst nicht ausgeführt wird, kann der Hybrid Runbook Worker nicht mit Azure Automation kommunizieren.

Lösung

Überprüfen Sie, ob der Agent ausgeführt wird, indem Sie den folgenden Befehl in PowerShell eingeben: Get-Service healthservice. Wenn der Dienst beendet wurde, geben Sie den folgenden Befehl in PowerShell ein, um ihn wieder zu starten: Start-Service healthservice.

Szenario: Ereignis 4502 im Operations Manager-Protokoll

Problem

Im Ereignisprotokoll unter Anwendungs- und Dienstprotokolle\Operations Manager werden das Ereignis 4502 und eine Ereignisnachricht, die Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent enthält, mit der folgenden Beschreibung angezeigt:
The certificate presented by the service \<wsid\>.oms.opinsights.azure.com was not issued by a certificate authority used for Microsoft services. Please contact your network administrator to see if they are running a proxy that intercepts TLS/SSL communication.

Ursache

Dieses Problem kann auftreten, wenn Ihr Proxy oder Ihre Netzwerkfirewall die Kommunikation mit Microsoft Azure blockiert. Stellen Sie sicher, dass der Computer an Port 443 über ausgehenden Zugriff auf *.azure-automation.net verfügt.

Lösung

Protokolle werden lokal auf jedem Hybrid Worker unter C:\ProgramData\Microsoft\System Center\Orchestrator\7.2\SMA\Sandboxes gespeichert. Sie können überprüfen, ob in den Ereignisprotokollen unter Anwendungs- und Dienstprotokolle\Microsoft-SMA\Operations und Anwendungs- und Dienstprotokolle\Operations Manager Warnungs- oder Fehlerereignisse vorhanden sind. Diese Protokolle zeigen Verbindungsprobleme oder andere Probleme an, die Auswirkungen auf das Aktivieren der Rolle in Azure Automation haben, oder Probleme, die im normalen Betrieb auftreten. Weitere Hilfe bei der Behandlung von Problemen mit dem Log Analytics-Agent finden Sie unter Behandeln von Problemen mit dem Log Analytics Windows-Agent.

Hybrid Worker senden Runbookausgabe und -meldungen an Azure Automation auf dieselbe Art, auf die in der Cloud ausgeführte Runbookaufträge Ausgabe und Meldungen versenden. Wie bei Runbooks können Sie den ausführlichen Datenstrom und den Fortschrittsdatenstrom aktivieren.

Szenario: „Orchestrator.Sandbox.exe“ kann keine Verbindung mit Microsoft 365 über den Proxy herstellen

Problem

Ein auf einem Windows-Hybrid Runbook Worker ausgeführtes Skript kann nicht erwartungsgemäß mit Microsoft 365 in einer Orchestrator-Sandbox verbunden werden. Das Skript verwendet für die Verbindung Connect-MgGraph.

Wenn Sie Orchestrator.Sandbox.exe.config anpassen und den Proxy und die Umgehungsliste festlegen, wird weiterhin keine ordnungsgemäße Verbindung mit der Sandbox hergestellt. Eine Datei Powershell_ise.exe.config mit denselben Einstellungen für Proxy und Umgehungsliste scheint erwartungsgemäß zu funktionieren. SMA- (Service Management Automation) und PowerShell-Protokolle enthalten keine Informationen zum Proxy.

Ursache

Die Verbindung mit den Active Directory-Verbunddiensten (AD FS) auf dem Server kann den Proxy nicht umgehen. Denken Sie daran, dass eine PowerShell-Sandbox als der protokollierte Benutzer ausgeführt wird. Eine Orchestrator-Sandbox ist jedoch stark angepasst und ignoriert die Einstellungen in der Datei Orchestrator.Sandbox.exe.config möglicherweise. Sie weist speziellen Code für die Verarbeitung von Computer- oder Log Analytics-Agent-Proxyeinstellungen auf, jedoch nicht für den Umgang mit anderen benutzerdefinierten Proxyeinstellungen.

Lösung

Sie können das Problem für die Orchestrator-Sandbox beheben, indem Sie Ihr Skript migrieren, sodass die Microsoft Entra-Module anstelle der PowerShell-Cmdlets verwendet werden. Weitere Informationen finden Sie unter Migrieren von Orchestrator zu Azure Automation (Beta).

​Wenn Sie die Cmdlets des Moduls weiterhin verwenden möchten, ändern Sie das Skript, um Invoke-Command zu verwenden. Geben Sie Werte für die Parameter ComputerName und Credential an.

$Credential = Get-AutomationPSCredential -Name MyProxyAccessibleCredential​
Invoke-Command -ComputerName $env:COMPUTERNAME -Credential $Credential
{ Connect-MgGraph … }​

Diese Codeänderung startet eine vollständig neue PowerShell-Sitzung im Kontext der angegebenen Anmeldeinformationen. Dadurch sollte der Datenverkehr über einen Proxyserver geleitet werden können, der den aktiven Benutzer authentifiziert.

Hinweis

Mit dieser Lösung ist es nicht erforderlich, die Konfigurationsdatei der Sandbox zu bearbeiten. Selbst wenn die Konfigurationsdatei erfolgreich mit Ihrem Skript funktioniert, wird sie bei jeder Aktualisierung des Hybrid Runbook Worker-Agents gelöscht.

Szenario: Keine Meldungen vom Hybrid Runbook Worker

Problem

Der Computer mit dem Hybrid Runbook Worker wird zwar ausgeführt, im Arbeitsbereich werden jedoch keine Heartbeatdaten für den Computer angezeigt.

Die folgende Beispielabfrage zeigt die Computer in einem Arbeitsbereich und ihren jeweils letzten Heartbeat an:

Heartbeat
| summarize arg_max(TimeGenerated, *) by Computer

Ursache

Dieses Problem kann durch einen beschädigten Cache für den Hybrid Runbook Worker verursacht werden.

Lösung

Melden Sie sich zur Behebung dieses Problems beim Hybrid Runbook Worker an, und führen Sie das folgende Skript aus. Dieses Skript beendet den Log Analytics-Agent für Windows, entfernt den dazugehörigen Cache und startet den Dienst neu. Dadurch muss der Hybrid Runbook Worker seine Konfiguration erneut aus Azure Automation herunterladen.

Stop-Service -Name HealthService

Remove-Item -Path 'C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State' -Recurse

Start-Service -Name HealthService

Szenario: Sie können keinen Windows Hybrid Runbook Worker hinzufügen

Problem

Die folgende Nachricht wird angezeigt, wenn Sie versuchen, einen Hybrid Runbook Worker mithilfe des Cmdlets Add-HybridRunbookWorker hinzuzufügen:

Machine is already registered

Ursache

Dies kann dadurch verursacht werden, dass der Computer bereits bei einem anderen Automation-Konto registriert ist oder Sie versuchen, den Hybrid Runbook Worker nach dem Entfernen vom Computer wieder hinzuzufügen.

Lösung

Entfernen Sie den folgenden Registrierungsschlüssel, starten Sie HealthService neu, und versuchen Sie, das Cmdlet Add-HybridRunbookWorker noch mal auszuführen, um dieses Problem zu lösen.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HybridRunbookWorker

Szenario: Sie können keinen Linux Hybrid Runbook Worker hinzufügen

Problem

Die folgende Nachricht wird angezeigt, wenn Sie versuchen, einen Hybrid Runbook Worker mithilfe des Python-Skripts sudo python /opt/microsoft/omsconfig/.../onboarding.py --register hinzuzufügen:

Unable to register, an existing worker was found. Please deregister any existing worker and try again.

Darüber hinaus wird versucht, die Registrierung eines Hybrid Runbook Worker mithilfe des Python-Skripts sudo python /opt/microsoft/omsconfig/.../onboarding.py --deregister aufzuheben:

Failed to deregister worker. [response_status=404]

Ursache

Dieses Problem kann auftreten, wenn der Computer bereits bei einem anderen Automation-Konto registriert ist, die Azure Hybrid Worker-Gruppe gelöscht wurde oder Sie versuchen, den Hybrid Runbook Worker nach dem Entfernen vom Computer wieder hinzuzufügen.

Lösung

So beheben Sie dieses Problem:

  1. Entfernen Sie den Agent sudo sh onboard_agent.sh --purge.

  2. Führen Sie diese Befehle aus:

    sudo mv -f /home/nxautomation/state/worker.conf /home/nxautomation/state/worker.conf_old
sudo mv -f /home/nxautomation/state/worker_diy.crt /home/nxautomation/state/worker_diy.crt_old
sudo mv -f /home/nxautomation/state/worker_diy.key /home/nxautomation/state/worker_diy.key_old

  3. Integrieren Sie den Agent sudo sh onboard_agent.sh -w <workspace id> -s <workspace key> -d opinsights.azure.com wieder.

  4. Warten Sie, bis der Ordner /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker aufgefüllt wurde.

  5. Versuchen Sie erneut, das Python-Skript sudo python /opt/microsoft/omsconfig/.../onboarding.py --register auszuführen.

Nächste Schritte

Wenn Ihr Problem hier nicht aufgeführt wird oder Sie es nicht lösen können, besuchen Sie einen der folgenden Kanäle, um weitere Unterstützung zu erhalten:

  • Erhalten Sie Antworten von Azure-Experten über Azure-Foren.
  • Kontaktieren Sie @AzureSupport, das offizielle Microsoft Azure-Konto für die Optimierung der Customer Experience. Der Azure-Support verbindet die Azure-Community mit Antworten, Support und Experten.
  • Erstellen Sie einen Azure-Supportfall. Wechseln Sie zur Azure-Supportwebsite, und wählen Sie Support erhalten aus.