Install on-premises data gateway for Azure Logic Apps

In Consumption logic app workflows, some connectors provide access to on-premises data sources. Before you can create these connections, you have to download and install the on-premises data gateway and then create an Azure resource for that gateway installation. The gateway works as a bridge that provides quick data transfer and encryption between on-premises data sources and your workflows. You can use the same gateway installation with other cloud services, such as Power Automate, Power BI, Power Apps, and Azure Analysis Services.

In Standard logic app workflows, built-in service provider connectors don't need the gateway to access your on-premises data source. Instead, you provide information that authenticates your identity and authorizes access to your data source. If a built-in connector isn't available for your data source, but a managed connector is available, you need the on-premises data gateway.

This how-to guide 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 article. For more information about the gateway, see What is an on-premises gateway? To automate gateway installation and management tasks, see the Data Gateway PowerShell cmdlets in the PowerShell gallery.

For information about how to use the gateway with these services, see these articles:


  • An Azure account and subscription. If you don't have a subscription, create a free account.

    • Your Azure account needs to use either a work account or school account with the format <username>@<organization>.com. You can't use Azure B2B (guest) accounts or personal Microsoft accounts, such as accounts with or domains.


      If you signed up for a Microsoft 365 offering and didn't provide your work email address, your address might have the format In this case, your account is stored in an Azure Active Directory (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 Microsoft 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 AD tenant or directory. You need to use that account when you install and administer 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's associated with your gateway installation. You can link only one gateway installation and one Azure gateway resource to each other. However, you can use your Azure account to set up different gateway installations that are each associated with an Azure gateway resource. Your logic app workflows can then use these gateway resources in triggers and actions that can access on-premises data sources.

  • Local computer requirements:

    Minimum requirements

    • .NET Framework 4.8
    • 64-bit version of Windows 7 or Windows Server 2008 R2 (or later)

    Recommended requirements

    • An eight-core CPU
    • 8 GB of 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.

  • Related considerations:

    • 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, 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 workflow. 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.


      During gateway setup, the Change Region command is unavailable if you signed in with your Azure Government account, which is associated with an Azure AD tenant in the Azure Government cloud. The gateway automatically uses the same region as your user account's Azure AD tenant.

      To continue using your Azure Government account, but set up the gateway to work in the global multi-tenant Azure Commercial cloud instead, first sign in during gateway installation with the username. This solution forces the gateway to use the global multi-tenant Azure cloud, but still lets you continue using your Azure Government account.

    • Your logic app resource and the Azure gateway resource, which you create after you install the gateway, must use the same Azure subscription. But these resources can exist in different Azure resource groups.

    • 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. Microsoft 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. 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.

    • Logic Apps supports read and write operations through the gateway. However, these operations have limits on their payload size.

Install data gateway

  1. Download and run the gateway installer on a local computer.

  2. Review the minimum requirements, keep the default installation path, accept the terms of use, and then select Install.

    Screenshot of the gateway installer, with a minimum requirements link, an installation path, and a checkbox that's highlighted for accepting terms.

  3. After the gateway installation finishes, provide the email address for your Azure account, and then select Sign in.

    Screenshot of the gateway installer, with a message about a successful installation, a box that contains an email address, and a 'Sign in' button.

    Your gateway installation can link to only one Azure account.

  4. Select Register a new gateway on this computer > Next. This step registers your gateway installation with the gateway cloud service.

    Screenshot of the gateway installer, with a message about registering the gateway. The 'Register a new gateway on this computer' option is selected.

  5. Provide this information for your gateway installation:

    • A gateway name that's unique across your Azure AD tenant
    • A recovery key that has at least eight characters
    • Confirmation of the recovery key

    Screenshot of the gateway installer, with input boxes for the gateway name, a recovery key, and confirmation of the recovery key.


    Save your recovery key in a safe place. You need this key to move, recover, or take over a gateway installation or to change its location.

    Note the Add to an existing gateway cluster option. When you install additional gateways for high-availability scenarios, you use this option.

  6. Check the region for the gateway cloud service and Azure Service Bus messaging instance that your gateway installation uses. By default, this region is the same location as the Azure AD tenant for your Azure account.

    Screenshot of part of the gateway installer window. The gateway cloud service region is highlighted.

  7. To accept the default region, select Configure. But 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 workflow. Or, you might select the region that's closest to your on-premises data source. Your gateway resource in Azure and your logic app workflow can have different locations.

    1. Next to the current region, select Change Region.

      Screenshot of part of the gateway installer window. Next to the gateway cloud service region, 'Change Region' is highlighted.

    2. On the next page, open the Select Region list, select the region you want, and then select Done.

      Screenshot of the gateway installer window. The 'Select Region' list is open. A 'Done' button is visible.

  8. 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.

    Screenshot of the gateway installer window with a 'Close' button and green check marks for Power Apps, Power Automate, and Power BI.

  9. Now create the Azure resource for your gateway installation.

Check or adjust communication settings

The on-premises data gateway depends on Service Bus messaging to provide cloud connectivity and to establish 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 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 connector outbound IP addresses. All logic app workflows in the same region use the same IP address ranges.

For more information, see these articles:

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. You also need the recovery key for that installation.

  • Your primary gateway must be running the gateway update from November 2017 or later.

To install another gateway after you set up your primary gateway:

  1. In the gateway installer, select Add to an existing gateway cluster.

  2. In the Available gateway clusters list, select the first gateway that you installed.

  3. Enter the recovery key for that gateway.

  4. Select Configure.

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 you used 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.

  1. Run the gateway installer on the computer that has the existing gateway.

  2. When the installer prompts you, sign in with the same Azure account that you used to install the gateway.

  3. Select Migrate, restore, or takeover an existing gateway > Next.

    Screenshot of the gateway installer. The 'Migrate, restore, or takeover an existing gateway' option is selected and highlighted.

  4. Select from the available clusters and gateways, and enter the recovery key for the selected gateway.

    Screenshot of the gateway installer. The 'Available gateway clusters,' 'Available gateways,' and 'Recovery key' boxes all have values.

  5. To change the region, select Change Region, and then select the new region.

  6. When you're ready, select Configure.

Tenant-level administration

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.

Restart 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 that's 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 a 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. But 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 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.

Architecture diagram of an on-premises data gateway that shows the flow of data between cloud services and on-premises data sources.


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:

  1. 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.

  2. The gateway cloud service analyzes the query and pushes the request to Service Bus messaging.

  3. Service Bus messaging sends the pending requests to the gateway.

  4. The gateway gets the query, decrypts the credentials, and connects to one or more data sources with those credentials.

  5. The gateway sends the query to the data source for running.

  6. 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 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 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

You need to use the same UPN for your on-premises Active Directory accounts and Azure AD accounts. So, make sure that the UPN for each on-premises Active Directory account matches your Azure AD account UPN. 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 an 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 AD 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

Next steps