Unfortunately, there’s no easy way to do this. But we did come up a few methods, two of which we’ll describe below. Please note: These solutions are NOT supported by Microsoft – if your team is caught, the Secretary will disavow all knowledge of your actions. (We’re joking, of course.)
The ReportServer.dbo.Catalog Method
SSRS stores its metadata in a SQL Server database called ReportServer. In that database the directory structure of the SSRS installation is stored in a table called Catalog. This table contains the root, the folders, all of the connection files, reports, etc.
(See image below.)
Of interest here are the Path and Name columns. They are one part of the pathway that drives the default export filename. Conceivably, a SQL procedure could change these to meet your requirements and be scheduled to run on a regular basis.
However, because of the clunky nature of this method (exporting a report is client-side, so the solution should ideally be client-side as well) and its various side effects (this method would change the report name, not just the default export filename) we moved to the next method.
The actual code customization was trivial. In fact, we found a user modification online for MS Dynamics CRM that essentially accomplishes the same goal. And since Dynamics CRM uses the ReportViewer module as well, we only had to adapt that code slightly to meet our needs.
The concept is simple: ReportViewer has a variable called ExportUrlBase, which stores the default export filename (among other things). So, all we had to do was modify ExportUrlBase and change the default filename.
In the above code, the try-catch block as well as the if(r == null) block are set up so that if the function is called before the ReportViewer module is fully loaded, it won’t modify ExportUrlBase, but will instead keep checking every second to see if ReportViewer has finished loading.
So there you have it. This is the method we used to modify our default export filename, and it does the job well.