When attempting to set up and configure the ConfigMgr 2012 site system role for reporting services, a frequently experienced “problem” is that the instance name can be blank/empty in the wizard and thereby unable to proceed with the wizard. This usually occurs when SRS has not been pre-configured properly.
While it is common “knowledge” that the reporting services database needs to be created first, an oft-overlooked step is to use the Reporting Services Configuration Manager to create the virtual directories for IIS. And it is these steps which need to be completed to get you on your way.
- Open Reporting Services Configuration Manager
- Connect to the server/instance
- Click on Web Service URL – make a fake change, such as changing the name of the virtual directory and then putting it back to ReportServer – and clicking Apply. This will then create the new virtual directories.
- Click on Report Manager URL – again, make a change to the name and put back to just Reports – and click Apply to generate the new virtual directories.
- Close configuration manager
- Return to the CM12 site role setup program, click “Verify” for the database connection, and voila the instance is now populated correctly!
We went to install an SRS database on our SCCM 2007 server for FEP 2010, but when attempting to create a new report server db, we were getting error 1807 “System.Data.SqlClient.SqlException: Could not obtain exclusive lock on database ‘model’. Retry the operation later.” It was discovered that the install failed because the Model database had become corrupted and detached. And more unfortunately someone removed backups of the database (lesson learned: do monitor the backups of your system databases!)
Our initial attempts to restore Model was to ‘import’ the model db from another server with the exact same SQL version. While the import was successful and the database was automagically moved into System Databases, the error continued. Knowing that a service pack in effect reinstalls SQL, we upgraded to SQL 2005 SP4. There was still no joy. A proposed solution was to do a cut-over of SCCM to a new server with a clean install of SQL and SCCM. However, in my experience, that would have caused more issues resulting a longer drawn out resolution path. So I wanted to avoid that. Based upon a forum thread somewhere, we had indications that the error was now being caused by Model not having the proper system database ID value. To confirm this, we used a Microsoft support case.
The issue was caused by the `model` db having the incorrect database_id. It was registered as 7, but all system databases must have the specific db_id, with model being ID 3. Which means that model was actually a user database, despite being listed in the System Databases category. To fix the issue, all user databases, model, and msdb were detached. Then attaching them in order model, msdb, user dbs resulted in creating model with ID 3 and msdb with ID 4. The ability to create databases was then fully functional again…