What's your Migration Date?

I am realizing reading through several posts that this seems similar to a problem we wrestled with for a few months post-conversion to v11. We opened a ticket, but eventually resolved it on our own. Infomaker reports were scheduled and ran just fine. SSRS Reports were scheduled, and would "run", but not get "saved" to the folder for emailing, so it appeared as though they didn't run at all. A bevy of errors in the Tessitura Report Server Application Log pointed us in the right direction. Here is a brief description of what we discovered:

----------

We did indeed finally get a working solution, and it came down
to permissions on the folder that temporarily stores the files prior to
emailing.

1) we had to move to using a snapshot folder on the app services machine (which
is also our Report Server) instead of on our SQL database machine
2) we shared the snapshot folder (particularly to the user running SQL services and
the Report Server)
3) we gave full read/write permissions to the 'IIS AppPool\Tessitura_Svcs'
application pool

It was #3 that was really the sticking point - if we kept the snapshot folder on the SQL
database server, adding the app services *machine* rights were not enough to make
this work. It seems we specifically needed the *app pool* rights, and the
only way to do that was to have the folder on the same server as the app
services. Not sure if that is the intended setup, but at least we have it
working again. On pg 12 of the Report Setup/Admin document, it is not very
clear as to the best location of the folder, nor does it specify the app
pool permissions we found to work in our situation.

Our patch upgrade to 11.0.4 last week seems to have also cleared up a few
other small issues as well.

----------

Unknown said:

SSRS Reports were scheduled, and would "run", but not get "saved" to the folder for emailing, so it appeared as though they didn't run at all.

An almost exact description of our situation, i.e. "error creating snapshot" in the Report Server log, the snapshot actually gets created in Report Manager and can be seen and opened there, but nothing is e-mailed. We've gone around and around with permissions settings on the EMAIL REPORT PATH, but our support ticket remains open (since September).

Unknown said:

[...] if we kept the snapshot folder on the SQL
database server, adding the app services *machine* rights were not enough to make
this work. It seems we specifically needed the *app pool* rights, and the
only way to do that was to have the folder on the same server as the app
services.

I'd love to give this a try immediately, but moving our SSRS server to our Services server would not be trivial.

I wonder if the snapshot folder (same as the SSRS_SNAPPATH from t_defaults, yes?) needs to live on the same server as the rest of SSRS? Hmm....

Unknown said:

Quick question.  If the tessitura SSRS_SNAPPATH in t_defaults says /TessituraScheduledReports then it would be in the root of C:  or under impresario client?

 

That's a folder within SSRS, i.e. it can be seen via the Report Manager site. On our server it lives at this URL:

http://actdata/Reports/Pages/Folder.aspx?ItemPath=%2fTessituraScheduledReports&ViewMode=List

Actually, Chris, I believe SSRS_SNAPPATH is deprecated: http://www.tessituranetwork.com/Help_System/Content/System_Tables/Deprecated%20Defaults.htm

(In our case, I believe it is pointing to a non-existent folder - probably from v10.)

The snapshot folder we are now using in v11/SSRS is setup this way:

1) T_DEFAULTS >>> IMPRESARIO >>> EMAIL REPORT PATH >>> \\<YOUR_IISAPPSERVICES_SERVERNAME>\EmailReports

2) On the machine that is hosting IIS/v11 Application Services <YOUR_IISAPPSERVICES_SERVERNAME>, we created a folder (C:\ReportServer\EmailReports)

3) We shared that folder, giving specific read/write permissions to "IIS AppPool\Tessitura_Svcs"

IMPORTANT: I believe we had to type this in by hand, because we couldn't search to find the services app pool name

This page was key in helping us: http://www.bluevalleytech.com/techtalk/blog/assigning-ntfs-folder-permission-to-iis7-application-pools/

(We also shared this folder with our domain user account that runs some of the SQL services - in case that is also necessary - but I believe it was the app pool permissions that did the trick.)

This shared folder holds snapshots for both Infomaker and SSRS reports. You can also test this by changing a setting in T_DEFAULTS:

