Condividi tramite

Risolvere i problemi del ruolo di lavoro ibrido per runbook basato sull’agente della macchina virtuale in automazione

  • Articolo

Importante

Il Ruolo di lavoro ibrido per runbook utente basato su agente di Automazione di Azure (Windows e Linux) è stato ritirato il 31 agosto 2024 e non è più supportato. Seguire le linee guida su come effettuare la migrazione da un ruoli di lavoro ibrido per i runbook basati su agente a ruoli di lavoro ibrido basati su estensione.

Questo articolo contiene informazioni sulla risoluzione dei problemi relativi ai ruoli di lavoro ibridi per runbook basato su agente di Automazione di Azure. Per la risoluzione dei problemi relativi ai ruoli di lavoro basati su agente, vedere Risolvere i problemi del ruolo di lavoro ibrido per runbook basato su agente in Automazione. Per informazioni generali, vedere Panoramica dei ruoli di lavoro ibrido per runbook.

Generali

Il ruolo di lavoro ibrido per runbook si affida a un agente per comunicare con l'account di Automazione di Azure per registrare il ruolo di lavoro, ricevere i processi del runbook e segnalare lo stato. In Windows, si tratta dell'agente di Log Analytics per Windows, mentre in Linux è l'agente di Log Analytics per Linux.

Non è possibile aggiornare i moduli AZ usando il ruolo di lavoro ibrido

Problema

I processi del ruolo di lavoro ibrido per runbook non sono riusciti perché non è possibile importare i moduli Az.

Risoluzione

Come soluzione alternativa, seguire questi passaggi:

  1. Andare alla cartella: C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomation\7.3.1722.0\HybridAgent
  2. Modificare il file con il nome Orchestrator.Sandbox.exe.config
  3. Aggiungere le righe seguenti all'interno dei tag <assemblyBinding>:
<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>

Nota

La soluzione alternativa sostituisce il file con l'originale se si riavvia MMA/il server abilitando la soluzione o applicando patch. Per entrambi questi scenari, è consigliabile sostituire il contenuto.

Scenario: l'esecuzione del runbook ha esito negativo

Problema

L'esecuzione del runbook ha esito negativo e viene visualizzato il messaggio di errore seguente:

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

Il runbook viene sospeso dopo il terzo tentativo di esecuzione. Alcune condizioni possono interrompere il runbook prima del completamento. Il relativo messaggio di errore potrebbe essere privo di informazioni aggiuntive.

Causa

Le possibili cause sono le seguenti:

  • I runbook non possono autenticarsi con le risorse locali.
  • Il ruolo di lavoro ibrido è protetto da proxy o firewall.
  • Il computer designato per eseguire il ruolo di lavoro ibrido per runbook non soddisfa i requisiti hardware minimi.

Risoluzione

Verificare che il computer abbia accesso in uscita a *.azure-automation.net sulla porta 443.

I computer che eseguono il ruolo di lavoro ibrido per runbook devono soddisfare i requisiti hardware minimi per consentire al ruolo di lavoro di ospitare questa funzionalità. I runbook e il processo in background in uso potrebbero causare un sovraccarico al sistema e provocare ritardi o timeout nei processi di runbook.

Verificare che il computer designato per svolgere il ruolo di lavoro ibrido per runbook soddisfi i requisiti hardware minimi. In caso affermativo, monitorare l'utilizzo di CPU e memoria per determinare eventuali correlazioni tra le prestazioni dei processi del ruolo di lavoro ibrido per runbook e Windows. Un uso elevato di CPU o memoria può indicare la necessità di aggiornamento delle risorse. In alternativa, selezionare una risorsa di calcolo diversa in grado di supportare i requisiti minimi e il ridimensionamento quando le esigenze del carico di lavoro indicano la necessità di un aumento.

