Wat de on-premises gateway nu eigenlijk doet en waarom deze faalt
De Power BI-datagateway voor on-premises gebruik is een Windows-service (PBIEgwService) die draait op een machine binnen uw netwerk en een permanente uitgaande verbinding met Azure Service Bus onderhoudt. Wanneer Power BI Service een geplande refresh moet uitvoeren voor een on-premises gegevensbron, stuurt deze de job via dat Service Bus-kanaal naar de gateway. De gateway voert een query uit op de bron, transformeert de gegevens via de Power Query Mashup Engine en streamt het resultaat terug naar Power BI Service.
Deze architectuur heeft twee verbindingen die onafhankelijk van elkaar kunnen worden verbroken. De eerste is de verbinding van Power BI Service naar de gateway via Azure Service Bus – een cloud-naar-gateway-verbinding. De tweede is de verbinding van de gatewaymachine naar de daadwerkelijke gegevensbron – een gateway-naar-gegevensbron-verbinding. De meeste probleemoplossingssessies voor gateways beginnen zonder te weten welke verbinding is verbroken, daarom is systematische diagnose zo belangrijk.
Wanneer de gateway offline is, mislukken alle geplande refreshen voor elke dataset die via die gateway wordt gerouteerd, gelijktijdig. Het feit dat de problemen zich tegelijkertijd voordoen, is op zichzelf al een diagnostisch signaal: wanneer tien datasets exact tegelijkertijd uitvallen, ligt het probleem bij de gateway en niet bij een van de afzonderlijke datasets.
PBIEgwService is gestopt: de meest voorkomende oorzaak
De meest genoemde oorzaak voor een offline gateway in de Fabric Community-forums, waaronder een thread met meer dan 22.000 weergaven, is dat de gateway Windows-service onverwacht stopt. Windows Update herstart de server, een antivirusproces beëindigt de service of een crash zorgt ervoor dat de service stopt zonder dat automatisch herstel is geconfigureerd.
Controleer de servicestatus en configureer automatisch herstarten:
Get-Service -Name "PBIEgwService" | Select-Object Name, Status, StartType
Als de service is gestopt, herstart deze dan en configureer herstel na een fout:
Restart-Service -Name "PBIEgwService" -Force sc.exe failure PBIEgwService reset= 86400 actions= restart/5000/restart/10000/restart/20000
Hiermee wordt de service geconfigureerd om na een crash automatisch opnieuw op te starten, met steeds langere vertragingen tussen herstartpogingen (5 seconden, vervolgens 10, vervolgens 20). Stel het opstarttype in op Automatisch in Services (services.msc), zodat de service na het opnieuw opstarten van de server zonder handmatige tussenkomst start.
Voor servers die worden beheerd door Windows Update, kunt u het opnieuw opstarten van updates buiten de geplande refreshsvensters plannen of updates pauzeren tijdens kritieke refreshsperioden.
Firewall blokkeert Azure Service Bus
De gateway communiceert uitsluitend met Power BI Service via uitgaande verbindingen met Azure Service Bus op poort 443 (HTTPS/WebSocket). Als een firewallregel dit uitgaande verkeer blokkeert, kan de gateway de verbinding met Power BI niet behouden en lijkt deze offline, ook al is de gatewayservice zelf actief.
De vereiste eindpunten voor gatewaycommunicatie:
- *.servicebus.windows.net op poort 443
- *.frontend.clouddatahub.net op poort 443
Test de connectiviteit vanaf de gatewaymachine:
Test-NetConnection -ComputerName "westeurope-prod-sb.servicebus.windows.net" -Port 443
Als de test mislukt, blokkeert de firewall de verbinding. Voeg de vereiste eindpunten toe aan de lijst met toegestane eindpunten voor uitgaand verkeer. Houd er rekening mee dat proxyservers die TLS-inspectie uitvoeren de WebSocket-verbinding kunnen onderscheppen en verbreken, zelfs als de poort open is. In het gedeelte Diagnostiek van de gateway-app kunt u controleren of de Service Bus-verbinding van begin tot eind succesvol is.
Het gatewayconfiguratiebestand (Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config) kan worden gebruikt om proxy-instellingen te specificeren als de gateway-machine proxy-authenticatie vereist voor uitgaande verbindingen.
Gateway is geïnstalleerd op een laptop of een niet-speciaal daarvoor bestemde computer.
Het installeren van de Power BI-gateway op een laptop, een ontwikkelwerkstation of een andere machine die niet altijd aan staat, is een van de meest betrouwbare manieren om onvoorspelbare fouten bij geplande refreshen te krijgen. Elke onderbreking van de machine – slaapstand, het sluiten van het deksel of het loskoppelen van het netwerk – zorgt ervoor dat de gateway offline gaat.
De documentatie van Microsoft raadt expliciet een dedicated server of virtuele machine aan die nooit in slaapstand gaat en een stabiele netwerkverbinding heeft. Dit is geen suggestie voor grote omgevingen – het is de minimale vereiste voor betrouwbare geplande refreshen in een productieomgeving.
Voor machines die de gateway moeten draaien maar niet volledig dedicated zijn, schakelt u de slaapstand uit:
powercfg /change standby-timeout-ac 0
powercfg /change monitor-timeout-ac 0
Dit voorkomt dat de machine in de standby-modus gaat terwijl deze is aangesloten op het stroomnet. Het biedt geen oplossing als de machine wordt uitgeschakeld of opnieuw wordt opgestart – in die gevallen is een dedicated server met automatische service-opstart en -herstel de enige betrouwbare configuratie.
Verouderde gateway-versie
Microsoft brengt maandelijks een update uit voor de on-premises data gateway. Oudere versies bevatten bekende bugs: verbindingsproblemen met bijgewerkte Azure Service Bus-eindpunten, problemen met verlopen certificaten en bugs in de Mashup Engine die ervoor zorgen dat bepaalde typen gegevensbronverbindingen mislukken.
De gatewayversie is zichtbaar in Power BI Service onder Instellingen > Gateways beheren. Als de geïnstalleerde versie meer dan twee of drie maanden achterloopt op de huidige release, werk deze dan bij voordat u tijd besteedt aan andere diagnostische tests. Het probleem kan een bekende bug zijn waarvoor een oplossing is gepubliceerd.
Download de nieuwste versie via het Microsoft Downloadcentrum of via de pagina Gateways beheren in Power BI Service. Het updateproces is een standaardinstallatieprogramma dat de bestaande gatewayconfiguratie en gegevensbronreferenties behoudt.
Organisaties die gateway-updates gedurende langere perioden overslaan, merken soms dat hun gateway de verbinding volledig verliest omdat Azure-eindpunten zijn gewijzigd en de oude versie deze niet meer kan bereiken. Maandelijkse of driemaandelijkse updates voorkomen dit soort problemen volledig.
Verlopen van inloggegevens en mislukte authenticatie van de gegevensbron
De gateway slaat referenties op voor elke geconfigureerde gegevensbron. Wanneer de referenties van een gegevensbron verlopen – bijvoorbeeld omdat een wachtwoord van een serviceaccount is gewijzigd, een OAuth-token is ingetrokken of een API-sleutel is vernieuwd – kan de gateway nog steeds online zijn (verbonden met Azure Service Bus), maar geen verbinding kunnen maken met de specifieke gegevensbron. Power BI kan dit rapporteren als een gatewayfout in plaats van een referentiefout, waardoor het lijkt alsof er een probleem is met de gateway-infrastructuur, terwijl het in werkelijkheid een authenticatieprobleem is.
Om onderscheid te maken: controleer of alle datasets op de gateway een foutmelding geven of alleen datasets die een specifieke gegevensbron gebruiken. Als slechts één of enkele datasets een foutmelding geven terwijl andere wel werken, is de gateway waarschijnlijk in orde en ligt het probleem bij de referenties voor die specifieke gegevensbron.
Referenties bijwerken in Power BI Service: Instellingen > Gateways beheren > selecteer de gateway > selecteer de gegevensbron > Referenties bewerken > voer de huidige waarden in. Nadat u de gegevens hebt opgeslagen, start u een handmatige refresh om te controleren of de nieuwe referenties werken voordat het volgende geplande refreshsvenster wordt uitgevoerd.
Voor organisaties met een AD-wachtwoordrotatiebeleid van 90 dagen, kunt u een agendaherinnering toevoegen om de Power BI-gegevensbronreferenties drie dagen vóór elke rotatie bij te werken. De voorspelbare fout die zich elke 90 dagen voordoet, heeft een voorspelbare oplossing: het enige dat het een incident maakt in plaats van een geplande onderhoudsstap, is het vergeten ervan.
De gatewaylogboeken worden uitgelezen om de daadwerkelijke fout te achterhalen.
De gatewaylogboeken bevatten meer details dan wat Power BI Service rapporteert in de refreshsgeschiedenis. Wanneer de refreshsgeschiedenis een algemene gatewayfout weergeeft, toont het logbestand op de gatewaymachine de specifieke uitzondering, het tijdstempel en vaak het exacte onderdeel dat is mislukt.
Locatie van het gatewaylogboek:
explorer "$env:LOCALAPPDATA\Microsoft\On-premises data gateway"
Filter het logboek op fouten:
Get-Content "$env:LOCALAPPDATA\Microsoft\On-premises data gateway\GatewayErrors.log" -Tail 200 | Where-Object { $_ -match "ERROR|WARN" }
De logboekvermeldingen bevatten een InnerType- en InnerMessage-veld in JSON-formaat. Een netwerkverbindingsfout wordt bijvoorbeeld weergegeven als bericht GatewayNotReachable met InnerType System.Net.Sockets.SocketException en InnerMessage "Er kon geen verbinding tot stand worden gebracht omdat de doelmachine deze actief heeft geweigerd". Het InnerType identificeert de uitzonderingsklasse: CryptographicException voor certificaat- of SSO-problemen, SocketException voor netwerkverbindingsproblemen en SqlException voor authenticatiefouten bij de gegevensbron. Het lezen van InnerType en InnerMessage is bijna altijd sneller dan werken met de algemene foutcode in Power BI Service.
MetricSign en gateway-foutgroepering
MetricSign groepeert 'refresh_failed'-incidenten per gatewaycluster, waardoor tien gelijktijdige datasetfouten als één incident worden weergegeven met een lijst van alle getroffen datasets – en niet als tien afzonderlijke waarschuwingen. De dienstdoende engineer ziet direct de omvang van het probleem en kan meteen het gatewayonderzoek starten.
MetricSign genereert ook 'refresh_delayed'-incidenten wanneer een verwachte refresh niet binnen een bepaald tijdsbestek na de geplande tijd start. Dit detecteert het geval waarin de gateway offline is en de refresh nooit start – wat geen foutcode in Power BI Service oplevert en anders onzichtbaar zou blijven totdat een gebruiker een verouderd dashboard opent.