T_DEFAULTS >>> IMPRESARIO >>> EMAIL REPORT DELETE FILE >>> NO

Setting to no will allow you to see if/where the reports are getting created. (Set this back to Yes when done testing, though.)

It shouldn't require moving SSRS per se - just having a folder on the app services machine should be enough (**I think**)

See page 12 of the Report Server Setup doc - http://www.tessituranetwork.com/~/media/Documentation/Installation/Tessitura_Report_Server_Setup_and_Administration.ashx

It gets to the crux of the problem, but without a ton of details on how to actually carryout the setup.

(Also note that we use SMTP Server Relay for our email report setup in case that makes a difference - probably not. YMMV)

Beth

BETH GILLILAND
UMS Tessitura System Administrator 
bethgill@umich.edu
www.ums.org  //  www.umslobby.org

Unknown said:

Actually, Chris, I believe SSRS_SNAPPATH is deprecated:

Yeah, I don't think ours is being used any more, but the troubleshooting process for this bug has been long and involved, and I know we've touched SSRS_SNAPPATH at some point, though probably not since moving to v11, I'm not sure.

Unknown said:

1) T_DEFAULTS >>> IMPRESARIO >>> EMAIL REPORT PATH >>> \\<YOUR_IISAPPSERVICES_SERVERNAME>\EmailReports

The directory EMAIL REPORT PATH points to is definitely something we've fiddled with the permissions on many times. Evidently giving "Full Control" to "Everyone" on this is insufficient, if you can imagine.

I will definitely try moving EMAIL REPORT PATH to our Services server, and will apply read/write to "IIS AppPool\Tessitura_Svcs" as you describe. 

Thanks for the links and info, this is much appreciated. It sure would be nice to get this bug in the rear-view mirror!

Just to throw my 2 cents in here -

The method that Beth states of simply moving the shared folder off the SSRS server and to the app server along with adding the IIS App Pool permissions worked at our organization as well. The one 'extra' step I had to do in order to get it to work was to not only restart my report server, but I also manually opened Tessitura on the report server and made sure the client files were refreshed. Not sure if it was just an instance of my client files being out of sync or not, but something to make sure of as well because it didn't work until I did that.

- Heather

P.S. And a clarification: giving specific read/write permissions to "IIS AppPool\Tessitura_Svcs" should be the name of YOUR particular organization's Application Pool (which you can see in the IIS manager on your app services server). If you named it something different be sure to use the correct name. We installed v11 before all the recommended naming conventions were out, so I just wanted to mention that.

Unknown said:

Just to throw my 2 cents in here - [...] I also manually opened Tessitura on the report server and made sure the client files were refreshed

Good advice. From bitter experience (with the Report Server of course), the client on the db/report server (the same in our case) is always the first client I start & refresh whenever there are new client files. :-)

Unknown said:

The snapshot folder we are now using in v11/SSRS is setup this way:

[...]

3) We shared that folder, giving specific read/write permissions to "IIS AppPool\[YourAppPoolName]"

[...]

We already had an EmailReports folder on our Services server, since I think I had worked with support on almost this very idea, i.e. EMAIL REPORT PATH on the services server, but without the crucial element above of the app pool permissions on the directory. I've just tried that here, and can report ... it worked!

I just ran a scheduled SSRS -> e-mailed PDF report, received the email with attachment, and the log contains the magic words:

2012-12-12 13:58:46 138734 Info Report snapshot created successfully.

I can't declare complete victory until at least one scheduled job runs overnight, but things are looking very good indeed.

Beth, you are my hero!

Unknown said:

When you restarted the report server did you restart the application or the box?

 

YMMV, but for me this worked without restarting anything but the Report Server app.

Hi John -

Just restarted the report server application - not the server itself.

HTH,

Heather

So glad to hear it worked, Chris. That's what the Network is for, right?!? :) I'm merely standing on the shoulders of other tessy giants.

Heather had a good point, too, about restarting and updating client files on the Report Server. That has bitten us before. I'm pretty sure we restarted the entire system once everything was all said and done in setting up SSRS emailed reports, just to be 100% sure.

Beth