Verificare se nel registro eventi Microsoft-SMA è presente un evento corrispondente alla descrizione Win32 Process Exited with code [4294967295]. L'errore è causato dalla mancata configurazione dell'autenticazione nei runbook oppure le credenziali Esegui come non sono state specificate per il gruppo del ruolo di lavoro ibrido. Controllare le autorizzazioni del runbook in Esecuzione di runbook in un ruolo di lavoro ibrido per runbook per verificare di avere configurato correttamente l'autenticazione per i runbook.

Scenario: I runbook hanno esito negativo con errore del gateway

Problema

Non è stato possibile aggiornare i processi del ruolo di lavoro ibrido per runbook durante la comunicazione tramite un server gateway di Log Analytics e l'errore restituito è simile al seguente: Spool operation id does not exist (spool ID): see attachment for job details and exact exception messages.

Risoluzione

Verificare che il server gateway di Log Analytics sia online e accessibile dal computer che ospita il ruolo di lavoro ibrido per runbook. Per altre informazioni sulla risoluzione dei problemi, vedere Risolvere i problemi relativi al gateway di Log Analytics.

Scenario: Il processo non viene avviato in quanto il ruolo di lavoro ibrido non era disponibile all'avvio del processo pianificato

Problema

Il processo non viene avviato su un ruolo di lavoro ibrido e viene restituito l'errore seguente:

Avvio non riuscito, perché il ruolo di lavoro ibrido non era disponibile all'avvio del processo pianificato, il ruolo di lavoro ibrido è stato attivo l'ultima volta il gg/mm/aaaa.

Causa

Questo errore si può verificare per i motivi seguenti:

  • I computer non esistono più.
  • Il computer è disattivato e non è raggiungibile.
  • Il computer ha un problema di connettività di rete.
  • L'estensione del ruolo di lavoro ibrido per runbook è stata disinstallata dal computer.

Risoluzione

  • Controllare che il computer esista e che l'estensione del ruolo di lavoro ibrido per runbook sia installata su di esso. Il ruolo di lavoro ibrido deve essere integro e restituire un heartbeat. Risolvere qualsiasi problema di rete controllando i registri eventi Microsoft-SMA sui ruoli di lavoro nel gruppo dei ruoli di lavoro ibridi per runbook che ha cercato di eseguire questo processo.
  • È anche possibile monitorare la metrica HybridWorkerPing, che fornisce il numero di ping da un ruolo di lavoro ibrido e può aiutare a identificare i problemi correlati ai ping.

Scenario: il processo è stato sospeso perché ha superato il limite di processi per un ruolo di lavoro ibrido

Problema

Il processo è stato sospeso con il messaggio di errore seguente:

Il processo è stato sospeso perché ha superato il limite di processi per un ruolo di lavoro ibrido. Aggiungere più ruoli di lavoro ibridi al gruppo di ruoli di lavoro ibridi per superare questo problema.

Causa

I processi potrebbero essere sospesi a causa di uno dei motivi seguenti:

  • Ciascun ruolo di lavoro ibrido attivo nel gruppo esegue il polling per i processi ogni 30 secondi per verificare la disponibilità di eventuali processi. Il ruolo di lavoro seleziona i processi in base all'ordine di arrivo. A seconda del momento in cui è stato eseguito il push di un processo, il ruolo di lavoro ibrido all'interno del gruppo di ruoli di lavoro ibridi che esegue per primo il ping del servizio di Automazione è quello che ottiene il processo. Un singolo ruolo di lavoro ibrido in genere può raccogliere quattro processi per ping, ovvero ogni 30 secondi. Se il tasso di push di processi è superiore a quattro ogni 30 secondi e nessun altro ruolo di lavoro seleziona il processo, quest'ultimo potrebbe essere sospeso.
  • Potrebbe non verificarsi il polling del ruolo di lavoro ibrido ogni 30 secondi, come previsto. Questo potrebbe verificarsi se il ruolo di lavoro non è integro o in presenza di problemi di rete.

Risoluzione

  • Se il limite di processi per un ruolo di lavoro ibrido supera i quattro processi ogni 30 secondi, è possibile aggiungere altri ruoli di lavoro ibridi al gruppo di ruoli di lavoro ibridi per ottenere una disponibilità elevata e un bilanciamento del carico. È anche possibile pianificare i processi, in modo che non superino il limite di quattro processi ogni 30 secondi. Il tempo di elaborazione della coda processi dipende dal profilo hardware e dal carico del ruolo di lavoro ibrido. Verificare che il ruolo di lavoro ibrido sia integro e restituisca un heartbeat.
  • Risolvere qualsiasi problema di rete controllando i registri eventi Microsoft-SMA sui ruoli di lavoro nel gruppo dei ruoli di lavoro ibridi per runbook che ha cercato di eseguire questo processo.
  • È anche possibile monitorare la metrica HybridWorkerPing, che fornisce il numero di ping da un ruolo di lavoro ibrido e può aiutare a identificare i problemi correlati ai ping.

Scenario: Evento 15011 nel ruolo di lavoro ibrido per runbook

Problema

Il ruolo di lavoro ibrido per runbook riceve l'evento 15011 a indicare che il risultato di una query non è valido. L'errore seguente viene visualizzato quando il ruolo di lavoro tenta di aprire una connessione con il server SignalR.

