1

I have an Azure VM (Windows Server 2016 Datacenter) that is running MS SQL Server 2017. I've created several SSIS packages that use Execute Process Tasks to run EXEs and batch files that are stored on my Azure file storage account (i.e. \[storage name].file.core.windows.net[storage name]).

I have deployed these packages to the Integration Services Catalog. I am able to manually run these packages by right-clicking the package and clicking Execute... but when I set the packages up as SQL Server Agent jobs they fail.

I created Credentials for the server's admin account and use those creds as Proxies (which I have done in the past). I am able to run other packages that access network files without issue but when I try to run a bat/exe I get the below errors:

Execute Process Task 1:Error: There were errors during task validation.

Execute Process Task 1:Error: File/Process "\ [storage name].file.core.windows.net[storage name]\Production\TEST \test.bat" is not in path.

I have copied the same file to the C drive and the package runs successfully. I have also try to map the network drive but that fails too.

Any help or info would be greatly appreciated.

  • Since it works when you run it but not via scheduled/impersonation runs, clearly it's some permission somewhere failing. Devil's going to be finding where :( I'd probably start with creating credentials as you and having it run via that proxy to rule out something with the admin account (like interact with desktop) not being set versus whatever else we'll discover. – billinkc Mar 06 '18 at 18:57
  • For this VM, the admin creds are the only ones I have on the machine. The idea is to only use this machine to run SSIS packages. If it makes sense, I could set up another Windows user on the machine and using that as a proxy. – Justin Birmingham Mar 06 '18 at 21:45
  • 1
    New info... I have now created a test "Operating system (CmdExec)" step in SQL Server Agent that uses "pushd" to mount my Azure shared drive (Azure Storage Account - File Service). When I run the job it fails with the message "Executed as user: [admin user]. The user name or password is incorrect. Process Exit Code 1. The step failed." Like what billinkc stated, there seems to be an issue with permissions but I can't figure out why Integration Services Catalogs has access to the share drive and SQL Server Agent does not when I am, in theory, using the same creds through the proxy. – Justin Birmingham Mar 08 '18 at 14:01

0 Answers0