TeamCity failing to generate DotCover reports from custom build script - teamcity-8.0

What do I need to do to get TeamCity to properly generate coverage reports against my project?
I've got a custom powershell build script running DotCover against my code. The build script has a coverage method like so
Function Invoke-NUnitWithCoverage ( [string] $targetAssembly, [string] $outputDir, [string] $runCommand){
$fileName = Get-TestFileName $outputDir $runCommand
$xmlFile = "$fileName-TestResults.xml"
$txtFile = "$fileName-TestResults.txt"
$coverageFile = "$fileName-CoverageResults.xml"
exec{ dotcover.exe analyse /TargetExecutable=$nunitRunnerDir\nunit-console.exe /TargetArguments="$targetAssembly /fixture:$runCommand /xml=$xmlFile /out=$txtFile /nologo /framework=4.0" /Output=$coverageFile /ReportType=xml } "Running code coverage '$runCommand' failed."
Write-Host "##teamcity[importData type='dotNetCoverage' tool='dotcover' path='$coverageFile']"
}
The output appears correct on TeamCity, however it's not generating the report. Here's the TeamCity Log. As you can see, there are generation failures.
TL;DR;
If you don't want to read the entire log, here are the key lines.
[JetBrains dotCover] Failed to merge snapshots. Unknown storage type. Unknown storage type
...
[JetBrains dotCover] Unhandled exception: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
...
[JetBrains dotCover] Report generation failed. Too short file
...
[JetBrains dotCover] Failed to create zipped snapshot. Too short file
...
[JetBrains dotCover] 'E:\BuildAgent\temp\buildTmp\dotCover5237101456909205485Merge' is not a coverage snapshot.
##teamcity[importData type='dotNetCoverage' tool='dotcover' path='E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-App-Tests-CoverageResults.xml']
....
....
Waiting for 16 service processes to complete
[10:32:34]Processing 1 coverage report(s)
[10:32:34]Generating coverage report by dotcover for files: [E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-App-Tests-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Framework-Test-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-CommonDataService-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Contracts-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Invoicing-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-FlowingGasService-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-JobSchedulingService-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-CommonDataService-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Contracts-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Invoicing-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-FlowingGasService-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-JobSchedulingService-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-CommonDataService-Tests-Acceptance-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Contracts-Tests-Acceptance-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-FlowingGasService-Tests-Acceptance-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Invoicing-Tests-Acceptance-CoverageResults.xml]
[10:32:34]Get dotCover version (1s)
[10:32:35]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe version E:\BuildAgent\temp\buildTmp\dotCover2609519531914093171Version
[10:32:35]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[10:32:35]dotCover exited with code: 0
[10:32:35]Use DotCover 2.7.x commands set
[10:32:35]Merge dotCover reports (10s)
[10:32:45]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe merge E:\BuildAgent\temp\buildTmp\dotcover6392358845042650216.xml
[10:32:45]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[JetBrains dotCover] Snapshot merging started [12/3/2014 10:32:44 AM]
[JetBrains dotCover] Source snapshots number: 16
Merging snapshots 1-5
[JetBrains dotCover] Failed to merge snapshots. Unknown storage type. Unknown storage type
[10:32:45]dotCover exited with code: -2
[10:32:45]dotCover returned non-zero exit code.
[10:32:45]Remove dotCover snapshot files
[10:32:45]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe delete E:\BuildAgent\temp\buildTmp\dotcover4610370083173723447.xml
[10:32:45]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[JetBrains dotCover] Unhandled exception: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
[10:32:45]dotCover exited with code: -10
[10:32:45]dotCover returned non-zero exit code.
[10:32:45]Generate dotCover report (7s)
[10:32:52]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe report E:\BuildAgent\temp\buildTmp\dotcover8678535704262330052.xml
[10:32:52]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[JetBrains dotCover] Report generation started [12/3/2014 10:32:45 AM]
[JetBrains dotCover] Report generation failed. Too short file
[10:32:52]dotCover exited with code: -2
[10:32:52]dotCover returned non-zero exit code.
[10:32:52]Generate dotCover HTML report
[10:32:52]Packing snapshot files (6s)
[10:32:59]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe zip E:\BuildAgent\temp\buildTmp\dotcover1602620273009840026.xml
[10:32:59]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[JetBrains dotCover] Failed to create zipped snapshot. Too short file
[10:32:59]dotCover exited with code: -2
[10:32:59]dotCover returned non-zero exit code.
[10:32:59]Remove dotCover snapshot files (6s)
[10:33:06]No statistics values are provided by dotCover report generator (recommended)

