セルフホステッド統合ランタイムのトラブルシューティング

[アーティクル]
01/05/2024

適用対象: Azure Data Factory Azure Synapse Analytics Microsoft Purview

ヒント

企業向けのオールインワン分析ソリューション、Microsoft Fabric の Data Factory をお試しください。 Microsoft Fabric は、データ移動からデータサイエンス、リアルタイム分析、ビジネスインテリジェンス、レポートまで、あらゆるものをカバーしています。無料で新しい試用版を開始する方法について説明します。

この記事では、Azure Data Factory および Synapse ワークスペースにおけるセルフホステッド統合ランタイム (IR) に対する共通のトラブルシューティング方法を探索します。

セルフホステッド IR を収集する

Azure Data Factory と Azure Synapse Analytics

セルフホステッド IR または共有 IR で実行中のアクティビティが失敗した場合、Azure Data Factory ではエラーログの表示とアップロードがサポートされます。エラーレポート ID を取得するには、こちらの手順に従い、レポート ID を入力して関連する既知の問題を検索します。

サービス UI の [監視] ページで、 [パイプラインの実行] を選びます。
次のスクリーンショットに示すように、 [アクティビティの実行] の下の [エラー] 列で、強調表示されたボタンを選択してアクティビティログを表示します。
- Azure Data Factory
- Azure Synapse
失敗したアクティビティの実行に関するアクティビティログが表示されます。
さらに支援が必要な場合は、 [ログの送信] を選択してください。

[Share the self-hosted integration runtime (IR) logs with Microsoft](セルフホステッド統合ランタイム (IR) ログを Microsoft と共有する) ウィンドウが開きます。
送信するログを選択します。
- "セルフホステッド IR" では、失敗したアクティビティに関連するログ、またはセルフホステッド IR ノード上のすべてのログをアップロードできます。
- "共有 IR" では、失敗したアクティビティに関連するログのみをアップロードできます。
ログがアップロードされたら、問題を解決するためにさらに支援が必要な場合に後で使用できるように、レポート ID を記録しておきます。

注意

ログの表示とアップロードの要求は、すべてのオンラインセルフホステッド IR インスタンスで実行されます。いずれかのログが欠落している場合は、すべてのセルフホステッド IR インスタンスがオンラインになっていることを確認してください。

Microsoft Purview

セルフホステッド IR または共有 IR で実行中に失敗した Microsoft Purview に対して、サービスでは Windows イベントビューアーからのエラーログの表示とアップロードがサポートされています。

表示されるすべてのエラーは以下のエラーガイドで検索できます。 SHIR の問題に関するサポートとトラブルシューティングのガイダンスを受けるには、エラーレポート ID を生成し、Microsoft サポートに問い合わせをしていただく必要があります。

Microsoft サポートのためのエラーレポート ID を生成するには、次の手順に従います。

Microsoft Purview ガバナンスポータルでスキャンを開始する前に、次の手順を実行します。
1. セルフホステッド統合ランタイムがインストールされているマシンに移動し、Windows イベントビューアーを開きます。
2. [統合ランタイム] セクションで Windows イベントビューアーログをクリアします。ログを右クリックし、[ログのクリア] オプションを選択します。
3. Microsoft Purview ガバナンスポータルに戻り、スキャンを開始します。
スキャンの状態が失敗と表示されたら、SHIR VM またはマシンに戻り、[統合ランタイム] セクションでイベントビューアーを更新します。
失敗したスキャン実行に関するアクティビティログが表示されます。
Microsoft からさらにサポートを受ける場合は、[ログの送信] を選択します。

[セルフホステッド統合ランタイム (SHIR) ログを Microsoft と共有する] ウィンドウが開きます。
送信するログを選択します。
- "セルフホステッド IR" では、失敗したアクティビティに関連するログ、またはセルフホステッド IR ノード上のすべてのログをアップロードできます。
- "共有 IR" では、失敗したアクティビティに関連するログのみをアップロードできます。
ログがアップロードされたら、問題を解決するためにさらに支援が必要な場合に後で使用できるように、レポート ID を記録しておきます。

注意

セルフホステッド IR の一般的な障害またはエラー

メモリ不足の問題

現象

リンクされた IR またはセルフホステッド IR を使用してルックアップアクティビティを実行しようとすると、OutOfMemoryException (OOM) エラーが発生します。
原因

IR マシンで瞬間的にメモリが大量に使用された場合、新しいアクティビティによって OOM エラーがスローされることがあります。この問題は、大量の同時実行アクティビティが原因で発生する可能性があります。このエラーは設計によるものです。
解決策

IR ノードでリソース使用量とアクティビティの同時実行を確認してください。 1 つの IR ノードでの同時実行が過剰にならないように、アクティビティ実行の内部およびトリガーの時間を調整します。

コンカレントジョブの制限の問題

現象

UI からコンカレントジョブの上限数を増やそうとすると、プロセスは [更新中] 状態でハングアップします。

サンプルシナリオ: コンカレントジョブの最大値は現在 24 に設定されていますが、ジョブの実行速度を上げるために、この数を増やしたいと考えています。入力できる最小値は 3 で、最大値は 32 です。値を 24 から 32 に増やしてから、 [更新] ボタンを選択します。次のスクリーンショットに示すように、プロセスは [更新中] の状態でスタックします。ページを更新しても、値は 24 と表示されたままです。予期していた 32 には更新されていません。
原因

コンカレントジョブ数の制限は、コンピューターの論理コアとメモリによって決まります。値を 24 などの値に下方に調整して、結果を表示してみてください。
ヒント
- 論理コア数の詳細を確認し、使用するマシンの論理コア数を判別するには、Windows 10 で CPU のコア数を調べる 4 つの方法に関するページを参照してください。
- math.log を計算する方法については、対数計算機のページにアクセスしてください。

セルフホステッド IR 高可用性 (HA) の SSL 証明書の問題

現象

セルフホステッド IR のワークノードで次のエラーが報告されました。

