Wednesday, May 15, 2013

DPM 2012 Not Generating E-mail Reports after Upgrading to SP1

We have been using DPM 2012 for quite a while now. We also have the reports set to deliver reports daily/weekly. After we upgraded to SP1, we noticed it no longer was e-mailing us the reports, even though the alerts for errors continued to come. We also could run reports manually, but no automatic e-mails.

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 to fail. The system files may be corrupt. Retry the reporting task. If the problem persists, repair your DPM installation using the steps described in the System Center 2012 Service Pack 1 DPM Deployment Guide. ID: 3014"

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 (, 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.


regalleuchte said...

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

Justin Bennett said...

I'm glad it worked for you. Greetings from Southern California!

John E said...

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

Unknown said...

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

Justin Bennett said...

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.

Unknown said...

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.

Unknown said...

in our case also, we are unable to email after a AD account is disabled...did you get a solution for this?