November 25, 2019 at 8:29 pm
I have a sql agent job that is called by a cmd file remotely using an admin account for example I will call it OrchestrorService account.
In SQL agent job history I can see the job was invoked by that account.
But the job step actually is a SSIS package. And the step is run using SQL server service account which is another account.
I tried to figure out the permission issue, both the account is a Sysadmin, I want to know which account it runs under in this case,
the SQL server service account, or whoever invoked the account?
Thanks
November 25, 2019 at 8:51 pm
SSIS steps in SQL Agent will run as the same user that the Windows service "SQL Server Agent" is setup to log on as. If you want to control what account this is, you can setup a credential within SQL Server for the account, setup a proxy in the SQL Agent, and then setup the individual job step that runs SSIS to run as that proxy account:
November 25, 2019 at 9:45 pm
The strange thing is that the service account does not have access to a share, but it still can access the file.
November 26, 2019 at 9:24 pm
Thanks, figured out the access issue
November 27, 2019 at 2:24 am
Thanks, figured out the access issue
Two way street here... what was the solution that you figured out?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 3, 2019 at 6:45 am
Thanks, figured out the access issue
Can you kindly tell us what you figured out? It'll help other folks (and me 😉 ). Thanks.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2019 at 12:18 am
I found out the account actually does have read access to the directory.
I tested to ask somebody not in our team but in same department to see if she can access it, but actually she should not.
It turns out she can access it.
So I contacted our network admin again to let him know the share permission may not be setup correctly.
He is trying to figure out that.
So it is a share permission issue.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply