Waarom werkt vernieuwen in Power BI Desktop wel maar in de Service niet?

Desktop kan jouw lokale netwerkroute, drivers en aanmelding gebruiken, terwijl de Service via een toegewezen cloudverbinding of gatewayverbinding werkt. Test een on-premises bron daarom ook vanaf de gatewaycomputer en controleer daarna de koppeling van het semantic model in de Service.

Wat betekent dat de gateway offline is of niet kan worden bereikt?

De Power BI Service kan op dat moment niet via de toegewezen gateway werken. Laat de gatewaybeheerder de servicestatus, versie, netwerkroute, firewall of proxy en daarna de bronbereikbaarheid vanaf de gatewaycomputer controleren.

Moeten server- en databasenamen in Desktop en de gateway exact gelijk zijn?

Ja, bij gatewaybronnen zoals SQL Server waarvan de koppeling op server- en databasenaam berust. De gebruikte schrijfwijze moet overeenkomen: een DNS-naam, IP-adres en SERVER\INSTANCE zijn niet automatisch dezelfde gatewaybron.

Waar moet ik verlopen Power BI-credentials bijwerken?

Dat hangt af van het verbindingstype. Bij een standaard on-premises gateway beheert de gateway- of verbindingseigenaar de credentials van de databron. Bij personal gateway of een persoonlijke cloudverbinding staan de relevante instellingen bij het semantic model of de gekoppelde verbinding.

Waarom verschijnt mijn gateway niet bij het semantic model?

Een vereiste databron kan ontbreken, de brondefinitie kan niet exact matchen of jouw account kan geen gebruiksrecht voor die databron hebben. Een semantic model met gatewaybronnen moet alle vereiste brondefinities via dezelfde gatewayverbinding kunnen bereiken.

Moet ik een nieuwe gateway installeren als de refresh faalt?

Niet als eerste stap. Controleer eerst de bestaande toewijzing, brondefinities, status, bereikbaarheid en rechten. Een tweede gateway maakt een ontbrekende bronmatch of verlopen credential niet vanzelf geldig en kan de diagnose onduidelijker maken.

Hoe test ik een reparatie zonder meerdere productie-instellingen tegelijk te wijzigen?

Wijzig één aantoonbare oorzaak, start daarna één on-demand refresh en lees de nieuwe poging in de refreshgeschiedenis. Controleer bij succes ook de verwachte actualiteitsdatum en de eerstvolgende geplande run.

Power BI-refresh mislukt: gateway en credentials controleren (2026)

Mislukt een Power BI-refresh in de Service, lees dan eerst de laatste poging in de refreshgeschiedenis en controleer daarna de bronkoppeling en gatewaystatus vóór je credentials wijzigt. Een geslaagde refresh in Desktop bewijst niet dat de Service dezelfde netwerkroute, drivers, verbinding en accountcontext gebruikt.

Deze route gaat over een Import- of geplande refresh van een semantic model in de Power BI Service, niet over een DAX-fout in een visual; noteer voor de diagnose alleen tijdstip, foutcategorie, verbindingstype en laatste geslaagde run, en deel nooit wachtwoorden, tokens, connection strings, servernamen of volledige logs.

Bepaal eerst waar de refresh faalt

Ga in de werkruimte naar het semantic model en kies Refresh > Refresh history. Microsoft beschrijft in Configure scheduled refresh dat je daar per poging de status, starttijd, duur en foutmelding ziet. Leg de laatste mislukte poging vast voordat je instellingen wijzigt.

Maak daarna dit onderscheid:

Alleen de Service faalt: controleer de toegewezen gateway- of cloudverbinding, de opgeslagen credentials en de bereikbaarheid vanuit die verbinding.
Desktop en Service falen allebei: begin bij de bron, Power Query-stappen, drivers, typeconversies of een recente modelwijziging. Lees bij een datatypemelding ook de route voor tekstconversies in Power BI.
De refresh slaagt, maar de gegevens lijken oud: controleer of je het juiste semantic model en de juiste refreshpoging bekijkt. Vergelijk daarna een bekende bronwaarde of actualiteitsdatum, zonder een successtatus als bewijs voor de inhoud te behandelen.
Alleen een visual faalt na een geslaagde refresh: behandel dat als een model-, filter- of DAX-vraag. De algemene DAX-foutmeldingroute houdt die laag apart.
Het model gebruikt DirectQuery of een live connection: de meeste brondata wordt dan niet via een geplande Import-refresh geladen. Controleer eerst welk onderdeel werkelijk ververst, bijvoorbeeld modelmetadata, voordat je een gatewaycredential verandert.

Lees de melding als route naar de juiste beheerlaag

De melding vertelt niet altijd de volledige oorzaak, maar beperkt wel waar je veilig begint.

Gateway is offline of kan niet worden bereikt

Open bij het semantic model Settings > Gateway and cloud connections en controleer welke verbinding is toegewezen. Laat bij een offline standaardgateway de gatewaybeheerder eerst de Windows-service, gatewayversie en netwerkverbinding controleren. Wijzig nog geen broncredential: een correct wachtwoord kan een niet-bereikbare gateway niet online brengen.

