SQLTeam.com | Weblogs | Forums

Done messed up my SSRS


Changed the Reporting services service to use a dedicated AD service account.
Then changed the Report Server configuration to use that same account.
Did both of these without backing up the encryption key

restarted everything and now I am having issues uploading new reports or making changes to subscriptions and permissions. Is my Reporting service hosed and resintall from scratch or can I roll back some of my changes and restore from backup?


I think you can reset everything with a new encryption key - but before doing that try changing everything back to what it was originally.

From Reporting Services Configuration Manager - try backing up the key, and restoring it. If that doesn't work - try changing it...and if that doesn't work you can try deleting (if you do this, you have to reset all encrypted data which could be problematic).

BTW - what is driving the requirement to run Reporting Services with a dedicated AD service account? This is one area where it isn't necessary - in fact, I would recommend against doing that - because you can defined the execution account to that service account to get the level of permissions needed.

1 Like

Thanks @jeffw8713 I will try those. What do you mean by changing it?

There is no specific requirement to have the service run with a dedicated AD service account. i can revert it back to what it was : NT Service or something like that.

Also within the Reporting Service Configuration panel which account is it recommended to use. Previously it was some Virtual xyz

I think it might be time for us to migrate to 2019 anyways.


You have the option here to change the encryption key - this should reset all encrypted data. You also have the option to delete - but if you do that you have to manually update all connection strings, credentials and subscriptions (which is a pain if you have embedded data sources and lots of subscriptions).

You can define an Execution Account - that account will then be used for external access to resources, which is normally why you would set the service to use a domain account. This allows for using the built-in NT SERVICE\ReportServer account for reporting services service and leaves that account with minimal permissions at the OS level.

Change the account back and restart - see if that fixes the issue. If it does - then just define the execution account to be that domain account.

duh, guess I should have scrolled down. hey @jeffw8713 maybe I should move to python :slight_smile: and create all them SSRS widgets

Thanks sir let me try that out.

I did all recommended setting changes. now I am seeing a new error which might not be SSRS related
in my browser network tab:

a POST to api/v1.0/catalogitems which errors out

Status Code: 503 Service Unavailable

Verify the service is actually running - it looks like something isn't running now.

And yes, you can move the Python and hand-build all of the HTML5 coding to display the data exactly as you want :slight_smile: :grinning:

let me get back to you in 5 years...if not I will go back to SSRS :slight_smile:

ok I think this reporting server is hosed. going to redeploy to a new one


1 Like

well this new issue seems to be related to a VIP being down. which could have been the whole issue to begin with :frowning:


Thanks @jeffw8713 I spun up a new instance on same server + Reporting services, restored db, deleted encryption, re-added all connection strings, stopped previous reporting service, used same configs for new reporting service and VOILA!