[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()​

Causa

Il ruolo di lavoro ibrido per runbook non è stato configurato correttamente per la distribuzione automatica delle funzionalità, ad esempio per Gestione aggiornamenti. La distribuzione contiene una parte che connette la macchina virtuale all'area di lavoro Log Analytics. Lo script di PowerShell cerca l'area di lavoro nella sottoscrizione con il nome specificato. In questo caso, l'area di lavoro Log Analytics si trova in una sottoscrizione diversa. Lo script non è in grado di trovare l'area di lavoro e tenta di crearne una, ma il nome è già in uso. Di conseguenza, la distribuzione ha esito negativo.

Risoluzione

Per risolvere il problema sono disponibili due opzioni:

  • Modificare lo script di PowerShell per cercare l'area di lavoro Log Analytics in un'altra sottoscrizione. Si tratta di una soluzione efficace se si prevede di distribuire molti computer con ruolo di lavoro ibrido per runbook in futuro.

  • Configurare manualmente il computer di lavoro per l'esecuzione in una sandbox di Orchestrator. Eseguire quindi un runbook creato nell'account di Automazione di Azure nel ruolo di lavoro per testare la funzionalità.

Scenario: macchine virtuali di Microsoft Azure eliminate automaticamente da un gruppo del ruolo di lavoro ibrido

Problema

Non è possibile visualizzare le VM o il ruolo di lavoro ibrido per runbook quando il computer di lavoro è rimasto inattivo per molto tempo.

Causa

Il computer con ruolo di lavoro ibrido per runbook non ha eseguito il ping con Automazione di Azure per più di 30 giorni. Di conseguenza, Automazione ha rimosso il gruppo del ruolo di lavoro ibrido per runbook o del ruolo di lavoro di sistema.

Risoluzione

Avviare il computer con ruolo di lavoro, quindi registrarlo nuovamente con Automazione di Azure. Per istruzioni su come installare l'ambiente per runbook e connettersi ad Automazione di Azure, vedere Distribuzione di un ruolo di lavoro ibrido per runbook di Windows.

Scenario: non è stato trovato alcun certificato nell'archivio certificati del ruolo di lavoro ibrido per runbook

Problema

Un runbook in esecuzione nel ruolo di lavoro ibrido per runbook ha esito negativo con il messaggio di errore seguente:

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

Causa

Questo errore si verifica quando si prova a usare un account RunAs in un runbook eseguito nel ruolo di lavoro ibrido per runbook in cui non è presente il certificato dell'account RunAs. Per impostazione predefinita, i ruoli di lavoro ibridi per runbook non hanno l'asset del certificato in locale. L'account RunAs richiede il corretto funzionamento di questo asset.

Risoluzione

Se il ruolo di lavoro ibrido per runbook in una macchina virtuale di Azure, è possibile usare l'autenticazione del runbook con le identità gestite. Questo scenario rende più semplice l'autenticazione, consentendo all'utente di autenticarsi nelle risorse di Azure usando l'identità gestita della macchina virtuale di Azure anziché l'account RunAs. Quando il ruolo di lavoro ibrido per runbook è un computer locale, è necessario installare sul computer il certificato dell'account RunAs. Per informazioni su come installare il certificato, vedere la procedura di esecuzione del runbook di PowerShell Export-RunAsCertificateToHybridWorker in Esecuzione di runbook in un ruolo di lavoro ibrido per runbook.

Scenario: Errore 403 durante la registrazione di un ruolo di lavoro ibrido per runbook

Problema

La fase di registrazione iniziale del ruolo di lavoro ha esito negativo e si visualizza l'errore 403 seguente:

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

Causa

Le possibili cause sono le seguenti:

  • Errore nella digitazione di un ID o una chiave (primaria) dell'area di lavoro nelle impostazioni dell'agente.
  • Download della configurazione da parte del ruolo di lavoro ibrido per runbook non riuscito, provocando un errore di collegamento degli account. Quando Azure abilita funzioni sui computer, il collegamento tra un'area di lavoro Log Analytics e un account di Automazione è supportato solo in determinate aree. È anche possibile che nel computer sia impostata una data o un'ora non corretta. Se si rileva una differenza di circa 15 minuti nell'orario, la distribuzione della funzionalità ha esito negativo.
  • Il gateway di Log Analytics non è configurato per supportare il ruolo di lavoro ibrido per runbook.

Risoluzione

Errore di digitazione di un ID o una chiave dell'area di lavoro

Per verificare la presenza di errori di digitazione nell'ID o nella chiave dell'area di lavoro dell'agente, vedere Aggiunta o rimozione di un'area di lavoro: Agente di Windows per l'agente di Windows o Aggiunta o rimozione di un'area di lavoro: Agente di Linux per l'agente di Linux. Assicurarsi di selezionare la stringa completa nel portale di Azure, quindi copiarla e incollarla con cautela.

Configurazione non scaricata

L'area di lavoro Log Analytics e l'account di Automazione devono trovarsi in un'area collegata. Si tratta della soluzione consigliata per il ruolo di lavoro ibrido per runbook usato da Gestione aggiornamenti. Per un elenco delle aree supportate, vedere Mapping dell'area di lavoro Log Analytics e di Automazione di Azure.

Potrebbe inoltre essere necessario aggiornare la data o il fuso orario del computer. Se si seleziona un intervallo di tempo personalizzato, assicurarsi di usare il fuso orario UTC, che può essere diverso da quello locale.

Gateway di Log Analytics non configurato

Seguire i passaggi indicati qui per aggiungere endpoint del ruolo di lavoro ibrido per runbook al gateway di Log Analytics.

Scenario: Set-AzStorageBlobContent non riesce in un ruolo di lavoro ibrido per runbook

Problema

Il runbook non riesce quando cerca di eseguire Set-AzStorageBlobContent e viene visualizzato il messaggio di errore seguente:

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

Causa

Questo errore è causato dal comportamento del nome di file lungo delle chiamate a [System.IO.Path]::GetFullPath(), che aggiunge percorsi UNC.

Risoluzione

Come soluzione alternativa, è possibile creare un file di configurazione denominato OrchestratorSandbox.exe.config con il contenuto seguente:

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

Posizionare questo file nella stessa cartella del file eseguibile OrchestratorSandbox.exe. ad esempio:

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

Nota

Se si aggiorna l'agente, questo file di configurazione verrà eliminato e dovrà essere ricreato.

Linux

Il ruolo di lavoro ibrido per runbook di Linux si affida all'agente di Log Analytics per Linux per comunicare con l'account di Automazione e registrare il ruolo di lavoro, ricevere i processi del runbook e segnalare lo stato. Se la registrazione del ruolo di lavoro non riesce, ecco alcune possibili cause dell'errore.

Scenario: Il ruolo di lavoro ibrido per runbook di Linux riceve la richiesta di una password durante la firma di un runbook

Problema

L'esecuzione del comando sudo per un ruolo di lavoro ibrido per runbook di Linux recupera una richiesta di password imprevista.

Causa

L'account nxautomationuser per l'agente di Log Analytics per Linux non è configurato correttamente nel file sudoers. Il ruolo di lavoro ibrido per runbook richiede una configurazione adeguata delle autorizzazioni dell'account e di altri dati, in modo che possa firmare i runbook nel ruolo di lavoro per runbook di Linux.

Risoluzione

Scenario: L'agente di Log Analytics per Linux non è in esecuzione

Problema

L'agente di Log Analytics per Linux non è in esecuzione.

Causa

Se l'agente non è in esecuzione, il ruolo di lavoro ibrido per runbook di Linux non è in grado di comunicare con Automazione di Azure. L'agente potrebbe non essere in esecuzione per diversi motivi.

Risoluzione

Verificare che l'agente sia in esecuzione immettendo il comando ps -ef | grep python. L'output dovrebbe essere simile al seguente. Sono inclusi i processi Python e l'account utente nxautomation. Se la funzionalità di Automazione di Azure non è abilitata, non viene eseguito nessuno dei processi seguenti.

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>

L'elenco seguente mostra i processi avviati per un ruolo di lavoro ibrido per runbook di Linux. Si trovano tutti nella directory /var/opt/microsoft/omsagent/state/automationworker/.

  • oms.conf: processo di gestione del ruolo di lavoro. Viene avviato direttamente da DSC.
  • worker.conf: processo del ruolo di lavoro ibrido registrato automaticamente. Viene avviato dal gestore del ruolo di lavoro. Questo processo viene usato da Gestione aggiornamenti ed è trasparente all'utente. Non è presente se la soluzione Gestione aggiornamenti non è abilitata nel computer.
  • diy/worker.conf: processo del ruolo di lavoro ibrido registrato manualmente. Il processo del ruolo di lavoro ibrido registrato manualmente viene usato per eseguire i runbook dell'utente nel ruolo di lavoro ibrido per runbook. L'unica differenza con il processo del ruolo di lavoro ibrido registrato automaticamente consiste nell'uso di una configurazione diversa. Questo processo non è presente se Automazione di Azure non è abilitata e il ruolo di lavoro ibrido manuale di Linux non è registrato.

Se l'agente non è in esecuzione, eseguire il comando seguente per avviare il servizio: sudo /opt/microsoft/omsagent/bin/service_control restart.

Scenario: La classe specificata non esiste

Se si visualizza il messaggio di errore The specified class does not exist.. in /var/opt/microsoft/omsconfig/omsconfig.log, è necessario aggiornare l'agente di Log Analytics per Linux. Eseguire il comando seguente per reinstallare l'agente.

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

Finestre

Il ruolo di lavoro ibrido per runbook di Windows si affida all'agente di Log Analytics per Windows per comunicare con l'account di Automazione e registrare il ruolo di lavoro, ricevere i processi del runbook e segnalare lo stato. Se la registrazione del ruolo di lavoro ha esito negativo, questa sezione include alcune possibili cause.

Scenario: L'agente di Log Analytics per Windows non è in esecuzione

Problema

Il servizio healthservice non è in esecuzione nel computer del ruolo di lavoro ibrido per runbook.

Causa

Se il servizio di Log Analytics per Windows non è in esecuzione, il ruolo di lavoro ibrido per runbook di Linux non è in grado di comunicare con Automazione di Azure.

Risoluzione

Verificare l'effettiva esecuzione dell'agente immettendo il comando seguente in PowerShell: Get-Service healthservice. Se il servizio viene arrestato, immettere il comando seguente in PowerShell per avviare il servizio: Start-Service healthservice.

Scenario: Evento 4502 nel log di Operations Manager

Problema

Nel registro eventi Application and Services Logs\Operations Manager viene visualizzato l'evento 4502 e un messaggio di evento contenente Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent con la descrizione seguente:
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.

Causa

Questo problema può essere causato dal firewall proxy o di rete che blocca la comunicazione con Microsoft Azure. Verificare che il computer abbia accesso in uscita a *.azure-automation.net sulla porta 443.

Risoluzione

I log vengono archiviati localmente in ogni ruolo di lavoro ibrido in C:\ProgramData\Microsoft\System Center\Orchestrator\7.2\SMA\Sandboxes. È possibile verificare la presenza di eventuali avvisi o eventi di errore nei registri eventi Application and Services Logs\Microsoft-SMA\Operations e Application and Services Logs\Operations Manager. Questi registri indicano problemi di connettività o di altro tipo che influiscono sull'abilitazione del ruolo in Automazione di Azure o problemi riscontrati durante normali operazioni. Per altre informazioni sulla risoluzione dei problemi relativi all'agente di Log Analytics, vedere Risoluzione dei problemi relativi all'agente dell'analisi dei log di Windows.

I ruoli di lavoro ibridi inviano output e messaggi del runbook ad Automazione di Azure nello stesso modo in cui li inviano i processi del runbook in esecuzione nel cloud. È possibile abilitare i flussi dettagliati e di stato esattamente come per i runbook.

Scenario: Connessione di Orchestrator.Sandbox.exe a Microsoft 365 tramite proxy non riuscita

Problema

Uno script in esecuzione in un ruolo di lavoro ibrido per runbook di Windows non si connette come previsto a Microsoft 365 su una sandbox di Orchestrator. Lo script usa Connect-MgGraph per la connessione.

Se si modifica Orchestrator.Sandbox.exe.config per configurare il proxy e l'elenco di esclusione, la sandbox continua a non connettersi correttamente. Un file Powershell_ise.exe.config con le stesse impostazioni del proxy e dell'elenco di esclusione. I registri di Service Management Automation (SMA) e PowerShell non forniscono alcuna informazione relativa al proxy.

Causa

La connessione ad Active Directory Federation Services (AD FS) nel server non può escludere il proxy. Tenere presente che una sandbox di PowerShell viene eseguita come utente registrato. Tuttavia, una sandbox di Orchestrator è altamente personalizzata e potrebbe ignorare le impostazioni del file Orchestrator.Sandbox.exe.config. La sandbox dispone di codice speciale per gestire le impostazioni del computer o del proxy agente di Log Analytics, ma non per la gestione di altre impostazioni del proxy personalizzate.

Risoluzione

È possibile risolvere il problema per la sandbox di Orchestrator eseguendo la migrazione dello script per usare i moduli Microsoft Entra anziché i cmdlet di PowerShell. Per altre informazioni, vedere Migrazione da Orchestrator ad Automazione di Azure (Beta).

​Se si vuole continuare a usare i cmdlet del modulo, modificare lo script in modo da usare Invoke-Command. Specificare i valori per i parametri ComputerName e Credential.

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

Questa modifica del codice avvia una sessione di PowerShell completamente nuova nel contesto delle credenziali specificate. Questo dovrebbe abilitare il flusso del traffico tramite un server proxy che esegue l'autenticazione dell'utente attivo.

Nota

Questa risoluzione rende non necessaria la modifica del file di configurazione sandbox. Anche se funziona correttamente con lo script, il file di configurazione viene cancellato ogni volta che si aggiorna l'agente del ruolo di lavoro ibrido per runbook.

Scenario: Nessuna segnalazione da parte dei ruoli di lavoro ibridi per runbook

Problema

Il computer del ruolo di lavoro ibrido per runbook è in esecuzione, ma non vengono visualizzati i dati di heartbeat per il computer nell'area di lavoro.

La query di esempio seguente mostra i computer di un'area di lavoro e l'ultimo heartbeat generato:

Heartbeat
| summarize arg_max(TimeGenerated, *) by Computer

Causa

Questo problema può essere causato da una cache danneggiata nel ruolo di lavoro ibrido per runbook.

Risoluzione

Per risolvere questo problema, accedere al ruolo di lavoro ibrido per runbook ed eseguire lo script seguente. Questo script l'agente di Log Analytics per Windows, rimuove la cache e riavvia il servizio. Questa azione costringe il ruolo di lavoro ibrido per runbook a scaricare nuovamente la configurazione da Automazione di Azure.

Stop-Service -Name HealthService

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

Start-Service -Name HealthService

Scenario: Non è possibile aggiungere un ruolo di lavoro ibrido per runbook di Windows

Problema

Quando si prova ad aggiungere un ruolo di lavoro ibrido per runbook usando il cmdlet Add-HybridRunbookWorker viene visualizzato il messaggio seguente:

Machine is already registered

Causa

Questo problema può verificarsi se il computer è già registrato con un account di Automazione diverso o se si prova ad aggiungere nuovamente il ruolo di lavoro ibrido per runbook dopo averlo rimosso da un computer.

Risoluzione

Per risolvere questo problema, rimuovere la chiave del Registro di sistema seguente, riavviare HealthService e provare di nuovo a eseguire il cmdlet Add-HybridRunbookWorker.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HybridRunbookWorker

Scenario: Non è possibile aggiungere un ruolo di lavoro ibrido per runbook Linux

Problema

Quando si prova ad aggiungere un ruolo di lavoro ibrido per runbook usando lo script Python sudo python /opt/microsoft/omsconfig/.../onboarding.py --register, viene visualizzato il messaggio seguente:

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

Inoltre, tentando di annullare la registrazione di un ruolo di lavoro ibrido per runbook usando lo script Python sudo python /opt/microsoft/omsconfig/.../onboarding.py --deregister:

Failed to deregister worker. [response_status=404]

Causa

Questo problema può verificarsi se il computer è già registrato con un account di Automazione diverso, se il gruppo di ruoli di lavoro ibridi di Azure è stato eliminato o se si tenta di aggiungere nuovamente il ruolo di lavoro ibrido per runbook dopo averlo rimosso da un computer.

Risoluzione

Per risolvere il problema:

  1. Rimuovere l'agente sudo sh onboard_agent.sh --purge.

  2. Eseguire i comandi seguenti:

    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. Eseguire di nuovo l'onboarding dell'agente sudo sh onboard_agent.sh -w <workspace id> -s <workspace key> -d opinsights.azure.com.

  4. Attendere che la cartella /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker venga popolata.

  5. Provare di nuovo lo script Python sudo python /opt/microsoft/omsconfig/.../onboarding.py --register.

Passaggi successivi

Se il problema riscontrato non è presente in questo elenco o se non si riesce a risolverlo, visitare uno dei canali seguenti per ottenere maggiore assistenza:

  • Ottenere risposte dagli esperti di Azure tramite i forum di Azure.
  • Connettersi con @AzureSupport, l'account ufficiale Microsoft Azure per migliorare l'esperienza del cliente. Il supporto di Azure mette in contatto la community di Azure con le risorse giuste: risposte, supporto ed esperti.
  • Archiviare un incidente del supporto tecnico di Azure. Accedere al sito del supporto tecnico di Azure e selezionare Supporto tecnico.