Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!To celebrate FabCon Vienna, we are offering 50% off select exams. Ends October 3rd. Request your discount now.
I have looked through the forum here but i havent seen anyone post about the issue ive seen internally here.
We have a setup as follows:
User logs into a secure portal
User clicks a link to the Power BI Report Server portal
- The secure portal passes the user credentials to the pbi portal (Kerberous is involved)
When using the portal, if the user clicks on a power bi report, everything functions as expected
When using the portal, if the user clickes on a pagenated report, the report fails to load, and the report server reloads, and nests an instance of itself inside the previous instance. See image below.
Solved! Go to Solution.
I've never seen this sort of issue before. But the paginated report rendering is done by the webservice component of Report Server while a different process handles the rendering of pbix reports. So it would be worth checking either in the Report Server Configuration Manager or in the rsreportserver.config file to make sure that the webservice url (which normally defaults to /ReportServer ) is not pointing to the same address as the portal url (which normally defaults to /Reports). If the webservice url was changed to point to /Reports it *might* explain this behaviour as when the portal tried to ask the webservice to render a report it would end up pointing at itself.
I've never seen this sort of issue before. But the paginated report rendering is done by the webservice component of Report Server while a different process handles the rendering of pbix reports. So it would be worth checking either in the Report Server Configuration Manager or in the rsreportserver.config file to make sure that the webservice url (which normally defaults to /ReportServer ) is not pointing to the same address as the portal url (which normally defaults to /Reports). If the webservice url was changed to point to /Reports it *might* explain this behaviour as when the portal tried to ask the webservice to render a report it would end up pointing at itself.
User | Count |
---|---|
5 | |
3 | |
3 | |
2 | |
2 |
User | Count |
---|---|
9 | |
3 | |
3 | |
2 | |
2 |