SSRS development and production environment

  • Hi,

    We have set up ssrs 2008 r2 in our company. We are using this for development now. Now we would need a separate environment, that can be called production. Without installing a separate instance can I replicate the same configuration in the same machine or different machine and set that up to callit as production environment for ssrs.

    Thanks in advance

  • yes you can.

    export the encryption key from your existing SSRS service, and then restore the encryption key on the new one.

    backup both the ReportServer and ReportServerTempDb databases, and resotre then on wherever they will be hosted.

    then in Report Service Manager, point the service to use that database, and you end up cloning the reports and everything...but the connection strings of those reports still point to the original db connections.

    if your dev team designed them smartly, and are using shared data sources, you only need to change it in one or two places.

    if each report is using a data source unique to itself, then yuck, you have to edit each report.

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • Thanks so much for your quick reply. I will definitely try it this way.

  • I thought that each server had to have its own key that is unique to the machine. We have a dev server with reports, and now want to place on prod server. In addition, I was creating the initial reports using SSDT-BI and deploying to the dev server. We have two web interfaces - one for dev and one for prod (2 ssrs setups), each pointing to their respective databases (dev and prod).

    I want to move folder structures , reports, datasets, datasources, etc over to prod machine. I was going to try backing up dev db and restore on prod db. I have previously backed up ssrs encryption keys on both dev and prod machines. Question: do I have to also backup transaction logs? Do I just restore encryption key by pointing to the prod key I had backed up previously?

    I want the end result to be: having both dev and prod servers, each with copies of the same reports, report folders and deploying first to dev, have user test, then deploy to prod. Am I thinking of this correctly?

  • jxj363 (9/29/2015)


    I thought that each server had to have its own key that is unique to the machine. We have a dev server with reports, and now want to place on prod server. In addition, I was creating the initial reports using SSDT-BI and deploying to the dev server. We have two web interfaces - one for dev and one for prod (2 ssrs setups), each pointing to their respective databases (dev and prod).

    I want to move folder structures , reports, datasets, datasources, etc over to prod machine. I was going to try backing up dev db and restore on prod db. I have previously backed up ssrs encryption keys on both dev and prod machines. Question: do I have to also backup transaction logs? Do I just restore encryption key by pointing to the prod key I had backed up previously?

    I want the end result to be: having both dev and prod servers, each with copies of the same reports, report folders and deploying first to dev, have user test, then deploy to prod. Am I thinking of this correctly?

    if your reports are REPLACING, completely, the reports on production, then the restoration of the encryption key plus restoration of the databases is perfect.

    the encryption key just sets the per-server logic for encrypting connection information, ie, if a report had a datasource featuring explicit credentials for the user [ReportReader], the password is encrypted in a way unique to the server. export the encryption key,and restore it,and then both servers decrypt the same way. otherwise you end up with broken reports, where you have to re-enter the credentials for the data sources.

    I change my ReportServer databases to use simple recovery mode...they change so rarely, that i'd spin off an extra backup if i was migrating them to another server, rather than restoring full/tran or full/diff sets

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • Thank you for your help. From comparing what you presented and some MS documentation, I believe I now have a clearer picture. I always thought of the restore as happening only for the db on the current machine, but now see that after moving db over, would have to use encryption key of machine that the db was originally on. Restoring appears to use the key to create another key. I made sure to backup the encryption key again - this time on the new machine, after the restore occurred.

    I did the following, which worked:

    1. Backed up dev db (copy only), and made sure the encryption key for was backed up

    2. copied backup over to prod server so could use

    3. stopped reporting Server instance, restored prod db with backup taken, and re-started Reporting Server instance

    4. Opened SSRS Config Mgr on prod server & restored using the key I had backed up from dev. I did get the following error:

    Microsoft.ReportingServices.WmiProvider.WMIProviderException: The feature: "Scale-out deployment" is not supported in this edition of Reporting Services. (rsOperationNotSupported)

    As we don't use Enterprise Edition, this is rather strange. However, the dev server happened to be joined as well as the prod server when I looked at the Scale-out-Deployment page of the config mgr. I removed dev and afterwards was able to restore.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply