この記事では、Microsoft デスクトップ用 Power Automate での直接接続の問題を解決する方法について詳しく説明します。
適用対象: Power Automate
元の KB 番号: 5016345
現象
クラウド フローからデスクトップ フローを実行したり、デスクトップ フロー マシンを管理したりしようとすると、次のいずれかの問題が発生する可能性があります。
シナリオ 1
以前に登録したマシンは、起動してネットワークに接続するとオフラインで表示されます。
次のいずれかのエラー メッセージで実行が失敗します。
ConnectionNotEstablished - 許可されたタイムアウト内に接続されたリスナーのいずれも接続を受け入れられませんでした。 コンピューターがオンラインであることを確認します。
NoListenerConnected - エンドポイントが見つかりませんでした。 エンドポイントに接続されているリスナーはありません。 コンピューターがオンラインであることを確認します。
シナリオ 2
- デスクトップ フローは、ユーザー セッションが実行されている (参加済みの実行) 限り、または最後のユーザーがサインアウトしてから数分 (無人実行) 場合でも、登録済みのコンピューター上で実行されます。
- マシンへの接続は、数分後に失われます (たとえば、15 分)。
- ユーザーがコンピューターにサインインし直すと、接続が再確立されます。
シナリオ 3
Windows コンピューターからサインアウトすると、Power Automate ポータルのコンピューターの状態が切断済みとして表示されます。
原因
コンピューターへの直接接続では、 Azure WCF リレー を使用して、Microsoft クラウドがオンプレミスのマシンに接続し、デスクトップ フローの実行をスケジュールできます。 オンプレミスで実行される Power Automate Windows サービスは、Web ソケットを開くことで Azure クラウドに接続するリレー リスナーを開きます。
リレー接続の問題の最も一般的な原因は、マシンがネットワークへの接続を失うことです。 これは、ユーザーがマシンにサインインしていないときに、コンピューターの電源がオンにされていないか、ネットワークが失われていることが原因で発生する可能性があります。
Power Automate サービスは、ネットワークにアクセスでき、 *.servicebus.windows.net に接続できる必要がある独自の Windows アカウント (NT Service\UIFlowService 既定) で実行されます (詳細については、 network 要件を参照してください)。
Note
Azure 仮想マシン (VM) を使用してデスクトップ用 Power Automateを実行する場合は、Azure VM が配置されているサブネット レベルで Microsoft.ServiceBus エンドポイントがオフになっていることを確認します。 これは、既知の制限です。 詳細については、「 Azure Relay はネットワーク サービス エンドポイントをサポートしていませんを参照してください。
マシンと Power Automate サービスがネットワークへの信頼性の高いアクセス権を持っている場合、次に問題の原因は、オンプレミスネットワークのブロックまたは Azure リレー接続の妨害です。
どちらのシナリオでも一般的な原因は、送信トラフィックを制限するネットワーク プロキシです。 特に、Power Automate サービスが独自の専用アカウントで実行されることを考えると、接続された Windows ユーザーの資格情報を使用する認証済みプロキシ。
Power Automate サービスで使用される既定のプロキシ設定をオーバーライドする必要があると判断した場合はProxy のセットアップを参照してください。 オンプレミスのサービス アカウント 変更する必要がある場合もあります。
調査方法
これらの問題を調査するには、ネットワーク管理者が、何が起こっているかを理解するために必要な知識を持っていることを確認してください。
ネットワークのトポロジについて理解します。パブリック インターネットに渡される前にトラフィック がホップスルーするネットワーク デバイス (NAT、ファイアウォール、プロキシなど)。 影響を受ける実行中にこれらのデバイスからログを取得し、 *.servicebus.windows.net へのトラフィックがパブリック インターネットに渡されることを証明する最も外側のネットワーク デバイスからログを取得します。
ネットワーク トラフィックがプロキシを使用して実行される場合は、Power Automate サービス (UIFlowService) が実行されるオンプレミス アカウントを変更して、問題の軽減を試みます。
Power Automate サービス (UIFlowService) から WCF ログを取得します。 詳細については、以下の「 有効な WCF トレース 」セクションを参照してください。
ネットワーク構成で Web ソケット トラフィックと実行時間の長い接続が許可されていることを確認します。一般的なパターンは、設定された時間が経過した後に接続を強制終了するプロキシまたはその他のネットワーク デバイスです。
サポート チケットを開くときに含める情報
- ネットワーク トポロジ: トラフィックが通過するデバイスは何ですか。 (上記のセクションの手順 2 を参照)
- コンピューター上の Power Automate サービス (UIFlowService) が既定のアカウント (NT Service\UIFlowService) として実行されているか、別のアカウントとして実行されるように変更されているか。
- トラフィックが実際にパブリック インターネットに渡されていることを示すネットワーク デバイスからのログ。 問題の時刻と、ログで使用されるタイム ゾーンを含めます。
- 影響を受けたマシンからの WCF トレース。 ( を参照してください。WCF トレースを有効にする 後のセクション)
- 影響を受けた実行のデスクトップ フロー実行 ID。
- 影響を受けるコンピューターからのローカル ログ: Power Automate マシン ランタイム アプリのトラブルシューティング ウィンドウを使用して抽出できます。
WCF トレースを有効にする
インストール フォルダー (通常は C:\Program Files (x86)\Power Automate Desktop) で、 UIFlowService.exe.config ファイルを編集します。 これには、管理者としてテキスト エディターを実行する必要があります。
次の構成セクションを追加します。
<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>
-
c:\logs\PADwcfTraces.svclog値は任意の有効なパスに置き換えることができますが、フォルダー (この例ではc:\logs) が存在している必要があります。そうしないと、作成されなくなり、ログは書き込まれません。 - Power Automate サービスには、選択したフォルダーに書き込むアクセス許可が必要です。"Everyone" ユーザーにフォルダーの完全な制御権が付与されます。 そのユーザーにのみアクセス許可を付与する場合は、コマンド ラインで
sc showsid UIFlowServiceを実行することで、サービス ユーザーの Sid を取得できます。
この構成セクションは、 </system.net> と <appSettings の間に追加する必要があります>次のスクリーンショットを参照してください。
構成ファイルを保存した後、Power Automate サービスを再起動します。 これは、サービス ツールで実行できます。 ツールは、スタート メニューに「 services 」と入力し、Power Automate Service を見つけて右クリックし、 Restart を選択することで見つけることができます。 次のスクリーンショットは、Power Automate サービスを再起動する手順を示しています。
その後、構成で選択したファイルにトレースが書き込まれます。