You design a Business Intelligence (BI) solution by using SQL Server 2008. The solution includes several SQL Server 2008 Integration Services (SSIS) packages. The SSIS packages import data from files located on other servers.
The packages will be deployed to a SQL Server 2008 instance and scheduled to run through the SQL Server Agent service. The SQL Server Agent service runs under a local user account. The SSIS packages fail to run when the SQL Server Agent jobs are executed. You need to ensure that the packages run successfully in the production environment.
What should you do?
A.
Configure the SQL Server Agent job step to run as a proxy account.
B.
Configure the SQL Server Agent job to use the sa account as the job owner.
C.
Configure the SQL Server Agent service to use the Local Service account.
D.
Configure the SQL Server Agent service to use a local administrator account.
Explanation:
Tip: "other servers" = "step"
Burgos: The correct Solution certally is SQL Server Agent service to use a Domain Account with permisinos on servers that holds the files and with administratives rights on Server that holds Agent Service.http://msdn.microsoft.com/en-us/library/ms189064.aspx
Creating SQL Server Agent Proxies
A SQL Server Agent proxy defines the security context for a job step. A proxy provides SQL Server Agent with access to the security credentials for a Microsoft Windows user. Each proxy can be associated with one or more subsystems. A job step that uses the proxy can access the specified subsystems by using the security context of the Windows user. Before SQL Server Agent runs a job step that uses a proxy, SQL Server Agent impersonates the credentials defined in the proxy, and then runs the job step by using that security context.
Job steps that execute Transact-SQL do not use SQL Server Agent proxies. Transact-SQL job steps run in the security context of the owner of the job. To set the security context for a Transact-SQL job step, use the database_user_name parameter in the sp_add_jobstep stored procedure.