"Failed to pull shared states from primary node net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. (プライマリノード net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/ から共有状態をプルできませんでした。) Activity ID:XXXXX The X.509 certificate CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft chain building failed. (アクティビティ ID: XXXXX。X.509 証明書 CN=abc.cloud.corp.Microsoft.com、OU=test、O=Microsoft チェーンの作成に失敗しました。) 使用された証明書には、検証できない信頼チェーンが含まれています。証明書を交換するか、certificateValidationMode を変更してください。 The revocation function was unable to check revocation because the revocation server was offline. (失効サーバーがオフラインであったため、失効関数が失効を確認できませんでした。)"
原因

SSL/TLS ハンドシェイクに関連したケースを処理しているときに、証明書チェーンの検証に関連した問題が発生することがあります。
解決策
- X.509 証明書チェーンの作成エラーをトラブルシューティングするための簡単で直感的な方法を次に示します。
  1. 検証が必要な証明書をエクスポートします。そのためには、次の手順を実行します。
    
    a. Windows で [スタート] を選択し、「証明書」と入力し始めて、 [コンピューター証明書の管理] を選択します。
    
    b. エクスプローラーの左側のペインで、確認する証明書を検索し、それを右クリックしてから、 [すべてのタスク] > [エクスポート] を選択します。
  2. エクスポートされた証明書をクライアントマシンにコピーします。
  3. クライアント側のコマンドプロンプトウィンドウで、次のコマンドを実行します。 <certificate path> と <output txt file path> を実際のパスに置き換えてください。
```
Certutil -verify -urlfetch    <certificate path>   >     <output txt file path> 
```
    例:
```
Certutil -verify -urlfetch c:\users\test\desktop\servercert02.cer > c:\users\test\desktop\Certinfo.txt
```
  4. 出力 TXT ファイルにエラーがないかどうかを確認します。エラーの概要は、この TXT ファイルの最後にあります。
    
    次に例を示します。
    
    次のスクリーンショットに示すように、ログファイルの最後にエラーがない場合は、証明書チェーンがクライアントマシンで正常に作成されたと考えることができます。
- AIA (機関情報アクセス)、CDP (CRL 配布ポイント)、または OCSP (オンライン証明書状態プロトコル) のファイル名拡張子が証明書ファイルに構成されている場合は、より直観的な方法で確認できます。
  1. 次のスクリーンショットに示されているように、証明書の詳細を確認してこの情報を取得します。
  2. 次のコマンドを実行します。 <certificate path> は、必ず証明書の実際のパスに置き換えてください。
```
  Certutil   -URL    <certificate path> 
```
    URL 取得ツールが開きます。
  3. AIA、CDP、および OCSP のファイル名拡張子を持つ証明書を確認するには、 [取得] を選択します。
    
    AIA からの証明書の状態が "検証済み" で、なおかつ CDP または OCSP からの証明書の状態が "検証済み" であれば、証明書チェーンは正常に作成されています。
    
    AIA または CDP を取得しようとして失敗した場合は、ネットワークチームと協力して、クライアントマシンをターゲット URL に接続できる状態にしてください。 HTTP パスまたはライトウェイトディレクトリアクセスプロトコル (LDAP) パスのいずれかを確認できれば十分です。

セルフホステッド IR がファイルまたはアセンブリを読み込めない

現象

次のエラーメッセージが表示されます。

"Could not load file or assembly 'XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' or one of its dependencies. (ファイルまたはアセンブリ 'XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX'、またはその依存関係の 1 つを読み込めませんでした。) 指定されたファイルが見つかりません。 Activity ID: (アクティビティ ID:) 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

より具体的なエラーメッセージを次に示します。

"Could not load file or assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' or one of its dependencies. (ファイルまたはアセンブリ 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX'、またはその依存関係の 1 つを読み込めませんでした。) 指定されたファイルが見つかりません。 Activity ID: (アクティビティ ID:) 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"
原因

プロセスモニターで、次の結果を表示できます。

ヒント

プロセスモニターで、次のスクリーンショットに示すようにフィルターを設定できます。

前のエラーメッセージは、DLL System.ValueTuple が、関連するグローバルアセンブリキャッシュ (GAC) フォルダー、C:\Program Files\Microsoft Integration Runtime\4.0\Gateway フォルダー、または C:\Program Files\Microsoft Integration Runtime\4.0\Shared フォルダー内にないことを示しています。

基本的に、このプロセスでは、まず GAC フォルダーから、次に "共有" フォルダーから、そして最後に "ゲートウェイ" フォルダーから DLL が読み込まれます。そのため、有用なパスであれば、どのパスからでも DLL を読み込むことができます。
解像度

System.ValueTuple.dll ファイルは C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan フォルダーにあります。この問題を解決するには、System.ValueTuple.dll ファイルを C:\Program Files\Microsoft Integration Runtime\4.0\Gateway フォルダーにコピーします。

その他の欠落しているファイルやアセンブリの問題も同じ方法を使用して解決できます。
この問題に関する追加情報

System.ValueTuple.dll が %windir%\Microsoft.NET\assembly や %windir%\assembly の下に表示される理由は、これが .NET の動作だからです。

次のエラーでは、System.ValueTuple アセンブリが欠落していることを明確に確認できます。この問題は、アプリケーションが System.ValueTuple.dll アセンブリを確認しようとしたときに発生します。

"<LogProperties><ErrorInfo>[{"Code":0,"Message":"The type initializer for 'Npgsql.PoolManager' threw an exception.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Could not load file or assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' or one of its dependencies. (LogPropertiesErrorInfo[{"Code":0,"Message":"'Npgsql.PoolManager' のタイプ初期化子が例外をスローしました。","EventType":0,"Category":5,"Data":,"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"ファイルまたはアセンブリ 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX'、またはその依存関係の 1 つを読み込めませんでした。) The system cannot find the file specified.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties> (指定されたファイルが見つかりません。","EventType":0,"Category":5,"Data":,"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]/ErrorInfo/LogProperties)"

GAC の詳細については、「グローバルアセンブリキャッシュ」を参照してください。

セルフホステッド統合ランタイムの認証キーがない

現象

セルフホステッド統合ランタイムが認証キーなしで突然オフラインになり、イベントログに次のエラーメッセージが表示されます。

"Authentication Key is not assigned yet (認証キーがまだ割り当てられていません)"
原因
- Azure portal のセルフホステッド IR ノードまたは論理セルフホステッド IR が削除された。
- クリーンアンインストールが実行された。
解決策

前述のどちらの原因も該当しない場合は、 %programdata%\Microsoft\Data Transfer\DataManagementGateway フォルダーに移動して、Configurations ファイルが削除されているかどうかを確認してください。削除されていた場合は、Windows ファイルサーバーからファイルを削除したユーザーの検出に関する Netwrix の記事の指示に従ってください。

セルフホステッド IR を使用して 2 つのオンプレミスデータストアをブリッジできない

現象

ソースと宛先の両方のデータストアに対してセルフホステッド IR を作成した後、その 2 つの IR を接続してコピーアクティビティを完了したいと考えています。データストアが別の仮想ネットワークに構成されている場合、またはデータストアによってゲートウェイのメカニズムが理解されない場合は、次のいずれかのエラーが発生します。
- "The driver of source cannot be found in destination IR (ソースのドライバーが宛先の IR で見つかりません。)"
- "The source cannot be accessed by the destination IR (宛先の IR がソースにアクセスできません)"
原因

セルフホステッド IR は、それぞれのデータストアにインストールする必要のあるクライアントエージェントとしてではなく、コピーアクティビティの中央ノードとして設計されています。

この場合は、同じ IR を使用してデータストアごとにリンクされたサービスを作成する必要があり、IR はネットワーク経由で両方のデータストアにアクセスできる必要があります。 IR がインストールされているのがソースデータストアか宛先データストアか、または第 3 のマシンかは問題ではありません。 2 つのリンクされたサービスが異なる IR を使用して作成されているが、同じコピーアクティビティで使用されている場合は、宛先 IR が使用されるため、両方のデータストアのドライバーを宛先 IR マシンにインストールする必要があります。
解決策

ソースと宛先両方のデータストアのドライバーを宛先 IR にインストールし、そこからソースデータストアにアクセスできることを確認します。

2 つのデータストア間のネットワークをトラフィックが通過できない場合 (それらが 2 つの仮想ネットワークに構成されている場合など)、IR がインストールされていても、1 回のアクティビティでコピーが完了しない可能性があります。 1 回のアクティビティでコピーを完了できない場合は、それぞれが 1 つの VNET 内にある 2 つの IR を使用して 2 つのコピーアクティビティを作成できます。
- 1 つの IR をデータストア 1 から Azure Blob Storage にコピーします。
- 別の IR を Azure Blob Storage からデータストア 2 にコピーします。
このソリューションでは、IR を使用して 2 つの切断されたデータストアを接続するブリッジを作成するための要件をシミュレートできます。

資格情報の同期の問題によって HA から資格情報が失われる

現象

データソース資格情報 "XXXXXXXXXX" が、ペイロードが含まれている現在の統合ランタイムノードから削除された場合、次のエラーメッセージが表示されます。

"When you delete the link service on Azure portal, or the task has the wrong payload, please create new link service with your credential again. (Azure portal のリンク　サービスを削除した場合、またはタスクのペイロードが正しくない場合は、資格情報を使用して新しいリンクサービスをもう一度作成してください。)"
原因

セルフホステッド IR は 2 つのノードを使用した HA モードで構築されていますが、それらのノードで資格情報が同期状態になっていません。これは、ディスパッチャーノードに格納されている資格情報が他のワーカーノードと同期されていないことを意味します。ディスパッチャーノードからワーカーノードへのフェールオーバーが発生したときに、前のディスパッチャーノードにしか資格情報が存在しない場合、資格情報にアクセスを試みた時点でそのタスクは失敗し、上記のエラーが発生します。
解決策

この問題を回避する唯一の方法は、2 つのノードで確実に資格情報を同期状態にすることです。同期されていない場合は、新しいディスパッチャーの資格情報を再入力する必要があります。

秘密キーがないため、証明書を選択できない

現象
- 証明書ストアに PFX ファイルをインポートしました。
- IR Configuration Manager UI で証明書を選択したときに、次のエラーメッセージが表示されました。
  
  "Failed to change intranet communication encryption mode. (イントラネット通信の暗号化モードを変更できませんでした。) It is likely that certificate ''<certificate name>' may not have a private key that is capable of key exchange or the process may not have access rights for the private key. (証明書 "'certificate name" に、キー交換が可能な秘密キーがないか、プロセスに秘密キーへのアクセス権がない可能性があります。) 詳細については、内部例外を参照してください。""
原因
- ユーザーアカウントの特権レベルが低いため、秘密キーにアクセスできません。
- 証明書はキー交換としてではなく、署名として生成されました。
解決策
- UI を操作するには、秘密キーにアクセスするための適切な特権を持つアカウントを使用します。
- 次のコマンドを実行して証明書をインポートします。
```
certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
```

セルフホステッド統合ランタイムノードの同期が取れない問題

現象

セルフホステッド統合ランタイムノードによってノード間での資格情報の同期が試みられますが、プロセスが停止し、しばらくすると次のエラーメッセージが表示されます。

"Integration Runtime (セルフホステッド) ノードは、ノード間で資格情報を同期しようとしています。これには数分かかることがあります。"

注意

このエラーが 10 分以上発生する場合は、ディスパッチャーノードとの接続を確認してください。
原因

理由は、ワーカーノードに秘密キーへのアクセス許可がないためです。これは、次のセルフホステッド統合ランタイムのログから確認できます。

[14]0460.3404::05/07/21-00:23:32.2107988 [System] A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

リンクサービスでサービスプリンシパル認証を使用している場合は、同期処理には問題は発生していません。しかし、認証タイプをアカウントキーに変更すると、同期の問題が発生しました。これは、セルフホステッド統合ランタイムサービスがサービスアカウント (NT SERVICE\DIAHostService) で実行され、秘密キーのアクセス許可に追加される必要があるためです。
解決策

この問題を解決するには、セルフホステッド統合ランタイムのサービスアカウント (NT SERVICE\DIAHostService) を秘密キーのアクセス許可に追加する必要があります。次の手順を適用できます。
1. Microsoft 管理コンソール (MMC) の実行コマンドを開きます。
2. MMC ウィンドウで、次の手順を適用します。
  1. [ファイル] を選択します。
  2. ドロップダウンメニューで [スナップインの追加と削除] を選択します。
  3. "利用できるスナップイン" ウィンドウで、 [証明書] を選択します。
  4. [追加] を選択します。
  5. ポップアップの "証明書スナップイン" ウィンドウで、 [コンピューターアカウント] を選択します。
  6. [次へ] を選択します。
  7. "コンピューターの選択" ウィンドウで [ローカルコンピューター: (このコンソールを実行しているコンピューター)] を選択します。
  8. [完了] を選択します。
  9. "スナップインの追加と削除" ウィンドウで [OK] を選択します。
