Went to clear and recreate the report schedule and set it to e-mail us, and we got this awesome non-descript error ID: 3014. "An error occurred causing the reporting job on
I checked out the guide and the basic idea to "repair" is uninstall and reinstall. I don't know about you all, but risking loosing backup data just to fix reporting didn't sit well. So, I proceeded to evaluate what was occurring with the SQL Server Profiler on our system and comparing it to our secondary server.
After playing around with it for hours, seemed to narrow down that it was an issue with permissions for the Reporting Services predefined database role called RSExecRole. I went through this guide Create the RSExecRole (http://technet.microsoft.com/en-us/library/cc281308.aspx), used to recreate permissions during a report database move, and we were able to recreate the e-mail subscriptions. It looks like there must have been some undetected failure during the SP1 upgrade.
7 comments:
Thank you so much! With your help and the TechNet documentation I was able to add the missing Stored Procedures to the RSExecRole in the MSDB system database. Et voilà: the scheduled reports are working again. Greetings from Germany, Ralf
I'm glad it worked for you. Greetings from Southern California!
Just to give you some validation.
I saw this on an existing DPM setup, when I was trying to schedule reports.
I followed the suggestion and reloaded DPM from scratch just to make sure it was installed successfully..
After I got it all back up, It still didn't work, same error, It wasn't until I found your blog that it's now doing what it's supposed to..
Thank you
John
Thanks for the information. But the information is not working for me - we're not upgrading but installed a new DPM 2012 SP1 and the reporting worked for sometimes and stopped. Have tried to follow the article but RSExecRole exist in Master and MSDB.
Kindly assist
It's not so much that the role didn't exist as it was missing the needed permissions outlined in the article. If you've gone over all of the permissions and they're set to what they need to be, I'd suggest hitting up a TechNet Forum.
In my case it was the account that we deleted in AD. We have 4 DPMs and they were all running fine until we deleted the account that was used when DPMs were installed. To resolve this issue quickly, we restored deleted account and reports were able to be emailed to distribution list that was specified in DPM settings. Now we are not getting ID Error 3014 anymore in DPM when we try to make change in Reports section of DPM. We will have to investigate and see why this AD account was used in reporting feature of DPM and SQL.
in our case also, we are unable to email after a AD account is disabled...did you get a solution for this?
Post a Comment