April 18, 2018 at 6:08 am
Hi,
My SSIS packages are not running when called from a SQL Server Agent Job .I have been reading about setting a proxy account and i did that still not working.Can you please help if anyone knows how to solve this.
When creating a proxy account i read that i must use a separate account,is it an account only for that machine or a domain account which logs in to all servers?
Please help, i am stuck.
Thank you.
April 25, 2018 at 1:47 pm
tmmutsetse - Wednesday, April 18, 2018 6:08 AMHi,My SSIS packages are not running when called from a SQL Server Agent Job .I have been reading about setting a proxy account and i did that still not working.Can you please help if anyone knows how to solve this.
When creating a proxy account i read that i must use a separate account,is it an account only for that machine or a domain account which logs in to all servers?
Please help, i am stuck.
Thank you.
You create and use a domain account following the principle of least privileges. It just needs access to what the packages need access to.
Sue
April 25, 2018 at 1:56 pm
More information is needed. If you're using SQL 2012+, you may be able to use the manage service accounts. Or if the job is reading from a database, the SQL Server Agent account may need read permission. If you're accessing another server, that complicates the matter. It still may be difficult to help over a forum, but without more information, it's not possible to help without just guessing.
April 25, 2018 at 2:03 pm
RonKyle - Wednesday, April 25, 2018 1:56 PMMore information is needed. If you're using SQL 2012+, you may be able to use the manage service accounts. Or if the job is reading from a database, the SQL Server Agent account may need read permission. If you're accessing another server, that complicates the matter. It still may be difficult to help over a forum, but without more information, it's not possible to help without just guessing.
It's for an Agent proxy account, not the service account for Agent. The packages run in the security context of the account that the credential points to when creating the proxy so you wouldn't do anything with the SQL Server Agent account. .
Sue
April 25, 2018 at 2:09 pm
As I already said, knowing the version would be helpful. If it's 2012+ I would ask why you need to use proxy accounts rather than the managed service accounts. It's not that there can't be a reason to use a proxy account. Only that the managed service accounts should not be overlooked. I have found them to be very useful and saves some of the issues I've experienced when using proxy accounts.
April 25, 2018 at 2:45 pm
RonKyle - Wednesday, April 25, 2018 2:09 PMAs I already said, knowing the version would be helpful. If it's 2012+ I would ask why you need to use proxy accounts rather than the managed service accounts. It's not that there can't be a reason to use a proxy account. Only that the managed service accounts should not be overlooked. I have found them to be very useful and saves some of the issues I've experienced when using proxy accounts.
Proxy accounts and service accounts are two very different things for different purposes.
I use managed service accounts and I have proxies accounts. It's not one or the other. From the documentation in this link
Configure a User to Create and Manage SQL Server Agent Jobs:
By default, members of these database roles can create their own job steps that run as themselves. If these non-administrative users want to run jobs that execute other job step types (for example, SSIS packages), they will need to have access to a proxy account.
That's why people want to create proxies. It's for logins that don't have administrative privileges. Seems better than giving out syadmin to more users.
Sue
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply