I'm trying to open a password protected package in SQL Server BIDs and I keep getting the following error message each time I pu in the correct password:
Failed to remove package protection with error 0x80131940 "(null)"
This occurs in the CPaqckage::LoadFromXML method.
Any Ideas?
I ran into the same problem and discovered that caps-lock was on. Typing the correct password with caps-lock on gives the error message "Failed to remove package protection with error 0x80131940 "(null)", whereas typing the wrong password gives the "The password you have entered is incorrect" message. Very misleading but simple to fix.
I believe you thought you had the right password but that you really didn't.
I recently ran into this problem. I know you posted a long time ago but I could not find an answer when I ran into the same situation. Turns out I had the wrong password when I thought I had it right (I was not the one who created the package).
I had assumed that since some wrong passwords produced a wrong password error message that I must have had the right password with the one that did not produce a wrong password message - it turns out that different wrong passwords can return different error messages when opening a password encrypted SSIS package!
Very odd. At any rate, after finally getting a hold of the original developer, and getting the correct password, I was able to open the package just fine.
For what its worth I would never recommend encrypting the whole package with password, sensitive data maybe, but not the entire package.
I just received the same error. My issue was targeting SQL Server 2017 instead of SQL Server 2016 (Project > Propertied > Configuration Properties > General > Deployment Target Version > TargetServerVersion)
I got this message running a package built on vs 2017 enterprise on my laptop. In this situation people always fuss about your password. If you can get into the package with visual studio, you know your password. I was setting encryptAllWithPassword at the solution and package level. It was only failing with this message on my laptop as dtexec. When I moved the package to azure it ran with the /DECRYPT statement. So if you're only testing in one environment and it fails, try it in another environment (azure or server environment) and it might work.
Related
I have created a new SQL Database on Azure, and have copied the connection string directly from the Azure Portal.
On my .NET application, when I am trying to run 'Update-Database' command in Package Manager Console to commit the migration, I receive the following error:
Error Number:18456,State:1,Class:14 Login failed for user
'benhayward'.
Extra Information:
- I have changed my database admin password.
- I have confirmed that the log-in credentials are correct.
- I am on the Azure free trial.
Any advice or assistance on this would be greatly appreciated.
Ok a slightly embarrassing solution, but the reason this wasn't working is because of the curly brackets surrounding the password, as LeonYue suggested.
I had the same issue. The problem was that I had two entirelly different connection strings with the same name in different config files. The right one in app settings was being overwritten by another connection string in my user secrets. As soon as I deleted connection string from my secrets, everything went fine without any errors. Hope my solution will help the others
I've created a package that gets some information from a sql database and inserts them into Dynamics CRM.
When testing the package from Visual Studio everything goes as expected and the task finishes without any errors and the rows get inserte . However , when I publish the package to SSISDB on Sql Server the package fails with this error :
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException : CRM service call returned an error : A password is required in order to establish the connection ...
I tried changing the package protection level to EncryptSensitiveWithUserKey but it still gives the same message as above , created the package again from scratch still doesn't work . This package was working before , maybe there's something I did the last time in configuration which made it work but I cannot replicate it anymore .
Also I tried the Integrated Authentication it says this :
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException : CRM service call returned an error : The caller was not authenticated by the service .
#Drinv, this is a typical SSIS runtime deployment issue. You need to make sure that you have provided a password for your job configuration for the connection manager. What you provided to the package doesn't count as far as sensitive fields are concerned (password being one) when you are using the EncryptSensitiveWithUserKey option since user key is not transferrable between different systems or different users. An easy workaround is to change your SSIS package/project's ProtectionLevel setting to encrypt using a password instead, although it may not be the best practice. If you still have trouble getting this going, please reach out to us directly, our team can walk you through the issue.
I found out what I was doing wrong .
My SSIS project was on Project Deployment Model and I was trying to deploy only the package. After making my connections available on project level and deploying the whole project everything worked as expected .
I have created an SSIS package (08) that has a script task which runs an SSRS report (08) with given parameters. The report creates a pdf version of the file on a file share drive of my choosing.
When I run the SSIS manually it works perfectly, however, when I upload SSIS into SQL and then run it from the job agent it fails. It gives a long error message but the basic piece is;
(0xC0016016 Source: Description: Failed to decrypt
protected XML node "DTS:Property" with error 0x8009000B "Key not valid
for use in specified state.". You may not be authorized to access
this information. This error occurs when there is a cryptographic
error. Verify that the correct key is available. End Error
Error: 2018-01-15 16:09:58.28 Code: 0xC001600C
Source:
PackageSchedule Connection manager "ReportServer08"
Description:
Server authentication failed. This error occurs when login credentials
are not provided, or the credentials are incorrect. )
I have tried to change the "ProtectionLevel" to "EncryptSensitiveWithPassword" and also "Donset upSensitive".
I setup a subscription to the report just to make sure it wasn't a read/write error to the specific folder and the subscription ran without error as well.
Any help on this would be greatly appreciated.
According to this SO answer the issue was related to a date type issue. You could be experiencing the same thing
Thank-you for the feedback. I was able to figure it out. On Import of the package to SQL itself I changed the 'Protection Level' to 'Rely on server storage and roles for access control'. This allowed the job to execute successfully and everything looks great!
I have created a project level sql-server connection for my SSIS project. There are multiple packages which utilise this connection and it works perfectly fine. However, I have a new package which contains an "Execute SQL Task". This task also utilises the same connection but throws an error saying "login failed for user".
It might be one of these things:
The Protection level property that is set to DontSaveSensitive, meaning the password doesn't get saved. You can choose to change it to EncryptSensitiveWithUserKey. Although I wouldnt suggest this when you deliver the project to Deployment server
If you are using package configuration and saving the connection string to a XML File (for example) the password won't get saved, you have to add it manually. Something like: ;Password=someReallyCoolPassword;
Even if you do at the password manually, it can still have some problems. I believe it can be that the word "Password" is sensitive itself, and even if you have protection level as DontSaveSensitive, when the package read the XML File, it wont read the password value. I have no idea why, but have to put a blank space before Password, like this: ; Password=someReallyCoolPassword; and it will work, although your connection could be seen if someone hover the mouse over the connection manager.
If you could add more information about how you are handling your connection, I could give you a mroe specific answer
I'm getting this error when running an SSIS package through SQL Agent
Failed to acquire connection "ORACLE ADO.NET". Connection may not be configured correctly or you may not have the right permissions on this connection.
When I log on as the SQL Agent User and run the ssis package directly it is fine. When I then execute it through the SQL agent job, it fails.
I've read around extensively on this topic, and it seems a lot of the advise concerns how you are logged in, configuring of proxy accounts, etc, etc, etc, none of which has been helpful.
I am logging onto an Oracle database with an ADO.NET conncetion. The connection string is as follows (datasource, userid and password have been changed):
Data Source=DATASOURCE;User ID=userid;Password=password;Persist Security Info=True;Unicode=True;
I'm loading this from a registry setting using package configuration. To check that I am getting the correct string, I am writing it into a temporary log table. I am definately getting the string I need from the correct registry setting.
I've tested the oracle login credentials though PL/SQL developer, and it lets me login just fine.
As far as I can tell, as I'm using an explicit user name and password for the Oracle connection it just shouldn't matter who the SSIs pacakge is run as. The only point of failure that Ican see would be the reading of the information from the registry, but that seems fine.
I'm really quite baffled, I must confess, and would appreciate any help some of the splendid experts here can offer.
Many thanks,
James
Ok, tracked this one down after quite a lot of pain.
It was working fine on one environment, but not another, so I fired up Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and ran a package through the SQL Agent job, comparing which system entities were hit on each enviroment.
On the failing environment, at the point of the bulk transfer operation, the package attempted to get the Oracle 11 client DLL, and then hung.
I knew that this was installed, and, moreoever, the DLL path was a system environment setting. After further investigation it was revealed that the server had not been rebooted since the Oracle Client install and the SQL Server Agent process had not bee recycled.
Yes, can you believe it, the old helpdesk fix "Can you reboot your computer?" worked.
Sigh!
We had issues at a client with running packages connecting to Oracle before stored on our sql server instance. The work around we found was to change the package property, protection level, to "Dont save Sensitive Data" and for security purposes, we encrypted the username and password in the package configuration that was decrypted by a udf in sql server. Of course, before you try the whole encryption part, I would recommend putting the username and password in the package configuration without encrypting the values to see if changing the protection level setting is the solution to your specific problem. I hope this helps.
I was getting this error when tnsnames.ora file did not have a valid entry for the environment