For those migrating soon, what’s your migration date?
We are T-minus 17 days – Sunday October 7
Gonna start working on my migration-day procedure sheet!!
Dave Vivino
Cleveland Orchestra
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?
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chris Jensen Sent: Wednesday, December 12, 2012 9:51 AM To: John Brandt Subject: RE: [Tessitura Next Generation Forum] What's your Migration Date?
Beth Gilliland: 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.
Beth Gilliland:
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).
Beth Gilliland: [...] 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.
[...] 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....
From: Beth Gilliland <bounce-bethgilliland6030@tessituranetwork.com> Sent: 12/12/2012 9:58:43 AM
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.
Group policy may indeed be the culprit, depending on how you have permissions setup. If anyone needs more details, let me know - I can try and dig up more info.
Beth Gilliland
UMS Tessitura System Administrator
bethgill@umich.edu
www.ums.org // www.umslobby.org
You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!
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 GILLILANDUMS Tessitura System Administrator bethgill@umich.eduwww.ums.org // www.umslobby.org
Unknown said: Actually, Chris, I believe SSRS_SNAPPATH is deprecated:
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
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]" [...]
[...]
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!
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.