3. MMC のウィンドウで、次の手順に進みます。
  1. 左のフォルダーの一覧から、[コンソールルート] -> [証明書 (ローカルコンピューター)] -> [個人] -> [証明書] を選択します。
  2. Microsoft Intune Beta MDM を右クリックします。
  3. ドロップダウンリストで [すべてのタスク] を選択します。
  4. [プライベートキーの管理] を選択します。
  5. "グループ名またはユーザー名" の下の [追加] を選択します。
  6. NT SERVICE\DIAHostService を選択して、この証明書へのフルコントロールアクセス許可を付与し、適用して保存します。
  7. [名前の確認] を選択し、 [OK] を選択します。
  8. "アクセス許可" ウィンドウで、 [適用] を選択してから [OK] を選択します。

Azure へのコピーアクティビティを実行するときに UserErrorJreNotFound エラーメッセージが表示される

現象

Java ベースのツールまたはプログラムを使用して Microsoft Azure にコンテンツをコピーしようとすると (たとえば、ORC または Parquet フォーマットファイルをコピーする場合)、次のようなエラーメッセージが表示されます。

ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment が見つかりません。 http://go.microsoft.com/fwlink/?LinkId=808605 にアクセスして、Integration Runtime (セルフホステッド) ノードコンピューターにダウンロードし、インストールします。 64 ビットの Integration Runtime には、64 ビットの JRE が必要であり、32 ビットの Integration Runtime には 32 ビットの JRE が必要であることに注意してください。,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=DLL 'jvm.dll を読み込めません': 指定されたモジュールが見つかりませんでした。 (HRESULT からの例外: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge
原因

この問題は、次のいずれかの理由で発生します。
- Integration Runtime サーバーに Java Runtime Environment (JRE) が正しくインストールされていません。
- Integration Runtime サーバーに、JRE に必要な依存関係がありません。
既定では、Integration Runtime でレジストリエントリを使用して JRE パスが解決されます。これらのエントリは、JRE のインストール時に自動的に設定されます。
解決策

慎重にこのセクションの手順に従います。レジストリを正しく変更しないと、重大な問題が発生する可能性があります。変更する前に、問題が発生した場合に復元するためにレジストリをバックアップします。

この問題を解決するには、次の手順に従って、JRE のインストールの状態を確認します。
1. Integration Runtime (Diahost.exe) と JRE が同じプラットフォームにインストールされていることを確認します。次の状況を確認します。
  - 64 ビットの ADF Integration Runtime の 64 ビット JRE は、C:\Program Files\Java\ のフォルダーにインストールする必要があります。
    
    注意
    
    このフォルダーは C:\Program Files (x86)\Java\ ではありません
  - Java Runtime (JRE) は、バージョン 11 以上で、Microsoft OpenJDK 11 や Eclipse Temurin 11 などの JRE プロバイダーから提供されます。 JAVA_HOME システム環境変数に (JRE フォルダーだけでなく) JDK フォルダーが設定されていることを確認します。システムの PATH 環境変数に bin フォルダーを追加することが必要な場合もあります。
