Then set your Dynamics NAV service tier up to handle the new port and the encrypted connection. In this case it the DynamicsNAV90_NUP service that should publish the oData connection on port 7148. The DynamicsNAV90_NUP service has been configured with the NavUserPassword authentication.

Next test the connection from inside and outside the firewall.

For testing the inside, copy the content of the oData field and paste it in a browser:

This is a good sign [:)]

Entering the user id and password, the following shows up - which by the way also IS a good sign:

Testing from outside the firewall, replace the internal server name with the domain name:

The important part here (I think) is the bad request –Error in Syntax.

That made me think.

The Danish CRONUS name is: CRONUS Danmark A/S, because that is the way Ltd companies are spelled in Denmark. The / in the company name creates the problem and to get around that, I renamed the company to: CRONUS Danmark AS in Dynamics NAV.

Does the NAV instance/service have to be configured with the NavUserPassword authentication? I have been trying this for days and ours is set to WIndows authentication. Outside the firewall, I can use the Get Data command to connect PowerBI to the NAV data, can also use the NAV Webclient and the Windows 10 client app. However, if I try to create a Connection in PowerApps or use 1 of the NAV content packs in PowerBI, I get authentication issues. Could that be due to the NavUserPassword vs Windows authentication?

Does the NAV instance/service have to be configured with the NavUserPassword authentication? I have been trying this for days and ours is set to WIndows authentication. Outside the firewall, I can use the Get Data command to connect PowerBI to the NAV data, can also use the NAV Webclient and the Windows 10 client app. However, if I try to create a Connection in PowerApps or use 1 of the NAV content packs in PowerBI, I get authentication issues. Could that be due to the NavUserPassword vs Windows authentication?