SSISDB Error: The current master key cannot be decrypted

I had to move the SSISDB database f rom server1 to Server2

On Server 1 I did the following
Backed up the master key
USE SSISDB


BACKUP MASTER KEY TO FILE = 'C:\MSSQL\Keys\SQLSVER1_key'
ENCRYPTION BY PASSWORD = 'oldpassword'


Backed up the SSISDB database .

Copied the key and the back up file to  server2

On server2 I did the following
Restored the SSISDB
Restored the master key as follows
USE SSISDB


RESTORE MASTER KEY FROM FILE = 'V:\MSSQL\Keys\SQLSVER1_key'


DECRYPTION BY PASSWORD = 'oldpassword'


ENCRYPTION BY PASSWORD = 'newpassword'


But ran into an issue where it threw the error  -
The current master key cannot be decrypted. If this is a database master key, you should attempt to open it in the session before performing this operation. The FORCE option can be used to ignore this error and continue the operation but the data encrypted by the old master key will be lost.

I ran  the script again with the FORCE option

USE SSISDB


RESTORE MASTER KEY FROM FILE = 'V:\MSSQL\Keys\SQLSVER1_key'


DECRYPTION BY PASSWORD = 'oldpassword'


ENCRYPTION BY PASSWORD = 'newpassword'
FORCE

That did not work, still got error

Solution: I had copied the keys to a folder where SQL SERVICE account did not have r/w permissions. Copied the key to the folder where the permission was already setup and rant the script with the FORCE option  and it worked!   

Work adventure: I/O error 21(The device is not ready )

We had an error all of a sudden on our sql server

"Microsoft OLE DB Provider for SQL Server:
I/O error 21(The device is not ready.) detected during read at offset 0x0000a7a239c000 in file 'DataFileName'.
- HY000 - HRESULT=0x80004005 “

Since the error message mentions that the drive on which one of the data file resided was not ready, it was obvious that the underlying storage was the problem.
But the System Event Log did not have any error messages related to storage. The database was online and accessible. But when I  tried accessing the Properties of this database, the same error was thrown.


The reason for this error was not something that happened at that time. Another email chain from the Windows Administrators sent a few hours ago said it all. They had found that the drive letter associated with the Mount Point hosting this data file was missing and they had *mapped* it somehow. Not sure how they had done the drive mapping. Most likely the drive hosting this data file got disconnected while the database was online.


I fixed this by bringing the database offline and back online after few seconds

ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE
ALTER DATABASE <dbname> SET ONLINE