Ssrs 2014 migration to 2016.

Question

Ssrs 2014 migration to 2016.

SilentOne

Ten Centuries

Points: 1325
More actions
April 19, 2017 at 9:43 am

#329573

Hi,
I'm trying to migrate a 2014 Ssrs solution to Ssrs 2016, and had got to the point I felt we were ready to swap to the new migration and we started getting errors relating to failed decryption.
I followed the migration steps from Microsoft and the errors always return/persist.
The steps I took were:
1. Backup and restore original databases
2. Backup encryption key
3. Install Ssrs 2016 on new server with managed service account.
4. Restore databases and remove server key entry from key table in the report database.
5. Configure Ssrs 2016 to look at new restored databases on same new instance.
6. Restore keys from backup.
The errors I see are:
Microsoft.ReportingServices.Portal.WebHost!crypto!3!04/19/2017-15:04:11:: e ERROR: Decryption failed, Current user: SSRS$ : System.Runtime.InteropServices.COMException (0x80090005): Bad Data. (Exception from HRESULT: 0x80090005) at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo) at RSManagedCrypto.RSCrypto.DecryptData(Byte[] pCipherText, Boolean useSalt) at Microsoft.ReportingServices.Diagnostics.SymmetricKeyEncryption.Decrypt(Byte[] data, Boolean useSalt)Microsoft.ReportingServices.Portal.WebHost!crypto!7!04/19/2017-15:04:11:: e ERROR: Decryption failed, Current user: SSRS$ : System.Runtime.InteropServices.COMException (0x80090005): Bad Data. (Exception from HRESULT: 0x80090005) at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
I must be missing something because i've done this for previous instances without issue.

Viewing 13 posts - 1 through 12 (of 12 total)

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

Sue_H SSC Guru Points: 90860 More actions · Answer 1

If you did it previously without problems you would have managed the process with the key differently.
Backup the key on the original - your case SSRS 2014 - server. Remember the password.
Backup the databases on the original server.
Restore the databases on the new server.
Restore the encryption key you backed up from the original server using Report Server Configuration Manager on the new server.

Sue

SilentOne Ten Centuries Points: 1325 More actions · Answer 2

Thanks, exactly what i've done a few times over to be sure. At least I can rule out a mistake in my understanding of how this should work.

The only things that stick out in my head is we are using a managed service account and windows server 2012.

Mgoing to try a new install and import the objects via powershell.... if it's possible.

Sue_H SSC Guru Points: 90860 More actions · Answer 3

You shouldn't delete the key at all though. Just restore the key on the new server from the original backup that you took on the old server. And do both the backup and restore using each ones Reporting Services Configuration Manager.

Sue

SilentOne Ten Centuries Points: 1325 More actions · Answer 4

Okay, so I tried uninstalling SSRS 2016 and reinstalling, backup DB + key, restore... etc, and SSRS worked until I tried to configure Subscriptions.

Specifically, from the moment I added an SMTP relay for the subscriptions I started getting errors when I viewed data sources. The error I get isn't helpful:

"An error has occurred. Something went wrong. Please try again later."

The last error in the log is:

"Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: Invalid PBI Configuration, Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. ;"

But this is a PowerBI integration which we don't use nor have configured, but looking at the time stamp this could be causing the issue.

Sue_H SSC Guru Points: 90860 More actions · Answer 5

The fairly useless "Something Went Wrong" error when using a new install of Reporting Services can often just happen from configuration issues. You'd probably want to look for earlier error messages in the log. But you would want to really make sure your setup is correct. Open up Report Server Configuration Manager, go through each of the pages and check the configurations, make sure the service account is set up correctly, add the unattended execution account, double check your settings on the old server and make sure it's all covered.
Make sure the service account is configured correctly - double check with this article:
Configure the Report Server Service Account (SSRS Configuration Manager)

Another thing to check - If the error is when you view the properties or other pages for the Data Source, go through the log and you should be able to see where you are accessing the data sources. You can try one in particular data source in Report Manager and don't do anything after you get the error. Then search for that Data Source name in the log and see what errors you have just after accessing that. Not easy to find but you can do something like go to to the end of the log and search up for the Data source name. That can get you closer to the error.