For dotCover you should send paths to the snapshot (dotCover.snapshot) file that is generated by the dotCover.exe cover command, not .xml file.

Related

SSIS editing a script task and saving it doesn't work

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.

Disable a sequence container in SSIS using SQL query?

Suppose I have a SSIS package which is having almost 20 sequence containers and while running the job, a few sequence container got completed successfully but a few fail. So, here I want an automated SQL query to disable the completed sequence container and enable the failed sequence container so that if I run the package again, then it will run only failed sequence container.
Is there any chance to disable the completed sequence container and run the failed one?
Personally, I detest checkpoints. They don't work within the context of a loop and maybe it's just my bad luck, but I have far too often experienced a corruption of the checkpoint file
I always advise clients to design their ETL solutions with restartability in mind. At some point, the process will fail and you know it's going to be in the middle of something crucial so remove the "thinking" aspect of getting it restarted. Don't make it depend on someone running a script to clean up half committed loads, etc. But that's a different question...
Every object in your control flow will support a property called Disable. When you run a package, you can deactivate tasks via the /SET command. Given the following example, each sequence container has a Script Task that does nothing but fires an information event
When I run that from the command line,
C:\Users\bfellows\source\repos\SO_Trash\SO_Trash>dtexec /file SO_61477591.dtsx /rep i
Microsoft (R) SQL Server Execute Package Utility
Version 14.0.3238.1 for 32-bit
Copyright (C) 2017 Microsoft. All rights reserved.
Started: 10:45:43 AM
Info: 2020-04-28 10:45:43.71
Code: 0x00000000
Source: SCR0 SCR Echo Back
Description: System::ParentContainerGUID : {3910E325-F3D0-4EC6-96FD-5E125FEC0ED2}
End Info
Info: 2020-04-28 10:45:43.74
Code: 0x00000000
Source: SCR1 SCR Echo Back
Description: System::ParentContainerGUID : {08bf88d5-71c3-4105-824e-bb8b1e942b24}
End Info
Info: 2020-04-28 10:45:43.77
Code: 0x00000000
Source: SCR2 SCR Echo Back
Description: System::ParentContainerGUID : {59823604-1caf-4a90-9303-45d55126d8b3}
End Info
Info: 2020-04-28 10:45:43.80
Code: 0x00000000
Source: SCR3 SCR Echo Back
Description: System::ParentContainerGUID : {977567f1-6bcf-4c84-909e-eb18ba17165d}
End Info
DTExec: The package execution returned DTSER_SUCCESS (0).
Started: 10:45:43 AM
Finished: 10:45:43 AM
Elapsed: 0.609 seconds
By specifying the path to the executable, I can set the property disable property like /set \Package\SEQC1.Properties[Disable];"True" where SEQC1 is the case sensitive name of the object I want to disable
C:\Users\bfellows\source\repos\SO_Trash\SO_Trash>dtexec /file .\SO_61477591.dtsx /rep i /set \Package\SEQC1.Properties[Disable];"True"
Microsoft (R) SQL Server Execute Package Utility
Version 14.0.3238.1 for 32-bit
Copyright (C) 2017 Microsoft. All rights reserved.
Started: 10:45:50 AM
Info: 2020-04-28 10:45:50.62
Code: 0x00000000
Source: SCR0 SCR Echo Back
Description: System::ParentContainerGUID : {3910E325-F3D0-4EC6-96FD-5E125FEC0ED2}
End Info
Info: 2020-04-28 10:45:50.66
Code: 0x00000000
Source: SCR2 SCR Echo Back
Description: System::ParentContainerGUID : {59823604-1caf-4a90-9303-45d55126d8b3}
End Info
Info: 2020-04-28 10:45:50.69
Code: 0x00000000
Source: SCR3 SCR Echo Back
Description: System::ParentContainerGUID : {977567f1-6bcf-4c84-909e-eb18ba17165d}
End Info
DTExec: The package execution returned DTSER_SUCCESS (0).
Started: 10:45:50 AM
Finished: 10:45:50 AM
Elapsed: 0.609 seconds
Notice that SCR1 is no longer in the output due to the SET command disabling it.
Knowing how to disable tasks, you could leave the package as-is and modify your start to be text generated from SQL Queries (give me all the tasks that have completed and build the correct /SET statements)
A better approach that would require modification to the existing package would be have an Execute SQL Task(s) that runs at the start of the package and it sets Boolean SSIS variables with an indicator of whether the Task should be disabled. And then modify each object to have an expression on the Disable property that is the new SSIS variable.
Personally, my approach is to make many SSIS packages. Each package is a unit of work (load sales table). When a package fires, it records that execution has begun. When it completes successfully, it records that it has completed (as well has how many rows inserted/updated/deleted)
I then have a orchestrator package that queries the list of known packages and identifies any package that has not run successfully. It then uses a foreach loop with an Execute package task to then start running the child processes.
An advantage to my approach is that, assuming no dependencies between task 1 and 3, I could have two copies of this running - one "stack" handles the package 0 and 2, while a different stack handles 1 and 3. One of the advantages of SSIS is that it makes it trivial to parallelize your workload.
You can use CHECKPOINT file feature in SSIS to automatically run only the failed containers in the control flow task. It is available out of the box in SSIS. You can configure it in the package.
Read more on Checkpoint usage & Restart packages using checkpoint on MSDN

