6

I'm experiencing symptoms very similar to what is described in this 2015 MSSSQLTips article:

SQL Server Reporting Services (SSRS) is not compatible with Internet Explorer 11

You upgraded to Internet Explorer 11, now when you preview a SQL Server Reporting Services (SSRS) report you find the print command is not visible in the report viewer. Also, sometimes when you change parameter values IE11 stops responding or it takes a long time to load the report. You may also find that the toolbar that displays the report controls and export features, appears on multiple lines when viewed with IE11. When you preview the same SSRS report in Chrome or Mozilla Firefox, it works fine without any issue, which means it is a browser compatibility issue. How can you make SQL Server Reporting Services (SSRS) compatible with IE11?

Virtually all discussion I can find of this problem refers to this article (or to a now-unavailable MS Connect page).

The problem is that the server-side fix suggested for SSRS 2008 doesn't work for SSRS 2017 (there is no <meta http-equiv="X-UA-Compatible" content="IE=5"> tag in the ReportServer\Pages\reportviewer.aspx file).

Is there an equivalent server-side fix for SSRS 2017? Should I be adding this meta tag to this or a different ASPX file?

Other posts suggest upgrading SSRS, like this question about SSRS 2012, but I'm already on the next-to-last version of SSRS 2017 (14.0.600.689), and the change log for the more recent patch doesn't seem to contain any relevant fixes.

(A client-side fix isn't absolutely out of the question, but would involve a more difficult AD group policy push, so I'd prefer a server-side fix if there is one.)

Improve this question
5
  • I just read that same page from MSSQLTips and have the same question. Did you ever find a fix?
    – Steven Howes
    Jul 19, 2018 at 14:43
  • @StevenHowes Nope, still an open issue for me. I suspect this is something we will have to play around with and figure out. I just added a bounty to the question to motivate additional research.
    – BradC
    Jul 19, 2018 at 15:46
  • 1
    In case you've not yet come across this in your epic quest through google result pages, I think this blog post outlined the kludgy workaround outlined in that connect item: msbitips.blogspot.com/2015/07/…
    – John Eisbrener
    Jul 19, 2018 at 18:01
  • Thanks, @JohnEisbrener. For those unable to follow the link (my work firewall had some complaints), that article discusses editing some specific .js files in SSRS 2018 R2. This doesn't apply to SSRS 2017, which has only .aspx files and .dll files.
    – BradC
    Jul 25, 2018 at 17:00
  • 2
    Why not try adding that meta tag?
    – Anthony Genovese
    Jul 25, 2018 at 20:42

2 Answers 2

Reset to default
2
+250

try add

<meta http-equiv="X-UA-Compatible" content="IE=EDGE">

tag in the ReportServer\Pages\reportviewer.aspx file.

https://stackoverflow.com/questions/6771258/what-does-meta-http-equiv-x-ua-compatible-content-ie-edge-do

Improve this answer
1
  • Thanks, we ended up doing that. We found some related issues that had different fixes, see my other post.
    – BradC
    Jul 26, 2018 at 21:40
1

So after sitting down with the impacted users and walking through the issues in detail, it ended up being several unrelated factors:

  1. The custom logo uploaded as part of the SSRS portal branding was displaying in other browsers but not in IE. It isn't entirely clear what the problem was here (comments on that link discuss several possibilities), but we re-created the PNG logo file using a different graphics app, re-uploaded the "brand package", and this appears to fix the logo issue.
  2. Reports were occasionally loading very slow and/or timing out. It's not clear whether this was entirely a browser issue, but to improve this we ended up disabling "Customer Feedback" usage reporting by setting the following registry key to 0:

HKLM/SOFTWARE/Microsoft/Microsoft SQL Server/SSRS/CPE/CustomerFeedback

Note that most discussion of this suggests turning it off via the "SQL Server Error and Usage Reporting tool, but this doesn't exist on a server with only SSRS installed, so the registry fix (followed by a service restart) is required.

Turns out they weren't actually having an issue with the print button or anything (as described in my original link), so it is unclear whether it was really the same issue at all.

A few other user complaints (about whether parameters with long drop-downs can be re-sized) seem to have resolved on their own, perhaps by an update to IE 11? In any case, we couldn't reproduce these issues.

I did end up adding <meta http-equiv="X-UA-Compatible" content="IE=Edge"></meta> to the <head> section of the ReportViewer.aspx file, per the suggestions here and the comments in the original link. It's not clear whether that fixed anything else, since the other issues had already been resolved.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.