2. レジストリで適切な設定を確認します。これを行うには、次の手順に従います。
  1. [ファイル名を指定して実行] メニューで「Regedit」と入力し、Enter キーを押します。
  2. ナビゲーションウィンドウで、次のサブキーを見つけます。
    
    [https://login.microsoftonline.com/consumers/](HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment)
    
    [詳細] ウィンドウに、JRE バージョン (たとえば 1.8) を示す最新バージョンのエントリが表示されています。
  3. ナビゲーションウィンドウで、JRE フォルダーの下にあるバージョン (たとえば、1.8) と完全に一致するサブキーを見つけます。詳細ウィンドウに、JavaHome エントリが表示されます。このエントリの値は、JRE インストールパスです。
3. 次のパスで bin\server フォルダーを見つけます。
  
  C:\Program Files\Java\jre1.8.0_74
4. このフォルダーに jvm.dll ファイルが含まれているかどうかを確認します。そうでない場合は、bin\client フォルダー内のファイルを確認します。
注意
- これらの構成のいずれかが上記の手順の説明どおりでない場合は、JRE Windows インストーラーを使用して問題を解決します。
- 上記の手順のすべての構成が正しい場合は、システムに VC++ ランタイムライブラリがない可能性があります。この問題を解決するには、VC++ 2010 再頒布可能パッケージをインストールします。

セルフホステッド IR の設定

統合ランタイムの登録エラー

現象

次のいずれかの理由で、セルフホステッド IR を別のアカウントで実行することが必要になる場合があります。
- サービスアカウントが会社のポリシーで許可されていない。
- なんらかの認証が必要である。
サービスペインでサービスアカウントを変更した後に、統合ランタイムが動作を停止し、次のエラーメッセージが表示される場合があります。

"The Integration Runtime (Self-hosted) node has encountered an error during registration. (登録中に Integration Runtime (セルフホステッド) ノードでエラーが発生しました。) Cannot connect to the Integration Runtime (Self-hosted) Host Service. (Integration Runtime (セルフホステッド) ホストサービスに接続できません。)"
原因

多くのリソースは、サービスアカウントにのみ付与されます。サービスアカウントを別のアカウントに変更しても、依存するすべてのリソースのアクセス許可は変更されません。
解決策

統合ランタイムのイベントログにアクセスしてエラーを確認してください。
- イベントログのエラーが "UnauthorizedAccessException" の場合は、次の手順を実行します。
  1. Windows サービスパネルで DIAHostService ログオンサービスアカウントを確認します。
  2. ログオンサービスアカウントに、 %programdata%\Microsoft\DataTransfer\DataManagementGateway フォルダーへの読み取りおよび書き込みアクセス許可があるかどうかを確認します。
    - サービスのログオンアカウントが変更されていなければ、既定で読み取りおよび書き込みアクセス許可が割り当てられているはずです。
    - サービスのログオンアカウントを変更した場合は、次の手順を実行して問題を軽減してください。
      
      a. 現在のセルフホステッド IR のクリーンアンインストールを実行します。
      b. セルフホステッド IR ビットをインストールします。
      c. 次の手順を実行して、サービスアカウントを変更します。
      
      i. セルフホステッド IR のインストールフォルダーに移動し、Microsoft Integration Runtime\4.0\Shared フォルダーに切り替えます。
      ii. 管理者特権を使用してコマンドプロンプトウィンドウを開きます。 <user> と <password> を実際のユーザー名とパスワードに置き換えてから、次のコマンドを実行します。
      dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
      iii. LocalSystem アカウントに変更したい場合は、そのアカウントの正しい形式を使用してください: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
      次の形式は使用 "しない" でください: dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
      iv. LocalSystem には管理者よりも高い特権があるため、必要な場合、[サービス] で直接それを変更することもできます。
      v. IR サービスのログオンアカウントには、ローカルまたはドメインのユーザーを使用できます。
      
      d. 統合ランタイムを登録します。
- エラーが、"Service 'Integration Runtime Service' (DIAHostService) failed to start. Verify that you have sufficient privileges to start system services (サービス 'Integration Runtime Service' (DIAHostService) を開始できませんでした。システムサービスを開始するのに十分な特権があることを確認してください。)" の場合、次の手順を実行します。
  1. Windows サービスパネルで DIAHostService ログオンサービスアカウントを確認します。
  2. そのログオンサービスアカウントに、Windows サービスを開始するための [サービスとしてログオン] アクセス許可があるかどうかを確認します。
詳細情報

前述の 2 つの解決パターンのいずれも当てはまらない場合は、次の Windows イベントログを収集してみてください。
- [アプリケーションとサービスログ] > [Integration Runtime]
- [Windows ログ] > [アプリケーション]

セルフホステッド IR を登録するための [登録] ボタンが見つからない

現象

セルフホステッド IR を登録するときに、Configuration Manager ペインに [登録] ボタンが表示されません。
原因

Integration Runtime 3.0 のリリース時点で、よりクリーンでセキュアな環境を実現するために、既存の統合ランタイムノードの [登録] ボタンが削除されました。オンラインかどうかにかかわらず、ノードが統合ランタイムに登録されている場合、それを別の統合ランタイムに再登録するには、前のノードをアンインストールしてから、ノードをインストールして登録する必要があります。
解決策
1. コントロールパネルで、既存の統合ランタイムをアンインストールします。
  
  重要
  
  次のプロセスで、 [はい] を選択します。アンインストールプロセス中はデータを保持しないでください。
2. 統合ランタイムインストーラーの MSI ファイルがない場合は、ダウンロードセンターにアクセスして、最新の統合ランタイムをダウンロードしてください。
3. MSI ファイルをインストールし、統合ランタイムを登録します。

localhost が原因でセルフホステッド IR を登録できない

現象

get_LoopbackIpOrName を使用しているときは、セルフホステッド IR を新しいマシンに登録できません。

デバッグ: 実行時エラーが発生しました。 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' のタイプ初期化子が例外をスローしました。データベースの参照中に、修復できないエラーが発生しました。

例外の詳細: System.TypeInitializationException: 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' のタイプ初期化子が例外をスローしました。 ---> System.Net.Sockets.SocketException: データベースの参照中に、System.Net.Dns.GetAddrInfo(String name) で修復できないエラーが発生しました。
原因

この問題は、通常、localhost の解決中に発生します。
解決策

localhost の IP アドレス127.0.0.1 を使用してファイルをホストし、問題を解決します。

セルフホステッドの設定に失敗した

現象

既存の IR のアンインストール、新しい IR のインストール、または既存の IR から新しい IR へのアップグレードができません。
原因

統合ランタイムのインストールは、Windows インストーラーサービスに依存します。インストールの問題は、次の理由で発生する可能性があります。
- 使用可能なディスク領域が不足している。
- 必要なアクセス許可がない。
- Windows NT サービスがロックされている。
- CPU 使用率が高すぎる。
- ネットワークの速度が遅い場所で MSI ファイルがホストされている。
- 一部のシステムファイルまたはレジストリに意図しない変更があった。

IR サービスアカウントで証明書のアクセス権を取得できなかった。

現象

Microsoft Integration Runtime Configuration Manager を使用してセルフホステッド IR をインストールすると、信頼できる証明機関 (CA) の証明書が生成されます。この証明書を適用して 2 つのノード間の通信を暗号化することができず、次のエラーメッセージが表示されています。

"イントラネット通信暗号化モードを変更できませんでした: 証明書 '<certificate name>' へのアクセス権を Integration Runtime サービスアカウントに付与できませんでした。 Error code 103 (エラーコード 103)"
原因

この証明書にはキー格納プロバイダー (KSP) が使用されていますが、これはまだサポートされていません。現在のところ、セルフホステッド IR では暗号化サービスプロバイダー (CSP) のストレージのみがサポートされています。
解決策

この場合、CSP 証明書を使用することをお勧めします。

解決策 1

証明書をインポートするには、次のコマンドを実行します。

Certutil.exe -CSP "CSP or KSP" -ImportPFX FILENAME.pfx

解決策 2

証明書を変換するには、次のコマンドを実行します。

openssl pkcs12 -in .\xxxx.pfx -out .\xxxx_new.pem -password pass: <EnterPassword> openssl pkcs12 -export -in .\xxxx_new.pem -out xxxx_new.pfx

変換前と変換後:

セルフホステッド統合ランタイムバージョン 5.x

セルフホステッド統合ランタイムバージョン 5.x にアップグレードするためには、 .NET Framework Runtime 4.7.2 以降が必要です。ダウンロードページには、最新の 4.x バージョンと 2 つの最新 5.x バージョン用のダウンロードリンクがあります。

Azure Data Factory v2 および Azure Synapse のお客様:

自動更新がオンになっていて、.NET Framework ランタイムを 4.7.2 以降に既にアップグレードしている場合、セルフホステッド統合ランタイムは最新の 5.x バージョンに自動的にアップグレードされます。
自動更新がオンになっていて、.NET Framework ランタイムを 4.7.2 以降にまだアップグレードしていない場合、セルフホステッド統合ランタイムは最新の 5.x バージョンに自動的にアップグレードされません。セルフホステッド統合ランタイムは、現在の 4.x バージョンのままになります。 .NET Framework ランタイムのアップグレードに関する警告が、ポータルとセルフホストテッド統合ランタイムのクライアントに表示されます。
自動更新がオフになっていて、.NET Framework ランタイムを 4.7.2 以降に既にアップグレードしている場合は、最新の 5.x を手動でダウンロードして、お使いのマシンにインストールできます。
自動更新がオフになっていて、.NET Framework ランタイムを 4.7.2 以降にアップグレードしていない場合: セルフホステッド統合ランタイム 5.x を手動でインストールしてキーを登録しようとすると、最初に .NET Framework ランタイムのバージョンをアップグレードするように求められます。

セルフホステッド IR の接続の問題

セルフホステッド統合ランタイムがクラウドサービスに接続できない

現象

セルフホステッド統合ランタイムを登録しようとすると、Configuration Manager によって次のエラーメッセージが表示されます。

"The Integration Runtime (Self-hosted) node has encountered an error during registration. (Integration Runtime (セルフホステッド) ノードで登録中にエラーが発生しました。)"
原因

セルフホステッド IR がサービスバックエンドに接続できません。この問題は、通常、ファイアウォールのネットワーク設定が原因で発生します。
解決策
1. 統合ランタイムサービスが実行されているかどうかを確認します。そうであれば、手順 2 に進みます。
2. セルフホステッド IR にプロキシが構成されていない (既定の設定) 場合は、セルフホステッド統合ランタイムがインストールされているマシン上で次の PowerShell コマンドを実行します。
```
(New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")
```
  注意
  
  サービスの URL は、データファクトリまたは Synapse ワークスペースインスタンスの位置によって変わる可能性があります。サービスの URL を見つけるには、データファクトリまたは Azure Synapse インスタンスの [管理] ページを使用して統合ランタイムを検索し、セルフホステッド IR をクリックして編集してください。そこで [ノード] タブを選び、 [サービス URL の表示] をクリックします。
  
  想定される応答を次に示します。
3. 想定していた応答が得られない場合は、適宜、次のいずれかの方法を使用します。
  - "リモート名を解決できませんでした" というメッセージを受け取る場合は、ドメインネームシステム (DNS) の問題が発生しています。この問題を解決するには、ネットワークチームに問い合わせてください。
  - 「ssl/tls 証明書は信頼されていません」というメッセージを受け取る場合は、証明書 (https://wu2.frontend.clouddatahub.net/) がマシン上で信頼されているかどうかを確認し、次に証明書マネージャーを使用して公開証明書をインストールします。この操作により、問題が軽減されます。
  - [Windows]>[イベントビューアー (ログ)]>[アプリケーションとサービスログ]>[統合ランタイム] に移動し、DNS、ファイアウォール規則、または会社のネットワーク設定が原因でエラーが発生していないかを確認します。そのようなエラーが見つかった場合は、接続を強制的に閉じてください。どの会社にも独自のカスタマイズされたネットワーク設定があるため、これらの問題をトラブルシューティングするには、自社のネットワークチームにお問い合わせください。
4. セルフホステッド統合ランタイムで "プロキシ" が構成されている場合は、プロキシサーバーからサービスエンドポイントにアクセスできることを確認します。サンプルコマンドについては、「PowerShell, web requests, and proxies」(PowerShell、Web 要求、プロキシ) を参照してください。
```
$user = $env:username
$webproxy = (get-itemproperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet
Settings').ProxyServer
$pwd = Read-Host "Password?" -assecurestring
$proxy = new-object System.Net.WebProxy
$proxy.Address = $webproxy
$account = new-object System.Net.NetworkCredential($user,[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($pwd)), "")
$proxy.credentials = $account
$url = "https://wu2.frontend.clouddatahub.net/"
$wc = new-object system.net.WebClient
$wc.proxy = $proxy
$webpage = $wc.DownloadData($url)
$string = [System.Text.Encoding]::ASCII.GetString($webpage)
$string
```
想定される応答を次に示します。
注意

プロキシに関する考慮事項：
- プロキシサーバーを [信頼できる宛先のリスト] に含める必要があるかどうかを確認します。その場合は、必ずこのようなドメインを [信頼できる宛先のリスト] に含めます。
- SSL/TLS 証明書 wu2.frontend.clouddatahub.net/ がプロキシサーバー上で信頼されているかどうかを確認します。
- プロキシで Active Directory 認証を使用している場合は、サービスアカウントを、"Integration Runtime サービス" としてプロキシにアクセスできるユーザーアカウントに変更してください。

エラーメッセージ:セルフホステッド統合ランタイムノードまたは論理セルフホステッド IR は非アクティブまたは "実行中 (制限あり)" 状態です。

原因

次のスクリーンショットに示すように、セルフホステッド統合ランタイムノードは [非アクティブ] 状態になる場合があります。

この動作は、ノードが相互に通信できない場合に発生します。

解決策

ノードでホストされている仮想マシン (VM) にログインします。 [アプリケーションとサービスログ]>[統合ランタイム] で、イベントビューアーを開き、エラーログをフィルター処理します。

エラーログに次のエラーが含まれているかどうかを確認します。

System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://xxxxxxx.bwld.com:8060/ExternalService.svc/WorkerManager. The connection attempt lasted for a time span of 00:00:00.9940994. TCP error code 10061: No connection could be made because the target machine actively refused it 10.2.4.10:8060. 
System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it. 
10.2.4.10:8060
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)

このエラーが表示された場合は、コマンドプロンプトウィンドウで次のコマンドを実行します。
```
telnet 10.2.4.10 8060
```
次のスクリーンショットに示されている "Could not open connection to the host (ホストへの接続を開けませんでした)" というコマンドラインエラーが表示された場合は、IT 部門に連絡して、この問題を解決するための支援を要請してください。 telnet を正常に実行できた後も、統合ランタイムノードの状態に問題がある場合は、Microsoft サポートにお問い合わせください。

エラーログに次のエントリが含まれているかどうかを確認します。

Error log: Cannot connect to worker manager: net.tcp://xxxxxx:8060/ExternalService.svc/ No DNS entries exist for host azranlcir01r1. No such host is known Exception detail: System.ServiceModel.EndpointNotFoundException: No DNS entries exist for host xxxxx. ---> System.Net.Sockets.SocketException: No such host is known at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostEntry(String hostNameOrAddress) at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri) --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri)

この問題を解決するには、次の方法のいずれかまたは両方を試してください。
- すべてのノードを同じドメインに配置する。
- ホストされているすべての VM のホストファイルで、IP とホストのマッピングを追加する。

セルフホステッド IR と、データファクトリまたは Azure Synapse インスタンスとの間、あるいは、セルフホステッド IR と、データソースまたはシンクとの間における接続に関する問題

ネットワーク接続の問題のトラブルシューティングを行うには、ネットワークトレースの収集方法を確認して、その使用方法を理解し、Microsoft ネットワークモニター (Netmon) トレースを分析してから、実際のケースでセルフホステッド IR から Netmon ツールを適用する必要があります。

現象

次のスクリーンショットに示すような、セルフホステッド IR とデータファクトリまたは Azure Synapse インスタンスとの間、あるいは、セルフホステッド IR とデータソースまたはシンクとの間における接続問題に対するトラブルシューティングが必要になる場合があります。

どちらのインスタンスでも、次のエラーが発生する可能性があります。
- "Copy failed with error:Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Cannot connect to SQL Server:'IP address' (エラーによってコピーが失敗しました: Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException、Message= SQL Server に接続できません: 'IP address')"
- "One or more errors occurred. (1 つ以上のエラーが発生しました。) この要求の送信中にエラーが発生しました。基になる接続が閉じられました。An unexpected error occurred on a receive. (受信時に予期しないエラーが発生しました。) データをトランスポート接続から読み取れません: リモートホストによって、既存の接続は強制的に切断されました。 An existing connection was forcibly closed by the remote host Activity ID. (既存の接続はリモートホストのアクティビティ ID によって強制的に切断されました。)"
解決策

上記のエラーが発生した場合は、このセクションの手順に従ってトラブルシューティングを行います。
- 分析のために Netmon トレースを収集します。
  1. サーバーからクライアント側へのリセットを確認するためのフィルターを設定できます。次のスクリーンショットの例では、サーバー側が Data Factory サーバーであることを確認できます。
  2. リセットパッケージを取得したら、伝送制御プロトコル (TCP) を追跡してメッセージ交換を見つけることができます。
  3. フィルターを削除して、クライアントと Data Factory サーバーの間の会話を取得します。
- 収集した Netmon トレースの分析では、Time to Live (TTL) の合計が 64 であることが示されています。 IP Time to Live (TTL) とホップ制限の基本に関する記事 (次の一覧に抜粋) に記載されている値によると、パッケージをリセットし、切断を発生させたのは Linux システムであることがわかります。
  
  既定の TTL とホップの制限値は、こちらの一覧に示すように、オペレーティングシステムによって異なります。
  - Linux カーネル 2.4 (2001 年ごろ):TCP、ユーザーデータグラムプロトコル (UDP)、およびインターネット制御メッセージプロトコル (ICMP) の場合は 255
  - Linux カーネル 4.10 (2015):TCP、UDP、および ICMP の場合は 64
  - Windows XP (2001):TCP、UDP、および ICMP の場合は 128
  - Windows 10 (2015):TCP、UDP、および ICMP の場合は 128
  - Windows Server 2008:TCP、UDP、および ICMP の場合は 128
  - Windows Server 2019 (2018):TCP、UDP、および ICMP の場合は 128
  - MacOS (2001):TCP、UDP、および ICMP の場合は 64
  前の例では、TTL は 64 ではなく 61 と表示されています。これは、ネットワークパッケージが宛先に到達するとき、ルーターやネットワークデバイスなどのさまざまなホップを経由する必要があるためです。最終的な TTL を算出するために、ルーターやネットワークデバイスの数が差し引かれます。
  
  この場合は、リセットが Linux システムから TTL 64 で送信された可能性があることがわかります。
- リセットデバイスの発信元を確認するには、セルフホステッド IR から 4 番目のホップを確認します。
  
  Linux システム A からの TTL 64 のネットワークパッケージ -> B TTL 64-1 = 63 -> C TTL 63-1 = 62 -> TTL 62-1 = 61 セルフホステッド IR
- 理想的な状況では、TTL ホップ数は 128 になります。これは、Windows オペレーティングシステムによってデータファクトリインスタンスが実行されていることを意味します。次の例に示すように、"128-107 = 21 ホップ" です。これは、TCP 3 ハンドシェイク中に、データファクトリインスタンスからセルフホステッド IR にパッケージの 21 ホップが送信されたことを意味します。
  
  このため、セルフホステッド IR からの 4 番目のホップを確認するには、ネットワークチームと協力する必要があります。それがファイアウォールである場合は、Linux システムと同様に、TCP 3 ハンドシェイク後にそのデバイスによってパッケージがリセットされた理由をログで確認します。
  
  調査する場所がわからない場合は、問題発生時のセルフホステッド IR とファイアウォール両方からの Netmon トレースを取得してみてください。この方法は、どのデバイスによってパッケージがリセットされて切断が引き起こされた可能性があるかを判断するのに役立ちます。この場合も、ネットワークチームと協力して作業を進める必要があります。

Netmon トレースを分析する

注意

次の手順は、Netmon トレースに適用されます。 Netmon トレースは現在サポート対象外のため、Wireshark をこの目的に使用できます。

収集した Netmon トレースを使用して telnet 8.8.8.8 888 を実行しようとすると、次のスクリーンショットに示すトレースが表示されます。

Netmon トレースの説明を示すスクリーンショット。

前の図は、ポート 888 で 8.8.8.8 サーバー側に TCP 接続を確立できなかったことを示しています。そのため、そこに 2 つの SynReTransmit 追加パッケージがあるのを確認できます。ソース SELF-HOST2 は、最初のパッケージを使用して 8.8.8.8 に接続できなかったため、接続を試行し続けます。

ヒント

この接続を確立するには、次の解決策を試してください。

[フィルターの読み込み]>[標準フィルター]>[アドレス]>[IPv4 アドレス] を選択します。
フィルターを適用するには、IPv4.Address == 8.8.8.8 を入力し、 [適用] を選択します。これにより、ローカルマシンから宛先 8.8.8.8 への通信を確認できます。

フィルターアドレスを示すスクリーンショット。

その他のフィルターアドレスを示すスクリーンショット。

次の例では成功したシナリオを示します。

問題なく telnet 8.8.8.8 53 を実行できる場合は、TCP 3 ハンドシェイクが正常に行われ、セッションは TCP 4 ハンドシェイクで終了します。
前述の TCP 3 ハンドシェイクでは、次のワークフローが生成されます。
セッションを完了するための TCP 4 ハンドシェイクは、次のワークフローで示されています。

この通知が自分に影響があるものかどうかを判断する

この通知は、次のシナリオに適用されます。

シナリオ 1:企業のファイアウォール内でオンプレミスで実行されているセルフホステッド統合ランタイムからの送信方向の通信

自分に影響があるかどうかを判断する方法:

ファイアウォール規則を、ファイアウォール構成と IP アドレスの許可リストのセットアップを行うに関するページに記されるアプローチを使う完全修飾ドメインネーム (FQDNs) に基づいて定義している場合は、影響を受けません。
企業のファイアウォールで送信 IP アドレスの許可リストを明示的に有効にしている場合は、影響を受けます。

影響を受ける場合の対処方法: 2020 年 11 月 8 日までにネットワーク構成を更新して最新のデータファクトリの IP アドレスを使用するように、ネットワークインフラストラクチャチームに通知します。最新の IP アドレスをダウンロードするには、「ダウンロード可能な JSON ファイルを使用してサービスタグを検出する」に移動してください。

シナリオ 2: カスタマーマネージド Azure 仮想ネットワーク内の Azure VM で実行されているセルフホステッド統合ランタイムからの送信方向の通信

自分に影響があるかどうかを判断する方法:

セルフホステッド統合ランタイムが含まれているプライベートネットワークに送信ネットワークセキュリティグループ (NSG) 規則があるかどうかを確認します。送信制限がない場合は、影響を受けません。
アウトバウンド規則の制限がある場合は、サービスタグを使用しているかどうかを確認します。サービスタグを使用している場合は、影響を受けません。新しい IP 範囲は既存のサービスタグの下にあるため、変更や追加を行う必要はありません。
Azure 仮想ネットワークの NSG 規則設定で送信 IP アドレスの許可リストを明示的に有効にしている場合は、影響を 受けます。

影響を受ける場合の対処方法: 2020 年 11 月 8 日までに Azure 仮想ネットワーク構成の NSG 規則を更新して最新のデータファクトリの IP アドレスを使用するように、ネットワークインフラストラクチャチームに通知します。最新の IP アドレスをダウンロードするには、「ダウンロード可能な JSON ファイルを使用してサービスタグを検出する」に移動してください。

シナリオ 3: カスタマーマネージド Azure 仮想ネットワークでの SSIS Integration Runtime からの送信方向の通信

自分に影響があるかどうかを判断する方法:

SQL Server Integration Services (SSIS) Integration Runtime が含まれているプライベートネットワークに送信 NSG 規則があるかどうかを確認します。送信制限がない場合は、影響を受けません。
アウトバウンド規則の制限がある場合は、サービスタグを使用しているかどうかを確認します。サービスタグを使用している場合は、影響を受けません。新しい IP 範囲は既存のサービスタグの下にあるため、変更や追加を行う必要はありません。
Azure 仮想ネットワークの NSG 規則設定で送信 IP アドレスの許可リストを明示的に有効にしている場合は、影響を 受けます。

影響を受ける場合の対処方法: 2020 年 11 月 8 日までに Azure 仮想ネットワーク構成の NSG 規則を更新して最新のデータファクトリの IP アドレスを使用するように、ネットワークインフラストラクチャチームに通知します。最新の IP アドレスをダウンロードするには、「ダウンロード可能な JSON ファイルを使用してサービスタグを検出する」に移動してください。

SSL/TLS のセキュリティで保護されているチャネルに対して信頼関係を確立できなかった

現象

セルフホステッド IR が Azure Data Factory または Azure Synapse サービスに接続できませんでした。

Windows>イベントビューアー (ログ)>アプリケーションとサービスログ>統合ランタイムに移動した後に、セルフホステッド IR イベントログをチェックすると、次のエラーメッセージが表示されます。

"基になる接続が閉じられました: SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした。検証プロシージャによると、リモート証明書は無効です。"

サービスのサーバー証明書を確認する最も簡単な方法は、ブラウザーでサービスの URL を開くことです。たとえば、セルフホステッド IR がインストールされているマシンでサーバー証明書の確認リンク (https://eu.frontend.clouddatahub.net/) を開き、サーバー証明書情報を表示します。

$Azure Data Factory サービスの [check server certificate]$サーバー証明書の確認$ ペインのスクリーンショット。$
原因

この問題の原因は 2 つ考えられます。
- 理由 1: サービスのサーバー証明書のルート CA が、セルフホステッド IR がインストールされているマシンで信頼されていません。
- 理由 2: お使いの環境でプロキシが使われており、サービスのサーバー証明書がプロキシによって置き換えられて、置き換えられたサーバー証明書が、セルフホステッド IR がインストールされているマシンに信頼されていません。
解決策
- 理由 1 の場合: サービスのサーバー証明書とその証明書チェーンが、セルフホステッド IR がインストールされているマシンに信頼されていることをご確認ください。
- 理由 2 の場合: セルフホステッド IR マシンで、置き換えられたルート CA を信頼してください。または、サービスのサーバー証明書を置き換えないようにプロキシを構成してください。
Windows での証明書の信頼の詳細については、信頼されたルート証明書のインストールに関する記事を参照してください。
追加情報
DigiCert から署名されている新しい SSL 証明書がロールアウトされました。 DigiCert Global Root G2 が、信頼されたルート CA にあるかどうかを確認してください。

信頼されたルート CA に含まれていない場合は、こちらからダウンロードしてください。

トラブルシューティングの詳細について、次のリソースを参照してください。

次の方法で共有

セルフホステッド統合ランタイムのトラブルシューティング

セルフホステッド IR を収集する