In previous blogs in this series, we’ve covered Microsoft Power BI governance topics useful for your organization. The topic of on-premises data gateway is only needed for organizations using on-premises data sources. If you’re using all cloud data sources, then congratulations! This step is not needed at all for your implementation and simplifies your Power BI architecture.
However, for those of you using on-premises data sources, a data gateway is required for your Power BI service architecture. To help you understand what to do, let’s dive into some guidelines when configuring your on-premises gateway(s). (See our data solutions)
One Gateway Per Server
Setting up a data gateway is only needed for on-premises data sources. Additionally, only one data gateway can be installed per server. Here is a link to download the latest Power BI data gateway.
Use Service Accounts
Ensure you are using service accounts with the appropriate permissions for authentication in your data source connections. Don’t use personal accounts, due to password expiration or an employee leaving your organization. If passwords expire and you haven’t replaced them in the gateway connection, then your data sources will be offline. This may lead to end user frustration with Power BI reports being unavailable.
Consider Clustering Data Gateways
Clustering data gateways means you can install one data gateway and then install another data gateway and attach it (or cluster it) to the existing data gateway. We have some use cases for this below.
Dev/Test/Prod Data Separation
One option for your gateway setup is to have a single gateway for your dev data source connections, your test, or your prod data sources. Similar to how we recommended setting up your workspace environments with a dev/test/prod distinction, consider setting up your data gateway cluster in a similar 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 to consider putting all your imported dataset connections on one cluster. For your DirectQuery data source connections, you will want those connections to sit on a separate data gateway.
Why? Because DirectQuery datasets require more CPU for those native queries back to your data source. Import datasets will require more memory (RAM) resources on that gateway server.
Do Not Allow Personal Data Gateways
It’s possible to install personal gateways. That’s often for users testing out Power BI in their personal workspace in the Power BI service. It is highly recommended to not allow personal gateway installation to avoid confusion with end users configuring their dataset refreshes in the Power BI service.
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 on-premises 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. 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 within your organization.
If you have more questions about effective data gateway setup, feel free to contact us. We are always happy to help.