Blijft de gateway online maar faalt de bronverbinding, test dan vanaf de gatewaycomputer. Microsoft noemt in Troubleshoot the on-premises data gateway expliciet een lokale Power BI Desktop-test op die computer om een bron- of driverprobleem af te bakenen. Een test vanaf je eigen laptop levert dat bewijs niet.

Data source credentials bevatten een fout

Controleer eerst welk verbindingstype is gekoppeld. Bij een standaard on-premises gateway staan de broncredentials in de beheerde databronverbinding en beheert een gateway- of verbindingseigenaar ze. Bij personal gateway worden credentials via het semantic model beheerd. Voor een cloudbron kan het semantic model aan een persoonlijke of deelbare cloudverbinding zijn gekoppeld.

Laat de bevoegde eigenaar alleen de credential van de getroffen verbinding bijwerken. Verander niet tegelijk authenticatiemethode, bronadres, privacyinstelling en query. Een melding over credentials is ook geen opdracht om een account breder te machtigen dan de bron voor de refresh nodig heeft.

Er verschijnt geen bruikbare gateway

Controleer bij een standaardgateway drie voorwaarden:

iedere on-premises bron van het semantic model bestaat als databrondefinitie op de gateway;
de verbindingsgegevens matchen met de brondefinitie uit Desktop;
de eigenaar van het semantic model mag de betreffende databron gebruiken.

Microsoft legt in Add or remove a gateway data source uit dat de gateway alleen beschikbaar wordt wanneer de vereiste bronnen zijn toegevoegd, de bronmatch klopt en de gebruiker toegang heeft. Voor SQL Server moeten server- en databasenamen exact overeenkomen. SERVER\INSTANCE, een DNS-naam en een IP-adres zijn voor die match verschillende schrijfwijzen.

Een semantic model kan maar één gatewayverbinding gebruiken. Heeft het model meerdere on-premises bronnen, voeg dan alle vereiste definities aan dezelfde gateway toe. Maak geen tweede gateway om één ontbrekende definitie te omzeilen.

De refresh vraagt om privacy- of combinatie-informatie

De Service neemt niet iedere lokale Desktop-instelling over. De officiële gatewayprobleemoplossing noemt als voorbeeld de melding “Information is needed in order to combine data” wanneer Desktop privacycontroles negeert maar de Service dat niet doet. Controleer de privacy-instellingen per bron, test Desktop zonder de optie om privacycontroles altijd te negeren, publiceer een noodzakelijke modelwijziging opnieuw en werk alleen daarna de bedoelde verbinding bij.

Verlaag niet willekeurig alle privacygrenzen om de fout te laten verdwijnen. Bepaal eerst welke bronnen werkelijk worden gecombineerd en welke classificatie daarbij hoort.

De geplande refresh staat uit

Power BI kan een refreshschema uitschakelen na vier opeenvolgende fouten of bij een niet-herstelbare configuratiefout, zoals ongeldige of verlopen credentials. Herstel eerst de onderliggende fout. Zet daarna pas bij Refresh > Schedule refresh het schema weer aan en controleer de eerstvolgende geplande poging in de refreshgeschiedenis.

Stappenplan voor gateway, bron en credentials

1. Leg één mislukte poging vast

Noteer tijdzone, semantic model, starttijd, duur, foutcategorie en of het om een geplande of handmatige refresh ging. Noteer ook de laatste relevante wijziging aan bron, gateway, account, firewall, proxy, driver, Power Query of publicatie. Bewaar geen screenshot met servernaam, gebruikersnaam, querytekst, token of e-mailadres in een breed gedeeld ticket.

2. Identificeer de actieve verbinding

Open de instellingen van het semantic model en vouw Gateway and cloud connections uit. Bepaal welke van deze situaties geldt:

Standaard on-premises gateway: het semantic model is gekoppeld aan een beheerde databronverbinding. De broncredentials worden door de verbindingseigenaar of gatewaybeheerder beheerd, niet als vrije invoer bij iedere refresh.
Personal gateway: de gateway hoort bij één gebruiker en de broncredentials staan bij het semantic model.
Cloudverbinding: een persoonlijke of deelbare cloudverbinding is aan de bron gekoppeld. Controleer de gekozen mapping en laat de eigenaar van die verbinding de authenticatie herstellen.
Gemengde mashup: één Power Query-query combineert een on-premises bron met een cloudbron. De cloudbron kan dan ook via de gateway moeten lopen.

Microsoft beschrijft deze grenzen in Data refresh in Power BI: een standaardgateway gebruikt brondefinities met beheerde credentials, een personal gateway gebruikt de credentials bij het semantic model en een gecombineerd model kan extra brondefinities op dezelfde gateway nodig hebben.

3. Controleer bronmatch en toegang

Vergelijk connector, server- of hostnotatie, database, bestandspad en andere vaste bronparameters met de gepubliceerde Desktop-definitie. Controleer bij SQL Server expliciet dezelfde server- en databasenaam. Kijk vervolgens of het account van de modelbeheerder gebruiksrecht heeft voor iedere vereiste databron op de gateway.

