Update: The original blog post below was written before the following UI for the gateway was available:
Per the image, just launch the On-premises data gateway application and go to Service Settings to access the ‘Restart now’.
Original blog post:
Let’s say you’re an IT admin or someone on the BI and Analytics team responsible for your organization’s Power BI deployment. Let’s also say that the most important Power BI reports and dashboards that your BI/IT team support use on-premises data and thus depend on the On-premises data gateway for either live connections and direct queries or scheduled refreshes (imports to PBI datasets).
If this is the case now and into the future (ie Hybrid BI architecture; data warehouse stays on-premises) then you’ll want to plan for at least all essential administrative scenarios such as restoring the gateway and it’s sources to a different server, common connectivity issues and troubleshooting techniques, and you’ll also likely want to establish a performance monitoring and alerting solution using the gateway performance monitor counters and/or the gateway log files. Adam Saxton (Guy In A Cube) has recently produced multiple videos on these topics and you can always reference the official documentation or to an extent my paper/post in August.
There are many considerations with gateway architecture (how many servers, resource specs of each, for which workloads?) and admin roles and protocols to ensure your organization is getting the most value out of Power BI and other services (PowerApps, MS Flow). Today’s post is narrowly focused on the workflow of simply restarting the On-premises gateway service.
Step 1: Power BI Goes Down
Maybe you get an email (or a thousand) advising that Power BI reports and dashboards are failing or haven’t been refreshed. (Again, you should probably look at ways to be more pro-active in managing the availability of your gateways and data sources).
Step 2: You determine it’s a gateway issue
You might see a warning icon like this for a dataset:
You click the warning icon and get this:
As a gateway admin, you click the gear icon in PBI and then ‘Manage Gateways’ to arrive at the following:
At this point we know that all data sources using this gateway (and thus all datasets/reports/dashboards) have been impacted.
Step 3: Check that the Gateway Service is Running
On the server running this gateway, check that the service is running.
Task Manager – Services – PBIEgwService
So the gateway service is Stopped, which of course aligns with the error messages.
Step 4: Restart the Gateway
Open a command prompt with admin privileges on the gateway server:
net start PBIEgwService
You could also just use Task Manager right-click context:
Step 5: Confirm On-premises gateway (and PBI) is back online
The command prompt, Task Manager, and gateway management screen, and the PBI dataset itself should now be healthy (no warning signs) and users should see their PBI reports and dashboards again.
Conclusions and Next Steps
A ‘big picture’ takeaway is just acknowledging that user adoption hinges on availability and thus, even if it takes away from other BI development resources/projects, these admin processes shouldn’t be taken lightly. A capability is needed to quickly isolate the issue (network? database? gateway?) and have someone (or some script) ready to respond.
What could’ve caused the gateway service to stop? Is there a reference architecture of gateways for different workloads? Is there a recommended delegation of responsibilities for managing PBI availability and performance? These are all good questions to keep in mind that I’ll likely blog about in the future. (One quick plug: detailed analyses and consulting on topics like this are offered by Frontline Analytics).
Insight Quest 