How To Rename Your Reporting Services Databases

I've installed TFS in more than one environment where Reporting Services is already in use.  The big problem that everyone yells about is that TFS requires a blank RS instance in order to install it successfully.  In case you don't have a spare SQL database instance laying around, a nice workaround is to rename the RS databases from their default names.  This allows TFS to create the new RS databases it requires with the default and you can move on with your life.

Thanks to Bob Coppedge over at Simplex-IT for his original blog post on this.  I was able to follow his steps with some slight variations to rename the Reporting Services databases.

1. Backup the ReportServer and ReportServerTempDB databases you plan on renaming--just in case something goes wrong...which never happens, of course.
2. Stop Reporting Services using the Reporting Services Configuration Tool.
3. Script the stored procedures from the ReportServer database to new query window.
4. In the script, search for and replace CREATE PROC with ALTER PROC (one instance contains two spaces between CREATE and PROC.)
5. Save the script.
6. Rename the ReportServer and ReportServerTempDB databases.
7. Go back to the stored procedure script and search for and replace ReportServer with the new database name (ex. ReportServer to ReportServer-NEW.)
8. Save a copy of the script with a new name.
9. Execute the script.
10. Start Reporting Services using the Reporting Services Configuration Tool.
11. Go to the Database Setup "tab".
12. Click the Connect button and then click OK on the pop-up.
13. Select the new database name in the dropdown list.
14. Click Apply and then click OK on the pop-up.  An error will probably occur when saving the new connection info.  Click Apply again and it should succeed.

Finished!  You should be able to test the reports now.  I would go so far as to recommend this as a best practice.  You could leverage the same database server for multiple RS instances this way.  At the very least, it enables you to install Team Foundation Server against a database server that is already supporting an existing RS instance.

jb

Issues with Reporting Services Permissions

After working with TFS security for the better part of a year, I suddenly ran into a nasty permissions issue in Reporting Services this week.  I'll illustrate the problem using pictures.  When I look at security at the top level in Reporting Services using my tfsSetup account, I see that only the TFS Administrators group has the Content Manager role.  That's good because I don't necessarily want everyone looking at the project reports across the board.

Now I'll drill down into the folder for my team project.  In this case, the team project name is JobBoard.  Here I've broken the security inheritance and given my jobBoardProjectAdmin account the Content Manager role.  The expectation is that he or she will be able to manage security for that folder and any of the contained items without having to bug me.  I'd like to fully delegate that function to the JobBoard Team Project Administrator.

With that set up, let's see if the jobBoardProjectAdmin account has access to view the reports as well as administer security for the JobBoard folder.

Looks like I can see the list of reports but then I click the Properties tab...uh oh!  That doesn't look right.  Reporting Services gives me an error stating "The permissions granted to user 'VSTS2008\jobBoardProjectAdmin' are insufficient for performing this operation. (rsAccessDenied)".  I just gave that account the Content Manager role!  I'll check one of the reports.  Maybe that will work.

Same error.  I can view the report just fine, but I can't edit the permissions.  Argh!

So I do some Googling and really don't find much except for folks talking about giving the user some sort of access at a higher level.  I'd rather not have to do that but if I'm going, I'd prefer to do it once and get it over with.  I'll try giving all Authenticated Users the Browser role at the top level.  This may seem to fly in the face of my earlier statement about not wanting everyone to see all of the projects reports.  However, since I broke the security inheritance for the JobBoard folder, the Authenticated Users group won't have the Browser role at that level.  Only the users explicitly given permissions to the folder will be able to see it.  I'll use that policy going forward so the Authenticated Users approach is okay.

Now I'll I try the Properties tab for the JobBoard folder using the jobBoardProjectAdmin account.  The result:  I can see it AND manage permissions.

Success!...kind of.  Why does this work?  Why does this fix the problem?  Why do I have to do this?  Is this the way it's supposed to work?  I really don't know, but I'll have to live with it for now.  I'm working with SQL Server 2008 here.  The problem can be seen in SQL Server 2005, as well.  If anyone has feedback or ideas about this, feel free to respond.  If you're looking for a solution to the problem in your own environment, the Authenticated Users should work just fine.  You could always use a more specific domain group if you like.

On a side note, during this process I discovered a nice little feature in Visual Studio Team System that I hadn't seen before.  In the Security and Group Membership dialogs that are part of Team Explorer there are these links for SQL Server Reporting Services and Windows SharePoint Services Site Administration at the bottom.  I never paid attention to those until now.  They actually take you straight to the appropriate locations for administering security for those resources.

Interestingly enough, the Reporting Services link takes to you to the Properties tab of the top-level folder rather than the folder for the team project.  Strange...

jb