Pas de naam niet stil aan naar een lokaal pad, privé-IP-adres of persoonlijk account om een groen testresultaat te krijgen. Daarmee verander je de productiebron in plaats van de bestaande refresh te herstellen.

4. Test bereikbaarheid vanaf de gatewaycomputer

Laat de gatewaybeheerder controleren of de gateway online is en op de verwachte machine draait. Open vroeg in deze stap de gatewaylogs voor het exacte tijdstip van de vastgelegde fout en bewaar die uitgangssituatie voordat iemand de service herstart, bijwerkt of opnieuw configureert. Test daarna op diezelfde computer of de bron via Power BI Desktop bereikbaar is, vooral wanneer een connector een aparte driver of lokale component nodig heeft.

Deel bij escalatie alleen het tijdstip, de gatewaycategorie, de foutcategorie en de relevante gemaskeerde logregels. Een volledig logpakket kan bronadressen, gebruikerscontext of querydetails bevatten en hoort bij de aangewezen beheerder.

5. Werk alleen de juiste credential bij

Geeft de fout expliciet een verlopen of ongeldige aanmelding aan, laat dan de eigenaar de credential bijwerken op de plek die bij het verbindingstype hoort. Gebruik dezelfde bedoelde authenticatiemethode, bijvoorbeeld Windows, Basic of OAuth2, tenzij een beheerd besluit die methode wijzigt.

Controleer daarnaast of het bronaccount nog de minimaal benodigde leesrechten heeft. Een online gateway met een geldige aanmelding kan nog steeds falen wanneer bronrechten zijn ingetrokken. Geef geen bredere rol om alleen de test te laten slagen.

6. Voer één on-demand refresh uit

Start na precies één aantoonbare herstelactie één handmatige refresh. Lees de nieuwe poging opnieuw via Refresh history en vergelijk status, duur en foutcategorie met de vorige run. Controleer bij een geslaagde run ook een bekende actualiteitsdatum of controlewaarde in het rapport.

Laat daarna de eerstvolgende geplande refresh gecontroleerd plaatsvinden. Een eenmalige handmatige run bewijst niet dat het schema nog aan staat, dat het geplande tijdvenster werkt of dat de bedoelde beheerder een volgende foutmelding ontvangt.

7. Leg eigenaar en herstelbewijs vast

Noteer verbindingstype, eigenaar, broncategorie, laatste succesvolle refresh, aangepaste instelling en gecontroleerde uitkomst. Noteer nooit het wachtwoord zelf. Leg ook vast wie een verlopen credential mag vernieuwen en wie een gatewaystoring ontvangt, zodat de volgende fout niet opnieuw met willekeurige accountwissels begint.

Wanneer Power Query of DAX toch de oorzaak is

Een refreshfout kan pas zichtbaar worden nadat gateway en credentials correct werken. Kijk dan naar de volledige fouttekst en de eerste falende Power Query-stap. Een nieuw tekstformaat, ontbrekende kolom of gewijzigde bronwaarde vraagt een bron- of transformatieherstel, geen nieuwe gateway.

Faalt een modelberekening tijdens verwerking door een afhankelijkheidslus, gebruik dan de route voor een circulaire afhankelijkheid in Power BI. Voeg geen willekeurige aggregatie toe om een bron-, relatie- of verbindingsfout te verbergen. Ga voor de overige diagnosepaden terug naar de Power BI-hub.

Gebruik als vaste volgorde: refreshpoging lezen, actieve verbinding bepalen, bronmatch controleren, gatewaybereikbaarheid testen, credential en rechten controleren, en pas daarna query of model onderzoeken.

Veelgemaakte fouten

Alleen op je eigen computer testen. Desktop gebruikt mogelijk jouw netwerkroute, drivers en aanmelding, niet die van de gateway of Service.
Een standaardgateway en personal gateway hetzelfde beheren. De relevante credentials staan niet in dezelfde beheerlaag.
Een tweede gateway maken zonder oorzaak. Daardoor kan de ontbrekende brondefinitie of oude koppeling blijven bestaan.
Servernaam in een andere vorm invoeren. Bij connectoren zoals SQL Server kan een IP-adres, alias of andere instance-notatie de vereiste match verbreken.
Credentials breed delen. Laat alleen de bevoegde eigenaar de verbinding bijwerken en zet geen geheimen in tickets, chat, screenshots of logs.
Vier instellingen tegelijk wijzigen. Je kunt dan niet bewijzen welke wijziging hielp of welke veilig moet worden teruggedraaid.
Een verbindingstest als volledige oplossing zien. Bevestig met één echte on-demand refresh, inhoudelijke actualiteitscontrole en de volgende geplande run.
Een bron- of Power Query-fout als gatewayprobleem behandelen. Een verdwenen kolom, gewijzigd pad of nieuwe datavorm vraagt een andere herstelactie.

Hulp inschakelen zonder credentials te delen

Blijft de fout na deze afbakening terugkomen, leg dan alleen de foutcategorie, het verbindingstype, het tijdstip en de uitgevoerde controle vast. Wil je de volgorde laten nalopen zonder credentials, brondata of volledige logs te delen, stel je vraag via WhatsApp.