I've run into an interesting issue when trying to deploy SSIS packages that leverage project level DQS connection managers.
We're able to deploy SSIS projects and run the SSIS packages to our development environment just fine and run them with no issues. But when trying to deploy the exact same projects to our test environment, the deploy constantly fails at the same point: changing protection level.
After double and triple checking that the package protection level is the same as the project protection level, I decided to try removing the project level DQS connection manager and replacing it with a package level DQS connection manager. Voila! Deployed just fine with no issues.
I'm at a complete loss as to why 1.) the same project(s) deploys fine to one server and not another, and 2.) why a DQS connection manager would have anything to do with the protection level??
I know when deploying to a catalog, it changes the protection level to storage, but again, not sure what a connection manager has to do with that.
The only difference I can see between the two servers are the versions.
The server which has no deployment issues is at 14.0.3029.16
The server that is having issues is at 14.0.3035.2
Apparently 3035.2 is a security update meant to address a security flaw:
https://support.microsoft.com/en-us/help/4293805/security-update-for-remote-code-execution-vulnerability-in-sql-server
After reading this, I still don't see where this would impact deploying SSIS packages with a DQS connection manager.
We'd be fine with using a project level connection manager, but we have two DQS servers and package level connection managers don't travel well between environments.
If anyone has any insight into this or has seen this, please feel free to comment!
Thanks!
A. M. Robinson