Protection Level for SSIS Packages are missing

  • Hello  Everyone

    I have SQL server 2019 with CU8 and Visual Studio 2019

    I was given the packages from the data scientist and when i was looking at them i found that the Protection Level information was missing from the package properties window. Even the security section which holds the protection level is missing.

    Anyone have any ideas? Were these packages setup incorrectly?

    I noticed he used project level connection managers which didnt allow me to deploy the packages to the SSIS catalog so i converted those to package level connection managers but thats not the issue here.

    Did anyone ever face this before?

    regards

    Kal

  • What problem does this cause? Can't you just set the protection level manually?

    Was the package developed in 2019, or could there be versioning issues?

    If the original developer used project-level connections, they should have sent you the entire project, not just a few packages from it ... poor!

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • Hi Phil

    The whole project was given to me but when I click on properties for any of the packages the security section is missing completely.

    It’s there when I check the project properties but it is not there in the package properties.

    how could they just disappear?

     

    Kal

  • Sorry, but I really have no idea. Never seen anything like that.

    But if you are opening the .sln, you should not be having a problem with the project-level connections, so it does seem odd.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • I’ll send a snapshot in a couple of hours.

    I even tried to create a new project and even the control flow properties didn’t show the protection level.

    strange?????

     

    Kal

  • Hi Phil

    Sorry for the delay i created a new project and made a new package and surprisingly that the security section is missing.

    please see the attachment. What can cause this?

     

    Kal

    Attachments:
    You must be logged in to view attached files.
  • You are displaying the properties for a data flow task.

    Instead, click on a blank area on the Control Flow window and you should get the properties for the package.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • Live and learn

    I found it so thats where it was hiding

    Do the projects and packages have to have passwords set before you can deploy them on the SSIS catalog and create jobs in the SQL server agent to run these packages?

     

  • No. I suggest you change the protection levels on the project and all its packages to DontSaveSensitive.

    If you need to pass sensitive info into the packages at runtime, use Sensitive parameters & configure them in an SSISDB environment.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • Per our CISO we have to set the protection level to EncryptAllWithPassword

    We are using SSIS packages just to move data from one table to another and it contains meter reading production data which will be finally sent to the PowerBI Service in the form of a dashboard.

    You still recommend DontSaveSensitive?

     

    Kal

  • hurricaneDBA wrote:

    Per our CISO we have to set the protection level to EncryptAllWithPassword

    We are using SSIS packages just to move data from one table to another and it contains meter reading production data which will be finally sent to the PowerBI Service in the form of a dashboard.

    You still recommend DontSaveSensitive?

    Kal

    It's what I've used for years and has the following benefits:

    1. No sensitive data ever gets checked in to source control, because all passwords and the like are held as sensitive params and assigned from SSISDB environments.
    2. All developers can maintain SSIS projects without the need for passwords.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

Viewing 11 posts - 1 through 10 (of 10 total)

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