Häufig gestellte Fragen zum virtuellen Netzwerkdatengateway

Wir unterstützen GCC L4 (Texas und Virginia) und L5 (DoD East). Dieses Feature wird derzeit in GCC L2 nicht unterstützt.

Kunden sollten die RP-Zuordnung auf Abonnementebene erst nach dem Löschen eines Gateways entfernen, da wir weiterhin Ressourcen bereinigen müssen.

Wenn Sie OAuth2-Anmeldeinformationen in Dataflows Gen1 verwenden, unterstützt das Gateway das Automatische Aktualisieren von Token nicht, wenn Zugriffstoken ablaufen. Token laufen in der Regel 1 Stunde nach dem Start der Aktualisierung ab, können jedoch je nach Datenquelle und Mandantenrichtlinien in weniger als 1 Stunde ablaufen. Dataflows Gen2, Semantic models, Data pipelines are able to refresh tokens mid-stream and should not be impacted due this.

Wir unterstützen Clouds mit Air Gap in den USA US Nat East/West und US Sec East/West.

Verwenden Sie private Links, um diese Konnektivität zu sichern. Weitere Informationen: Dokumentation zu privaten Power BI-Links

Das virtuelle Netzwerkdatengateway befindet sich physisch in derselben Region wie Ihr virtuelles Azure-Netzwerk. Die Metadaten (Name, Details, Datenquellen, verschlüsselte Anmeldeinformationen usw.) für alle Ihre virtuellen Netzwerkdatengateways werden jedoch in der Standardregion Ihres Mandanten gespeichert. Sie können alle virtuellen Netzwerkdatengateways verwalten, wenn Sie die Basisregion Ihres Mandanten in Power Platform Admin Center auswählen.

Ja. Sie können ein virtuelles Netzwerkdatengateway verwenden, und Ihre Richtlinien für bedingten Zugriff gelten weiterhin.

Eine vollständige Liste der unterstützten Data Services:

• für Power BI unter Unterstützte Azure-Datendienste verfügbar
• für Power Platform-Dataflows unter Unterstützte Datenquellen verfügbar

Virtuelle Netzwerkdatengateways sind ein Premium-Feature und sind nur in Fabric (jeder SKU) und Power BI Premium-Kapazität (A4-SKU oder höher oder P-SKU) verfügbar.

Ja

Überprüfen Sie die Azure Virtual Network-Dokumentation auf Einschränkungen (z. B. in Bezug auf Regionen) für VNets, Endpunkte und zugehörige Azure-Ressourcen.

Überprüfen Sie in der entsprechenden Produktdokumentation zum Azure Data Service, ob private Endpunkte unterstützt werden und wie diese aktiviert werden.

Wenn Fehler wie Authorization failed for Public API route oder DM_GWPipeline_Client_OAuthTokenLoginFailedError angezeigt werden, wenn Sie versuchen, eine Verbindung für das virtuelle Netzwerkdatengateway mit OAuth-Authentifizierung für eine Azure-Ressource mit einer Firewall zu erstellen, die den öffentlichen Internetzugriff blockiert und mit privaten Endpunkten konfiguriert ist, bedeutet dies, dass Sie explizit einen Dienstendpunkt für die private Authentifizierung erstellen müssen, indem Sie den Microsoft Entra ID-Dienst aufrufen. Um diese Situation zu umgehen, wechseln Sie zum Subnetz des virtuellen Netzwerks, das für das virtuelle Netzwerkdatengateway verwendet wird, und aktivieren Sie den Dienstendpunkt „Microsoft.AzureActiveDirectory“, wie hier dargestellt:

Ja, bei diesem Feature besteht keine Abhängigkeit von der Power BI-Basisregion. Wenn dieses Feature in der Region aktiviert ist, in der sich das virtuelle Netzwerk befindet, können Sie ein neues virtuelles Netzwerkdatengateway erstellen.

Nein Das virtuelle Netzwerkdatengateway befindet sich physisch in derselben Region wie Ihr virtuelles Azure-Netzwerk. Derzeit können Sie auch nicht auswählen, wo die Metadaten (Name, Details, Datenquellen, verschlüsselte Anmeldeinformationen usw.) für alle Ihre virtuellen Netzwerkdatengateways gespeichert werden. Diese Daten werden in der Standardregion Ihres Mandanten gespeichert.

Nein Das virtuelle Netzwerkdatengateway muss im selben Mandanten wie der Power BI-Mandant erstellt werden.

Nein, virtuelle Netzwerkdatengateways sind derzeit nur in der Basisregion Ihres Mandanten verfügbar.

Einige zu überprüfende Bereiche:

• Stellen Sie sicher, dass Ihre Datenquelle online ist und ausgeführt wird.
• Stellen Sie sicher, dass aus dem virtuellen Netzwerk auf die Datenquelle zugegriffen werden kann, insbesondere aus dem Subnetz, das beim Erstellen des virtuellen Netzwerkdatengateways delegiert wurde. Sie können beispielsweise eine VM im Subnetz bereitstellen und prüfen, ob Sie sich mit der Datenquelle verbinden können.
• Abhängig von Ihrem Szenario sind möglicherweise die folgenden Azure-Netzwerksicherheitsgruppen (NSG) erforderlich:
  • Erlauben Sie ausgehenden Datenverkehr zum Microsoft Entra ID-Endpunkt, während Sie die OAuth- oder Dienstprinzipal-Authentifizierung zum Herstellen einer Verbindung mit einer Datenquelle verwenden.
  • Lassen Sie ausgehenden Datenverkehr zur ZS (Zertifizierungsstelle) zu, während Sie HTTPS zum Herstellen einer Verbindung mit einer Datenquelle verwenden.

