August 16, 2005 at 6:34 am
When you schedule the report to run, can you see it in the Jobs of SQL Server Agent? Or have you tiered checking the event logs for any errors during execution?
August 16, 2005 at 6:40 am
There are four jobs in the SQL Server Agent jobs, the times all corresponding to the four different ways we've tried to run this -- two timed subscriptions, and the history and execution. However, the steps of those jobs just enter something into an event table, and those jobs are running fine. I've been trying to learn enough under-the-hood stuff to figure out what picks up from there. My guess is that the subscription or snapshot creates that little job we see. That job runs and places a tag in the event table (which happens successfully). Then *something* should poll that event table (maybe a trigger...? haven't gone digging there yet) and see that the report snaphot/subscription should be kicked off. Is that correct?
I have to admit, so far, logging in RS mystifies me. I've looked at the server event logs (app, sys and security) and can't see anything at the time the jobs kick off, so there are no errors there. Are there any other logs associated with RS that I can check? I've checked the one in the RS directory, but it shows nothing except for the direct access through the Report Manager that I can tell.
Thanks!!!!!
August 17, 2005 at 4:48 am
ReportingServices installs a service called 'ReportServer', it is this that polls the event table, and actually runs your job.
The Report Server logs you need to check for errors are in:
C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\LogFiles
August 17, 2005 at 9:11 am
We did more digging throughout the day yesterday.
The service has been running (we'd checked that). I did stop and restart it, and nothing happened.
I went hunting logfiles (I found a reference that said specifically to check ReportServerService*.log). I discovered that *that* particular logfile (and not the other two generated) stopped back on 6/12 -- it looks like it shuts down every 12 hrs and restarts itself in a new file, and that time it didn't come back. When I restarted the service, it started logging again -- but to a different directory!! The service runs as a particular ID, and now it's logging to that IDs temp directory, rather the one listed above that it SHOULD log to.
And subscriptions/snapshots are still not working. *sighs* Back to more poking.
August 17, 2005 at 12:51 pm
Got a little further. The logging has been fixed -- somehow the permissions for our service ID had been taken away on the logging directory, so it couldn't write to the logs there, so it stored them in its own place.
This is being run by an ID which has run as service access to the server only -- it can't log on. On the live server, where everything works, the service does its restart thing every 12 hrs successfully. On the test server, it gives a temporary profile error, and hiccups during the service starting. I can't help but think this difference is a part of the symptoms. Right now, symptoms seem to be what I've got available for chasing.
August 18, 2005 at 2:38 pm
Just in case someone else runs into this problem, here are the things we ended up finding wrong with it and had to do to fix it.
1. Fixed directory permissions
Directory permissions had been inherited from somewhere further up the line, erasing the permissions for our RS Service ID to the following directories under Reporting Services:
logfiles -- RW
ReportServer -- RWE
Temp -- RWED
2. Fixed login permissions
Someone had added the group Everyone to the Guest account on this server. So, any domain ID not in another group ended up logging on as a Guest -- ie, a temporary profile. Since Win2k won't write encryption information to a temporary profile, the service startup failed.
We removed Everyone from Guest. Then added our service ID temporarily to the Admin group so we could log on once to create the profile. AFter that, removed it again and we were able to restart the service... but now we were getting key errors.
3. Remove encrypted information
Because of all the account finagling, RS thought we'd changed IDs. *sighs* Since we had no good ID to revert to, we had to simply delete the encrypted information (rskeymgmt -d).
However, this also removed all the connection strings from our data sources, and removed all stored credentials from the data sources, so we needed to redeploy those.
And NOW my subscriptions and snapshots are working beautifully again.
Viewing 6 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply