0
votes

Ultimately, I'm trying to schedule SSIS packages to run on a regular basis using Task Scheduler in an Azure VM (Windows Server 2016 Datacenter). From the command line on my development machine (Windows 10), I'm able to run...

dtexec.exe /Project "pathToMy.ispac" /Package "pathToMy.dtsx"

...and it works as expected. However, when I try to do the same from the Azure VM I get the following error:

Microsoft (R) SQL Server Execute Package Utility Version 11.0.6020.0 for 32-bit Copyright (C) Microsoft Corporation. All rights reserved.

Started: 2:17:46 PM Could not load package "MyPackage.dtsx" because of error 0x80131500. Description: The package failed to load due to error 0xC0011008 "Error loading from XML. No further detailed error information can be specified for this problem because no Events object was passed where detailed error information can be stored.". This occurs when CPackage::LoadFromXML fails. Source: MyPackage Started: 2:17:46 PM Finished: 2:17:47 PM Elapsed: 0.547 seconds

On both machines, I have the same version of SQL Server 2016 Developer (w/ SSIS) and Visual Studio 2015 installed. Also, I'm able to run the package fine on the VM from within Visual Studio. It's only from dtexec.exe that I have issues.

I've tried every solution on here from other posts getting similar errors and none have helped. Any ideas?

Thanks, Ian

1
Is the dtexec also the same version? Can you confirm which Protection Level you are using - dont save, encrypt with password, encrypt with user key - Nick.McDermaid
@Nick.McDermaid - you nailed it! Apparently, the global path was pointing to an old (v11) version on the VM and the version on my dev machine was v13. By providing the full path to the v13 file, I was able to get it going. THANKS! If you want to repeat this suggestion as a reply instead of a comment, I'll be glad to mark it as the correct answer. - Ian Lee
What would be best is if you could document what you did (with paths etc. as an answer) as an answer and accept it yourself. - Nick.McDermaid

1 Answers

0
votes

Thanks to @Nick.McDermaid, the answer to this riddle has been found. By running dtexec.exe (with no parameters) on the dev machine and on the VM, I was able to see that the VM version was v11 and the dev version was v13 which explained why I was getting the error and why one worked and another didn't.

I then did a File Explorer search on the VM for dtexec.exe copies and found several. Apparently, the environment path was set to find the older version. I probably could have found the variable causing this problem and changed it. However, out of concern about breaking something else and wanting a quick solution, I chose to execute using the full path to the correct version. For v13, this ended up being...

"C:\Program Files\Microsoft SQL Server\130\DTS\Binn\dtexec.exe"

So, for my schedule task I set the following properties for my "Start a program" action.

Program/Script: "C:\Program Files\Microsoft SQL Server\130\DTS\Binn\dtexec.exe"

Add Arguments: /Project "bin/Development/myProject.ispac" /Package "myPackage.dtsx"

Start in: c:{path to my .dtsx file}