SSIS Project Fails To Build On Self Hosted Agent

I've seen other issues documented regarding SSIS project build failures but nothing that fits my scenario.
I am attempting to build an SSIS project (.dtproj) on a self hosted agent.
The project builds fine in Visual Studio 2019 and also on Azure Pipelines, but when I attempt to build it with the self hosted agent (via Command Line Task in a Build Pipeline in Azure DevOps) I get the following errors:
[debug]Evaluating condition for step: 'Build SSIS Packages'
[debug]Evaluating: succeeded()
[debug]Evaluating succeeded:
[debug]=> True
[debug]Result: True Starting: Build SSIS Packages
======================================================================== Task : Command line Description : Run a command line script
using Bash on Linux and macOS and cmd.exe on Windows Version: 2.151.2 Author: Microsoft Corporation
=========================================================================
[debug]VstsTaskSdk 0.9.0 commit 6c48b16164b9a1c9548776ad2062dad5cd543352
[debug]Entering C:\My Project\agent_work_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\cmdline.ps1.
[debug]Loading resource strings from: C:\My Project\agent_work_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\task.json
[debug]Loaded 6 strings.
[debug]SYSTEM_CULTURE: 'en-US'
[debug]Loading resource strings from: C:\My Project\agent_work_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\Strings\resources.resjson\en-US\resources.resjson
[debug]Loaded 6 strings.
[debug]INPUT_FAILONSTDERR: 'false'
[debug] Converted to bool: False
[debug]INPUT_SCRIPT: 'echo Building SsisProject...
[debug]
[debug]"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv.com" C:\My
Project\agent_work\1\s\MySolution.sln /build Development /project
C:\My
Project\agent_work\1\s\ETL\Integration\MySsisProject\MySsisProject.dtproj'
[debug]INPUT_WORKINGDIRECTORY: 'C:\My Project\agent_work\1\s'
[debug]Asserting container path exists: 'C:\My Project\agent_work\1\s' Generating script.
[debug]AGENT_VERSION: '2.155.1'
[debug]AGENT_TEMPDIRECTORY: 'C:\My Project\agent_work_temp'
[debug]Asserting container path exists: 'C:\My Project\agent_work_temp'
[debug]Asserting leaf path exists: 'C:\WINDOWS\system32\cmd.exe'
========================== Starting Command Output ========================
[debug]Entering Invoke-VstsTool.
[debug] Arguments: '/D /E:ON /V:OFF /S /C "CALL "C:\My Project\agent_work_temp\dde3e815-8cea-4bea-ab26-77e9bb52d973.cmd""'
[debug] FileName: 'C:\WINDOWS\system32\cmd.exe'
[debug] WorkingDirectory: 'C:\My Project\agent_work\1\s' "C:\WINDOWS\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "C:\My
Project\agent_work_temp\dde3e815-8cea-4bea-ab26-77e9bb52d973.cmd""
Building SsisProject...
Microsoft Visual Studio 2019 Version 16.0.29306.81. Copyright (C)
Microsoft Corp. All rights reserved.
The following files were specified on the command line:
C:\My Project\agent_work\1\s\MySolution.sln My
Project\agent_work\1\s\ETL\Integration\MySsisProject\MySsisProject.dtproj
[debug]Exit code: 1
[debug]Leaving Invoke-VstsTool.
[error]Cmd.exe exited with code '1'.
[debug]Processed: ##vso[task.logissue type=error]Cmd.exe exited with code '1'.
[debug]Processed: ##vso[task.complete result=Failed]Error detected
[debug]Leaving C:\My Project\agent_work_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\cmdline.ps1.
The other generic trouble shooting advice is to remove the space in your "My Project" folder. Yes, it's 2019 and it shouldn't matter and many tools comprehend spaces but the fewer escapes you need to worry about, the better your chances of success.

package failed to load due to error 0x80131534 "(null)". This occurs when CPackage::LoadFromXML fails

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.

SQL Server Agent Error on running an SSIS package

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?