オンプレミス データ ゲートウェイに関する FAQ

いいえ。通常、サービスはゲートウェイなしでクラウド データ ソースに接続できます。 ただし、データソースがファイアウォールの背後にある場合、VPN が必要な場合、または仮想ネットワーク上にある場合は、データ ゲートウェイが必要になることがあります。

OAuth2 資格情報を使用する際に、アクセス トークンの有効期限が切れた場合 (更新の開始から 1 時間後)、現在、ゲートウェイはトークンの自動更新に対応していません。 実行時間の長い更新に対するこの制限は、VNET ゲートウェイとオンプレミス データ ゲートウェイに存在します。

インストールに関する記事の要件セクションを確認してください。

いいえ。ゲートウェイは、指定された接続情報を使用してデータ ソースに接続します。 この意味では、ゲートウェイをクライアント アプリケーションと考えてください。 ゲートウェイは、指定されたサーバーに接続するだけで済みます。

現在 Microsoft では、オンプレミス データ ゲートウェイの最新の 6 リリースのみを積極的にサポートしています。 データ ゲートウェイの新しい更新プログラムは毎月リリースしています。

ゲートウェイのインストールと登録に関するライセンス制限はありません。 ただし、クラウド サービスには、そのサービス内でのゲートウェイの使用にかかわるライセンス制限がある場合があります。 Power BI の場合、プレミアム ライセンスが必要です。 すべてのファブリック ライセンスでゲートウェイがサポートされます。 他のサービスにも独自のライセンス制限がある場合があります。

ネットワーク接続のスループットが良好なことを確認してください。 それぞれの環境は異なり、スループットは送信されるデータ量によって異なります。 オンプレミスのデータ ソースと Azure データセンターの間のスループットの最小レベルを確保するには、Azure ExpressRoute を使用します。 スループットの測定には、Azure 速度テスト アプリ を使用できます。

データ ソースのために入力した資格情報は暗号化され、ゲートウェイ クラウド サービスに格納されます。 資格情報は、オンプレミスのゲートウェイで暗号化が解除されます。 Power BI での資格情報の暗号化について詳しくは、「Power BI のセキュリティに関するホワイト ペーパー」を参照してください。

ローカル コンピューターのサービス アプリでは、このサービスは "オンプレミスの データ ゲートウェイ サービス" と呼ばれます。 タスク マネージャーの [サービス] タブでは、サービス名は "PBIEgwService" になります。 既定では、Windows サービスはサービス SID (SSID) として "NT SERVICE\PBIEgwService" を使用します。

いいえ。Windows サービスには有効な Windows アカウントが必要です。

いいえ。ゲートウェイは、Azure Relay への送信接続を使用します。

「Azure 接続の送信を有効にする」を参照してください。

送信 IP トラフィックをブロックする場合は、Azure データセンター IP リストのブロックを解除することが必要になる場合があります。 ゲートウェイは、IP アドレスと完全修飾ドメイン名を使って Azure Relay と通信します。 Azure データ センター IP リストは毎週更新されます。 詳細については、「Azure 接続の送信を有効にする」を参照してください。

ネットワーク待ち時間を避けるために、ゲートウェイをデータ ソースのできるだけ近くにインストールしてください。 実際のデータ ソース上にゲートウェイをインストールできる場合、その近接性によって待ち時間は最小限に抑えられます。

また、Azure データセンターへの近接性も考慮してください。 たとえば、サービスが米国西部のデータセンターを使用していて、SQL Server が Azure 仮想マシンでホストされている場合、米国西部リージョンに Azure VM を配置することも必要になる場合があります。 この構成により、待ち時間が最小限に抑えられ、Azure VM でのエグレス料金を回避できます。

結果は Azure Relay 経由で送信されます。 詳細については、「オンプレミス データ ゲートウェイのアーキテクチャ」を参照してください。

ゲートウェイはデータ ソースに接続する必要があります。 したがって、境界ネットワーク内でデータ ソースに接続できない場合、ゲートウェイはアクセスできないおそれがあります。

たとえば、SQL Server コンピューターが境界ネットワーク内にないと想定します。 また、境界ネットワークからそのコンピューターに接続できないとします。 ゲートウェイを境界ネットワーク内に配置した場合、そのゲートウェイは SQL Server コンピューターにアクセスできません。

はい。

この優先順位は、Windows または関連するデータ ソースのドライバーによって異なります。 この動作は、Windows と各種ドライバの両方で構成可能ですが、ゲートウェイの制御下にはありません。

いいえ。クロステナントの Microsoft Entra ID アクセスはサポートされていません。 テナントの Power BI セマンティック モデルは、Microsoft Entra ID アカウントを使って別のテナントのデータソースには接続できません。 この制限は、データ ソースがオンプレミスのデータ ゲートウェイを使用しているかどうかに関わらず適用されます。 この制限を解消するには、OAuth 以外の認証タイプを使用してください。

はい。詳しくは、「Azure Relay との HTTPS 通信を強制する」を参照してください。 この機能をオンにしても、パフォーマンスへの影響はほとんどありません。

いいえ。それらは別の製品です。 現在はセルフホステッド統合ランタイムと呼ばれているデータ管理ゲートウェイの詳細については、「セルフホステッド統合ランタイムを作成して構成する」を参照してください。

はい。PowerShell を使用して、他の所有者を同じゲートウェイに追加する必要があります。 これらのユーザーは、Azure portal でゲートウェイを作成できます。 ただし、同じテナントを使用してポータルとゲートウェイに接続する必要があります。

不正解です。 オンプレミスのデータ ソースに接続する場合も、ゲートウェイが必要です。

詳細情報: データが格納されているリージョンにデータを保持する

単一障害点を回避するため、高可用性のためにオンプレミス データ ゲートウェイをクラスターとして設定できます。 既定では、Power Apps や Power BI のようなクラウド サービスはプライマリ ゲートウェイを使用し、プライマリが使用できない場合はセカンダリ ゲートウェイにフォール バックします。

ゲートウェイをインストールするときに、回復キーを指定してください。 そのキーを使って、ゲートウェイの復元や移行を実行できます。

キーを使うと、クラスターに新しいゲートウェイを追加したり、ゲートウェイの移行、回復、または引き継ぎを行ったりできます。

トラブルシューティング

詳細については、「オンプレミス データ ゲートウェイのトラブルシューティング」を参照してください。

[トラブルシューティング ツール] に移動します。

追加のログ記録をオンにすることでクエリ トレースを有効にできます。 ログには、送信されたクエリが含まれます。 トラブルシューティングが完了したら、必ずクエリ トレースをオフにしてください。 クエリ トレースが有効になっていると、ログの容量が大きくなります。

クエリ トレース用のデータ ソースのツールを検討することもできます。 たとえば、SQL Server と SQL Server Analysis Services がデータ ソースである場合、SQL Server 拡張イベントまたは SQL Server プロファイラーを使用してクエリをトレースできます。

1 ユーザーあたり 1000 個のデータ ソースに制限されます。

データ ソースの最大数に達した場合は、1 ユーザーあたりのデータ ソースの数がこの制限を超えていないことを確認してください。 関連する問題を解決するには、管理センターから手動でデータ ソースを削除するか、次の Gateway PowerShell スクリプトを使用して、制限を超えるデータ ソースを検索して一括削除することができます。

## https://learn.microsoft.com/powershell/module/datagateway/?view=datagateway-ps
## PowerShell version of '7.0.0' to run
## required module "DataGateway" Install-Module -Name DataGateway and sign in the same user who exceeded the 1000 limit
Connect-DataGatewayServiceAccount

## get the gateway information per the sign in person
$gatewayClusters = Get-DataGatewayCluster | where-Object {$_.Type -EQ 'Personal'}; 
foreach ($gw in $gatewayClusters)
{
  $datasources = Get-DataGatewayClusterDatasource -GatewayClusterId $gw.Id;
  foreach ($datasource in $datasources)
  {
    $datasource
    "gateway cluster id={0}, Personal Gateway={1}, datasource id={2}, datasourceType={3}, datasource connection details={4}" -f $gw.Id, $datasource.OnPremGatewayRequired, $datasource.Id, $datasource.DatasourceType, $datasource.ConnectionDetails 
   
    ## conditional logic to determine if name matches set
    ## Remove-DataGatewayClusterDatasource -GatewayClusterId $gw.Id -GatewayClusterDatasourceId $datasource.Id
  }
}

この制限に達しないようにするにはどうすればよいですか? 多くの顧客を持つ ISV またはその他の Power BI Embedded アプリ所有者の場合は、Power BI Embedded のマルチテナント アプリに対してサービス プリンシパル プロファイルを使用してください。 ISV でない場合は、CSV または Excel ファイルごとに新しいデータ ソースを作成するため、この制限に達する可能性があります。 これを解決するには、Power BI Desktop の [ファイルのアップロード ボックス] を使用して複数の Excel ファイルを選択し、複数のデータ ソース接続を作成することができます。 このシナリオでは、単一のデータ ソースのみが選択されるようにするため、代わりにこれらの Excel ファイルを含むフォルダーを選択することをお勧めします。

はい。ゲートウェイを管理するユーザーは、管理者のタブに移動し、管理者を追加できます。 セキュリティ グループを管理者にすることもできます。

いいえ。ゲートウェイ管理者は、サービス内からゲートウェイを管理します。

新しいサーバーで移行プロセスが失敗した場合でも、オンプレミス データ ゲートウェイは古いサーバー内に存在しており、サーバーがオフラインであるかゲートウェイ ソフトウェアがアンインストールされていない限り、そのゲートウェイを実行できます。 ただし、古いサーバーでゲートウェイを復元するために、ゲートウェイの回復キーを使用するように求められる場合があります。

移行にはゲートウェイのインストールと新しいサーバーでの復元と構成という 2 つのタスクしか含まれないため、移行は通常 10 分から 15 分で完了します。

はい。 ただし、この間に障害が発生する可能性は十分にあるため、このような移行はダウンタイム期間中に実行する必要があります。 詳細情報: 「移行のダウンタイムを最小限に抑える」

• 1 時間を超える OAuth の更新が、"接続の資格情報が無効" エラーまたはタイムアウトでキャンセルされた場合、資格情報の有効期限が切れている可能性があります。

次のステップ

• オンプレミス データ ゲートウェイのトラブルシューティング