One of the criteria that the report server uses to match the provided SessionID with a stored report is that the SessionID has to be provided by the same user that initially created the session. Usually, this is the case. Someone browses the report in IE, they click around to paginate or expand toggles, and things just work because they are the same user they were when they initially ran the report.
Sometimes though, things go wrong.
One way that this can happen is when you are hosting the ASP.Net Viewer Control in your own application and you are not impersonating the incoming user all the way to the backend report server. This is a totally supported configuration, however there is a little caveat that you have to keep in mind. Since the report server requires that the user names match across session retrievals, you have to ensure that the viewer control is impersonating the same user. Sounds easy, right? Well not so fast if you are using a machine specific account for your application pool which is hosting the viewer control. The specific topology that can get you into trouble is something like the following:
In this scenario you have the following:
The sequence of operations that can lead to trouble are:
There are a couple of ways to address this problem: