Forum Discussion
Gateway installation error - Network request returned unexpected errors
Hi!
i have installed standard on-premise gateway on a server and after installation it wants me to sign-in. Here i cant get past the error "Network request returned unexpected error"
what i have i checked according to "troubleshoot guide"
Are the FQDNs and ports mentioned in our documentation opened/allowed in your firewall and/or proxy? - Yes we have all azure service tags enabled for this. with both inbound and outbound traffic enabled
If you're using a proxy server in your environment: - No proxy is present. Its a new server and i am also just trying to install this for the first time.
Is your Firewall just allowing the communication on ports 80 and 443? - Yes its all open
- If yes, ensure the HTTPS mode in gateway is enabled. - i cant set this since i wont get past the "register gateway part with the sign-in.
Other things i have tried which atleast give some clues.
1. ran test in powershell on server (not my strongest thing so dont really know if this says much). something seems not to be able to resolve dns. But i dont get why, we use the latest azure service tags to whitelist IPs etc
any help would be greatly appriciated to get forward and be able to install/ register the gateway.
Hi D_Lav ,
I am wondering if the issue is in DNS policies - perhaps the you do not have a public DNS resolver? Are you allowing all the possible domains - they should be *.powerbi.com, *.analysis.windows.net or *. servicebus.windows.net.
OR, do you have some sort of antivirus software that is blocking it? Either by domain or endpoints?
Is there a log being built that maybe gives a hint? That should be at: C:\Users\<GatewayServiceAccount>\AppData\Local\Microsoft\On-premises data gateway\GatewayConfiguratorLogs
OR, you could just run a network trace with something like Fiddler to see where the block might be occuring.i think its solved! FOR some reason, DNS was able to resolve all endpoints except api.powerbi.com. So Powerbi.com could be resolved which was weird. It seemed to be on server side so what we (Security person and i) eventually did was to update C:\Windows\System32\drivers\etc - Hosts file with the following,
api.powerbi.com
api.privatelink.analysis.windows.netAfter this it worked.
8 Replies
i think its solved! FOR some reason, DNS was able to resolve all endpoints except api.powerbi.com. So Powerbi.com could be resolved which was weird. It seemed to be on server side so what we (Security person and i) eventually did was to update C:\Windows\System32\drivers\etc - Hosts file with the following,
api.powerbi.com
api.privatelink.analysis.windows.netAfter this it worked.
Hi D_Lav,
Based on the PowerShell output, it appears that not all the ports are open properly, as the test to *.analysis.windows.net failed.
Can you work with your firewall team to have all of the below ports opened:
Public Cloud Domain names Outbound ports Description
*.download.microsoft.com 443 Used to download the installer. The gateway app also uses this domain to check the version and gateway region. *.powerbi.com 443 Used to identify the relevant Power BI cluster. *.analysis.windows.net 443 Used to identify the relevant Power BI cluster. *.login.windows.net, login.live.com, aadcdn.msauth.net, login.microsoftonline.com, *.microsoftonline-p.com 443 Used to authenticate the gateway app for Microsoft Entra ID and OAuth2. Note that additional URLs could be required as part of the Microsoft Entra ID sign in process that can be unique to a tenant. *.servicebus.windows.net 5671-5672 Used for Advanced Message Queuing Protocol (AMQP). *.servicebus.windows.net 443 and 9350-9354 Listens on Azure Relay over TCP. Port 443 is required to get Azure Access Control tokens. *.msftncsi.com 80 Used to test internet connectivity if the Power BI service can't reach the gateway. *.dc.services.visualstudio.com 443 Used by AppInsights to collect telemetry. ecs.office.com 443 Used for ECS configuration to enable Mashup features. Public cloud domain names Outbound ports Description
*.core.windows.net 443 Used by Dataflow Gen1 to write data to Azure Data Lake. *.dfs.fabric.microsoft.com 443 Endpoint used by Dataflow Gen1 and Gen2 to connect to OneLake. Learn more *.datawarehouse.pbidedicated.windows.net 1433 Old endpoint used by Dataflow Gen2 to connect to the Fabric staging lakehouse. Learn more *.datawarehouse.fabric.microsoft.com 1433 New endpoint used by Dataflow Gen2 to connect to the Fabric staging lakehouse. Learn more *.frontend.clouddatahub.net 443 Required for Fabric Pipeline execution
Adjust communication settings for the on-premises data gateway | Microsoft Learn
If this helps, please consider giving Kudos. If I answered your question, mark this post as the solutionHi D_Lav ,
I am wondering if the issue is in DNS policies - perhaps the you do not have a public DNS resolver? Are you allowing all the possible domains - they should be *.powerbi.com, *.analysis.windows.net or *. servicebus.windows.net.
OR, do you have some sort of antivirus software that is blocking it? Either by domain or endpoints?
Is there a log being built that maybe gives a hint? That should be at: C:\Users\<GatewayServiceAccount>\AppData\Local\Microsoft\On-premises data gateway\GatewayConfiguratorLogs
OR, you could just run a network trace with something like Fiddler to see where the block might be occuring.Thankyou tayloramy and collinqfor your response.
Hi D_Lav,
We appreciate your inquiry through the Microsoft Fabric Community Forum.
We would like to inquire whether have you got the chance to check the solutions provided by tayloramy, collinq to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.
Thank you.
Hi D_Lav,
We are following up to see if what we shared solved your issue. If you need more support, please reach out to the Microsoft Fabric community.
Thank you.Hi!
Its not solved yet. I will check the provided ideas with IT asap. will get back directly after.
I have checked an all ports etc are open so everything according to communication should be correct? We dont allow names with wildcards so i guess that Azure service tags should take care of that? the list is updated automatically when a new list is published.
i did find a funny thing regarding another gateway in my cluster (to which i want to connect the new gateway that im trying to install). On my main cluster instance, proxy is configured. Its not configured on the second member or on the new one that i am trying to configure/install.
Problem is that, as soon as i try to remove it. gateway stops working. This is a production machine with hundreds of datasources connected to it so i am deadly afraid of trying to destroy anything so my business need to redo all datasources.
Could this have anything to do with the issue on the other servers? The idea of adding a new member to the cluster was because i eventually wanted to reinstall the main member to remove the proxy. OR if anyone else has a better option i am all ears around that.
