June 26, 2017 at 11:56 am
Whenever I attempt to create a new job and add a step with a SSIS encrypted (with the Protection Level of EncryptAllWithPassword) package, I receive the following error:
Failed to remove package protection with error 0x80131430 "(null)". This occurs in the CPackage::LoadFromXML method.
I am confident that I know the password and am typing it correctly because I can open the package in VS.
I receive the same error:
As a test, I changed the Protection Level to DontSaveSensitive, and it worked just fine. Of course, I need to have the package encrypted.
Has anyone seen anything like this before?
June 26, 2017 at 3:17 pm
What version are you using? If it is 2012 or above - you should change your deployment model to use the Integration Services Catalog. Using that model you don't need to worry about encrypting the password as you can set it in the catalog - and it is exposed in SQL Server Agent to be changed/updated there...
If you are on 2008 R2 or below (or for some reason you must use this model) - then deploy your package with the Package Protection Level set to 'Rely on server storage and roles for access control'. This protection level will save the SQL username and password securely in the package on the server.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
June 29, 2017 at 6:18 am
Just to follow up on this in case anyone happens to have the same issue.
In response to using the Integration Service Catalog: That might have worked and it was something that wasn't tried. But for us, it was not ideal. (Without going into a lot of detail, let me simply say that the current operating structure / environment limits the practicality of this.) Nonetheless, thank you. I appreciate the idea.
For us, we ultimately traced the issue back to Visual Studio. We had an opportunity to copy/run the same package on a different server and received the same error. If we used a different install (on a different computer) to create the packages, the issue went away. The odd thing is that VS never gave any errors and appeared to be completely functional.
Thanks again for your help, Jeffrey
June 5, 2018 at 10:50 am
Thanks! You're absolutely right about the versions. We all upgraded our Data Tools to Sql Server 2017, but our sql servers are all still 2016. When I changed the Project properties TargetServerVersion to SQL Server 2016, I was able to put passwords back onto my SSIS packages.
Most other posts I read kept referring to permissions.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply