When trying to execute an SSIS package I get the following error:
Date 14/08/2013 15:02:42 Log Job History (test)
Step ID 1 Server YGAL1-MOBL1 Job Name test Step Name ssis
Duration 00:00:00 Sql Severity 0 Sql Message ID 0 Operator
Emailed Operator Net sent Operator Paged Retries Attempted 0
Message Executed as user: GER\YGAL1-MOBL1$. Microsoft (R) SQL Server
Execute Package Utility Version 10.50.1600.1 for 64-bit Copyright
(C) Microsoft Corporation 2010. All rights reserved. Started:
15:02:42 Error: 2013-08-14 15:02:42.84 Code: 0xC0011007
Source: {0AF31012-7A56-4B28-92EF-BE439E68E6F0} 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: 2013-08-14 15:02:42.84 Code: 0xC0011002 Source:
{0AF31012-7A56-4B28-92EF-BE439E68E6F0} Description: Failed to
open package file "C:\Users\ygal1\Documents\Visual Studio
2008\Projects\Integration Services Project2\Integration Services
Project2\Package.dtsx" due to error 0x80070005 "Access is denied.".
This happens when loading a package and the file cannot be opened or
loaded correctly into the XML document. This can be the result of
either providing an incorrect file name was specified when calling
LoadPackage or the XML file was specified and has an incorrect format.
End Error Could not load package "C:\Users\ygal1\Documents\Visual
Studio 2008\Projects\Integration Services Project2\Integration
Services Project2\Package.dtsx" because of error 0xC0011002.
Description: Failed to open package file
"C:\Users\ygal1\Documents\Visual Studio 2008\Projects\Integration
Services Project2\Integration Services Project2\Package.dtsx" due to
error 0x80070005 "Access is denied.". This happens when loading a
package and the file cannot be opened or loaded correctly into the XML
document. This can be the result of either providing an incorrect file
name was specified when calling LoadPackage or the XML file was
specified and has an incorrect format. Source:
{0AF31012-7A56-4B28-92EF-BE439E68E6F0} Started: 15:02:42 Finished:
15:02:42 Elapsed: 0.046 seconds. The package could not be found.
The step failed.
Any ideas on how can I solve it?
i had a similar problem and what i did to get my package to run was:
a. Open Job properties in SQL Server
b. On the Steps page in the Package field: I used the entire folder name instead of the mapped name, for example: \share\allusers\myuserid\mypackage.dtsx instead of A:\mypackage.dtsx
Best.
It looks to me like the Service account for the SQL Agent doesn't have permissions to read package.dtsx.
Maybe check which account is running the SQL Agent & give it NTFS read permissions to C:\Users\ygal1\Documents\Visual Studio 2008\Projects\Integration Services Project2\Integration Services Project2
Or store the DTSX file in a location the SQL Agent account can access?
Related
I am working on lift and shift SSIS packages through ADF. Setup have been done properly but when I trigger the activity in ADF, I see this error "Package execution failed. For more details, select the output of your activity run on the same row". How to resolve this error?
Going through the official MS docs, I can see the below error documented. Can you try as suggested.
Error message: "Staging task failed. TaskStatus: Failed, ErrorCode: 2906, ErrorMessage: Package execution failed. For more details, select the output of your activity run on the same row., Output: {"OperationErrorMessages": "4/14/2021 7:10:35 AM +00:00 : = Failed to start Named pipe proxy... "
Check if security policies are correctly assigned to the account
running self-hosted IR service. If Windows authentication is used on
Execute SSIS Package activity or the execution credential is set in
SSIS catalog (SSISDB), the same security policies must be assigned to
the Windows account used. More detail can be found at Configure
Self-Hosted IR as a proxy for Azure-SSIS IR in
ADF
Note: I am not an SSIS developer and have a very limited knowledge on it, so may be missing on very small details, please read carefully.
I have an existing SSIS package which has script task in one of the steps.
I had to update one single value in script task, so I opened it in notepad++ and updated the value and saved it. Now when the scheduled SSIS job runs, it still picks up the old value and not the updated one.
I realized script task is a VB file, so probably would need to re-compile it for the binaries. I read about it and found out, if you open it through VS and save it, VS automatically compiles it and you don't have to do anything further. I can be wrong here.
I can't do project deployment on the server, so I would just need the updated package file to replace it on the server.(I am taking this updated package file from the Visual studio project that I created to edit the SSIS package. I am not sure, if there is another way to get the package or even if this is a right package.
Now the problem is,
when I updated the old package using notepad++, it didn't throw any error when it was running through scheduled job, but it took the old value
Now when I am putting the new package that I edited using Visual studio, it throws below error
Executed as user: sampleUser(nameupdated). Microsoft (R) SQL Server Execute Package Utility Version 13.0.5026.0 for 32-bit Copyright (C) 2016 Microsoft. All rights reserved. Started: 5:08:09 PM Error: 2021-11-02 17:08:10.83 Code: 0xC0016016 Source: OraclePackage 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 Error: 2021-11-02 17:08:11.26 Code: 0x00000005 Source: Rename files in archive folder to _yyyymmddhhmm Rename files in archive folder to _yyyymmddhhmm Description: Failed to migrate scripts contained in the package to the VSTA 14.0 format. Move the scripts to a new Script task. End Error Error: 2021-11-02 17:08:14.19 Code: 0x00000005 Source: Script Task Script Task Description: Failed to migrate scripts contained in the package to the VSTA 14.0 format. Move the scripts to a new Script task. End Error Error: 2021-11-02 17:08:17.17 Code: 0x00000001 Source: Script Task Description: Exception has been thrown by the target of an invocation. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 5:08:09 PM Finished: 5:08:17 PM Elapsed: 7.25 seconds. The package execution failed. The step failed.
I read about this error and found that package's security level can cause this issue, so update the protection level of the package from "EncryptSensitiveWithUserKey" to "DontSaveSensitive"
Now when I am running the project I get below error
Executed as user: sampleuser(nameUpdated). Microsoft (R) SQL Server Execute Package Utility Version 13.0.5026.0 for 32-bit Copyright (C) 2016 Microsoft. All rights reserved. Started: 5:31:44 PM Error: 2021-11-02 17:31:53.93 Code: 0x00000001 Source: Script Task Description: Exception has been thrown by the target of an invocation. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 5:31:44 PM Finished: 5:31:53 PM Elapsed: 9.047 seconds. The package execution failed. The step failed.
Please let me know if there is another way to edit the script task directly and compile it in place so that it takes the updated values else, if there is something else I can do.
Thanks in advance.
I found a solution(more of an error or less knowledge from my side actually)
Updating the security from "EncryptSensitiveWithUserKey" to "DontSaveSensitive"
When you open an existing SSIS package in Visual studio, the read and write variables are wiped out from script task for some reason. Reassigning them resolved the problem.
How did I find out if that was the problem, I put some exception handling in the script task to notify me of further issues.
Hope this helps to someone in the similar problem.
So, I have a SSIS package, which is supposed to write a file to "..\Prod\OUT\Markedsføringslisten".
However, SSIS fails, citing access rights:
[SSIS.Pipeline] Error: Flat File Destination failed the pre-execute phase and returned error code 0xC020200E.
[Flat File Destination [2]] Error: Cannot open the datafile "..\prod\Out\Markedsføringslisten\AL_Erhverv_Markedsføringslisten_2021_12_06.csv".
[Flat File Destination [2]] Warning: Access is denied.
However, If I change the path to:
"...\Prod\OUT\Markedsfoeringslisten" (ø = oe) then everything works just fine, meaning that it shouldn't really be an access issue with the subfolder. We need to keep using the same name, however, as other solutions are expecting files from: "..\Prod\OUT\Markedsføringslisten".
The package is being build in SSIS 2017. An older variant of the package, built in 2013, works just fine. I can't see any immediate difference between the two connections, but feel free to ask for additional information if you feel it could help.
I ran the following batch file on our SQL Server "9". It is an SSIS 2012 package with no connections, no tasks, no code. It's an empty package.
ECHO before dtexe!
REM "DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
"D:\SQL2012\110\DTS\Binn\DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
SET RESULT=%errorlevel%
ECHO RESULT AFTER DTEXEC=%RESULT%
exit /B %RESULT%
Here's my output:
----------------------------------------------------------------
Output of messages for workload object TEST/GHG1990R.28/MAIN
Start date Tue Oct 06 20:45:38 2015
----------------------------------------------------------------
C:\Users\MyServerId>ECHO before dtexe!
before dtexe!
C:\Users\MyServerId>REM "DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
C:\Users\MyServerId>"D:\SQL2012\110\DTS\Binn\DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
Microsoft (R) SQL Server Execute Package Utility
Version 11.0.5058.0 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started: 8:45:39 PM
Could not load package "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx" because of error 0x80131534.
Description: The package failed to load due to error 0x80131534 "(null)". This occurs when CPackage::LoadFromXML fails.
Source: {BA581388-EFF5-4BC7-89E7-48E11D6DF0AE}
Started: 8:45:39 PM
Finished: 8:45:39 PM
Elapsed: 0.094 seconds
C:\Users\MyServerId>SET RESULT=5
C:\Users\MyServerId>ECHO RESULT AFTER DTEXEC=5
RESULT AFTER DTEXEC=5
C:\Users\MyServerId>exit /B 5
I get the same error regardless of whether I run with the 32 or 64 bit DTEXEC utility. When I run the same batch file against the same package on another SQL Server, server "80", I get no error.
All of the packages work on server 80, none work on 9. I get the above error every time on server 9.
When I execute this on both 80 and 9,
select ##version
I get the same result
Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
May 14 2014 18:34:29
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)
I am able to successfully use the sqlcmd and bcp utilities on 9, but not the dtexec utility.
The error that I am getting seems to suggest that I am using an old version of dtexec to open up a newer package, for example, trying to use a SQL 2008 dtexec util to execute a new SQL 2012 package.
Clearly the packages are not corrupt because all of the packages work on 80 and copies of the exct files on 9 all do not work.
The only thing I can think of is a installation issue with SQL Server, for example, a corrupt install or unregistered dll.
As far as I can tell, this is the first and only version of SQL Server installed on these machines, so I shoould not be acidentily runnning an old version of DTEXEC with a newer 2012 package.
Here is the complete Empty2012Package.dtsx file:
<?xml version="1.0"?>
<DTS:Executable
DTS:refId="Package" xmlns:DTS="www.microsoft.com/SqlServer/Dts"
DTS:ExecutableType="SSIS.Package.3"
DTS:CreatorName="MyDOMAIN\MyLanId"
DTS:CreatorComputerName="MYCPTR"
DTS:CreationDate="7/2/2015 8:26:52 AM"
DTS:PackageType="5"
DTS:VersionBuild="2"
DTS:VersionGUID="{00FD1F37-6375-4942-91D3-9ECA0B131FFD}"
DTS:LastModifiedProductVersion="11.0.2100.60"
DTS:LocaleID="1033"
DTS:ObjectName="Empty2012Package"
DTS:DTSID="{1539BA56-F17B-438E-A874-A2151F2F79C5}"
DTS:CreationName="SSIS.Package.3">
<DTS:Property
DTS:Name="PackageFormatVersion">6</DTS:Property>
<DTS:Variables />
<DTS:Executables />
<DTS:DesignTimeProperties><![CDATA[<?xml version="1.0"?>
<!--This CDATA section contains the layout information of the package. The section includes information such as (x,y) coordinates, width, and height.-->
<!--If you manually edit this section and make a mistake, you can delete it. -->
<!--The package will still be able to load normally but the previous layout information will be lost and the designer will automatically re-arrange the elements on the design surface.-->
<Objects
Version="sql11">
<!--Each node below will contain properties that do not affect runtime behavior.-->
</Objects>]]></DTS:DesignTimeProperties>
</DTS:Executable>
Since I used SQL 2012 to create the dtsx file, I knew that is was a 2012 package. However, according to this web page,
http://www.techbrothersit.com/2014/09/ssis-how-to-find-version-of-ssis.html
PackageFormatVersion of 6 indicates a 2012 package.
I don't have access to the server to see the versions of each dtexec.exe file. I hope to get this information soon.
When I run the same batch file with the same package on 80, as mentioned above, it works:
----------------------------------------------------------------
Output of messages for workload object C1_GHG1_TEST/GHG1999I.11/MAIN
Start date Tue Oct 06 22:21:08 2015
----------------------------------------------------------------
C:\Users\MyServerId>ECHO before dtexe!
before dtexe!
C:\Users\MyServerId>REM "DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
C:\Users\MyServerId>"D:\SQL2012\110\DTS\Binn\DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
Microsoft (R) SQL Server Execute Package Utility
Version 11.0.5058.0 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started: 10:21:08 PM
DTExec: The package execution returned DTSER_SUCCESS (0).
Started: 10:21:08 PM
Finished: 10:21:08 PM
Elapsed: 0.203 seconds
C:\Users\MyServerId>SET RESULT=0
C:\Users\MyServerId>ECHO RESULT AFTER DTEXEC=0
RESULT AFTER DTEXEC=0
C:\Users\MyServerId>exit /B 0
Any ideas on what may be causing this error? I'm thinking that this is a server SQL Server setup issue rather than something that I can control.
Your thoughts?
Update
The problem is related to security permissions. When we try running the job in the CA Scheduler udner MyServiceID, an Admin with access to the box then checked the Event Log and found this error:
The user has not been granted the requested logon type at this machine.
Furthermore, When a user who is in the local Admin group remotes to this server and launches the same batch file, the job runs successfully.
According to this link,
https://technet.microsoft.com/en-us/library/cc732593(v=ws.10).aspx
The error can be resoled by granting the right to "Allow User To Log On Locally." The user is already granted "Allow Log On As Batch" rights. When I dop a "net user MyServiceId" command from the command line, I also see that the ID is active and allowed on all Workstations at all times.
When I requested "Allow user to LogOn Locally" rights to be granted, apparently even the "Admins" could not grant this right because is is disallowed by Group Policy. Because this is the only server where this is happening, I am left wondering what is different about this server assuming that all serevrs share the same Group Policy. One thing that we noticed is that the OWNER property on the dtsx file is not MyServiceId and in environments. I don't have the righs to change this but I don't thing that this is it. The MyServiceAccount does have full control of the folder where the batch files and packages reside.
Update 2
Since this is now clearly a security issue, perhaps it would help if I try an state the question after stating the known facts:
MyServiceId has execute access to the local folder, E:\SSIS\MyAppName\Packages\, in which SSIS package resides
MyServiceId has execute access to the local folder, D:\SQL2012\110\DTS\Binn\, in which DTEXEC resides
MyServiceId has LogOn As Batch rights on the Server.
MyServiceId is an active account that is allowed on all Servers and Workstations
Question:
Given the simple one line batch file that calls DTEXEC passing a package path as a param, what could be contributing to the error that I am getting? What additional things can I look for? Sicne "Allow User To Log On locally" is never set on other server, what can be different on this server that is contributing to this error:
The user has not been granted the requested logon type at this machine.
Is the value of the OWNER property of the dtsx file relevant?
Update 3
Calling process Name: C:\Windows\System32\LSASS.exe
Is this a hint?
Update 4
In production, where it works,the service id is executing with a Network Logon type of 3, which is interactive. On 9, where it's giving us this error, it is executing with a logon type of 2, which is interactive. (We do not have the option to turn on "Allow Log On Locally" for the uyser on 9. This is verboten.
What would account for the same ID running on 2 different machines on teh same domain, to run as different user types?
I encountered this error shortly after making a modification to my machine.config file on my workstation. I resolved my issues in the machine.config (I had placed a node under the wrong parent node) and this error went away.
Unfortunately, since the error is vague, this may not be the solution for your situation. Just thought I'd share in case it helps someone.
I changed my SQL service account to local system. My SSIS services were also running from local system only.
So, ideally we can try keeping both as same services account.
NOTE: this needs to be applied only in case we are not able to change the access rights of SQL agent service account.
I two SSIS packages that both run fine on my local machine. I can import them to SSIS on the server and execute them both with no problems. However, I need to run them in series every night at 3AM. Thus, I created a SQL Server Agent Job with two steps. The first step runs the first package successfully. The second step should run the second package but it fails with this error message:
Message
Executed as user: IT-DEV\itdev. Microsoft (R) SQL Server Execute Package Utility Version 11.0.2100.60 for 64-bit Copyright (C)
Microsoft Corporation. All rights reserved. Started: 1:27:21 PM
Error: 2013-05-30 13:27:21.53 Code: 0x00000001 Source: Create
text files on IT DEV Description: Exception has been thrown by
the target of an invocation. End Error DTExec: The package execution
returned DTSER_FAILURE (1). Started: 1:27:21 PM Finished: 1:27:21
PM Elapsed: 0.375 seconds. The package execution failed. The step
failed.
Both packages move some files from one directory to another and do some work. They both run in the same security context using the same proxy. I can see the work completed successfully from step 1, but again step 2 fails. I have looked through all possible step settings for each and see no differences. Thus, how can I get a more descriptive message so I know what the real issue is. I'm guessing its permissions but again both packages do similar work in similar locations requiring the same permissions. One runs, the other doesn't. Please help. Thanks in advance.
FYI I've also turned SSIS logging on and write everything to a file but the message below is the only error I see.
UPDATE
I ended up writing to a text file all over inside the script task to try to identify the problem. I seem to be getting stuck here:
string connStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + myPath + ";Extended Properties=\"text;HDR=NO;FMT=TabDelimited\"";
OleDbDataAdapter adapter = new OleDbDataAdapter("SELECT * FROM MYFILE.txt", connStr);
outfile.WriteLine("Adapter Created");
DataTable dtFiles = new DataTable();
adapter.Fill(dtFiles);
outfile.WriteLine("Filled DataTable");
I never see "Filled DataTable" in the file I'm writing to... the last entry says "Adapter Created".
Turns out I needed to replace this: Microsoft.Jet.OLEDB.4.0 with this: Microsoft.ACE.OLEDB.12.0 because I'm running the agent job on Windows Server 2008 64 bit.