I was running OpsMgr Reporting, OpsMgr DB, DW, and RMS all on one server install. I set up scheduled reporting to email a report on a weekly basis. The links in the emails being sent were not working. I read a post somewhere, and thought it said to uninstall OpsMgr reporting, then reinstall. Looking back, I think i may have misread the post, because this was a bad idea (and i cant find the post anymore). Here is what i did, and what i had to do to fix the problem.
Also, the original problem of the links not working in the scheduled email reports is a known-issue in SQL Reporting Services. See http://support.microsoft.com/kb/949454/en-us
Here is what I did:
- Uninstalled OpsMgr Reporting.
- Tried to reinstall, but couldn’t. Data already exists (Panic Panic Panic.) LOL
- Tried running resetSRS.exe Failed with “unhandled exception” error, with following event in application log:
.NET Runtime 2.0 Error. EventID 5000
EventType clr20r3, P1 resetsrs.exe, P2 6.0.4900.0, P3 47b73633, P4 system.data, P5 188.8.131.52, P6 471ebb06, P7 245c, P8 2c, P9 system.data.sqlclient.sql, P10 NIL.
- Panicked even more, decided to uninstall SQL Reporting Services
- Removed SQL Reporting Services (SRS) using add/remove programs
- Dropped ReportingServices databases
- Removed ReportServer IIS Virtual Directory/Application pool
- Ran full ntbackup.exe I should have done this yesterday, then I wouldn’t be in this situation LOL
- Reinstalled SRS. Note that I had to choose the SQL components that I wanted to be installed even if they were already installed. In other words, I had to choose database services, and reporting services, even though database services were already installed
- Upgraded SRS to SP2
- Manually ran Reporting Services Configuration tool using default config on all tabs
- Verified SQL reporting services install by browsing to http://localhost/reports yay it worked
- Rebooted just for fun
- Reinstalled OpsMgr Reporting SP1
- Still getting a bunch of SQL Log In failure events in the application log
- Removed the simple log in accounts which were causing the SQL LogIn failures. In OpsMgr UI>Administration>Run As Accounts>Simple Authentication>”Data Warehouse SQL Server Account”> Properties>Account Tab. Change the user to a single space as the user name, and a single space as the password.
- Followed this KB to recreate references to Datawarehouse in the opsMgr DB. http://support.microsoft.com/kb/942865/en-us Using this query on the OperationsManagerDW db:
EXEC MemberDatabaseAttach’dbserver\instanceName’,’datawarehouseDBname’, 1, 1, 1
I had to run the query with the single quotes, but without a space before the single quotes before it would run. In the KB they have spaces before the single quotes which wouldn’t work for some reason.
This seemed to fix the issue, and everything is working properly now. The moral of the story is to take a breather when you start to panic. Also, always lab test database changes, and have a reliable, tested backup.