Install on-premises data gateway for Azure Logic Apps
Before you can connect to on-premises data sources from Azure Logic Apps, download and install the on-premises data gateway on a local computer. The gateway works as a bridge that provides quick data transfer and encryption between data sources on premises and your logic apps. You can use the same gateway installation with other cloud services, such as Power Automate, Power BI, Power Apps, and Azure Analysis Services. For information about how to use the gateway with these services, see these articles:
- Microsoft Power Automate on-premises data gateway
- Microsoft Power BI on-premises data gateway
- Microsoft Power Apps on-premises data gateway
- Azure Analysis Services on-premises data gateway
This article shows how to download, install, and set up your on-premises data gateway so that you can access on-premises data sources from Azure Logic Apps. You can also learn more about how the data gateway works later in this topic. For more information about the gateway, see What is an on-premises gateway? To automate gateway installation and management tasks, visit the PowerShell gallery for the DataGateway PowerShell cmdlets.
An Azure account and subscription. If you don't have an Azure account with a subscription, sign up for a trial Azure subscription.
- Your Azure account needs to be either a work account or school account, which looks like
firstname.lastname@example.org. You can't use Azure B2B (guest) accounts or personal Azure accounts, such as @hotmail.com or @outlook.com.
If you signed up for a Microsoft 365 offering and didn't provide your work email address, your address might look like
email@example.com. Your account is stored in an Azure AD tenant. In most cases, the User Principal Name (UPN) for your Azure account is the same as your email address.
To use a Visual Studio Standard subscription that's associated with a Azure account, first create an Azure AD tenant or use the default directory. Add a user with a password to the directory, and then give that user access to your Azure subscription. You can then sign in during gateway installation with this username and password.
Your Azure account must belong only to a single Azure Active Directory (Azure AD) tenant or directory. You need to use the same Azure account for installing and administering the gateway on your local computer.
When you install the gateway, you sign in with your Azure account, which links your gateway installation to your Azure account and only that account. You can't link the same gateway installation across multiple Azure accounts or Azure AD tenants.
Later in the Azure portal, you need to use the same Azure account to create an Azure gateway resource that links to your gateway installation. You can link only one gateway installation and one Azure gateway resource to each other. However, your Azure account can link to different gateway installations that are each associated with an Azure gateway resource. Your logic apps can then use this gateway resource in triggers and actions that can access on-premises data sources.
- Your Azure account needs to be either a work account or school account, which looks like
Here are requirements for your local computer:
- .NET Framework 4.8
- 64-bit version of Windows 7 or Windows Server 2008 R2 (or later)
- 8-core CPU
- 8 GB memory
- 64-bit version of Windows Server 2012 R2 or later
- Solid-state drive (SSD) storage for spooling
The gateway doesn't support Windows Server Core.
Install the on-premises data gateway only on a local computer, not a domain controller. You don't have to install the gateway on the same computer as your data source. You need only one gateway for all your data sources, so you don't need to install the gateway for each data source.
To minimize latency, you can install the gateway as close as possible to your data source, or on the same computer, assuming that you have permissions.
Install the gateway on a local computer that's on a wired network, connected to the internet, always turned on, and doesn't go to sleep. Otherwise, the gateway can't run, and performance might suffer over a wireless network.
If you plan to use Windows authentication, make sure that you install the gateway on a computer that's a member of the same Active Directory environment as your data sources.
The region that you select for your gateway installation is the same location that you must select when you later create the Azure gateway resource for your logic app. By default, this region is the same location as your Azure AD tenant that manages your Azure user account. However, you can change the location during gateway installation or later.
If you're updating your gateway installation, uninstall your current gateway first for a cleaner experience.
As a best practice, make sure that you're using a supported version. Azure releases a new update to the on-premises data gateway every month, and currently supports only the last six releases for the on-premises data gateway. If you experience issues with the version that you're using, try upgrading to the latest version as your issue might be resolved in the latest version.
The gateway has two modes: standard mode and personal mode, which applies only to Power BI. You can't have more than one gateway running in the same mode on the same computer.
Azure Logic Apps supports read and write operations through the gateway. However, these operations have limits on their payload size.
Install data gateway
After the gateway successfully installs, provide the email address for your Azure account, and then select Sign in, for example:
Your gateway installation can link to only one Azure account.
Select Register a new gateway on this computer > Next. This step registers your gateway installation with the gateway cloud service.
Provide this information for your gateway installation:
- A gateway name that's unique across your Azure AD tenant
- The recovery key, which must have at least eight characters, that you want to use
- Confirmation for your recovery key
Save and keep your recovery key in a safe place. You need this key if you ever want to change the location, move, recover, or take over a gateway installation.
Note the option to Add to an existing gateway cluster, which you select when you install additional gateways for high-availability scenarios.
Check the region for the gateway cloud service and Azure Service Bus Messaging instance that's used by your gateway installation. By default, this region is the same location as the Azure AD tenant for your Azure account.
To accept the default region, select Configure. However, if the default region isn't the one that's closest to you, you can change the region.
Why change the region for your gateway installation?
For example, to reduce latency, you might change your gateway's region to the same region as your logic app. Or, you might select the region closest to your on-premises data source. Your gateway resource in Azure and your logic app can have different locations.
Next to the current region, select Change Region.
On the next page, open the Select Region list, select the region you want, and select Done.
Review the information in the final confirmation window. This example uses the same account for Logic Apps, Power BI, Power Apps, and Power Automate, so the gateway is available for all these services. When you're ready, select Close.
Check or adjust communication settings
The on-premises data gateway depends on Azure Service Bus Messaging for cloud connectivity and establishes the corresponding outbound connections to the gateway's associated Azure region. If your work environment requires that traffic goes through a proxy or firewall to access the internet, this restriction might prevent the on-premises data gateway from connecting to the gateway cloud service and Azure Service Bus Messaging. The gateway has several communication settings, which you can adjust.
An example scenario is where you use custom connectors that access on-premises resources by using the on-premises data gateway resource in Azure. If you also have a firewall that limits traffic to specific IP addresses, you need to set up the gateway installation to allow access for the corresponding managed connectors outbound IP addresses. All logic apps in the same region use the same IP address ranges.
For more information, see these topics:
- Adjust communication settings for the on-premises data gateway
- Configure proxy settings for the on-premises data gateway
High availability support
To avoid single points of failure for on-premises data access, you can have multiple gateway installations (standard mode only) with each on a different computer, and set them up as a cluster or group. That way, if the primary gateway is unavailable, data requests are routed to the second gateway, and so on. Because you can install only one standard gateway on a computer, you must install each additional gateway that's in the cluster on a different computer. All the connectors that work with the on-premises data gateway support high availability.
You must already have at least one gateway installation with the same Azure account as the primary gateway and the recovery key for that installation.
Your primary gateway must be running the gateway update from November 2017 or later.
After you set up your primary gateway, when you go to install another gateway, select Add to an existing gateway cluster, select the primary gateway, which is the first gateway that you installed, and provide the recovery key for that gateway. For more information, see High availability clusters for on-premises data gateway.
Change location, migrate, restore, or take over existing gateway
If you must change your gateway's location, move your gateway installation to a new computer, recover a damaged gateway, or take ownership for an existing gateway, you need the recovery key that was provided during gateway installation.
Before you restore the gateway on the computer that has the original gateway installation, you must first uninstall the gateway on that computer. This action disconnects the original gateway. If you remove or delete a gateway cluster for any cloud service, you can't restore that cluster.
Run the gateway installer on the computer that has the existing gateway.
After the installer opens, sign in with the same Azure account that was used to install the gateway.
Select Migrate, restore, or takeover an existing gateway > Next, for example:
Select from the available clusters and gateways, and enter the recovery key for the selected gateway, for example:
To change the region, select Change Region, and select the new region.
When you're ready, select Configure so that you can finish your task.
To get visibility into all the on-premises data gateways in an Azure AD tenant, global administrators in that tenant can sign in to the Power Platform Admin center as a tenant administrator and select the Data Gateways option. For more information, see Tenant-level administration for the on-premises data gateway.
By default, the gateway installation on your local computer runs as a Windows service account named "On-premises data gateway service". However, the gateway installation uses the
NT SERVICE\PBIEgwService name for its "Log On As" account credentials and has "Log on as a service" permissions.
Your Windows service account differs from the account used for connecting to on-premises data sources and from the Azure account that you use when you sign in to cloud services.
Like any other Windows service, you can start and stop the gateway in various ways. For more information, see Restart an on-premises data gateway.
How the gateway works
Users in your organization can access on-premises data for which they already have authorized access. However, before these users can connect to your on-premises data source, you need to install and set up an on-premises data gateway. Usually, an admin is the person who installs and sets up a gateway. These actions might require Server Administrator permissions or special knowledge about your on-premises servers.
The gateway helps facilitate faster and more secure behind-the-scenes communication. This communication flows between a user in the cloud, the gateway cloud service, and your on-premises data source. The gateway cloud service encrypts and stores your data source credentials and gateway details. The service also routes queries and their results between the user, the gateway, and your on-premises data source.
The gateway works with firewalls and uses only outbound connections. All traffic originates as secured outbound traffic from the gateway agent. The gateway sends the data from on-premises sources on encrypted channels through Azure Service Bus Messaging. This service bus creates a channel between the gateway and the calling service, but doesn't store any data. All data that travels through the gateway is encrypted.
Depending on the cloud service, you might need to set up a data source for the gateway.
These steps describe what happens when you interact with an element that's connected to an on-premises data source:
The cloud service creates a query, along with the encrypted credentials for the data source. The service then sends the query and credentials to the gateway queue for processing.
The gateway cloud service analyzes the query and pushes the request to Azure Service Bus Messaging.
Azure Service Bus Messaging sends the pending requests to the gateway.
The gateway gets the query, decrypts the credentials, and connects to one or more data sources with those credentials.
The gateway sends the query to the data source for running.
The results are sent from the data source back to the gateway, and then to the gateway cloud service. The gateway cloud service then uses the results.
Authentication to on-premises data sources
A stored credential is used to connect from the gateway to on-premises data sources. Regardless of the user, the gateway uses the stored credential to connect. There might be authentication exceptions for specific services, such as DirectQuery and LiveConnect for Analysis Services in Power BI.
Azure Active Directory (Azure AD)
Microsoft cloud services use Azure AD to authenticate users. An Azure AD tenant contains usernames and security groups. Typically, the email address that you use for sign-in is the same as the User Principal Name (UPN) for your account.
What is my UPN?
If you're not a domain admin, you might not know your UPN. To find the UPN for your account, run the
whoami /upn command from your workstation. Although the result looks like an email address, the result is the UPN for your local domain account.
Synchronize an on-premises Active Directory with Azure AD
The UPN for your on-premises Active Directory accounts and Azure AD accounts must be the same. So, make sure that each on-premises Active Directory account matches your Azure AD account. The cloud services know only about accounts within Azure AD. So, you don't need to add an account to your on-premises Active Directory. If the account doesn't exist in Azure AD, you can't use that account.
Here are ways that you can match your on-premises Active Directory accounts with Azure AD.
Add accounts manually to Azure AD.
Create an account in the Azure portal or in the Microsoft 365 admin center. Make sure that the account name matches the UPN for the on-premises Active Directory account.
Synchronize local accounts to your Azure AD tenant by using the Azure Active Directory Connect tool.
The Azure AD Connect tool provides options for directory synchronization and authentication setup. These options include password hash sync, pass-through authentication, and federation. If you're not a tenant admin or a local domain admin, contact your IT admin to get Azure AD Connect set up. Azure AD Connect ensures that your Azure AD UPN matches your local Active Directory UPN. This matching helps if you're using Analysis Services live connections with Power BI or single sign-on (SSO) capabilities.
Synchronizing accounts with the Azure AD Connect tool creates new accounts in your Azure AD tenant.
FAQ and troubleshooting
- On-premises data gateway FAQ
- Troubleshoot the on-premises data gateway
- Monitor and optimize gateway performance