Sue

Mr. Brian Gale SSC-Insane Points: 24690 More actions · Answer 6

If you are not using Enterprise Edition, you should check the ReportServer.dbo.Keys table. Actually, even if you are using enterprise edition, might not hurt to check that. Standard will fail to let you connect if more than 1 real machine name is in there. I have a null row and 1 row with my server in it.
I had odd issues with mine but it was due to having the old and new server data sitting in there. Deleted the row for the old server and things started playing nice again.

Make sure to back up that table first because the last thing you want is to make things worse.

The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

SilentOne Ten Centuries Points: 1325 More actions · Answer 7

bmg002 - Wednesday, April 19, 2017 4:20 PM
If you are not using Enterprise Edition, you should check the ReportServer.dbo.Keys table. Actually, even if you are using enterprise edition, might not hurt to check that. Standard will fail to let you connect if more than 1 real machine name is in there. I have a null row and 1 row with my server in it.
I had odd issues with mine but it was due to having the old and new server data sitting in there. Deleted the row for the old server and things started playing nice again.
Make sure to back up that table first because the last thing you want is to make things worse.

Thanks for the tip, we are using standard and I had removed the old server name from the ReportServer.dbo.Keys table.

SilentOne Ten Centuries Points: 1325 More actions · Answer 8

Sue_H - Wednesday, April 19, 2017 2:46 PM
The fairly useless "Something Went Wrong" error when using a new install of Reporting Services can often just happen from configuration issues. You'd probably want to look for earlier error messages in the log. But you would want to really make sure your setup is correct. Open up Report Server Configuration Manager, go through each of the pages and check the configurations, make sure the service account is set up correctly, add the unattended execution account, double check your settings on the old server and make sure it's all covered.
Make sure the service account is configured correctly - double check with this article:
Configure the Report Server Service Account (SSRS Configuration Manager)
Another thing to check - If the error is when you view the properties or other pages for the Data Source, go through the log and you should be able to see where you are accessing the data sources. You can try one in particular data source in Report Manager and don't do anything after you get the error. Then search for that Data Source name in the log and see what errors you have just after accessing that. Not easy to find but you can do something like go to to the end of the log and search up for the Data source name. That can get you closer to the error.
Sue

Thanks for the link to the service account permissions this was the first thing I had in mind to read/find this morning (UK). Last night I also tried changing the authentication type from NTLM to basic as recommended by a MS employee in an article I found which still failed but provided the following message:

Windows returned a ERROR_ACCESS_DENIED error when Reporting Services attempted to call the Windows Authz APIs

We are using a domain managed service account, rather than a standard domain user account and so I'm going to try using a standard domain account instead and see if that helps.

alexmilner008 SSC Rookie Points: 47 More actions · Answer 9

I have discovered that the SQL commands which have been illustrated in this article are very advanced. These are the kind of commands which are very nice and relevant in SQL programming. I have loved every bit of the post. It is indeed very educative.ProjectReview and Editing Help

Sue_H SSC Guru Points: 90860 More actions · Answer 10

So it is an issue with the account but I think it's more likely that you might be hitting a bug with it that was fixed in SP1. Have you applied that yet?

Sue

SilentOne Ten Centuries Points: 1325 More actions · Answer 11

Sue_H - Thursday, April 20, 2017 6:51 AM
So it is an issue with the account but I think it's more likely that you might be hitting a bug with it that was fixed in SP1. Have you applied that yet?
Sue

Sue, thanks for all your help. It turns out it was a problem with the account. Our IT created the managed service account with a typo, and rename it. This is appears caused AD authentication issues.

Switching to basic authentication caused SSRS to log the error, then we did a lot of different tests to provide a solid understanding of the symptoms and decided that creating a new managed service account would be a good test which ultimately resolved the issue.

I did check the SP level earlier because I saw a description of a bug that was fixed with SP1 that sounded plausible but we are on the latest SP.

Thanks again.

Sue_H SSC Guru Points: 90860 More actions · Answer 12

Yup, messing up the naming of the account and renaming probably causes the same problems with the permissions with the SIDS as the issue that is fixed in the service pack. Glad you got it fixed - thanks for posting back.

Sue