When a report is emailed to an end user and they've checked the "Include Link" the link is created using the hostname of the server rather than the FQDN.
In rsreportserver.config I've set the <UrlRoot> attribute in the <Service> node to be the FQDN of the report server: ie: <UrlRoot>https://reportservername.domain.edu/ReportServer</UrlRoot>
I've rebinded the certificate just to make sure it wasn't a flaky bind. It is a wildcard cert, but it works for everything else just fine.
Does PBIRS ignore the <UrlRoot> attribute? Anyone else seeing this issue?
I also have come across this problem and I'm using a wildcard certificate. Has anyone found a workaround for this problem? I've installed Power BI Report Server May 2019 version.
I think I found the fix for this. If you look in the most recent ReportingServicesService_<datetime>.log file I saw lines like the following:
configmanager!WindowsService_0!134c!05/29/2019-09:20:49:: i INFO: Using report server internal url https://<server FQDN>/ReportServer. configmanager!WindowsService_0!134c!05/29/2019-09:20:49:: i INFO: Using report server external url http://<server machine name>:80/ReportServer.
Notice that the external url is listed as being the machine/hostname.
It's not very well documented (in fact the docs claim that its only Sharepoint that uses this setting) but I found that adding both ReportServerUrl and ReportServerExternalUrl settings in the rsreportserver.config file fixed this issue.
These setting needs to be nested in the <UI> element (see below)
<Configuration> .... <UI> <ReportServerUrl>https://<fqdn>/ReportServer</ReportServerUrl> <ReportServerExternalUrl>https://<fqdn>/ReportServer</ReportServerExternalUrl> <PageCountMode>Estimate</PageCountMode> </UI> .... </Configuration>
After adding these settings I think you need to stop then start PBIRS for them to take effect. Make sure to take a backup copy of your config file and check the most ReportServerService_<date>.log file after re-starting PBIRS as if you introduce any errors PBIRS may not start up properly, but you should find the reason in this log file.