Internal application link


I am facing a problem with my internal application URL, DBI0040.
My instance can be accessed using https://example/logon and I’ve added this link, https://example/, into the internal application URL configuration but is still wrong.

Where can I find the correct internal link?


How do you know that it’s wrong?

I had a case where Dundas kept complaining that it was wrong, but it turned out to be a firewall issue on our end.


Hello David,

When I run the health check I’ve received this error:
“Scheduler service is running, but cannot connect to server. Check the application log for further details.
Ensure the value for the ‘Internal Application URL’ configuration setting is correct.”
Can you detail a little bit this firewall error please? I want to understand if this can be my problem too.

That is the exact symptoms that I had.

Can you access the link from your computer? Can you access the link from a browser running on the server that is running Dundas BI?

When Dundas uses the application link it requires Dundas to go out of its server and then back in to the same server again, as far as I understand. I’m not sure what the firewall issue was - our IT sorted it - but it was to do with traffic being allowed out and in of the server itself.


I agree with David on this one. I know his browser nowadays has internet access since I worked with Costin on an issue once regarding that, so accessing it shouldn’t be an issue from that perspective.

Costin - copy the link you specified in the Internal Application URL setting, then remote into your server, open a browser on it and paste the link in to try and access it.

1 Like

Thanks @david.glickman and @christian.pervan! :slightly_smiling_face:
I’ve solved this error. It was a port forwarding problem.

In my case, I had to use this site (since our server is Ubuntu (Linux)):

Under Dundas BI scheduler commands I ran the status command and it showed that the scheduler was running! Unreal, since it clearly wasn’t. I then ran the restart command by prefixing the whole thing with sudo (sudo systemctl restart ...) to restart the service, and boom, everything came back online.

Side note: getting the {InstanceName} proved to be a bit challenging. I ran systemctl list-units --type=service to see the names of dundas services running, and it showed me the name, which I wouldn’t have guessed.

Hope this helps anyone else searching for answers to this issue!

1 Like