In previous blogs in this series, I’ve covered Power BI governance topics that are useful for most organizations but implementing a data gateway is only needed for organizations using on-premise data sources. If you’re using all cloud data sources, then congratulations! This step is not needed at all for your implementation. That makes your life a little easier with deploying and implementing Power BI.
However, for those of you still using on-premise data sources, a data gateway is required for your Power BI implementations. To help you understand what to do, let’s dive into some guidelines to follow when setting up your data gateway(s).
One Gateway Per Server
Setting up a data gateway is only needed for on-premise data sources. Additionally, only one data gateway is allowed per server. Here is a link to download the latest Power BI data gateway.
Use Service Accounts
Make sure you use service accounts with the correct permissions for your data source connections. Service accounts are shared accounts that have the appropriate permissions for those on-premise data sources. Don’t use personal accounts, because that can get messy when passwords expire. If passwords expire and you haven’t replaced them in the gateway connection, then your data sources will be offline, and you may have end users saying they can’t connect to their Power BI reports.
Consider Clustering Data Gateways
By “clustering”, I mean you can install one data gateway and then install another data gateway and attach it (or cluster it) to the existing data gateway. I have some use cases for this below.
Dev/Test/Prod Data Separation
Maybe you want to have a data gateway for just your dev data source connections, your test, or your prod data sources. Like how we set up workspaces in that dev/test/prod environment, consider setting up your data gateway cluster in that same configuration.
Divide by Type (Like DirectQuery vs Import)
You may want to set up your cluster based on the type of data source connections you’re using (like DirectQuery vs. import data source connections). You may want all your imported dataset connections to sit on one cluster. For your DirectQuery data source connections, you’ll want that to sit on a different data gateway.
Why? Because DirectQuery utilizes much more CPU for those queries back to your data source. For import data source connections, you’re going to need much more RAM (memory) resources on that gateway server because all that data is saved in data source files.
Do Not Allow Personal Data Gateways
It’s possible to install personal gateways. That’s often for people trying out Power BI – maybe on their own. Power BI lets you install a personal data gateway, but don’t do this because it often causes confusion with end users.
When end users publish their reports to the service, they will often connect to their personal gateway by default if it’s installed. You want end users connecting their reports to the data sources set up in the data gateways that are managed by your IT department.
Have a Strategy for Monthly Gateway Updates
Just like with Power BI Desktop, the data gateway comes out with monthly updates (to learn more about the monthly Power BI Desktop updates, check out my regularly updated blog about the latest features). It’s important to stay up to date on those. Create a strategy for who’s going to make those updates and how the data gateway will get updated.
Designate Gateway Administrators
Finally, designate the appropriate gateway admins in your organization. Put the right people in charge of your data gateway: those who have the permissions and access to shared credentials. Oftentimes, that may be certain people in the IT department, or maybe certain power users in the different business units.
If you have more questions about effective data gateway setup, please reach out. We are always happy to help.