Problem med direktanslutning i Power Automate för dator

Den här artikeln innehåller mer information om hur du löser problem med direktanslutning i Microsoft Power Automate för dator.

Gäller för: Power Automate
Ursprungligt KB-nummer: 5016345

Symptom

Tänk på följande scenarier när du använder direkt datoranslutning (inte datagatewayen, som har blivit inaktuell för skrivbordsflöden):

Scenario 1

• Dina tidigare registrerade datorer visas offline när de startas och är anslutna till nätverket.

• Körningar misslyckas med något av följande felmeddelanden:

  ConnectionNotEstablished – ingen av de anslutna lyssnarna accepterade anslutningarna inom den tillåtna tidsgränsen. Kontrollera att datorn är online.

  NoListenerConnected – slutpunkten hittades inte. Det finns inga lyssnare anslutna för slutpunkten. Kontrollera att datorn är online.

Scenario 2

• Skrivbordsflöden körs på en registrerad dator så länge en användarsession körs (deltog i körningar) eller till och med i några minuter efter att den senaste användaren har loggat ut (obevakade körningar).
• Anslutningen till datorn går förlorad efter några minuter (till exempel 15 minuter).
• Anslutningen återupprättas när en användare loggar in på datorn igen.

Orsak

Direkt till datoranslutning använder Azure WCF-reläer så att Microsoft-molnet kan ansluta till lokala datorer och schemalägga körningar av skrivbordsflöden. Power Automate Windows-tjänsten som körs lokalt öppnar en vidarebefordranlyssnare som ansluter till Azure-molnet genom att öppna webbsocketar.

Den vanligaste orsaken till problem med reläanslutningen är att datorn förlorar anslutningen till nätverket. Detta kan bero på att datorn inte är påslagen eller förlorar nätverket när ingen användare är inloggad på datorn till exempel.

Power Automate-tjänsten körs under sitt eget Windows-konto (NT Service\UIFlowService som standard) som måste ha åtkomst till nätverket och kunna ansluta till *.servicebus.windows.net (mer information finns i nätverkskrav.)

Om datorn och Power Automate-tjänsten har tillförlitlig åtkomst till nätverket är den näst mest likartade källan till problem att det lokala nätverket blockerar eller stör Azure Relay-anslutningar.

En vanlig gärningsman i båda scenarierna är en nätverksproxy som begränsar utgående trafik. I synnerhet autentiserade proxyservrar som använder autentiseringsuppgifterna för den anslutna Windows-användaren, eftersom Power Automate-tjänsten körs under sitt eget dedikerade konto.

Du kan läsa proxykonfigurationen om du anser att du behöver åsidosätta standardproxyinställningarna som används av Power Automate-tjänsten. Du kan också behöva ändra det lokala tjänstkontot.

Så här undersöker du

1. För att hjälpa dig att undersöka dessa problem bör du kontakta nätverksadministratörerna som har den kunskap som krävs för att förstå vad som händer.

2. Förstå nätverkets topologi: vilka nätverksenheter som trafiken går igenom innan de överlämnas till det offentliga Internet: NAT, brandväggar, proxyservrar och så vidare. Hämta loggar från dessa enheter under påverkade körningar och loggar från den yttersta nätverksenheterna som intygar att trafiken till *.servicebus.windows.net överlämnas till det offentliga Internet.

3. Hämta WCF-loggar från UI-flödestjänsten. Mer information finns i avsnittet Aktivera WCF-spårning nedan.

4. Kontrollera att nätverkskonfigurationen tillåter webbsockettrafik och långvariga anslutningar: ett vanligt mönster är proxyservrar eller andra nätverksenheter som dödar anslutningar efter en viss tid.

Vilken information som ska ingå när du öppnar ett supportärende

• Din nätverkstopologi: vilka enheter trafiken går igenom. (se steg 2 i avsnittet ovan)
• Loggar från dina nätverksenheter som visar att trafiken verkligen vidarebefordras till det offentliga Internet. Inkludera tidpunkter för problemen och de tidszoner som används av loggarna.
• WCF-spårningar från de berörda datorerna. (se avsnittet Aktivera WCF-spårning nedan)
• Körnings-ID:t för skrivbordsflöde för påverkade körningar.
• Lokala loggar från den berörda datorn: de kan extraheras med hjälp av power automate-datorns körningsapps felsökningsfönster.

Aktivera WCF-spårning

I installationsmappen (vanligtvis C:\Program Files (x86)\Power Automate Desktop) redigerar duUIFlowService.exe.config-filen . Detta kräver att du kör textredigeraren som administratör.

Lägg till det här konfigurationsavsnittet:

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel" 
            switchValue="Information,ActivityTracing"
            propagateActivity="true">
      <listeners>
        <add name="wcfTraces"
             type="System.Diagnostics.XmlWriterTraceListener"
             initializeData="c:\logs\PADwcfTraces.svclog" />
      </listeners>
    </source>
  </sources>
 <trace autoflush="true" />
</system.diagnostics>

• Du kan ersätta c:\logs\PADwcfTraces.svclog värdet med valfri giltig sökväg, men mappen (c:\logs i det här exemplet) måste finnas, annars skapas den inte och loggar skrivs inte.
• Power Automate-tjänsten måste ha behörighet att skriva i den valda mappen, vilket ger användaren fullständig kontroll över mappen fungerar. Du kan hämta tjänstanvändarens Sid genom att köra sc showsid UIFlowService på en kommandorad om du bara vill ge behörighet till den användaren.

Det här konfigurationsavsnittet måste läggas till mellan </system.net> och <appInställningar>, se följande skärmbild:

När du har sparat konfigurationsfilen startar du om Power Automate-tjänsten. Detta kan göras i verktyget Tjänster. Du hittar verktyget genom att skriva tjänster på Start-menyn, söka efter Power Automate-tjänsten, högerklicka på den och välja Starta om. Följande skärmbild visar steget för att starta om Power Automate-tjänsten:

Spårningar skrivs sedan till den fil som valts i konfigurationen.