My office just migrated from SQL Server 2008R2 to SQL Server 2017. We converted just under 100 SSIS packages to the 2017 format. We have many of these being triggered by SQL jobs. The large majority of these are running fine after the migration. However, we have a handful (maybe 10) that are sometimes failing with an invalid signature error. For those that are failing, I am not even seeing a consistent 100% failure rate.
Why are the packages failing intermittently with this error?
Below is an example of the full error text. One of the example packages was deployed to 4 different servers, and it runs fine on 3 of them. The only difference between the 4 versions is the path to the dtconfig file. We did not change anything about the jobs that call the packages.
I tried re-deploying the failing package for that example that I just mentioned, but it will still fail intermittently with an invalid signature error. In addition, I had our IT department confirm that the user under which the jobs execute has permissions to read the dtsx file.
Executed as user: domain\username. Microsoft (R) SQL Server Execute
Package Utility Version 14.0.3045.24 for 64-bit Copyright (C) 2017
Microsoft. All rights reserved. Started: 6:30:00 AM Error:
2018-12-18 06:30:00.82 Code: 0xC0011007 Source:
{5576F0C1-D470-418D-8FAB-9700612AEF76} Description: Unable to
load the package as XML because of package does not have a valid XML
format. A specific XML parser error will be posted. End Error Error:
2018-12-18 06:30:00.82 Code: 0xC0011002 Source:
{5576F0C1-D470-418D-8FAB-9700612AEF76} Description: Failed to
open package file "\\servername\sharename\mypackage.dtsx" due to error
0x80090006 "Invalid Signature.". This occurs when loading a package
and the file cannot be opened or loaded correctly into the XML
document. This can be the result of specifying an incorrect file name
when calling LoadPackage or the specified XML file has an incorrect
format. End Error Could not load package
"\\servername\sharename\mypackage.dtsx" because of error 0xC0011002.
Description: Failed to open package file
"\\servername\sharename\mypackage.dtsx" due to error 0x80090006
"Invalid Signature.". This occurs when loading a package and the file
cannot be opened or loaded correctly into the XML document. This can
be the result of specifying an incorrect file name when calling
LoadPackage or the specified XML file has an incorrect format.
Source: {5576F0C1-D470-418D-8FAB-9700612AEF76} Started: 6:30:00 AM
Finished: 6:30:00 AM Elapsed: 0.016 seconds. The package could not
be found. The step failed.
A co-worker found a solution that worked for us. We had to update the SQL Server jobs that called the SSIS packages. Instead of referencing UNC paths, these jobs are now referencing local paths. After making this change, we are no longer seeing the errors.
The same job definitions were working under SQL Server 2008R2. However, we did also update our server OS version at the same time, so perhaps that was a factor as well.
Related
Can anyone help, I have a SQL table built in my database that feeds from an excel file that will be regularly updated. I got it working fine, but I need the data in SSMS to be updated upon refresh (ie: fetch the latest from the excel file).
I have created a dtsx file which I believe is what I need in order to update, but when I go to execute on SSMS I get this error message:
The job failed. Unable to determine if the owner (DESKTOP-DACFOFI\chris) of job UpdateCSKASubs has server access (reason: Could not obtain information about Windows NT group/user 'DESKTOP-DACFOFI\chris', error code 0x534. [SQLSTATE 42000] (Error 15404)).
I saw on other forums that the solution was to change Owner to "sa", but that gave me this error message:
Executed as user: NT Service\SQLSERVERAGENT. Microsoft (R) SQL Server Execute Package Utility Version 15.0.2000.5 for 64-bit Copyright (C) 2019 Microsoft. All rights reserved. Started: 16:03:36 Error: 2021-04-03 16:03:36.61 Code: 0xC0011007 Source: {122CA6EC-6AEA-452B-95FC-516979E12E61} Description: Unable to load the package as XML because of package does not have a valid XML format. A specific XML parser error will be posted. End Error Error: 2021-04-03 16:03:36.62 Code: 0xC0011002 Source: {122CA6EC-6AEA-452B-95FC-516979E12E61}
Description: Failed to open package file "C:\Users\chris\Google Drive\CSKA\ImportFromExcel.dtsx" due to error 0x80070005 "Access is denied.". This occurs when loading a package and the file cannot be opened or loaded correctly into the XML document. This can be the result of specifying an incorrect file name when calling LoadPackage or the specified XML file has an incorrect format. End Error Could not load package "C:\Users\chris\Google Drive\CSKA\ImportFromExcel.dtsx" because of error 0xC0011002. Description: Failed to open package file "C:\Users\chris\Google Drive\CSKA\ImportFromExcel.dtsx" due to error 0x80070005 "Access is denied.". This occurs when loading a package and the file cannot be opened or loaded correctly into the XML document.
This can be the result of specifying an incorrect file name when
calling LoadPackage or the specified XML file has an incorrect format.
Source: {122CA6EC-6AEA-452B-95FC-516979E12E61} Started: 16:03:36
Finished: 16:03:36 Elapsed: 0.016 seconds. The package could not be
found. The step failed.
When you run it as sa, the error message indicates that the SQL Agent process cannot access a package in your user space.
To resolve that, deploy the package to somewhere the sql agent can access. The DTS Package Store is likely as good as any. Your error message indicates "SQL Server Execute Package Utility Version 15" so v15 is also SQL Server 2019 so copy the file to
C:\Program Files\Microsoft SQL Server\150\DTS\Packages
Unless you need to run it in 32 bit mode, then copy to (I think - it's been a long while since I've dealt with file system deploys)
C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Packages
Depending on whether the Excel file is a local or network resource, you might then run into an issue with connecting to the UNC/mount path but that'll be an artifact of how you have SQL Server/Agent and the job (credentialed user?) set up.
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!
My SSIS Package works, but fails as a SSMS job (Error: 0xC0016016)
I am posting this question and sharing my solution to this issue as my own question because I didn't see the posed problem match the specific issue I encountered and the answers seemed to be scattered in different forum questions.
Background:
I have four SSIS packages on SQL Server 2012 that import a table from SQL Server 2008 R2, 2008, or 2005, depending on the specific package. I use a designated sql server login and password for the source database and integrated Windows security for the target database.
Within SSIS I am able to run each package without a problem.
To ensure this package ran on a schedule, I set up a SSMS job on the same server as the SSIS package. In Job step properties, I chose: SQL Server Integration Services Package > run as SQL Sever Agent Service Account > Package source: File system).
The Symptom:
When manually running the job to make sure it worked, I got an error and saw this in the Log File Viewer. This was the first of several errors, but as this was chronologically the first error, I looked into this one first.
Error: 2014-10-24 09:52:34.48
Code: 0xC0016016
Source: [Redacted -- the correct name of the table I was importing]
Description: Failed to decrypt protected XML node "DTS:Password" 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
I looked up the error code on Google and started looking at resolutions. Rather than retelling how I found the bits and pieces of the resolution, I am presenting an actionable result in sequence -- at least for me and the network infrastructure I'm working with.
In the "properties" panel of the SSIS solution (do this first) and each package in that solution, reset the "ProtectionLevel" attribute to EncryptSensitiveWithPassword and set a password. The package passwords must match the solution password.
Just a double-check, run your packages in debug mode to make sure that no other new issues arise. In my case, I needed to re-enter the sql server password for the source server database.
Rebuild your SSIS solution.
In SSMS, open your job and open the job step properties for the task in question.
Select the "Command Line" tab. A "Package Password" popup appears. Enter the password that you entered in step 1.
Select "Edit the command line manually" and place the same password from step 1 immediately after /DECRYPT.
Repeat steps 4-6 for each job step that runs this type of package.
Press the "OK" button and re-run your job.
I was able to run my job successfully after that.
I have built an SSIS Packaage that imports data on a daily basis.
i have tested it in BIDS and it runs fine, i have deployed it to the the SSIS server and it runs fine, but when i schedule it to run as a job it Errors out. i get the errors below. i've added the srvSQLagent account to the the correct group to have access to the folder that causing the problem.. am i missing something stupid here?
===================================================================
Date 03/07/2013 14:55:06
Log Job History (Import SN2 Data)
Step ID 1
Server STX-RPT
Job Name Import SN2 Data
Step Name Run Import Package
Duration 00:00:09
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
Executed as user: INT\srvSQLagent. Microsoft (R) SQL Server Execute Package Utility Version 10.50.1600.1 for 32-bit Copyright (C) Microsoft Corporation 2010. All rights reserved.
Started: 14:55:06
Error: 2013-07-03 14:55:15.69
Code: 0xC001401E
Source: Servicenet Data Import Connection manager "Downloaded"
Description: The file name "\\FILE\Groups\ISG\England\Servicenet Data\Downloaded" specified in the connection was not valid. End Error
Error: 2013-07-03 14:55:15.69
Code: 0xC0202070
Source: Servicenet Data Import Connection manager "Downloaded"
Description: The file name property is not valid. The file name is a device or contains invalid characters. End Error
Error: 2013-07-03 14:55:15.69
Code: 0xC0029163
Source: File System Task File System Task
Description: File or directory "\\FILE\Groups\ISG\England\Servicenet Data\Downloaded" represented by connection "Downloaded" does not exist. End Error
DTExec: The package execution returned DTSER_FAILURE (1).
Started: 14:55:06
Finished: 14:55:15
Elapsed: 9 seconds.
The package execution failed.
The step failed.
The issue had arisen from using a File system task to clear a folder of all Files.
I never got to the bottom of the problem, i simply found a different method of deleting the required files.
It's definitely folder permission issue.
Please give proper rights for everyone.
Alpesh Dhori
Software Professional
I suppose that next solution will help you:
Assume that we need to write
\\serv\share\dir1..\dirN\targetDir\somefile.txt using SSIS throught SQL Agent Job and nonadmin proxy account MyDomain\TestAccount
1) MyDomain\TestAccount need read/write access to share \\serv\share
2) MyDomain\TestAccount needed at least FILE_READ_DATA permission for all folders (share,dir1,..dirN)
3) MyDomain\TestAccount needed the CHANGE rights + FILE_DELETE_CHILD permission for folder targetDir
(cacls should show this permissions as following:
DELETE
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_GENERIC_EXECUTE
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_EXECUTE
FILE_DELETE_CHILD
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES
)
Of course the full rights for targetDir are enough.
If targetDir doesn't has FILE_DELETE_CHILD permission then we see such strange behavior of flat file connection in SSIS. User MyDomain\TestAccount may doing anything with file somefile.txt (read,write,delete) using standard Windows tools. But SSIS Job can't overwrite this file and fail.
I have Integration Services packages that need to work with Excel files (shudder) and also need to execute on x64. I have a handle on the whole SSIS x64 vs. 32-bit issue, so I am scheduling these problem-child packages using MS suggested technique of using SQL Agent job step type Operating System / CMDExec, with a command line string that explicitly calls the 32-bit dtexec. So far so good.
Here's the issue: the packages still fail to load, and complain about failing to load not the Excel bits, but instead my handy Log Provider that logs to SQL Server. This is the error message, edited for object names:
Started: 2:33:01 PM
Error: 2009-07-24 14:33:06.51
Code: 0xC0010018
Source:
Description:
Error loading value "<DTS:ConnectionManager xmlns:DTS="www.microsoft.com/SqlServer/Dts"><DTS:Property DTS:Name="DelayValidation">0</DTS:Property><DTS:Property DTS:Name="ObjectName">My_LogCon</DTS:Property><DTS:Property DTS:Name="DTSID">{86320FE6-AEFD-4A58-9277-84685B9B9" from node "DTS:ConnectionManager".
End Error Could not load package "c:\folder\mypkg.dtsx" because of error 0xC0010014.
Description: The package failed to load due to error 0xC0010014 "One or more error occurred. There should be more specific errors preceding this one that explains the details of the errors. This message is used as a return value from functions that encounter errors.". This occurs when CPackage::LoadFromXML fails. ... Process Exit Code 5. The step failed.
The packages run perfectly in 32-bit Visual Studio/debug. Anyone seen this type of thing?
From the 70-488 book:
Dtexec, dtutil, and the SQL Server Import and Export Wizard have both
a 64-bit and a 32-bit application. Be sure to note that if you develop
a package in a 32-bit environment and want to run the package in a
64-bit environment, the connection managers need to be 64-bit
compliant. Some connection managers such as Excel work in a 32-bit
environment only.
I do not think this is Excel related. Your error message clearly states:
Could not load package "c:\folder\mypkg.dtsx"
More detailed error message might help. Also curious to know, are there a lot of processes after the Excel file loads? I am faced with the same scenario and it is shame having to run the whole process in 32 bit.
I might have a work around that will allow you to use Excel files as source, but still configure it to run as a SSIS job, not CmdExec. Will share details once I test this.
Check the following Microsoft knowledge base article. There seems to be a different reason for your issue.
You receive an error message when you try to load an SSIS package that contains a DateTime type variable in SQL Server 2005