Die Konnektivität zwischen dem neuen VNet-Dienst und Ihrem virtuellen Netzwerk nutzt HTTPS und TLS 1.2.

Bei serverlosem SQL mit automatischer Anhaltefunktion kann die erste Anforderung fehlschlagen, wenn SQL angehalten ist, die nächsten Anforderungen werden erfolgreich sein.

Bei der erstmaligen Verwendung dauert die Einrichtung des virtuellen Netzwerkdatengateways etwa 2 Minuten. Wenn das virtuelle Netzwerkdatengateway 30 Minuten lang nicht verwendet wird, kann es bei der nächsten Verwendung ebenfalls zu einer Verzögerung von etwa einer Minute kommen.

Nein, in der öffentlichen Vorschauversion werden nur kommerzielle Clouds unterstützt.

Nein Das VNET-Datengateway stellt eine vollständig verwaltete Compute bereit. Sie können die Anzahl der Knoten in jedem Cluster skalieren.

Ja

Überprüfen Sie, ob andere Gateways dasselbe virtuelle Netzwerk und Subnetz verwenden. Das Löschen ist erst 48 bis 72 Stunden nach dem Entfernen des letzten Gateways möglich, das dieses virtuelle Netzwerk und Subnetz verwendet.

Neben den fünf reservierten IP-Adressen werden ungefähr 5–7 zusätzliche IP-Adressen empfohlen, damit Sie demselben virtuellen Netzwerk und Subnetz weitere VNet-Gateways hinzufügen können.

Stellen Sie sicher, dass Sie explizit über eine Rolle mit der Berechtigung „Microsoft.Network/virtualNetworks/subnets/join/action“ für das virtuelle Netzwerk verfügen, z. B. die Azure-Rolle „Netzwerkmitwirkender“. Diese Berechtigung ist zum Erstellen eines virtuellen Netzwerkdatengateways erforderlich.

Wie sieht es mit der Sicherheit im Vergleich zum lokalen Datengateway aus? Ja, alle Daten, die ein virtuelles Netzwerkdatengateway passieren, bleiben im Azure-Backbone. Wir verwenden einen internen Microsoft-Tunnel, der das öffentliche Internet zwischen dem virtuellen Netzwerk und dem Power BI-Dienst nicht erreicht. Andererseits öffnet das lokale Datengateway eine Verbindung, damit Azure Relay zum Herstellen einer Verbindung mit dem Power BI-Dienst verwendet werden kann.

Unter Berücksichtigung der verschiedenen Ressourcen: Abonnement, Microsoft.PowerPlatform-Ressourcenanbieter, virtuelles Netzwerk, Subnetz und Basismandant des Power BI-Diensts. Wenn Sie einen Dienstendpunkt verwenden, sollten sich das VNet und das Subnetz in derselben Region wie die Daten befinden, mit denen Sie eine Verbindung herstellen. Wenn Sie einen privaten Endpunkt verwenden, können sie sich in verschiedenen Regionen befinden. Die Konfiguration des Datengateways befindet sich in der Power BI-Basismandantenregion.

Ein VNet-Gateway kann im Allgemeinen Quellen erreichen, die innerhalb desselben virtuellen Netzwerks erreichbar sind. Wenn es ein weiteres virtuelles Netzwerk gibt, das vom ersten VNet isoliert ist, ist ein weiteres VNet-Gateway erforderlich.

• Der IP-Bereich des VNet-Subnetzes darf sich nicht mit 10.0.1.x überschneiden.
• Ein Subnetz namens gatewaysubnet kann nicht an das Power Platform Admin Center delegiert werden. Grund für diese Einschränkung ist, dass es sich um ein reserviertes Wort für das Azure Gateway-Subnetzfeature handelt.
• Sie können die Region, das Abonnement oder die Ressourcengruppe für das virtuelle Netzwerk, in dem das virtuelle Netzwerkdatengateway erstellt wurde, nicht ändern. Dieses Szenario wird derzeit nicht unterstützt.
• Wenn eine OAuth-Aktualisierung, die länger als eine Stunde dauert, mit dem Fehler „Ungültige Anmeldeinformationen für die Verbindung“ oder wegen einer Zeitüberschreitung abgebrochen wird, liegt das Problem wahrscheinlich darin, dass die Anmeldeinformationen abgelaufen sind.

Benutzer sind auf 1.000 Datenquellen auf jedem VNET-Gateway beschränkt. Wenn Sie die maximale Anzahl von Datenquellen erreichen, überprüfen Sie, ob die Anzahl der Datenquellen für jedes VNET-Gateway nicht über dem Grenzwert von 1000 liegt. Um verwandte Probleme zu beheben, können Sie die Datenquellen manuell aus dem Admin Center entfernen oder alternativ das folgende PowerShell-Skript verwenden, um alle Datenquellen mit einem angegebenen VNET-Gateway zu massenlöschen, das diesen Grenzwert überschreitet. Sie müssen den Text "GatewayClusterID" durch die spezifische VNET-Gateway-ID ersetzen, damit dieses Skript funktioniert.

## 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
$datasources = Get-DataGatewayClusterDatasource -GatewayClusterId <GatewayClusterId>;
foreach ($datasource in $datasources)
{
  $datasource
  "datasource id={2}, datasourceType={3}, datasource connection details={4}" -f $datasource.Id, $datasource.DatasourceType, $datasource.ConnectionDetails
 
  ## conditional logic to determine if name matches set
  ## Remove-DataGatewayClusterDatasource -GatewayClusterId $gw.Id -GatewayClusterDatasourceId $datasource.Id
}